Re: Newbie - user authentication failing.

[Vinay Kalkoti <kalkoti.vinay [at] gmail.com>]

One of the mail thread "[nssldap] question about nssldap
configuration" (link -->
http://lists.arthurdejong.org/padl-nssldap/2010/msg00079.html) has
suggested hashing username. I am not sure what this means.

Thanks,
Vinay

On Fri, Feb 11, 2011 at 12:21 PM, Vinay Kalkoti <kalkoti.vinay@gmail.com> wrote:
> Hi,
>
> 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)(!(objectClass=computer))(uidNumber=*)(unixHomeDirectory=*))
> filter passwd (&(objectClass=user)(uidNumber=*))
> map    passwd uid              sAMAccountName
> #map    passwd homeDirectory    unixHomeDirectory
> map    passwd gecos            displayName
> #filter shadow 
> (&(objectClass=user)(!(objectClass=computer))(uidNumber=*)(unixHomeDirectory=*))
> 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"
>
>
> Thanks,
> Vinay
>
> On Fri, Feb 11, 2011 at 10:32 AM, Vinay Kalkoti <kalkoti.vinay@gmail.com> 
> 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 <arthur@arthurdejong.org> 
>> 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 - arthur@arthurdejong.org - http://arthurdejong.org --
>>>
>>
>
-- 
To unsubscribe send an email to
nss-pam-ldapd-users-unsubscribe@lists.arthurdejong.org or see
http://lists.arthurdejong.org/nss-pam-ldapd-users