Hi all.
I'm running sssd on RHEL6 and seem to have a problem seeing secondary/auxiliary groups for logged in users.
I'm using SASL/Kerberos/LDAP authentication to an AD backend. I'm using this config:
[domain/KRB5DOMAIN] enumerate = true cache_credentials = True id_provider = ldap auth_provider = krb5 chpass_provider = krb5
ldap_schema = rfc2307bis ldap_user_object_class = user ldap_group_object_class = group ldap_user_member_of = msSFU30PosixMemberOf ldap_group_member = msSFU30PosixMember
ldap_uri = ldap://xxx.xxx.xxx/ ldap_search_base = dc=xxx,dc=xxx,dc=xxx ldap_group_search_base = ou=Groups,dc=xxx,dc=xxx,dc=xxx ldap_sasl_mech = gssapi ldap_sasl_authid = host/hostname.xxx.xxx.xxx@xxx.xxx.xxx ldap_krb5_keytab = /etc/krb5.keytab ldap_krb5_init_creds = true krb5_realm = xxx.xxx.xxx
Logging in works fine, and I can specify an "ldap_access_filter" to limit the people who can log into the machine by the AD groups they are in and it works a treat.
The problem I have is: when I log in I can not see the secondary groups that my userid is in. When I run "id" or "groups", I only see my primary group:
[tim@rhel6 ~]$ groups sysadm
If I run the "groups" command on a RHEL5 system (using ldap/krb5/pam_ldap), you see many groups:
[tim@rhel5 ~]$ groups sysadm unixdef edc0002 midrange midora cifrs cifru yyyyy cdirt pdiru jbsrt cdir cdird edcrt cdiri voiru voirs estrt pc4rt middlemr pc4ru insrd insrt insrs fess dplrt dplru sdsdev sdsrd gwrrt mmsrt cbsrt hudru jirru sybau aimru aimrs svnr fshru oggat rmbat aairu aairs pdirs ecors ecoru frirt esvru nexru xyzrt xxxrt kkrt dumrt tabrs tabrt
I've been through the red hat bugzilla and sssd trac and I don't see a solution. I have set my schema to "rfc2307bis"https://bugzilla.redhat.com/show_bug.cgi?id=580402 and I have enumerate = truehttps://bugzilla.redhat.com/show_bug.cgi?id=626775.
I'm wondering if sssd only grabs the first 1000 users and 1000 groups and then stops:
[root@rhel6 /]# grep 1000 /var/log/sssd/sssd_KRB5DOMAIN.log (Tue Dec 21 14:50:11 2010) [sssd[be[KRB5DOMAIN]]] [sdap_get_users_process] (6): Search for users, returned 1000 results. (Tue Dec 21 14:50:17 2010) [sssd[be[KRB5DOMAIN]]] [sdap_get_users_done] (9): Saving 1000 Users - Done (Tue Dec 21 14:50:21 2010) [sssd[be[KRB5DOMAIN]]] [sdap_get_groups_process] (6): Search for groups, returned 1000 results. (Tue Dec 21 14:50:36 2010) [sssd[be[KRB5DOMAIN]]] [sdap_get_groups_done] (9): Saving 1000 Groups - Done [root@rhel6 ~]# getent group | wc -l 1049 [root@rhel6 ~]# wc -l /etc/group 49 /etc/group
Could it be because our AD has many more than 1000 users and 1000 groups? If so, if there any way to increase this limit?
Alternatively, if we there was a group search filter option that would also reduce the number of groups to enumerate, but I see this feature has already been requestedhttps://fedorahosted.org/sssd/ticket/647.
I'm not convinced this 1000 record limit exists or is even the root cause of my problem though. If there's anything you guys can suggest I'd be most appreciative.
Many thanks,
Tim.
________________________________ This e-mail is sent by Suncorp-Metway Limited ABN 66 010 831 722 or one of its related entities "Suncorp". Suncorp may be contacted at Level 18, 36 Wickham Terrace, Brisbane or on 13 11 55 or at suncorp.com.au. The content of this e-mail is the view of the sender or stated author and does not necessarily reflect the view of Suncorp. The content, including attachments, is a confidential communication between Suncorp and the intended recipient. If you are not the intended recipient, any use, interference with, disclosure or copying of this e-mail, including attachments, is unauthorised and expressly prohibited. If you have received this e-mail in error please contact the sender immediately and delete the e-mail and any attachments from your system. If this e-mail constitutes a commercial message of a type that you no longer wish to receive please reply to this e-mail by typing Unsubscribe in the subject line.
On Tue, Dec 21, 2010 at 04:02:14PM +1000, GOLLSCHEWSKY, Tim wrote:
Hi all.
I'm running sssd on RHEL6 and seem to have a problem seeing secondary/auxiliary groups for logged in users.
I'm using SASL/Kerberos/LDAP authentication to an AD backend. I'm using this config:
[domain/KRB5DOMAIN] enumerate = true cache_credentials = True id_provider = ldap auth_provider = krb5 chpass_provider = krb5
ldap_schema = rfc2307bis ldap_user_object_class = user ldap_group_object_class = group ldap_user_member_of = msSFU30PosixMemberOf ldap_group_member = msSFU30PosixMember
ldap_uri = ldap://xxx.xxx.xxx/ ldap_search_base = dc=xxx,dc=xxx,dc=xxx ldap_group_search_base = ou=Groups,dc=xxx,dc=xxx,dc=xxx ldap_sasl_mech = gssapi ldap_sasl_authid = host/hostname.xxx.xxx.xxx@xxx.xxx.xxx ldap_krb5_keytab = /etc/krb5.keytab ldap_krb5_init_creds = true krb5_realm = xxx.xxx.xxx
Logging in works fine, and I can specify an "ldap_access_filter" to limit the people who can log into the machine by the AD groups they are in and it works a treat.
The problem I have is: when I log in I can not see the secondary groups that my userid is in. When I run "id" or "groups", I only see my primary group:
[tim@rhel6 ~]$ groups sysadm
If I run the "groups" command on a RHEL5 system (using ldap/krb5/pam_ldap), you see many groups:
Can you send the sanitized ldap.conf you use for pam_ldap and the log output of sssd during the 'groups' call with 'enumerate = false' (see below) ?
[tim@rhel5 ~]$ groups sysadm unixdef edc0002 midrange midora cifrs cifru yyyyy cdirt pdiru jbsrt cdir cdird edcrt cdiri voiru voirs estrt pc4rt middlemr pc4ru insrd insrt insrs fess dplrt dplru sdsdev sdsrd gwrrt mmsrt cbsrt hudru jirru sybau aimru aimrs svnr fshru oggat rmbat aairu aairs pdirs ecors ecoru frirt esvru nexru xyzrt xxxrt kkrt dumrt tabrs tabrt
I've been through the red hat bugzilla and sssd trac and I don't see a solution. I have set my schema to "rfc2307bis"https://bugzilla.redhat.com/show_bug.cgi?id=580402 and I have enumerate = truehttps://bugzilla.redhat.com/show_bug.cgi?id=626775.
I'm wondering if sssd only grabs the first 1000 users and 1000 groups and then stops:
[root@rhel6 /]# grep 1000 /var/log/sssd/sssd_KRB5DOMAIN.log (Tue Dec 21 14:50:11 2010) [sssd[be[KRB5DOMAIN]]] [sdap_get_users_process] (6): Search for users, returned 1000 results. (Tue Dec 21 14:50:17 2010) [sssd[be[KRB5DOMAIN]]] [sdap_get_users_done] (9): Saving 1000 Users - Done (Tue Dec 21 14:50:21 2010) [sssd[be[KRB5DOMAIN]]] [sdap_get_groups_process] (6): Search for groups, returned 1000 results. (Tue Dec 21 14:50:36 2010) [sssd[be[KRB5DOMAIN]]] [sdap_get_groups_done] (9): Saving 1000 Groups - Done [root@rhel6 ~]# getent group | wc -l 1049 [root@rhel6 ~]# wc -l /etc/group 49 /etc/group
Could it be because our AD has many more than 1000 users and 1000 groups? If so, if there any way to increase this limit?
AD only sends 1000 entries at a time. This is called paging and we plan to support paging with sssd 1.6 (see trac ticket #658). With this large amount of users and groups I would recommend to set 'enumerate = false', because for most of the typical uses cases this should be sufficient.
bye, Sumit
Alternatively, if we there was a group search filter option that would also reduce the number of groups to enumerate, but I see this feature has already been requestedhttps://fedorahosted.org/sssd/ticket/647.
I'm not convinced this 1000 record limit exists or is even the root cause of my problem though. If there's anything you guys can suggest I'd be most appreciative.
Many thanks,
Tim.
This e-mail is sent by Suncorp-Metway Limited ABN 66 010 831 722 or one of its related entities "Suncorp". Suncorp may be contacted at Level 18, 36 Wickham Terrace, Brisbane or on 13 11 55 or at suncorp.com.au. The content of this e-mail is the view of the sender or stated author and does not necessarily reflect the view of Suncorp. The content, including attachments, is a confidential communication between Suncorp and the intended recipient. If you are not the intended recipient, any use, interference with, disclosure or copying of this e-mail, including attachments, is unauthorised and expressly prohibited. If you have received this e-mail in error please contact the sender immediately and delete the e-mail and any attachments from your system. If this e-mail constitutes a commercial message of a type that you no longer wish to receive please reply to this e-mail by typing Unsubscribe in the subject line.
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
Hi Sumit,
Thanks for your response.
On Tue, Dec 21, 2010 at 04:02:14PM +1000, GOLLSCHEWSKY, Tim wrote:
Hi all.
I'm running sssd on RHEL6 and seem to have a problem seeing secondary/auxiliary groups for logged in users.
[snip]
Could it be because our AD has many more than 1000 users and 1000 groups? If so, if there any way to increase this limit?
AD only sends 1000 entries at a time. This is called paging and we plan to support paging with sssd 1.6 (see trac ticket #658). With this large amount of users and groups I would recommend to set 'enumerate = false', because for most of the typical uses cases this should be sufficient.
OK, I've done some more testing and I believe I've found the issue.
My original testing was on RHEL6, which currently ships with v1.2.1 of sssd. This version doesn't show the aux groups no matter what I do with "enumerate" or if I restrict my ldap_group_search_base to a filter than returns less than 1000 groups.
The way I got things to work was by downloading the stock RHEL6 SRPM and rebuilding it with sssd v1.2.2. So I guess somewhere in v1.2.1 -> v1.2.2 there was a patch to fix the auxillary group search in LDAP.
Note, this works now whether "enumerate" is set to true or false.
Looks like I have to wait until RHEL6 supports sssd v1.2.2 or higher before we can migrate our server fleet to RHEL6.
Thanks for your help.
Regards,
Tim.
This e-mail is sent by Suncorp-Metway Limited ABN 66 010 831 722 or one of its related entities "Suncorp". Suncorp may be contacted at Level 18, 36 Wickham Terrace, Brisbane or on 13 11 55 or at suncorp.com.au. The content of this e-mail is the view of the sender or stated author and does not necessarily reflect the view of Suncorp. The content, including attachments, is a confidential communication between Suncorp and the intended recipient. If you are not the intended recipient, any use, interference with, disclosure or copying of this e-mail, including attachments, is unauthorised and expressly prohibited. If you have received this e-mail in error please contact the sender immediately and delete the e-mail and any attachments from your system. If this e-mail constitutes a commercial message of a type that you no longer wish to receive please reply to this e-mail by typing Unsubscribe in the subject line.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/22/2010 07:25 PM, GOLLSCHEWSKY, Tim wrote:
Hi Sumit,
Thanks for your response.
On Tue, Dec 21, 2010 at 04:02:14PM +1000, GOLLSCHEWSKY, Tim wrote:
Hi all.
I'm running sssd on RHEL6 and seem to have a problem seeing secondary/auxiliary groups for logged in users.
[snip]
Could it be because our AD has many more than 1000 users and 1000 groups? If so, if there any way to increase this limit?
AD only sends 1000 entries at a time. This is called paging and we plan to support paging with sssd 1.6 (see trac ticket #658). With this large amount of users and groups I would recommend to set 'enumerate = false', because for most of the typical uses cases this should be sufficient.
OK, I've done some more testing and I believe I've found the issue.
My original testing was on RHEL6, which currently ships with v1.2.1 of sssd. This version doesn't show the aux groups no matter what I do with "enumerate" or if I restrict my ldap_group_search_base to a filter than returns less than 1000 groups.
The way I got things to work was by downloading the stock RHEL6 SRPM and rebuilding it with sssd v1.2.2. So I guess somewhere in v1.2.1 -> v1.2.2 there was a patch to fix the auxillary group search in LDAP.
Note, this works now whether "enumerate" is set to true or false.
Looks like I have to wait until RHEL6 supports sssd v1.2.2 or higher before we can migrate our server fleet to RHEL6.
What version of the SSSD package are you using in RHEL6? sssd-1.2.1-28.el6_0.4 should contain all fixes from 1.2.2 backported. Specifically, the group fixes should have been pulled into sssd-1.2.1-28.el6_0.1
- -- Stephen Gallagher RHCE 804006346421761
Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/
Hi Stephen,
On 12/22/2010 07:25 PM, GOLLSCHEWSKY, Tim wrote:
Hi Sumit,
Thanks for your response.
On Tue, Dec 21, 2010 at 04:02:14PM +1000, GOLLSCHEWSKY, Tim wrote:
Hi all.
I'm running sssd on RHEL6 and seem to have a problem seeing secondary/auxiliary groups for logged in users.
[snip]
Could it be because our AD has many more than 1000 users and 1000 groups? If so, if there any way to increase this limit?
AD only sends 1000 entries at a time. This is called paging and we plan to support paging with sssd 1.6 (see trac ticket #658). With this large amount of users and groups I would recommend to set 'enumerate = false', because for most of the typical uses cases this should be sufficient.
OK, I've done some more testing and I believe I've found the issue.
My original testing was on RHEL6, which currently ships with v1.2.1 of sssd. This version doesn't show the aux groups no matter what I do with "enumerate" or if I restrict my ldap_group_search_base to a filter than returns less than 1000 groups.
The way I got things to work was by downloading the stock RHEL6 SRPM and rebuilding it with sssd v1.2.2. So I guess somewhere in v1.2.1 -> v1.2.2 there was a patch to fix the auxillary group search in LDAP.
Note, this works now whether "enumerate" is set to true or false.
Looks like I have to wait until RHEL6 supports sssd v1.2.2 or higher before we can migrate our server fleet to RHEL6.
What version of the SSSD package are you using in RHEL6? sssd-1.2.1-28.el6_0.4 should contain all fixes from 1.2.2 backported. Specifically, the group fixes should have been pulled into sssd-1.2.1-28.el6_0.1
That's the version I was running previously. I've just removed my v1.2.2 RPMs and reinstalled the stock ones:
[u333890@jbsrd999m3 ~]$ rpm -q sssd sssd-1.2.1-28.el6_0.4.x86_64 [u333890@jbsrd999m3 ~]$ groups sysadm
Now reinstalling my v1.2.2 RPMs:
[u333890@jbsrd999m3 ~]$ rpm -q sssd sssd-1.2.2-28.el6.tim.x86_64 [u333890@jbsrd999m3 ~]$ groups sysadm unixdef dpl0002 dpl0003 dtmrp edc0001 edc0002 sasat sasap midrange midora middb2 cifrp cifrd cdirt cdirp agtrp pdirp jbsrp gbsrd dbprd edcrp jbsrd edcrd dtmrd gwrrp voirp apard estrd estrp pcmat pc4rd middlemr insrp mybrd viprp fesrp fesrd ofaat fsprd dplrp pijrd sdsrd etlat etlap iswat iswap gwrrd svnrd dbcat dbcap wmbad secru secrp optap giprp jirrp sybad sybap hudrp iswau svnrp fshrp trmst oggap rmbad iswad idmat pbirp pbird pbirt rmbat tm1ad tm1at tm1ap aairp pdiri pdird ecord ecorp abcrd nexrp esvrp xyzrd jpprd xxxrp abcrp prfrd tabrp aimrd aimrp
Thanks and regards,
Tim.
This e-mail is sent by Suncorp-Metway Limited ABN 66 010 831 722 or one of its related entities "Suncorp". Suncorp may be contacted at Level 18, 36 Wickham Terrace, Brisbane or on 13 11 55 or at suncorp.com.au. The content of this e-mail is the view of the sender or stated author and does not necessarily reflect the view of Suncorp. The content, including attachments, is a confidential communication between Suncorp and the intended recipient. If you are not the intended recipient, any use, interference with, disclosure or copying of this e-mail, including attachments, is unauthorised and expressly prohibited. If you have received this e-mail in error please contact the sender immediately and delete the e-mail and any attachments from your system. If this e-mail constitutes a commercial message of a type that you no longer wish to receive please reply to this e-mail by typing Unsubscribe in the subject line.
On Thu, Dec 23, 2010 at 4:02 PM, GOLLSCHEWSKY, Tim < Tim.GOLLSCHEWSKY@suncorp.com.au> wrote:
Hi Stephen,
On 12/22/2010 07:25 PM, GOLLSCHEWSKY, Tim wrote:
Hi Sumit,
Thanks for your response.
On Tue, Dec 21, 2010 at 04:02:14PM +1000, GOLLSCHEWSKY, Tim wrote:
Hi all.
I'm running sssd on RHEL6 and seem to have a problem seeing
secondary/auxiliary groups for logged in users.
[snip]
Could it be because our AD has many more than 1000 users and 1000
groups? If so, if there any way to increase this limit?
AD only sends 1000 entries at a time. This is called paging and we
plan
to support paging with sssd 1.6 (see trac ticket #658). With this
large
amount of users and groups I would recommend to set 'enumerate =
false',
because for most of the typical uses cases this should be sufficient.
OK, I've done some more testing and I believe I've found the issue.
My original testing was on RHEL6, which currently ships with v1.2.1 of
sssd. This version doesn't show the aux groups no matter what I do with "enumerate" or if I restrict my ldap_group_search_base to a filter than returns less than 1000 groups.
The way I got things to work was by downloading the stock RHEL6 SRPM
and rebuilding it with sssd v1.2.2. So I guess somewhere in v1.2.1 -> v1.2.2 there was a patch to fix the auxillary group search in LDAP.
Note, this works now whether "enumerate" is set to true or false.
Looks like I have to wait until RHEL6 supports sssd v1.2.2 or higher
before we can migrate our server fleet to RHEL6.
What version of the SSSD package are you using in RHEL6? sssd-1.2.1-28.el6_0.4 should contain all fixes from 1.2.2 backported. Specifically, the group fixes should have been pulled into sssd-1.2.1-28.el6_0.1
That's the version I was running previously. I've just removed my v1.2.2 RPMs and reinstalled the stock ones:
[u333890@jbsrd999m3 ~]$ rpm -q sssd sssd-1.2.1-28.el6_0.4.x86_64 [u333890@jbsrd999m3 ~]$ groups sysadm
Now reinstalling my v1.2.2 RPMs:
[u333890@jbsrd999m3 ~]$ rpm -q sssd sssd-1.2.2-28.el6.tim.x86_64 [u333890@jbsrd999m3 ~]$ groups sysadm unixdef dpl0002 dpl0003 dtmrp edc0001 edc0002 sasat sasap midrange midora middb2 cifrp cifrd cdirt cdirp agtrp pdirp jbsrp gbsrd dbprd edcrp jbsrd edcrd dtmrd gwrrp voirp apard estrd estrp pcmat pc4rd middlemr insrp mybrd viprp fesrp fesrd ofaat fsprd dplrp pijrd sdsrd etlat etlap iswat iswap gwrrd svnrd dbcat dbcap wmbad secru secrp optap giprp jirrp sybad sybap hudrp iswau svnrp fshrp trmst oggap rmbad iswad idmat pbirp pbird pbirt rmbat tm1ad tm1at tm1ap aairp pdiri pdird ecord ecorp abcrd nexrp esvrp xyzrd jpprd xxxrp abcrp prfrd tabrp aimrd aimrp
Thanks and regards,
Tim.
This e-mail is sent by Suncorp-Metway Limited ABN 66 010 831 722 or one of its related entities "Suncorp". Suncorp may be contacted at Level 18, 36 Wickham Terrace, Brisbane or on 13 11 55 or at suncorp.com.au. The content of this e-mail is the view of the sender or stated author and does not necessarily reflect the view of Suncorp. The content, including attachments, is a confidential communication between Suncorp and the intended recipient. If you are not the intended recipient, any use, interference with, disclosure or copying of this e-mail, including attachments, is unauthorised and expressly prohibited. If you have received this e-mail in error please contact the sender immediately and delete the e-mail and any attachments from your system. If this e-mail constitutes a commercial message of a type that you no longer wish to receive please reply to this e-mail by typing Unsubscribe in the subject line. _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
Just curious on this--Does AD use rfc2307 or rfc2307bis group definitions?
-bz
On Dec 23, 2010, at 7:19 PM, Brett Zimmerman zimmerman.brett@gmail.com wrote:
On Thu, Dec 23, 2010 at 4:02 PM, GOLLSCHEWSKY, Tim Tim.GOLLSCHEWSKY@suncorp.com.au wrote: Hi Stephen,
On 12/22/2010 07:25 PM, GOLLSCHEWSKY, Tim wrote:
Hi Sumit,
Thanks for your response.
On Tue, Dec 21, 2010 at 04:02:14PM +1000, GOLLSCHEWSKY, Tim wrote:
Hi all.
I'm running sssd on RHEL6 and seem to have a problem seeing secondary/auxiliary groups for logged in users.
[snip]
Could it be because our AD has many more than 1000 users and 1000 groups? If so, if there any way to increase this limit?
AD only sends 1000 entries at a time. This is called paging and we plan to support paging with sssd 1.6 (see trac ticket #658). With this large amount of users and groups I would recommend to set 'enumerate = false', because for most of the typical uses cases this should be sufficient.
OK, I've done some more testing and I believe I've found the issue.
My original testing was on RHEL6, which currently ships with v1.2.1 of sssd. This version doesn't show the aux groups no matter what I do with "enumerate" or if I restrict my ldap_group_search_base to a filter than returns less than 1000 groups.
The way I got things to work was by downloading the stock RHEL6 SRPM and rebuilding it with sssd v1.2.2. So I guess somewhere in v1.2.1 -> v1.2.2 there was a patch to fix the auxillary group search in LDAP.
Note, this works now whether "enumerate" is set to true or false.
Looks like I have to wait until RHEL6 supports sssd v1.2.2 or higher before we can migrate our server fleet to RHEL6.
What version of the SSSD package are you using in RHEL6? sssd-1.2.1-28.el6_0.4 should contain all fixes from 1.2.2 backported. Specifically, the group fixes should have been pulled into sssd-1.2.1-28.el6_0.1
That's the version I was running previously. I've just removed my v1.2.2 RPMs and reinstalled the stock ones:
[u333890@jbsrd999m3 ~]$ rpm -q sssd sssd-1.2.1-28.el6_0.4.x86_64 [u333890@jbsrd999m3 ~]$ groups sysadm
Now reinstalling my v1.2.2 RPMs:
[u333890@jbsrd999m3 ~]$ rpm -q sssd sssd-1.2.2-28.el6.tim.x86_64 [u333890@jbsrd999m3 ~]$ groups sysadm unixdef dpl0002 dpl0003 dtmrp edc0001 edc0002 sasat sasap midrange midora middb2 cifrp cifrd cdirt cdirp agtrp pdirp jbsrp gbsrd dbprd edcrp jbsrd edcrd dtmrd gwrrp voirp apard estrd estrp pcmat pc4rd middlemr insrp mybrd viprp fesrp fesrd ofaat fsprd dplrp pijrd sdsrd etlat etlap iswat iswap gwrrd svnrd dbcat dbcap wmbad secru secrp optap giprp jirrp sybad sybap hudrp iswau svnrp fshrp trmst oggap rmbad iswad idmat pbirp pbird pbirt rmbat tm1ad tm1at tm1ap aairp pdiri pdird ecord ecorp abcrd nexrp esvrp xyzrd jpprd xxxrp abcrp prfrd tabrp aimrd aimrp
Thanks and regards,
Tim.
This e-mail is sent by Suncorp-Metway Limited ABN 66 010 831 722 or one of its related entities "Suncorp". Suncorp may be contacted at Level 18, 36 Wickham Terrace, Brisbane or on 13 11 55 or at suncorp.com.au. The content of this e-mail is the view of the sender or stated author and does not necessarily reflect the view of Suncorp. The content, including attachments, is a confidential communication between Suncorp and the intended recipient. If you are not the intended recipient, any use, interference with, disclosure or copying of this e-mail, including attachments, is unauthorised and expressly prohibited. If you have received this e-mail in error please contact the sender immediately and delete the e-mail and any attachments from your system. If this e-mail constitutes a commercial message of a type that you no longer wish to receive please reply to this e-mail by typing Unsubscribe in the subject line. _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
Just curious on this--Does AD use rfc2307 or rfc2307bis group definitions?
RFC2307bis
-bz
-- Brett Zimmerman zim@ou.edu _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
What version of the SSSD package are you using in RHEL6? sssd-1.2.1-28.el6_0.4 should contain all fixes from 1.2.2 backported. Specifically, the group fixes should have been pulled into sssd-1.2.1-28.el6_0.1
That's the version I was running previously. I've just removed my v1.2.2 RPMs and reinstalled the stock ones:
[u333890@jbsrd999m3 ~]$ rpm -q sssd sssd-1.2.1-28.el6_0.4.x86_64 [u333890@jbsrd999m3 ~]$ groups sysadm
Now reinstalling my v1.2.2 RPMs:
[u333890@jbsrd999m3 ~]$ rpm -q sssd sssd-1.2.2-28.el6.tim.x86_64 [u333890@jbsrd999m3 ~]$ groups sysadm unixdef dpl0002 dpl0003 dtmrp edc0001 edc0002 sasat sasap midrange midora middb2 cifrp cifrd cdirt cdirp agtrp pdirp jbsrp gbsrd dbprd edcrp jbsrd edcrd dtmrd gwrrp voirp apard estrd estrp pcmat pc4rd middlemr insrp mybrd viprp fesrp fesrd ofaat fsprd dplrp pijrd sdsrd etlat etlap iswat iswap gwrrd svnrd dbcat dbcap wmbad secru secrp optap giprp jirrp sybad sybap hudrp iswau svnrp fshrp trmst oggap rmbad iswad idmat pbirp pbird pbirt rmbat tm1ad tm1at tm1ap aairp pdiri pdird ecord ecorp abcrd nexrp esvrp xyzrd jpprd xxxrp abcrp prfrd tabrp aimrd aimrp
Thanks and regards,
Tim.
...
Just curious on this--Does AD use rfc2307 or rfc2307bis group definitions?
-bz
I'm pretty sure it's rfc2307bis because there are "member" attributes in the LDAP group records, and also I'm using "ldap_schema = rfc2307bis" in my sssd.conf.
Just for kicks though I just changed ldap_schema to "rfc2307" in my sssd.conf and it doesn't work either.
But sssd v1.2.2 with "ldap_schema = rfc2307bis" works.
Tim.
________________________________ This e-mail is sent by Suncorp-Metway Limited ABN 66 010 831 722 or one of its related entities "Suncorp". Suncorp may be contacted at Level 18, 36 Wickham Terrace, Brisbane or on 13 11 55 or at suncorp.com.au. The content of this e-mail is the view of the sender or stated author and does not necessarily reflect the view of Suncorp. The content, including attachments, is a confidential communication between Suncorp and the intended recipient. If you are not the intended recipient, any use, interference with, disclosure or copying of this e-mail, including attachments, is unauthorised and expressly prohibited. If you have received this e-mail in error please contact the sender immediately and delete the e-mail and any attachments from your system. If this e-mail constitutes a commercial message of a type that you no longer wish to receive please reply to this e-mail by typing Unsubscribe in the subject line.
sssd-devel@lists.fedorahosted.org
-
Brett Zimmerman -
GOLLSCHEWSKY, Tim -
Stephen Gallagher -
Sumit Bose