Tips for finding Knowledge Articles

  • - Enter just a few key words related to your question or problem
  • - Add Key words to refine your search as necessary
  • - Do not use punctuation
  • - Search is not case sensitive
  • - Avoid non-descriptive filler words like "how", "the", "what", etc.
  • - If you do not find what you are looking for the first time,reduce the number of key words you enter and try searching again.
  • - Minimum supported Internet Explorer version is IE9
Home  >
article

KB-3308: adjoin fails with "KRB5 error code 68 for user xyz@US.yourdomain.local (enctype: ArcFour with HMAC/md5)"

Centrify DirectControl ,  

12 April,16 at 11:43 AM

Applies to: All versions of Centrify DirectControl
 
Question:
 
When using adjoin under the following syntax, it fails: 
 
adjoin -c OU=UnixServers,OU=Servers,OU=Systems,DC=ena,DC=us,DC=yourdomain,DC=local -s expadroot1.yourdomain.local -z CN=ALN,CN=US,CN=EHC,CN=Servers,CN=Zones,CN=Centrify,CN=Program Data,DC=yourdomain,DC=local -n alncmtddb1 -a alncmtddb1.yourdomain.local -u a02373a@us.yourdomain.local yourdomain.local --verbose
 
Where yourdomain.local is the name of the AD domain.
 
us.yourdomain.local is the subdomain where the US users are created, so the user account resides there. 
 
ena.us.yourdomain.local is the subdomain where the containers for Centrify computer objects and secured groups reside, this is why the full name of the container is specified on the adjoin command even though it is using one of the domain controllers for yourdomain.local at the upper level of the AD forest.
 
The following message is recorded in the debug log
 
May 17 17:51:05 Yourmachine adjoin[29467]: DIAG base.aduser Error: get creds: KRB5 error code 68 for user a02373a@US.yourdomain.local (enctype: ArcFour with HMAC/md5) 
May 17 17:51:05 Yourmachine adjoin[29467]: DEBUG base.osutil Module=Kerberos : get creds: KRB5 error code 68 (reference base/adbind.cpp:416 rc: -1765328316) 
 
Answer:
 
For this error, a network trace showed that the user in question is in ENA.US.yourdomain.LOCAL, but the UPN is a02373a@us.yourdomain.local.
 
The syntax should be modified as follows:
 
adjoin -c "OU=UnixServers,OU=Servers,OU=Systems,DC=ena,DC=us,DC=yourdomain,DC=local" -z "CN=ALN,CN=US,CN=EHC,CN=Servers,CN=Zones,CN=Centrify,CN=Program Data,DC=yourdomain,DC=local" -n alncmtddb1 -a alncmtddb1.aln.yourdomain.com -u a02373a@ena.us.yourdomain.local ena.us.yourdomain.local --verbose
 
 
From Microsoft: (provided as a courtesy)
 
- http://blogs.technet.com/b/askds/archive/2012/07/27/kerberos-errors-in-network-captures.aspx
- http://msdn.microsoft.com/en-us/library/Cc212351.aspx
 
=== Excerpt ===
Service 1 uses the name and realm of the user to locate the appropriate domain controller (DC) to provide the authorization information for the user. The user's realm may be found by local policy, or, if the user name is a User Principal Name, by using KRB_AS_REQ and KRB_AS_REP messages as follows. 
 
Service 1 sends a KRB_AS_REQ without any pre-authentication to Service 1's Key Distributor Center (KDC). If this KDC holds the user's account, then it will return KDC_ERR_PREAUTH_REQUIRED, and the user's realm is handled by the KDC. Otherwise, the KDC can refer Service 1 to another realm that may contain the user account or that may have better information about the realm of the user account, as specified in [Referrals] section 4. 
 
The KDC does this by returning a KDC_ERR_WRONG_REALM error, as specified in [RFC4120] section 7.5.9, in the KDC_AS_REP and setting the crealm field to the next realm to try. Service 1 then sends a KRB_AS_REQ to the next realm, repeating the process until it reaches a KDC in the user's realm or receives some other error.
=== ====== ===
 
 
 
Note: At the time of writing, an enhancement has been filed to handle this use case.
 

Still have questions? Click here to log a technical support case, or collaborate with your peers in Centrify's Online Community.