[cifs-protocol] RE: 600634 - RE: salt used for various principal types
Andrew Microsoft does use different methods of calculating the salt value used in encryption depending on the type account that is submitted to the salt calculation implementation. For example, in the case of interdomain trust accounts, "krbtgt" is appended. In the case of machine accounts, "host" is appended to the start of the salt value. Implementers are free to implement a salt algorithm of their choice, without affecting interoperability. In the case of the implementation acting as a KDC, the KDC that changes a password also stores that salt value in Active Directory in the supplementalCredentials field. In the case of a client using a salt value the KDC does not know how to interpret, the KDC will tell the client which salt value to use. We also have a related issue we are working together, where we have documented what the salt value structure stored in AD looks as part of the work we are currently doing on the supplementalCredentials structure. This value is stored as a UNICODE_STRING as per the documentation on KERB_STORED_CREDENTIAL (section 2.2.10.4 Primary:Kerberos - KERB_STORED_CREDENTIAL) and KERB_STORED_CREDENTIAL_NEW (Section 2.2.10.6 Primary:Kerberos-Newer-Keys - KERB_STORED_CREDENTIAL_NEW). Please let us know if you have further questions. Richard Guthrie Open Protocols Support Team Support Escalation Engineer, US-CSS DSC PROTOCOL TEAM Tel: +1 (469) 775-7794 E-mail: [EMAIL PROTECTED] We're hiring http://members.microsoft.com/careers/search/details.aspx?JobID=A976CE32-B0B9-41E3-AF57-05A82B88383E&start=1&interval=10&SortCol=DatePosted -Original Message- From: Richard Guthrie Sent: Tuesday, August 05, 2008 11:27 AM To: 'Andrew Bartlett' Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: 600634 - RE: salt used for various principal types Andrew, I will be working with you to resolve this issue. I will conduct my research and get back with you shortly. Richard Guthrie Open Protocols Support Team Support Escalation Engineer, US-CSS DSC PROTOCOL TEAM 7100 N Hwy 161, Irving, TX - 75039 "Las Colinas - LC2" Tel: +1 469 775 7794 E-mail: [EMAIL PROTECTED] We're hiring http://members.microsoft.com/careers/search/details.aspx?JobID=A976CE32-B0B9-41E3-AF57-05A82B88383E&start=1&interval=10&SortCol=DatePosted -Original Message- From: Andrew Bartlett [mailto:[EMAIL PROTECTED] Sent: Monday, August 04, 2008 9:19 PM To: Interoperability Documentation Help Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: salt used for various principal types I can't find any reference in either MS-ADTS or MS-KILE regarding the salt used for for the different types of principals in the kerberos protocol. (A salt is used as a confounded in string2key operations in kerberos) I know there are different salt calculations for users and computers, and presumably again for interdomain trust accounts. See: http://lists.samba.org/archive/samba-technical/2004-November/037976.html In particular, as I am working on interdomain trusts, and so in addition to the information at that URL, I need to know if there is a different salt used on the domain$ principal as compared to the krbtgt/[EMAIL PROTECTED] principal? Thanks, Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
RE: [Pfif] [cifs-protocol] Clarify AEAD behaviour for GSSAPI with AES
Andrew, In this case, you provided a diagram for us to add to the document and metze added some comments. Thanks for your contribution to our documentation and continued feedback. The product team reviewed the diagram and comments provided. We believe that the diagrams imply interaction between elements and without detailed notes they are subject to multiple interpretation and hence confusion.We believe that as a matter of providing deterministic documentation, we would prefer to provide specific examples. We'll be happy to get your feedback on creating examples and send them for your review once they are ready. Thanks ! Hongwei -Original Message- From: Andrew Bartlett [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 19, 2008 8:17 PM To: Hongwei Sun Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; Stefan (metze) Metzmacher Subject: Re: [Pfif] [cifs-protocol] Clarify AEAD behaviour for GSSAPI with AES On Fri, 2008-08-08 at 09:17 +0200, Stefan (metze) Metzmacher wrote: > Hongwei, > > >The encryption function in Kerberos is described in details in 5.3 > > [RFC3961] (http://www.ietf.org/rfc/rfc3961.txt), which is referenced by > > [MS-KILE]. > > I can summarize as follows > > > > * "conf" is actually a random confounder prefix of length c ,such > > as 16. > > > > * "pad" is for shortest padding to bring confounder and plaintext > > to a length that is the multiple of message block size m, which is octet(8) > > for AES encryption, as specified in section 6 [RFC 3962] > > (http://www.ietf.org/rfc/rfc3962.txt) > > > > * Ke is an encryption key and Ki is a checksum key. > > > > * Plain text is the input confidential data before encryption. > > > > * The GSSWrapEX() is exactly the same as the GSSWrap except that > > it supports ordered list of input buffers. Input buffers for which > > conf_req_flag == TRUE are encrypted and returned. Buffers which sign == > > TRUE are included in the signature. > > > > It would be extremly useful if the MS-RPCE document would explain what > the exact input buffers to GssWrapEX() are and what flags are used in > each of the cases (with and without header signing). > > Then it would be useful to know to what exactly SSPI EncryptMessage > call this is mapped. > > And finally how each of the of the encryption types (des-*, > arcfour-hmac-md5, and aes-*) are supposed to process the > EncryptMessage input. > > It would be nice if you could use a realistic example, with explicit > values. A bit like the "A.5 Test suite" section of RFC1321 - The MD5 > Message-Digest Algorithm. While we have Microsoft's bugs and features in this area worked around, this is the level of documentation this area needs. Has there been any more progress on this? (We didn't seem to get to this on the call today). Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] RE: 601628 RE: Mapping of MS-LSAD onto LDAP and DRS replications
Andrew, The link between G$$ and trustAuthIncoming is that G$$ is where the password for the trust was stored prior to active directory (I.E. NT4 for example). If the trust is a trust between Active Directory enabled domains, the TDO object is where the trust passwords are stored. I was mistaken when I spoke previously, stating that if you use the method LsarSetTrustedDomainInfo with InformationClass==TrustedPasswordInformation you would be able to modify trustAuthIncoming/ trustAuthOutgoing values. You can only modify secret objects when you have InformationClass==TrustedPasswordInformation. If you want to manipulate trustAuthIncoming/trustAuthOutgoing, you would need to set InformationClass = TrustedDomainInformationEx. One point to note is that this method requires all the fields on the TDO passed in the TrustedDOmainInformation object be set properly. The preferred means of modifying trustAuthIncoming/trustAuthOutgoing attributes on the TDO is through the use of LsarSetInformationTrustedDomain. We have also made a modification to the MS-LSAD document for section 3.1.4.7.3 to make the portion about TrustedPasswordInformation more clear that it refers to manipulation of a secret object. Here is the revised text below with the reference to section 3.1.1.4: TrustedPasswordInformation: The server MUST verify that a trusted domain object with this SID exists in its policy database. If the object does not exist, the call MUST fail with STATUS_NO_SUCH_DOMAIN. Otherwise, the server MUST open the secret object, as defined in section 3.1.1.4, (or create a secret object, if one does not already exist) with "Name" set to "G$$". The server MUST then set "Old Value" of the secret object to the "OldPassword" value in TrustedDomainInformation and set "New Value" of the secret object to the "Password" value in TrustedDomainInformation, similar to the processing when an LsarSetSecret request has been made. Please let us know if you have any additional questions regarding this issue. Richard Guthrie Open Protocols Support Team Support Escalation Engineer, US-CSS DSC PROTOCOL TEAM Tel: +1 (469) 775-7794 E-mail: [EMAIL PROTECTED] We're hiring http://members.microsoft.com/careers/search/details.aspx?JobID=A976CE32-B0B9-41E3-AF57-05A82B88383E&start=1&interval=10&SortCol=DatePosted -Original Message- From: Andrew Bartlett [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 12, 2008 10:51 PM To: Richard Guthrie Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: 601628 RE: Mapping of MS-LSAD onto LDAP and DRS replications On Tue, 2008-08-12 at 19:57 -0700, Richard Guthrie wrote: > Andrew, > We have completed our investigation of your request to include information > linking the structures in the backing store for LSA with the MS-LSAD > documents. We have focused on the methods related to trusted domain > operations. The list of these methods can be found in section 3.1.4.7. To > summarize, all of these methods deal with various aspects of > manipulating/querying Trusted Domain Objects as defined in section 7.1.6 of > the MS-ADTS documentation. I think we still have a fair way to go with this, but that at least provides some of the missing links. I'll note that on further reading, much of what I'm after can actually be answered pretty simply - if the table in MS-LSAD 3.1.1.5 and MS-ADTS 7.1.6.7 were combined. But as to your response, as a start, I'll pick on: > 3.)InformationClass == TrustedPasswordInformation > LSAPR_TRUSTED_PASSWORD_INFO (MS-LSAD section 2.2.46) This can be any > of the stored secret objects on the TDO such as TrustAuthIncoming and > TrustAuthOutgoing (MS-ADTS section 7.1.6.7.10 and 7.1.6.7.11) So (and this in part relates to my broader question), what is the link between G$$ secrets and trustAuthIncoming. Please specify to the extent that given an LDAP database, possibly containing such trust objects, I could both set and query these values, with the this call and with the secrets calls. Thanks, Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] RE: Secret 'last set times' doc incorrect in 2008 - 600578
Andrew, I will be working with you to resolve your issue. I had a quick question to help with our research: If you have a secret object with old/new secret values set. They also both have a timestamp indicating when the values were last updated/set. You call LsarSetSecret passing in null for new secret value and some value for old secret value. You observe that the old secret value timestamp = ?, You observe that the new secret value timestamp = ? (Please let me know what these values are in the test you reference). Richard Guthrie Open Protocols Support Team Support Escalation Engineer, US-CSS DSC PROTOCOL TEAM Tel: +1 (469) 775-7794 E-mail: [EMAIL PROTECTED] We're hiring http://members.microsoft.com/careers/search/details.aspx?JobID=A976CE32-B0B9-41E3-AF57-05A82B88383E&start=1&interval=10&SortCol=DatePosted -Original Message- From: Andrew Bartlett [mailto:[EMAIL PROTECTED] Sent: Monday, August 25, 2008 7:01 PM To: Interoperability Documentation Help Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Secret 'last set times' doc incorrect in 2008 In MS-LSAD 3.1.4.6.3 LsarSetSecret it states that: The server MUST also maintain "time stamp" values for current and old values of the secret object. The following table lists the rules by which the time stamps are computed. Value Effect on old time Effect on new time Old secret valueNULL Old value of "new secret time" Not applicable Old secret valueNon-NULL Current server timeNot applicable New secret valueNULL Not applicable Current server time New secret valueNon-NULL Not applicable Current server time However, tests against Window 2008 show that setting the old value (but not the new) removes the new value, and sets the time to 'current server time' Please update the docs, Thanks, Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] RE: How are 'supported enc types' determined in trusts? - 600253
Andrew, I will be working with you regarding this issue. I wanted to clarify your statement regarding downlevel domain. Are you referring to a windows 2008 server acting as a domain controller in a downlevel domain? I will get back to you shortly once I have completed my research. Richard Guthrie Open Protocols Support Team Support Escalation Engineer, US-CSS DSC PROTOCOL TEAM Tel: +1 (469) 775-7794 E-mail: [EMAIL PROTECTED] We're hiring http://members.microsoft.com/careers/search/details.aspx?JobID=A976CE32-B0B9-41E3-AF57-05A82B88383E&start=1&interval=10&SortCol=DatePosted -Original Message- From: Andrew Bartlett [mailto:[EMAIL PROTECTED] Sent: Monday, August 25, 2008 6:24 PM To: Interoperability Documentation Help Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: How are 'supported enc types' determined in trusts? In MS-LSAD 3.1.1.5 Supported Encryption Types It states the mapping between bits are supported encryption types. In MS-ADTS 7.1.6.7.3 we find the backing attribute is msDs-supportedEncryptionTypes. My question is, if a Windows 2008 server in a downlevel domain, and so trusted domain objects do not include msDs-supportedEncryptionTypes (or a 'set' was never performed on this LSA information level), what value will this attribute have? Is it dependent on the trust type/attributes flags for example? Thanks, Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] RE: 600634 - RE: salt used for various principal types
On Tue, 2008-08-26 at 08:37 -0700, Richard Guthrie wrote: > Andrew > > Microsoft does use different methods of calculating the salt value > used in encryption depending on the type account that is submitted to > the salt calculation implementation. For example, in the case of > interdomain trust accounts, "krbtgt" is appended. In the case of > machine accounts, "host" is appended to the start of the salt value. > > Implementers are free to implement a salt algorithm of their choice, without > affecting interoperability. This would be true, but this applies only to objects of the type normally found under cn=users. The salt to use for a password stored in trustAuthIncoming/trustAuthOutgoing must be specified in the docs. It is not possible to negotiate an alternate salt for the AES or DES keys of interdomain trusts in Kerberos. In any case, the salts as you describe should be included in a discussion of the Microsoft KDC. Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. signature.asc Description: This is a digitally signed message part ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] RE: How are 'supported enc types' determined in trusts? - 600253
On Tue, 2008-08-26 at 15:05 -0700, Richard Guthrie wrote: > Andrew, I will be working with you regarding this issue. I wanted to > clarify your statement regarding downlevel domain. Are you referring > to a windows 2008 server acting as a domain controller in a downlevel > domain? I will get back to you shortly once I have completed my > research. Yeah, I'm imagining any situation where the Windows 2008 codebase would need to operate without that attribute in the backing store. I presume this would occur if it were part of a Win2k3 level domain, for example. Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. signature.asc Description: This is a digitally signed message part ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] RE: 601628 RE: Mapping of MS-LSAD onto LDAP and DRS replications
On Tue, 2008-08-26 at 11:11 -0700, Richard Guthrie wrote: > Andrew, > > The link between G$$ and trustAuthIncoming is > that G$$ is where the password for the trust > was stored prior to active directory (I.E. NT4 for example). If the > trust is a trust between Active Directory enabled domains, the TDO > object is where the trust passwords are stored. I was mistaken when I > spoke previously, stating that if you use the method > LsarSetTrustedDomainInfo with > InformationClass==TrustedPasswordInformation you would be able to > modify trustAuthIncoming/ trustAuthOutgoing values. You can only > modify secret objects when you have > InformationClass==TrustedPasswordInformation. If you want to > manipulate trustAuthIncoming/trustAuthOutgoing, you would need to set > InformationClass = TrustedDomainInformationEx. One point to note is > that this method requires all the fields on the TDO passed in the > TrustedDOmainInformation object be set properly. The preferred means > of modifying trustAuthIncoming/trustAuthOutgoing attributes on the TDO > is through the use of LsarSetInformationTrustedDomain. > > We have also made a modification to the MS-LSAD document for section > 3.1.4.7.3 to make the portion about TrustedPasswordInformation more > clear that it refers to manipulation of a secret object. Here is the > revised text below with the reference to section 3.1.1.4: > > TrustedPasswordInformation: The server MUST verify that a trusted > domain object with this SID exists in its policy database. If the > object does not exist, the call MUST fail with STATUS_NO_SUCH_DOMAIN. > Otherwise, the server MUST open the secret object, as defined in > section 3.1.1.4, (or create a secret object, if one does not already > exist) with "Name" set to "G$$". The server MUST > then set "Old Value" of the secret object to the "OldPassword" value > in TrustedDomainInformation and set "New Value" of the secret object > to the "Password" value in TrustedDomainInformation, similar to the > processing when an LsarSetSecret request has been made. > Please let us know if you have any additional questions regarding this > issue. So, the secrets are another parallel to the trustAuthIncoming and trustAuthOutgoing? The modified text does not reference trustAuthIncoming or trustAuthOutgoing, so I'm confused. Also, how do the cn=users object is influenced by these calls? Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. signature.asc Description: This is a digitally signed message part ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] RE: Secret 'last set times' doc incorrect in 2008 - 600578
On Tue, 2008-08-26 at 14:21 -0700, Richard Guthrie wrote: > Andrew, > > I will be working with you to resolve your issue. I had a quick > question to help with our research: > > If you have a secret object with old/new secret values set. They also > both have a timestamp indicating when the values were last > updated/set. You call LsarSetSecret passing in null for new secret > value and some value for old secret value. You observe that the old > secret value timestamp = ?, You observe that the new secret value > timestamp = ? (Please let me know what these values are in the test > you reference). The old secret timestamp and the new secret timestamp is 'current server time' (or at least the same, my tests don't actually verify the clock). http://gitweb.samba.org/?p=samba.git;a=blob;f=source/torture/rpc/lsa.c;h=ec74426ac6487be632441ca925342eac2466914b;hb=0c4227e45d6b8e31a0219358042318e9d2a0b36d#l1276 Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. signature.asc Description: This is a digitally signed message part ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] RE: Secret 'last set times' doc incorrect in 2008 - 600578
On Wed, 2008-08-27 at 08:50 +1000, Andrew Bartlett wrote: > On Tue, 2008-08-26 at 14:21 -0700, Richard Guthrie wrote: > > Andrew, > > > > I will be working with you to resolve your issue. I had a quick > > question to help with our research: > > > > If you have a secret object with old/new secret values set. They also > > both have a timestamp indicating when the values were last > > updated/set. You call LsarSetSecret passing in null for new secret > > value and some value for old secret value. You observe that the old > > secret value timestamp = ?, You observe that the new secret value > > timestamp = ? (Please let me know what these values are in the test > > you reference). > > The old secret timestamp and the new secret timestamp is 'current server > time' (or at least the same, my tests don't actually verify the clock). > > http://gitweb.samba.org/?p=samba.git;a=blob;f=source/torture/rpc/lsa.c;h=ec74426ac6487be632441ca925342eac2466914b;hb=0c4227e45d6b8e31a0219358042318e9d2a0b36d#l1276 > > Andrew Bartlett I should note, that the changes to implement this in our code were mostly to remove the distinction between global and local secrets. ie http://gitweb.samba.org/?p=samba.git;a=commitdiff;h=da200ac64485fd9531b1aa048570c682b680b012;hp=1f12c368b2566b378a6c521c389b8b1bafbcf916 -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. signature.asc Description: This is a digitally signed message part ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
RE: [cifs-protocol] What are the POLICY_DOMAIN_KERBEROS_TICKET_INFO flags?
Andrew, I will be working on this request and I'll let you know when I have the information for you. Thanks ! Hongwei -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andrew Bartlett Sent: Monday, August 25, 2008 8:31 PM To: Interoperability Documentation Help Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: [cifs-protocol] What are the POLICY_DOMAIN_KERBEROS_TICKET_INFO flags? In MS-LSAD 2.2.53 POLICY_DOMAIN_KERBEROS_TICKET_INFO, it states: AuthenticationOptions: Optional flags that affect validations performed during authentication. What are the optional flags, what do they do, and where are they defined? (this is the packet against Windows 2008) trying QueryDomainInformationPolicy level 3 lsa_QueryDomainInformationPolicy: struct lsa_QueryDomainInformationPolicy in: struct lsa_QueryDomainInformationPolicy handle : * handle: struct policy_handle handle_type : 0x (0) uuid : 5b01caf4-d140-4325-b851-18cafb0c251c level: 0x0003 (3) lsa_QueryDomainInformationPolicy: struct lsa_QueryDomainInformationPolicy out: struct lsa_QueryDomainInformationPolicy info : * info : union lsa_DomainInformationPolicy(case 3) kerberos_info: struct lsa_DomainInfoKerberos enforce_restrictions : 0x0080 (128) service_tkt_lifetime : 0x0053d1ac1000 (3600) user_tkt_lifetime: 0x0053d1ac1000 (3600) user_tkt_renewaltime : 0x058028e44000 (60480) clock_skew : 0xb2d05e00 (30) unknown6 : 0x (0) result : NT_STATUS_OK Thanks, Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] RE: How to validate the PAC in NETLOGON
On Fri, 2008-08-08 at 08:29 -0700, Richard Guthrie wrote: > Andrew, > > Thank you for the request. I will be working with you on this issue. > I need to review the documentation and will get back to you with a > response shortly. What happened here? I've been attempting to implement this regardless of the unclear docs, but at least a way of getting windows to emit this request would be very useful. Thanks, Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. signature.asc Description: This is a digitally signed message part ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
