[Samba] SIDs and UIDs and RIDs - Oh My!

[Moondance Foxmarnick]

Mr. Terpstra,


Okay-- I downloaded your current version from the link you posted - and
perhaps I did something incorrectly, because your first reference, Chapter
4, begins on page 55 in my PDF version and the quote is located on 57. So
I'm afraid we are still not looking at the same version, however I did find
the quote.

In the book, of course, the only reference towards RID from the index is
located in Chapter 11 - Group Mapping.

The quote is helpful to me, I did find it in the book (something I did not
read as I didn't need to be "sold" on the concept and so passed over
"Feature and Benefits") - but to make sure I "get" it I would like to
re-state it in my network terms. My network being a simplistic one - SAMBA
is PDC and XPs are all clients; no sub-nets. 

So since my Win or AD Domain is actually SAMBA, what you're saying is that
when I perform a smbpasswd -a xxusernamexx SAMBA creates an unique SID + RID
for the user that is mapped to the *nix backend (whatever I chose for the
PAM).

And just 3 digits (the RID) indicate (for XP clients) which user belonging
to which group for the Domain. What about users that belong to multiple
groups?

<< If you follow the guidelines I documented you should not ever need to 
mess with the RIDs. That's the whole point of following standardized 
procedures as shown in the documentation.>>

Well, except that it would seem from Chapter 11, Group Mapping - MS Windows
and UNIX, that we _do_ have to mess with it; if I want stratified user
privileges at any rate. I want all users in my "students" group on Fedora to
have nothing more than "Domain Users" privileges. When I log on - I want
"Domain Administrator" privileges. How is this not messing with the RIDs?

However, now I'm questioning that I need this. These are not XP "local"
privileges. Being "Domain Administrator" on an XP client will not allow me
to install programs like the "Administrator" group that is local to the XP
client, right? Currently it would seem only useful in a mixed environment -
or for workers that are only trained in using MS domain management tools.

I need to re-read Chapter 11. In section 11.2 (Discussion) it would seem I
do in order to use ACLs. But then in section 11.4.1, it would seem not. I'm
less confused about RIDs, but still uncertain whether I need groupmap or
not. 

Right now all the output of my groupmap list reads out to -1. Whenever my
clients log in, I get the results I want but a warning in the logs that "NT
doesn't like that!" when the GID is resolved. I assumed that groupmapping
was at fault. I'm building a new server (oddly, we need more than 40Gb
space..) and wanted to correct some implementation mistakes as well as
upgrade. 

<< Now that I have explained it, is this any clearer? If it is, please 
help me by rewriting or ammending the documentation to remove the
confusion.>>

