(no subject)

We have been working this problem for two weeks debugging. We have 389-ds 
running and multi-master with 3 RHEL6 servers and a RHEL5. The RHEL5 ldap 
clients authenticate correctly to the RHEL6 389-ds directory server and 
with 'id' command can see all groups a user belongs too.

The same command in a RHEL6 ldap client using sssd shows ONLY the primary 
group. If we change the ldap clients to point at the RHEL5 389-ds 
directory server the same results occur. The one consistency is any RHEL6 
ldap client we setup will authenticate to either RHEL5 or RHEL6 but the 
entire list of groups that user belongs to do not transfer independent of 
server version. We have enumerate set to true and we have 
ldap_group_member set to uniqueMember. These seems to point to the ldap 
client as RHEL5 client works just fine and both RHEL5 and RHEL6 389-ds 
servers react the same but we're not sure how to correct or is it a bug. 
HELP?

Thanks!

Harry Devine
Common ARTS Software Development
AJM-245
[phone]
[e-mail]

[Justin Edmands]

On Tue, Oct 22, 2013 at 9:51 AM,  wrote:
> We have been working this problem for two weeks debugging. We have 389-ds
> running and multi-master with 3 RHEL6 servers and a RHEL5. The RHEL5 ldap
> clients authenticate correctly to the RHEL6 389-ds directory server and
> with 'id' command can see all groups a user belongs too.
>
> The same command in a RHEL6 ldap client using sssd shows ONLY the primary
> group. If we change the ldap clients to point at the RHEL5 389-ds directory
> server the same results occur. The one consistency is any RHEL6 ldap client
> we setup will authenticate to either RHEL5 or RHEL6 but the entire list of
> groups that user belongs to do not transfer independent of server version.
> We have enumerate set to true and we have ldap_group_member set to
> uniqueMember. These seems to point to the ldap client as RHEL5 client works
> just fine and both RHEL5 and RHEL6 389-ds servers react the same but we're
> not sure how to correct or is it a bug. HELP?
>
> Thanks!
>
> Harry Devine
> Common ARTS Software Development
> AJM-245
> [phone]
> [e-mail]
> --
> 389 users mailing list
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/389-users

I had the same issue. SSSD needs to be told where to pull these from.

I had to add this to the global section of the sssd.conf (you may need to
disable all caching devices as well. they will hold the old "id" lookups)

ldap_group_member = memberUid
ldap_group_search_base = ou=<your group here>,dc=sagedining,dc=com

We tried that and, sadly, it made no difference.  In fact, we get LESS 
information that before.  It appears as though we get the main group, and 
it does not know how to dig further to get the sub-groups and group 
members.  Also, we found that our ldap_group_member is called uniqueMember 
and not memberUid.  Perhaps that's unique to your installation?

Any other ideas?  Should we post our sssd.conf?

Thanks,
Harry

Harry Devine
Common ARTS Software Development
AJM-245
[phone]
[e-mail]

From:
Justin Edmands

To:
"General discussion list for the 389 Directory server project." 

Date:
10/22/2013 10:22 AM
Subject:
Re: [389-users] (no subject)
Sent by:
[e-mail]

On Tue, Oct 22, 2013 at 9:51 AM,  wrote:

We have been working this problem for two weeks debugging. We have 389-ds 
running and multi-master with 3 RHEL6 servers and a RHEL5. The RHEL5 ldap 
clients authenticate correctly to the RHEL6 389-ds directory server and 
with 'id' command can see all groups a user belongs too.

The same command in a RHEL6 ldap client using sssd shows ONLY the primary 
group. If we change the ldap clients to point at the RHEL5 389-ds 
directory server the same results occur. The one consistency is any RHEL6 
ldap client we setup will authenticate to either RHEL5 or RHEL6 but the 
entire list of groups that user belongs to do not transfer independent of 
server version. We have enumerate set to true and we have 
ldap_group_member set to uniqueMember. These seems to point to the ldap 
client as RHEL5 client works just fine and both RHEL5 and RHEL6 389-ds 
servers react the same but we're not sure how to correct or is it a bug. 
HELP?

Thanks!

Harry Devine
Common ARTS Software Development
AJM-245
[phone]
[e-mail]
--
389 users mailing list
[e-mail]
https://admin.fedoraproject.org/mailman/listinfo/389-users

I had the same issue. SSSD needs to be told where to pull these from.

I had to add this to the global section of the sssd.conf (you may need to 
disable all caching devices as well. they will hold the old "id" lookups)

ldap_group_member = memberUid
ldap_group_search_base = ou=<your group here>,dc=sagedining,dc=com
--
389 users mailing list
[e-mail]
https://admin.fedoraproject.org/mailman/listinfo/389-users

[Justin Edmands]

