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?

Thanks so much for explaining why posixAccount will be necessary if we are going to use pam_dap.   

I did develop a web service that makes straight LDAP calls to authenticate users and get their roles.  It was relatively painless and no restrictions such as this.   We have converted a couple of our web apps already to use the service, no problem there.  The issue is that we also have a CLI component on Linux boxes and some components that  makes use of SSH tunnels into the Linux systems that rely on unix  login, sshd, pam_unix, that we have to add LDAP authentication support.  pam_ldap was first thought of as an obvious choice.  I wish we could just convert those to use the web service also that makes straight LDAP API calls, so we no longer have to go through the pam_ldap route.  Is it even possible?  What are the options?

I would appreciate your input and suggestions!!


Date: Thu, 9 Apr 2015 10:25:53 +0200
Subject: 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
To unsubscribe send an email to or see