That is an excellent point. 

We have a lot of lab AD domains that trust the main AD domain, but the main domain doesn't trust them (nor should it).  So it's a one-way trust -- from the lab domain to the main domain.

When sssd starts, it discovers all domains with a trust relationship with this main domain, regardless of which way the trust operates.  So it discovers all these lab domains.

We have to put in:
    ad_enabled_domains = <main AD domain>

to tell sssd: I don't care what funky lab domains you discovered -- don't use them.  

We still see these funky lab domains in 'sssctl domain-list', but they're not used.  So no harm (other than sysadmin confusion on output of 'sssctl domain-list').

Also, locking it to the same AD server is a great investigattive idea.  Very rarely, we notice subtle differences when interrogating different AD DCs.

Spike

On Wed, Mar 19, 2025 at 2:55 PM Justin Stephenson via sssd-users <sssd-users@lists.fedorahosted.org> wrote:
If you really want to be sure SSSD clients behaves the same then you
would also pin to a specific AD server with 'ad_server' domain option.
Just an idea but you may also want to set 'ad_enabled_domains' to
ignore any unexpected domains that may be auto-discovered. Otherwise
you would need to compare SSSD domain logs with a higher debug level
to investigate furhter.

-Justin

On Wed, Mar 19, 2025 at 2:50 PM Johnnie W Adams via sssd-users
<sssd-users@lists.fedorahosted.org> wrote:
>
> Hi, folks,
>
>      I'm using this as my sssd.conf file:
>
> [sssd]
>
> domains = ad.example.com
>
> config_file_version = 2
>
> services = nss, pam
>
> [domain/ad.ualr.edu]
>
> ad_domain = ad.example.com
>
> krb5_realm = AD.EXAMPLE.COM
>
> realmd_tags = manages-system joined-with-adcli
>
> cache_credentials = True
>
> id_provider = ad
>
> krb5_store_password_if_offline = True
>
> default_shell = /bin/bash
>
> ldap_id_mapping = False
>
> use_fully_qualified_names = False
>
> fallback_homedir = /home/%u
>
> access_provider = ad
>
> auto_private_groups = True
>
>
>      I'm getting diverging results with it. Most of my machines do the right thing:
>
> id jxadams
>
> uid=65566(jxadams) gid=65566(jxadams) groups=65566(jxadams),65594(banpasswd),65727(banner_prog_proxies),65567(banmaint),1001(admin)
>
>
>      There's one my boss set up without me, which was not doing the right thing, so I replaced the sssd.conf file with the above, cleared the cache, and restarted sssd. Now it's doing this:
>
> uid=65566(jxadams) gid=65566(jxadams) groups=65566(jxadams),1814547618,1814447055,1814489591,1814522221,1814522197,1814534074,1814547143,1814489528,1814575840,1814524368,1814545535,1814521335,1814533990,1814493193,1814526964,1814531543,1814542584,1814522208,1814522405,1814522232,1814522215,1814522206,1814534064,1814522217,1814525653,1814508146,1814575767,1814547146,1814541911,1814451780,1814522199,1814522211,1814522228,1814575772,1814451777,1814545429,1814531330,1814522210,1814522213,1814533967,1814521035,1814521034,1814534042,1814522195,1814522223,1814506989,1814529481,1814522203,1814522404,1814453699,1814522214,1814522406,1814529482,1814522229,1814522202,1814522231,1814591696,1814523473,1814534041,1814522212,1814522222,1814522230,1814522226,1814506197,1814522233,1814522220,1814522407,1814522205,1814542411,1814521900,1814522403,1814522227,1814455342,1814533962,1814477586,1814451778,1814489529,1814403146,1814522219,1814522200,1814522198,1814523950,1814522209,1814522225,1814526200,1814522194,1814455182,1814545523,1814539163,1814400513,1814403152,1814594762,1814403134,1814591695,1814441279,1814586992,1814486196,1814586996,1814531498
>
>
>      Which all may be meaningful in the AD world, but which is not relevant to our Linux nodes.
>
>      Why is the same conf file, running against the same AD instance, giving me two different results?
>
> Thanks,
>
>      John A
> --
> John Adams
> Senior Linux/Middleware Administrator  | Information Technology Services
> +1-501-916-3010 | jxadams@ualr.edu | http://ualr.edu/itservices
> UA Little Rock
>
> Reminder:  IT Services will never ask for your password over the phone or in an email. Always be suspicious of requests for personal information that come via email, even from known contacts.  For more information or to report suspicious email, visit IT Security.
>
> --
> _______________________________________________
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

--
_______________________________________________
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue