Using users from Active Directory through sssd to run servic or not
Hello Community,
Because I'm very new on the following topic, the title of this thread may sound a bit fishy. Please bear with me and ask if something is hard to understand.
My questions are related to the following example:
We integrated our RHEL 7systems to Active Directory using realmd and sssd following Chapter 2.5 and 3 in Windows Integration Guide.
We think about using the users from Active Directory to run services on our RHEL 7 hosts. But in case the host loses his connection to the domain controller and the local cache times out, the service would break. To avoid this we thought we could create an user account in Active Directory with uidNumber and gidNumber and then create a local system user with the same uid and gid. The user should exist in Active Directory to be able to check whether a specific user already exists or not. And in case it exists, to use the same uid and gid for the locally created user. This way we would avoid mixed up uids on file shares. But if a host is aware that a user account already exists in Active Directory it will prevent the creation of a local user with the same name. And at this point I am lost.
How do you manage situations described in the example above? Do you run your services with users from Active Directory or do you only use local system users? In the first case, how do you avoid that the service crashes when the host lost his connection to the domain controller? In the second case, how do you prevent multiple uid and gid for a user (e.g. Bob) on multiple systems?
Where could I find information to this topic? Are there any best practises?
Any help is appreciated.
Best regards,
Joerg
EDIT: Fixed some very bad typos.
Responses
This is going to be something you establish your own policy for in my opinion. If you are concerned about unique/consistent uid/gid across systems, by all means, make sure all accounts are managed by AD.
I don't think you should be overly concerned about lost host communication with AD and an expired cache. If you reach this point, you've got much more serious issues.
Hi Jorg,
This really depends on your customer/site requirements and I have implemented both (local/SSSD). As much as I like SSSD I do still have annoying issues with it from time to time where it 'plays up' (sssd_be hitting 100% CPU comes to mind) and can impact services so I prefer to use local accounts for system services that have no genuine requirement for using AD (which is actually many of the Linux services customers run). In many sites if AD goes down or SSSD has issues, these applications can continue uninterrupted.
When making these user accounts, we basically create an LDAP/AD record for the user with UID/GID (to 'reserve' it from use) and then make a local user with the same configuration as you have described. Make sure nsswitch is configured to check local ('files') first, and then the local account is referenced.
With regard to your issue of account creation, if you stop the SSSD service temporarily (so the AD users aren't returned by getent) you can then create the local user account with the same details.
I know some may raise an issue with this approach because of multiple sources of truth, and I doubt many others would (academically) recommend this approach, but practically I have used it several times and haven't had any issues (yet). Once thing I should point out though is that these accounts that run the service have locked passwords and don't provide interactive login. I don't suggest using this approach if the account uses password based authentication because you will then have issues between local/central password rules, aging, resets etc.
Forgot to address this one
In the second case, how do you prevent multiple uid and gid for a user (e.g. Bob) on multiple systems?
I generally manage this through Puppet manifests/profiles for the applications. ie. required user accounts to support the application are configured in the application module in Puppet. This is a clean (and version controlled / centrally managed) method for managing users across multiple servers for networks/servers that may not have AD/directory connectivity.
The added benefit is that the local user account is only created if the related application profile is applied to that server.
Expert
1228 points
Thank your for your replies.
@Mike: I'm sure we need our own policy. While working on that part I'd like to learn from experiences other admins already made. Integrating RHEL directly in AD without any Idm, FreeIPA or other LDAP between them seems not so common, yet.
@PixelDrift.NET Support: As it seems you are managing services and users in the same way as we currently do. So I'm not the only one who keep things running like that.
RHEL is a new operating system in our environment. So we still figure out some of the basics and learn how to get around with RHEL. In addition to a new operating system I indroduced Ansible as configuration and orchestration management system. With all new things, a few like it but some are sceptic. So the process works slow and it will need some time until some additional people get familiar with it.
Thanks again for your posts.
Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.