It is certainly clearer. I think eventually I could contribute, but first I
need to study the PDF to see if it has changed significantly from the book -
especially Chapter 11 as that seems to be turning my brain inside out at the
moment. I feel as if I'm just on the verge of having it gel, but I just keep
missing something. I'm the How-to document's worst nightmare - I don't know
Windows Domain networking _or_ *Nix networking. 
So what seems like a simple statement: << Samba allows the administrator to
create MS Windows NT4/200x group accounts and to arbitrarily associate them
with UNIX/Linux group accounts >> (11.1 Features and Benefits) means that I
read it and think: "Why do I want this?" and what is winbindd (mentioned in
the next paragraph)? So off I go to see if I should be running winbindd (no,
I don't have an NT server). You begin to get the picture. 

I do feel strongly that if RIDs are still the subject of discussion in
Chapter 11 - then the information in Chapter 4 that you quoted should be
repeated there. It would have saved me a lot of time, but would have not
prevented this post.

Overall I'm happy and enthusiastic. After all, thanks to the books - I've
been running a SAMBA PDC with hidden and open shares and multiple groups et
all for a smidge over a year now with nary a complaint from an end user and
nothing but happy noises from upper Admin. for giving them more control with
out significant co$t. I'm certainly not going to hang out a shingle anytime
soon claiming to be a SAMBA whiz, but you gotta start somewhere.  

Thank you,

-Moondance

P.S.
<<	> Then on 154 it is stressed that under no circumstances should your
*nix groups or users trod on window's assigned RIDs for Domain Admins,
Domian Users, et. all. Another example of groupmap - oh look it lists a
RID?>

Please explain. What is your point now?>>

Just that in the book the net groupmap command now had a RID modifier, where
on the previous page it did not. I'm assuming from what I've read, that to
map groups - you need this. As you said the previous example was missing the
RID modifier.




-----Original Message-----
From: John H Terpstra [mailto:jht at Samba.Org] 
Sent: Saturday, August 13, 2005 4:48 PM
To: samba at lists.samba.org
Cc: Moondance Foxmarnick
Subject: Re: [Samba] SIDs and UIDs and RIDs - Oh My!

OK - I'll bite!

Clearly you have read the documentation I have written and find it
deficient. 
That's OK! Now, will you help me to  fix the deficiency please?

I need your help to make the documentation more useful.

Below is my side of this challenge you have issued. Please help me over my 
myopia.

On Saturday 13 August 2005 18:00, Moondance Foxmarnick wrote:
> I'm trying to grasp pg. 154 of the "Official SAMBA-3" book by Terpstra and
> Vernooij and I'm just missing a critical networking concept.

Good. Let's fix this now.

I presume that we are talking about the current version of this book. Right?
Here's the URL:

	http://www.samba.org/samba/docs/Samba3-HOWTO.pdf

If this is NOT the version you checked, please let me know precisely the URL

from which you obtained this and the creation date so I can refer to the
same 
document as you have.

> I understand that SIDs are the numerical identification of a user for the
> Windows world.

Correct. I checked the index for RID. The first reference is in section 4.1 
(page 46 in my build) where it says:

<quote>
A domain provides a unique network security identifier (SID). Domain user
and 
group security identifiers are comprised of the network SID plus a relative 
identifier (RID) that is unique to the account. User and group SIDs (the 
network SID plus the RID) can be used to create access control lists (ACLs) 
attached to network resources to provide organizational access control. UNIX

systems recognize only local security identifiers.
</quote>

So from this it might be interpreted that each Windows account has a unique 
RID, just as a UNIX user has a unique UID. Every Windows machine and every 
Windows security domain has a unique SID. A user SID is made up of the 
machine or domain SID and is catenated with a RID.

If that is not your interpretation please help me to understand the source
of 
confusion in the quoted section.

> I understand that UIDs are the equivalent for the *nix world.

A user account that has been created on a Windows workstation will have a 
locally assigned RID. If an account is created in a Windows NT4 or Active 
Directory Domain it will be allocated a unique RID within that security 
context.

> But what the @$@! is a Relative IDentifier (RID)?!?

A RID is like a UID or a GID. Where UNIX has separate IDs for users and 
groups, Windows has just one - the RID.

But the workstation referred to above has its SID. Every Windows workstation

has a unique SID. Every Windows NT4 or ADS domain has a SID also.

A user SID is made up of the SID of the security context within which it is 
created plus the RID.

A SID looks like this:

	S-1-5-21-11009899-23411980-22115678

If the user RID within the context of that SID has the value 879, then the 
user SID will be:

	S-1-5-21-11009899-23411980-22115678-879

>
> On page 153 the command to map a windows group to a *nix group - no
mention
> of RIDs.

Sorry. I really goofed on that didn't I!

> Then on 154 it is stressed that under no circumstances should your *nix
> groups or users trod on window's assigned RIDs for Domain Admins, Domian
> Users, et. all. Another example of groupmap - oh look it lists a RID?

Please explain. What is your point now?

> No mention as to where a RID comes from or can be viewed.

Really? I believe that is was in fact covered in section 4.1 - but if that
is 
not good enough please give me suggested text and a place you would like to 
see it located within the document (by section number please - not by page 
number).

> Do they mean that I can't have a user in Fedora that is 500? 

Sheesh! Really not clear is it! UIDs are mapped to RIDs.

Since Windows allocates RIDs sequentially for users, groups and for trust 
accounts we have to provide a way of mapping all UNIX users to a RID that is

absolutely unique. So Samba does algorithmic mapping. The RIDs are
calculated 
like this:

	User_RID = UID * 2 + 1000
	
	Group_RID = GID * 2 + 1001

That means that a UID of 500 will produce a RID of 2000.

> Isn't that a UID? 

No! I think I have clarified that.

> Is a UID a RID? 
No. A UID is a UNIX identifier. A RID is a Windows identifier. Samba
provides 
means to map them, but you can override the algorithmic mapping using the 
pdbedit and the net utilities. If you do override the mapping, just make
sure 
you get no overlap between Windows user and group RIDs.

> I've used Fedora for a year now and have never typed a  RID modifying 
> command. 

That is not a crime. No penalty is due. Most admins never need to mess with 
RIDs. If you follow the guidelines I documented you should not ever need to 
mess with the RIDs. That's the whole point of following standardized 
procedures as shown in the documentation.

> 
> I'm sure this is just so basic. But I don't know it and can't find it and
> it's critical to understand it.

Right. Now that I have explained it, is this any clearer? If it is, please 
help me by rewriting or ammending the documentation to remove the confusion.


When can I expect your patch, documentation update submission or a detailed 
bug report on https://bugzilla.samba.org to help get this straightened out?

- John T.