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
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::::
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.