SSSD local overrides

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

Let’s consider our domain has a user “tuser” that resolves with his UID and GID as defined on the server:
$ getent passwd tuser
tuser:*:1190000015:1190000015:test user:/home/tuser:/bin/sh
But on this particular host, we need this user to have a different IDs – maybe the user already owned some files before this host was added as a member to the domain. We can call the sss_override tool and assign him a different ID:
$ sudo sss_override user-add tuser -u 1234
SSSD needs to be restarted for the changes to take effect.
As the info message tells us, currently SSSD needs to be restarted when the first override is added in order for the overriden values to take effect. All subsequent overrides will take effect immediately.
$ sudo systemctl restart sssd
Now, let’s request the user again:
$ getent passwd tuser
tuser:*:1234:1190000015:test user:/home/tuser:/bin/sh
And the changes are visible now! Keep in mind that user-add always replaces the whole local override, so if we wanted to override this user’s name, too, the previous UID change would be lost:
$ sudo sss_override user-add tuser -n xuser
$ getent passwd xuser
xuser:*:1190000015:1190000015:test user:/home/tuser:/bin/sh
As you can see, only the login name was overriden, but the UID was reverted to the original value. This is because the -add command replaces the override completely. The correct way to override both values would be to specify both switches at the same time:
$ sudo sss_override user-add tuser -n xuser -u 1234
It’s possible to also override group attributes – at the moment, overriding group’s name or GID is supported. A very common use is to override a group ID, so let’s take a look:
$ 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

As explained earlier, the overrides are stored in the sssd cache itself. To provide some recovery mechanism for admins who sometimes need to purge the cache in order to reset the environment into clean state, we added import and export commands to the sss_override tool. With the example above, we can export the override for tuser with:
$ sudo sss_override user-export /var/log/sssd/user_overrides
This creates a passwd-like file that contains the override data:
$ sudo cat /var/log/sssd/user_overrides
 In case we decide to remove the cache, we can later add the override data back with:
$ 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.

The command sss_override user-find allows to find all overrides from all configured sssd domains:
$ sudo sss_override user-find
We can also direct the user-find command to a particular domain:
$ sudo sss_override user-find -d ipaldap
 Or, using the user-show command, even a particular user:
$ sss_override user-show tuser


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.

As an incremental improvement, the SSSD team is looking into ways of making the import and export more automated so that the danger of removing the database is mitigated by the SSSD tools.

3 thoughts on “SSSD local overrides

  1. 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 ?


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


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


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s