RSS feed

Re: Newbie - user authentication failing.

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

Re: Newbie - user authentication failing.


I read that I cannot create an expression for overriding "uidNumber".
One of my requirements is to authenticate active directory user
accounts whose "UNIX" attributes are not set.

I have been able to override "gidNumber", homeDirectory" and "loginShell".

Is there a way to override "uidNumber" or map it to any active
directory user schema attribute.

This is how my mapping looks like for active directory authentication.

pagesize 1000
#referrals off
filter passwd (&(objectClass=user)(uidNumber=*))
map    passwd uid              sAMAccountName
#map    passwd homeDirectory    unixHomeDirectory
map    passwd gecos            displayName
#filter shadow 
filter shadow (&(objectClass=user)(uidNumber=*))
map    shadow uid              sAMAccountName
#map    shadow shadowLastChange pwdLastSet
filter group  (objectClass=group)
map    group  uniqueMember     member

map passwd homeDirectory "/home/$sAMAccountName"
map passwd gidNumber "1002"
map passwd loginShell "/bin/bash"


On Fri, Feb 11, 2011 at 10:32 AM, Vinay Kalkoti <> wrote:
> Hi All,
> Thanks for a quick response.
> I had another question.
> Since nslcd runs as a daemon, are there any known issues which are not
> fixed in 0.7.13 on resource leaks and high CPU consumption so that I
> can have them at the back of my mind?.
> I saw one mail thread on memory leaks which was root caused to OpenLDAP 
> client.
> I still haven't been able to get my hands on the bug database (if any).
> Thanks,
> Vinay
> On Fri, Feb 11, 2011 at 3:31 AM, Arthur de Jong <> 
> wrote:
>> On Thu, 2011-02-10 at 13:25 +0530, Vinay Kalkoti wrote:
>>> I also wanted a confirmation that I can set the home directory path
>>> to /home/$uid even if the home directory attribute is set to a
>>> different path (like /users/unix) on the directory server.
>> When using
>>  map passwd homeDirectory "/home/$uid"
>> nslcd should not request the homeDirectory attribute from LDAP at all
>> and only use the uid attribute.
>>> Another question I had was, should I still configure openldap client
>>> for nss-pam-ldapd ?. I am using SLES (10, sp2) and my openldap
>>> configuration file is /etc/openldap/ldap.conf
>> The configuration of nslcd is completely separate from other LDAP tools.
>> The main reason for this is that things can break quite subtly with
>> conflicting configuration options. In most cases it is a good idea to
>> keep the basic settings in sync though to avoid typing when doing
>> ldapsearch from the command line.
>>> I need to configure it against both LDAP servers and Active Directory
>>> servers.
>> You can configure multiple servers but they are expected to be copies
>> used for fail-over. If all servers serve the same information you should
>> be fine.
>> If you have different data on servers you may be able to do some tricks
>> with referrals but authentication does not work as expected then.
>>> I have started with LDAP server and I have set the configurations in
>>> /etc/nslcd.conf
>>> - uri ldap://<ip>
>>> - base    dc=example,dc=comp,dc=com
>>> - binddn cn=Administrator,dc=example,dc=comp,dc=com
>>> - bindpw secret
>>> - scope sub
>> For normal operation nss-pam-ldapd does not need administrative access
>> to your LDAP server. It only needs to be able to read the needed
>> attributes. It only does write operations when changing passwords and
>> that should either use the logged-in user's credentials or the
>> rootpwmoddn credentials.
>>> If I try "su - test_user', it just throws me an error "su: user
>>> test_user does not exist, where test_user is from an ldap server and
>>> 'getent passwd' lists it.
>> It depends on how your PAM stack is set up how this works. For some
>> set-ups you need to also provide shadow information via NSS (otherwise
>> pam_unix blocks the user). Also, for this nscd can cause problems (as
>> pointed out by Ryan). When testing at least you should disable it.
>> For production, if you need caching you could have a look at unscd. It
>> is supposed to be a lot more stable and I've been using it a while now
>> without any issues (but I never had many issues with nscd).
>>> If I try ssh with the user account, I see that nslcd is trying the
>>> same user account for binding.
>>> nslcd: [b127f8] DEBUG: 
>>> ldap_simple_bind_s("uid=test_user,dc=example,dc=comp,dc=com","***") 
>>> (uri="ldap://1<ip>")
>>> nslcd: [b127f8] DEBUG: failed to bind to LDAP server ldap://<ip>: Invalid 
>>> credentials
>>> nslcd: [b127f8] DEBUG: ldap_unbind()
>>> nslcd: [b127f8] lookup of user uid=test_user,dc=example,dc=comp,dc=com 
>>> failed: Invalid credentials
>> Your LDAP server should allow simple authentication and allow it to
>> search for it's own entry. The following should work for authentication
>> to succeed:
>> ldapsearch -x -W -H ldap://<ip> \
>>  -D 'uid=test_user,dc=example,dc=comp,dc=com' \
>>  -b 'uid=test_user,dc=example,dc=comp,dc=com' \
>>  '(uid=test_user)' uid
>> (this is more or less what nslcd does to test authentication)
>> --
>> -- arthur - - --
To unsubscribe send an email to or see