On 10/25/2012 06:59 PM, Dmitri Pal wrote:
On 10/25/2012 06:38 PM, Paul B. Henson wrote:
On 10/25/2012 9:41 AM, Dmitri Pal wrote:
BTW SSSD connects in an authenticated way.
I assume you mean it supports connecting with authentication; considering I have provided it no credentials I would be surprised and disconcerted if it was doing anything other than an anonymous bind in my current deployment :).
This is strange. By default SSSD prefers strong authentication methods like GSSAPI and you really need to twist its arms to go with anonymous bind. It might not be the default for the LDAP provider (provider is SSSD component that actually talks to DS) though... only for the advanced providers like IPA and AD.
I just wanted to clarify this, because I think Dmitri is confused about the situation. There is NO requirement for authentication or encryption to perform LDAP id_provider lookups. By default we will use an unencrypted simple bind, because that will work in most cases.
We support using an authenticated connection (and indeed this is the default in the AD and IPA providers), but it is not required unless the LDAP server to which you are connecting has disabled or limited anonymous access. In this situation, you can use simple bind authentication to a known bind DN with a password or you can use a GSSAPI SASL bind to connect to the LDAP server.
This is in contrast to when the SSSD is using LDAP as an *authentication* provider. In this situation, we mandate that the LDAP connection be protected by encryption (one of LDAPS, LDAP+TLS or LDAP+GSSAPI) before we will allow it to perform a simple-bind auth for a user. This is done because the LDAP protocol will transport the simple-bind password in plaintext over the network, thereby making it very easy to snoop passwords. pam_ldap allowed this behavior but SSSD has forbidden it and will simply refuse to even attempt the authentication if the communication channel is not encrypted.
Obviously, if you are using Kerberos or another auth provider, the above is academic.