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:[EMAIL PROTECTED] Sent: Saturday, August 13, 2005 4:48 PM To: [email protected] 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 @[EMAIL PROTECTED] 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. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
