[Samba] Changing user SID or Domain (doesn't work)

Jonathan Johnson
Thu, 03 Jun 2004 14:57:14 -0000

I'll start off with my question: how do you change a user's SID? When I
issue the command:

	[root@server root]# pdbedit -u testuser -U \
	S-1-5-21-4000410194-515421893-615041212-2006

I see

	testuser:516:Test User
	[root@server root]#

Then, I do "pdbedit -Lv testuser" and it still shows the old SID.

Now, I'll give you a little background.

Previously, this server (NetBIOS name of SERVER) had Samba 2.2.7 on it,
functioning as a member of the workgroup AEC, using "local" security
and "passdb backend = smbpasswd."

I upgraded to Samba 3.0.3 (now 3.0.4), coverted the passdb to tdbsam,
THEN changed it to be a domain controller (there was no domain
controller on this network previously).

When I issue "pdbedit -Lv" I see that those accounts created before
the
server became a PDC list "Domain: SERVER". Those accounts created
after
becoming a PDC list "Domain: AEC".

This is a problem, because although a user can log in to a workstation
using the domain AEC, once logged in it thinks they are logged into the
domain SERVER. This causes domain browsing issues (it can't find a
domain controller for the domain SERVER), there appears a phantom
domain SERVER in Network Neighborhood, we have problems assigning
security because the windows machine cannot get a SID for
SERVER\testuser, etc. If I issue "net config workstation" on the XP
workstation, it shows the user login domain as SERVER.

Ultimately, I'd like to be able to just change the "Domain" for
each
user to be correct. Since I could not find any way to do this, I
thought I would just recreate the account and change back to the old
SID. (Recreating the account with a new SID will cause even more
headaches, because there is a fairly complex security structure)

HELP!

I guess the moral of the story is to convert to PDC mode before moving
accounts from smbpasswd to tdbsam. If there were a way to just change
the domain using pdbedit, that would be wonderful, but any solution
will be appreciated.

--Jon Johnson
Sutinen Consulting, Inc.
jon@sutinen.com