# SLES - AD integration **URL:** \ **Category:** SLES Configure-Administer\ **Created:** [October 18, 2013, 5:04pm UTC](https://forums.suse.com/t/sles-ad-integration/24644 "2013-10-18T17:04:19Z")\ **Posts on this page:** 11\ **Page:** 1
**Author:** ![jdoeconsulting](https://avatars.discourse-cdn.com/v4/letter/j/f19dbf/32.png) [@jdoeconsulting](https://forums.suse.com/u/jdoeconsulting)\ **Post date:** [October 18, 2013, 5:04pm UTC](https://forums.suse.com/t/sles-ad-integration/24644/1 "2013-10-18T17:04:19Z")
We’re working on a case in an all Windows environment where a new installation involves 10 Linux servers (all SLES 11 SP2). In order to manage the SLES servers we wanna integrate the servers with Active Directory. By using Yast|Windows Domain Membership we’ve already done this. And we’ve limited ssh to only allow members of certain AD groups to login. We’ve also tied sudo to AD groups, so that depending on what AD groups the user is a member of, he may perform various commands through sudo. The problem we’re seeing is that this integration actually gives AD users different UIDs on different servers. Since the UIDs begin at 10000 it depends on which AD user first authenticates to a server. First AD user to authenticate gets UID=10000 next AD user gets 10001 and so on. This can end up with having different users having UID 10000 on different servers. In order to be able to track user activity it’s vital that all AD users have the same UID on all servers. How may we achieve this? If at all possible we’d like to avoid having to make any changes to AD Schema and not install any additional components on the Domain Controllers. Is there anyway to achieve this by using only what’s available in SLES? Thx ---
**Author:** ![Jens-U](https://avatars.discourse-cdn.com/v4/letter/j/d78d45/32.png) [@Jens-U](https://forums.suse.com/u/Jens-U)\ **Post date:** [October 18, 2013, 5:28pm UTC](https://forums.suse.com/t/sles-ad-integration/24644/2 "2013-10-18T17:28:42Z")
Hi jdoeconsulting, > The problem we’re seeing is that this integration actually gives AD users different > UIDs on different servers. looks to me as if you’re using tdb or tdb2 as a backend for winbindd: From man smb.conf, section “idmap config backend”: “The first three of these [tdb, tdb2, ldap] create mappings of their own using internal unixid counters and store the mappings in a database.” When you’re running individual winbindd on all these SLES servers, those counters will obviously not be unique. You might want to try switching to another back-end: “The rid and hash backends use a pure algorithmic calculation to determine the unixid for a SID.”. As you said that changing the AD content is out of the question, the following description from the man page will not apply: “The ad and adex backends both use unix IDs stored in Active Directory via the standard schema extensions.”. Regards, Jens ---
**Author:** ![jdoeconsulting](https://avatars.discourse-cdn.com/v4/letter/j/f19dbf/32.png) [@jdoeconsulting](https://forums.suse.com/u/jdoeconsulting)\ **Post date:** [October 19, 2013, 4:01pm UTC](https://forums.suse.com/t/sles-ad-integration/24644/3 "2013-10-19T16:01:27Z")
Hi Jens, Thanks for your reply. You’re absolutely correct that we’re using the standard tdbsam backend. What you’re saying does sound very promising. I’ll definately look into this and most likely post back with any follow-up questions. Just to clarify, that we do not wanna have to convince the AD people that some extensions needs to be done to the AD schema or to the DC:s if at all possible to avoid. I do know that the UNIX attributes are part of the standard AD schema and thus those could be used to actually set the UID/GID in AD and perhaps have SLES to use those. I’ll have to test that out. Thanks! ---
**Author:** ![Jens-U](https://avatars.discourse-cdn.com/v4/letter/j/d78d45/32.png) [@Jens-U](https://forums.suse.com/u/Jens-U)\ **Post date:** [October 19, 2013, 8:42pm UTC](https://forums.suse.com/t/sles-ad-integration/24644/4 "2013-10-19T20:42:58Z")
Hi jdoeconsulting, [QUOTE=jdoeconsulting;16987]Hi Jens, Thanks for your reply. You’re absolutely correct that we’re using the standard tdbsam backend. What you’re saying does sound very promising. I’ll definately look into this and most likely post back with any follow-up questions.[/QUOTE] of course we’re here to help with anything you throw at us 🙂 (and would be happy to read about any success you have, too). [QUOTE=jdoeconsulting;16987]Just to clarify, that we do not wanna have to convince the AD people that some extensions needs to be done to the AD schema or to the DC:s if at all possible to avoid. I do know that the UNIX attributes are part of the standard AD schema and thus those could be used to actually set the UID/GID in AD and perhaps have SLES to use those.[/QUOTE] You were very clear about that in your original message, it was just for the sake of others stumbling over this thread that I didn’t want to leave out this possibility from my answer 😉 If changing the back-end to some predictable algorithm instead of simple enumeration, I’d call that a good solution, without having to mess with the AD folks… Regards, Jens ---
**Author:** ![jdoeconsulting](https://avatars.discourse-cdn.com/v4/letter/j/f19dbf/32.png) [@jdoeconsulting](https://forums.suse.com/u/jdoeconsulting)\ **Post date:** [October 20, 2013, 12:18am UTC](https://forums.suse.com/t/sles-ad-integration/24644/5 "2013-10-20T00:18:35Z")
Jens, Again, thanks a lot for your time on this. I’ve done some testing with changing the backen to rid and this appears to work very well. Now the big issue is what needs to be done with those accounts that have already logged in to the SLES boxes. After changing the backend to rid instead of tdbsam i notice that users that have already authenticated keeps their old uids even though I’ve set another range for the rid backend. I don’t see the accounts in /etc/passwd nor in /etc/shadow and from what I can tell from the modifications times of /etc/samba/passdb.tdb and /etc/samba/secrets.tdb , it doesn’t look like the info is stored in there as well. I need to get the users to get the new uid from the range set for the rid backend otherwise they’ll still have the old uid, which isn’t the same across all the boxes. Any pointers is much appreciated. ---
**Author:** ![Jens-U](https://avatars.discourse-cdn.com/v4/letter/j/d78d45/32.png) [@Jens-U](https://forums.suse.com/u/Jens-U)\ **Post date:** [October 20, 2013, 2:59pm UTC](https://forums.suse.com/t/sles-ad-integration/24644/6 "2013-10-20T14:59:36Z")
Hi jdoeconsulting, [QUOTE=jdoeconsulting;16989]Jens, Again, thanks a lot for your time on this. I’ve done some testing with changing the backen to rid and this appears to work very well. Now the big issue is what needs to be done with those accounts that have already logged in to the SLES boxes. After changing the backend to rid instead of tdbsam i notice that users that have already authenticated keeps their old uids even though I’ve set another range for the rid backend. I don’t see the accounts in /etc/passwd nor in /etc/shadow and from what I can tell from the modifications times of /etc/samba/passdb.tdb and /etc/samba/secrets.tdb , it doesn’t look like the info is stored in there as well. I need to get the users to get the new uid from the range set for the rid backend otherwise they’ll still have the old uid, which isn’t the same across all the boxes. Any pointers is much appreciated.[/QUOTE] please have a look at “wbinfo --remove-uid-mapping=UID,SID” and don’t be confused that the man page doesn’t list that option 😉 “wbinfo --help” does 🙂 I guess you’ll have to remove the original settings on all servers individually, bu fortunately, using “wbinfo -u”, “uid -u” and “wbinfo -n” will help you automate that task: `for i in $(wbinfo -u) ; do uid=$(id -u $i) sid=$(wbinfo -n $i) echo "wbinfo --remove-uid-mapping=$uid,$sid" done` Please test this first and never trust code you get from a public forum 😉 Regards, Jens ---
**Author:** ![jdoeconsulting](https://avatars.discourse-cdn.com/v4/letter/j/f19dbf/32.png) [@jdoeconsulting](https://forums.suse.com/u/jdoeconsulting)\ **Post date:** [October 21, 2013, 12:03pm UTC](https://forums.suse.com/t/sles-ad-integration/24644/7 "2013-10-21T12:03:49Z")
Jens, It seems that the --remove-uid-mapping option is not fully implemented, that might be the reason for it not being mentioned in the man page. Here’s the output I got from my tests; srv07:~ # id -u labnet\\dduck 10000 srv07:~ # wbinfo -n labnet\\dduck S-1-5-21-2120564822-90971336-1152605766-1104 SID\_USER (1) srv07:~ # wbinfo -i labnet\\dduck LABNET\dduck:\*:10000:10000::/home/LABNET/dduck:/bin/bash srv07:~ # wbinfo -U 10000 S-1-5-21-2120564822-90971336-11526057 srv07:~ # wbinfo --remove-uid-mapping=10000,S-1-5-21-2120564822-90971336-1152605766-1104 failed to call wbcRemoveUidMapping: WBC\_ERR\_NOT\_IMPLEMENTED Could not remove uid to sid mapping66-1104 Are you aware of any other means to remove the mappings, so I can have the user’s get their new UIDs? Thanks! ---
**Author:** ![jdoeconsulting](https://avatars.discourse-cdn.com/v4/letter/j/f19dbf/32.png) [@jdoeconsulting](https://forums.suse.com/u/jdoeconsulting)\ **Post date:** [October 21, 2013, 4:06pm UTC](https://forums.suse.com/t/sles-ad-integration/24644/8 "2013-10-21T16:06:10Z")
Looking upon this a bit further I see the mapping within /var/lib/samba/winbindd\_idmap.tdb when running tdbtool. However I’m reluctant to delete it directly using tdbtool as I’m sure it’s probably written in some other file as well. I’m hoping there’s another alternativ way to achieve what I want. Thanks! ---
**Author:** ![Jens-U](https://avatars.discourse-cdn.com/v4/letter/j/d78d45/32.png) [@Jens-U](https://forums.suse.com/u/Jens-U)\ **Post date:** [October 21, 2013, 4:27pm UTC](https://forums.suse.com/t/sles-ad-integration/24644/9 "2013-10-21T16:27:08Z")
Hi jdoeconsulting, > However I’m reluctant to delete it directly using tdbtool > as I’m sure it’s probably written in some other file as well. From “man 8 winbindd”: [QUOTE]The allocated unix ids are stored in a database and will be remembered. WARNING: The SID to unix id database is the only location where the user and group mappings are stored by winbindd. If this store is deleted or corrupted, there is no way for winbindd to determine which user and group ids correspond to Windows NT user and group rids.[/QUOTE] I’d say: Go for it. - stop smb services, especially winbindd - move away /var/lib/samba/winbindd\_idmap.tdb - restart samba - test If everything else fails, put the original file back in place. Of course, if you have resources (AKA “files & directories” 😃 ) owned by those Linux user ids, you should remember the old mapping and chown once you have the new id. Regards, Jens ---
**Author:** ![jdoeconsulting](https://avatars.discourse-cdn.com/v4/letter/j/f19dbf/32.png) [@jdoeconsulting](https://forums.suse.com/u/jdoeconsulting)\ **Post date:** [October 21, 2013, 10:58pm UTC](https://forums.suse.com/t/sles-ad-integration/24644/10 "2013-10-21T22:58:50Z")
Jens, Thanks for your continued support on this, it’s truly appreciated. After having checked the tdb files within /var/lib/samba I saw that the SID and UID are mentioned in several files. So insted of trying to remove the keys from all files with tdbtool, I instead removed all the files from the directory (they’re recreated when the winbind service starts up again). Now the users get a new UID from the rid range. Now I get the steps in order now it’s just a question of planning the switch. Thanks Jens, you’re the man!! ---
**Author:** ![Jens-U](https://avatars.discourse-cdn.com/v4/letter/j/d78d45/32.png) [@Jens-U](https://forums.suse.com/u/Jens-U)\ **Post date:** [October 22, 2013, 4:33pm UTC](https://forums.suse.com/t/sles-ad-integration/24644/11 "2013-10-22T16:33:03Z")
Hi jdoeconsulting, thank you for letting us know that your approach works - and thank you for the kind words, too! Regards, Jens