AD integration GID/UID management

Latest response

I am brand-new to RHEL, coming from a Windows-driven environment. I'm first looking to deploy a WordPress-enabled intranet site for our company with MS AD-integrated permissions, and so am looking to setup my first RHEL server to use AD logons, I've setup my RHEL server as a AD member via the SSSD configuration (no problem there), and have the settings placed to read GID/UID info from AD.

And there's the stop, after finding that going forward (when/if I implement Server 2016), I'll need to manage GIDs/UIDs myself as the old MS-supported methods for this have been deprecated.

So I'm using Powershell to script this management. Three parts:
1. Group GIDs. Read all existing GIDs, get the maximum GID present. Then add GIDs to groups without them, incrementing from the current max GID.
2. User UIDs. Read all existing UIDs, get the maximum UID present. Then add UIDs to users without them, incrementing from the current max UID.
3. Read User accounts again, getting their Primary Group and its GID, and setting each user accounts GID to be their Primary Group's GID.

My questions to you:
1. If I begin at GID/UID 1000000, so you see any issues with numbering?
2. Are there any oversights/gotchas to this plan?

Responses

Hi Karl,

If you do a fresh start with RHEL as an AD member you might want to consider using automatic id mapping. Then you do not have to set all UIDs/GIDs by yourself.

See Chapter 2. Using Active Directory as an Identity Provider for SSSD in the Windows Integration Guide for further information.

I'll need to manage GIDs/UIDs myself as the old MS-supported methods for this have been deprecated.

What exactly do you mean with "the old MS-supported methods"? Do you mean setting UID and GID via the Attribute-Editor in AD console or something else?

Kind regards, Joerg

Hi Jörg,

Thank you for your response. I was attempting 2.1.1 "To use POSIX attributes defined in AD" rather than having SSSD create the mapping from the AD SID directly. Referencing 2.1.3, I see that the Identity Management for UNIX has been deprecated. Also, MS deprecated NIS: https://blogs.technet.microsoft.com/activedirectoryua/2016/02/09/identity-management-for-unix-idmu-is-deprecated-in-windows-server/.

2.1.3 references https://access.redhat.com/articles/2203991, which mentions that RHEL can no longer manage UID/GID directly in AD.

All of this is what leads me to believe that if I want RHEL to read GIDs/UIDs from AD, I'll have to separately create and manage these attributes directly in AD and outside RHEL.

Windows Server has also dropped support for the management of the AD elements through the UI, but the extended attributes in AD (UID,GID,home,shell) can still be enabled/used.

I prefer to implement with the attributes stored in AD so it is the single point of truth. When you are using calculated/generated UID/GID on the RHEL side it makes querying the values from systems outside the Linux servers more difficult (ie. not a basic LDAP call).

The approach for starting numbering at a point will work, I personally use 10,000 when implementing and restrict local accounts on servers to use UIDs below this. The other thing you need to consider is that if administrators add local users on your servers (ie. adduser) after you are connected to your AD provider, the new user UID will increment from the highest UID it can see from the directory which will start causing collisions. I work around this by specifying the following in login.defs on the RHEL servers.

UID_MIN    9000
UID_MAX    9999
GID_MIN    9000
GID_MAX    9999

This ensures that locally generated (non-system) user accounts don't end up colliding with users/groups in the directory.

How you implement these local accounts is really up to your own policies.

I prefer to implement with the attributes stored in AD so it is the single point of truth.

Same here. We calculate the UID/GID from the objectSid every AD object has. We use the last block of the SID which is unique for each AD object. For example, if the objectSid is S-X-Y-ZZ-111111111-2222222222-3333333333-444444 the corresponding gidNumber or uidNumber would be 444444.

In our envirionment the number of the last block of the objectSid is larger than GID_MAX and UID_MAX on our RHEL servers.

Jorg,

Interested to know how you are implementing this. Are you storing this suffix in the UID/GID fields as well? or are you using a configuration in the SSSD provider to use this portion of the objectSid?

Is there any guarantee that this last portion of the Sid is unique? I have worked with several large directories and I would have concerns about collision.

Speaking of large directories, this is another reason why we use UID/GID stored in the directory. This essentially limits the number of accounts the Red Hat hosts see, to those that require Linux/Unix access. If an account doesn't need access to Unix hosts, we don't configure a UID/GID etc. for that object.

Hi,

We store this suffix in the fields uidNumber and/or gidNumber in Active Directory. We are not using some configuration in the SSSD provider.

In our environment we have only one large AD. In this the last block of the objectSid is unique. But as Karl mentioned in his comment this suffix does not seem to stay consistent if you move accounts between different AD domains.

In our environment we have some very old objects that have an objectSid <10000 which could collide with some local accounts on our RHEL servers. This could be an issue in the future. Today none of this accounts is used by an active user but we have to keep that in mind.

Our approach is far from beeing perfect. That's why we are evaluating a different approach using another directory service. If this new approach seems to work fine we are going to move away from AD integration because it has to many (unnecessary) confinements.

Regards, Joerg

PixelDrift and Jörg, thank you both for your responses. Going from AD's ObjectSID is intriguing, I'll investigate that further, especially our current numbering vs GID_MAX and UID_MAX - I'm not sure that the last block of our ObjectSIDs are high enough.

Especially thank you for highlighting the UID_ and GID_ settings on the RHEL servers - I did not read far enough to see that gotcha.

Investigating more, I find this regarding UID_MAX and GID_MAX: https://access.redhat.com/solutions/25404. This means that if I leave the default of 60000 in place, I can just start my GID/UID management in AD higher than 60000.

I also find that, especially for my AD Groups objectSIDs, their range is much too low to use them directly. Luckily we don't have multi-domain forests for our users, however I used to work at a place that did. If users move between domains when you're using objectSIDs to manage RHEL UIDs, watch out for https://technet.microsoft.com/en-us/library/cc961625.aspx. I don't find anything which guarantees that the last block of the objectSID is kept consistent (though perhaps testing would show it is, or you could read from the sIDHistory).

Hi,

Be aware that you could adjust the UID_MAX and GID_MAX to your needs in login.defs. So you could start with lower numbers than 60000 in AD.

I don't find anything which guarantees that the last block of the objectSID is kept consistent (though perhaps testing would show it is, or you could read from the sIDHistory).

Good point. I'll try to remember that. Although it may not matter in the future, because we are going to connect future RHEL systems to a Sun Directory Server (DSEE).

Close

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