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