Applies to: All versions of Centrify DirectControl
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 firstname.lastname@example.org 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: 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: DEBUG base.osutil Module=Kerberos : get creds: KRB5 error code 68 (reference base/adbind.cpp:416 rc: -1765328316)
For this error, a network trace showed that the user in question is in ENA.US.yourdomain.LOCAL, but the UPN is email@example.com.
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 firstname.lastname@example.org ena.us.yourdomain.local --verbose
From Microsoft: (provided as a courtesy)
=== 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.