Re: [nssldap] some questions regarding Active Directory <--> NSS Ldap

[Илья Шипицин <chipitsine [at] gmail.com>]

23 февраля 2010 г. 21:49 пользователь Jeffrey Watts
<jeffrey.w.watts@gmail.com> написал:
> You're welcome!  :)
>
> I don't use pam_ldap for authentication.  I use Kerberos, and for my newer
> systems I use the krb5_ccname, SASL, and a cached credential to secure the
> LDAP connection.  For my older systems I use an unprivileged account in AD
> (proxy user) to bind with.

I know LDAP much better than Kerberos, so I'd like to manage with pam_ldap ))

>
> The choice of whether to use LDAP or Kerberos for authentication is a
> complex one.  If you're not familiar with Kerberos but are comfortable with
> certificates, you might want to use LDAP.  Otherwise I'd recommend looking
> at Kerberos.  It's more secure and can be used with other services (SSH for
> example).  Microsoft heavily recommends using Kerberos for authentication
> (as do many others).
>
> In case you're new to the terminology, there are two components to doing
> user access - authentication, which is simply username and password "who are
> you?", and authorization, which typically involves more information and asks
> "what are you allowed to do?".  Kerberos only does authentication, LDAP can
> do both, though is generally considered not as secure in authentication.
> Most folks in a large scale AD setting use either LDAP for both, or Kerberos
> + LDAP.  There are some other options like Samba's winbind, but that has
> certain issues that make me not recommend it for larger deployments.
>
> As far as your bind issues go, I'm not sure I understand what problem you're
> having.  I use the "binddn" and "bindpw" options to specify my generic proxy
> user in /etc/ldap.conf.  That allows nss_ldap to bind to the AD server to
> perform queries.  pam_ldap would then use that connection to do user
> queries.  The nss_base_* variables dictate which containers to look in for
> users/groups.  You can specify more than one.


in multi-site AD there many OUs with users. and when proxy-user reads
AD, it cannot read userPassword attribute (which is possible in case
of OpenLDAP).
there no readable password-field in case of Active Directory, so proxy
user only can "find" where actually certain user  "lives", but after
that there must be second operation: bind with supplied credentials
(yes! we already found the full DN!), also, despite numerous
nss_base_* variables... administrators just add OU as they want to, I
cannot predict that. So, I cannot specify all the OUs.
>
> I do not recommend using pam_ldap without securing the connection.  You can
> use SSL/TLS or SASL/Kerberos.  The latter method may not be supported by
> your OS, for example RHEL3 does not support it, and RHEL4 only supports it
> with a small compile time change to nss_ldap (to recognize the krb5_ccname
> variable).
>
> Other folks, please feel free to correct me on any technical mistakes, while
> I have experience in working with this I'm certainly no expert.
>
> Jeffrey.
>
> 2010/2/23 Илья Шипицин <chipitsine@gmail.com>
>>
>> thank you, that was what I was looking for! I can map all users to
>> uid=1000, gid=1000, thank a lot.
>> also, how do you manage pam-ldap in case of Active Directory ?
>>
>> I used to work with OpenLDAP and figured out two ways pam-ldap work
>>
>> 1) it can bind using "proxy-user", find the required user and compare
>> userPassword field, in such case it doesn't matter where user resides,
>> but userPassword field must be readable by proxy-user
>>
>> 2) it can bind to certain context, say ou=Users,blah-blah-blah using
>> supplied password, in such case userPassword must not be readable, but
>> all users should reside within certain container (OU).
>>
>> neither will work with AD. in case of AD two-step scheme would work:
>>
>> a) bind to AD using some proxy-like user and find where user actually
>> resides
>>
>> b) bind to found user using supplied password
>>
>> is it possible to implement such algorithm using pam-ldap ? in my case
>> users are split across many sites and I cannot move them to single OU.
>>
>