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