sssd config
sssd.txt

Please try with a recent upstream version as indicated at: https://lists.fedorahosted.org/pipermail/sssd-users/2014-September/002214.html

Unless the suse 1.9.4 version is heavily patched, it contains several known bugs related to tokenGroups processing.

Kindly reopen if you can reproduce with a supported upstream version.

resolution: => worksforme
status: new => closed

Hello,

I was able to reproduce this issue with SSSD 1.11.6 on RHEL 6.5. The group processing fails (with output similar to #1 in the original ticket) returning GIDs (without group names) when talking to Windows Server 2008 R2 based domain controller but works well against Windows Server 2003 R2. This is with the same sssd.conf that was previously attached to this ticket.

mark: => 0

Fields changed

changelog: => Re-opening as the issue occurs on RHEL 6.5 + SSSD 1.11.6 against Windows Server 2008 R2
resolution: worksforme =>
status: closed => reopened
version: 1.9.4 => 1.11.6

Chances are this problem would be fixed in 1.11.7.

I built 1.11.7 for your convenience in a COPR repo:
http://copr-fe.cloud.fedoraproject.org/coprs/jhrozek/SSSD-1.11-RHEL6/

Please retest and let us know!

Hi jhrozek, Thank you for the package. I upgraded to 1.11.7 on my RHEL 6.5 box. I have a new problem now as SSSD fails to convert objectSID to Unix IDs. With a debug level of 9 (this is the same config that worked in previous versions < 1.11.7), I see the below:

(Mon Oct 13 16:03:32 2014) [sssd[be[dbg]]] [sdap_get_primary_name] (0x0400): Processing object chantri
(Mon Oct 13 16:03:32 2014) [sssd[be[dbg]]] [sdap_save_user] (0x0400): Processing user chantri
(Mon Oct 13 16:03:32 2014) [sssd[be[dbg]]] [sdap_save_user] (0x1000): Mapping user [chantri] objectSID [S-1-5-21-1611181143-1305343219-1050001001-2353897] to unix ID
(Mon Oct 13 16:03:32 2014) [sssd[be[dbg]]] [sdap_idmap_sid_to_unix] (0x0080): Could not convert objectSID [S-1-5-21-1611181143-1305343219-1050001001-2353897] to a UNIX ID
(Mon Oct 13 16:03:32 2014) [sssd[be[dbg]]] [sdap_save_user] (0x0020): Failed to save user [chantri]
(Mon Oct 13 16:03:32 2014) [sssd[be[dbg]]] [sdap_save_users] (0x0040): Failed to store user 0. Ignoring.

I tried with both the AD and LDAP providers but get the same result against both Windows Server 2003 and 2008 based domain controllers. I'm using the defaults in the domains section of sssd.conf. Snippet below:

[domain/test]
id_provider = ad
access_provider = ad
ad_server = example.test.abcd.com
ad_domain = test.abcd.com
ldap_id_mapping = true
dyndns_update = false
krb5_keytab = /etc/sssd/abcd.keytab
ldap_schema = ad
ldap_idmap_default_domain = test.abcd.com

Would appreciate if you could provide some guidance here. The RID range on my AD forest is upwards of 200k with the max being around 3000k.

Hi,

My issue with 1.11.6 is something similar to https://fedorahosted.org/sssd/ticket/2385 . The first initgroup returns empty group names (only the GID appears). Subsequent initgroups return the correct results until the cache is cleared and SSSD is restarted. Would appreciate inputs for getting 1.11.7 working on my system.

Hi,

I sorted out the issue explained in comment#6 and I now have SSSD 1.11.7 running with the AD provider against a Windows Server 2008 R2 based domain controller. BUT the core inconsistency issue with SSSD still exists. I get a number of empty groups (without names) with GIDs alone when I run the "id <user>" command.

I set ldap_use_tokengroups = false on 1.11.7 and everything works well now. I sense there are still bugs with token group processing on 1.11.7. Is there a way to disable token groups in 1.9 / 1.10 against AD backend?

Replying to [comment:8 prajwal83]:

Hi,

I sorted out the issue explained in comment#6 and I now have SSSD 1.11.7 running with the AD provider against a Windows Server 2008 R2 based domain controller. BUT the core inconsistency issue with SSSD still exists. I get a number of empty groups (without names) with GIDs alone when I run the "id <user>" command.

Unfortunately there is not, I'm sorry.

I know you also wrote to sssd-users. Would you mind sending SSSD logs to that thread? (All sssd developers are subscribed to sssd-users, not all sssd developers read all the tickets...)

Fields changed

owner: somebody => lslebodn
status: reopened => new

The purpose of this ticket is only to document that if ldap_group_search_base is set, tokenGroups might not be able to resolve all GIDs into names.

Fields changed

summary: SSSD returns inconsistent results in a AD forest with mixture of 2003 R2 and 2008 R2 based controllers => MAN: If ldap_group_base is set, tokengroups might not be able to convert all GIDs to names

Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.11.8

Fields changed

rhbz: => 0

Fields changed

status: new => assigned

Fields changed

patch: 0 => 1

• master: 0201118

• sssd-1-11: 3cc9377

resolution: => fixed
status: assigned => closed

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/3490

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.