Identical sssd.conf files give different results

[Johnnie W Adams]

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

[Justin Stephenson]

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
 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
> [phone] | [e-mail] | 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail].o...
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[Spike White]

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

[Johnnie W Adams]

Hi,

The suggestion of using a specific AD server isn't practical in our
environment, as our AD servers are behind a load balancer. There are no
other domains being discovered.

Thanks,

John A

On Wed, Mar 19, 2025 at 2:37 PM Justin Stephenson 
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
>  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
> > [phone] | [e-mail] | 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 -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> > 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/[e-mail].o...
> > Do not reply to spam, report it:
>
> https://pagure.io/fedora-infrastructure/new_issue

[Gregory Carter]

Change Authorization and Management rigor can usually address these sorts
of issues.

To test SAMBA deployments at work, I don't allow admin access to the
production machines unless it is through gitlab push/ansible update.

Before a rpm update or a config change I spin up a samba server for testing
the change before issuing it to the production cluster. So I have a KVM
network designed for testing that is on a different software defined
network, so I can test Workstation effects (i.e. Windows 11 Login
Issues....which was our latest problem changing its cipher lists.) That was
easy to fix as we just issue a new samba update package 4.21.4.

The point is we caught this update issue with Windows 11 and found out
specifically what was required to make the change so people could login
with the latest Microsoft patches. We also have a complete record in
ansible and gitlab logs what exactly was changed and if required reverse it
on any procedures on a critical server.

So to do that I normally have a samba-test, samba-production in gitlab,
with SOP for everything else we have to manage which normally is in a rpm
package from redhat, otherwise we  use Ansible recipt to handle the tarball
whatever that maybe and make a suitable commit in gitlab.

I put the rpm playbook for the upgrade I previously tested on the VM's and
moved it to production branch in gitlab samba-production to push out to
ansible. Then schedule the ansible push with management.

That way you always have complete records of change on your machines.

If you haven't considered doing that, I urge you to try it!

The most complex part of setting this up is the omnibus gitlab package and
Email notifications this stuff I describe above is the easy part actually.

On Wed, Mar 19, 2025 at 12:25 PM Johnnie W Adams via sssd-users <
[e-mail]> 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
> [phone] | [e-mail] | 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
> http://ualr.edu/itservices/security/.
>
> sssd-users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail].o...
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue