Hi Obaid, On ma, 04 marras 2019, Obaid Farooqi wrote: > Hi Alehander: > I just want to correct a typo in my email. I said " > msDS-Supported-Encryption-Types was introduced in ws20018.". It is > supposed to be " msDS-Supported-Encryption-Types was introduced in > ws2008." > > I am sure you understood what I meant but for the sake of record, I am > hereby correcting the error.
Yes, this was clearly a typo but thank you for the correction. > > Regards, > Obaid Farooqi > Escalation Engineer | Microsoft > > Exceeding your expectations is my highest priority. If you would like to > provide feedback on your case you may contact my manager at ramagane at > Microsoft dot com > > -----Original Message----- > From: Alexander Bokovoy <[email protected]> > Sent: Saturday, November 2, 2019 4:03 AM > To: Obaid Farooqi <[email protected]> > Cc: [email protected]; support > <[email protected]> > Subject: Re: Significance of empty TrustedDomainSupportedEncryptionTypes > value in a TDO 119101021001658 > > Hi Obaid, > > On pe, 01 marras 2019, Obaid Farooqi wrote: > > Hi Alexander: > > msDS-Supported-Encryption-Types was introduced in ws20018. When > > trustedDomain object is first created, it does not contain > > msDs-Supported-Encryption-Types attribute. If you query this > > attribute, the result would be what you are observing. > > For the msDS-Supported-Encryption-Types attribute to be created, an > > admin has to explicitly turn on AES support using MMC snap-in "Active > > Directory Domains and Trust". You can find how it is done in the > > following article: > > > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsupp > > ort.microsoft.com%2Fen-us%2Fhelp%2F4492348%2Fkerberos-unsupported-etyp > > e-error-when-authenticating-across-trust&data=02%7C01%7Cobaidf%40m > > icrosoft.com%7C98e161317e1b4a1099b208d75f736f95%7C72f988bf86f141af91ab > > 2d7cd011db47%7C1%7C0%7C637082821735529131&sdata=yQnHO9UdQlxQ5jovIM > > D40D7fu2FWIV%2FV2P%2FMlPERvqM%3D&reserved=0 > > > > So, it is an explicit step that needed to be perform for > > msDS-Supported-Encryption-Typse to exit. > > > > If you enable AES encryption by using the above method and then > > disable it, msDS-Supported-Encryption-Types will be set to zero again. > > > > Please let me know if this does not answer your question. > > This would explain a behavior we saw in one customer case where a trust was > established between two Windows-based Active Directory domains, both are at > least Windows Server 2008. > > However, this doesn't explain why we saw it in another case where a trust was > established between FreeIPA and Windows Server 2019 AD forest. > FreeIPA explicitly sets supported encryption types using > LsarSetInformationTrustedDomain, information class > TrustedDomainSupportedEncryptionTypes, to bits C|D|E as per MS-KILE > 2.2.7 (RC-HMAC | AES128-CTS-HMAC-SHA1-96 | AES256-CTS-HMAC-SHA1-96). > > Now, that I think about it, there is one possibility to actually have the > msDS-Supported-Encryption-Types missing: when a trust is created by using a > shared secret by both sides. Here there is nothing on Windows Server side > that sets msDS-Supported-Encryption-Typse, as you noted. > And from FreeIPA side nothing calls LsarSetInformationTrustedDomain because > there are no credentials that would give such access. > > Thank you, I think this case can be closed. > > > > > Regards, > > Obaid Farooqi > > Escalation Engineer | Microsoft > > > > Exceeding your expectations is my highest priority. If you would like > > to provide feedback on your case you may contact my manager at > > ramagane at Microsoft dot com > > > > -----Original Message----- > > From: Obaid Farooqi > > Sent: Monday, October 21, 2019 3:31 PM > > To: Alexander Bokovoy <[email protected]> > > Cc: [email protected]; support > > <[email protected]> > > Subject: RE: Significance of empty > > TrustedDomainSupportedEncryptionTypes value in a TDO 119101021001658 > > > > Hi Alexander: > > Can you send the traces for your in house repro (unsuccessful > > notwithstanding)? > > That will help zero in on the area of the code that potentially could be > > responsible for empty TrustedDomainSupportedEncryptionTypes. > > > > Regards, > > Obaid Farooqi > > Escalation Engineer | Microsoft > > > > Exceeding your expectations is my highest priority. If you would like > > to provide feedback on your case you may contact my manager at > > ramagane at Microsoft dot com > > > > -----Original Message----- > > From: Alexander Bokovoy <[email protected]> > > Sent: Sunday, October 20, 2019 4:37 AM > > To: Obaid Farooqi <[email protected]> > > Cc: [email protected]; support > > <[email protected]> > > Subject: Re: Significance of empty > > TrustedDomainSupportedEncryptionTypes value in a TDO 119101021001658 > > > > Hi Obaid, > > > > On to, 17 loka 2019, Obaid Farooqi wrote: > > > Hi Alexander: > > > > > > I have uploaded a zip file name PartnerTTDRecorder_x86_x64.zip. Use the > > > following link and credentials to download the file. > > > > > > > > > Please copy the file to Windows Server and extract the contents of > > > amd64/TTD folder in a folder called c:\ttt and follow the following steps > > > to collect traces: > > > > > > 1. start an elevated cmd prompt and cd to c:\ttt 2. execute the > > > command below to find the PID of lsass process > > > C:\ttt>tasklist |findstr /i "lsass" > > > 3. Execute the following command to start tracing > > > C:\ttt>tttracer -attach PID > > > Where PID is the process id from step 2 > > > > > > 4. Wait for a small Windows to pop up titled "lsass01.run" > > > 5. Reproduce the problem > > > 6. After successful repro, clear the check box next to "Tracing..." in > > > lsass01.run window. Please do not click "Exit" button. Doing this will > > > crash your server. > > > 7. In the cmd windows opened in step 1, you will see message about > > > the creation of a file name lsass01.run 8. upload the file to the link > > > provided above and let me know. > > > > Thank you for the tracer. Unfortunately, I'm not able to reproduce the > > issue myself. I have two customer reports so far and both are in > > production, so it is not possible to install the tracer. > > > > > > > > > > Regards, > > > Obaid Farooqi > > > Escalation Engineer | Microsoft > > > -----Original Message----- > > > From: Obaid Farooqi > > > Sent: Thursday, October 17, 2019 2:19 PM > > > To: Alexander Bokovoy <[email protected]>; [email protected] > > > Cc: support <[email protected]> > > > Subject: RE: Significance of empty > > > TrustedDomainSupportedEncryptionTypes value in a TDO 119101021001658 > > > > > > Hi Alexander: > > > I am still working on this and will be in touch as soon as I have an > > > answer. > > > > > > Regards, > > > Obaid Farooqi > > > Escalation Engineer | Microsoft > > > > > > Exceeding your expectations is my highest priority. If you would > > > like to provide feedback on your case you may contact my manager at > > > ramagane at Microsoft dot com > > > > > > -----Original Message----- > > > From: Obaid Farooqi > > > Sent: Friday, October 11, 2019 11:06 AM > > > To: Alexander Bokovoy <[email protected]>; [email protected] > > > Cc: support <[email protected]> > > > Subject: RE: Significance of empty > > > TrustedDomainSupportedEncryptionTypes value in a TDO 119101021001658 > > > > > > [Tom to Bcc] > > > Hi Alexander: > > > I will help you with this issue and will be in touch as soon as I have an > > > answer. > > > > > > Regards, > > > Obaid Farooqi > > > Escalation Engineer | Microsoft > > > > > > -----Original Message----- > > > From: Tom Jebo <[email protected]> > > > Sent: Thursday, October 10, 2019 12:41 PM > > > To: Alexander Bokovoy <[email protected]>; [email protected] > > > Cc: support <[email protected]> > > > Subject: RE: Significance of empty > > > TrustedDomainSupportedEncryptionTypes value in a TDO 119101021001658 > > > > > > [dochelp to bcc] > > > [support mail to cc] > > > > > > Hi Alexander, > > > > > > Thanks for the question regarding encryption types in trusted domain > > > object. I have created case number 119101021001658 to track this issue > > > and placed the number in the subject of this email. Please refer to it > > > and leave it in the subject when communicating about this issue with our > > > team. One of the Open Specifications team members will get back to you > > > shortly. > > > > > > Best regards, > > > Tom Jebo > > > Sr Escalation Engineer > > > Microsoft Open Specifications > > > > > > > > > -----Original Message----- > > > From: Alexander Bokovoy <[email protected]> > > > Sent: Wednesday, October 9, 2019 11:09 PM > > > To: Interoperability Documentation Help <[email protected]>; > > > [email protected] > > > Subject: Significance of empty TrustedDomainSupportedEncryptionTypes > > > value in a TDO > > > > > > Hello dochelp, > > > > > > I'm seeing an increasing number of cases where trusted domain object, > > > when queried with LsarQueryInfoTrustedDomain operation, level > > > TrustedDomainSupportedEncryptionTypes, returns encryption types field set > > > to all zeros. The query is done with Active Directory domain's > > > administrator privileges, so access checks should grant this access. > > > > > > However, we see something similar to below, when querying > > > TrustedDomainSupportedEncryptionTypes information class of > > > LsarQueryInfoTrustedDomain between two Active Directory domains based on > > > Microsoft Windows Server versions, the returned value is set to 0: > > > > > > >rpcclient $> lsaquerytrustdominfobyname example.test 13 > > > > info : union lsa_TrustedDomainInfo(case 13) > > > > enc_types: struct lsa_TrustDomainInfoSupportedEncTypes > > > > enc_types : 0x00000000 (0) > > > > 0: KERB_ENCTYPE_DES_CBC_CRC > > > > 0: KERB_ENCTYPE_DES_CBC_MD5 > > > > 0: KERB_ENCTYPE_RC4_HMAC_MD5 > > > > 0: KERB_ENCTYPE_AES128_CTS_HMAC_SHA1_96 > > > > 0: KERB_ENCTYPE_AES256_CTS_HMAC_SHA1_96 > > > > 0: KERB_ENCTYPE_FAST_SUPPORTED > > > > 0: KERB_ENCTYPE_COMPOUND_IDENTITY_SUPPORTED > > > > 0: KERB_ENCTYPE_CLAIMS_SUPPORTED > > > > 0: KERB_ENCTYPE_RESOURCE_SID_COMPRESSION_DISABLED > > > > > > I cannot find any behavioral description for such configuration: > > > - what encryption types should be used by the clients to > > > communicate > > > - in which situations zeroed encryption types list is expected > > > - how zeroed encryption types list is affecting cross-realm > > > communication > > > - what versions of Windows Server introduced this change > > > > > > When such TDO is seen between forest root and in-forest domain, we also > > > see KDC_ERR_POLICY response from the forest root DC when a user from > > > in-forest domain attempts to access a resource in a domain from a > > > separate forest. The forests in question trust each other in a direction > > > of access. > > > > > > I have seen it happening with Windows Server 2019 but we have reports for > > > unspecified older versions (2008-2016). > > > > > > For completeness, here is how the trusted domain object looks like: > > > >----------------- > > > >rpcclient $> lsaquerytrustdominfobyname example.test 12 > > > > info : union lsa_TrustedDomainInfo(case 12) > > > > full_info2_internal: struct lsa_TrustDomainInfoFullInfo2Internal > > > > info: struct lsa_TrustDomainInfoInfoEx2Internal > > > > info_ex: struct lsa_TrustDomainInfoInfoEx > > > > domain_name: struct lsa_StringLarge > > > > length : 0x0018 (24) > > > > size : 0x001A (26) > > > > string : * > > > > string : 'example.test' > > > > netbios_name: struct lsa_StringLarge > > > > length : 0x000C (12) > > > > size : 0x000E (14) > > > > string : * > > > > string : 'EXAMPLE-TEST' > > > > sid : * > > > > sid : > > > > S-1-5-21-1234567890-1234567890-12345678 > > > > trust_direction : 0x00000003 (3) > > > > 1: LSA_TRUST_DIRECTION_INBOUND > > > > 1: LSA_TRUST_DIRECTION_OUTBOUND > > > > trust_type : LSA_TRUST_TYPE_UPLEVEL (2) > > > > trust_attributes : 0x00000020 (32) > > > > 0: LSA_TRUST_ATTRIBUTE_NON_TRANSITIVE > > > > 0: LSA_TRUST_ATTRIBUTE_UPLEVEL_ONLY > > > > 0: LSA_TRUST_ATTRIBUTE_QUARANTINED_DOMAIN > > > > 0: LSA_TRUST_ATTRIBUTE_FOREST_TRANSITIVE > > > > 0: LSA_TRUST_ATTRIBUTE_CROSS_ORGANIZATION > > > > 1: LSA_TRUST_ATTRIBUTE_WITHIN_FOREST > > > > 0: LSA_TRUST_ATTRIBUTE_TREAT_AS_EXTERNAL > > > > 0: LSA_TRUST_ATTRIBUTE_USES_RC4_ENCRYPTION > > > > forest_trust_length : 0x00000000 (0) > > > > forest_trust_data : NULL > > > > posix_offset: struct lsa_TrustDomainInfoPosixOffset > > > > posix_offset : 0xc0000000 (3221225472) > > > > auth_info: struct lsa_TrustDomainInfoAuthInfo > > > > incoming_count : 0x00000000 (0) > > > > incoming_current_auth_info: NULL > > > > incoming_previous_auth_info: NULL > > > > outgoing_count : 0x00000000 (0) > > > > outgoing_current_auth_info: NULL > > > > outgoing_previous_auth_info: NULL > > > > > > > > > > > > > -- > > > / Alexander Bokovoy > > > > > > > -- > > / Alexander Bokovoy > > -- > / Alexander Bokovoy -- / Alexander Bokovoy _______________________________________________ cifs-protocol mailing list [email protected] https://lists.samba.org/mailman/listinfo/cifs-protocol
