Perhaps this is a caching issue? I do have several domains configured,
and each domain has development-wholesale name with different GID. Is
the domains cache configured/hased based on the group name ?
Thanks
On 07/23/2018 12:05 PM, Mario Rossi wrote:
I am seeing similar issues on CentOS 7, where groups, including
primary group, cannot be looked up. This is really bad when other
services depend on group lookups, for example sshd match group
statements for enabling tcpforwarding which otherwise is disable
globally, iptables group lookups ( yes, I use both ).
[root@snoopy ~]$ rpm -q sssd
sssd-1.16.0-19.el7_5.5.x86_64
root@snoopy[/etc/sssd]# service sssd stop; rm -f /var/lib/sss/db/*;
service sssd start
Redirecting to /bin/systemctl stop sssd.service
Redirecting to /bin/systemctl start sssd.service
root@snoopy[/etc/sssd]# id ezaporozhets(a)hostopia.com
uid=100001158(ezaporozhets)*gid=1004* groups=*1004*,1102
root@snoopy[/etc/sssd]# *getent -s sss group
development-wholesale(a)hostopia.com*
development-wholesale:*:1004:ezaporozhets,alyubyanitskiy
root@snoopy[/etc/sssd]# id ezaporozhets(a)hostopia.com
uid=100001158(ezaporozhets)*gid=1004(development-wholesale)
**groups=1004(development-wholesale),1102*
I tried setting ldap_use_tokengroups = false at domain level, however
still seeing the issue. I use ldap provider.
Thank you
On 07/23/2018 04:13 AM, Jakub Hrozek wrote:
>> On 22 Jul 2018, at 20:49, Spike White<spikewhitetx(a)gmail.com> wrote:
>>
>> I can't replicate that "duplicate domains" situation any more. (I
thought I'd saved that sssd.conf file, but it doesn't exhibit the same
behaviour).
>>
>> Here are the logs for a specific account failing to look up all groups with
ldap_use_tokengroups = True.
>>
>> Logs are at this URL:
>>
https://www.dropbox.com/sh/l37pj104qkrqxfa/AACuKgaQjWZ4MVr1NdEogbcMa?dl=0
>>
>> I have included the realmd.conf, sssd.conf and krb5.conf as well.
>>
>> Here's (incorrect) result back from sssd with ldap_use_tokengroups = True
>>
>> [root@spikerealmd02 sssd]# id admpatrick_wheeler
>> uid=2604370(admpatrick_wheeler) gid=2604370(admpatrick_wheeler)
groups=2604370(admpatrick_wheeler),1010(amerunixusers)
>>
> Thank you, now the logs are more helpful. What I see is repetition of “cant find
domain for $SID”. And I believe this is because the subdomains provider is disabled,
because (quite confusingly) the subdomains provider is also responsible for fetching
information about the joined domain, like its SID or the NetBIOS name.
>
> So I think there are three options:
> 1) add ad_enabled_domains=$self to each of the domains, e.g. add
ad_enabled_domains=amer.dell.com to the
amer.dell.com domain. This should make sssd fetch
info about that domain only. I know you wrote earlier that this gave you some other
headaches, but if it does, then there’s another bug..
> 2) try to help sssd by setting the domain SID manually with the
ldap_idmap_default_domain_sid option
> 3) just use tokengroups=false as a workaround.
>
>> Here is correct result back when ldap_use_tokengropus = False:
>>
>> [root@spikerealmd02 sssd]# id admpatrick_wheeler
>> uid=2604370(admpatrick_wheeler) gid=2604370(admpatrick_wheeler)
groups=2604370(admpatrick_wheeler),2283577(delta_bd_create_emea),2283643(gebs_read_prd),2283611(xxgl0370_prod),2283578(delta_bd_create),2283256(infa_developer),2283623(xxgl0363_prod),2283615(xxgl0503_prod),2283607(xxpa2891_prod),2283869(cowcprodsupport),1010(amerunixusers),1156(gbl_server_support),2284161(amerserveradministrator),2283573(dfs_gil_sit_auth),1033(amer_server_mgmt),1003(amerlinuxsup)
>>
>> this is sssd version 1.16.0
>>
>> Spike
>>
>>
>>
> Thanks, this is more helpful
>> On Thu, Jul 19, 2018 at 4:15 AM Jakub Hrozek<jhrozek(a)redhat.com> wrote:
>>
>>
>>> On 13 Jul 2018, at 17:40, Spike White<spikewhitetx(a)gmail.com> wrote:
>>>
>>> Jakub,
>>>
>>> Thank you to answering so promptly.
>>>
>>> We are currently testing this in a lab before full deployment, so I have some
degree of time before we deploy sssd in a bigger context. If you would prefer for me to
work with you directly off-line, please advise. As an example, the attached
sssd_amer.dell.com.log file was originally 40 MB. (I presume because of debugging level).
Out of respect for others on the mailing list, I severely trimmed the log file to only
the lines of interest (I hope). But it's entirely possible I may have over-trimmed.
>>>
>> I’m afraid so, because the logs say:
>>
>> (Fri Jul 13 09:25:43 2018) [sssd[be[amer.dell.com]]] [sdap_parse_range] (0x2000):
No sub-attributes for [tokenGroups]
>> ….
>>
>> and I’m really interested in this part :-)
>>
>> (Fri Jul 13 09:25:43 2018) [sssd[be[amer.dell.com]]]
[sdap_ad_tokengroups_update_members] (0x1000): Updating memberships for
[AdmPatrick_Wheeler(a)amer.dell.com]
>> ...
>> (Fri Jul 13 09:25:48 2018) [sssd[be[amer.dell.com]]]
[sdap_asq_search_parse_entry] (0x2000): Matched objectclass [user] on DN
[CN=AdmPatrick_Wheeler,OU=AdmAccounts,DC=amer,DC=dell,DC=com], will use associated map
>>
>>
>>> You asked:
>>> Can you send logs for a single lookup of "id username" with
tokengroups enabled?
>>>
>>> Attached are the logs. sssd_amer.dell.com.log and sssd_nss.log, for this
lookup:
>>>
>>> [root@spikerealmd02 sssd]# id admpatrick_wheeler
>>> uid=2604370(admpatrick_wheeler) gid=2604370(admpatrick_wheeler)
groups=2604370(admpatrick_wheeler),1010(amerunixusers)
>>>
>>> This is with ldap_use_tokengroups = True, so the above lookup is incorrect.
>>>
>>> What it should show is:
>>> id admpatrick_wheeler
>>> uid=2604370(admpatrick_wheeler) gid=2604370(admpatrick_wheeler)
groups=2604370(admpatrick_wheeler),1033(amer_server_mgmt),1003(amerlinuxsup),1010(amerunixusers)
>>>
>>> You asked:
>>> Why do you disable the subdomains provider? Isn't it easier to just
list
>>> the domains you want to enable using the ad_enabled_domains option?
>>>
>>> btw this can actually cause issues because the subdomains provider is
>>> needed to fetch the joined domain SID at least, among other things.
>>>
>>> When I ran with:
>>> ad_enabled_domains =
amer.dell.com,
apac.dell.com,
emea.dell.com,
japn.dell.com,
dell.com
>>>
>>> it broke cross-subdomain authentication. that is, I could resolve accounts
from the local domain (AMER), but not from any other domain (like apac). When I reviewed
the logs, I saw the sssd_nss.log would do a dispatch to the
apac.dell.com child, but the
dispatch would always fail.
>>>
>>> In sssd_apac.dell.com.log -- the dispatch was never picked up.
>> Interesting, do you still have the logs around?
>>
>>> I also noticed that sssctl domain-list gave me this:
>>>
amer.dell.com
>>>
apac.dell.com
>>>
emea.dell.com
>>>
japn.dell.com
>>>
dell.com
>>>
amer.dell.com
>>>
apac.dell.com
>>>
emea.dell.com
>>>
japn.dell.com
>> Including the duplicate domains? That sounds like a bug..
>>
>>> I suspect that sssd_nss was attempting to dispatch into this
apac.dell.com
"ghost" domain and failing. When I removed ad_enabled_domains (& commented
out
dell.com as a domain), I noticed sssctl domain-list gave me the expected:
>>>
>>>
amer.dell.com
>>>
apac.dell.com
>>>
emea.dell.com
>>>
japn.dell.com
>>>
>>> And cross-subdomain authentication worked (modulo this tokengroups problem
where not all groups show up when tokengroups == True).
>>>
>>> You stated:
>>>> ldap_schema = rfc2307bis
>>> Please don't set ldap_schema to anything else than 'ad' (the
default) with id_provider=ad.
>>>
>>> Unfortunately, our erstwhile AD administrators when they extended our AD
schema years ago did not use an rfc2307 schema extension. They used a rfc2307bis schema
extension instead.
>>>
>>> I had fits with even basic sssd AD integration until I realized this. (I
thought I was going to have to manually set up ldap_filters for the few quirky LDAP
attributes associated with an account, but then I realized this conformed 100% to
rfc2307bis.) When I set ldap_schema to rfc2307bis, the basic (same domain) authentication
worked (without tokengroups).
>>>
>> I meant something else. Internally in SSSD, ldap_schema=ad is a superset of
rfc2307bis with some defaults tuned to be AD-specific. And the AD provider really does not
expect the schema to be set to anything else, moreover there are some branches in the
underlying LDAP provider (the AD provider is a wrapper around the LDAP provider more or
less) that check if the schema is set to “ad” to follow some AD specific branch.
>>
>>> Spike
>>>
>>> On Tue, Jul 10, 2018 at 9:59 AM Jakub Hrozek<jhrozek(a)redhat.com>
wrote:
>>> On Mon, Jul 09, 2018 at 03:11:38PM -0500, Spike White wrote:
>>>> All,
>>>>
>>>> Below is a writeup of missing AD groups for accounts when using
>>>> tokengroups. When not using tokengroups, sssd is rock solid.
>>>>
>>>> Yes, most of the missing AD groups are universal or global groups -- but
>>>> not all! For some accounts, even domain-local AD groups are missed from
>>>> their group memberships. (when using tokengroups).
>>> [...]
>>>
>>>> tokengroups-disabled SSSD:
>>>>
>>>> uid=2604370(admpatrick_wheeler) gid=2604370(admpatrick_wheeler)
>>>>
groups=2604370(admpatrick_wheeler),1033(amer_server_mgmt),1010(amerunixusers),1003(amerlinuxsup),1156(gbl_server_support),2284161(amerserveradministrator),2283573(dfs_gil_sit_auth),2283577(delta_bd_create_emea),2283643(gebs_read_prd),2283611(xxgl0370_prod),2283578(delta_bd_create),2283256(infa_developer),2283623(xxgl0363_prod),2283615(xxgl0503_prod),2283607(xxpa2891_prod),2283869(cowcprodsupport)
>>>>
>>>>
>>>>
>>>> vas:
>>>>
>>>> uid=2604370(admpatrick_wheeler) gid=2604370(admpatrick_wheeler)
>>>> groups=2604370(admpatrick_wheeler),
>>>> 1033(amer_server_mgmt),1003(amerlinuxsup),1010(amerunixusers)
>>>>
>>>>
>>>>
>>>> diff is:
>>>>
>>>> 1033(amer_server_mgmt)
>>>>
>>>> 1003(amerlinuxsup)
>>>>
>>>>
>>>>
>>>> amer_server_mgmt is an AMER global group with GID 1033. <--- why is
sssd
>>>> not reporting this?!?
>>> Can you send logs for a single lookup of "id username" with
tokengroups
>>> enabled?
>>>
>>>> amerlinuxsup is an AMER universal group with GID 1003.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Here is my /etc/sssd/sssd.conf file:
>>>>
>>>> [nss]
>>>> debug_level = 9
>>>> filter_groups = root
>>>> filter_users = root
>>>> #entry_cache_timeout = 300
>>>> entry_cache_nowait_percentage = 75
>>>>
>>>> [sssd]
>>>> debug_level = 6
>>>> #domains =
amer.dell.com,apac.dell.com,emea.dell.com,japn.dell.com,dell.com
>>>> domains =
amer.dell.com,apac.dell.com,emea.dell.com,japn.dell.com
>>>> # Unnecessary. If missing, will search in order specified in
"domains"
>>>> lines above.
>>>> #domain_resolution_order =
amer.dell.com,
emea.dell.com,
apac.dell.com,
>>>>
japn.dell.com,
dell.com
>>>> config_file_version = 2
>>>> services = nss,pam
>>>> reconnection_retries = 3
>>>> #ldap_user_member_of = member
>>>>
>>>> [pam]
>>>> pam_verbosity = 3
>>>> debug_level = 9
>>>>
>>>> [
domain/amer.dell.com]
>>>> debug_level = 9
>>>> id_provider = ad
>>>> access_provider = simple
>>>> #access_provider = ad
>>>> auth_provider = ad
>>>> ad_domain =
amer.dell.com
>>>> krb5_realm =
AMER.DELL.COM
>>>> default_shell = /bin/bash
>>>> #use_fully_qualified_names = False
>>>> ldap_id_mapping = False
>>>> subdomains_provider = none
>>> Why do you disable the subdomains provider? Isn't it easier to just list
>>> the domains you want to enable using the ad_enabled_domains option?
>>>
>>> btw this can actually cause issues because the subdomains provider is
>>> needed to fetch the joined domain SID at least, among other things.
>>>
>>> I would change this to:
>>> ad_enabled_domains =
amer.dell.com
>>>
>>>> auto_private_groups = True
>>>> realmd_tags = joined-with-adcli
>>>> cache_credentials = True
>>>> krb5_store_password_if_offline = True
>>>> fallback_homedir = /home/%u
>>>> ldap_schema = rfc2307bis
>>> Please don't set ldap_schema to anything else than 'ad' (the
default)
>>> with id_provider=ad. We should probably just disallow changing the
>>> schema in the code completely.
>>>
>>>> ldap_sasl_authid =host/spikerealmd02.us.dell.com(a)AMER.DELL.COM
>>>> #ldap_sasl_authid =SPIKEREALMD02$(a)AMER.DELL.COM
>>>> #ldap_sasl_authid =spikerealmd02(a)AMER.DELL.COM
>>>> #TEST REMOVAL. July 4 2018. SW
>>>> #ad_enabled_domains =
amer.dell.com,apac.dell.com,emea.dell.com,
>>>>
japn.dell.com,dell.com
>>>> dyndns_update = False
>>>> # TEST -- commented out July 4 to not use tokengroups.
>>>> ldap_use_tokengroups = False
>>>> simple_allow_groups
=amerlinuxsup@AMER.DELL.COM,amerlinuxeng(a)AMER.DELL.COM,
>>>> emealinuxsup(a)EMEA.DELL.COM, AMER.DELL.COM,emealinuxeng(a)EMEA.DELL.COM,
>>>> apaclinuxsup@EMEA.DELL.COM,apaclinuxeng(a)EMEA.DELL.COM
>>>>
>>>> # also look at
>>>>
https://lists.fedorahosted.org/pipermail/sssd-users/2015-February/002648....
>>>>
>>>> [
domain/apac.dell.com]
>>>> debug_level = 9
>>>> auto_private_groups = True
>>>> #use_fully_qualified_names = False
>>>> ad_domain =
apac.dell.com
>>>> krb5_realm =
APAC.DELL.COM
>>>> cache_credentials = True
>>>> id_provider = ad
>>>> auth_provider = ad
>>>> krb5_store_password_if_offline = True
>>>> default_shell = /bin/bash
>>>> ldap_id_mapping = False
>>>> fallback_homedir = /home/%u
>>>> access_provider = simple
>>>> ldap_schema = rfc2307bis
>>>> ldap_sasl_authid =host/spikerealmd02.us.dell.com(a)AMER.DELL.COM
>>>> #ldap_sasl_authid =SPIKEREALMD02$(a)AMER.DELL.COM
>>>> #ldap_sasl_authid =spikerealmd02(a)AMER.DELL.COM
>>>> #TEST REMOVAL. July 4 2018. SW
>>>> #ad_enabled_domains =
amer.dell.com,
apac.dell.com,
apac.dell.com,
>>>>
japn.dell.com,
dell.com
>>>> dyndns_update = False
>>>> subdomains_provider = none
>>>> # TEST -- commented out July 4 to not use tokengroups.
>>>> ldap_use_tokengroups = False
>>>> simple_allow_groups
=apaclinuxsup@APAC.DELL.COM,apaclinuxeng(a)APAC.DELL.COM
>>>>
>>>> [
domain/emea.dell.com]
>>>> debug_level = 9
>>>> auto_private_groups = True
>>>> #use_fully_qualified_names = False
>>>> ad_domain =
emea.dell.com
>>>> krb5_realm =
EMEA.DELL.COM
>>>> cache_credentials = True
>>>> id_provider = ad
>>>> auth_provider = ad
>>>> krb5_store_password_if_offline = True
>>>> default_shell = /bin/bash
>>>> ldap_id_mapping = False
>>>> fallback_homedir = /home/%u
>>>> access_provider = simple
>>>> ldap_schema = rfc2307bis
>>>> ldap_sasl_authid =host/spikerealmd02.us.dell.com(a)AMER.DELL.COM
>>>> #ldap_sasl_authid =SPIKEREALMD02$(a)AMER.DELL.COM
>>>> #ldap_sasl_authid =spikerealmd02(a)AMER.DELL.COM
>>>> #TEST REMOVAL. July 4 2018. SW
>>>> #ad_enabled_domains =
amer.dell.com,
apac.dell.com,
emea.dell.com,
>>>>
japn.dell.com,
dell.com
>>>> dyndns_update = False
>>>> subdomains_provider = none
>>>> # TEST -- commented out July 4 to not use tokengroups.
>>>> ldap_use_tokengroups = False
>>>> simple_allow_groups
=emealinuxsup@EMEA.DELL.COM,emealinuxeng(a)EMEA.DELL.COM
>>>>
>>>> [
domain/japn.dell.com]
>>>> debug_level = 9
>>>> auto_private_groups = True
>>>> #use_fully_qualified_names = False
>>>> ad_domain =
japn.dell.com
>>>> krb5_realm =
JAPN.DELL.COM
>>>> cache_credentials = True
>>>> id_provider = ad
>>>> auth_provider = ad
>>>> krb5_store_password_if_offline = True
>>>> default_shell = /bin/bash
>>>> ldap_id_mapping = False
>>>> fallback_homedir = /home/%u
>>>> access_provider = simple
>>>> ldap_schema = rfc2307bis
>>>> ldap_sasl_authid =host/spikerealmd02.us.dell.com(a)AMER.DELL.COM
>>>> #ldap_sasl_authid =SPIKEREALMD02$(a)AMER.DELL.COM
>>>> #ldap_sasl_authid =spikerealmd02(a)AMER.DELL.COM
>>>> #TEST REMOVAL. July 4 2018. SW
>>>> #ad_enabled_domains =
amer.dell.com,
apac.dell.com,
japn.dell.com,
>>>>
japn.dell.com,
dell.com
>>>> dyndns_update = False
>>>> subdomains_provider = none
>>>> # TEST -- commented out July 4 to not use tokengroups.
>>>> ldap_use_tokengroups = False
>>>> simple_allow_groups
=japnlinuxsup@JAPN.DELL.COM,japnlinuxeng(a)JAPN.DELL.COM
>>>> _______________________________________________
>>>> sssd-users mailing list --sssd-users(a)lists.fedorahosted.org
>>>> To unsubscribe send an email tosssd-users-leave(a)lists.fedorahosted.org
>>>> Fedora Code of
Conduct:https://getfedora.org/code-of-conduct.html
>>>> List
Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines
>>>> List
Archives:https://lists.fedoraproject.org/archives/list/sssd-users@lists.f...
>>> _______________________________________________
>>> sssd-users mailing list --sssd-users(a)lists.fedorahosted.org
>>> To unsubscribe send an email tosssd-users-leave(a)lists.fedorahosted.org
>>> Fedora Code of
Conduct:https://getfedora.org/code-of-conduct.html
>>> List
Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines
>>> List
Archives:https://lists.fedoraproject.org/archives/list/sssd-users@lists.f...
>>>
<sssd_amer.dell.com.log><sssd_nss.log>_______________________________________________
>>> sssd-users mailing list --sssd-users(a)lists.fedorahosted.org
>>> To unsubscribe send an email tosssd-users-leave(a)lists.fedorahosted.org
>>> Fedora Code of
Conduct:https://getfedora.org/code-of-conduct.html
>>> List
Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines
>>> List
Archives:https://lists.fedoraproject.org/archives/list/sssd-users@lists.f...
>> _______________________________________________
>> sssd-users mailing list --sssd-users(a)lists.fedorahosted.org
>> To unsubscribe send an email tosssd-users-leave(a)lists.fedorahosted.org
>> Fedora Code of
Conduct:https://getfedora.org/code-of-conduct.html
>> List
Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List
Archives:https://lists.fedoraproject.org/archives/list/sssd-users@lists.f...
>> _______________________________________________
>> sssd-users mailing list --sssd-users(a)lists.fedorahosted.org
>> To unsubscribe send an email tosssd-users-leave(a)lists.fedorahosted.org
>> Fedora Code of
Conduct:https://getfedora.org/code-of-conduct.html
>> List
Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List
Archives:https://lists.fedoraproject.org/archives/list/sssd-users@lists.f...
> _______________________________________________
> sssd-users mailing list --sssd-users(a)lists.fedorahosted.org
> To unsubscribe send an email tosssd-users-leave(a)lists.fedorahosted.org
> Fedora Code of
Conduct:https://getfedora.org/code-of-conduct.html
> List
Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines
> List
Archives:https://lists.fedoraproject.org/archives/list/sssd-users@lists.f...
>