[SSSD-users] Re: Setting alternative shell for members of group in AD child domain
On Mon, Jul 18, 2016 at 05:46:07AM +0000, Renfro, Michael wrote:
I've previously only used sssd in a much simpler situation, on a
single-domain AD forest with no additional complications. Now, I'm trying
to make it work with the following:
1. Forest (vvu.edu) with two domains (vvu.edu, the root domain) and
vae.vvu.edu (child domain), with the default two-way trust between the
domains. For reasons of Windows system management and user experience, I
can't easily break the domain trust or put all users in the root domain.
2. Linux system with sssd, preferably Debian or Ubuntu, tied to the child
domain. CentOS and RHEL may be a possibility later. I assume any working
version number of sssd will work identically on any platform.
3. As far as the Linux system is concerned, all user accounts in the root
domain are normal, unprivileged end-user accounts. These should get a
shell of /usr/bin/rssh.
4. The only user accounts in the child domain are for system
administrators. Accounts in the AD group 'server-admins' should get a
shell of /bin/bash.
I got hints from both
https://fedorahosted.org/sssd/wiki/DesignDocs/ActiveDirectoryAccessControl
and http://serverfault.com/a/577885 , but I'm stuck without a complete
solution.
So the tl;dr is that you want different shells for different accounts?
I can think of severak ways to accomplish this:
1) use sss_override and locally set the shell for those accounts.
See https://jhrozek.wordpress.com/2016/02/15/sssd-local-overrides/
But this requires a newer sssd and also would require to set the
shell per-account on all systems.
2) use IPA and ID-views. I'm not sure this is an option for you, but
I thought I'd bring it up for completeness.
3) put the shell into the POSIX attribute set on the server side.
But please note that the choice of ID-mapping or POSIX attributes is
all-or-nothing, so you can't have ID-mapped UIDs and shell read from
the server.
3) Create separate SSSD domains in your config and set the
override_shell parameter locally. This is what you did, but I think
the difference is that the trusted domain is auto-discovered, so the
settings from the 'parent' domain apply. Can you try with
subdomain_provider=none and manually setting the
ldap_idmap_default_domain_sid (should not be required with 1.14.1..)
?
A simpler test might be to only define the 'trusted' domain section
with the correct shell override, clear the caches and see if all
accounts get the 'trusted shell' then.