Help with migrating local Linux users to Winbind AD users

Recently, we have found it necessary to join all of the Linux systems in our data center to our centralized AD Domain. In order to accomplish this, we ended up utilizing winbind to authenticate AD users onto the machines. For the most part, this solution seems to be working well for the systems we have tested it on. However, we are running into the problem that our systems have a lot of local user accounts on them that have equivalent accounts present in active directory, but since winbind requires the uids to be different for a local account and a domain account, these accounts are not synchronized. So my question is, is there a way for me to sync these accounts so that present group membership and file/directory permissions set up for the users can be preserved for the equivalent domain user account?

Just as an example, take an account with the following details:
local username: testuser
local uid: 12345
domain username: testuser
domain uid: 112345
local user groups: wheel, apache
domain user groups: Domain Users

I would ideally want the following to occur:
local testuser account gets “migrated” so that it points to the testuser account on the domain but maintains local user groups. It does not need to maintain local uid.

Thanks for any help!

Posted Oct 12, 2021, 5:24 PM UTC

59
hortimech•

It doesn't work like that, If you are using winbind, then the three main backends (ad, rid and autorid) work with information from AD and the users and groups in AD become Unix users and groups. The rid and autorid backends calculate the ID's using the RID and the Domain low range set in smb.conf. The 'ad' backend uses rfc2307 attributes you set in the user & group objects in AD.

What this means is that you should have very few local users in /etc/passwd and everything else (apart from system users & groups) comes from AD.

7
MRAndy_MCOP•

Our winbind config is using the 'ad' backend so that we can make use of the rfc2307 attributes like loginShell and unixHomeDirectory. However, these systems have been used extensively by several users before they were added to the domain with winbind, so there are still dozens of local users on each machine that have corresponding accounts on the domain, but the machines are reading the local users rather than the domain users.

1
hortimech•

What were they using before they were joined to the domain ? Winbind only works with a domain, it is its reason for existing.

Users & groups must have the required rfc2307 attributes containing numbers inside the domain range set in smb.conf, or they will be ignored. As I said, you really shouldn't have users & groups in AD and /etc/passwd and /etc/group

3
MRAndy_MCOP•

The users were only in /etc/passwd and /etc/group. The servers were not set up initially with winbind, they are being added after the fact. So there are still plenty of users that are both in AD and locally on the machine. I understand this is not what you want, but this is the scenario I am in and I'm trying to find a way to properly fix it.

1
hortimech•

The only way to fix this is to give your AD users a uidNumber attribute containing a number inside the domain range you set in smb.conf, then remove the local user. The same goes for groups, only these use gidNumber attributes.

4
IxI_DUCK_IxI•

Off topic, but on topic: rfc2307 is only applicable with Windows 2012R2 as the NIS extensions are depreciated in Windows 2016+. Is this the only way Winbind works is with the uid or does it support the SID as an attribute? We're kind of stuck on Windows 2012R2 for the time being cause we're not sure how to move forward with 2016+ due to NIS being depreciated.

1
bagatelly•

Look into SSSD uid/gid auto mapping which should kill off the need for winbind and extensions/attributes on AD. This also means you should use SSSD everywhere and not have a mix of sssd/winbind systems.

4
unccvince•

u/hortimech is 100% right.

Scripting may help you there if you have a lot of hosts. It may be more trivial to write a check to a company specializing in this kind of thing than to attempt it yourself.

1