-----BEGIN PGP SIGNED MESSAGE-----
On 02/21/2014 04:46 AM, Sumit Bose wrote:
On Thu, Feb 20, 2014 at 10:22:53PM +0100, Jakub Hrozek wrote:
> On Thu, Feb 20, 2014 at 04:13:51PM -0500, Simo Sorce wrote:
>> On Thu, 2014-02-20 at 16:01 -0500, Stephen Gallagher wrote:
>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>> On 02/20/2014 03:37 PM, John P Arends wrote:
>>>> I’m new to SSSD in general. I configured a RHEL 6.5
>>>> machines to authenticate against a 2008 R2 AD using
>>>> ldap_id_mapping because our AD does not have unix
>>>> information defined for users. All appears to be working
>>>> well. I had to add override_homedir = /home/%u to get home
>>>> directories to to be created by oddjob mkhomedir.
>>>> The only problem is the group ownership on the home
>>>> directory is “domain users” rather than the user’s private
>>>> group. The default permissions also allow domain users
>>>> read/execute access to the home directory.
>>>> It looks like you can change the umask used in
>>>> /etc/pam.d/system-auth-ac, but I don’t see where I can
>>>> control the group information. Any suggestions on best
>>>> practices on how to fix this? I was surprised it wasn’t in
>>>> the docs.
>>> "Domain Users" most likely *is* the user's primary group. By
>>> default, Active Directory doesn't create user-private groups.
>>> If you run 'id username', you should see "gid=XXX(domain
>>> users)" which is telling you what the default group is.
>>> You will want to change this on the Active Directory side, or
>>> else use a umask on the RHEL system to set the created
>>> directories as not readable by the group members. See
>>> /etc/oddjobd.conf.d/oddjobd-mkhomedir.conf for details. You
>>> can modify the '-u' option to the mkhomedir call to do this.
>> Didn't we discuss a while a go to add a feature to sssd so that
>> it would create local private groups for AD users instead of
>> using 'Domain Users' a the primary gid ?
>> The idea was to painlessly handle exactly these kind of
>> problems. Simo.
> I vaguely remember discussing something along the lines of "it
> would be nice to do..sometimes.." on one of our weekly meetings
> but there was never a trac ticket or a design.
I guess we have done it the way it currently is to be compatible
with other solution, but I think it is a good idea to add an
boolean option like ad_use_user_private_groups.
John, would you like to file an RFE at
It's worth noting that, because of the way SIDs work in AD, if we're
using ID-mapping, it's safe for us to create an MPG with the same GID
as the UID, since they will never overlap in AD.
However, if we're *not* using ID-mapping, this wouldn't be safe, since
the various GIDs on the system are specified manually and could
overlap. So I'd make this an ID-mapping only option.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
-----END PGP SIGNATURE-----