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[] - - - - - - - - -+ // | | // +---------------------------------------------------------------+ // // -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Friday, August 19, 2005 2:22 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] User SIDs... A SID of 68 bytes would have the 15 RIDs, which is as far as I can tell the highest number of RIDs a SID can hold. There is only 1 byte reserved in the first 8 bytes of a the SID structure to store the number of RIDs, so that is basically 15 (since 0 RIDs doesn't do much for you). Where do these giant SIDs come from? Most AD SIDs I've seen are 24 or 28 bytes (4 or 5 RIDs respectively). Joe K. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rick Kingslan Sent: Friday, August 19, 2005 12:43 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] User SIDs... Having read through most of the replies on this, it's interesting that there was an internal (to Microsoft - just to clarify) discussion on this same topic yesterday. Seems that a customer was having problems with a function calling APIs for SID creation when the SID exceeded 68 bytes. I'll let you determine from that statement what the largest supported SID is. :o) So, take that number into 12000 and I suspect that will give you a clear idea of how memberships would begin to cause issues with Kerberos. However, as al mentions, this can be increased but I don't know what the max supported size is. And, as to figuring out the actual size of a SID, yes there is. I don't have the algorithm at my finger tips, but it can be derived pretty easily - more easily with C/C++, or Perl, IIRC. Rick -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Smith, Brad Sent: Friday, August 19, 2005 7:29 AM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] User SIDs... Hello All, Does anyone know the default length a users SID (Win2K DC's, WinXP SP2clients ) can be before problems such as http://support.microsoft.com/?kbid=327825 <http://support.microsoft.com/?kbid=327825> start occuring ? Also, there anyway to determine the actual length of a users SID??? TIA, Brad This email and any attached files are confidential and copyright protected. If you are not the addressee, any dissemination of this communication is strictly prohibited. Unless otherwise expressly agreed in writing, nothing stated in this communication shall be legally binding. 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/ 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/
