I have recently built up a freeradius server V1.1.0, I am new to freeradius, since we were using and old version of Navisradius. In Navisradius it would compare the crypt password strings and log the crypt sting verses the clear text password. Is it possible to have freeradius not log the clear text passwords, while still logging the auth request? Or have it log the crypt password strings instead? My radius server is binding to a Netscape LDAP server which is storing the passwords using UNIX crypt. Yet the radius server is logging the clear test password. Thank you for your help. Corey Detail log shows: Packet-Type = Access-Request Thu Mar 23 11:23:30 2006 User-Name = "cburks" User-Password = "abc123" Vendor-3076-Attr-32 = 0x00000004 NAS-IP-Address = 172.16.15.251 NAS-Port-Type = Virtual Client-IP-Address = 172.16.15.251 Debug output shows rad_recv: Access-Request packet from host 172.16.15.251:2264, id=1, length=70 User-Name = "cburks" User-Password = "abc123" Vendor-3076-Attr-32 = 0x00000004 NAS-IP-Address = 172.16.15.251 NAS-Port-Type = Virtual Processing the authorize section of radiusd.conf modcall: entering group authorize for request 0 modcall[authorize]: module "preprocess" returns ok for request 0 radius_xlat: '/usr/local/freeradius/var/log/radius/radacct/172.16.15.251/detail ' rlm_detail: %A/%{Client-IP-Address}/detail expands to /usr/local/freeradius/var/ log/radius/radacct/172.16.15.251/detail modcall[authorize]: module "auth_log" returns ok for request 0 modcall[authorize]: module "chap" returns noop for request 0 modcall[authorize]: module "mschap" returns noop for request 0 rlm_realm: No '@' in User-Name = "cburks", looking up realm NULL rlm_realm: No such realm "NULL" modcall[authorize]: module "suffix" returns noop for request 0 rlm_eap: No EAP-Message, not doing EAP modcall[authorize]: module "eap" returns noop for request 0 users: Matched entry DEFAULT at line 234 modcall[authorize]: module "files" returns ok for request 0 rlm_ldap: - authorize rlm_ldap: performing user authorization for cburks radius_xlat: '(uid=cburks)' radius_xlat: 'ou=people,o=zhone.com' rlm_ldap: ldap_get_conn: Checking Id: 0 rlm_ldap: ldap_get_conn: Got Id: 0 rlm_ldap: attempting LDAP reconnection rlm_ldap: (re)connect to ldap-master.oak.zhone.com:389, authentication 0 rlm_ldap: bind as cn=Directory Manager/secret to ldap-master.oak.zhone.com:389 rlm_ldap: waiting for bind result ... rlm_ldap: Bind was successful rlm_ldap: performing search in ou=people,o=zhone.com, with filter (uid=cburks) rlm_ldap: looking for check items in directory... rlm_ldap: looking for reply items in directory... rlm_ldap: user cburks authorized to use remote access rlm_ldap: ldap_release_conn: Release Id: 0 modcall[authorize]: module "ldap" returns ok for request 0 modcall: leaving group authorize (returns ok) for request 0 rad_check_password: Found Auth-Type ldap auth: type "LDAP" Processing the authenticate section of radiusd.conf modcall: entering group LDAP for request 0 rlm_ldap: - authenticate rlm_ldap: login attempt by "cburks" with password "abc123" rlm_ldap: user DN: uid=CBurks,ou=People, o=zhone.com rlm_ldap: (re)connect to ldap-master.oak.zhone.com:389, authentication 1 rlm_ldap: bind as uid=CBurks,ou=People, o=zhone.com/abc123 to ldap-master.oak.zh one.com:389 rlm_ldap: waiting for bind result ... rlm_ldap: Bind was successful rlm_ldap: user cburks authenticated succesfully modcall[authenticate]: module "ldap" returns ok for request 0 modcall: leaving group LDAP (returns ok) for request 0 Processing the post-auth section of radiusd.conf modcall: entering group post-auth for request 0 radius_xlat: '/usr/local/freeradius/var/log/radius/radacct/172.16.15.251/reply- detail-20060323' rlm_detail: /usr/local/freeradius/var/log/radius/radacct/%{Client-IP-Address}/re ply-detail-%Y%m%d expands to /usr/local/freeradius/var/log/radius/radacct/172.16 .15.251/reply-detail-20060323 modcall[post-auth]: module "reply_log" returns ok for request 0 modcall: leaving group post-auth (returns ok) for request 0 Sending Access-Accept of id 1 to 172.16.15.251 port 2264 Tunnel-Type:0 = VLAN Tunnel-Medium-Type:0 = IEEE-802 Tunnel-Private-Group-Id:0 = "1" Finished request 0 Going to the next request --- Walking the entire request list --- Waking up in 6 seconds...
Yes u can hide or crypt passwords in freeradius, this question was raised in freeradius users mailing list, and if you search archives, the answer is there -----Original Message----- From: freeradius-users-bounces+radiussupport=lrcommunications.net@lists.freeradius .org [mailto:freeradius-users-bounces+radiussupport=lrcommunications.net@lists.fr eeradius.org] On Behalf Of Corey Burks Sent: Thursday, March 23, 2006 2:55 PM To: freeradius-users@lists.freeradius.org Subject: Clear text passwords I have recently built up a freeradius server V1.1.0, I am new to freeradius, since we were using and old version of Navisradius. In Navisradius it would compare the crypt password strings and log the crypt sting verses the clear text password. Is it possible to have freeradius not log the clear text passwords, while still logging the auth request? Or have it log the crypt password strings instead? My radius server is binding to a Netscape LDAP server which is storing the passwords using UNIX crypt. Yet the radius server is logging the clear test password. Thank you for your help. Corey Detail log shows: Packet-Type = Access-Request Thu Mar 23 11:23:30 2006 User-Name = "cburks" User-Password = "abc123" Vendor-3076-Attr-32 = 0x00000004 NAS-IP-Address = 172.16.15.251 NAS-Port-Type = Virtual Client-IP-Address = 172.16.15.251 Debug output shows rad_recv: Access-Request packet from host 172.16.15.251:2264, id=1, length=70 User-Name = "cburks" User-Password = "abc123" Vendor-3076-Attr-32 = 0x00000004 NAS-IP-Address = 172.16.15.251 NAS-Port-Type = Virtual Processing the authorize section of radiusd.conf modcall: entering group authorize for request 0 modcall[authorize]: module "preprocess" returns ok for request 0 radius_xlat: '/usr/local/freeradius/var/log/radius/radacct/172.16.15.251/detail ' rlm_detail: %A/%{Client-IP-Address}/detail expands to /usr/local/freeradius/var/ log/radius/radacct/172.16.15.251/detail modcall[authorize]: module "auth_log" returns ok for request 0 modcall[authorize]: module "chap" returns noop for request 0 modcall[authorize]: module "mschap" returns noop for request 0 rlm_realm: No '@' in User-Name = "cburks", looking up realm NULL rlm_realm: No such realm "NULL" modcall[authorize]: module "suffix" returns noop for request 0 rlm_eap: No EAP-Message, not doing EAP modcall[authorize]: module "eap" returns noop for request 0 users: Matched entry DEFAULT at line 234 modcall[authorize]: module "files" returns ok for request 0 rlm_ldap: - authorize rlm_ldap: performing user authorization for cburks radius_xlat: '(uid=cburks)' radius_xlat: 'ou=people,o=zhone.com' rlm_ldap: ldap_get_conn: Checking Id: 0 rlm_ldap: ldap_get_conn: Got Id: 0 rlm_ldap: attempting LDAP reconnection rlm_ldap: (re)connect to ldap-master.oak.zhone.com:389, authentication 0 rlm_ldap: bind as cn=Directory Manager/secret to ldap-master.oak.zhone.com:389 rlm_ldap: waiting for bind result ... rlm_ldap: Bind was successful rlm_ldap: performing search in ou=people,o=zhone.com, with filter (uid=cburks) rlm_ldap: looking for check items in directory... rlm_ldap: looking for reply items in directory... rlm_ldap: user cburks authorized to use remote access rlm_ldap: ldap_release_conn: Release Id: 0 modcall[authorize]: module "ldap" returns ok for request 0 modcall: leaving group authorize (returns ok) for request 0 rad_check_password: Found Auth-Type ldap auth: type "LDAP" Processing the authenticate section of radiusd.conf modcall: entering group LDAP for request 0 rlm_ldap: - authenticate rlm_ldap: login attempt by "cburks" with password "abc123" rlm_ldap: user DN: uid=CBurks,ou=People, o=zhone.com rlm_ldap: (re)connect to ldap-master.oak.zhone.com:389, authentication 1 rlm_ldap: bind as uid=CBurks,ou=People, o=zhone.com/abc123 to ldap-master.oak.zh one.com:389 rlm_ldap: waiting for bind result ... rlm_ldap: Bind was successful rlm_ldap: user cburks authenticated succesfully modcall[authenticate]: module "ldap" returns ok for request 0 modcall: leaving group LDAP (returns ok) for request 0 Processing the post-auth section of radiusd.conf modcall: entering group post-auth for request 0 radius_xlat: '/usr/local/freeradius/var/log/radius/radacct/172.16.15.251/reply- detail-20060323' rlm_detail: /usr/local/freeradius/var/log/radius/radacct/%{Client-IP-Address}/re ply-detail-%Y%m%d expands to /usr/local/freeradius/var/log/radius/radacct/172.16 .15.251/reply-detail-20060323 modcall[post-auth]: module "reply_log" returns ok for request 0 modcall: leaving group post-auth (returns ok) for request 0 Sending Access-Accept of id 1 to 172.16.15.251 port 2264 Tunnel-Type:0 = VLAN Tunnel-Medium-Type:0 = IEEE-802 Tunnel-Private-Group-Id:0 = "1" Finished request 0 Going to the next request --- Walking the entire request list --- Waking up in 6 seconds... - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Sorry in advance for my stupidity but it is still not working. I have been searching the archives and I did find a post where someone asked the same question. The response was " See 'radiusd.conf'. Look for 'log passwords'" In my radiusd.conf file I made the following changes and it is still logging my password clear text password log_auth = no log_auth_badpass = no log_auth_goodpass = no pap { encryption_scheme = crypt } Thanks Corey -----Original Message----- From: freeradius-users-bounces+cburks=zhone.com@lists.freeradius.org [mailto:freeradius-users-bounces+cburks=zhone.com@lists.freeradius.org] On Behalf Of Alex M Sent: Thursday, March 23, 2006 12:12 PM To: 'FreeRadius users mailing list' Subject: RE: Clear text passwords Yes u can hide or crypt passwords in freeradius, this question was raised in freeradius users mailing list, and if you search archives, the answer is there -----Original Message----- From: freeradius-users-bounces+radiussupport=lrcommunications.net@lists.freeradius .org [mailto:freeradius-users-bounces+radiussupport=lrcommunications.net@lists.fr eeradius.org] On Behalf Of Corey Burks Sent: Thursday, March 23, 2006 2:55 PM To: freeradius-users@lists.freeradius.org Subject: Clear text passwords I have recently built up a freeradius server V1.1.0, I am new to freeradius, since we were using and old version of Navisradius. In Navisradius it would compare the crypt password strings and log the crypt sting verses the clear text password. Is it possible to have freeradius not log the clear text passwords, while still logging the auth request? Or have it log the crypt password strings instead? My radius server is binding to a Netscape LDAP server which is storing the passwords using UNIX crypt. Yet the radius server is logging the clear test password. Thank you for your help. Corey Detail log shows: Packet-Type = Access-Request Thu Mar 23 11:23:30 2006 User-Name = "cburks" User-Password = "abc123" Vendor-3076-Attr-32 = 0x00000004 NAS-IP-Address = 172.16.15.251 NAS-Port-Type = Virtual Client-IP-Address = 172.16.15.251 Debug output shows rad_recv: Access-Request packet from host 172.16.15.251:2264, id=1, length=70 User-Name = "cburks" User-Password = "abc123" Vendor-3076-Attr-32 = 0x00000004 NAS-IP-Address = 172.16.15.251 NAS-Port-Type = Virtual Processing the authorize section of radiusd.conf modcall: entering group authorize for request 0 modcall[authorize]: module "preprocess" returns ok for request 0 radius_xlat: '/usr/local/freeradius/var/log/radius/radacct/172.16.15.251/detail ' rlm_detail: %A/%{Client-IP-Address}/detail expands to /usr/local/freeradius/var/ log/radius/radacct/172.16.15.251/detail modcall[authorize]: module "auth_log" returns ok for request 0 modcall[authorize]: module "chap" returns noop for request 0 modcall[authorize]: module "mschap" returns noop for request 0 rlm_realm: No '@' in User-Name = "cburks", looking up realm NULL rlm_realm: No such realm "NULL" modcall[authorize]: module "suffix" returns noop for request 0 rlm_eap: No EAP-Message, not doing EAP modcall[authorize]: module "eap" returns noop for request 0 users: Matched entry DEFAULT at line 234 modcall[authorize]: module "files" returns ok for request 0 rlm_ldap: - authorize rlm_ldap: performing user authorization for cburks radius_xlat: '(uid=cburks)' radius_xlat: 'ou=people,o=zhone.com' rlm_ldap: ldap_get_conn: Checking Id: 0 rlm_ldap: ldap_get_conn: Got Id: 0 rlm_ldap: attempting LDAP reconnection rlm_ldap: (re)connect to ldap-master.oak.zhone.com:389, authentication 0 rlm_ldap: bind as cn=Directory Manager/secret to ldap-master.oak.zhone.com:389 rlm_ldap: waiting for bind result ... rlm_ldap: Bind was successful rlm_ldap: performing search in ou=people,o=zhone.com, with filter (uid=cburks) rlm_ldap: looking for check items in directory... rlm_ldap: looking for reply items in directory... rlm_ldap: user cburks authorized to use remote access rlm_ldap: ldap_release_conn: Release Id: 0 modcall[authorize]: module "ldap" returns ok for request 0 modcall: leaving group authorize (returns ok) for request 0 rad_check_password: Found Auth-Type ldap auth: type "LDAP" Processing the authenticate section of radiusd.conf modcall: entering group LDAP for request 0 rlm_ldap: - authenticate rlm_ldap: login attempt by "cburks" with password "abc123" rlm_ldap: user DN: uid=CBurks,ou=People, o=zhone.com rlm_ldap: (re)connect to ldap-master.oak.zhone.com:389, authentication 1 rlm_ldap: bind as uid=CBurks,ou=People, o=zhone.com/abc123 to ldap-master.oak.zh one.com:389 rlm_ldap: waiting for bind result ... rlm_ldap: Bind was successful rlm_ldap: user cburks authenticated succesfully modcall[authenticate]: module "ldap" returns ok for request 0 modcall: leaving group LDAP (returns ok) for request 0 Processing the post-auth section of radiusd.conf modcall: entering group post-auth for request 0 radius_xlat: '/usr/local/freeradius/var/log/radius/radacct/172.16.15.251/reply- detail-20060323' rlm_detail: /usr/local/freeradius/var/log/radius/radacct/%{Client-IP-Address}/re ply-detail-%Y%m%d expands to /usr/local/freeradius/var/log/radius/radacct/172.16 .15.251/reply-detail-20060323 modcall[post-auth]: module "reply_log" returns ok for request 0 modcall: leaving group post-auth (returns ok) for request 0 Sending Access-Accept of id 1 to 172.16.15.251 port 2264 Tunnel-Type:0 = VLAN Tunnel-Medium-Type:0 = IEEE-802 Tunnel-Private-Group-Id:0 = "1" Finished request 0 Going to the next request --- Walking the entire request list --- Waking up in 6 seconds... - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Thu, 2006-23-03 at 17:44 -0500, Alan DeKok wrote:
"Corey Burks" <cburks@zhone.com> wrote:
In my radiusd.conf file I made the following changes and it is still logging my password clear text password
log_auth = no
You will have to edit the source code to the detail module to make it do what you want.
Is that the way it is supposed to be, or is it on a todo list for it to be fixed?
Guy Fraser <guy@incentre.net> wrote:
You will have to edit the source code to the detail module to make it do what you want.
Is that the way it is supposed to be, or is it on a todo list for it to be fixed?
Fixed to do what, and why? No, I'm not being dumb, I'd like to see reasons why dropping information from the detail log is a good idea. Alan DeKok.
Alan DeKok wrote:
Guy Fraser <guy@incentre.net> wrote:
You will have to edit the source code to the detail module to make it do what you want.
Is that the way it is supposed to be, or is it on a todo list for it to be fixed?
Fixed to do what, and why?
To not log passwords in the detail file, because it puts them at unnecessary risk of exposure.
No, I'm not being dumb, I'd like to see reasons why dropping information from the detail log is a good idea.
Actually, I may be confused here. Are we talking about passwords entered by users and sent to the RADIUS daemon by a NAS being logged in the radius.log or the detail file? I ask because I *don't* see this behavior (except in debugging mode) on freeradius 1.0.5. So maybe we're talking about something else. We have strict rules here about handling sensitive data; I'd be in big trouble if any of my systems was storing user-supplied passphrases in a log file. -- George C. Kaplan gckaplan@ack.berkeley.edu Communication & Network Services 510-643-0496 University of California at Berkeley
"George C. Kaplan" <gckaplan@ack.berkeley.edu> writes:
Alan DeKok wrote:
Guy Fraser <guy@incentre.net> wrote:
You will have to edit the source code to the detail module to make it do what you want.
Is that the way it is supposed to be, or is it on a todo list for it to be fixed?
Fixed to do what, and why?
To not log passwords in the detail file, because it puts them at unnecessary risk of exposure.
The detail module logs radius packets. If that's not what you want, then you probably shouldn't be using the detail module (except maybe for accounting, where there won't be any password in the packet).
No, I'm not being dumb, I'd like to see reasons why dropping information from the detail log is a good idea.
Actually, I may be confused here. Are we talking about passwords entered by users and sent to the RADIUS daemon by a NAS being logged in the radius.log or the detail file? I ask because I *don't* see this behavior (except in debugging mode) on freeradius 1.0.5. So maybe we're talking about something else.
We have strict rules here about handling sensitive data; I'd be in big trouble if any of my systems was storing user-supplied passphrases in a log file.
The default radiusd.conf does not enable detail logging for anything but accounting. The question is: Why do you want to configure the server to log the passwords and then modify the source not to honour this configuration choice? It seems a lot easier to just go with the defaults... Bjørn
Bjørn Mork wrote:
"George C. Kaplan" <gckaplan@ack.berkeley.edu> writes:
To not log passwords in the detail file, because it puts them at unnecessary risk of exposure.
The detail module logs radius packets. If that's not what you want, then you probably shouldn't be using the detail module (except maybe for accounting, where there won't be any password in the packet).
Actually, I may be confused here. Are we talking about passwords entered by users and sent to the RADIUS daemon by a NAS being logged in the radius.log or the detail file? I ask because I *don't* see this behavior (except in debugging mode) on freeradius 1.0.5. So maybe we're talking about something else.
The default radiusd.conf does not enable detail logging for anything but accounting.
OK, I was confused. This thread is about the *authentication* detail logging, which we don't use. We just use the default accounting detail logs.
The question is: Why do you want to configure the server to log the passwords and then modify the source not to honour this configuration choice? It seems a lot easier to just go with the defaults...
Well, if you log the details of the authentication packets, you get a lot of info useful for troubleshooting end-user or NAS configuration problems, even if the value of the password attribute (but not the attribute name) is suppressed. But since I've never felt the need to use the authentication detail logging, I certainly don't have a strong opinion on whether it would be worth the trouble to implement this. -- George C. Kaplan gckaplan@ack.berkeley.edu Communication & Network Services 510-643-0496 University of California at Berkeley
participants (6)
-
Alan DeKok -
Alex M -
Bjørn Mork -
Corey Burks -
George C. Kaplan -
Guy Fraser