Friday, January 23, 2004
Delgating Admin access
You can map the "Domain Admins" SID in samba 3.0 to any unixgroup, and grant a Samba domain account admin access on any domain member machine. However, this account will not be able to add machines to the domain (or reset passwords, or other domain database functions.) Basically the account get's the privleged domain admin's SID, which the workstation recognizes, and grants the user full access to the machine. But domain admin tasks couldn't be done from windows workstations.
At the other end, you can sudo the administrative commands (pdbedit, net) to users - and they could add and remove accounts from an ssh session without being privledged Unix users.
But, to grant a user full access to the domain from the Windows side, without giving them permission to wreak havoc on the Unix side, about the best you could do is to make a local unix account on the samba PDC, give it a uid of zero, but then not reveal the password to them. In otherwords, the samba domain account password is out of synch with the unix password.
You can map the "Domain Admins" SID in samba 3.0 to any unixgroup, and grant a Samba domain account admin access on any domain member machine. However, this account will not be able to add machines to the domain (or reset passwords, or other domain database functions.) Basically the account get's the privleged domain admin's SID, which the workstation recognizes, and grants the user full access to the machine. But domain admin tasks couldn't be done from windows workstations.
At the other end, you can sudo the administrative commands (pdbedit, net) to users - and they could add and remove accounts from an ssh session without being privledged Unix users.
But, to grant a user full access to the domain from the Windows side, without giving them permission to wreak havoc on the Unix side, about the best you could do is to make a local unix account on the samba PDC, give it a uid of zero, but then not reveal the password to them. In otherwords, the samba domain account password is out of synch with the unix password.
Monday, January 05, 2004
Migration Successful
So, we've turned off our NT 4.0 domian controllers. Only one major problem- the groups didn't migrate correctly because I was trying to outsmart the system a bit. So, at first, my NT groups didn't migrate, and it took me a while to figure out how to fix them by hand.
When the command net rpc vampire pulls the informaiton out of the NT 4 PDC, it creates group mappings to the new Samba 3.0 Domain Controller.
That is, it grabs the SID of a group (i.e. Dept-Business) and looks for a local unix group with the same name. The samba daemon will now push out that SID, but interpret membership in that group based on the members in the local unix group file.
We thought we'd be clever, and since SMB uses SIDs and not GIDs to identify a particular group, the entries for our NT Groups in our local unix group file all had the same GID. So what do you think happened?
It mapped all our NT groups to the same unix group, the first group which used that GID. All our SIDs got brought over, but they got mapped to the same group.
So, the unix groups were given unique GIDs. The next step was reparing the mappings. This is done using the net command, but the syntax and concept took me a while to figure out.
Adding to the difficulty, I was running the net command with out the -s parameter, and since we're running the config files for net in a non-standard location, it was doing some odd stuff until I aliased net to net -s [path to smb.conf].
To view all the mapping on your Samba 3.0 domain, the command is net groupmap list. After cleaning up my unix group files, the bad maps would show up like this
...in this case, Dept-Buisness was the name Samba would push out, followed by the group SID. 88 was the GID I was trying recycle.
First, I tried creating a new mapping
...which would be successfull, but wouldn't work. I'd get something like this
...where 999988888 was the SID samba was autogenerating. So I fixed this by using net with the -s parameter. But really, you can't add a second mapping, you need to fix the first one. And, what you need to do is to indicate the SID, not the ntgroup name. Samba will name it itself.
The correct command was
And then delete the bad mapping by SID too, lest you undo what you just did,
So, we've turned off our NT 4.0 domian controllers. Only one major problem- the groups didn't migrate correctly because I was trying to outsmart the system a bit. So, at first, my NT groups didn't migrate, and it took me a while to figure out how to fix them by hand.
When the command net rpc vampire pulls the informaiton out of the NT 4 PDC, it creates group mappings to the new Samba 3.0 Domain Controller.
That is, it grabs the SID of a group (i.e. Dept-Business) and looks for a local unix group with the same name. The samba daemon will now push out that SID, but interpret membership in that group based on the members in the local unix group file.
We thought we'd be clever, and since SMB uses SIDs and not GIDs to identify a particular group, the entries for our NT Groups in our local unix group file all had the same GID. So what do you think happened?
It mapped all our NT groups to the same unix group, the first group which used that GID. All our SIDs got brought over, but they got mapped to the same group.
So, the unix groups were given unique GIDs. The next step was reparing the mappings. This is done using the net command, but the syntax and concept took me a while to figure out.
Adding to the difficulty, I was running the net command with out the -s parameter, and since we're running the config files for net in a non-standard location, it was doing some odd stuff until I aliased net to net -s [path to smb.conf].
To view all the mapping on your Samba 3.0 domain, the command is net groupmap list. After cleaning up my unix group files, the bad maps would show up like this
% net groupmap list | grep Buisness
Dept-Business (S-1-5-21-23545555-1234) -> 88
...in this case, Dept-Buisness was the name Samba would push out, followed by the group SID. 88 was the GID I was trying recycle.
First, I tried creating a new mapping
% net groupmap add ntgroup=Dept-Business unixgroup=Dept-Business type=domain
...which would be successfull, but wouldn't work. I'd get something like this
% net groupmap list | grep Buisness
Dept-Business (S-1-5-21-23545555-1234) -> 88
Dept-Business (S-1-5-21-99998888-1234) -> Dept-Business
...where 999988888 was the SID samba was autogenerating. So I fixed this by using net with the -s parameter. But really, you can't add a second mapping, you need to fix the first one. And, what you need to do is to indicate the SID, not the ntgroup name. Samba will name it itself.
The correct command was
% net groupmap modify sid=S-1-5-21-23545555-1234 unixgroup=Dept-Business
% net groupmap list | grep Buisness
Dept-Business (S-1-5-21-23545555-1234) -> Dept-Business
Dept-Business (S-1-5-21-99998888-1234) -> Dept-Business
And then delete the bad mapping by SID too, lest you undo what you just did,
% net groupmap delete sid=S-1-5-21-99998888-1234