Freeradius, Kerberos and Openldap GSSAPI-SASL service principal issue
Hi there, I'm writing to this mailing list looking for some help in order to configure Freeradius on a Kerberos and OpenLDAP GSSAPI-SASL infrastructure. We have everything working flawlessly. Freeradius service and server is working fine with krb5 and ldap modules enabled. The problem is when we need to start the freeradius service. The service only starts if you manually issue a ticket for the service kerberos principal or the host principal. This is such a strange behavior I can't understand. Krb5 module: krb5 { keytab = /etc/radius.keytab service_principal = radius/ex.ample.com pool { start = ${thread[pool].start_servers} min = ${thread[pool].min_spare_servers} max = ${thread[pool].max_servers} spare = ${thread[pool].max_spare_servers} uses = 0 lifetime = 0 idle_timeout = 0 } } The keytab /etc/radius.keytab contains the keys for the service principal radius/ex.ample.com. The service should be able to access to the keytab to asks automatically for a ticket for radius/ex.ample.com. But it doesn't. Instead, the service fails until we issue for a new ticket: kinit -k -t /etc/radius.keytab radius/ex.ample.com The ownership of this keytab is radiusd:radiusd and it has reading permissions 440. But I've also tried with 777 with no luck The reason because it does not understand is that ldap has anon bind disallowed and the freeradius service tries an anonymous bind. I know that according to the rules I should have posted the full output debug log but I'm afraid that since it's a totally isolated environment, I can't extract the whole log. Error: rlm_ldap (ldap): Bind with (anonymous) to ldap://ex.ample.com:389 failed: Local error Error: rlm_ldap (ldap): Opening connection failed (0) Error: rlm_ldap (ldap): Error: /etc/raddb/mods-enabled/ldap [8]: Instantiation failed for module "ldap" This is how the ldap module SASL section looks: sasl { mech = 'GSSAPI' realm ='EX.AMPLE.COM' } The most weird behavior is that If we issue a host ticket (kinit -k) it starts and bind correctly using the host/ex.ample.com service principal. No matter that the service principal configured on krb5 module is radius/ex.ample.com Any ideas about how to proceed and the reasons why this happens? We are running the 3.0.15-2.11.2 freeradius version on SuSE12 SP3. Thank you so much. Kind Regards. Dario Garcia Díaz-Miguel GGCS-SES Unit GGCS SKMF Infrastructure Division GMV C\ de Isaac Newton, 11 28760, Tres Cantos, Madrid España +34 918 07 21 00 +34 918 07 21 99 www.gmv.com P Please consider the environment before printing this e-mail.
Hai Marco, As far i know .. 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. Use ldaps and use a valid user from AD. Add the SPN/UPN to the keytab file, i see you already dont that, but its it also known in the AD? If not, use: ( on a member server ) net ads keytab add_update_ads radius/$(hostname -f) -U Administrator Greetz, Louis ;-)
-----Oorspronkelijk bericht----- Van: Freeradius-Users [mailto:freeradius-users-bounces+belle=bazuin.nl@lists.freerad ius.org] Namens Dario García Díaz-Miguel Verzonden: vrijdag 18 september 2020 11:54 Aan: freeradius-users@lists.freeradius.org Onderwerp: Freeradius, Kerberos and Openldap GSSAPI-SASL service principal issue
Hi there,
I'm writing to this mailing list looking for some help in order to configure Freeradius on a Kerberos and OpenLDAP GSSAPI-SASL infrastructure. We have everything working flawlessly. Freeradius service and server is working fine with krb5 and ldap modules enabled. The problem is when we need to start the freeradius service. The service only starts if you manually issue a ticket for the service kerberos principal or the host principal. This is such a strange behavior I can't understand.
Krb5 module: krb5 { keytab = /etc/radius.keytab service_principal = radius/ex.ample.com pool { start = ${thread[pool].start_servers} min = ${thread[pool].min_spare_servers} max = ${thread[pool].max_servers} spare = ${thread[pool].max_spare_servers} uses = 0 lifetime = 0 idle_timeout = 0 } }
The keytab /etc/radius.keytab contains the keys for the service principal radius/ex.ample.com. The service should be able to access to the keytab to asks automatically for a ticket for radius/ex.ample.com. But it doesn't. Instead, the service fails until we issue for a new ticket:
kinit -k -t /etc/radius.keytab radius/ex.ample.com
The ownership of this keytab is radiusd:radiusd and it has reading permissions 440. But I've also tried with 777 with no luck
The reason because it does not understand is that ldap has anon bind disallowed and the freeradius service tries an anonymous bind. I know that according to the rules I should have posted the full output debug log but I'm afraid that since it's a totally isolated environment, I can't extract the whole log. Error: rlm_ldap (ldap): Bind with (anonymous) to ldap://ex.ample.com:389 failed: Local error Error: rlm_ldap (ldap): Opening connection failed (0) Error: rlm_ldap (ldap): Error: /etc/raddb/mods-enabled/ldap [8]: Instantiation failed for module "ldap"
This is how the ldap module SASL section looks:
sasl { mech = 'GSSAPI' realm ='EX.AMPLE.COM' }
The most weird behavior is that If we issue a host ticket (kinit -k) it starts and bind correctly using the host/ex.ample.com service principal. No matter that the service principal configured on krb5 module is radius/ex.ample.com
Any ideas about how to proceed and the reasons why this happens?
We are running the 3.0.15-2.11.2 freeradius version on SuSE12 SP3.
Thank you so much. Kind Regards.
Dario Garcia Díaz-Miguel GGCS-SES Unit GGCS SKMF Infrastructure Division GMV C\ de Isaac Newton, 11 28760, Tres Cantos, Madrid España +34 918 07 21 00 +34 918 07 21 99 www.gmv.com
P Please consider the environment before printing this e-mail.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Hello Louis, Thank you for your reply.
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.
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...
Add the SPN/UPN to the keytab file, i see you already dont that, but its it also known in the AD? If not, use: ( on a member server ) net ads keytab add_update_ads radius/$(hostname -f) -U Administrator We are using OpenLDAP and Kerberos5 MIT deployed on OpenSuSE 12 SP3 so I'm afraid this is not an AD environment.
Thank you so much. Kind Regards. Thank you. Kind Regards Dario Garcia Díaz-Miguel GGCS-SES Unit GGCS SKMF Infrastructure Division GMV C\ de Isaac Newton, 11 28760, Tres Cantos, Madrid España +34 918 07 21 00 +34 918 07 21 99 www.gmv.com -----Mensaje original----- De: Freeradius-Users [mailto:freeradius-users-bounces+dgdiaz=gmv.com@lists.freeradius.org] En nombre de L.P.H. van Belle via Freeradius-Users Enviado el: viernes, 18 de septiembre de 2020 12:29 Para: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> CC: L.P.H. van Belle <belle@bazuin.nl> Asunto: RE: Freeradius, Kerberos and Openldap GSSAPI-SASL service principal issue Hai Marco, As far i know .. 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. Use ldaps and use a valid user from AD. Add the SPN/UPN to the keytab file, i see you already dont that, but its it also known in the AD? If not, use: ( on a member server ) net ads keytab add_update_ads radius/$(hostname -f) -U Administrator Greetz, Louis ;-)
-----Oorspronkelijk bericht----- Van: Freeradius-Users [mailto:freeradius-users-bounces+belle=bazuin.nl@lists.freerad ius.org] Namens Dario García Díaz-Miguel Verzonden: vrijdag 18 september 2020 11:54 Aan: freeradius-users@lists.freeradius.org Onderwerp: Freeradius, Kerberos and Openldap GSSAPI-SASL service principal issue
Hi there,
I'm writing to this mailing list looking for some help in order to configure Freeradius on a Kerberos and OpenLDAP GSSAPI-SASL infrastructure. We have everything working flawlessly. Freeradius service and server is working fine with krb5 and ldap modules enabled. The problem is when we need to start the freeradius service. The service only starts if you manually issue a ticket for the service kerberos principal or the host principal. This is such a strange behavior I can't understand.
Krb5 module: krb5 { keytab = /etc/radius.keytab service_principal = radius/ex.ample.com pool { start = ${thread[pool].start_servers} min = ${thread[pool].min_spare_servers} max = ${thread[pool].max_servers} spare = ${thread[pool].max_spare_servers} uses = 0 lifetime = 0 idle_timeout = 0 } }
The keytab /etc/radius.keytab contains the keys for the service principal radius/ex.ample.com. The service should be able to access to the keytab to asks automatically for a ticket for radius/ex.ample.com. But it doesn't. Instead, the service fails until we issue for a new ticket:
kinit -k -t /etc/radius.keytab radius/ex.ample.com
The ownership of this keytab is radiusd:radiusd and it has reading permissions 440. But I've also tried with 777 with no luck
The reason because it does not understand is that ldap has anon bind disallowed and the freeradius service tries an anonymous bind. I know that according to the rules I should have posted the full output debug log but I'm afraid that since it's a totally isolated environment, I can't extract the whole log. Error: rlm_ldap (ldap): Bind with (anonymous) to ldap://ex.ample.com:389 failed: Local error Error: rlm_ldap (ldap): Opening connection failed (0) Error: rlm_ldap (ldap): Error: /etc/raddb/mods-enabled/ldap [8]: Instantiation failed for module "ldap"
This is how the ldap module SASL section looks:
sasl { mech = 'GSSAPI' realm ='EX.AMPLE.COM' }
The most weird behavior is that If we issue a host ticket (kinit -k) it starts and bind correctly using the host/ex.ample.com service principal. No matter that the service principal configured on krb5 module is radius/ex.ample.com
Any ideas about how to proceed and the reasons why this happens?
We are running the 3.0.15-2.11.2 freeradius version on SuSE12 SP3.
Thank you so much. Kind Regards.
Dario Garcia Díaz-Miguel GGCS-SES Unit GGCS SKMF Infrastructure Division GMV C\ de Isaac Newton, 11 28760, Tres Cantos, Madrid España +34 918 07 21 00 +34 918 07 21 99 http://www.gmv.com
P Please consider the environment before printing this e-mail.
- List info/subscribe/unsubscribe? See https://urldefense.proofpoint.com/v2/url?u=http-3A__www.freeradius.org _list_users.html&d=DwIGaQ&c=CIoxZ4z5BqFvKvSGFOTo726QZIiNTc_M9CmngT-Pla 4&r=s4b0BQg-AwMD3kIEG9JKyw&m=qOZjTOlX3zDW_RGNFqROA4X5acDDHDTwW5mrHOpWd tI&s=NIbJxiw7xy1UQAUL-mjlGcrCNXy6_rjuPgO8wBx7XS8&e=
- List info/subscribe/unsubscribe? See https://urldefense.proofpoint.com/v2/url?u=http-3A__www.freeradius.org_list_... P Please consider the environment before printing this e-mail.
On Sep 18, 2020, at 6:56 AM, Dario García Díaz-Miguel <dgdiaz@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.
participants (3)
-
Alan DeKok -
Dario García Díaz-Miguel -
L.P.H. van Belle