[cifs-protocol] New Case Created: 00747518

[Modcloth Customer Care]

Hey Stefan,

Thank you for writing to ModCloth Customer Care! We have received your message and hope to be getting back to you within 3 business days.

If you have an urgent need, you can always contact us with any questions, concerns or feedback via live chat by clicking here or by phone (888-495-9699) between the hours of 9am-9pm EST Monday-Friday, we're always more than happy to help! ?

Thanks,

Modcloth
Email Body:-
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
cifs-protocol at lists.samba.org
https://lists.samba.org/mailman/listinfo/cifs-protocol

ref:_00D7F5lFYJ._5007Frtc6J:ref

Have more questions? We have the answers! 

We're here 9am-9pm EST Monday-Friday to help inspire your unique personal style and help you feel like the most remarkable version of you!

Don't hesitate to connect with us through chat or email on our help page here, https://help.modcloth.com/, or call us at 888-495-9699.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.samba.org/pipermail/cifs-protocol/attachments/20191010/b9265bd3/attachment.htm>