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://support.microsoft.com/en-us/help/4492348/kerberos-unsupported-etype-error-when-authenticating-across-trust > > 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 _______________________________________________ cifs-protocol mailing list [email protected] https://lists.samba.org/mailman/listinfo/cifs-protocol
