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

[Jeffrey Watts <jeffrey.w.watts [at] 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.

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.

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 [at] 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.