i am in the process of updating all of my systems to fedora 20 from fedora 16, and am using all the latest available builds for openldap, cyrus-sasl and mit kerberos. i have put everything together as i had on fedora 16, and i am finding that the sasl instance is using sasl/gss-spnego, and not sasl/gssapi like it did on the older version.
i am not sure if i should be concerned about this, but it feels like i should be. i am not able to find anything that allow me to configure things one way or another, so i can force the use of gssapi from configs, it seems.
can anyone point me in a direction about this, tell me if i should be concerned, or if you might have come across this before what i should be doing that i am not?
thank you,
brendan
On 12/26/14 12:10 -0500, Brendan Kearney wrote:
i am in the process of updating all of my systems to fedora 20 from fedora 16, and am using all the latest available builds for openldap, cyrus-sasl and mit kerberos. i have put everything together as i had on fedora 16, and i am finding that the sasl instance is using sasl/gss-spnego, and not sasl/gssapi like it did on the older version.
i am not sure if i should be concerned about this, but it feels like i should be. i am not able to find anything that allow me to configure things one way or another, so i can force the use of gssapi from configs, it seems.
can anyone point me in a direction about this, tell me if i should be concerned, or if you might have come across this before what i should be doing that i am not?
To limit the use of specific sasl mechanisms, configure a libsasl slapd.conf file which contains a 'mech_list' option explicitly listing the mechanisms (space separated) you wish to offer.
Consult the fedora documentation for both slapd and libsasl2 for the location to place the slapd.conf file in.
To obtain a list of advertised mechanisms, do:
ldapsearch -LLL -x -H ldap://ldap.example.org -s "base" -b "" supportedSASLMechanisms
You should also force your clients to use gssapi explicitly if that's your preferred mechanism. The OpenLDAP client utilities offer a '-Y' option for to do that.
On Fri, 2014-12-26 at 14:53 -0600, Dan White wrote:
On 12/26/14 12:10 -0500, Brendan Kearney wrote:
i am in the process of updating all of my systems to fedora 20 from fedora 16, and am using all the latest available builds for openldap, cyrus-sasl and mit kerberos. i have put everything together as i had on fedora 16, and i am finding that the sasl instance is using sasl/gss-spnego, and not sasl/gssapi like it did on the older version.
i am not sure if i should be concerned about this, but it feels like i should be. i am not able to find anything that allow me to configure things one way or another, so i can force the use of gssapi from configs, it seems.
can anyone point me in a direction about this, tell me if i should be concerned, or if you might have come across this before what i should be doing that i am not?
To limit the use of specific sasl mechanisms, configure a libsasl slapd.conf file which contains a 'mech_list' option explicitly listing the mechanisms (space separated) you wish to offer.
Consult the fedora documentation for both slapd and libsasl2 for the location to place the slapd.conf file in.
To obtain a list of advertised mechanisms, do:
ldapsearch -LLL -x -H ldap://ldap.example.org -s "base" -b "" supportedSASLMechanisms
You should also force your clients to use gssapi explicitly if that's your preferred mechanism. The OpenLDAP client utilities offer a '-Y' option for to do that.
kudos and thanks to mr. white. /etc/sasl2/slapd.conf containing "mech_list: gssapi" did the trick.
having put this in brought to mind something i will be looking to do in the near future, and i am now wondering if i am limiting myself in that effort.
i want to use the "pass-through" auth mechanism with sasl, so that i validate credentials against the kerberos database, and not have to maintain passwords in multiple places. right now, saslauthd is configured and if i test with my id, i get OK/Success back.
it seems i need to add PLAIN to the "mech_list" along with maybe a couple other directives for this to be enabled. i have olcSaslSecProps set to "noanonymous,noplain", so i am assuming i will need to remove the "noplain".
being that this weakens a security posture (at least it looks to do so), what can be done to mitigate the risk. i would imagine tls is one step, but would any other steps be necessary? acls can help, too, but the plain bind/auth would have already occurred.
Brendan Kearney wrote:
On Fri, 2014-12-26 at 14:53 -0600, Dan White wrote:
On 12/26/14 12:10 -0500, Brendan Kearney wrote:
i am in the process of updating all of my systems to fedora 20 from fedora 16, and am using all the latest available builds for openldap, cyrus-sasl and mit kerberos. i have put everything together as i had on fedora 16, and i am finding that the sasl instance is using sasl/gss-spnego, and not sasl/gssapi like it did on the older version.
i am not sure if i should be concerned about this, but it feels like i should be. i am not able to find anything that allow me to configure things one way or another, so i can force the use of gssapi from configs, it seems.
can anyone point me in a direction about this, tell me if i should be concerned, or if you might have come across this before what i should be doing that i am not?
To limit the use of specific sasl mechanisms, configure a libsasl slapd.conf file which contains a 'mech_list' option explicitly listing the mechanisms (space separated) you wish to offer.
Consult the fedora documentation for both slapd and libsasl2 for the location to place the slapd.conf file in.
To obtain a list of advertised mechanisms, do:
ldapsearch -LLL -x -H ldap://ldap.example.org -s "base" -b "" supportedSASLMechanisms
You should also force your clients to use gssapi explicitly if that's your preferred mechanism. The OpenLDAP client utilities offer a '-Y' option for to do that.
kudos and thanks to mr. white. /etc/sasl2/slapd.conf containing "mech_list: gssapi" did the trick.
having put this in brought to mind something i will be looking to do in the near future, and i am now wondering if i am limiting myself in that effort.
i want to use the "pass-through" auth mechanism with sasl, so that i validate credentials against the kerberos database, and not have to maintain passwords in multiple places.
The right way to do this is to store your KDC keystore in slapd.
right now, saslauthd is configured and if i test with my id, i get OK/Success back.
it seems i need to add PLAIN to the "mech_list" along with maybe a couple other directives for this to be enabled. i have olcSaslSecProps set to "noanonymous,noplain", so i am assuming i will need to remove the "noplain".
No.
If you're already using SASL/GSSAPI then there's no need to do anything else. If you're talking about clients performing plaintext authentication, then what you just described is irrelevant. "sasl pass-through" uses LDAP Simple Bind and the {SASL} crypt scheme. The SASL PLAIN mech is only used for LDAP SASL Binds, and is totally irrelevant here. If your client can perform SASL Binds already then it would have used GSSAPI in the first place.
being that this weakens a security posture (at least it looks to do so), what can be done to mitigate the risk. i would imagine tls is one step, but would any other steps be necessary? acls can help, too, but the plain bind/auth would have already occurred.
There is no valid use for SASL/PLAIN in LDAP. There is almost never any valid reason to change the olcSaslSecProps config.
In the meantime, yes, if you allow LDAP Simple Binds to be authenticated against Kerberos credentials, then you will need TLS otherwise your Kerberos credentials will be easily compromised.
On Sun, 2014-12-28 at 02:50 +0000, Howard Chu wrote:
Brendan Kearney wrote:
On Fri, 2014-12-26 at 14:53 -0600, Dan White wrote:
On 12/26/14 12:10 -0500, Brendan Kearney wrote:
i am in the process of updating all of my systems to fedora 20 from fedora 16, and am using all the latest available builds for openldap, cyrus-sasl and mit kerberos. i have put everything together as i had on fedora 16, and i am finding that the sasl instance is using sasl/gss-spnego, and not sasl/gssapi like it did on the older version.
i am not sure if i should be concerned about this, but it feels like i should be. i am not able to find anything that allow me to configure things one way or another, so i can force the use of gssapi from configs, it seems.
can anyone point me in a direction about this, tell me if i should be concerned, or if you might have come across this before what i should be doing that i am not?
To limit the use of specific sasl mechanisms, configure a libsasl slapd.conf file which contains a 'mech_list' option explicitly listing the mechanisms (space separated) you wish to offer.
Consult the fedora documentation for both slapd and libsasl2 for the location to place the slapd.conf file in.
To obtain a list of advertised mechanisms, do:
ldapsearch -LLL -x -H ldap://ldap.example.org -s "base" -b "" supportedSASLMechanisms
You should also force your clients to use gssapi explicitly if that's your preferred mechanism. The OpenLDAP client utilities offer a '-Y' option for to do that.
kudos and thanks to mr. white. /etc/sasl2/slapd.conf containing "mech_list: gssapi" did the trick.
having put this in brought to mind something i will be looking to do in the near future, and i am now wondering if i am limiting myself in that effort.
i want to use the "pass-through" auth mechanism with sasl, so that i validate credentials against the kerberos database, and not have to maintain passwords in multiple places.
The right way to do this is to store your KDC keystore in slapd.
i am doing this. the benefits i saw were real-time replication in conjunction with my MMR, as well as multi-master kadmin that allows multiple/concurrent write sessions.
right now, saslauthd is configured and if i test with my id, i get OK/Success back.
it seems i need to add PLAIN to the "mech_list" along with maybe a couple other directives for this to be enabled. i have olcSaslSecProps set to "noanonymous,noplain", so i am assuming i will need to remove the "noplain".
No.
If you're already using SASL/GSSAPI then there's no need to do anything else. If you're talking about clients performing plaintext authentication, then what you just described is irrelevant. "sasl pass-through" uses LDAP Simple Bind and the {SASL} crypt scheme. The SASL PLAIN mech is only used for LDAP SASL Binds, and is totally irrelevant here. If your client can perform SASL Binds already then it would have used GSSAPI in the first place.
being that this weakens a security posture (at least it looks to do so), what can be done to mitigate the risk. i would imagine tls is one step, but would any other steps be necessary? acls can help, too, but the plain bind/auth would have already occurred.
There is no valid use for SASL/PLAIN in LDAP. There is almost never any valid reason to change the olcSaslSecProps config.
In the meantime, yes, if you allow LDAP Simple Binds to be authenticated against Kerberos credentials, then you will need TLS otherwise your Kerberos credentials will be easily compromised.
ok, then i have misunderstood PLAIN vs SIMPLE, it seems. i will back up and explain what i am trying to do.
apache, dhcp and freeradius can all use ldap for various functionality. they all use what i now believe to be SIMPLE auth, where they are using "cn=user,dc=domain,dc=tld" as ldap usernames. these processes are using ldap for authentication, whereas i have only kerberos authentication setup in my environment (and ldap authorization). my hope was that sasl could allow me to push the ldap authN request through to kerberos, and in essence proxy the authentication.
the idea is to not have passwords stored in ldap, but have them stored in kerberos (even though the kerberos data is housed in ldap). am i trying to use a screwdriver, where a wrench is needed?
thank you,
brendan
On 12/28/14 11:24 -0500, Brendan Kearney wrote:
On Sun, 2014-12-28 at 02:50 +0000, Howard Chu wrote:
Brendan Kearney wrote:
i want to use the "pass-through" auth mechanism with sasl, so that i validate credentials against the kerberos database, and not have to maintain passwords in multiple places.
ok, then i have misunderstood PLAIN vs SIMPLE, it seems. i will back up and explain what i am trying to do.
apache, dhcp and freeradius can all use ldap for various functionality. they all use what i now believe to be SIMPLE auth, where they are using "cn=user,dc=domain,dc=tld" as ldap usernames. these processes are using ldap for authentication, whereas i have only kerberos authentication setup in my environment (and ldap authorization). my hope was that sasl could allow me to push the ldap authN request through to kerberos, and in essence proxy the authentication.
This is a valid use of pass-through in my opinion, but you'll want to protect the authentication as Howard mentioned over ldapi:/// ideally, or tls otherwise.
pass-through does not require that you advertise any other sasl mechanisms, such as plain, since it does not involve sasl over the wire. To use, see:
http://www.openldap.org/doc/admin24/security.html#Pass-Through%20authenticat...
Add 'pwcheck_method: saslauthd' to your libsasl slapd.conf file, and should need nothing else unless you're using a non standard location for your saslauthd mux.
Verify that your slapd user has permissions to access the saslauthd mux, and verify your saslauthd config with testsaslauthd.
On Mon, 2014-12-29 at 10:49 -0600, Dan White wrote:
On 12/28/14 11:24 -0500, Brendan Kearney wrote:
On Sun, 2014-12-28 at 02:50 +0000, Howard Chu wrote:
Brendan Kearney wrote:
i want to use the "pass-through" auth mechanism with sasl, so that i validate credentials against the kerberos database, and not have to maintain passwords in multiple places.
ok, then i have misunderstood PLAIN vs SIMPLE, it seems. i will back up and explain what i am trying to do.
apache, dhcp and freeradius can all use ldap for various functionality. they all use what i now believe to be SIMPLE auth, where they are using "cn=user,dc=domain,dc=tld" as ldap usernames. these processes are using ldap for authentication, whereas i have only kerberos authentication setup in my environment (and ldap authorization). my hope was that sasl could allow me to push the ldap authN request through to kerberos, and in essence proxy the authentication.
This is a valid use of pass-through in my opinion, but you'll want to protect the authentication as Howard mentioned over ldapi:/// ideally, or tls otherwise.
pass-through does not require that you advertise any other sasl mechanisms, such as plain, since it does not involve sasl over the wire. To use, see:
http://www.openldap.org/doc/admin24/security.html#Pass-Through%20authenticat...
Add 'pwcheck_method: saslauthd' to your libsasl slapd.conf file, and should need nothing else unless you're using a non standard location for your saslauthd mux.
Verify that your slapd user has permissions to access the saslauthd mux, and verify your saslauthd config with testsaslauthd.
i had the pwcheck_method directive in there, along with the path to one of two saslauthd mux's. /var/run/saslauthd/mux and /run/saslauthd/mux, which both show up as "srwxrwxrwx" and are owned by root:root. testing using testsaslauthd works with my id, but i am not sure how to have authentication work when the other process is binding with "cn=user,dc=domain,dc=tld" and not a username.
On 12/30/14 10:32 -0500, Brendan Kearney wrote:
On Mon, 2014-12-29 at 10:49 -0600, Dan White wrote:
http://www.openldap.org/doc/admin24/security.html#Pass-Through%20authenticat...
Add 'pwcheck_method: saslauthd' to your libsasl slapd.conf file, and should need nothing else unless you're using a non standard location for your saslauthd mux.
Verify that your slapd user has permissions to access the saslauthd mux, and verify your saslauthd config with testsaslauthd.
i had the pwcheck_method directive in there, along with the path to one of two saslauthd mux's. /var/run/saslauthd/mux and /run/saslauthd/mux, which both show up as "srwxrwxrwx" and are owned by root:root. testing
Typically for the saslauthd mux, it's the parents' directory permissions that restrict access.
using testsaslauthd works with my id, but i am not sure how to have authentication work when the other process is binding with "cn=user,dc=domain,dc=tld" and not a username.
dn: cn=user,dc=domain,dc=tld userPassword: {SASL}username@realm
On Tue, 2014-12-30 at 09:37 -0600, Dan White wrote:
On 12/30/14 10:32 -0500, Brendan Kearney wrote:
On Mon, 2014-12-29 at 10:49 -0600, Dan White wrote:
http://www.openldap.org/doc/admin24/security.html#Pass-Through%20authenticat...
Add 'pwcheck_method: saslauthd' to your libsasl slapd.conf file, and should need nothing else unless you're using a non standard location for your saslauthd mux.
Verify that your slapd user has permissions to access the saslauthd mux, and verify your saslauthd config with testsaslauthd.
i had the pwcheck_method directive in there, along with the path to one of two saslauthd mux's. /var/run/saslauthd/mux and /run/saslauthd/mux, which both show up as "srwxrwxrwx" and are owned by root:root. testing
Typically for the saslauthd mux, it's the parents' directory permissions that restrict access.
using testsaslauthd works with my id, but i am not sure how to have authentication work when the other process is binding with "cn=user,dc=domain,dc=tld" and not a username.
dn: cn=user,dc=domain,dc=tld userPassword: {SASL}username@realm
/run: drwxr-xr-x 2 root root 100 Dec 30 10:26 saslauthd
/var/run: lrwxrwxrwx. 1 root root 6 Dec 10 21:46 /var/run -> ../run
so the ldap user would have read and execute permissions. should i change anything?
i do have a user for dhcpd setup in that way (dn: uid=dhcpd,dc=bpk2,dc=com and userPassword: {SASL}dhcpd@BPK2.COM). the kerberos object does exist as well.
On 12/30/14 11:09 -0500, Brendan Kearney wrote:
/run: drwxr-xr-x 2 root root 100 Dec 30 10:26 saslauthd
/var/run: lrwxrwxrwx. 1 root root 6 Dec 10 21:46 /var/run -> ../run
so the ldap user would have read and execute permissions. should i change anything?
No.
i do have a user for dhcpd setup in that way (dn: uid=dhcpd,dc=bpk2,dc=com and userPassword: {SASL}dhcpd@BPK2.COM). the kerberos object does exist as well.
What testsaslauthd command are you running? Are you currently using the '-r' option when starting saslauthd? Try running saslauthd in debug mode and compare output. If you're not seeing any output when authenticating against slapd, verify your configured saslauthd_path in slapd.conf. It should include the '/mux' in the path, e.g. '/var/run/saslauthd/mux'.
Dan White wrote:
On 12/28/14 11:24 -0500, Brendan Kearney wrote:
On Sun, 2014-12-28 at 02:50 +0000, Howard Chu wrote:
Brendan Kearney wrote:
i want to use the "pass-through" auth mechanism with sasl, so that i validate credentials against the kerberos database, and not have to maintain passwords in multiple places.
ok, then i have misunderstood PLAIN vs SIMPLE, it seems. i will back up and explain what i am trying to do.
apache, dhcp and freeradius can all use ldap for various functionality. they all use what i now believe to be SIMPLE auth, where they are using "cn=user,dc=domain,dc=tld" as ldap usernames. these processes are using ldap for authentication, whereas i have only kerberos authentication setup in my environment (and ldap authorization). my hope was that sasl could allow me to push the ldap authN request through to kerberos, and in essence proxy the authentication.
This is a valid use of pass-through in my opinion,
Too many moving parts, and all unnecessary. He already has his KDC data stored in LDAP, he should just use {K5KEY} password scheme and be done with it.
You're just making extra work.
but you'll want to protect the authentication as Howard mentioned over ldapi:/// ideally, or tls otherwise.
Howard Chu wrote:
Dan White wrote:
On 12/28/14 11:24 -0500, Brendan Kearney wrote:
On Sun, 2014-12-28 at 02:50 +0000, Howard Chu wrote:
Brendan Kearney wrote:
i want to use the "pass-through" auth mechanism with sasl, so that i validate credentials against the kerberos database, and not have to maintain passwords in multiple places.
ok, then i have misunderstood PLAIN vs SIMPLE, it seems. i will back up and explain what i am trying to do.
apache, dhcp and freeradius can all use ldap for various functionality. they all use what i now believe to be SIMPLE auth, where they are using "cn=user,dc=domain,dc=tld" as ldap usernames. these processes are using ldap for authentication, whereas i have only kerberos authentication setup in my environment (and ldap authorization). my hope was that sasl could allow me to push the ldap authN request through to kerberos, and in essence proxy the authentication.
This is a valid use of pass-through in my opinion,
Too many moving parts, and all unnecessary.
I agree here but..
He already has his KDC data stored in LDAP, he should just use {K5KEY} password scheme and be done with it.
..AFAIK this requires using slapo-smbk5pwd which only works with heimdal's libs and KDC schema.
I guess Fedora does not ship OpenLDAP builds with slapo-smbk5pwd and it definitely uses MIT Kerberos.
Ciao, Michael.
openldap-technical@openldap.org
-
Brendan Kearney -
Dan White -
Howard Chu -
Michael Ströder