:o) I wasn't going after you JoeK. I am more against how MS set the terms in MSDN, you are simply using MS's terms for the fields so by the MS book, your post is exactly correct. I also agree that at the bit level, there is no difference between a RID and a subauthority, they are simply a 32 bit portion of an identifier.
In the interest of less confusion for those less than comfortable with swimming through winnt.h and reading what the dev guys actually wrote and possibly intended, what I posted was hopefully more in line with how most admins understand it now for easier digest. Actually I spent a little time yesterday just surfing through a lot of the SID based docs and there is a lot there that is stated in confusing ways, I may spend some time writing the MSDN feedback alias on the issues I saw. It even mentions RIDs greater than 32 bits which isn't really possible from how I understand it and also Dean pinged me on my post mentioning that RIDs are actually limited to 2^30 instead of 2^32 (i.e. 30 bits instead of 32) which I am not surprised by though the field for its reprensentation in a SID is still 32 bits. It is the RID generation side of the house that limits it to 30 bits. A SID with a RID of 32 bits would be entirely valid because it is defined to be so. It is sort of like building a car to do 100 and then other components that the car is dependent upon are only efficient enough to get it to 80. The car can still do 100 fine, just not with the way it is being supplied. As an aside, I received an offlist response from a trustworthy individual discussing a little bit about the ADAM SIDs and that they are actually an attempt at not having a RID master and use a variation of the GUID generation algorithm to generate the SIDs. That makes sense from what I saw when I first noticed that the ADAM SIDs were "odd". I still think my idea of each host of an instance should be as subauthority of the entire instance so it could positively guarantee unique SIDs is better than just producing something that is a best effort unique but hey, its not my call. I also still like the idea of dumping SIDS and GUIDs entirely for a more OID based space as well. As this person put it, if there was a natural occurrence that caused a failure off the statistical improbability of duplicates that person would be looking for a new job anyway... ;o) As for your last question, it would be when you are using actual real subauthorities and allowing them to also issue SIDs. For instance say the president of your company can issue SIDs and her SID is S-1-5-21-1. Anything she issues would be S-1-5-21-1-xxx where xxx would be the unique RID within her realm. Now lets say that her VP represented by S-1-5-21-1-10 is VP of Finance and wants to issue her own SIDs so any SID produced by her would be S-1-5-21-1-10-yyy. Then someone under her, say S-1-5-21-1-10-200 wants to issue SIDs of the type S-1-5-21-1-10-200-zzz, etc etc etc. Until you hit 14 subauths (don't forget the 21 is a subauth after the identifier of 5) and then all you can have would be the unique RIDs. Now if you wanted and didn't mind going against the standard, you could create your own Version 2 of the SID and then redefine the rest of the structure so that you use all 8 bits of the subauth field size (versus setting defined max of 15 and using 4 bits) so you now get up to 255 subauths. Or since you are off the standard anyway, you could even say you want the 4 extra bits of subauth count field AND the 4 reserved bits giving you up to 4095 subauths which would be one heck of a large SID buffer. If you were going to do this, I would just say set up your own OID attribute and go from there. In either case, you could say that the VP of Finance was found to be untrustworthy and immediately cancel access to anyone under the S-1-5-21-1-10 level. That would obviously require security to be done a little different than it is now since it really isn't hierarchical though the original plan seems to have been a hierarchical based plan. joe -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Friday, August 19, 2005 10:48 PM To: [email protected] Subject: RE: [ActiveDir] User SIDs... LOL! The great irony of this message is that Dean emailed me offline to ask me something about it too and I lamented that I had probably under-engineered my response, but I had assumed that you would come along to clean up my mess. :) I also claim lack of time due to book writing responsibilities and such. However, aside from my smearing of the distinction between a sub authority and a RID, I believe I was correct from a binary standpoint. The winnt.h structure definition actually doesn't make a distinction between a sub authority and a RID, so I always thought the terms could be used interchangeably. Given that the sub authorities and the RID are both DWORDs that are treated as integers when converted to the SDDL representation, it is a pretty natural mistake to make. I'm still wondering what situation would call for a SID with more than 15 sub authorities (or 14 + 1 RID, however you want to slice it). Thanks, Joe K. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Friday, August 19, 2005 4:21 PM To: [email protected] Subject: RE: [ActiveDir] User SIDs... Sorry, I have just been lurking occasionally lately, I am quite busy with the book and some stupid things with Exchange I am looking into at work in how failovers are detected and reported and the fact that the ESM and WMI don't seem to do a very good job reporting what is happening but the event log seems to have good info.... Anyway this post caught my attention. I was shocked to see JoeK saying a SID could have 15 RIDs. Knowing JoeK I was like, "where is that coming from?". So I looked up the docs in MSDN as I haven't peeked in a while and they do in fact say "a variable number of subauthority or relative identifier (RID) values". This is, in my opinion, extremely misleading and could cause confusion as people try to figure out how the "RIDs" get stacked up to produce a SID. Also, IMO, the subauthorities are generally NOT RIDs, at least not in the common use of the word RID by Windows Admins. Note this isn't an attack on JoeK's explanation, I am just pointing out what I consider to be some confusing if not hokey MS documentation here and bad use of well known terms. A RID is a 32 bit value, issued by a given authority to indicate a unique object in the realm of authority the authority is well, authoritative for. :o) When I think RID, I think the values that a computer or domain generate to attach to the SID that the computer or domain has for itself which it, in turn, assumes as unique. When you take a domain or computer SID made of the revision (1), the identifier (5), the first DWORD subauthority (21), and the remaining computer or domain subauthorities (usually 3 for a total of 96 bits or 3 DWORDS) there is NOTHING guaranteeing that SID is unique anywhere, it is a complete and utter prayer. There isn't an authority of S-1-5-21 that issues a a unique RID used for the next subauthority which in turn issues the next, etc. You simply have 3 randomly generated subauthorities that are tacked onto S-1-5-21 [1]. That SID is in turn a real authority and generates real RIDs that are combined with the SID and assigned to specific objects making that SID a unique identifier within the realm of that authority but not necessarily unique anywhere else. In other words, it is absolutely possible to have duplicate SIDs in different realms. Consider the case of ghosted machines for instance. In that case, you are guaranteed to have duplicated SIDs across multiple realms representing different objects unless you have changed the machines' SIDs. So anyway, a version 1 SID could contain 15 DWORD subauthorities maximum (or 14 SubAuthorities and a RID). This would make your maximum SID size of 15*32 + 4*16 or 480+64=544 bits (68 bytes) [2]. The standard SID (i.e. not well known principals) that you usually see that is assigned to a user or group, etc contains 4 subauthorities, 21-xxxxxx-yyyyyyy-zzzzzzz and a RID (or 5 subauthorities). For a total size of 5*32+4*16 = 160+64=224 bits (28 bytes) [3]. If the idea of the SID had taken off and others outside of MS started issuing SIDs from specific authorities and the subauthorities issued their own SIDs etc etc etc then I would swallow the whole subauthorities as RIDs explanation but that hasn't occurred. MS instead has jumped off the SID bandwagon and gone to the GUID which is a fixed length value that is also not guaranteed to be unique but is far easier to deal with being a fixed size. Personally, it may have been more logical to go to the OID type space and run with that. It is like the SID but you have multiple issuing authorities and companies could further subdivide its issue value internally and specify its own subauthorities, etc etc... :o) So anyway, all of this to say that when discussing SIDs of normal objects we should think of them as a revision, an identifier authority, a variable number of random subauthorities, and a RID. :o) joe [1] Which BTW, has a constant name of SECURITY_NT_NON_UNIQUE... [2] Which explains the reason why someone had an issue creating a SID of > 68 bytes. The structure is capped at 68 bytes due to the definitions of the size of the subauthorities and how many subauthorities can reside in a SID structure. Even if someone were successful at creating the SID, it would be considered invalid at best and at worst, it would be truncated down to the size specified by the subauthority count field. If I heard someone was trying to create a SID greater than 68 bytes I would ask... Why? [3] Note that ADAM SIDs seem to jump around considerably. I haven't had a chance to sit down and discern the patterns, if any exist, yet. The "builtin" groups such as administrators/users/readers all have two subauthorities that seem to be randomly generated and the normal users created seem to have 3 additional randomly generated subauthorities and a seemingly randomly generated RID instead of an incrementing RID. This would seem to be a trifle dangerous in a multi-host ADAM instance. I need to play with it. It could be another one of those cases of "it isn't likely to happen so we won't worry about it"... I am sure it checks itself to see if it is a dupe but if you have two hosts both holding the same instance but not replicating regularly, I could visualize hitting an issue unless each host is its own subauthority which I now realize I never doublechecked. For fun, this is the SID structure stuff out of winnt.h //////////////////////////////////////////////////////////////////////// // // // Security Id (SID) // // // //////////////////////////////////////////////////////////////////////// // // // Pictorially the structure of an SID is as follows: // // 1 1 1 1 1 1 // 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 // +---------------------------------------------------------------+ // | SubAuthorityCount |Reserved1 (SBZ)| Revision | // +---------------------------------------------------------------+ // | IdentifierAuthority[0] | // +---------------------------------------------------------------+ // | IdentifierAuthority[1] | // +---------------------------------------------------------------+ // | IdentifierAuthority[2] | // +---------------------------------------------------------------+ // | | // +- - - - - - - - SubAuthority[] - - - - - - - - -+ // | | // +---------------------------------------------------------------+ // // This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
