users file: =~ and User-Password

[Stefan Winter]

> That will not work. How is the mschap module supposed to know which
> plaintext password to perform the challenge/response with? In fact,
> since the "value" is a regexp, how is it supposed to even know what the
> alternative values are (you cannot in general reverse a regexp to get
> the matching inputs).

I don't expect it to do that. This line in the users file is supposed to work 
only for services that use PAP, and can actually do a string comparison on 
User-Password. What I would like to do when these people use VPN is that 
"users" doesn't match, and the VPN-only password is subsequently fetched in 
authorize->sql, with which the mschap module can do its magic. (Sorry for not 
mentioning beforehand that these users also are in sql - just with 
User-Password := VPN password)

> Hmm. You're probably right - it should never match.

Thanks. That's my point. If it wouldn't match, user validation would work 
beautifully by fetching the appropriate VPN password from sql and my case was 
solved.

> Given that it should never match, why don't you just delete those
> entries? What are you expecting them to do? Are you expecting that to
> somehow try two passwords in turn for a user, because it won't. See
> below for a possible solution.

Well, as said above, these lines are supposed to match against PAP requests. 
(And they do - it's just the VPN case that makes trouble)

> No. The "files" modules definitely does nothing like that.

Then I really wonder why the debug output says:
    users: Matched entry foobar at line 115

> It's not, and it's not happening. Something else is going on. I would
> have to look at the source to determine what, and am busy a.t.m.

Okay, no problem. It's not urgent, I found a way around it. Still it is 
strange. And the debug output is painfully clear about "users" matching this 
line.

> Well, what you're doing (at least, the way you're doing it) is not
> possible. MSCHAP is a challenge/response algorithm, and needs a single
> unambiguous plaintext at the server to validate the response.

If =~ would work like expected, things would work the way I set them up.

> You might be able to use the module failover to do something:

Huh. Better not. My workaround was to add an entry for the VPN concentrator IP 
that does nothing and does not fall through, before the lines with the uneasy 
users. That way it jumps to sql and is happy.

> My advice to you would be to solve the non-technical problem
> non-technically and educate your users to use the correct (VPN) password
> when accessing VPN.

*sigh* We're underway. Actually, we tell these people to update their 
passwords, because then they will automatically get synchronised. But we need 
something for the transition time.

Greetings,

Stefan Winter

-- 
Stefan WINTER

RESTENA Foundation - Réseau Téléinformatique de l'Education Nationale et de 
la Recherche
R&D Engineer

6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg
email: stefan.winter at restena.lu     Tel.:     +352 424409-1
http://www.restena.lu               Fax:      +352 422473