Stefan Winter wrote:

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)

Ah, sorry. Did not realise that. The rest of my reply can be ignored then.


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.

Ok, quick look at main/valuepair.c:259 (in 1.1.0 source) shows:

for check_item in check_items {
  (...)

  switch (check_item->attribute) {
        case PW_PASSWORD:
                if (pairfind(request, PW_PASSWORD) == NULL) {
                        continue;
                }
                break;
  }
}

That is, if the checkitem is User-Password the check is SKIPPED if there's no User-Password in the request. Since the default return value if "paircmp" is 0, if the line consists solely of:

username User-Password ~= (foo|bar)

...then it'll match.

Actually I can see why it does that, and arguably it's not wildly invalid. That said, the comments before that case statement refer to it as a hack.

The only thing I can think of is to add another checkitem to the users file that will only match for the PAP-using service (huntgroup?) - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Reply via email to