RSS feed

RE: Why does nslcd require LDAP user entry objectClass=posixAccount?

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

RE: Why does nslcd require LDAP user entry objectClass=posixAccount?

On Thu, 9 Apr, 2015 at 5:19 , Shimin <> wrote:
Unfortunately, it's not an option for us to change LDAP user schema.  We have to support/use an external LDAP database where we cannot extend their schema to add objectClass=posixAccount to their existing user entries.   Can we use

map passwd uidNumber employeenumber

maybe, but you'll also have to map gidNumber, loginShell, and a few others.

Most Unix applications, ns services, and PAM expect to be able to call getuid(), geteuid(), getgid(), getpwent(), etc.  PAM will, by default, check if you have a valid shell.  It's common for applications to call getpwent(geteuid()) to get information about the user.

Even if you're not supplying a full login, some applications will attempt to call this, which will in turn make calls to NS, which is why you are using nslcd (NS LDAP)  NS must provide answers to these questions.

The minimum you will need is basically a valid getpwent() entry.  man getpwent.

gecos is allowed to be empty, but not NULL.

shell is not usually allowed to be empty, but you can edit pam to prevent that, I think.  You should be able to default this to /bin/bash or /bin/nologin.

dir is not allowed to be empty, I think.

It makes no sense to require all LDAP user entries to use objectClass=posixAccount when the users are not unix-based and posixAccount attributes like loginShell do not make sense.

Then why are you using PAM?  Why not make a straight LDAP call?

What do you think? would the attribute map above work?  Thanks!!

If uidNumber can be >65535, make sure it's valid on your system.  Not all older apps accept more than a 16-bit int.  There used to be funny stuff with uid_t being a signed int too.  employeeNumbers can frequently be bigger, and frequently have leading zeroes.
To unsubscribe send an email to or see