Hi Joe - I had already studied the 327825 fix, but have re-read it again now - thanks for the hint. It doesn't really state any specifics about how it changes the storage of the SIDs in a Kerberos ticket, but the new formula given for the calculation does provide some hints that confirm your statement rdg. the RIDs being used.
Basically I'd interpret is as such that all Domain Local Groups (even from the own domain) plus all groups from external domain AND all SID-History SIDs are stored as full SIDs in the token, while only all global and universal groups from the own domain are stored as RIDs. This means, that the SID-History tokens (which are naturally from external domains anyways) will definitely make quite a difference in the token sizes... A rough calculation according to the new formula allows to store approx. 225 groups (50/50 internal/external) without requiring to increasing the MaxTokenSize limit. And with almost all objects containing SID-history, I'd say this fix will grant you approx. 100 "real" group memberships (ofcourse everyone's milage will vary, depending on the group types...) /Guido -----Original Message----- From: Joe [mailto:[EMAIL PROTECTED] Sent: Freitag, 29. August 2003 05:04 To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] Problems with too many nested group memberships Hey Guido. It seems that the notechain I have involves the fix in 327825 and that applying that change to the DC's should be enough because the client pieces were already in place or had been in place all along. The client handles the whole expansion process and looking at the post from Carlos (thanks Carlos and Hi right back at ya) the GroupCount/GroupIds fields explanation for the kerb ticket seem, at least to me at first blush, to be verification. The note chain I have is very high level, no level of detail like the doc Carlos posted. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joe Sent: Thursday, August 28, 2003 7:19 AM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] Problems with too many nested group memberships Also I seem to recall them saying that the functionality has been on the client receiving side for some time, they just never added the functionality to the DC side because I had responded with a question similar to yours Guido. joe -----Original Message----- From: Joe [mailto:[EMAIL PROTECTED] Sent: Thursday, August 28, 2003 7:16 AM To: '[EMAIL PROTECTED]' Subject: RE: [ActiveDir] Problems with too many nested group memberships I'll see if I can dig up the note I have from PSS on it. joe -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of GRILLENMEIER,GUIDO (HP-Germany,ex1) Sent: Thursday, August 28, 2003 3:59 AM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] Problems with too many nested group memberships Joe, do you have any more info on this? I'm just wondering how this should work - if a Kerberos token only stores the RID of a group, which process would then explode that information to the full SID format when it is needed to analyse ACLs for the effective permissions of the user? If this is done by a certain fix (which one?) then this would change the whole picture of authentication processing for Windows 2000 and would probably be required on all machines that receive this "new version" of the Kerberos ticket... Would be glad to read more about this - thanks, Guido -----Original Message----- From: Joe [mailto:[EMAIL PROTECTED] Sent: Mittwoch, 27. August 2003 14:11 To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] Problems with too many nested group memberships I agree on the cleanup the sid history's. Also the number of groups you are in before you break can vary greatly based on where in the forest the groups are located at. One of the fixes implemented changes how the group information is stored in the token, if the groups are all local to the domain the user is in then only the RID is needed, however if the groups are from other domains, the entire SID is stored this would be the difference in space usage of something like: S-1-5-21-1275210071-789336058-1957994488-3146 and 3146 -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of GRILLENMEIER,GUIDO (HP-Germany,ex1) Sent: Wednesday, August 27, 2003 7:41 AM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] Problems with too many nested group memberships Tony, I believe that the 1000 SID limit is only relevant for NTLM authentication - the Kerberos ticket excepts a far smaller number of SIDs in the Token by default (roughly 120). With the number of group-memberships that you have (likely more than 120), it sounds like you'll have to increase the MaxTokenSize value in your environment (even after applying the fix http://support.microsoft.com/default.aspx?scid=kb;[LN];327825) As you'll be authenticated via Kerberos on the Server you're trying to join to AD at the time of joining it, I'd try to change the in the MaxTokenSize value in the registry on the server itself PRIOR to joining it to AD. Also - have the groups which the user is a mebmer of been migrated with SID-History? In this case you'll have 2 SIDs per group which further decreases the number of "real" groups your Kerberos ticket will be able to accept by default to approx. 60. /Guido -----Original Message----- From: Tony Murray [mailto:[EMAIL PROTECTED] Sent: Dienstag, 26. August 2003 16:16 To: [EMAIL PROTECTED] Subject: [ActiveDir] Problems with too many nested group memberships I'm hoping someone can shed some light on this. The background.... A while ago some admins had problems joining servers to an AD domain. The error was: "The Parameter is incorrect" We narrowed it down to the fact that the admins with problems had a large number of nested group memberships (400+). If we removed the group memberships the admin could join the server to the domain with no problem. We opened a call with Microsoft PSS, who advised us to install the hotfix mentioned in http://support.microsoft.com/default.aspx?scid=kb;[LN];327825 We duly installed the hotfix an all DCs. Now it seems we have the problem again, albeit intermittently. We re-opened the case with PSS and they have advised us that the problem is due to the accumulation of too many SIDs in the access token (http://support.microsoft.com/default.aspx?scid=kb;[LN];275266). There is no workaround apparently, this is behaviour by design. The problem I have with this is that, even with nesting, the "problem" accounts are members far few than the 1000 groups mentioned in the KB article. This is still open with PSS. Obviously, we have a workaround to the problem, but it is frustrating not knowing the true cause behind the issue. The only thing we know is that it has "something" to do with the size of the access token, but no real detail. Anyone come across the same (or similar) problem? Any pointers? Tony List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
