Written by Pavel Březina and Jakub Hrozek
In most cases, using the SSSD is all about connecting a client machine to a central user database, like FreeIPA or Active Directory precisely because you want all users on all machines across the domain to have exactly the same properties. However, even though it would be best to centralize all the things, there will always be exceptions. There can be an odd legacy server where a particular user has a UID set to a value that predates the migration to a central domain controller. Or you might administer a machine where a user stores her files in a different home directory than any other machines.
If the client is a member of an FreeIPA domain, you can just define an “ID view” and define the custom values centrally on the IPA server. Using ID views is the recommended way of setting any overriden attributes – however, not all environments use a FreeIPA server..
To solve those use-cases, the SSSD provides a command-line tool that allows the administrator to set one or more POSIX attributes to a different value on that particular system. The tool is called sss_override and is part of the sssd-tools package since version 1.13.1. Running sss_override --help would present the user with a list of available sub-commands. We’ll show some examples of using them later in this text. Please note that the local overrides can not be used in combination with IPA provider. Instead, the server side overrides can be defined directly through IPA web or command line interface.
One very important aspect to keep in mind is that the overrides are stored in the cache, along with the data from the directory server. This conflicts with a very commonly used practice among admins who often remove the database and try to start from a clean cache when they encounter any problems with sssd. Therefore it is necessary to manually export the override data prior deleting the cache and import them again later, otherwise the override data would be lost!
Creating user and group overrides
$ getent passwd tuser
tuser:*:1190000015:1190000015:test user:/home/tuser:/bin/sh
$ sudo sss_override user-add tuser -u 1234
SSSD needs to be restarted for the changes to take effect.
$ sudo systemctl restart sssd
$ getent passwd tuser tuser:*:1234:1190000015:test user:/home/tuser:/bin/sh
$ sudo sss_override user-add tuser -n xuser
$ getent passwd xuser
xuser:*:1190000015:1190000015:test user:/home/tuser:/bin/sh
$ sudo sss_override user-add tuser -n xuser -u 1234
$ id tuser uid=1190000015(tuser) gid=1190000015(tuser) groups=1190000015(tuser),1190000016(tgroup)
$ sudo sss_override group-add tgroup -g 5555
$ id tuser uid=1190000015(tuser) gid=1190000015(tuser) groups=1190000015(tuser),5555(tgroup)
Import and export
$ sudo sss_override user-export /var/log/sssd/user_overrides
$ sudo cat /var/log/sssd/user_overrides
tuser@ipaldap:xuser:1234::::
$ sudo sss_override user-import /var/log/sssd/user_overrides
Listing
To see what overrides are actually configured on the system, you can use sss_override commands user-find, user-show, group-find and group-show.
$ sudo sss_override user-find
tuser@ipaldap:xuser:1234::::
admin@anotherdomain:administrator:4321::::
$ sudo sss_override user-find -d ipaldap
tuser@ipaldap:xuser:1234::::
$ sss_override user-show tuser
tuser@ipaldap:xuser:1234::::
Conclusion
The local overrides are a powerful mechanism to deal with irregularities in an otherwise centralized environment. That said, using a completely centralized solution, like IPA’s idviews feature avoids issues with keeping the overrides in the cache itself as well as provides a unified view of all overrides in the UI.
Hi,
im having inconsistent results with sss_override. from time to time user would resolve ID provided by AD instead from sss_override. which i causing problems accessing files. how can fix this?
initially when i started working on single sing on with AD i created POSIX UID for users in AD. however that would require to enable that for every user. in addition AD groups without GID wouldnt resolve. so i switched from ldap to AD as provider with user id mapping enabled. which works great accept for few user that already had uids assigned and mapped in netapp and changing ownership on all files in our storage would be painful process.
sss_overrirde works greats when it works… what would be your suggestion here? how can i make sss_override consistent ?
LikeLike
So, this is a bug, known upstream and in RHEL, but we haven’t fixed it only because it’s been really hard for us (so far impossible) to reproduce the bug locally. The only suggestion one of my colleagues had was that people who seemed to have hit this bug have had a user and a group with the same name and only one of those had an override.
So if you could help me understand how can I reproduce the bug so I can fix it, I’ll be glad to help..
LikeLike
I get this bug on multiple machines / versions. I’m working with team to setup vm environment with AD similar to ours and redhat clients. once we reproduce this i will let you know. maybe i will be able to upload those vm’s to you.
meanwhile if there is anything else i could do please reach out: michal.dudzinski [@] gmail com
LikeLike