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-5616: Cached logins may fail for the first few minutes when connected to external (non-domain) networks

Centrify Identity Service, Mac Edition ,  

12 April,16 at 10:57 AM

Applies to: Centrify DirectControl version 5.2.0 through 5.2.4 on all versions of Mac OS X

Problem:
  • If a Mac system is taken off the domain and then connected to an external network (like a home wifi network), then cached AD users may appear to fail to login.
    • If the user waits a few minutes and then tries to login again, then the cached login will be successful.
  • However if all network connections are completely disabled and then the Mac rebooted completely offline - then the cached user is able to immediately login in Disconnected mode.
  • Similarly, if the Mac is brought back on to the domain and rebooted while connected - then the user is able to immediately login in Connected mode. 


Cause:

In some environments if a Mac system boots up in an "ambiguous" state of connectivity (i.e. connected to a network, but not the domain network), the Centrify agent needs additional time to determine whether it really is in connected or disconnected mode. This is due to the way the OS reports its state of network connectivity during the boot-phase:
  • When the Centrify agent first starts up during machine boot up, it sends a request to OS X to check whether "network is ready".
  • This network-check is normally executed and completed long before the boot-up reaches the login screen, and the Centrify agent is fully ready to handle the login by the time the user goes into input their credentials.
    • When the Mac is definitely connected to the network, or completely offline, OS X is able to respond instantly and accurately and the Centrify agent is able to invoke Connected or Disconnected mode logins as needed.
  • However, in some environments when the Mac system's network state at boot-up is ambiguous, the OS does not always respond to the network-check accurately.
    • In earlier versions of the agent, it was found that these types of environments would cause the agent would end up using the wrong method to login and cause the cached user to appear like they were completely locked out while offline (regardless of how long they waited at the login screen).
  • In order to improve the reliability of the network-check request, the Centrify agent now performs its own network-checks at boot-time to verify whether the Mac really is or isn't connected to the domain.
    • The cost of these additional checks is that it may take additional time to determine the true connected status of the system. But the user should ultimately be able to login after a short wait.
    • Without these additional checks, the chance of an incorrect network status being reported at startup is much higher - leading to a much higher rate of login issues for remote users.


Workaround:

Note:
  • The default values of the network-checks were chosen to allow the most accurate readings in the widest range of environments. 
  • These values can be adjusted to reduce the wait-time if the conditions of the affected networks are known.
    • Be aware that reducing the wait-time too low may cause the Centrify agent to determine it is in Disconnected state too soon in on-premise (Connected) environments where DNS latency is high.
    • If an AD user does a cached login while actually connected to the domain, they may not immediately get a Kerberos ticket - however the agent will eventually detect the true connected status of the Mac system and obtain a ticket shortly afterwards.

Methods of reducing the network check wait-time:

Option 1: (Recommended)
  • Upgrade Mac system to Centrify DC 5.3.0​
Notes on the following options:
  • All of the following parameters are found in: /etc/centrifydc/centrifydc.conf
  • The options below can be used individually, or combined together as needed.
  • After making the changes and saving the conf file, make sure to run the following command before restarting to invoke the changes:
    • sudo adreload

Option 2:
  • Set the following:
    • dns.udp.timeouts: 1 
  • This will try the UDP once, and wait for one second.
  • (Default is to try three times, for one second, two seconds and four seconds respectively)

Option 3:
  • Set the following:
    • dns.sweep.pattern: u1 
  • This will reduce number of scans used to locate a usable DNS server. 
  • (Default is to do six sweeps for each known DNS server)

Option 4: 
  • Set the following:
    • adclient.network.wait.max: 5 
  • This reduces the network-wait time at boot down to five seconds.
  • (Default is to wait for thirty seconds). 

To push the above configuration changes out via GP, use the following policy:
  • Computer Configuration / Centrify Settings / DirectControl Settings / "Add centrifydc.conf properties"


Resolution:

None. The root cause is located in a module that is not maintained by Centrify

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