On Tue, 2012-04-03 at 16:54 +0300, Marko Myllynen wrote:
Hi,
>> users logging into a system to have different environment. And the case
>> where bash (and other shells) behave differently depending whether
>> invoked as /bin/bash or /bin/sh might be something administrators will
>> hit especially with subdomains as not all AD domains have UNIX
>> attributes enabled.
>>
>> It would help administrators if SSSD would provide a method to force a
>> shell to all users regardless of domain/libc/user configuration but
>> unfortunately the RFE requesting this functionality has been deferred
>> (#1087). Even though you could state that the shell users will get is
>> not of your concern, it is much of a concern for system administrators
>> and the subdomain_shell option would seem to be helpful with that regard.
>
> The reason we deferred 1087 is because we feel that if the user has a
> preferred shell set on the central server and the same shell is
> available on the client machine, then the user should be granted access
> to that shell on any machine they log into.
I agree that this is usually the case.
> We have the 'vetoed_shells'
> option in the event that a particular client machine wants to prevent a
> user from using a specific shell. Otherwise, if the administrator really
> wants to force users to use a particular shell, then the most expedient
> solution is to make that change to the central LDAP attribute, thus
> percolating it out to all machines trivially.
I'm not convinced that this would be trivial when you have AD subdomains
in play, some of those potentially without UNIX attributes enabled.
Cheers,
You make a good argument. I've pulled 1087 back into NEEDS_TRIAGE with
the recommendation that we should implement it as part of the AD
Provider effort I'm currently working on for SSSD 1.9.