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: ActiveDir@mail.activedir.org 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/
