2.0.4 occasionally loses User-Password attribute?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello list, something weird occcured today. We have one "special" user which is not in a database, but gets a Crypt-Password set hardcoded in the virtual server config. For some reason, the incoming request has a correct User-Password, but later the pap module claims there is none. Here's the -X: Going to the next request Waking up in 4.3 seconds. ~ User-Name = "cyrus" ~ User-Password = "obfuscated" ~ NAS-IP-Address = A.B.C.D ~ NAS-Identifier = "IMAP" ~ NAS-Port = 18585 ~ NAS-Port-Type = Virtual ~ Service-Type = Authenticate-Only server IMAP { +- entering group authorize ++[request] returns notfound ++? if (( User-Name == cyrus ) && ( RESTENA-Service-Type == IMAP ) ) ?? Evaluating (User-Name == cyrus ) -> TRUE ?? Evaluating (RESTENA-Service-Type == IMAP ) -> TRUE ++? if (( User-Name == cyrus ) && ( RESTENA-Service-Type == IMAP ) ) -> TRUE ++- entering if (( User-Name == cyrus ) && ( RESTENA-Service-Type == IMAP ) ) +++[control] returns notfound ++- if (( User-Name == cyrus ) && ( RESTENA-Service-Type == IMAP ) ) returns notfound ~ expand: /var/log/radius/radacct/%Y%m%d/%{RESTENA-Service-Type}-service/auth-detail - -> /var/log/radius/radacct/20080528/IMAP-service/auth-detail rlm_detail: /var/log/radius/radacct/%Y%m%d/%{RESTENA-Service-Type}-service/auth-detail expands to /var/log/radius/radacct/20080528/IMAP-service/auth-detail ~ expand: %t -> Wed May 28 13:18:12 2008 ++[auth_log] returns ok ~ expand: %{User-Name} -> cyrus rlm_sql (sql-imap): sql_set_user escaped user --> 'cyrus' rlm_sql (sql-imap): Reserving sql socket id: 1 ~ expand: (SELECT id, username, attribute, value, op FROM check_imap WHERE username='%{SQL-User-Name}') ~ UNION (SELECT id, username, attribute, value, op FROM check_imap_mailgui WHERE username='%{SQL-User-Name}') -> (SELECT id, username, attribute, value, op FROM check_imap WH ERE username='cyrus') UNION ~ (SELECT id, username, attribute, value, op FROM check_imap_mailgui WHERE username='cyrus') rlm_sql_mysql: query: (SELECT id, username, attribute, value, op FROM check_imap WHERE username='cyrus') ~ UNION (SELECT id, username, attribute, value, op FROM check_imap_mailgui WHERE username='cyrus') rlm_sql (sql-imap): Released sql socket id: 1 rlm_sql (sql-imap): User cyrus not found ++[sql-imap] returns notfound ++? if (RESTENA-Service-Type == UserGUI ) ? Evaluating (RESTENA-Service-Type == UserGUI ) -> FALSE ++? if (RESTENA-Service-Type == UserGUI ) -> FALSE rlm_pap: No clear-text password in the request. Not performing PAP. ++[pap] returns noop auth: No User-Password or CHAP-Password attribute in the request auth: Failed to validate the user. That is rather strange. The virtual server config is nothing spectacular, though non-standard, so here it is below: server IMAP { authorize { ~ # remember: UserGUI sends its own RESTENA-Service-Type, honour # it (IMAP comes without) ~ update request { ~ RESTENA-Service-Type = "IMAP" ~ } ~ if ( ( User-Name == cyrus ) && ( RESTENA-Service-Type == IMAP ) ) { ~ update control { ~ Crypt-Password := somecryptstring ~ } ~ } ~ auth_log ~ sql-imap ~ if ( RESTENA-Service-Type == UserGUI ) { ~ sql-dialup ~ } ~ pap } authenticate { ~ Auth-Type PAP{ ~ pap ~ } } The thousands of users in the sql-* databases are authenticated fine, the problem only occurs with this one static user. I'm sort of lost here. Greetings, Stefan Winter -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFIPUL5+jm90f8eFWYRAoCNAJ43yoK3MUsTaBGyVjPkgwF0WYJyBgCdFvnO BYXomOsHoqdlKRTnyGoaQyM= =ZctO -----END PGP SIGNATURE-----
Hi,
The thousands of users in the sql-* databases are authenticated fine, the problem only occurs with this one static user. I'm sort of lost here.
a long time back i reported a similar issue. we have thousands of users in AD and they are all fine. we have a monitoring user statically defined in the users file. every now and again, the password is marked as incorrect by PAP - thus the monitor fails... Wed May 28 10:52:15 2008 : Auth: Login OK: [nagios] (from client test port 0) Wed May 28 10:53:33 2008 : Auth: Login OK: [nagios] (from client test2 port 0) Wed May 28 10:57:16 2008 : Auth: Login OK: [nagios] (from client test port 0) Wed May 28 10:58:33 2008 : Auth: Login incorrect (rlm_pap: CLEAR TEXT password check failed): [nagios] (from client test2 port 0) Wed May 28 11:01:33 2008 : Auth: Login OK: [nagios] (from client test port 0) Wed May 28 11:02:16 2008 : Auth: Login OK: [nagios] (from client test2 port 0) Wed May 28 11:06:33 2008 : Auth: Login OK: [nagios] (from client test port 0) Wed May 28 11:07:15 2008 : Auth: Login OK: [nagios] (from client test2 port 0) Wed May 28 11:11:33 2008 : Auth: Login OK: [nagios] (from client test port 0) Wed May 28 11:12:15 2008 : Auth: Login OK: [nagios] (from client test2 port 0) Wed May 28 11:16:33 2008 : Auth: Login incorrect (rlm_pap: CLEAR TEXT password check failed): [nagios] (from client test port 0) alan
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 | a long time back i reported a similar issue. we have thousands of | users in AD and they are all fine. we have a monitoring user statically | defined in the users file. every now and again, the password | is marked as incorrect by PAP - thus the monitor fails... Funny enough, our own Nagios suffers from the exact same (noticed that just a few minutes later as our migration went on). That config is even simpler. It seems like a stanza like: update control { Cleartext-Password := "something" } is enough to erase the User-Password from the server's request list. Strange indeed. Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFIPVQq+jm90f8eFWYRAgJYAJ4vMqxaWXgZCQxmMcSPirgD50WsWACghC/L P1Aio8JkPM6FEr9i0dSUvWc= =gZhY -----END PGP SIGNATURE-----
Stefan Winter wrote:
Funny enough, our own Nagios suffers from the exact same (noticed that just a few minutes later as our migration went on). That config is even simpler. It seems like a stanza like:
update control { Cleartext-Password := "something" }
is enough to erase the User-Password from the server's request list.
No... the password is cached in request->password, in *addition* to being in the request list. If that pointer gets mangled, then a module will think that the password doesn't exist, even though it does. This *should* have been fixed in 2.0.4. But the underlying solution is to get rid of request->password altogether. Alan DeKok.
participants (3)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
Stefan Winter