All password checks disbaled... ugh
Hi, posting to devel, as this is possibly a severe bug. Apologies if not. In FR 2, I authenticated our staff against a users-style file, setting NT-Password := ... Their passwords were checked. In FreeRADIUS 3, I retained this, NT-Passwords are found, pap returns noop(?), authorize returns ok, and then I see Auth-Type = Accept, accepting the user *regardless of his password* ? I've rolled back the one affected vserver that had this problem, but would be really interested in an explanation. here is the -X flow: rad_recv: Access-Request packet from host 158.64.1.65 port 46814, id=96, length=63 User-Name = 'ctompers' User-Password = '' NAS-Identifier = 'AAI-Staff-IdP' (11) # Executing section authorize from file /usr/local/freeradius/config/raddb/sites-enabled/AAI (11) authorize { (11) if ( NAS-Identifier == "AAI-Staff-IdP" ) (11) if ( NAS-Identifier == "AAI-Staff-IdP" ) -> TRUE (11) if ( NAS-Identifier == "AAI-Staff-IdP" ) { (11) update request { (11) RESTENA-Service-Type := 'Staff-AAI' (11) } # update request = noop (11) } # if ( NAS-Identifier == "AAI-Staff-IdP" ) = noop (11) ... skipping else for request 11: Preceding "if" was taken (11) suffix : No '@' in User-Name = "ctompers", looking up realm NULL (11) suffix : No such realm "NULL" (11) [suffix] = noop (11) if ( NAS-Identifier == "AAI-Staff-IdP" ) (11) if ( NAS-Identifier == "AAI-Staff-IdP" ) -> TRUE (11) if ( NAS-Identifier == "AAI-Staff-IdP" ) { (11) update control { (11) Proxy-To-Realm := 'TO-STAFF' (11) } # update control = noop (11) } # if ( NAS-Identifier == "AAI-Staff-IdP" ) = noop (11) ... skipping else for request 11: Preceding "if" was taken (11) } # authorize = noop Proxying to virtual server staff (11) # Executing section authorize from file /usr/local/freeradius/config/raddb/sites-enabled/staff (11) authorize { (11) if ( "%{NAS-Identifier}" == "ejabberd" ) (11) EXPAND %{NAS-Identifier} (11) --> AAI-Staff-IdP (11) if ( "%{NAS-Identifier}" == "ejabberd" ) -> FALSE (11) elsif ( "%{NAS-Identifier}" == "AAI-Staff-IdP" ) (11) EXPAND %{NAS-Identifier} (11) --> AAI-Staff-IdP (11) elsif ( "%{NAS-Identifier}" == "AAI-Staff-IdP" ) -> TRUE (11) elsif ( "%{NAS-Identifier}" == "AAI-Staff-IdP" ) { (11) update request { (11) RESTENA-Service-Type = 'Staff-AAI' (11) } # update request = noop (11) } # elsif ( "%{NAS-Identifier}" == "AAI-Staff-IdP" ) = noop (11) ... skipping else for request 11: Preceding "if" was taken (11) if ( "%{client:staff_type}" == "Nagios-Login" && User-Name == "testuser.monitor" ) (11) Client does not contain config item "staff_type" (11) EXPAND %{client:staff_type} (11) --> (11) if ( "%{client:staff_type}" == "Nagios-Login" && User-Name == "testuser.monitor" ) -> FALSE (11) if ( "%{RESTENA-Service-Type}" == "Staff-Jabber" ) (11) EXPAND %{RESTENA-Service-Type} (11) --> Staff-AAI (11) if ( "%{RESTENA-Service-Type}" == "Staff-Jabber" ) -> FALSE (11) auth_log_silent : EXPAND /var/log/radius/radacct/%Y%m%d/%{RESTENA-Service-Type}-service/auth-detail (11) auth_log_silent : --> /var/log/radius/radacct/20140415/Staff-AAI-service/auth-detail (11) auth_log_silent : /var/log/radius/radacct/%Y%m%d/%{RESTENA-Service-Type}-service/auth-detail expands to /var/log/radius/radacct/20140415/Staff-AAI-service/auth-detail (11) auth_log_silent : EXPAND %t (11) auth_log_silent : --> Tue Apr 15 09:57:57 2014 (11) [auth_log_silent] = ok (11) if ( "%{RESTENA-Service-Type}" == "Staff-IMAP" && "%{strlen:%{User-Password}}" == "96" ) (11) EXPAND %{RESTENA-Service-Type} (11) --> Staff-AAI (11) if ( "%{RESTENA-Service-Type}" == "Staff-IMAP" && "%{strlen:%{User-Password}}" == "96" ) -> FALSE (11) else else { (11) staff-auth : users: Matched entry ctompers at line 22 (11) [staff-auth] = ok (11) } # else else = ok (11) if ( "%{RESTENA-Service-Type}" == "Staff-AAI" ) (11) EXPAND %{RESTENA-Service-Type} (11) --> Staff-AAI (11) if ( "%{RESTENA-Service-Type}" == "Staff-AAI" ) -> TRUE (11) if ( "%{RESTENA-Service-Type}" == "Staff-AAI" ) { (11) staff-attributes : users: Matched entry ctompers at line 45 (11) [staff-attributes] = ok (11) } # if ( "%{RESTENA-Service-Type}" == "Staff-AAI" ) = ok (11) [mschap] = noop (11) [eap-staff] = noop (11) [pap] = noop (11) if ( "%{Packet-Src-IP-Address}" == "158.64.1.229" ) (11) EXPAND %{Packet-Src-IP-Address} (11) --> 158.64.1.65 (11) if ( "%{Packet-Src-IP-Address}" == "158.64.1.229" ) -> FALSE (11) } # authorize = ok (11) Auth-Type = Accept, accepting the user (11) # Executing section post-auth from file /usr/local/freeradius/config/raddb/sites-enabled/staff (11) post-auth { (11) restena_log_policy restena_log_policy { You see two files matches: the first one, "staff-auth : users: Matched entry ctompers at line 22" is the NT-Password: [...] ctompers NT-Password := EA38E7ADC559499F31CF4FA0F195ABCD [...] (the password hash is edited) The second match is a series of reply attributes, none of which is Auth-Type of course. The match at that line 45 is expected. But... WHY does it not check the password against the NT-Password? This same config works with FreeRADIUS 2; pap returns updated, authorize returns updated, and authenticate checks the input against the configured password? Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66
Hi, On Tue, Apr 15, 2014 at 10:26:22AM +0200, Stefan Winter wrote:
In FreeRADIUS 3, I retained this, NT-Passwords are found, pap returns noop(?), authorize returns ok, and then I see
Auth-Type = Accept, accepting the user
*regardless of his password* ?
Can't reproduce it here. Have you got a minimal config that creates it? The pap module returns noop without printing output in only a very few cases, the only ones really is if it can't find a password and you're proxying or some eap types are set. The only case I can see is if the dictionary lookup for the module name fails, and it can't set the auth-type name correctly. But even then it sets Auth-Type to 0, not 254 (Accept). ...
(11) [mschap] = noop (11) [eap-staff] = noop (11) [pap] = noop (11) if ( "%{Packet-Src-IP-Address}" == "158.64.1.229" ) (11) EXPAND %{Packet-Src-IP-Address} (11) --> 158.64.1.65 (11) if ( "%{Packet-Src-IP-Address}" == "158.64.1.229" ) -> FALSE (11) } # authorize = ok (11) Auth-Type = Accept, accepting the user ...
Are you sure it's definitely the pap module that's setting Auth-Type? If you comment it out, does the blank password still authenticate? If so, a binary chop on your config to find the culprit may be helpful. Matthew -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
Hi,
Hi,
On Tue, Apr 15, 2014 at 10:26:22AM +0200, Stefan Winter wrote:
In FreeRADIUS 3, I retained this, NT-Passwords are found, pap returns noop(?), authorize returns ok, and then I see
Auth-Type = Accept, accepting the user
*regardless of his password* ? Can't reproduce it here. Have you got a minimal config that creates it?
Sorry, limited time to work on this today. Maybe tomorrow.
The pap module returns noop without printing output in only a very few cases, the only ones really is if it can't find a password and you're proxying or some eap types are set.
As you see, no proxying (no suffix module at all) nor EAP-Message in the debug log.
The only case I can see is if the dictionary lookup for the module name fails, and it can't set the auth-type name correctly. But even then it sets Auth-Type to 0, not 254 (Accept).
I have looked at other occasions where NT-Password gets used (e.g. we have a vserver which pulls it out of SQL). I guess I should be seeing that normify() outputs something in the debug output I sent - but not at all. It is hex-encoded though, so the RDEBUG2 inside normify can't possibly be silent. This makes me believe that the NT-Password is not actually evaluated . But then again, the log also says that the line matched, so it should really get going. Wondering about inst->normify - that's inside an if. Maybe it is false, so pw_found is set to true, but the normifying is never done? I also see that instantiate() does not set inst->normify. Does it have to? Not good enough in C to answer this. I should also note that other clients are mapped to the same virtual server - and check the password correctly. It only fails deterministically for two clients of that virtual server. Greetings, Stefan Winter
...
(11) [mschap] = noop (11) [eap-staff] = noop (11) [pap] = noop (11) if ( "%{Packet-Src-IP-Address}" == "158.64.1.229" ) (11) EXPAND %{Packet-Src-IP-Address} (11) --> 158.64.1.65 (11) if ( "%{Packet-Src-IP-Address}" == "158.64.1.229" ) -> FALSE (11) } # authorize = ok (11) Auth-Type = Accept, accepting the user ...
Are you sure it's definitely the pap module that's setting Auth-Type? If you comment it out, does the blank password still authenticate?
If so, a binary chop on your config to find the culprit may be helpful.
Matthew
Follow-up to myself,
As you see, no proxying (no suffix module at all) nor EAP-Message in the debug log.
Ah, there is a suffix instance but it does nothing, noop.
I have looked at other occasions where NT-Password gets used (e.g. we have a vserver which pulls it out of SQL). I guess I should be seeing that normify() outputs something in the debug output I sent - but not at all. It is hex-encoded though, so the RDEBUG2 inside normify can't possibly be silent.
This makes me believe that the NT-Password is not actually evaluated . But then again, the log also says that the line matched, so it should really get going.
Wondering about inst->normify - that's inside an if. Maybe it is false, so pw_found is set to true, but the normifying is never done? I also see that instantiate() does not set inst->normify. Does it have to? Not good enough in C to answer this.
Found that it is set in config. My pap module config is really minimal: pap { auto_header = no } It doesn't set normalise, and as per code it then defaults to "yes". So inst->normify should do its job. Which means I'm more clueless than before, if that's even possible :-( Stefan
I should also note that other clients are mapped to the same virtual server - and check the password correctly. It only fails deterministically for two clients of that virtual server.
Greetings,
Stefan Winter
...
(11) [mschap] = noop (11) [eap-staff] = noop (11) [pap] = noop (11) if ( "%{Packet-Src-IP-Address}" == "158.64.1.229" ) (11) EXPAND %{Packet-Src-IP-Address} (11) --> 158.64.1.65 (11) if ( "%{Packet-Src-IP-Address}" == "158.64.1.229" ) -> FALSE (11) } # authorize = ok (11) Auth-Type = Accept, accepting the user ...
Are you sure it's definitely the pap module that's setting Auth-Type? If you comment it out, does the blank password still authenticate?
If so, a binary chop on your config to find the culprit may be helpful.
Matthew
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
On 15 Apr 2014, at 13:17, Stefan Winter <stefan.winter@restena.lu> wrote:
Follow-up to myself,
As you see, no proxying (no suffix module at all) nor EAP-Message in the debug log.
Ah, there is a suffix instance but it does nothing, noop.
I have looked at other occasions where NT-Password gets used (e.g. we have a vserver which pulls it out of SQL). I guess I should be seeing that normify() outputs something in the debug output I sent - but not at all. It is hex-encoded though, so the RDEBUG2 inside normify can't possibly be silent.
This makes me believe that the NT-Password is not actually evaluated . But then again, the log also says that the line matched, so it should really get going.
Wondering about inst->normify - that's inside an if. Maybe it is false, so pw_found is set to true, but the normifying is never done? I also see that instantiate() does not set inst->normify. Does it have to? Not good enough in C to answer this.
Found that it is set in config. My pap module config is really minimal: pap { auto_header = no }
It doesn't set normalise, and as per code it then defaults to "yes". So inst->normify should do its job.
Which means I'm more clueless than before, if that's even possible :-(
Use GDB and step through? It can attach to a running process, especially if you've got a panic action set :) Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
Hi,
Found that it is set in config. My pap module config is really minimal: pap { auto_header = no }
It doesn't set normalise, and as per code it then defaults to "yes". So inst->normify should do its job.
Which means I'm more clueless than before, if that's even possible :-( Use GDB and step through?
It can attach to a running process, especially if you've got a panic action set :)
Might do. Meanwhile, one of the mini things I found while chasing ghosts is that my "files" instance separates the username and the NT-Password := ABCDFOO with *spaces*, while the doc says it need to be tabs. I see now that that requirement was also in v2 - but it worked there. My theory is that it might have matched line 22, but not actually picked up the password; and then by some dubious assumption concluded "nothing to check, so Accept"? This doesn't explain why other clients on the same virtual server do check the NT-Password. Oh well. Hope that's not it, but... let me know. It's going to be one of the things to test when back in the office. Stefan
Stefan Winter wrote:
Found that it is set in config. My pap module config is really minimal: pap { auto_header = no
The auto_header directive has been removed in v3. The User-Password is now always just the password. The Password-With-Header attribute should contain the header.
Might do. Meanwhile, one of the mini things I found while chasing ghosts is that my "files" instance separates the username and the NT-Password := ABCDFOO with *spaces*, while the doc says it need to be tabs.
Both spaces and tabs are accepted. The "users" file parsing code hasn't changed in v3.
My theory is that it might have matched line 22, but not actually picked up the password; and then by some dubious assumption concluded "nothing to check, so Accept"?
No. If there's no Cleartext-Password, it should default to rejecting the request.
This doesn't explain why other clients on the same virtual server do check the NT-Password. Oh well.
No idea. Alan DeKok.
Hi,
The auto_header directive has been removed in v3. The User-Password is now always just the password. The Password-With-Header attribute should contain the header.
Well, it exists as documentation / sample config piece in 3.0.2's radds/mods-avilable/pap. Not that I care; I don't use that functionality. But if it has been removed, the docs shouldn't talk about it any more. But seriously... this is just a side issue. I'm MUCH more concerned about proxy-to-vserver requests behaving very strangely, to the extent of defaulting to Accept. Any news on that main issue? Greetings, Stefan Winter
Might do. Meanwhile, one of the mini things I found while chasing ghosts is that my "files" instance separates the username and the NT-Password := ABCDFOO with *spaces*, while the doc says it need to be tabs.
Both spaces and tabs are accepted. The "users" file parsing code hasn't changed in v3.
My theory is that it might have matched line 22, but not actually picked up the password; and then by some dubious assumption concluded "nothing to check, so Accept"?
No. If there's no Cleartext-Password, it should default to rejecting the request.
This doesn't explain why other clients on the same virtual server do check the NT-Password. Oh well.
No idea.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
-- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66
Stefan Winter wrote:
Well, it exists as documentation / sample config piece in 3.0.2's radds/mods-avilable/pap.
I've fixed that, and updated the documentation.
But seriously... this is just a side issue. I'm MUCH more concerned about proxy-to-vserver requests behaving very strangely, to the extent of defaulting to Accept.
Any news on that main issue?
I'll try to look at it today. This weekend is a 4 day holiday, so I may not get to it until Tuesday. Alan DeKok.
Hi, I think I have found it now: there is one difference between the two clients which exhibit this strange behaviour and all others which authenticate correctly. The difference is in that the wrongly handled request were previously proxied to the "staff" virtual server; all other clients are dispatched immediately to that virtual server. Below is a -X debug of a request that went to staff natively, and which works: rad_recv: Access-Request packet from host 158.64.2.228 port 47328, id=105, length=63 User-Name = 'ctompers' User-Password = 'sdfghjk' NAS-Identifier = 'AAI-Staff-IdP' (2) # Executing section authorize from file /usr/local/freeradius/config/raddb/sites-enabled/staff (2) authorize { (2) if ( "%{NAS-Identifier}" == "ejabberd" ) (2) EXPAND %{NAS-Identifier} (2) --> AAI-Staff-IdP (2) if ( "%{NAS-Identifier}" == "ejabberd" ) -> FALSE (2) elsif ( "%{NAS-Identifier}" == "AAI-Staff-IdP" ) (2) EXPAND %{NAS-Identifier} (2) --> AAI-Staff-IdP (2) elsif ( "%{NAS-Identifier}" == "AAI-Staff-IdP" ) -> TRUE (2) elsif ( "%{NAS-Identifier}" == "AAI-Staff-IdP" ) { (2) update request { (2) RESTENA-Service-Type = 'Staff-AAI' (2) } # update request = noop (2) } # elsif ( "%{NAS-Identifier}" == "AAI-Staff-IdP" ) = noop (2) ... skipping else for request 2: Preceding "if" was taken (2) if ( "%{client:staff_type}" == "Nagios-Login" && User-Name == "testuser.monitor" ) (2) EXPAND %{client:staff_type} (2) --> Usermgt (2) if ( "%{client:staff_type}" == "Nagios-Login" && User-Name == "testuser.monitor" ) -> FALSE (2) if ( "%{RESTENA-Service-Type}" == "Staff-Jabber" ) (2) EXPAND %{RESTENA-Service-Type} (2) --> Staff-AAI (2) if ( "%{RESTENA-Service-Type}" == "Staff-Jabber" ) -> FALSE (2) auth_log_silent : EXPAND /var/log/radius/radacct/%Y%m%d/%{RESTENA-Service-Type}-service/auth-detail (2) auth_log_silent : --> /var/log/radius/radacct/20140416/Staff-AAI-service/auth-detail (2) auth_log_silent : /var/log/radius/radacct/%Y%m%d/%{RESTENA-Service-Type}-service/auth-detail expands to /var/log/radius/radacct/20140416/Staff-AAI-service/auth-detail (2) auth_log_silent : EXPAND %t (2) auth_log_silent : --> Wed Apr 16 08:19:06 2014 (2) [auth_log_silent] = ok (2) if ( "%{RESTENA-Service-Type}" == "Staff-IMAP" && "%{strlen:%{User-Password}}" == "96" ) (2) EXPAND %{RESTENA-Service-Type} (2) --> Staff-AAI (2) if ( "%{RESTENA-Service-Type}" == "Staff-IMAP" && "%{strlen:%{User-Password}}" == "96" ) -> FALSE (2) else else { (2) staff-auth : users: Matched entry ctompers at line 22 (2) [staff-auth] = ok (2) } # else else = ok (2) if ( "%{RESTENA-Service-Type}" == "Staff-AAI" ) (2) EXPAND %{RESTENA-Service-Type} (2) --> Staff-AAI (2) if ( "%{RESTENA-Service-Type}" == "Staff-AAI" ) -> TRUE (2) if ( "%{RESTENA-Service-Type}" == "Staff-AAI" ) { (2) staff-attributes : users: Matched entry ctompers at line 45 (2) [staff-attributes] = ok (2) } # if ( "%{RESTENA-Service-Type}" == "Staff-AAI" ) = ok (2) [mschap] = noop (2) eap-staff : No EAP-Message, not doing EAP (2) [eap-staff] = noop (2) pap : Normalizing NT-Password from hex encoding, 32 bytes -> 16 bytes (2) [pap] = updated (2) if ( "%{Packet-Src-IP-Address}" == "158.64.1.229" ) (2) EXPAND %{Packet-Src-IP-Address} (2) --> 158.64.2.228 (2) if ( "%{Packet-Src-IP-Address}" == "158.64.1.229" ) -> FALSE (2) } # authorize = updated (2) Found Auth-Type = PAP (2) # Executing group from file /usr/local/freeradius/config/raddb/sites-enabled/staff (2) Auth-Type PAP { (2) pap : Login attempt with password (2) pap : Comparing with "known-good" NT-Password As you can see, staff/authorize/pap actually found the NT-Password and did it's stuff with it. If you compare that with the same pap instance on the other request, it just says noop. So, I can only suspect that the proxy-to-vserver functionality breaks it. Greetings, Stefan Winter On 15.04.2014 10:26, Stefan Winter wrote:
Hi,
posting to devel, as this is possibly a severe bug. Apologies if not.
In FR 2, I authenticated our staff against a users-style file, setting NT-Password := ...
Their passwords were checked.
In FreeRADIUS 3, I retained this, NT-Passwords are found, pap returns noop(?), authorize returns ok, and then I see
Auth-Type = Accept, accepting the user
*regardless of his password* ?
I've rolled back the one affected vserver that had this problem, but would be really interested in an explanation. here is the -X flow:
rad_recv: Access-Request packet from host 158.64.1.65 port 46814, id=96, length=63 User-Name = 'ctompers' User-Password = '' NAS-Identifier = 'AAI-Staff-IdP' (11) # Executing section authorize from file /usr/local/freeradius/config/raddb/sites-enabled/AAI (11) authorize { (11) if ( NAS-Identifier == "AAI-Staff-IdP" ) (11) if ( NAS-Identifier == "AAI-Staff-IdP" ) -> TRUE (11) if ( NAS-Identifier == "AAI-Staff-IdP" ) { (11) update request { (11) RESTENA-Service-Type := 'Staff-AAI' (11) } # update request = noop (11) } # if ( NAS-Identifier == "AAI-Staff-IdP" ) = noop (11) ... skipping else for request 11: Preceding "if" was taken (11) suffix : No '@' in User-Name = "ctompers", looking up realm NULL (11) suffix : No such realm "NULL" (11) [suffix] = noop (11) if ( NAS-Identifier == "AAI-Staff-IdP" ) (11) if ( NAS-Identifier == "AAI-Staff-IdP" ) -> TRUE (11) if ( NAS-Identifier == "AAI-Staff-IdP" ) { (11) update control { (11) Proxy-To-Realm := 'TO-STAFF' (11) } # update control = noop (11) } # if ( NAS-Identifier == "AAI-Staff-IdP" ) = noop (11) ... skipping else for request 11: Preceding "if" was taken (11) } # authorize = noop Proxying to virtual server staff (11) # Executing section authorize from file /usr/local/freeradius/config/raddb/sites-enabled/staff (11) authorize { (11) if ( "%{NAS-Identifier}" == "ejabberd" ) (11) EXPAND %{NAS-Identifier} (11) --> AAI-Staff-IdP (11) if ( "%{NAS-Identifier}" == "ejabberd" ) -> FALSE (11) elsif ( "%{NAS-Identifier}" == "AAI-Staff-IdP" ) (11) EXPAND %{NAS-Identifier} (11) --> AAI-Staff-IdP (11) elsif ( "%{NAS-Identifier}" == "AAI-Staff-IdP" ) -> TRUE (11) elsif ( "%{NAS-Identifier}" == "AAI-Staff-IdP" ) { (11) update request { (11) RESTENA-Service-Type = 'Staff-AAI' (11) } # update request = noop (11) } # elsif ( "%{NAS-Identifier}" == "AAI-Staff-IdP" ) = noop (11) ... skipping else for request 11: Preceding "if" was taken (11) if ( "%{client:staff_type}" == "Nagios-Login" && User-Name == "testuser.monitor" ) (11) Client does not contain config item "staff_type" (11) EXPAND %{client:staff_type} (11) --> (11) if ( "%{client:staff_type}" == "Nagios-Login" && User-Name == "testuser.monitor" ) -> FALSE (11) if ( "%{RESTENA-Service-Type}" == "Staff-Jabber" ) (11) EXPAND %{RESTENA-Service-Type} (11) --> Staff-AAI (11) if ( "%{RESTENA-Service-Type}" == "Staff-Jabber" ) -> FALSE (11) auth_log_silent : EXPAND /var/log/radius/radacct/%Y%m%d/%{RESTENA-Service-Type}-service/auth-detail (11) auth_log_silent : --> /var/log/radius/radacct/20140415/Staff-AAI-service/auth-detail (11) auth_log_silent : /var/log/radius/radacct/%Y%m%d/%{RESTENA-Service-Type}-service/auth-detail expands to /var/log/radius/radacct/20140415/Staff-AAI-service/auth-detail (11) auth_log_silent : EXPAND %t (11) auth_log_silent : --> Tue Apr 15 09:57:57 2014 (11) [auth_log_silent] = ok (11) if ( "%{RESTENA-Service-Type}" == "Staff-IMAP" && "%{strlen:%{User-Password}}" == "96" ) (11) EXPAND %{RESTENA-Service-Type} (11) --> Staff-AAI (11) if ( "%{RESTENA-Service-Type}" == "Staff-IMAP" && "%{strlen:%{User-Password}}" == "96" ) -> FALSE (11) else else { (11) staff-auth : users: Matched entry ctompers at line 22 (11) [staff-auth] = ok (11) } # else else = ok (11) if ( "%{RESTENA-Service-Type}" == "Staff-AAI" ) (11) EXPAND %{RESTENA-Service-Type} (11) --> Staff-AAI (11) if ( "%{RESTENA-Service-Type}" == "Staff-AAI" ) -> TRUE (11) if ( "%{RESTENA-Service-Type}" == "Staff-AAI" ) { (11) staff-attributes : users: Matched entry ctompers at line 45 (11) [staff-attributes] = ok (11) } # if ( "%{RESTENA-Service-Type}" == "Staff-AAI" ) = ok (11) [mschap] = noop (11) [eap-staff] = noop (11) [pap] = noop (11) if ( "%{Packet-Src-IP-Address}" == "158.64.1.229" ) (11) EXPAND %{Packet-Src-IP-Address} (11) --> 158.64.1.65 (11) if ( "%{Packet-Src-IP-Address}" == "158.64.1.229" ) -> FALSE (11) } # authorize = ok (11) Auth-Type = Accept, accepting the user (11) # Executing section post-auth from file /usr/local/freeradius/config/raddb/sites-enabled/staff (11) post-auth { (11) restena_log_policy restena_log_policy {
You see two files matches:
the first one, "staff-auth : users: Matched entry ctompers at line 22" is the NT-Password:
[...] ctompers NT-Password := EA38E7ADC559499F31CF4FA0F195ABCD [...]
(the password hash is edited)
The second match is a series of reply attributes, none of which is Auth-Type of course. The match at that line 45 is expected.
But... WHY does it not check the password against the NT-Password? This same config works with FreeRADIUS 2; pap returns updated, authorize returns updated, and authenticate checks the input against the configured password?
Greetings,
Stefan Winter
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
-- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66
Hi,
As you can see, staff/authorize/pap actually found the NT-Password and did it's stuff with it.
If you compare that with the same pap instance on the other request, it just says noop.
And if you look at the previous line, in the correct flow also the eap-staff module is not silent, prints out "eap-staff : No EAP-Message, not doing EAP"; but on the incorrect one, it only prints "noop".
So, I can only suspect that the proxy-to-vserver functionality breaks it.
And this continues to be my suspicion. Stefan
Greetings,
Stefan Winter
On 15.04.2014 10:26, Stefan Winter wrote:
Hi,
posting to devel, as this is possibly a severe bug. Apologies if not.
In FR 2, I authenticated our staff against a users-style file, setting NT-Password := ...
Their passwords were checked.
In FreeRADIUS 3, I retained this, NT-Passwords are found, pap returns noop(?), authorize returns ok, and then I see
Auth-Type = Accept, accepting the user
*regardless of his password* ?
I've rolled back the one affected vserver that had this problem, but would be really interested in an explanation. here is the -X flow:
rad_recv: Access-Request packet from host 158.64.1.65 port 46814, id=96, length=63 User-Name = 'ctompers' User-Password = '' NAS-Identifier = 'AAI-Staff-IdP' (11) # Executing section authorize from file /usr/local/freeradius/config/raddb/sites-enabled/AAI (11) authorize { (11) if ( NAS-Identifier == "AAI-Staff-IdP" ) (11) if ( NAS-Identifier == "AAI-Staff-IdP" ) -> TRUE (11) if ( NAS-Identifier == "AAI-Staff-IdP" ) { (11) update request { (11) RESTENA-Service-Type := 'Staff-AAI' (11) } # update request = noop (11) } # if ( NAS-Identifier == "AAI-Staff-IdP" ) = noop (11) ... skipping else for request 11: Preceding "if" was taken (11) suffix : No '@' in User-Name = "ctompers", looking up realm NULL (11) suffix : No such realm "NULL" (11) [suffix] = noop (11) if ( NAS-Identifier == "AAI-Staff-IdP" ) (11) if ( NAS-Identifier == "AAI-Staff-IdP" ) -> TRUE (11) if ( NAS-Identifier == "AAI-Staff-IdP" ) { (11) update control { (11) Proxy-To-Realm := 'TO-STAFF' (11) } # update control = noop (11) } # if ( NAS-Identifier == "AAI-Staff-IdP" ) = noop (11) ... skipping else for request 11: Preceding "if" was taken (11) } # authorize = noop Proxying to virtual server staff (11) # Executing section authorize from file /usr/local/freeradius/config/raddb/sites-enabled/staff (11) authorize { (11) if ( "%{NAS-Identifier}" == "ejabberd" ) (11) EXPAND %{NAS-Identifier} (11) --> AAI-Staff-IdP (11) if ( "%{NAS-Identifier}" == "ejabberd" ) -> FALSE (11) elsif ( "%{NAS-Identifier}" == "AAI-Staff-IdP" ) (11) EXPAND %{NAS-Identifier} (11) --> AAI-Staff-IdP (11) elsif ( "%{NAS-Identifier}" == "AAI-Staff-IdP" ) -> TRUE (11) elsif ( "%{NAS-Identifier}" == "AAI-Staff-IdP" ) { (11) update request { (11) RESTENA-Service-Type = 'Staff-AAI' (11) } # update request = noop (11) } # elsif ( "%{NAS-Identifier}" == "AAI-Staff-IdP" ) = noop (11) ... skipping else for request 11: Preceding "if" was taken (11) if ( "%{client:staff_type}" == "Nagios-Login" && User-Name == "testuser.monitor" ) (11) Client does not contain config item "staff_type" (11) EXPAND %{client:staff_type} (11) --> (11) if ( "%{client:staff_type}" == "Nagios-Login" && User-Name == "testuser.monitor" ) -> FALSE (11) if ( "%{RESTENA-Service-Type}" == "Staff-Jabber" ) (11) EXPAND %{RESTENA-Service-Type} (11) --> Staff-AAI (11) if ( "%{RESTENA-Service-Type}" == "Staff-Jabber" ) -> FALSE (11) auth_log_silent : EXPAND /var/log/radius/radacct/%Y%m%d/%{RESTENA-Service-Type}-service/auth-detail (11) auth_log_silent : --> /var/log/radius/radacct/20140415/Staff-AAI-service/auth-detail (11) auth_log_silent : /var/log/radius/radacct/%Y%m%d/%{RESTENA-Service-Type}-service/auth-detail expands to /var/log/radius/radacct/20140415/Staff-AAI-service/auth-detail (11) auth_log_silent : EXPAND %t (11) auth_log_silent : --> Tue Apr 15 09:57:57 2014 (11) [auth_log_silent] = ok (11) if ( "%{RESTENA-Service-Type}" == "Staff-IMAP" && "%{strlen:%{User-Password}}" == "96" ) (11) EXPAND %{RESTENA-Service-Type} (11) --> Staff-AAI (11) if ( "%{RESTENA-Service-Type}" == "Staff-IMAP" && "%{strlen:%{User-Password}}" == "96" ) -> FALSE (11) else else { (11) staff-auth : users: Matched entry ctompers at line 22 (11) [staff-auth] = ok (11) } # else else = ok (11) if ( "%{RESTENA-Service-Type}" == "Staff-AAI" ) (11) EXPAND %{RESTENA-Service-Type} (11) --> Staff-AAI (11) if ( "%{RESTENA-Service-Type}" == "Staff-AAI" ) -> TRUE (11) if ( "%{RESTENA-Service-Type}" == "Staff-AAI" ) { (11) staff-attributes : users: Matched entry ctompers at line 45 (11) [staff-attributes] = ok (11) } # if ( "%{RESTENA-Service-Type}" == "Staff-AAI" ) = ok (11) [mschap] = noop (11) [eap-staff] = noop (11) [pap] = noop (11) if ( "%{Packet-Src-IP-Address}" == "158.64.1.229" ) (11) EXPAND %{Packet-Src-IP-Address} (11) --> 158.64.1.65 (11) if ( "%{Packet-Src-IP-Address}" == "158.64.1.229" ) -> FALSE (11) } # authorize = ok (11) Auth-Type = Accept, accepting the user (11) # Executing section post-auth from file /usr/local/freeradius/config/raddb/sites-enabled/staff (11) post-auth { (11) restena_log_policy restena_log_policy {
You see two files matches:
the first one, "staff-auth : users: Matched entry ctompers at line 22" is the NT-Password:
[...] ctompers NT-Password := EA38E7ADC559499F31CF4FA0F195ABCD [...]
(the password hash is edited)
The second match is a series of reply attributes, none of which is Auth-Type of course. The match at that line 45 is expected.
But... WHY does it not check the password against the NT-Password? This same config works with FreeRADIUS 2; pap returns updated, authorize returns updated, and authenticate checks the input against the configured password?
Greetings,
Stefan Winter
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
-- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66
Hi, so, I'm now down to a simplistic setup: two vservers, two scenarios 1) vserver 2 gets packet -> Auth-Type Reject 2) vserver 1 gets packet -> proxy to vserver 2 -> Auth-Type Accept I can confirm that internal proxying is at fault. I also ran a gdb "step" for both scenarios and tried to spot differences (yuck). One thing which caught my eye (not sure if it's the neuralgic spot, but looks good): authorize/pap only gets called by vserver 2, so breaking at mod_authoirze of rlm_pap: Scenario 1) - correct behaviour: Breakpoint 1, mod_authorize (instance=0x8766e0, request=0x88fc30) at src/modules/rlm_pap/rlm_pap.c:177 177 rlm_pap_t *inst = instance; (gdb) 178 bool auth_type = false; (gdb) 179 bool found_pw = false; (gdb) 183 rad_assert(request != NULL); (gdb) 185 for (vp = fr_cursor_init(&cursor, &request->config_items); (gdb) _fr_cursor_init (cursor=0x7fffffffb508, node=0x88fc58) at src/lib/cursor.c:34 34 memset(cursor, 0, sizeof(*cursor)); (gdb) 36 if (!node || !cursor) { (gdb) 40 memcpy(&cursor->first, &node, sizeof(cursor->first)); (gdb) 41 cursor->current = *cursor->first; (gdb) 43 if (cursor->current) { (gdb) 44 VERIFY_VP(cursor->current); (gdb) 45 cursor->next = cursor->current->next; (gdb) 48 return cursor->current; (gdb) 49 } (gdb) mod_authorize (instance=0x8766e0, request=0x88fc30) at src/modules/rlm_pap/rlm_pap.c:188 188 switch (vp->da->attr) { (gdb) 296 if (inst->normify) { (gdb) 297 normify(request, vp, 16); /* ensure it's in the right format */ (gdb) normify (request=0x88fc30, vp=0x890510, min_length=16) at src/modules/rlm_pap/rlm_pap.c:128 Scenario 2) - wrong behaviour: Breakpoint 1, mod_authorize (instance=0x8766e0, request=0x88fc20) at src/modules/rlm_pap/rlm_pap.c:177 177 rlm_pap_t *inst = instance; (gdb) 178 bool auth_type = false; (gdb) 179 bool found_pw = false; (gdb) 183 rad_assert(request != NULL); (gdb) 185 for (vp = fr_cursor_init(&cursor, &request->config_items); (gdb) _fr_cursor_init (cursor=0x7fffffffb388, node=0x88fc48) at src/lib/cursor.c:34 34 memset(cursor, 0, sizeof(*cursor)); (gdb) 36 if (!node || !cursor) { (gdb) 40 memcpy(&cursor->first, &node, sizeof(cursor->first)); (gdb) 41 cursor->current = *cursor->first; (gdb) 43 if (cursor->current) { (gdb) 44 VERIFY_VP(cursor->current); (gdb) 45 cursor->next = cursor->current->next; (gdb) 48 return cursor->current; (gdb) 49 } (gdb) mod_authorize (instance=0x8766e0, request=0x88fc20) at src/modules/rlm_pap/rlm_pap.c:188 188 switch (vp->da->attr) { (gdb) 325 REALM *realm = realm_find(vp->vp_strvalue); (gdb) realm_find (name=0x890950 "TO-STAFF") at src/main/realms.c:1998 1998 if (!name) name = "NULL"; (gdb) 2000 myrealm.name = name; (gdb) 2001 realm = rbtree_finddata(realms_byname, &myrealm); (gdb) rbtree_finddata (tree=0x827930, data=0x7fffffffb1a8) at src/lib/rbtree.c:539 539 x = rbtree_find(tree, data); (gdb) Apparently, the previously-proxied request still has Proxy-To-Realm TO-STAFF in its request structure; and rlm_pap goes a different way due to that. I would think the control items list from the first vserver does not get proxied - but it is? Greetings, Stefan Winter On 15.04.2014 10:26, Stefan Winter wrote:
Hi,
posting to devel, as this is possibly a severe bug. Apologies if not.
In FR 2, I authenticated our staff against a users-style file, setting NT-Password := ...
Their passwords were checked.
In FreeRADIUS 3, I retained this, NT-Passwords are found, pap returns noop(?), authorize returns ok, and then I see
Auth-Type = Accept, accepting the user
*regardless of his password* ?
I've rolled back the one affected vserver that had this problem, but would be really interested in an explanation. here is the -X flow:
rad_recv: Access-Request packet from host 158.64.1.65 port 46814, id=96, length=63 User-Name = 'ctompers' User-Password = '' NAS-Identifier = 'AAI-Staff-IdP' (11) # Executing section authorize from file /usr/local/freeradius/config/raddb/sites-enabled/AAI (11) authorize { (11) if ( NAS-Identifier == "AAI-Staff-IdP" ) (11) if ( NAS-Identifier == "AAI-Staff-IdP" ) -> TRUE (11) if ( NAS-Identifier == "AAI-Staff-IdP" ) { (11) update request { (11) RESTENA-Service-Type := 'Staff-AAI' (11) } # update request = noop (11) } # if ( NAS-Identifier == "AAI-Staff-IdP" ) = noop (11) ... skipping else for request 11: Preceding "if" was taken (11) suffix : No '@' in User-Name = "ctompers", looking up realm NULL (11) suffix : No such realm "NULL" (11) [suffix] = noop (11) if ( NAS-Identifier == "AAI-Staff-IdP" ) (11) if ( NAS-Identifier == "AAI-Staff-IdP" ) -> TRUE (11) if ( NAS-Identifier == "AAI-Staff-IdP" ) { (11) update control { (11) Proxy-To-Realm := 'TO-STAFF' (11) } # update control = noop (11) } # if ( NAS-Identifier == "AAI-Staff-IdP" ) = noop (11) ... skipping else for request 11: Preceding "if" was taken (11) } # authorize = noop Proxying to virtual server staff (11) # Executing section authorize from file /usr/local/freeradius/config/raddb/sites-enabled/staff (11) authorize { (11) if ( "%{NAS-Identifier}" == "ejabberd" ) (11) EXPAND %{NAS-Identifier} (11) --> AAI-Staff-IdP (11) if ( "%{NAS-Identifier}" == "ejabberd" ) -> FALSE (11) elsif ( "%{NAS-Identifier}" == "AAI-Staff-IdP" ) (11) EXPAND %{NAS-Identifier} (11) --> AAI-Staff-IdP (11) elsif ( "%{NAS-Identifier}" == "AAI-Staff-IdP" ) -> TRUE (11) elsif ( "%{NAS-Identifier}" == "AAI-Staff-IdP" ) { (11) update request { (11) RESTENA-Service-Type = 'Staff-AAI' (11) } # update request = noop (11) } # elsif ( "%{NAS-Identifier}" == "AAI-Staff-IdP" ) = noop (11) ... skipping else for request 11: Preceding "if" was taken (11) if ( "%{client:staff_type}" == "Nagios-Login" && User-Name == "testuser.monitor" ) (11) Client does not contain config item "staff_type" (11) EXPAND %{client:staff_type} (11) --> (11) if ( "%{client:staff_type}" == "Nagios-Login" && User-Name == "testuser.monitor" ) -> FALSE (11) if ( "%{RESTENA-Service-Type}" == "Staff-Jabber" ) (11) EXPAND %{RESTENA-Service-Type} (11) --> Staff-AAI (11) if ( "%{RESTENA-Service-Type}" == "Staff-Jabber" ) -> FALSE (11) auth_log_silent : EXPAND /var/log/radius/radacct/%Y%m%d/%{RESTENA-Service-Type}-service/auth-detail (11) auth_log_silent : --> /var/log/radius/radacct/20140415/Staff-AAI-service/auth-detail (11) auth_log_silent : /var/log/radius/radacct/%Y%m%d/%{RESTENA-Service-Type}-service/auth-detail expands to /var/log/radius/radacct/20140415/Staff-AAI-service/auth-detail (11) auth_log_silent : EXPAND %t (11) auth_log_silent : --> Tue Apr 15 09:57:57 2014 (11) [auth_log_silent] = ok (11) if ( "%{RESTENA-Service-Type}" == "Staff-IMAP" && "%{strlen:%{User-Password}}" == "96" ) (11) EXPAND %{RESTENA-Service-Type} (11) --> Staff-AAI (11) if ( "%{RESTENA-Service-Type}" == "Staff-IMAP" && "%{strlen:%{User-Password}}" == "96" ) -> FALSE (11) else else { (11) staff-auth : users: Matched entry ctompers at line 22 (11) [staff-auth] = ok (11) } # else else = ok (11) if ( "%{RESTENA-Service-Type}" == "Staff-AAI" ) (11) EXPAND %{RESTENA-Service-Type} (11) --> Staff-AAI (11) if ( "%{RESTENA-Service-Type}" == "Staff-AAI" ) -> TRUE (11) if ( "%{RESTENA-Service-Type}" == "Staff-AAI" ) { (11) staff-attributes : users: Matched entry ctompers at line 45 (11) [staff-attributes] = ok (11) } # if ( "%{RESTENA-Service-Type}" == "Staff-AAI" ) = ok (11) [mschap] = noop (11) [eap-staff] = noop (11) [pap] = noop (11) if ( "%{Packet-Src-IP-Address}" == "158.64.1.229" ) (11) EXPAND %{Packet-Src-IP-Address} (11) --> 158.64.1.65 (11) if ( "%{Packet-Src-IP-Address}" == "158.64.1.229" ) -> FALSE (11) } # authorize = ok (11) Auth-Type = Accept, accepting the user (11) # Executing section post-auth from file /usr/local/freeradius/config/raddb/sites-enabled/staff (11) post-auth { (11) restena_log_policy restena_log_policy {
You see two files matches:
the first one, "staff-auth : users: Matched entry ctompers at line 22" is the NT-Password:
[...] ctompers NT-Password := EA38E7ADC559499F31CF4FA0F195ABCD [...]
(the password hash is edited)
The second match is a series of reply attributes, none of which is Auth-Type of course. The match at that line 45 is expected.
But... WHY does it not check the password against the NT-Password? This same config works with FreeRADIUS 2; pap returns updated, authorize returns updated, and authenticate checks the input against the configured password?
Greetings,
Stefan Winter
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
-- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66
participants (4)
-
Alan DeKok -
Arran Cudbard-Bell -
Matthew Newton -
Stefan Winter