[Samba] Re: Samba PDC migration - success!
timallen at ls83.fsnet.co.uk
Mon Jul 22 01:13:01 GMT 2002
Andrew Bartlett wrote:
> Tim Allen wrote:
> > Andrew
> > > Samba does not send back 'null' strings easily - if the passdb comes
> > > with 'null' it uses the default. Perhaps by setting 'logon path' etc
> > > "" it might help. Or it might not.
> > OK, tried this but unfortunately it does not fix the problem.
> > The user who is logging in has a UID of 1002
> > Looking at the logs, Samba authenticates the user OK, but then we see
> > his RID is set to 3004, not 1002. From then on, it's a new user. I
> > this new RID is coming from the NT4 workstation? The question is, what's
> > making it do this? What sort of negotiation takes place between Samba
> > the workstation at this point?.
> OK. You have a fundemental misunderstanding of how samba creates RIDs
> for users.
> Samba must create a globaly unqiue identifier for every user and group
> it represents to NT. This is called a SID, and starts with the 'domain
> sid'. This belongs to the domain, and is generated at startup.
> Each user and group also needs a SID, and this is made up of both a RID
> 'Relitive Identifier' and the Doamin SID.
> Domain SID: S-1-5-21-4117985702-3860941512-23890400
> User RID: 1081
> User SID: S-1-5-21-4117985702-3860941512-23890400-1081
> So, how to get a unique RID. The 'correct' solution is to store it
> along with other details on the user, like their password. Unfortunelty
> we don't do that in 2.2, only in HEAD. For Samba 2.2, we simply get
> their RID by this formula:
> (UID is unix UID)
> RID = (UID*2)+1000
> Groups are
> RID = (UID*2) + 1001
> So, if you want to migrate NT domains, your only option is to migrate
> the domain sid (see posts on this list, probably easiest to either suck
> it to secrets.tdb with 2.2's smbpasswd, or put it in MACHINE.SID in your
> secrets/ dir, and delete secrets.tdb) then import all the users into
> LDAP has the 'RID' attribute, and this can be set to any value. Samba
> HEAD will honer that value, but you should look into the 'alogrithmic
> rid base' to bump the '1000' value up to '10000' to ensure that users
> not in ldap don't create conflicting rids.
> Andrew Bartlett
Yes - I'd realised what was happening right after sending that email. The
point I was confused about was that the UID-RID translation is always
At the moment I know zippo about LDAP so need to read up on that before
following up your suggestion. But in the meantime, I've had success with
your suggestion a while back:
Since all my UID's and GID's are around 1000 max (probably the typical
situation in many cases) I modified /include/rpc_misc.h to use bit 11 (2048)
as the USER/GROUP identifier. I then modified pdb_user_rid_to_uid(),
pdb_user_rid_to_gid(), pdb_uid_to_user_rid() and pdb_gid_to_group_rid() to
not do the 1000 shift. This means that user RID's are left untouched and
group RID's shifted up by 2048.
I've treated administrator and guest as special cases to ensure that their
well-known RID's are used.
(BTW, the typecast on the return value in pdb_user_rid_to_gid() needs
It's all a bit of a hack but it works. Obviously it would run into
difficulties if the UID's/GID's are above 2047 to start with. A higher bit
could be used if necessary - I wasn't sure what the limits are on UID's,
GID's and RID's so played safe here.
Also, there's the obvious problem with incompatibility with the standard
mapping (which is probably irrelevant if you're needing to migrate).
I do have a question:
I'm assuming there's no mapping issues with the GID's and it is OK to shift
these. Is that the case or is there a potential problem there?
I'd be interested in your comments on this. Certainly for us it appears like
a workable way of migrating. Many thanks for your input which made it
More information about the samba