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(a)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.
> 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
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
Unfortunately this is pretty blurry and I'm pretty sure today this would have
been written differently:
One could argue that if TLS is already established there is an integrity
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 Sorce * Red Hat, Inc * New York