Applies to: Centrify DirectControl 4.2.x
The Centrify agent does not work properly in a DR (Disaster Recovery) environment.
Note: Be aware that each DR situation/environment is different and each agent (the version matters) will behave differently.
The example shown below is one case study which has proven to be helpful:
1) Centrify could not locate Domain Controller because DNS does not work in the DR environment.
Below is a brief on how adclient finds the DC to communicate with.
A) adclient always does SRV query _ldap._tcp.<site>._sites.<domain> and _ldap._tcp.<domain> to locate the DCs to use.
B) By specifying dns.dc.<domain>/dns.gc.<domain> in /etc/centrifydc/centrifydc.conf, the above SRV queries are overridden such that only the specified list is used.
, but it is interpreted as multiple addresses of the same host (by convention). us.your company.comD) Note: Some DNS configurations may return multiple IP addresses when queried for host
Therefore it is up to the DNS to give the usable IP addresses in the host query first.
... until server.try.max. dns.dc.us.yourcompany.com: <domain-controller>" set, adclient will NOT do the SRV query. Instead it will loop through each entry in the list, use getaddrinfo to get IP address from the first DNS and try it. If it answers, then it is good. If not, it will to the next one on the list of dns.dc.us.yourcompany.comC) With "
2) Salt lookup is disabled by default in older versions of Centrify (4.2.1).
It is not a concern if all the domain controllers are Win2003. In particular RC4 HMAC - the default encryption technology for Windows 2003 domains do not use salt, so in these environments; salt is a non-issue.
AD 2008 introduces AES encryption which requires salt as part of their crypto functions. So enabling in those environments, salt lookup is needed.
Starting DirectControl 4.4.2, the configuration parameter adclient.force.salt.lookup is set to true by default.
In a Win2003 & 2008 mixed environment, it is recommend to either turn this parameter to true, or upgrade Centrify to the latest version.
3) Incorrect User home directory permission settings.
The AD user is able to login, but it prompts "access denied for the home directory". The reason is the home directory is located on a VFS mount. Please make sure that the vfstab config is correct.
The AD user can still login even if the home directory is not accessible, it just takes more time after supplying AD password for authentication because the system needs to wait for the timeout.
4) Hard-coding the global catalog (GC) in config file
This is not a must, but recommended. Users are authenticated via DC, GC speeds up the locating of domain resources. So connecting to GC will have performance benefits. Normally GCs can be located via DNS query. In some cases, they can also be hard-coded in the config file (same method as hard-coding domain controllers).
5) Long delay during first user login.
The local cache is wiped in an adleave process. While the local cache is empty, it takes some time to fetch the users/group object from AD during an initial user login. The next user authentication will be much faster once the system caches the information.
These changes should be implemented for DR:
1) Open the config file: /etc/centrifydc/centrifydc.conf
dns.dc.<domain-name>: <domain-controller1> <domain-controller2>
dns.gc.<domain-name>: <domain-controler1> <domain-controller2>
2) Save the config file
3) Run: adleave
4) Run: adjoin
5) Verify the Centrify agent status by running: adinfo
6) Attempt an AD user login.