Re: Newbie - user authentication failing.

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

> A unix environment expects unique numeric user ids to be available for
> users. Most applications also assume that username -> uid lookups and
> uid -> username lookups are unique.

My requirement is that even if the unix attribute "uidNumber" (and
others) are not set on the active directory user account, the user
should be able to login to my linux box. This means that my ldap
client should populate that value.

I just want to map the uid, objectclass for user/group. Other
attribute values should be populated internally if they are not
present on the server side.

I am comfortable with "C" programming. I can tweak the code to
populate the uidNumber by creating a hash of "uid" so that it gives me
a unique number for each user account. But, I would need pointers on
what code to tweak.

Help would be highly appreciated.

Thanks,
Vinay


On Fri, Feb 11, 2011 at 12:41 PM, Vinay Kalkoti <kalkoti.vinay@gmail.com> wrote:
> 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