[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 _______________________________________________ cifs-protocol mailing list [email protected] https://lists.samba.org/mailman/listinfo/cifs-protocol
