Porting ldap module configuration from 2.2.9 to 3.0.15
Hi, I am curently trying to migrate my sever from freeradius 2 to 3 and am facing a number of problems. The first in in ldap module. In version 2, I did not define an identity nor a password and the binding to ldap server is made with the user name and password, effectively using ldap to authenticate the user. In ldap logs, with Freeradius 2, I have: Aug 31 16:19:41 ldap slapd[550]: conn=60636 fd=98 ACCEPT from IP=192.41.170.6:39806 (IP=192.41.170.6:636) Aug 31 16:19:41 ldap slapd[550]: conn=60636 fd=98 TLS established tls_ssf=256 ssf=256 Aug 31 16:19:41 ldap slapd[550]: conn=60636 op=0 BIND dn="uid=on,ou=People,ou=csim,dc=cs,dc=ait,dc=ac,dc=th" method=128 Aug 31 16:19:41 ldap slapd[550]: conn=60636 op=0 BIND dn="uid=on,ou=People,ou=csim,dc=cs,dc=ait,dc=ac,dc=th" mech=SIMPLE ssf=0 Aug 31 16:19:41 ldap slapd[550]: conn=60636 op=0 RESULT tag=97 err=0 text= Aug 31 16:19:41 ldap slapd[550]: conn=60636 op=1 UNBIND Aug 31 16:19:41 ldap slapd[550]: conn=60636 fd=98 closed showing that radius has properly bound to ldap using the username (dn="on"). With the version3, I see: Aug 31 16:30:32 ldap slapd[550]: conn=60904 fd=107 ACCEPT from IP=192.41.170.3:37996 (IP=192.41.170.6:636) Aug 31 16:30:32 ldap slapd[550]: conn=60904 fd=107 TLS established tls_ssf=256 ssf=256 Aug 31 16:30:32 ldap slapd[550]: conn=60904 op=0 BIND dn="" method=128 where an anonymous bind is attempted (dn=""). I am not sure what has change in this regard between version 2 and 3, but I really need to replicate the same mechanism as in version 2, that is bind with the user name instead of going with some administrator account that would search in the ldap directory. How can I acheive that? Thanks in advance, Olivier --
On Thu, Aug 31, 2017 at 4:44 PM, Olivier <Olivier.Nicole@cs.ait.ac.th> wrote:
The first in in ldap module. In version 2, I did not define an identity nor a password and the binding to ldap server is made with the user name and password, effectively using ldap to authenticate the user.
With the version3, I see:
Aug 31 16:30:32 ldap slapd[550]: conn=60904 fd=107 ACCEPT from IP=192.41.170.3:37996 (IP=192.41.170.6:636) Aug 31 16:30:32 ldap slapd[550]: conn=60904 fd=107 TLS established tls_ssf=256 ssf=256 Aug 31 16:30:32 ldap slapd[550]: conn=60904 op=0 BIND dn="" method=128
where an anonymous bind is attempted (dn=""). I am not sure what has change in this regard between version 2 and 3, but I really need to replicate the same mechanism as in version 2, that is bind with the user name instead of going with some administrator account that would search in the ldap directory.
So you only want ldap for authentication, not authorization? Try https://wiki.freeradius.org/modules/Rlm_ldap#userdn-attribute -- Fajar
"Fajar A. Nugraha" <list@fajar.net> writes:
On Thu, Aug 31, 2017 at 4:44 PM, Olivier <Olivier.Nicole@cs.ait.ac.th> wrote:
The first in in ldap module. In version 2, I did not define an identity nor a password and the binding to ldap server is made with the user name and password, effectively using ldap to authenticate the user.
With the version3, I see:
Aug 31 16:30:32 ldap slapd[550]: conn=60904 fd=107 ACCEPT from IP=192.41.170.3:37996 (IP=192.41.170.6:636) Aug 31 16:30:32 ldap slapd[550]: conn=60904 fd=107 TLS established tls_ssf=256 ssf=256 Aug 31 16:30:32 ldap slapd[550]: conn=60904 op=0 BIND dn="" method=128
where an anonymous bind is attempted (dn=""). I am not sure what has change in this regard between version 2 and 3, but I really need to replicate the same mechanism as in version 2, that is bind with the user name instead of going with some administrator account that would search in the ldap directory.
So you only want ldap for authentication, not authorization? Try https://wiki.freeradius.org/modules/Rlm_ldap#userdn-attribute
I need only authentication, but the authentication should be done inside LDAP, with a binding using the User-Name that is provided to FreeRadius but what LDAP tells me is that I am binding with no username. I need something like http://confluence.diamond.ac.uk/display/PAAUTH/Using+LDAP+as+authentication+... TIA, Olivier --
On Tue, Sep 19, 2017 at 2:15 PM, Olivier <Olivier.Nicole@cs.ait.ac.th> wrote:
"Fajar A. Nugraha" <list@fajar.net> writes:
On Thu, Aug 31, 2017 at 4:44 PM, Olivier <Olivier.Nicole@cs.ait.ac.th> wrote:
The first in in ldap module. In version 2, I did not define an identity nor a password and the binding to ldap server is made with the user name and password, effectively using ldap to authenticate the user.
With the version3, I see:
Aug 31 16:30:32 ldap slapd[550]: conn=60904 fd=107 ACCEPT from IP= 192.41.170.3:37996 (IP=192.41.170.6:636) Aug 31 16:30:32 ldap slapd[550]: conn=60904 fd=107 TLS established tls_ssf=256 ssf=256 Aug 31 16:30:32 ldap slapd[550]: conn=60904 op=0 BIND dn="" method=128
where an anonymous bind is attempted (dn=""). I am not sure what has change in this regard between version 2 and 3, but I really need to replicate the same mechanism as in version 2, that is bind with the user name instead of going with some administrator account that would search in the ldap directory.
So you only want ldap for authentication, not authorization? Try https://wiki.freeradius.org/modules/Rlm_ldap#userdn-attribute
I need only authentication, but the authentication should be done inside LDAP, with a binding using the User-Name that is provided to FreeRadius
... which, to the best of my knowledge, the link pretty tells you how you can achieve that.
but what LDAP tells me is that I am binding with no username.
Because it needs to fill Ldap-UserDN attribute. Did you read the link? Did you follow what it says to 'avoid the ldap search completely'? -- Fajar
"Fajar A. Nugraha" <list@fajar.net> writes:
On Tue, Sep 19, 2017 at 2:15 PM, Olivier <Olivier.Nicole@cs.ait.ac.th> wrote:
"Fajar A. Nugraha" <list@fajar.net> writes:
On Thu, Aug 31, 2017 at 4:44 PM, Olivier <Olivier.Nicole@cs.ait.ac.th> wrote:
The first in in ldap module. In version 2, I did not define an identity nor a password and the binding to ldap server is made with the user name and password, effectively using ldap to authenticate the user.
With the version3, I see:
Aug 31 16:30:32 ldap slapd[550]: conn=60904 fd=107 ACCEPT from IP= 192.41.170.3:37996 (IP=192.41.170.6:636) Aug 31 16:30:32 ldap slapd[550]: conn=60904 fd=107 TLS established tls_ssf=256 ssf=256 Aug 31 16:30:32 ldap slapd[550]: conn=60904 op=0 BIND dn="" method=128
where an anonymous bind is attempted (dn=""). I am not sure what has change in this regard between version 2 and 3, but I really need to replicate the same mechanism as in version 2, that is bind with the user name instead of going with some administrator account that would search in the ldap directory.
So you only want ldap for authentication, not authorization? Try https://wiki.freeradius.org/modules/Rlm_ldap#userdn-attribute
I need only authentication, but the authentication should be done inside LDAP, with a binding using the User-Name that is provided to FreeRadius
... which, to the best of my knowledge, the link pretty tells you how you can achieve that.
but what LDAP tells me is that I am binding with no username.
Because it needs to fill Ldap-UserDN attribute.
Did you read the link? Did you follow what it says to 'avoid the ldap search completely'?
Yes I did and I added: DEFAULT Ldap-UserDN := "uid=%{User-Name},ou=People,ou=csim,dc=cs,dc=ait,dc=ac,dc=th" in the file raddb/users. But it does not change the behaviour. Also, I am wondering, because the top of the file users mention that # Configuration file for the rlm_files module. Thank you, Olivier --
On Tue, Sep 19, 2017 at 3:06 PM, Olivier <Olivier.Nicole@cs.ait.ac.th> wrote:
I need only authentication, but the authentication should be done inside LDAP, with a binding using the User-Name that is provided to FreeRadius
... which, to the best of my knowledge, the link pretty tells you how you can achieve that.
but what LDAP tells me is that I am binding with no username.
Because it needs to fill Ldap-UserDN attribute.
Did you read the link? Did you follow what it says to 'avoid the ldap search completely'?
Yes I did and I added:
DEFAULT Ldap-UserDN := "uid=%{User-Name},ou=People, ou=csim,dc=cs,dc=ait,dc=ac,dc=th"
in the file raddb/users. But it does not change the behaviour. Also, I
That is odd. Try running freeradius in debug mode (with -X), test authentication from client, and read the result (or post it here). What you should watch out for: - whether the files module are loaded and processed before ldap module - and whether Ldap-UserDN is correctly aded - what ldap module does am wondering, because the top of the file users mention that
# Configuration file for the rlm_files module.
Correct. One module can affect others. In this case, if the wiki is correct, the files module (rlm_files) can be used to add an attribute (Ldap-UserDN). If that attribute is already present, ldap module will behave differently. -- Fajar
"Fajar A. Nugraha" <list@fajar.net> writes:
On Tue, Sep 19, 2017 at 3:06 PM, Olivier <Olivier.Nicole@cs.ait.ac.th> wrote:
I need only authentication, but the authentication should be done inside LDAP, with a binding using the User-Name that is provided to FreeRadius
... which, to the best of my knowledge, the link pretty tells you how you can achieve that.
but what LDAP tells me is that I am binding with no username.
Because it needs to fill Ldap-UserDN attribute.
Did you read the link? Did you follow what it says to 'avoid the ldap search completely'?
Yes I did and I added:
DEFAULT Ldap-UserDN := "uid=%{User-Name},ou=People, ou=csim,dc=cs,dc=ait,dc=ac,dc=th"
in the file raddb/users. But it does not change the behaviour. Also, I
That is odd.
Try running freeradius in debug mode (with -X), test authentication from client, and read the result (or post it here). What you should watch out for: - whether the files module are loaded and processed before ldap module - and whether Ldap-UserDN is correctly aded - what ldap module does
am wondering, because the top of the file users mention that
# Configuration file for the rlm_files module.
Correct.
One module can affect others. In this case, if the wiki is correct, the files module (rlm_files) can be used to add an attribute (Ldap-UserDN). If that attribute is already present, ldap module will behave differently.
OK, I did not know about that and I had disabled the files module because I don't use it. I enabled it and the output is attached below. Thank you, Olivier --
On Tue, Sep 19, 2017 at 4:04 PM, Olivier <Olivier.Nicole@cs.ait.ac.th> wrote:
"Fajar A. Nugraha" <list@fajar.net> writes:
On Tue, Sep 19, 2017 at 3:06 PM, Olivier <Olivier.Nicole@cs.ait.ac.th> wrote:
I need only authentication, but the authentication should be done inside LDAP, with a binding using the User-Name that is provided to FreeRadius
... which, to the best of my knowledge, the link pretty tells you how you can achieve that.
but what LDAP tells me is that I am binding with no username.
Because it needs to fill Ldap-UserDN attribute.
Did you read the link? Did you follow what it says to 'avoid the ldap search completely'?
Yes I did and I added:
DEFAULT Ldap-UserDN := "uid=%{User-Name},ou=People, ou=csim,dc=cs,dc=ait,dc=ac,dc=th"
in the file raddb/users. But it does not change the behaviour. Also, I
That is odd.
Try running freeradius in debug mode (with -X), test authentication from client, and read the result (or post it here). What you should watch out for: - whether the files module are loaded and processed before ldap module - and whether Ldap-UserDN is correctly aded - what ldap module does
am wondering, because the top of the file users mention that
# Configuration file for the rlm_files module.
Correct.
One module can affect others. In this case, if the wiki is correct, the files module (rlm_files) can be used to add an attribute (Ldap-UserDN). If that attribute is already present, ldap module will behave differently.
OK, I did not know about that and I had disabled the files module because I don't use it.
I enabled it and the output is attached below.
At first glance I see this (0) Received Access-Request Id 149 from 192.41.170.3:30992 to 192.41.170.3:1812 length 72 (0) User-Name = "on" ... (0) authorize { ... (0) [files] = noop The last part shouldn't be there, since you should've had an entry that adds Ldap-UserDN. It should print something like this (0) authorize { (0) files: EXPAND uid=%{User-Name},ou=people,dc=company,dc=com (0) files: --> uid=testuser,ou=people,dc=company,dc=com (0) files: users: Matched entry DEFAULT at line 1 ... (0) [files] = ok Did you edit the correct file? The default (in ubuntu) is /etc/freeradius/users (or /etc/raddb/users in most other distros), which is a symlink to mods-config/files/authorize -- Fajar
"Fajar A. Nugraha" <list@fajar.net> writes:
The last part shouldn't be there, since you should've had an entry that adds Ldap-UserDN.
It should print something like this (0) authorize { (0) files: EXPAND uid=%{User-Name},ou=people,dc=company,dc=com (0) files: --> uid=testuser,ou=people,dc=company,dc=com (0) files: users: Matched entry DEFAULT at line 1 ... (0) [files] = ok
Did you edit the correct file? The default (in ubuntu) is /etc/freeradius/users (or /etc/raddb/users in most other distros), which is a symlink to mods-config/files/authorize
I found my mistake. When setting the chroot, I copied all raddb with cp(1) and the symlinks got overwritten by plain files. raddb/users was not a symlink anymore. Now I get the correct result for authorize/files. I removed any reference to ldap in the authorize section of sites-enable/default. Now I get the error "ERROR: No Auth-Type found: rejecting the user via Post-Auth-Type = Reject" With the full messages being: Ready to process requests (0) Received Access-Request Id 162 from 192.41.170.3:19766 to 192.41.170.3:1812 length 72 (0) User-Name = "on" (0) User-Password = "***** password redeacted" (0) NAS-IP-Address = 192.41.170.6 (0) NAS-Port = 0 (0) Message-Authenticator = 0x768ce2f6e2d22042c783973be35af3b8 (0) # Executing section authorize from file /usr/local/etc/raddb/sites-enabled/default (0) authorize { (0) policy filter_username { (0) if (&User-Name) { (0) if (&User-Name) -> TRUE (0) if (&User-Name) { (0) if (&User-Name =~ / /) { (0) if (&User-Name =~ / /) -> FALSE (0) if (&User-Name =~ /@[^@]*@/ ) { (0) if (&User-Name =~ /@[^@]*@/ ) -> FALSE (0) if (&User-Name =~ /\.\./ ) { (0) if (&User-Name =~ /\.\./ ) -> FALSE (0) if ((&User-Name =~ /@/) && (&User-Name !~ /@(.+)\.(.+)$/)) { (0) if ((&User-Name =~ /@/) && (&User-Name !~ /@(.+)\.(.+)$/)) -> FALSE (0) if (&User-Name =~ /\.$/) { (0) if (&User-Name =~ /\.$/) -> FALSE (0) if (&User-Name =~ /@\./) { (0) if (&User-Name =~ /@\./) -> FALSE (0) } # if (&User-Name) = notfound (0) } # policy filter_username = notfound (0) policy filter_password { (0) if (&User-Password && (&User-Password != "%{string:User-Password}")) { (0) EXPAND %{string:User-Password} (0) --> ***** password redeacted (0) if (&User-Password && (&User-Password != "%{string:User-Password}")) -> FALSE (0) } # policy filter_password = notfound (0) [preprocess] = ok (0) auth_log: EXPAND /var/log/radacct/%{%{Packet-Src-IP-Address}:-%{Packet-Src-IPv6-Address}}/auth-detail-%Y%m%d (0) auth_log: --> /var/log/radacct/192.41.170.3/auth-detail-20170920 (0) auth_log: /var/log/radacct/%{%{Packet-Src-IP-Address}:-%{Packet-Src-IPv6-Address}}/auth-detail-%Y%m%d expands to /var/log/radacct/192.41.170.3/auth-detail-20170920 (0) auth_log: EXPAND %t (0) auth_log: --> Wed Sep 20 04:48:30 2017 (0) [auth_log] = ok (0) [mschap] = noop (0) suffix: Checking for suffix after "@" (0) suffix: No '@' in User-Name = "on", looking up realm NULL (0) suffix: No such realm "NULL" (0) [suffix] = noop (0) eap: No EAP-Message, not doing EAP (0) [eap] = noop (0) files: EXPAND %{Client-IP-Address} (0) files: --> 192.41.170.3 (0) files: users: Matched entry DEFAULT at line 222 (0) files: EXPAND uid=%{User-Name},ou=People,ou=csim,dc=cs,dc=ait,dc=ac,dc=th (0) files: --> uid=on,ou=People,ou=csim,dc=cs,dc=ait,dc=ac,dc=th (0) [files] = ok (0) [expiration] = noop (0) [logintime] = noop (0) } # authorize = ok (0) ERROR: No Auth-Type found: rejecting the user via Post-Auth-Type = Reject (0) Failed to authenticate the user (0) Using Post-Auth-Type Reject (0) Post-Auth-Type sub-section not found. Ignoring. (0) # Executing group from file /usr/local/etc/raddb/sites-enabled/default (0) Login incorrect (No Auth-Type found: rejecting the user via Post-Auth-Type = Reject): [on/***** password redeacted] (from client fbsd35.cs.ait.ac.th port 0) Thank you, Olivier --
On Wed, Sep 20, 2017 at 12:11 PM, Olivier <Olivier.Nicole@cs.ait.ac.th> wrote:
"Fajar A. Nugraha" <list@fajar.net> writes:
The last part shouldn't be there, since you should've had an entry that adds Ldap-UserDN.
It should print something like this (0) authorize { (0) files: EXPAND uid=%{User-Name},ou=people,dc=company,dc=com (0) files: --> uid=testuser,ou=people,dc=company,dc=com (0) files: users: Matched entry DEFAULT at line 1 ... (0) [files] = ok
Did you edit the correct file? The default (in ubuntu) is /etc/freeradius/users (or /etc/raddb/users in most other distros), which is a symlink to mods-config/files/authorize
I found my mistake. When setting the chroot, I copied all raddb with cp(1) and the symlinks got overwritten by plain files. raddb/users was not a symlink anymore.
Now I get the correct result for authorize/files. I removed any reference to ldap in the authorize section of sites-enable/default.
Now I get the error "ERROR: No Auth-Type found: rejecting the user via Post-Auth-Type = Reject"
Here's what works for me, tested on fresh openldap user (with only one user, the 'admin' user) on ubuntu: - top of /etc/freeradius/users admin Ldap-UserDN := "cn=%{User-Name},dc=ldap1,dc=s,dc=1elf,dc=net", Auth-Type := LDAP Fall-Through = yes Adjust to your DN, obviously. If all your users are LDAP users, you should be able to replace 'admin' with 'DEFAULT' - /etc/freeradius/sites-enabled/default: comment-out '-ldap' from authorize section. You don't need it if you ONLY use LDAP for authentication with LDAP bind. uncomment these lines from authenticate section (also read the comments before these lines to understand what they do): Auth-Type LDAP { ldap } Relevant part of my debug log using 'radtest' ... (0) # Executing section authorize from file /etc/freeradius/sites-enabled/default (0) authorize { ... (0) files: EXPAND cn=%{User-Name},dc=ldap1,dc=s,dc=1elf,dc=net (0) files: --> cn=admin,dc=ldap1,dc=s,dc=1elf,dc=net (0) files: users: Matched entry admin at line 1 (0) [files] = ok ... (0) } # authorize = ok (0) Found Auth-Type = LDAP (0) # Executing group from file /etc/freeradius/sites-enabled/default (0) Auth-Type LDAP { ... rlm_ldap (ldap): Reserved connection (0) (0) ldap: Login attempt by "admin" (0) ldap: Using user DN from request "cn=admin,dc=ldap1,dc=s,dc=1elf,dc=net" (0) ldap: Waiting for bind result... (0) ldap: Bind successful (0) ldap: Bind as user "cn=admin,dc=ldap1,dc=s,dc=1elf,dc=net" was successful ... (0) [ldap] = ok (0) } # Auth-Type LDAP = ok ... (0) Sent Access-Accept Id 122 from 127.0.0.1:1812 to 127.0.0.1:46573 length 0 -- Fajar
"Fajar A. Nugraha" <list@fajar.net> writes:
On Wed, Sep 20, 2017 at 12:11 PM, Olivier <Olivier.Nicole@cs.ait.ac.th> wrote:
"Fajar A. Nugraha" <list@fajar.net> writes:
The last part shouldn't be there, since you should've had an entry that adds Ldap-UserDN.
It should print something like this (0) authorize { (0) files: EXPAND uid=%{User-Name},ou=people,dc=company,dc=com (0) files: --> uid=testuser,ou=people,dc=company,dc=com (0) files: users: Matched entry DEFAULT at line 1 ... (0) [files] = ok
Did you edit the correct file? The default (in ubuntu) is /etc/freeradius/users (or /etc/raddb/users in most other distros), which is a symlink to mods-config/files/authorize
I found my mistake. When setting the chroot, I copied all raddb with cp(1) and the symlinks got overwritten by plain files. raddb/users was not a symlink anymore.
Now I get the correct result for authorize/files. I removed any reference to ldap in the authorize section of sites-enable/default.
Now I get the error "ERROR: No Auth-Type found: rejecting the user via Post-Auth-Type = Reject"
Here's what works for me, tested on fresh openldap user (with only one user, the 'admin' user) on ubuntu:
- top of /etc/freeradius/users
admin Ldap-UserDN := "cn=%{User-Name},dc=ldap1,dc=s,dc=1elf,dc=net", Auth-Type := LDAP Fall-Through = yes
Adjust to your DN, obviously. If all your users are LDAP users, you should be able to replace 'admin' with 'DEFAULT'
- /etc/freeradius/sites-enabled/default:
comment-out '-ldap' from authorize section. You don't need it if you ONLY use LDAP for authentication with LDAP bind.
uncomment these lines from authenticate section (also read the comments before these lines to understand what they do): Auth-Type LDAP { ldap }
That's what I have (modulo the change of the DN).
Relevant part of my debug log using 'radtest' ... (0) # Executing section authorize from file /etc/freeradius/sites-enabled/default (0) authorize { ... (0) files: EXPAND cn=%{User-Name},dc=ldap1,dc=s,dc=1elf,dc=net (0) files: --> cn=admin,dc=ldap1,dc=s,dc=1elf,dc=net (0) files: users: Matched entry admin at line 1 (0) [files] = ok ... (0) } # authorize = ok (0) Found Auth-Type = LDAP (0) # Executing group from file /etc/freeradius/sites-enabled/default (0) Auth-Type LDAP { ... rlm_ldap (ldap): Reserved connection (0) (0) ldap: Login attempt by "admin" (0) ldap: Using user DN from request "cn=admin,dc=ldap1,dc=s,dc=1elf,dc=net" (0) ldap: Waiting for bind result... (0) ldap: Bind successful (0) ldap: Bind as user "cn=admin,dc=ldap1,dc=s,dc=1elf,dc=net" was successful ... (0) [ldap] = ok (0) } # Auth-Type LDAP = ok ... (0) Sent Access-Accept Id 122 from 127.0.0.1:1812 to 127.0.0.1:46573 length 0
But I still get: (0) files: EXPAND uid=%{User-Name},ou=People,ou=csim,dc=cs,dc=ait,dc=ac,dc=th (0) files: --> uid=on,ou=People,ou=csim,dc=cs,dc=ait,dc=ac,dc=th (0) [files] = ok (0) [expiration] = noop (0) [logintime] = noop (0) } # authorize = ok (0) ERROR: No Auth-Type found: rejecting the user via Post-Auth-Type = Reject Could it be something linked to user-Password vs. Cleartext-Password, as mentioned in raddb/README.rst: From version 3.0 onwards the server no longer supports authenticating against a cleartext password in the 'User-Password' attribute. Any occurences of this (for instance, in the users file) should now be changed to 'Cleartext-Password' instead. I see that radtest sends both User-Password and Cleartext-Password: Sent Access-Request Id 17 from 0.0.0.0:24803 to 192.41.170.3:1812 length 72 User-Name = "on" User-Password = "**** password redacted" NAS-IP-Address = 192.41.170.6 NAS-Port = 0 Message-Authenticator = 0x00 Cleartext-Password = "**** password redacted" but in the debug messages from radiusd -X, I only see the User-Password: Ready to process requests (0) Received Access-Request Id 17 from 192.41.170.3:24803 to 192.41.170.3:1812 length 72 (0) User-Name = "on" (0) User-Password = "**** password redacted" (0) NAS-IP-Address = 192.41.170.6 (0) NAS-Port = 0 (0) Message-Authenticator = 0xb299934119453c5d6105169256071d2a Thank you, Olivier --
On Wed, Sep 20, 2017 at 3:03 PM, Olivier <Olivier.Nicole@cs.ait.ac.th> wrote:
"Fajar A. Nugraha" <list@fajar.net> writes:
On Wed, Sep 20, 2017 at 12:11 PM, Olivier <Olivier.Nicole@cs.ait.ac.th> wrote:
"Fajar A. Nugraha" <list@fajar.net> writes:
The last part shouldn't be there, since you should've had an entry that adds Ldap-UserDN.
It should print something like this (0) authorize { (0) files: EXPAND uid=%{User-Name},ou=people,dc=company,dc=com (0) files: --> uid=testuser,ou=people,dc=company,dc=com (0) files: users: Matched entry DEFAULT at line 1 ... (0) [files] = ok
Did you edit the correct file? The default (in ubuntu) is /etc/freeradius/users (or /etc/raddb/users in most other distros), which is a symlink to mods-config/files/authorize
I found my mistake. When setting the chroot, I copied all raddb with cp(1) and the symlinks got overwritten by plain files. raddb/users was not a symlink anymore.
Now I get the correct result for authorize/files. I removed any reference to ldap in the authorize section of sites-enable/default.
Now I get the error "ERROR: No Auth-Type found: rejecting the user via Post-Auth-Type = Reject"
Here's what works for me, tested on fresh openldap user (with only one user, the 'admin' user) on ubuntu:
- top of /etc/freeradius/users
admin Ldap-UserDN := "cn=%{User-Name},dc=ldap1,dc=s,dc=1elf,dc=net", Auth-Type := LDAP Fall-Through = yes
Adjust to your DN, obviously. If all your users are LDAP users, you should be able to replace 'admin' with 'DEFAULT'
- /etc/freeradius/sites-enabled/default:
comment-out '-ldap' from authorize section. You don't need it if you ONLY use LDAP for authentication with LDAP bind.
uncomment these lines from authenticate section (also read the comments before these lines to understand what they do): Auth-Type LDAP { ldap }
That's what I have (modulo the change of the DN).
Relevant part of my debug log using 'radtest' ... (0) # Executing section authorize from file /etc/freeradius/sites-enabled/default (0) authorize { ... (0) files: EXPAND cn=%{User-Name},dc=ldap1,dc=s,dc=1elf,dc=net (0) files: --> cn=admin,dc=ldap1,dc=s,dc=1elf,dc=net (0) files: users: Matched entry admin at line 1 (0) [files] = ok ... (0) } # authorize = ok (0) Found Auth-Type = LDAP (0) # Executing group from file /etc/freeradius/sites-enabled/default (0) Auth-Type LDAP { ... rlm_ldap (ldap): Reserved connection (0) (0) ldap: Login attempt by "admin" (0) ldap: Using user DN from request "cn=admin,dc=ldap1,dc=s,dc=
1elf,dc=net"
(0) ldap: Waiting for bind result... (0) ldap: Bind successful (0) ldap: Bind as user "cn=admin,dc=ldap1,dc=s,dc=1elf,dc=net" was successful ... (0) [ldap] = ok (0) } # Auth-Type LDAP = ok ... (0) Sent Access-Accept Id 122 from 127.0.0.1:1812 to 127.0.0.1:46573 length 0
But I still get:
(0) files: EXPAND uid=%{User-Name},ou=People,ou= csim,dc=cs,dc=ait,dc=ac,dc=th (0) files: --> uid=on,ou=People,ou=csim,dc=cs,dc=ait,dc=ac,dc=th (0) [files] = ok (0) [expiration] = noop (0) [logintime] = noop (0) } # authorize = ok (0) ERROR: No Auth-Type found: rejecting the user via Post-Auth-Type = Reject
Short version: If you still get 'No Auth-Type found', your users file is different from mine. Doublecheck my example, and compare to yours. Auth-Type (in your case) should be set in users file (or whatever method you choose, can be db, ulang, etc) in authorize section.
Could it be something linked to user-Password vs. Cleartext-Password, as mentioned in raddb/README.rst:
From version 3.0 onwards the server no longer supports authenticating against a cleartext password in the 'User-Password' attribute. Any occurences of this (for instance, in the users file) should now be changed to 'Cleartext-Password' instead.
I see that radtest sends both User-Password and Cleartext-Password:
Sent Access-Request Id 17 from 0.0.0.0:24803 to 192.41.170.3:1812 length 72 User-Name = "on" User-Password = "**** password redacted" NAS-IP-Address = 192.41.170.6 NAS-Port = 0 Message-Authenticator = 0x00 Cleartext-Password = "**** password redacted"
but in the debug messages from radiusd -X, I only see the User-Password:
Ready to process requests (0) Received Access-Request Id 17 from 192.41.170.3:24803 to 192.41.170.3:1812 length 72 (0) User-Name = "on" (0) User-Password = "**** password redacted" (0) NAS-IP-Address = 192.41.170.6 (0) NAS-Port = 0 (0) Message-Authenticator = 0xb299934119453c5d6105169256071d2a
If you still get 'ERROR: No Auth-Type found: rejecting the user via Post-Auth-Type = Reject', anything that comes after that doesn't matter. Fix that first. -- Fajar
On Wed, Sep 20, 2017 at 7:40 PM, Fajar A. Nugraha <list@fajar.net> wrote:
On Wed, Sep 20, 2017 at 3:03 PM, Olivier <Olivier.Nicole@cs.ait.ac.th> wrote:
Could it be something linked to user-Password vs. Cleartext-Password, as
mentioned in raddb/README.rst:
From version 3.0 onwards the server no longer supports authenticating against a cleartext password in the 'User-Password' attribute. Any occurences of this (for instance, in the users file) should now be changed to 'Cleartext-Password' instead.
To be clear: this is related to what you have in whatever database that stores your user passwords. Can be users file, db, LDAP, etc. The attribute name stored in that database (for unencrypted password) should be 'Cleartext-Password', not 'User-Password'.
The Cleartext-Password attribute is not what the NAS (i.e. radtest, wifi access point, etc) sends.
I see that radtest sends both User-Password and Cleartext-Password:
Sent Access-Request Id 17 from 0.0.0.0:24803 to 192.41.170.3:1812 length 72 User-Name = "on" User-Password = "**** password redacted" NAS-IP-Address = 192.41.170.6 NAS-Port = 0 Message-Authenticator = 0x00 Cleartext-Password = "**** password redacted"
I believe it prints 'Cleartext-Password' for debug purposes, to show 'what password you put in the command line'. In the case of pap (default in radtest), User-Password attribute (the one that actually gets sent) will have the same value. However if you use 'radtest -t eap-md5', there will be no attribute sent that contains the clear-text password (but radtest would still print 'Cleartext-Password' and fill it with your input). You can examine the actual attributes sent using tcpdump (or other similar tools, like wireshark). An example from mine: # tcpdump -i lo port 1812 -vv tcpdump: listening on lo, link-type EN10MB (Ethernet), capture size 262144 bytes 19:46:13.702277 IP (tos 0x0, ttl 64, id 24410, offset 0, flags [none], proto UDP (17), length 103) localhost.44576 > localhost.radius: [bad udp cksum 0xfe66 -> 0x8fcb!] RADIUS, length: 75 Access-Request (1), id: 0x4c, Authenticator: 784e48bc200a17e20a5d8618c5510c27 User-Name Attribute (1), length: 7, Value: admin 0x0000: 6164 6d69 6e User-Password Attribute (2), length: 18, Value: 0x0000: *** masked *** NAS-IP-Address Attribute (4), length: 6, Value: build 0x0000: 7f00 0101 NAS-Port Attribute (5), length: 6, Value: 0 0x0000: 0000 0000 Message-Authenticator Attribute (80), length: 18, Value: ....2....&V..4.S 0x0000: 1ffc 96da 320c d71d c926 5682 8834 0f53 It sends 5 attributes, the same one as what freeradius debug mode prints. No 'Cleartext-Password' attribute sent. -- Fajar
Thank you Fajar for the time you spend helping me. Olivier "Fajar A. Nugraha" <list@fajar.net> writes:
On Wed, Sep 20, 2017 at 7:40 PM, Fajar A. Nugraha <list@fajar.net> wrote:
On Wed, Sep 20, 2017 at 3:03 PM, Olivier <Olivier.Nicole@cs.ait.ac.th> wrote:
Could it be something linked to user-Password vs. Cleartext-Password, as
mentioned in raddb/README.rst:
From version 3.0 onwards the server no longer supports authenticating against a cleartext password in the 'User-Password' attribute. Any occurences of this (for instance, in the users file) should now be changed to 'Cleartext-Password' instead.
To be clear: this is related to what you have in whatever database that stores your user passwords. Can be users file, db, LDAP, etc. The attribute name stored in that database (for unencrypted password) should be 'Cleartext-Password', not 'User-Password'.
The Cleartext-Password attribute is not what the NAS (i.e. radtest, wifi access point, etc) sends.
I see that radtest sends both User-Password and Cleartext-Password:
Sent Access-Request Id 17 from 0.0.0.0:24803 to 192.41.170.3:1812 length 72 User-Name = "on" User-Password = "**** password redacted" NAS-IP-Address = 192.41.170.6 NAS-Port = 0 Message-Authenticator = 0x00 Cleartext-Password = "**** password redacted"
I believe it prints 'Cleartext-Password' for debug purposes, to show 'what password you put in the command line'. In the case of pap (default in radtest), User-Password attribute (the one that actually gets sent) will have the same value. However if you use 'radtest -t eap-md5', there will be no attribute sent that contains the clear-text password (but radtest would still print 'Cleartext-Password' and fill it with your input).
You can examine the actual attributes sent using tcpdump (or other similar tools, like wireshark). An example from mine:
# tcpdump -i lo port 1812 -vv tcpdump: listening on lo, link-type EN10MB (Ethernet), capture size 262144 bytes 19:46:13.702277 IP (tos 0x0, ttl 64, id 24410, offset 0, flags [none], proto UDP (17), length 103) localhost.44576 > localhost.radius: [bad udp cksum 0xfe66 -> 0x8fcb!] RADIUS, length: 75 Access-Request (1), id: 0x4c, Authenticator: 784e48bc200a17e20a5d8618c5510c27 User-Name Attribute (1), length: 7, Value: admin 0x0000: 6164 6d69 6e User-Password Attribute (2), length: 18, Value: 0x0000: *** masked *** NAS-IP-Address Attribute (4), length: 6, Value: build 0x0000: 7f00 0101 NAS-Port Attribute (5), length: 6, Value: 0 0x0000: 0000 0000 Message-Authenticator Attribute (80), length: 18, Value: ....2....&V..4.S 0x0000: 1ffc 96da 320c d71d c926 5682 8834 0f53
It sends 5 attributes, the same one as what freeradius debug mode prints. No 'Cleartext-Password' attribute sent.
--
Hi Olivier, Have a look in your authorize section... You should have this in your authorize section too (*after* the 'pap' line, which should be active): if (&request:User-Password) { update control { Auth-Type = ldap } } Note that the operator is '=', not ':='. This means that an Auth-Type is only set when none exists. The message about the server no longer authenticating cleartext passwords in the User-Password attribute only refers to entries in the 'users' file or other backends (such as databases). AFAIK, RADIUS protocol will always continue to send User-Password, which the PAP module (and others) will decode based on what they find in it. Given that your Access-Request packet does contain User-Password, I suspect it's the fact that you don't set an Auth-Type with unlang that it fails. V3 is much more powerful and flexible (but stricter). :-) Stefan Paetow Moonshot Industry & Research Liaison Coordinator t: +44 (0)1235 822 125 gpg: 0x3FCE5142 xmpp: stefanp@jabber.dev.ja.net skype: stefan.paetow.janet jisc.ac.uk Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc¹s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800.
Thank you Stefan,
Have a look in your authorize section... You should have this in your authorize section too (*after* the 'pap' line, which should be active):
if (&request:User-Password) { update control { Auth-Type = ldap } }
I used if ((&request:User-Password) && (Client-IP-Address == "192.41.170.3")) { update control { Auth-Type = LDAPFIREWALL Ldap-UserDN = "uid=%{User-Name},ou=People,ou=csim,dc=cs,dc=ait,dc=ac,dc=th" } } instead, and it works fine. I can customize it by client IP (having different instances of the ldap module, with different filters). It seems to work even is authorize pap has been disabled...
Note that the operator is '=', not ':='. This means that an Auth-Type is only set when none exists.
The message about the server no longer authenticating cleartext passwords in the User-Password attribute only refers to entries in the 'users' file or other backends (such as databases). AFAIK, RADIUS protocol will always continue to send User-Password, which the PAP module (and others) will decode based on what they find in it.
Given that your Access-Request packet does contain User-Password, I suspect it's the fact that you don't set an Auth-Type with unlang that it fails.
V3 is much more powerful and flexible (but stricter).
Indeed. I am left with a warning: (0) [ldap_firewall] = ok (0) } # Auth-Type LDAPFIREWALL = ok (0) # Executing section post-auth from file /usr/local/etc/raddb/sites-enabled/default (0) post-auth { (0) update { (0) No attributes updated (0) } # update = noop (0) reply_log: EXPAND /var/log/radacct/%{%{Packet-Src-IP-Address}:-%{Packet-Src-IPv6-Address}}/reply-detail-%Y%m%d (0) reply_log: --> /var/log/radacct/192.41.170.3/reply-detail-20170921 (0) reply_log: /var/log/radacct/%{%{Packet-Src-IP-Address}:-%{Packet-Src-IPv6-Address}}/reply-detail-%Y%m%d expands to /var/log/radacct/192.41.170.3/reply-detail-20170921 (0) reply_log: WARNING: Skipping empty packet (0) [reply_log] = ok I am not sure how to eliminate this "WARNING: Skipping empty packet". Best regards, Olivier
On 21 September 2017 08:03:47 BST, Olivier <Olivier.Nicole@cs.ait.ac.th> wrote:
It seems to work even is authorize pap has been disabled...
The only reason for putting it after pap is that if you are using the pap module already and you put this before it, you will break pap. If you're not using pap, it doesn't really matter.
I am left with a warning:
(0) [ldap_firewall] = ok (0) } # Auth-Type LDAPFIREWALL = ok (0) # Executing section post-auth from file /usr/local/etc/raddb/sites-enabled/default (0) post-auth { (0) update { (0) No attributes updated (0) } # update = noop (0) reply_log: EXPAND /var/log/radacct/%{%{Packet-Src-IP-Address}:-%{Packet-Src-IPv6-Address}}/reply-detail-%Y%m%d (0) reply_log: --> /var/log/radacct/192.41.170.3/reply-detail-20170921 (0) reply_log: /var/log/radacct/%{%{Packet-Src-IP-Address}:-%{Packet-Src-IPv6-Address}}/reply-detail-%Y%m%d expands to /var/log/radacct/192.41.170.3/reply-detail-20170921 (0) reply_log: WARNING: Skipping empty packet (0) [reply_log] = ok
I am not sure how to eliminate this "WARNING: Skipping empty packet".
Your reply packet is empty, so it's just letting you know there is nothing to log this time. You can ignore it. -- Matthew
if ((&request:User-Password) && (Client-IP-Address == "192.41.170.3")) { update control { Auth-Type = LDAPFIREWALL Ldap-UserDN = "uid=%{User-Name},ou=People,ou=csim,dc=cs,dc=ait,dc=ac,dc=th" } }
instead, and it works fine. I can customize it by client IP (having different instances of the ldap module, with different filters).
Ok... If that's how you want to/can do it, that's fine. :-) Glad you got that working then. With Regards Stefan Paetow Moonshot Industry & Research Liaison Coordinator t: +44 (0)1235 822 125 gpg: 0x3FCE5142 xmpp: stefanp@jabber.dev.ja.net skype: stefan.paetow.janet jisc.ac.uk Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc¹s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800.
participants (4)
-
Fajar A. Nugraha -
Matthew Newton -
Olivier -
Stefan Paetow