[cifs-protocol] Significance of empty TrustedDomainSupportedEncryptionTypes value in a TDO 119101021001658
Alexander Bokovoy
ab at samba.org
Sat Nov 2 09:02:45 UTC 2019
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 <ab at samba.org>
> Cc: cifs-protocol at lists.samba.org; support <support at mail.support.microsoft.com>
> 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 <ab at samba.org>
> Sent: Sunday, October 20, 2019 4:37 AM
> To: Obaid Farooqi <obaidf at microsoft.com>
> Cc: cifs-protocol at lists.samba.org; support <support at mail.support.microsoft.com>
> 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 <ab at samba.org>; cifs-protocol at lists.samba.org
> > Cc: support <support at mail.support.microsoft.com>
> > 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 <ab at samba.org>; cifs-protocol at lists.samba.org
> > Cc: support <support at mail.support.microsoft.com>
> > 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 <tomjebo at microsoft.com>
> > Sent: Thursday, October 10, 2019 12:41 PM
> > To: Alexander Bokovoy <ab at samba.org>; cifs-protocol at lists.samba.org
> > Cc: support <support at mail.support.microsoft.com>
> > 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 <ab at samba.org>
> > Sent: Wednesday, October 9, 2019 11:09 PM
> > To: Interoperability Documentation Help <dochelp at microsoft.com>;
> > cifs-protocol at lists.samba.org
> > 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
More information about the cifs-protocol
mailing list