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

["Uwe Sauter" <sauter [at] hlrs.de>]

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.

Regards,

        Uwe

Am 15.09.2011, 22:31 Uhr, schrieb Arthur de Jong <arthur@arthurdejong.org>:

> 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
> recommended.
>
> > 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
> > to PAM/NSS.
>
> 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
> >   DNs
>
> 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: http://www.opera.com/mail/
--
To unsubscribe send an email to
nss-pam-ldapd-users-unsubscribe@lists.arthurdejong.org or see
http://lists.arthurdejong.org/nss-pam-ldapd-users/