Here is some info just to understand what sits inside the ticket and how its used,
To validate the request and the digital signature on it, the KDC will first validate a certificate. The KDC will query the Active Directory for a mapping between the certificate and a Windows 2000 SID; if it finds a mapping, it will issue a TGT for the corresponding SID.
The Windows 2000 KDC creates a new service ticket for the user principal to access the resource.
INFO IN THE TICKET:
KickOffTime - the time at which the server should forcibly logoff
the client. If the client should not be forced off, this
field should be set to (0x7fffffff,0xffffffff).
UserId - This field contains the relative Id for the client. If
zero, then the User ID is the first SID in the ExtraSids
field.
PrimaryGroupId - This field contains the relative ID for this
clients primary group.
GroupCount - This field contains the number of groups, within the
clientÆs domain, to which the client is a member.
GroupIds - This field contains an array of the relative Ids and
attributes of the groups in the clients domain of which the
client is a member.
UserFlags - This field contains information about which fields in
this structure are valid. The two bits that may be set are
indicated below. Having these flags set indicates that the
corresponding fields in the KERB_VALIDATION_INFO structure
are present and valid.
#define LOGON_EXTRA_SIDS 0x0020
#define LOGON_RESOURCE_GROUPS 0x0200
LogonDomainId - This field contains the SID of the clientÆs domain.
This field is used in conjunction with the UserId,
PrimaryGroupId,and GroupIds fields to create the user and
group SIDs for the client.
SidCount - This field contains the number of SIDs present in the
ExtraSids field. This field is only valid if the
LOGON_EXTRA_SIDS flag has been set in the UserFlags field.
ExtraSids - This field contains a list of SIDs for groups to which
the user is a member. This field is only valid if the
LOGON_EXTRA_SIDS flag has been set in the UserFlags field.
ResouceGroupCount - This field contains the number of resource
groups in the ResourceGroupIds field. This field is only
valid if the LOGON RESOURCE_GROUPS flag has been set in the
UserFlags field._
ResourceGroupDomainSid - This field contains the SID of the resource
domain. This field is used in conjunction with the
ResourceGroupIds field to create the group SIDs for the
client.
ResourceGroupIds - This field contains an array of the relative Ids
and attributes of the groups in the resource domain of which
the resource is a member.
When used in the KERB_VALIDATION_INFO, this is NDR encoded. The
FILETIME type is defined as follows:
typedef unsigned int DWORD;
typedef struct _FILETIME {
DWORD dwLowDateTime;
DWORD dwHighDateTime;
} FILETIME;
Times are encoded as the number of 100 nanosecond increments since
January 1, 1601, in UTC time.
When used in the KERB_VALIDATION_INFO, this is NDR encoded. The
UNICODE_STRING structure is defined as:
typedef struct _UNICODE_STRING
USHORT Length;
USHORT MaximumLength;
[size_is(MaximumLength / 2), length_is((Length) / 2) ]
USHORT * Buffer;
} UNICODE_STRING;
The Length field contains the number of bytes in the string, not
including the null terminator, and the MaximumLength field contains
the total number of bytes in the buffer containing the string.
The GROUP_MEMBERSHIP structure contains the relative ID of a group
and the corresponding attributes for the group.
typedef struct _GROUP_MEMBERSHIP {
ULONG RelativeId;
ULONG Attributes;
} *PGROUP_MEMBERSHIP;
The group attributes must be:
#define SE_GROUP_MANDATORY (0x00000001L)
#define SE_GROUP_ENABLED_BY_DEFAULT (0x00000002L)
#define SE_GROUP_ENABLED (0x00000004L)
The SID structure is defined as follows:
typedef struct _SID_IDENTIFIER_AUTHORITY {
UCHAR Value[6];
} SID_IDENTIFIER_AUTHORITY, *PSID_IDENTIFIER_AUTHORITY;
The constant value for the NT Authority is
#define SECURITY_NT_AUTHORITY {0,0,0,0,0,5}
typedef struct _SID {
UCHAR Revision;
UCHAR SubAuthorityCount;
SID_IDENTIFIER_AUTHORITY IdentifierAuthority;
[size_is(SubAuthorityCount)] ULONG SubAuthority[*];
} SID, *PSID;
The SubAuthorityCount field contains the number of elements in the
actual SubAuthority conformant array. The maximum number of
subauthorities allowed is 15.
The KERB_SID_AND_ATTRIBUTES structure contains entire group SIDs and
their corresponding attributes:
typedef struct _KERB_SID_AND_ATTRIBUTES {
PSID Sid;
ULONG Attributes;
} KERB_SID_AND_ATTRIBUTES, *PKERB_SID_AND_ATTRIBUTES;
The attributes are the same as the group attributes defined above.
Signatures (PAC_SERVER_CHECKSUM and PAC_PRIVSVR_CHECKSUM)
The PAC contains two digital signatures: one using the key of the
server, and one using the key of the KDC. The signatures are present
for two reasons. First, the signature with the serverÆs key is
present to prevent a client from generating their own PAC and
sending it to the KDC as encrypted authorization data to be included
in tickets. Second, the signature with the KDCÆs key is present to
prevent an untrusted service from forging a ticket to itself with an
invalid PAC. The two signatures are sent in PAC_INFO_BUFFERs of type
PAC_SERVER_CHECKSUM and PAC_PRIVSVR_CHECKSUM respectively.
The signatures are contained in the following structure:
typedef struct _PAC_SIGNATURE_DATA {
ULONG SignatureType;
UCHAR Signature[1];
} PAC_SIGNATURE_DATA, *PPAC_SIGNATURE_DATA;
The fields are defined as follows:
SignatureType - This field contains the type of checksum used to
create a signature. The checksum must be a keyed checksum.
Signature - This field consists of an array of bytes containing the
checksum data. The length of bytes may be determined by the
wrapping PAC_INFO_BUFFER structure.
For the serverÆs checksum, the key used to generate the signature
should be the same key used to encrypt the ticket. Thus, if the
enc_tkt_in_skey option is used, the session key from the serverÆs
TGT should be used. The Key used to encrypt ticket granting tickets
is used to generate the KDCÆs checksum.
The checksums are computed as follows:
1. The complete PAC is built, including space for both checksums
2. The data portion of both checksums is zeroed.
3. The entire PAC structure is checksummed with the serverÆs key,
and the result is stored in the serverÆs checksum structure.
4. The serverÆs checksum is then checksummed with the KDC's key.
5. The checksum with the KDC key is stored in the KDC's checksum
structure.
PAC Request Pre-Auth Data
Normally, the PAC is included in every pre-authenticated ticket
received from an AS request. However, a client may also explicitly
request either to include or to not include the PAC. This is done by
sending the PAC-REQUEST preauth data.
This is an ASN.1 encoded structure.
KERB-PA-PAC-REQUEST ::= SEQUENCE {
include-pac[0] BOOLEAN -- if TRUE, and no pac present,
-- include PAC.
---If FALSE, and pac
-- PAC present, remove PAC
}
The fields are defined as follows:
include-pac - This field indicates whether a PAC should be included
or not. If the value is TRUE, a PAC will be included
independent of other preauth data. If the value is FALSE,
then no PAC will be included, even if other preauth data is
present.
The preauth ID is:
#define KRB5_PADATA_PAC_REQUEST 128
Security Considerations
Before the PAC data is used for access control, the
PAC_SERVER_CHECKSUM signature MUST be checked. This will verify that
the provider of the PAC data knows the server's secret key.
Validation of the PAC_PRIVSVR_CHECKSUM is OPTIONAL. It is used to
verify that the PAC was issued from the KDC and not placed in the
ticket by someone other than the KDC with access to the service key.
Caution must be used with accepting the SIDs present in the logon-
info part of the PAC. Only SIDs from a domain that is authoritative
for a particular domain's SIDs should be used in the construction of
access tokens. If a SID is found to be from outside of a domain's
authoritative SID namespace, it MUST be ignored for purposes of
access control.
Hope that sheds some deeper light into the subject ;P
CARLOS MAGALHAES HTTP://GROUPS.YAHOO.COM/GROUP/ADSIANDDIRECTORYSERVICES
P.s.
Hey ya JOE!
-----Original Message-----
From: Joe [mailto:[EMAIL PROTECTED]]
Sent: Thursday, August 28, 2003 1:19 PM
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/
------------------------------------------------------------- This email and any files transmitted are confidential and intended solely for the use of the individual or entity to which they are addressed, whose privacy should be respected. Any views or opinions are solely those of the author and do not necessarily represent those of the Trencor Group, or any of its representatives, unless specifically stated.
Email transmission cannot be guaranteed to be secure, error free or without virus contamination. The sender therefore accepts no liability for any errors or omissions in the contents of this message, nor for any virus infection that might result from opening this message. Trencor is not responsible in the event of any third party interception of this email. If you have received this email in error please notify [EMAIL PROTECTED] For more information about Trencor, visit www.trencor.net <http://www.trencor.net>
