RSS feed

Re: Newbie questions: knowledge of login procedure in general and configuration of nss-pam-ldapd for Acive Directory

[Date Prev][Date Next] [Thread Prev][Thread Next]

Re: Newbie questions: knowledge of login procedure in general and configuration of nss-pam-ldapd for Acive Directory

Thank you, Arthur, for your explanations.

I'm using version 0.7.2 as this is the version which comes with Ubuntu 10.04 by default. A freshly installed Debian 6 Squeeze stable which comes with v0.7.13 shows the same behavior as described. So I think the problems I have are all related to the adverse attitude of my Active Directory admins. But I'm going to try out both v0.8.4 which seems to be in Debian's testing branch and Samba's winbindd solution.



Am 15.09.2011, 22:31 Uhr, schrieb Arthur de Jong <>:

On Wed, 2011-09-14 at 23:15 +0200, Uwe Sauter wrote:
I have no clue how this is with LDAP. Why do you need both a PAM and a
NSS module?  Wouldn't it suffice if NSS would communicate with an LDAP
server if configured in nsswitch.conf?

With LDAP everything in the flat files (/etc/passwd, /etc/shadow,
/etc/group) except the actual password information is exposed through
NSS. You could also expose password hashes through NSS (nss-pam-ldapd
doesn't do this by default even if the LDAP server allows this) and in
that case pam_unix should be sufficient.

By using pam_ldap you can avoid exposing password hashes, you can use
all hash formats that your LDAP server supports and you can implement
extra access control checks (e.g. pam_authz_search). In general, this is

The way I think it works with LDAP is: the PAM/NSS combination talks
to nslcd, which caches authentication and account information. nslcd
even maps attribute names if configured correspondingly. nslcd then
asks the LDAP server for the required information and passes them back

With nss-pam-ldapd the NSS and PAM modules talk to nslcd which
translates the requests into appropriate LDAP queries. It doesn't do
caching at the moment. nscd can do caching of a number of NSS queries
(but not PAM and not all queries).

So the idea was to use primaryGroupID which defaults to 513 aka "Domain
User". The problem with this: a search for this "gid" won't return "Domain
Users" or any other kind of information.

If you don't use the primary group id for anything, you could map it to
some constant, say:

  map passwd gidNumber "100"

(assuming "getent group 100" returns something reasonable, it could be a
local group) Note that the user doesn't have to be an explicit member of
their primary group.

Reason is that ADs use distinguished names to refer to a group or user:

- a user entry can have multiple "memberOf" attributes that contain
  DNs of the particular group
- group entries have a "member" attribute that holds a list of user

nslcd currently doesn't support the memberOf attribute. It does support
the member attribute in the mapping you have.

I think you are missing a mapping of the gidNumber attribute in the
group map:

  map group gidNumber primaryGroupID

(assuming the primaryGroupID is present in group entries in AD) For a
group to be available in NSS it has to have a unique id.

From your logs it shows you are using nss-pam-ldapd 0.7.2 which is very
old and has a number of known bugs. The 0.7.13 release is well tested
and stable. The 0.8 series is somewhat less mature but does include
functionality to use the objectSid attribute to construct user and group
ids which could be helpful to you.

Hope this helps.

Erstellt mit Operas revolutionärem E-Mail-Modul:
To unsubscribe send an email to or see