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?
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.”.
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.
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…
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.
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
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?
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.
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.
(and would be happy to read about any success you have, too).
) owned by those Linux user ids, you should remember the old mapping and chown once you have the new id.