#2448 MAN: If ldap_group_base is set, tokengroups might not be able to convert all GIDs to names
Closed: Fixed None Opened 4 years ago by prajwal83.

I'm trying to integrate SUSE Linux (version 11 Patch level 2) with Microsoft Active Directory(AD) using the SSSD version 1.9.4 for making AD groups available to the Linux OS subsystem (SSSD is not used for authentication)

I've added the "sss" as a source for "passwd", "group", "shadow" within the "/etc/nsswitch.conf" file.

I'm seeing SSSD return inconsistent results while fetching the User/Group information through "id" / "getent" commands. It appears that we are facing this inconsistency only while SSSD interacts with Domain Controller with version Windows Server 2008 R2, and not while SSSD is interacting with Windows Server 2003 R2 based domain controller.

Please find the response/output from Linux host (terminal) as below:

1) For Windows Server 2008 R2 based Domain Controller
controller@indelappvm02:~> id user_hadoop_3001
uid=2763510(user_hadoop_3001) gid=100513(Domain Users) groups=100513(Domain Users),2816151(Mygroups-hadoop-GED_KPI),2115887,2812298(Mygroups-hadoop-DAS_ANALYST),2812208(Mygroups-hadoop-CV_US),2809985(Mygroups-hadoop-DB_TICKET),2816149(Mygroups-hadoop-TLM),2827118(Mygroups-hadoop-DAS_ALL),2819228(Mygroups-hadoop-IMAGINE_GED_LON),2820642(Mygroups-hadoop-IMHOTEP),2812212(Mygroups-hadoop-OPEX),2024985,2356240,2358411,2100126,2115932,2099 968,2337579,1743308,1463380,2100236,1881724,1707456

As can be seen above, certain GIDs are displayed though these are not relevant to the user. When I query the same user again in the same session, I get the correct results without the additional GIDs. The problem re-appears when the cache has been cleared and the command is re-run.

2) For Windows Server 2003 R2 based Domain Controller
controller@indelappvm02:~> id user_hadoop_3001
uid=2763510(user_hadoop_3001) gid=100513(Domain Users) groups=100513(Domain Users),2816151(Mygroups-hadoop-GED_KPI),2812208(Mygroups-hadoop-CV_US),2819228(Mygroups-hadoop-IMAGINE_GED_LON),2827118(Mygroups-hadoop-DAS_ALL),2812298(Mygroups-hadoop-DAS_ANALYST),2809985(Mygroups-hadoop-DB_TICKET),2816149(Mygroups-hadoop-TLM),2820642(Mygroups-hadoop-IMHOTEP),2812212(Mygroups-hadoop-OPEX)

The results are always accurate.

SSSD config is attached.


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

resolution: => fixed
status: assigned => closed

Metadata Update from @prajwal83:
- Issue assigned to lslebodn
- Issue set to the milestone: SSSD 1.11.8

2 years ago

Login to comment on this ticket.

Metadata