sssd 1.16.5 gives no results for other domains in the AD Forest
by Bill Conn
I'm working on a university's research cluster with nodes that all run CentOS7 and are joined to the school's Active Directory domain. Our domain is part of a statewide forest that contains every state university, and we have used this arrangement to grant cluster access to users from other Universities to our cluster.
Recently, a user from outside my Universities domain have said they cannot log in anymore which caused me to look into this issue. I found that if I issue an id command for a user in a different domain in the forest, it gives me the error "no such user". I know that our setup used to work, and after looking into it and trying to replicate the old and new behavior I found out that CentOS7 machines with sssd 1.16.4 can get results from other domains in the forest, but machines with 1.16.5 cannot.
Is there some setting that changed between these minor versions that would cause this? Is it possible this is not caused by sssd? I'm testing a node with CentOS 7.9.2009 which doesn't return other domains in the forest and a node with CentOS 7.7.1908 which does return results from other domains.
1 year, 2 months
Access report not implemented for domains of type ad...
by Spike White
Occasionally some of our app teams work with external auditors that wish to
verify proper login access to servers.
In our older commercial AD integration tool, they'd just run an "access
report" which would provide all desired information. I got hit up today to
run an access report for sssd-enabled prod servers.
I saw with great interest the "sssctl access-report" command.
# sssctl access-report amer.company.com
Access report not implemented for domains of type ad
Any plans to implement this access-report subcommand for domains of type
No urgency; you can get most of what's needed via
sssctl user-checks <user>
1 year, 3 months
Copying files with AD gid
by Michael Barkdoll
I used to copy and extract files to a RHEL node with ansible setting the
gid of the files to a future gid that would exist after joining AD.
However, that has stopped working. The only workaround that I've found is
to join AD then change the gid. Are there any other methods that allow me
to `chown root:176780xxxx file` without having joined AD? I tried with
ACLs but that wouldn't work for me as well.
1 year, 3 months
sssd performance on large domains
I'm wondering if there are any plans to improve sssd performance on large active directory domains (100k+ users, 40k+ groups), or if there are settings I am not aware of that can greatly improve performance, specifically for workstation use cases.
Currently if I do not set "ignore_group_members = True" in sssd.conf, logins can take upwards of 6 minutes and "sssd_be" will max the CPU for up to 20 minutes after logon, which makes it a non-starter. The reason I want to allow group members to be seen is that I want certain domain groups to be able to perform elevated actions using polkit. If I ignore group members, polkit reports that the group is empty and so no one can elevate in the graphical environment.
Ultimately this means that Linux workstations are at a severe disadvantage since they cannot be bound to the domain and have the normal set of access features users and IT expect from macOS or Windows.
Distributions used: Ubuntu 16.04 (sssd 1.13.4-1ubuntu1.1), Ubuntu 16.10 (sssd 1.13.4-3) and Fedora 24 (sssd-1.13.4-3.fc24). All exhibit the same problems.
I've also tried "ldap_group_nesting_level = 1" without seeing any noticeable improvement with respect to performance. Putting the database on /tmp isn't viable as these are workstations that will reboot semi-frequently, and I don't believe this is an I/O bound performance issue anyways.
Thanks for your time.
1 year, 4 months