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