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?
- From: Berend De Schouwer <berend [at] deschouwer.co.za>
- To: Shimin <smqian [at] hotmail.com>
- Cc: "nss-pam-ldapd-users [at] lists.arthurdejong.org" <nss-pam-ldapd-users [at] lists.arthurdejong.org>, Todd Grayson <tgrayson [at] cloudera.com>
- Subject: RE: Why does nslcd require LDAP user entry objectClass=posixAccount?
- Date: Thu, 09 Apr 2015 10:25:53 +0200
On Thu, 9 Apr, 2015 at 5:19 , Shimin <smqian@hotmail.com> 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 usemap 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.
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 nss-pam-ldapd-users-unsubscribe@lists.arthurdejong.org or see http://lists.arthurdejong.org/nss-pam-ldapd-users/
- Why does nslcd require LDAP user entry objectClass=posixAccount?,
Shimin
- Re: Why does nslcd require LDAP user entry objectClass=posixAccount?,
Todd Grayson
- RE: Why does nslcd require LDAP user entry objectClass=posixAccount?,
Shimin
- Re: Why does nslcd require LDAP user entry objectClass=posixAccount?, Todd Grayson
- RE: Why does nslcd require LDAP user entry objectClass=posixAccount?, Berend De Schouwer
- RE: Why does nslcd require LDAP user entry objectClass=posixAccount?,
Shimin
- Re: Why does nslcd require LDAP user entry objectClass=posixAccount?,
Todd Grayson
- Prev by Date: Re: Why does nslcd require LDAP user entry objectClass=posixAccount?
- Next by Date: RE: Why does nslcd require LDAP user entry objectClass=posixAccount?
- Previous by thread: Re: Why does nslcd require LDAP user entry objectClass=posixAccount?
- Next by thread: RE: Why does nslcd require LDAP user entry objectClass=posixAccount?