On Tue, Oct 22, 2013 at 11:25 AM,  wrote:
> We tried that and, sadly, it made no difference.  In fact, we get LESS
> information that before.  It appears as though we get the main group, and
> it does not know how to dig further to get the sub-groups and group
> members.  Also, we found that our ldap_group_member is called uniqueMember
> and not memberUid.  Perhaps that's unique to your installation?
>
> Any other ideas?  Should we post our sssd.conf?
>
> Thanks,
> Harry
>
> Harry Devine
> Common ARTS Software Development
> AJM-245
> [phone]
> [e-mail]
>
> From: Justin Edmands 
>  To: "General discussion list for the 389 Directory server project." <
> [e-mail]> Date: 10/22/2013 10:22 AM Subject: Re:
> [389-users] (no subject) Sent by:
> [e-mail]
>
> On Tue, Oct 22, 2013 at 9:51 AM, <*[e-mail]*>
> wrote:
>
> We have been working this problem for two weeks debugging. We have 389-ds
> running and multi-master with 3 RHEL6 servers and a RHEL5. The RHEL5 ldap
> clients authenticate correctly to the RHEL6 389-ds directory server and
> with 'id' command can see all groups a user belongs too.
>
> The same command in a RHEL6 ldap client using sssd shows ONLY the primary
> group. If we change the ldap clients to point at the RHEL5 389-ds directory
> server the same results occur. The one consistency is any RHEL6 ldap client
> we setup will authenticate to either RHEL5 or RHEL6 but the entire list of
> groups that user belongs to do not transfer independent of server version.
> We have enumerate set to true and we have ldap_group_member set to
> uniqueMember. These seems to point to the ldap client as RHEL5 client works
> just fine and both RHEL5 and RHEL6 389-ds servers react the same but we're
> not sure how to correct or is it a bug. HELP?
>
> Thanks!
>
> Harry Devine
> Common ARTS Software Development
> AJM-245*
> **[phone]* <%28609%29485-4218>*
> **[e-mail]*
>
> 389 users mailing list*
> **[e-mail]* *
> **https://admin.fedoraproject.org/mailman/listinfo/389-users*https://admin.fedoraproject.org/mailman/listinfo/389-users
>
> I had the same issue. SSSD needs to be told where to pull these from.
>
> I had to add this to the global section of the sssd.conf (you may need to
> disable all caching devices as well. they will hold the old "id" lookups)
>
> ldap_group_member = memberUid
> ldap_group_search_base = ou=<your group here>,dc=sagedining,dc=com
> --
> 389 users mailing list
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/389-users
>
> --
> 389 users mailing list
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/389-users

Please do

[Rob Crittenden]

[e-mail] wrote:
> We tried that and, sadly, it made no difference.  In fact, we get LESS
> information that before.  It appears as though we get the main group,
> and it does not know how to dig further to get the sub-groups and group
> members.  Also, we found that our ldap_group_member is called
> uniqueMember and not memberUid.  Perhaps that's unique to your
> installation?
>
> Any other ideas?  Should we post our sssd.conf?

You may want to cross-post this on the sssd-users mailing list, 
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

rob
> Thanks,
> Harry
>
> Harry Devine
> Common ARTS Software Development
> AJM-245
> [phone]
> [e-mail]
>
> From: 	Justin Edmands 
> To: 	"General discussion list for the 389 Directory server project."
>
> Date: 	10/22/2013 10:22 AM
> Subject: 	Re: [389-users] (no subject)
> Sent by: 	[e-mail]
>
> On Tue, Oct 22, 2013 at 9:51 AM, <[e-mail]_
> > wrote:
>
> We have been working this problem for two weeks debugging. We have
> 389-ds running and multi-master with 3 RHEL6 servers and a RHEL5. The
> RHEL5 ldap clients authenticate correctly to the RHEL6 389-ds directory
> server and with 'id' command can see all groups a user belongs too.
>
> The same command in a RHEL6 ldap client using sssd shows ONLY the
> primary group. If we change the ldap clients to point at the RHEL5
> 389-ds directory server the same results occur. The one consistency is
> any RHEL6 ldap client we setup will authenticate to either RHEL5 or
> RHEL6 but the entire list of groups that user belongs to do not transfer
> independent of server version. We have enumerate set to true and we have
> ldap_group_member set to uniqueMember. These seems to point to the ldap
> client as RHEL5 client works just fine and both RHEL5 and RHEL6 389-ds
> servers react the same but we're not sure how to correct or is it a bug.
> HELP?
>
> Thanks!
>
> Harry Devine
> Common ARTS Software Development
> AJM-245_
> __(609)485-4218_ tel:%28609%29485-4218_
> [e-mail]_ 
> --
> 389 users mailing list_
> [e-mail]_
> _
> __https://admin.fedoraproject.org/mailman/listinfo/389-users_
>
> I had the same issue. SSSD needs to be told where to pull these from.
>
> I had to add this to the global section of the sssd.conf (you may need
> to disable all caching devices as well. they will hold the old "id" lookups)
>
> ldap_group_member = memberUid
> ldap_group_search_base = ou=<your group here>,dc=sagedining,dc=com
> --
> 389 users mailing list
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/389-users
>
> --
> 389 users mailing list
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/389-users

[Gordon Messmer]

On 10/22/2013 06:51 AM, [e-mail] wrote:
> We have enumerate set to true and we have ldap_group_member set to
> uniqueMember.

uniqueMember can only be used for ldap_group_member if you also set 
ldap_schema=rfc2307bis

If you don't set the ldap_schema, ldap_group_member is expected to 
contain usernames, which will normally be in memberUid.  uniqueMember 
contains a DN, and is not interchangeable with memberUid.