Sorry for late response.
Yes, it resolves the DN properly along with secondary groups.
[psunda...@ldap02 ~]$ id psundaram
uid=2100(psundaram) gid=1000(staff)
groups=1050(people),2000(admins),1000(staff)
I will test the mapping attribute in a week or so.
-Prashanth
On Thu, 2010-05-06 at 14:45 -
On Thu, 2010-05-06 at 14:45 -0400, Prashanth Sundaram wrote:
> I got around this by changing the ldap.conf.
>
> pam_filter objectclass=posixAccount
> pam_member_attribute uniquemember
>
> I haven;t tested this but you can also map the memberuid and memberof
> to Uniquememember. So the nss_ldap ch
I got around this by changing the ldap.conf.
pam_filter objectclass=posixAccount
pam_member_attribute uniquemember
I haven;t tested this but you can also map the memberuid and memberof to
Uniquememember. So the nss_ldap checks the uniquemember value every time.
nss_map_attribute memberuid unique
On Tue, May 4, 2010 at 7:31 PM, John A. Sullivan III
wrote:
> Sure - go to the advanced properties of the group. Look at the
> objectclass attribute. If it does not contain posixgroup (I believe
> that's the correct value - I'm not looking at my 389 right now), click
> in the list of values and
Rick Dicaire wrote:
> On Tue, May 4, 2010 at 7:07 AM, John A. Sullivan III
> wrote:
>
>>> Why doesn't the group I'd added the user to show?
>>>
>>>
>> I do not know if it is the same issue but I found I had to add the
>> posixgroup objectclass to the group; I had to add the memberuid
>>
On Tue, May 4, 2010 at 7:07 AM, John A. Sullivan III
wrote:
>> Why doesn't the group I'd added the user to show?
>>
> I do not know if it is the same issue but I found I had to add the
> posixgroup objectclass to the group; I had to add the memberuid
As a followup, is this group issue something s
