HI!
Is it possible to use SASL/EXTERNAL when connecting to a LDAP server with StartTLS or LDAPS using client certs?
In a project they have certs in all systems anyway (because of using puppet) and I'd like to let the sssd instances on all the systems authenticate to the LDAP server to restrict visibility of LDAP entries by ACL. I'd like to avoid having to set/configure passwords for each system's sssd.
Ciao, Michael.
On Mon, Aug 13, 2012 at 09:36:44PM +0200, Michael Ströder wrote:
HI!
Is it possible to use SASL/EXTERNAL when connecting to a LDAP server with StartTLS or LDAPS using client certs?
In a project they have certs in all systems anyway (because of using puppet) and I'd like to let the sssd instances on all the systems authenticate to the LDAP server to restrict visibility of LDAP entries by ACL. I'd like to avoid having to set/configure passwords for each system's sssd.
Ciao, Michael.
Not currently, there is a ticket that is tracking adding the support: https://fedorahosted.org/sssd/ticket/561
Jakub Hrozek wrote:
On Mon, Aug 13, 2012 at 09:36:44PM +0200, Michael Ströder wrote:
HI!
Is it possible to use SASL/EXTERNAL when connecting to a LDAP server with StartTLS or LDAPS using client certs?
In a project they have certs in all systems anyway (because of using puppet) and I'd like to let the sssd instances on all the systems authenticate to the LDAP server to restrict visibility of LDAP entries by ACL. I'd like to avoid having to set/configure passwords for each system's sssd.
Not currently, there is a ticket that is tracking adding the support: https://fedorahosted.org/sssd/ticket/561
Very sad that this does not make it into 1.9.0. Given the fact that the patch should be really simple.
Ciao, Michael.
On 09/13/2012 05:05 PM, Michael Ströder wrote:
Jakub Hrozek wrote:
On Mon, Aug 13, 2012 at 09:36:44PM +0200, Michael Ströder wrote:
HI!
Is it possible to use SASL/EXTERNAL when connecting to a LDAP server with StartTLS or LDAPS using client certs?
In a project they have certs in all systems anyway (because of using puppet) and I'd like to let the sssd instances on all the systems authenticate to the LDAP server to restrict visibility of LDAP entries by ACL. I'd like to avoid having to set/configure passwords for each system's sssd.
Not currently, there is a ticket that is tracking adding the support: https://fedorahosted.org/sssd/ticket/561
Very sad that this does not make it into 1.9.0. Given the fact that the patch should be really simple.
If you are willing to contribute a patch and we see that it is not drastic we might consider including it in 1.9.x but it all depends on how fast you can do it. We can at least treat it as a tech preview in RHEL.
Ciao, Michael.
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Jakub Hrozek wrote:
On Mon, Aug 13, 2012 at 09:36:44PM +0200, Michael Ströder wrote:
Is it possible to use SASL/EXTERNAL when connecting to a LDAP server with StartTLS or LDAPS using client certs?
In a project they have certs in all systems anyway (because of using puppet) and I'd like to let the sssd instances on all the systems authenticate to the LDAP server to restrict visibility of LDAP entries by ACL. I'd like to avoid having to set/configure passwords for each system's sssd.
Not currently, there is a ticket that is tracking adding the support: https://fedorahosted.org/sssd/ticket/561
Well, the years pass by...
Any chance that this is ever implemented?
Ciao, Michael.
On Wed, Feb 11, 2015 at 06:05:49PM +0100, Michael Ströder wrote:
Jakub Hrozek wrote:
On Mon, Aug 13, 2012 at 09:36:44PM +0200, Michael Ströder wrote:
Is it possible to use SASL/EXTERNAL when connecting to a LDAP server with StartTLS or LDAPS using client certs?
In a project they have certs in all systems anyway (because of using puppet) and I'd like to let the sssd instances on all the systems authenticate to the LDAP server to restrict visibility of LDAP entries by ACL. I'd like to avoid having to set/configure passwords for each system's sssd.
Not currently, there is a ticket that is tracking adding the support: https://fedorahosted.org/sssd/ticket/561
Well, the years pass by...
Any chance that this is ever implemented?
Ciao, Michael.
Patches are very much welcome. This might be a good starting point: https://fedorahosted.org/sssd/wiki/DevelTutorials
On Wed, Feb 11, 2015 at 06:15:47PM +0100, Jakub Hrozek wrote:
On Wed, Feb 11, 2015 at 06:05:49PM +0100, Michael Ströder wrote:
Jakub Hrozek wrote:
On Mon, Aug 13, 2012 at 09:36:44PM +0200, Michael Ströder wrote:
Is it possible to use SASL/EXTERNAL when connecting to a LDAP server with StartTLS or LDAPS using client certs?
In a project they have certs in all systems anyway (because of using puppet) and I'd like to let the sssd instances on all the systems authenticate to the LDAP server to restrict visibility of LDAP entries by ACL. I'd like to avoid having to set/configure passwords for each system's sssd.
Not currently, there is a ticket that is tracking adding the support: https://fedorahosted.org/sssd/ticket/561
Well, the years pass by...
Any chance that this is ever implemented?
Ciao, Michael.
Patches are very much welcome. This might be a good starting point: https://fedorahosted.org/sssd/wiki/DevelTutorials
Sorry, this didn't sound as I intended.
We would very much like to fix all the bugs and RFEs, but we simply only have limited capacity, sorry...the most straightforward way to fix tickets forward is to provide a patch or work with us on the patch..
Jakub Hrozek wrote:
On Wed, Feb 11, 2015 at 06:15:47PM +0100, Jakub Hrozek wrote:
On Wed, Feb 11, 2015 at 06:05:49PM +0100, Michael Ströder wrote:
Jakub Hrozek wrote:
On Mon, Aug 13, 2012 at 09:36:44PM +0200, Michael Ströder wrote:
Is it possible to use SASL/EXTERNAL when connecting to a LDAP server with StartTLS or LDAPS using client certs?
In a project they have certs in all systems anyway (because of using puppet) and I'd like to let the sssd instances on all the systems authenticate to the LDAP server to restrict visibility of LDAP entries by ACL. I'd like to avoid having to set/configure passwords for each system's sssd.
Not currently, there is a ticket that is tracking adding the support: https://fedorahosted.org/sssd/ticket/561
Well, the years pass by...
Any chance that this is ever implemented?
Ciao, Michael.
Patches are very much welcome. This might be a good starting point: https://fedorahosted.org/sssd/wiki/DevelTutorials
Sorry, this didn't sound as I intended.
We would very much like to fix all the bugs and RFEs, but we simply only have limited capacity, sorry...the most straightforward way to fix tickets forward is to provide a patch or work with us on the patch..
Strange enough it seems to work in 1.11+. :-) I did not test it before sending my last message. I had just looked at the ticket status.
Now the question is whether it is an officially supported feature or whether it might disappear later.
Ciao, Michael.
On Sun, Feb 22, 2015 at 06:39:51PM +0100, Michael Ströder wrote:
Jakub Hrozek wrote:
On Wed, Feb 11, 2015 at 06:15:47PM +0100, Jakub Hrozek wrote:
On Wed, Feb 11, 2015 at 06:05:49PM +0100, Michael Ströder wrote:
Jakub Hrozek wrote:
On Mon, Aug 13, 2012 at 09:36:44PM +0200, Michael Ströder wrote:
Is it possible to use SASL/EXTERNAL when connecting to a LDAP server with StartTLS or LDAPS using client certs?
In a project they have certs in all systems anyway (because of using puppet) and I'd like to let the sssd instances on all the systems authenticate to the LDAP server to restrict visibility of LDAP entries by ACL. I'd like to avoid having to set/configure passwords for each system's sssd.
Not currently, there is a ticket that is tracking adding the support: https://fedorahosted.org/sssd/ticket/561
Well, the years pass by...
Any chance that this is ever implemented?
Ciao, Michael.
Patches are very much welcome. This might be a good starting point: https://fedorahosted.org/sssd/wiki/DevelTutorials
Sorry, this didn't sound as I intended.
We would very much like to fix all the bugs and RFEs, but we simply only have limited capacity, sorry...the most straightforward way to fix tickets forward is to provide a patch or work with us on the patch..
Strange enough it seems to work in 1.11+. :-) I did not test it before sending my last message. I had just looked at the ticket status.
Now the question is whether it is an officially supported feature or whether it might disappear later.
Ciao, Michael.
I haven't tested this case at all, I just did a 2-minute git grep through the code, but we still only support GSSAPI as the only SASL mechanism.
Did you check the client actually authenticates (as opposed to running unencrypted or falling back to defaults) ?
Jakub Hrozek wrote:
On Sun, Feb 22, 2015 at 06:39:51PM +0100, Michael Ströder wrote:
Jakub Hrozek wrote:
On Wed, Feb 11, 2015 at 06:15:47PM +0100, Jakub Hrozek wrote:
On Wed, Feb 11, 2015 at 06:05:49PM +0100, Michael Ströder wrote:
Jakub Hrozek wrote:
On Mon, Aug 13, 2012 at 09:36:44PM +0200, Michael Ströder wrote: > Is it possible to use SASL/EXTERNAL when connecting to a LDAP server with > StartTLS or LDAPS using client certs? > > In a project they have certs in all systems anyway (because of using puppet) > and I'd like to let the sssd instances on all the systems authenticate to the > LDAP server to restrict visibility of LDAP entries by ACL. I'd like to avoid > having to set/configure passwords for each system's sssd. > Not currently, there is a ticket that is tracking adding the support: https://fedorahosted.org/sssd/ticket/561
Well, the years pass by...
Any chance that this is ever implemented?
Patches are very much welcome. This might be a good starting point: https://fedorahosted.org/sssd/wiki/DevelTutorials
Sorry, this didn't sound as I intended.
We would very much like to fix all the bugs and RFEs, but we simply only have limited capacity, sorry...the most straightforward way to fix tickets forward is to provide a patch or work with us on the patch..
Strange enough it seems to work in 1.11+. :-) I did not test it before sending my last message. I had just looked at the ticket status.
Now the question is whether it is an officially supported feature or whether it might disappear later.
I haven't tested this case at all, I just did a 2-minute git grep through the code, but we still only support GSSAPI as the only SASL mechanism.
Did you check the client actually authenticates (as opposed to running unencrypted or falling back to defaults) ?
Funny. It really works! (tested again)
With EXTERNAL you don't have to do anything special in your code except not filtering out EXTERNAL being used as SASL mech because libldap will do everything for you.
Ciao, Michael.
On Fri, Mar 06, 2015 at 08:26:29PM +0100, Michael Ströder wrote:
Jakub Hrozek wrote:
On Sun, Feb 22, 2015 at 06:39:51PM +0100, Michael Ströder wrote:
Jakub Hrozek wrote:
On Wed, Feb 11, 2015 at 06:15:47PM +0100, Jakub Hrozek wrote:
On Wed, Feb 11, 2015 at 06:05:49PM +0100, Michael Ströder wrote:
Jakub Hrozek wrote: > On Mon, Aug 13, 2012 at 09:36:44PM +0200, Michael Ströder wrote: >> Is it possible to use SASL/EXTERNAL when connecting to a LDAP server with >> StartTLS or LDAPS using client certs? >> >> In a project they have certs in all systems anyway (because of using puppet) >> and I'd like to let the sssd instances on all the systems authenticate to the >> LDAP server to restrict visibility of LDAP entries by ACL. I'd like to avoid >> having to set/configure passwords for each system's sssd. >> > Not currently, there is a ticket that is tracking adding the support: > https://fedorahosted.org/sssd/ticket/561
Well, the years pass by...
Any chance that this is ever implemented?
Patches are very much welcome. This might be a good starting point: https://fedorahosted.org/sssd/wiki/DevelTutorials
Sorry, this didn't sound as I intended.
We would very much like to fix all the bugs and RFEs, but we simply only have limited capacity, sorry...the most straightforward way to fix tickets forward is to provide a patch or work with us on the patch..
Strange enough it seems to work in 1.11+. :-) I did not test it before sending my last message. I had just looked at the ticket status.
Now the question is whether it is an officially supported feature or whether it might disappear later.
I haven't tested this case at all, I just did a 2-minute git grep through the code, but we still only support GSSAPI as the only SASL mechanism.
Did you check the client actually authenticates (as opposed to running unencrypted or falling back to defaults) ?
Funny. It really works! (tested again)
With EXTERNAL you don't have to do anything special in your code except not filtering out EXTERNAL being used as SASL mech because libldap will do everything for you.
Ciao, Michael.
Can you send me the logs for examination, please? Feel free to sanitize the logs or send them to me (jhrozek -at- redhat -dot- com) directly.
The way I read the logs, only GSSAPI should be supported..so needless to say I'm a bit suprised.
Jakub Hrozek wrote:
On Fri, Mar 06, 2015 at 08:26:29PM +0100, Michael Ströder wrote:
Funny. It really works! (tested again)
With EXTERNAL you don't have to do anything special in your code except not filtering out EXTERNAL being used as SASL mech because libldap will do everything for you.
Can you send me the logs for examination, please?
Do you mean the sssd logs? Which log level would you like to see?
The way I read the logs, only GSSAPI should be supported..so needless to say I'm a bit suprised.
The setup would not work if SASL bind EXTERNAL is not sent by sssd. I can see in the OpenLDAP server's log that the authc-DN (cert subject DN) is correctly rewritten to the accompanying LDAP authz-DN which definitely wouldn't be the case for non-SASL/EXTERNAL bind.
The authz-DN-mapping in OpenLDAP's config:
authz-regexp "cn=([a-zA-Z0-9.-]+),ou=ito,o=stroeder.com,l=karlsruhe,st=ba-wue,c=de" "ldap:///ou=ae-dir??sub?(&(objectClass=aeHost)(host=$1)(aeStatus=0))"
See the sssd.conf attached.
Ciao, Michael.
On Sat, Mar 07, 2015 at 10:59:39AM +0100, Michael Ströder wrote:
Jakub Hrozek wrote:
On Fri, Mar 06, 2015 at 08:26:29PM +0100, Michael Ströder wrote:
Funny. It really works! (tested again)
With EXTERNAL you don't have to do anything special in your code except not filtering out EXTERNAL being used as SASL mech because libldap will do everything for you.
Can you send me the logs for examination, please?
Do you mean the sssd logs? Which log level would you like to see?
The way I read the logs, only GSSAPI should be supported..so needless to say I'm a bit suprised.
The setup would not work if SASL bind EXTERNAL is not sent by sssd. I can see in the OpenLDAP server's log that the authc-DN (cert subject DN) is correctly rewritten to the accompanying LDAP authz-DN which definitely wouldn't be the case for non-SASL/EXTERNAL bind.
The authz-DN-mapping in OpenLDAP's config:
authz-regexp "cn=([a-zA-Z0-9.-]+),ou=ito,o=stroeder.com,l=karlsruhe,st=ba-wue,c=de" "ldap:///ou=ae-dir??sub?(&(objectClass=aeHost)(host=$1)(aeStatus=0))"
See the sssd.conf attached.
Thank you.
Yes, can you also send me the sssd domain logs?
I re-read the logs again and you're right we don't seem to error out on on anything else than GSSAPI (which is what I thought previously). Nonetheless, it would be great to see the domain logs.
On Sun, Mar 15, 2015 at 08:53:40PM +0100, Michael Ströder wrote:
Jakub Hrozek wrote:
I re-read the logs again and you're right we don't seem to error out on on anything else than GSSAPI (which is what I thought previously). Nonetheless, it would be great to see the domain logs.
Which log level is that?
I would like to hit this line: 923 924 DEBUG(SSSDBG_CONF_SETTINGS, "Executing sasl bind mech: %s, user: %s\n", 925 sasl_mech, sasl_user);
CONF_SETTINGS is debug_level 4, but for the tracing info, 6 or 7 would be even better. Feel free to sanitize any confidential info.
Jakub Hrozek wrote:
On Sun, Mar 15, 2015 at 08:53:40PM +0100, Michael Ströder wrote:
Jakub Hrozek wrote:
I re-read the logs again and you're right we don't seem to error out on on anything else than GSSAPI (which is what I thought previously). Nonetheless, it would be great to see the domain logs.
Which log level is that?
I would like to hit this line: 923 924 DEBUG(SSSDBG_CONF_SETTINGS, "Executing sasl bind mech: %s, user: %s\n", 925 sasl_mech, sasl_user);
Ok, here it comes. Solely test stuff => no confidential data in there.
Subject DN of client cert is: cn=ae-client1.example.org,ou=ito,o=stroeder.com,l=karlsruhe,st=ba-wue,c=de
LDAP DN of sssd client is: host=ae-client1.example.org,cn=example-srvgrp-1,cn=example,ou=ae-dir
You can see in the log excerpt below how OpenLDAP's slapd maps it (see lines with "BIND authcid" and "BIND dn=").
BTW: I consider it to be a bug that sssd tries to read the rootDSE before binding.
In the sssd domain log you can find:
(Mon Mar 16 10:24:26 2015) [sssd[be[AE-DIR]]] [sasl_bind_send] (0x0100): Executing sasl bind mech: EXTERNAL, user: (null)
Find sssd.conf, client cert and /var/log/sssd/ in the attached tar.xz.
Ciao, Michael.
---------------------------- slapd's log -------------------------------
5506a14d conn=1000 fd=13 ACCEPT from IP=172.16.15.137:51064 (IP=0.0.0.0:2342) 5506a14d conn=1000 op=0 EXT oid=1.3.6.1.4.1.1466.20037 5506a14d conn=1000 op=0 STARTTLS 5506a14d conn=1000 op=0 RESULT oid= err=0 text= 5506a14d conn=1000 fd=13 TLS established tls_ssf=256 ssf=256 5506a14d conn=1000 op=1 SRCH base="" scope=0 deref=0 filter="(objectClass=*)" 5506a14d conn=1000 op=1 SRCH attr=* altServer namingContexts supportedControl supportedExtension supportedFeatures supportedLDAPVersion supportedSASLMechanisms domainControllerFunctionality defaultNamingContext lastUSN highestCommittedUSN 5506a14d conn=1000 op=1 SEARCH RESULT tag=101 err=8 nentries=0 text=strong(er) authentication required 5506a14d conn=1000 op=2 BIND dn="" method=163 5506a14d <= mdb_equality_candidates: (aeStatus) not indexed 5506a14d conn=1000 op=2 BIND authcid="cn=ae-client1.example.org,ou=ito,o=stroeder.com,l=karlsruhe,st=ba-wue,c=de" authzid="cn=ae-client1.example.org,ou=ito,o=stroeder.com,l=karlsruhe,st=ba-wue,c=de" 5506a14d conn=1000 op=2 BIND dn="host=ae-client1.example.org,cn=example-srvgrp-1,cn=example,ou=ae-dir" mech=EXTERNAL sasl_ssf=0 ssf=256 5506a14d conn=1000 op=2 RESULT tag=97 err=0 text= 5506a14d conn=1000 op=3 SRCH base="" scope=0 deref=0 filter="(objectClass=*)" 5506a14d conn=1000 op=3 SRCH attr=* altServer namingContexts supportedControl supportedExtension supportedFeatures supportedLDAPVersion supportedSASLMechanisms domainControllerFunctionality defaultNamingContext lastUSN highestCommittedUSN 5506a14d conn=1000 op=3 ENTRY dn="" 5506a14d conn=1000 op=3 SEARCH RESULT tag=101 err=0 nentries=1 text= 5506a14d conn=1000 op=4 SRCH base="ou=ae-dir" scope=2 deref=0 filter="(&(objectClass=posixAccount)(uid=*)(uidNumber=*)(gidNumber=*))" 5506a14d conn=1000 op=4 SRCH attr=objectClass uid userPassword uidNumber gidNumber gecos homeDirectory loginShell krbPrincipalName cn memberOf modifyTimestamp modifyTimestamp shadowLastChange shadowMin shadowMax shadowWarning shadowInactive shadowExpire shadowFlag krbLastPwdChange krbPasswordExpiration pwdAttribute authorizedService accountExpires userAccountControl nsAccountLock host loginDisabled loginExpirationTime loginAllowedTimeMap sshPublicKey 5506a14d conn=1000 op=5 SRCH base="ou=ae-dir" scope=2 deref=0 filter="(&(objectClass=sudoRole)(|(!(sudoHost=*))(sudoHost=ALL)(sudoHost=ae-client1)(sudoHost=ae-client1.example.com)(sudoHost=172.16.15.137)(sudoHost=172.16.15.0/24)(sudoHost=fe80::20c:29ff:fe02:711c)(sudoHost=fe80::/64)(?sudoHost=+*)(|(?sudoHost=*\5C*)(?sudoHost=*?*)(?sudoHost=*\2A*)(?sudoHost=*[*]*))))" 5506a14d conn=1000 op=5 SRCH attr=objectClass cn sudoCommand sudoHost sudoUser sudoOption sudoRunAs sudoRunAsUser sudoRunAsGroup sudoNotBefore sudoNotAfter sudoOrder modifyTimestamp
On Mon, 2015-03-16 at 10:33 +0100, Michael Ströder wrote:
BTW: I consider it to be a bug that sssd tries to read the rootDSE before binding.
[off-topic]
Why do you consider this a bug? The RootDSE contains information to allow SSSD to learn what mechanisms it's allowed to use when binding. That's one of its primary purposes.
That said, if we can't reach it, we just guess, connect and then reread the rootDSE after binding.
Stephen Gallagher wrote:
On Mon, 2015-03-16 at 10:33 +0100, Michael Ströder wrote:
BTW: I consider it to be a bug that sssd tries to read the rootDSE before binding.
Why do you consider this a bug? The RootDSE contains information to allow SSSD to learn what mechanisms it's allowed to use when binding. That's one of its primary purposes.
That said, if we can't reach it, we just guess, connect and then reread the rootDSE after binding.
Ouch! A client MUST NOT assume that anything security relevant is really true when reading the rootDSE. The client has to obey its configuration. Period.
Ciao, Michael.
On 16 Mar 2015, at 21:06, Michael Ströder michael@stroeder.com wrote:
Stephen Gallagher wrote:
On Mon, 2015-03-16 at 10:33 +0100, Michael Ströder wrote:
BTW: I consider it to be a bug that sssd tries to read the rootDSE before binding.
Why do you consider this a bug? The RootDSE contains information to allow SSSD to learn what mechanisms it's allowed to use when binding. That's one of its primary purposes.
That said, if we can't reach it, we just guess, connect and then reread the rootDSE after binding.
Ouch! A client MUST NOT assume that anything security relevant is really true when reading the rootDSE. The client has to obey its configuration. Period.
Sorry, but can you elaborate effect does the sssd's mechanism of trying anonymous first and retrying with anonymous have? I still don't see why you consider this a bug..
Ciao, Michael.
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Jakub Hrozek wrote:
On 16 Mar 2015, at 21:06, Michael Ströder michael@stroeder.com wrote:
Stephen Gallagher wrote:
On Mon, 2015-03-16 at 10:33 +0100, Michael Ströder wrote:
BTW: I consider it to be a bug that sssd tries to read the rootDSE before binding.
Why do you consider this a bug? The RootDSE contains information to allow SSSD to learn what mechanisms it's allowed to use when binding. That's one of its primary purposes.
That said, if we can't reach it, we just guess, connect and then reread the rootDSE after binding.
Ouch! A client MUST NOT assume that anything security relevant is really true when reading the rootDSE. The client has to obey its configuration. Period.
Sorry, but can you elaborate effect does the sssd's mechanism of trying anonymous first and retrying with anonymous have? I still don't see why you consider this a bug..
I consider this a bug because in my setups anon searches does not reveal anything at all.
Also if a client chooses StartTLS policy or SASL authc mechs based on rootDSE information that's clearly a violation of best practices because of possible down-grade attacks. The client's configuration is the only trustworthy source.
Some hints herein: http://tools.ietf.org/html/rfc4513#section-6
For SASL: http://tools.ietf.org/html/rfc4513#section-6.4
Unfortunately this is pretty blurry and I'm pretty sure today this would have been written differently: http://tools.ietf.org/html/rfc4513#section-5.2.1.5
One could argue that if TLS is already established there is an integrity protection.
But frankly I don't consider rootDSE to be really trustworthy even if no evil attacker is part of the game.
Ciao, Michael.
On Mon, 2015-03-16 at 22:58 +0100, Michael Ströder wrote:
Jakub Hrozek wrote:
On 16 Mar 2015, at 21:06, Michael Ströder michael@stroeder.com wrote:
Stephen Gallagher wrote:
On Mon, 2015-03-16 at 10:33 +0100, Michael Ströder wrote:
BTW: I consider it to be a bug that sssd tries to read the rootDSE before binding.
Why do you consider this a bug? The RootDSE contains information to allow SSSD to learn what mechanisms it's allowed to use when binding. That's one of its primary purposes.
That said, if we can't reach it, we just guess, connect and then reread the rootDSE after binding.
Ouch! A client MUST NOT assume that anything security relevant is really true when reading the rootDSE. The client has to obey its configuration. Period.
Sorry, but can you elaborate effect does the sssd's mechanism of trying anonymous first and retrying with anonymous have? I still don't see why you consider this a bug..
I consider this a bug because in my setups anon searches does not reveal anything at all.
That is fine.
Also if a client chooses StartTLS policy or SASL authc mechs based on rootDSE information that's clearly a violation of best practices because of possible down-grade attacks. The client's configuration is the only trustworthy source.
We do not downgrade, if the mechanism configured in SSSD is not available, at most we fail to proceed.
Some hints herein: http://tools.ietf.org/html/rfc4513#section-6
For SASL: http://tools.ietf.org/html/rfc4513#section-6.4
Unfortunately this is pretty blurry and I'm pretty sure today this would have been written differently: http://tools.ietf.org/html/rfc4513#section-5.2.1.5
One could argue that if TLS is already established there is an integrity protection.
TLS insures integrity and confidentiality, that's part of what TLS provides, no need to argue.
But frankly I don't consider rootDSE to be really trustworthy even if no evil attacker is part of the game.
rootDSE is authoritative, if you do not trust it you do not trust your LDAP server at all.
Simo.
Simo Sorce wrote:
On Mon, 2015-03-16 at 22:58 +0100, Michael Ströder wrote:
Also if a client chooses StartTLS policy or SASL authc mechs based on rootDSE information that's clearly a violation of best practices because of possible down-grade attacks. The client's configuration is the only trustworthy source.
We do not downgrade, if the mechanism configured in SSSD is not available, at most we fail to proceed.
Then you don't need rootDSE information at all. Why read it then?
Best you can do with it is writing some informative log message. But likely this will cause more confusion than anything else.
But frankly I don't consider rootDSE to be really trustworthy even if no evil attacker is part of the game.
rootDSE is authoritative, if you do not trust it you do not trust your LDAP server at all.
Well, LDAP server implementations have different semantics when to put something into supported* attributes or not. In my experience you cannot rely on it for feature discovery when implementing LDAP clients supposed to be interoperable with all LDAP servers out there - BTDT [1].
Ciao, Michael.
On Mon, 2015-03-16 at 21:06 +0100, Michael Ströder wrote:
Stephen Gallagher wrote:
On Mon, 2015-03-16 at 10:33 +0100, Michael Ströder wrote:
BTW: I consider it to be a bug that sssd tries to read the rootDSE before binding.
Why do you consider this a bug? The RootDSE contains information to allow SSSD to learn what mechanisms it's allowed to use when binding. That's one of its primary purposes.
That said, if we can't reach it, we just guess, connect and then reread the rootDSE after binding.
Ouch! A client MUST NOT assume that anything security relevant is really true when reading the rootDSE. The client has to obey its configuration. Period.
Can you explain what is your worry here ?
Simo.
sssd-users@lists.fedorahosted.org
-
Dmitri Pal -
Jakub Hrozek -
Michael Ströder -
Simo Sorce -
Stephen Gallagher