After an account is migrated to the target domain with password migration, the target account cannot do Kerberos authentication in the target domain when RC4 is disabled in the target domain. RC4 is enabled in the target domain globally, but disabled on specific OU, where workstations are migrated to.
With RC4 turned on: Client is sending over TGS-REQ with 5 supported etype items:
DC is responding with TGS-REP with the highest one selected: eTYPE-AES256-CTS-HMAC-SHA1-96 (18) Kerberos is done through AES256.
With RC4 turned off on OU, there are two scenarios:
1. For accounts created new in the current domain: Client is sending over TGS-REQ with 2 supported etype items:
DC is responding with TGS-REP with the highest one selected: eTYPE-AES256-CTS-HMAC-SHA1-96 (18) Kerberos is done through AES256.
2. For accounts that are migrated from the source domain:
Client is sending over TGS-REQ with 3 supported etype items:
DC is responding with KRB Error: KRB5KDC_ERR_ETYPE
Enhancement request MMAD-180 has been created for the issue.
Possible workarounds:
- enable RC4 on the target OU/avoid to disable RC4 domain-wide. Keep RC4 enabled on the target domain if it's enabled on the source (because passwords were hashed using RC4 there).
- reset account's password on the target domain, so the new password's hash will use AES-based encryption instead of RC4
© 2024 Quest Software Inc. ALL RIGHTS RESERVED. 使用条款 隐私 Cookie Preference Center