Freeradius, Kerberos and Openldap GSSAPI-SASL service principal issue
Alan DeKok
aland at deployingradius.com
Fri Sep 18 14:10:48 CEST 2020
On Sep 18, 2020, at 6:56 AM, Dario García Díaz-Miguel <dgdiaz at gmv.com> wrote:
>
>> Error: rlm_ldap (ldap): Bind with (anonymous) to ldap://ex.ample.com:389 failed: Local error Thats the problem, your not allowed to anonymous bind to the AD.
> Yes, that's what I'm saying in my original message since If I don't ask manually for a ticket, it automatically tries to anon bind instead of using the service principal configured on the krb5 module.
The Krb5 module is *not* used for LDAP binding. You can change the service principle in the krb5 module, and it won't affect the LDAP bind.
So something *else* is making the ldap bind use that same service principle. i.e. it's also configured somewhere else in the system.
>> Use ldaps and use a valid user from AD.
> We are using STARTL so using ldaps is not possible.
> The service principal actually is also a user in the LDAP directory and we are using Cyrus saslauthd to passthrough the userPassword field to the PAM modules which points to kerberos and ldap in the common-auth...
That shouldn't affect the ldap bind.
What I suspect what's happening is that the LDAP client is somehow configured to user kerberos. And that won't work until you manually get a ticket.
You've got to find out where in the system you've configured that. Perhaps in the sasl / GSSAPI systems, and you've configured FreeRADIUS to use that.
FreeRADIUS does not use kerberos tickets for the LDAP binding. But it does use SASL. And SASL is likely using kerberos.
So no amount of poking FreeRADIUS will fix this. The solutions are:
* have some system automatically issue a ticket when the system starts
* configure FreeRADIUS to use a name/password for binding, instead of SASL and anonymous bind
Alan DeKok.
More information about the Freeradius-Users
mailing list