RE: LDAP + SASL Freeradius 3.0.11
Date: Thu, 5 May 2016 21:20:37 +0000 From: "Danner, Mearl" <jmdanner@samford.edu> To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Subject: RE: LDAP + SASL Freeradius 3.0.11
You'll probably need the FQDN of the user. I.E. cn=ldaplookup, .......... Sorry I forgot to mention I did try it with the FQDN same error. Also I could not get the FQDN to work with ldapsearch I wonder if I need to use a different option to use fqdn with LDAPsearch.
Also, with most AD implementations the Users container is CN= rather than OU= In this case the person who setup AD moved all the users from the default users container to an OU called users.
Matt
Sometimes cn is not equal to samaccountname. In ad cn is a multivalued attribute. Make sure that the user only has one value in cn and use that value. Sent from my Android phone using Symantec TouchDown (www.symantec.com) -----Original Message----- From: Matthew Beckler [mbeckler@overturecenter.org] Received: Thursday, 05 May 2016, 7:42PM To: freeradius-users@lists.freeradius.org [freeradius-users@lists.freeradius.org] Subject: RE: LDAP + SASL Freeradius 3.0.11 Date: Thu, 5 May 2016 21:20:37 +0000 From: "Danner, Mearl" <jmdanner@samford.edu> To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Subject: RE: LDAP + SASL Freeradius 3.0.11
You'll probably need the FQDN of the user. I.E. cn=ldaplookup, .......... Sorry I forgot to mention I did try it with the FQDN same error. Also I could not get the FQDN to work with ldapsearch I wonder if I need to use a different option to use fqdn with LDAPsearch.
Also, with most AD implementations the Users container is CN= rather than OU= In this case the person who setup AD moved all the users from the default users container to an OU called users.
Matt - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
________________________________ From: Danner, Mearl <jmdanner@samford.edu> Sent: Thursday, May 5, 2016 7:46 PM To: freeradius-users@lists.freeradius.org Subject: RE: LDAP + SASL Freeradius 3.0.11
Sometimes cn is not equal to samaccountname. I have verified the cn is identical to the samaccountanem. I even renamed the account to make sure it was correct.
In ad cn is a multivalued attribute. Make sure that the user only has one value in cn and use that value. I have verified this as well.
I think 52e return specifically means invalid password from my research. It means username valid password/credential invalid. I wonder if something is happening to the password before it gets sent. I turned commented out sasl mech and did a tcpdump and the password looked correct in the packet. Also I did tcpdump both with running ldapsearch that worked and freeradius -X that did not and from what is human readable in the capture is very similar.
-----Original Message----- From: Freeradius-Users [mailto:freeradius-users- bounces+jmdanner=samford.edu@lists.freeradius.org] On Behalf Of Matthew Beckler Sent: Friday, May 06, 2016 1:15 PM To: freeradius-users@lists.freeradius.org Subject: Re: LDAP + SASL Freeradius 3.0.11
________________________________ From: Danner, Mearl <jmdanner@samford.edu> Sent: Thursday, May 5, 2016 7:46 PM To: freeradius-users@lists.freeradius.org Subject: RE: LDAP + SASL Freeradius 3.0.11
Sometimes cn is not equal to samaccountname. I have verified the cn is identical to the samaccountanem. I even renamed the account to make sure it was correct.
In ad cn is a multivalued attribute. Make sure that the user only has one value in cn and use that value. I have verified this as well.
I think 52e return specifically means invalid password from my research. It means username valid password/credential invalid.
I wonder if something is happening to the password before it gets sent. I turned commented out sasl mech and did a tcpdump and the password looked correct in the packet.
Also I did tcpdump both with running ldapsearch that worked and freeradius -X that did not and from what is human readable in the capture is very similar.
Can't think of much more. Have you tried the ldapsearch without SASL i.e.: Ldapsearch -x -h host -b basedn -D binddn -W
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
So since my Ldapsearch works but Freeradius is not I must be doing something different on my ldapsearch string then what Freeradius is doing? Can anyone tell me what an ldapsearch string with MD5-DIGEST would look like to duplicate how Freeradius is trying to do it. My current LDAP search string is this and it works fine: ldapsearch -LLL -Y "DIGEST-MD5" -h dc.dc.local -U ldaplookup -W -b "ou=Users,ou=OU,dc=dc,dc=local" sAMAccountName=usertoget However I receive the previously mentioned 52e error (invalid credentials) when trying to start Freeradius with that user entered in the LDAP config. Thanks Matt
-----Original Message----- From: Freeradius-Users [mailto:freeradius-users- bounces+jmdanner=samford.edu@lists.freeradius.org] On Behalf Of Matthew Beckler Sent: Tuesday, May 10, 2016 8:30 AM To: freeradius-users@lists.freeradius.org Subject: RE: LDAP + SASL Freeradius 3.0.11
So since my Ldapsearch works but Freeradius is not I must be doing something different on my ldapsearch string then what Freeradius is doing? Can anyone tell me what an ldapsearch string with MD5-DIGEST would look like to duplicate how Freeradius is trying to do it.
My current LDAP search string is this and it works fine: ldapsearch -LLL -Y "DIGEST-MD5" -h dc.dc.local -U ldaplookup -W -b "ou=Users,ou=OU,dc=dc,dc=local" sAMAccountName=usertoget
I'll try again. Have you tried simple authentication with ldapsearch i.e.: ldapsearch -x -h host -b basedn -D binddn -W <search parameters> The mechanism in AD is different with SASL DIGEST-MD5 and simple authentication. https://msdn.microsoft.com/en-us/library/cc223500.aspx Third paragraph explains how one might receive the "invalid credentials" error. Also, have you tried changing the password for the user in case there is some Unicode UTF8 magic going on?
However I receive the previously mentioned 52e error (invalid credentials) when trying to start Freeradius with that user entered in the LDAP config.
Thanks Matt
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-----Original Message----- From: Danner, Mearl [mailto:jmdanner@samford.edu] Sent: Tuesday, May 10, 2016 10:00 AM To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Subject: RE: LDAP + SASL Freeradius 3.0.11
-----Original Message-----
I'll try again. Have you tried simple authentication with ldapsearch i.e.: ldapsearch -x -h host -b basedn -D binddn -W <search parameters> Hello my AD environment requires signing so a simply bind will not work as I receive the error " Strong(er) authentication required (8)" I can tell that the username and password are correct on the simple bind however because if the username and password are wrong I get the 52e error bind however when using correct username and password I receive the stronger authentication required message.
The mechanism in AD is different with SASL DIGEST-MD5 and simple authentication. https://msdn.microsoft.com/en-us/library/cc223500.aspx Third paragraph explains how one might receive the "invalid credentials" error.
I will research this documentation thanks for the link.
Also, have you tried changing the password for the user in case there is some Unicode UTF8 magic going on? Yes I tried removing all characters except UpperLower Case Alphanumeric and also I shortened it as it was 14 characters in the beginning.
Thanks again for assisting. Matt
So abandoning MD5 trying to get Kerberos working. I can do an ldapsearch with GSSAPI however when I try to run sudo freeradius -X I get an error. Could not find a step by step document on setting up GSSAPI Kerberos to LDAP so I could have missed some steps. Basically what I have done created keytab file with credentials in it. I have tested by running Kinit with keytab file then running ldapsearch and I get results successfully. I set environmental variable KRB5_CLIENT_KTNAME. Here is the error I get : rlm_ldap (ldap): Opening additional connection (0), 1 of 32 pending slots used rlm_ldap (ldap): Connecting to ldap://srv1.dc.local:389 rlm_ldap (ldap): Starting SASL mech(s): GSSAPI SASL/GSSAPI authentication started rlm_ldap (ldap): Bind with ldaplookup@dc.local to ldap://dc.local:389 failed: Local error rlm_ldap (ldap): Opening connection failed (0) rlm_ldap (ldap): Removing connection pool /etc/freeradius/mods-enabled/ldap[8]: Instantiation failed for module "ldap" Interesting that Sudo Klist before running Freeradius -X says "Credentials cache file not found" after running freeradius -x I now have a cache file so it appears to be getting past the part similar to kinit. Matt
On Thu, May 12, 2016 at 10:49 PM, Matthew Beckler <mbeckler@overturecenter.org> wrote:
So abandoning MD5 trying to get Kerberos working. I can do an ldapsearch with GSSAPI however when I try to run sudo freeradius -X I get an error. Could not find a step by step document on setting up GSSAPI Kerberos to LDAP so I could have missed some steps. Basically what I have done created keytab file with credentials in it. I have tested by running Kinit with keytab file then running ldapsearch and I get results successfully.
I set environmental variable KRB5_CLIENT_KTNAME.
Here is the error I get :
rlm_ldap (ldap): Opening additional connection (0), 1 of 32 pending slots used rlm_ldap (ldap): Connecting to ldap://srv1.dc.local:389 rlm_ldap (ldap): Starting SASL mech(s): GSSAPI SASL/GSSAPI authentication started rlm_ldap (ldap): Bind with ldaplookup@dc.local to ldap://dc.local:389 failed: Local error
Try to comment out identity and password directives in conf.
-----Original Message----- From: Isaac Boukris [mailto:iboukris@gmail.com] Sent: Thursday, May 12, 2016 3:30 PM To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Subject: Re: LDAP + SASL Freeradius 3.0.11
Try to comment out identity and password directives in conf.
I get the same error with identity and password commented out except it says anonymous.: (Last run had password commented out but identity not) rlm_ldap (ldap): Opening additional connection (0), 1 of 32 pending slots used rlm_ldap (ldap): Connecting to ldap://dc1.dc.local:389 rlm_ldap (ldap): Starting SASL mech(s): GSSAPI SASL/GSSAPI authentication started rlm_ldap (ldap): Bind with (anonymous) to ldap://dc1.dc.local:389 failed: Local error r rlm_ldap (ldap): Opening connection failed (0) rlm_ldap (ldap): Removing connection pool /etc/freeradius/mods-enabled/ldap[8]: Instantiation failed for module "ldap" One other point to help with this. I did have some trouble in the beginning using GSSAPI with ldapsearch even as some libraries were missing. So maybe I'm still missing some things. It was giving me an "Unsupported mechanism error" until I installed the proper libraries. I know libsasl2 and sasl2-bin were installed but I think libsasl2-modules-gssapi-mit was not installed when I was getting that previous error. Also I have restarted the server and verified that ldapsearch is still working. Thanks Matt
On Fri, May 13, 2016 at 4:13 PM, Matthew Beckler <mbeckler@overturecenter.org> wrote:
-----Original Message----- From: Isaac Boukris [mailto:iboukris@gmail.com] Sent: Thursday, May 12, 2016 3:30 PM To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Subject: Re: LDAP + SASL Freeradius 3.0.11
Try to comment out identity and password directives in conf.
I get the same error with identity and password commented out except it says anonymous.: (Last run had password commented out but identity not)
Let's leave client keytab aside, if you run 'kinit' followed by 'radiusd -X' does it work (identity commented out)? And makes sure to specify correct FQDN of the DC server.
________________________________ From: Isaac Boukris <iboukris@gmail.com> Sent: Friday, May 13, 2016 11:47 AM To: FreeRadius users mailing list Subject: Re: LDAP + SASL Freeradius 3.0.11
Let's leave client keytab aside, if you run 'kinit' followed by 'radiusd -X' does it work (identity commented out)? And makes sure to specify correct FQDN of the DC server.
Same error. Ldapsearch did work after I tried freeradius -X So What I did was this : sudo kinit ldaplookup sudo freeradius -X Got this: rlm_ldap (ldap): Opening additional connection (0), 1 of 32 pending slots used rlm_ldap (ldap): Connecting to ldap://dc01.dc.local:389 rlm_ldap (ldap): Starting SASL mech(s): GSSAPI SASL/GSSAPI authentication started rlm_ldap (ldap): Bind with (anonymous) to ldap://ovdc01.ov.local:389 failed: Local error rlm_ldap (ldap): Opening connection failed (0) rlm_ldap (ldap): Removing connection pool /etc/freeradius/mods-enabled/ldap[8]: Instantiation failed for module "ldap" Then ran ldapsearch and it worked sudo ldapsearch -LLL -h dc01.dc.local -b "ou=Users,dc=dc,dc=local" sAMAccountName SASL/GSSAPI authentication started SASL username: ldaplookup@dc.LOCAL SASL SSF: 56 SASL data security layer installed. Matt
On 15 May 2016, at 12:01, Matthew Beckler <mbeckler@overturecenter.org> wrote:
________________________________ From: Isaac Boukris <iboukris@gmail.com> Sent: Friday, May 13, 2016 11:47 AM To: FreeRadius users mailing list Subject: Re: LDAP + SASL Freeradius 3.0.11
Let's leave client keytab aside, if you run 'kinit' followed by 'radiusd -X' does it work (identity commented out)? And makes sure to specify correct FQDN of the DC server.
Same error. Ldapsearch did work after I tried freeradius -X So What I did was this : sudo kinit ldaplookup sudo freeradius -X
Try with v3.1.x just in case some fixes went in there. You also may need to specify keytab location and various other bits as environmental variables. # # SASL parameters to use for admin binds # # When we're prompted by the SASL library, the config items in the SASL # section (in addition to the identity password config items above) # determine the responses given. # # If any directive is commented out, a NULL response will be # provided to cyrus-sasl. # # Unfortunately the only way to control Keberos here is through # environmental variables, as cyrus-sasl provides no API to # set the kerberos (libkrb5) config directly. # # Full documentation for MIT krb5 can be found here: # # http://web.mit.edu/kerberos/krb5-devel/doc/admin/env_variables.html # # At a minimum you probably want to set KRB5_CLIENT_KTNAME. # sasl { # SASL mechanism # mech = 'PLAIN' # SASL authorisation identity to proxy. # proxy = 'autz_id' # SASL realm. Used for kerberos. # realm = 'example.org' } -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
Let's leave client keytab aside, if you run 'kinit' followed by 'radiusd -X' does it work (identity commented out)? And makes sure to specify correct FQDN of the DC server.
Same error. Ldapsearch did work after I tried freeradius -X So What I did was this : sudo kinit ldaplookup sudo freeradius -X
Got this: rlm_ldap (ldap): Opening additional connection (0), 1 of 32 pending slots used rlm_ldap (ldap): Connecting to ldap://dc01.dc.local:389 rlm_ldap (ldap): Starting SASL mech(s): GSSAPI SASL/GSSAPI authentication started rlm_ldap (ldap): Bind with (anonymous) to ldap://ovdc01.ov.local:389 failed: Local error rlm_ldap (ldap): Opening connection failed (0) rlm_ldap (ldap): Removing connection pool /etc/freeradius/mods-enabled/ldap[8]: Instantiation failed for module "ldap"
Then ran ldapsearch and it worked sudo ldapsearch -LLL -h dc01.dc.local -b "ou=Users,dc=dc,dc=local" sAMAccountName
SASL/GSSAPI authentication started SASL username: ldaplookup@dc.LOCAL SASL SSF: 56 SASL data security layer installed.
The client keytab is used to init credentials automatically into the ccache instead of having to run 'kinit' manually. If you have already initialized krb credentials then it should work even without a keytab and its environment variable. I suspect something is the matter with the linked ldap/sasl libraries so I'd suggest to try and compare 'ldd' output on both ldapsearch and radiusd binaries. If you have selinux / apparmor try to disable them as they might prevent access to the ccache file (klist will show the ccache in use, it should be accessible to radiusd). Here is how the output looks like on my system with identity commented out (3.1.x git head): rlm_ldap (ldap) - Connecting to ldap://ms.frenche.cp:389 rlm_ldap (ldap) - Starting SASL mech(s): GSSAPI SASL/GSSAPI authentication started SASL username: anna@FRENCHE.CP SASL SSF: 56 SASL data security layer installed. rlm_ldap (ldap) - Bind successful
-----Original Message----- From: Isaac Boukris [mailto:iboukris@gmail.com] Sent: Sunday, May 15, 2016 12:12 PM To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Subject: Re: LDAP + SASL Freeradius 3.0.11
The client keytab is used to init credentials automatically into the ccache instead of having to run 'kinit' manually. If you have already initialized krb credentials then it should work even without a keytab and its environment variable.
I suspect something is the matter with the linked ldap/sasl libraries so I'd suggest to try and compare 'ldd' output on both ldapsearch and radiusd binaries. If you have selinux / apparmor try to disable them as they might prevent access to the ccache file (klist will show the ccache in use, it should be accessible to radiusd).
Here is how the output looks like on my system with identity commented out (3.1.x git head): rlm_ldap (ldap) - Connecting to ldap://ms.frenche.cp:389 rlm_ldap (ldap) - Starting SASL mech(s): GSSAPI SASL/GSSAPI authentication started SASL username: anna@FRENCHE.CP SASL SSF: 56 SASL data security layer installed. rlm_ldap (ldap) - Bind successful
So I built from GIT so now I'm on 3.1.x However still got error. This time I ran with -Xx and got a bit more output : I tried removing apparmor and still nothing. But I finally got it to bind! It must be some permissions issues. So in recap: Sudo Kinit ldaplookup Sudo freeradius -X I receive error. If I do this I get a successful bind! sudo -H -u freerad kinit ldaplookup sudo -H -u freerad freeradius -X That narrows things down to the fact that it something with permissions. Although at this point I'm not sure yet where the permission issue lies.
On Tue, May 17, 2016 at 10:34 PM, Matthew Beckler <mbeckler@overturecenter.org> wrote:
If I do this I get a successful bind! sudo -H -u freerad kinit ldaplookup sudo -H -u freerad freeradius -X
That narrows things down to the fact that it something with permissions. Although at this point I'm not sure yet where the permission issue lies.
The credential cache should be accessible to radiusd, check with klist where it points to. You may also specify a ccache file to use via CURLOPT_KRB5_CCNAME environment variable.
participants (4)
-
Arran Cudbard-Bell -
Danner, Mearl -
Isaac Boukris -
Matthew Beckler