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

Hi,

Your questions are very valid and I am not sure there are good answers yet.

Out of interest, what problem do you have with space-separated AD groups?

I run significant environment where space-separated names of AD groups work well with /etc/security/access.conf and /etc/sudoers. On systems that need special access like IBM MQ, when we enable SSSD enumeration, it works well too.

Regards,

Dusan Baljevic

Mostly an "existing toolsets" issue. Some of my customer's groups used Centrify (which used a + substitution in AD object-names) and some/most used PBIS (which used a ^ substitution in AD object-names) . If objects' logical names change due to migration to SSSD, they have to update their scripts. Customers always favor the incumbent solution - even if you're trading for-fee for "included". To overcome that, I need to make the transition as close to invisible as possible. Otherwise, they'll simply say "no, we're not gonna do SSSD" and fall back on the incumbent solution.

What about realm's one-time-password option? It requires some up-front work from your AD admin, but makes automating the domain join pretty simple.

I'd looked at the keytab file options, but it was more hassle than it was worth. Overall, I'm looking to engage my AD folks as little as possible as they are not super-instructable on specific technical needs.

Close

Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.