[SSSD-users]Re: Identical sssd.conf files give different results

[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