LDAP + SASL Freeradius 3.0.11

[Isaac Boukris]

>>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 at 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 at FRENCHE.CP
SASL SSF: 56
SASL data security layer installed.
rlm_ldap (ldap) - Bind successful