winbindd_idmap.tdb recovery

[Esh, Andrew]

What happens when there are trusted domains? The RID really ought to be a
SID, but those are 128 bits, so even after truncating to 64 bit UIDs, there
is still a potential for collision, just among Windows users from various
domains. The more NIS/Unix users that are added to the equation, the worse
the problem gets.

-----Original Message-----
From: MCCALL,DON (HP-USA,ex1) [mailto:don_mccall at hp.com]
Sent: Friday, February 08, 2002 3:22 PM
To: MCCALL,DON (HP-USA,ex1); STEFFENS,MICHAEL (HP-Germany,ex1); 'Tim
Potter'
Cc: 'samba-technical at samba.org'
Subject: RE: winbindd_idmap.tdb recovery


Continuing this discussion with myself  (I think better when I talk, even
though it exposes my ignorance),

At least on HP-UX, uid_t is a 32bit unsigned integer, capable of handling
the entire rid space from win2k...
Why map at ALL? just USE the rid comming back from the Win2k server, and
only map if there is a conflict with a local uid?  Or are most other UN*X
implementations more limited to their uid space?

Or perhaps just use a base uid# for winbindd, and add this to each rid that
comes in to come up with the mapped unix uid.  This way the unix admin could
ensure that his 'local' users were all created with uids less than this base
uid#, to avoid collisions.
According to a microsoft article I read, the rids in a domain are
monotomically allocated, so the chance of us actually HITTING the uidbase#
+rid limit within a 1 billion number space should be pretty rare.

Question - how does it work when the sid/rid is comming in from a 'trusted'
domain to the domain we are actually a member of?  If I understand
correctly, currently we assign a uid from our 'pool' to the domain name/rid
pair that comes in, so if we were a member of dom1, which trusted dom2, when
dom1/mike (with rid 8774) accessed us for the first time, we would assign
out of a winbindd uid pool of (ex: 3000-4000) the uid 3000.  Then when
dom2/mike (coincidentally also rid 8774) accessed us for the first time,
different domain, same rid, he would get a different (3001) uid from the
pool...
So we would have a high potential for trusted domain rid collisions, since
we have only the single unix uid space to map into.
Oops...
Any ideas?
Don


-----Original Message-----
From: MCCALL,DON (HP-USA,ex1) 
Sent: Friday, February 08, 2002 3:51 PM
To: MCCALL,DON (HP-USA,ex1); STEFFENS,MICHAEL (HP-Germany,ex1); 'Tim
Potter'
Cc: 'samba-technical at samba.org'
Subject: RE: winbindd_idmap.tdb recovery


Ok, 
I know, I know - the problem is being able to map from a billion number
space (the number of potential rids that a win2k domain has to draw on) to
an arbitrarily small uid space.  GIVEN that the number of actual IN-USE rids
in the win2k space is not allowed to exceed the max number of uids in the
UID-SPACE.
I didn't say it would be easy....

-----Original Message-----
From: MCCALL,DON (HP-USA,ex1) 
Sent: Friday, February 08, 2002 2:57 PM
To: STEFFENS,MICHAEL (HP-Germany,ex1); Tim Potter
Cc: MCCALL,DON (HP-USA,ex1); samba-technical at samba.org
Subject: RE: winbindd_idmap.tdb recovery


Hi Michael,Tim, et al;
I've been thinking (I know - I shouldn't do that...).
All of the things we are trying to address with this additional
functionality/tool
are needed because we are assigning uid/gid's on a first come first serve
basis.
So if something screws up the database, we are pretty sure that when it gets
rebuilt
the uid-rid mapping will change.  In addition, this almost guarantees that
the uid-rid
mapping will be different on different samba servers in the SAME domain, as
users will
access them in a different order.

What we REALLY want is to guarantee is that ANY Samba server using winbindd
in the 
SAME WIN2k/NT domain, would map the same domain user to the same unix uid,
and the 
same domain group to the same group id.

What this suggests to me is a hashing algorythm that would take the SID/rid
of the 
domain group/user, and map that uniquely and consistently into the uid/gid
space that 
we define with winbindd uid and winbindd gid...

Just a quick thought - if you all can point out the problems/shortcomings of
a scheme
like this, I'll either look into it, or run away - run away (to misquote
Monty Python)...

Thanks,
Don


-----Original Message-----
From: Michael Steffens [mailto:michael_steffens at hp.com]
Sent: Wednesday, February 06, 2002 5:06 AM
To: Tim Potter
Cc: MCCALL,DON (HP-USA,ex1); samba-technical at samba.org
Subject: Re: winbindd_idmap.tdb recovery


Hi Tim,

Tim Potter wrote:
> I can always add a --export-idmap and --import-idmap arguments to
> be info that will do the trick.

as Don already said: great idea!

I think the --import-idmap functionality should be able to
cope with the cases

 - re-create idmap, i.e drop existing entries.

 - merge into existing idmap, discard new entries in case of
   conflicts with existing ones.

 - merge into existing idmap, overwrite existing entries in
   case of conflicts with new ones.

Maybe an interactive mode, prompting when coming across
conflicts, would also be helpful.

Would yo do that "online" via winbindd, or "offline" by directly
accessing winbindd_idmap.tdb?

I already thought about deriving an offline tool from tdbtool.

Cheers!
Michael
-------------- next part --------------
HTML attachment scrubbed and removed