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.
You asked:
Can you send logs for a single lookup of "id username" with tokengroups
enabled?
Last week, I attached the logs. for one specific lookup. Even though I
severely trimmed the logs, it exceeded the max file size for this mailing
list.
It was the 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.
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
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).
_______________________________________________
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@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.fedorahosted.org/message/IYWWAOUC4CCQA2ZU7OMEDAHFIYXD2ZSL/
