Customizing SSSD Behavior

Latest response

My customers currently use third-party tools for integrating RHEL systems with Active Directory. This is mostly a holdover from RHEL 5 days when winbind was the only "native" option for linking to AD. At the time they settled on the third-party tool, their directory was too large/complex for winbind to work reliably (even the third party tool's local cache can get blown up if you do overly-broad queries) - even before they changed AD to require an encryption-mode that the RHEL-shipped version of winbind didn't support.

At any rate, I'm trying to push them to using SSSD as they shift to RHEL 7 (since SSSD gets patched along with the OS but the third-party tools rarely, if ever, get updated due to lacking a equivalent update method to yum update.). Before I can do that, I need to see how "seamless" I can make the change for them. My primary stumbling blocks are:

  • "friendly" user names: I found use_fully_qualified_names option so that they can get the POSIX-y usernames that they prefer
  • "friendly" group names: all of the customer's scripts that leverage group names expect there to be no spaces in the group names. Does sssd.conf allow you to specify a separator-token that will convert space-containing group-names into something more like domain+users, domain^users, etc.? If so, what's the method for achieving this?
  • preferred home directory path-names: while switching to override_homedir = /home/%d/%u gets me close, what my customer currently has is /home/SHORTDOM/USER. I'm not finding anything that gives me this. I'd tried %D in hopes that it was an undocumented method for getting the short domain. Alors, it was not to be. Is there a method for getting me this type of formatting (if so, what is it)?

Side note: the realm command doesn't seem to offer a good method for automating tasks related domain-join and behavior configuration:

  • Doing echo AUTHSTRING | realm join --user=SVCACCOUNT FULL.DOMAIN.NAME works, it strikes me as a skosh clumsy.
  • It seems like updating SSSD behaviors needs to be done by editing/distribution of files rather than being able to execute scriptable-commands that gracefully handle the config updates: am I missing something?

Responses