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 <
[email protected]> 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
> <[email protected]> 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 | [email protected] | 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 -- [email protected]
> > To unsubscribe send an email to [email protected]
> > 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/[email protected]
> > Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
> --
> _______________________________________________
> sssd-users mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> 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/[email protected]
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
--
_______________________________________________
sssd-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
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/[email protected]
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
