Extreme long login times for Active Directory users, while remote

roland_huber
New Contributor II

We added all of our Active Directory bound systems to Casper lately.
Now we're facing an issue when the system is not connected to the internal network. Or more precisely, whenever we're trying to logon with the cached Active Directory user account while being on a remote network it takes up to 5 minutes until we get logged in. The account is a mobile account with local User-Directory.

In case we turn off all network adapters while logging out, the login speed is normal and no lag is experienced.

Is there any way, we can reduce the timeout for looking after a response from the Domain Controller?
Excerpt from the open directory.log:
2015-11-05 19:14:58.179217 CET - AID: 0x0000000000000000 - 78.73316 - nodestate - delay check for '/Active Directory/DOMAIN/Global Catalog' by* 145 seconds*
2015-11-05 19:14:58.179226 CET - AID: 0x0000000000000000 - 78.73316 - nodestate - '/Active Directory/DOMAIN/Global Catalog' is still offline

I have reviewed already a ton of articles but none of these really provide a root cause or solution to the problem:
https://jamfnation.jamfsoftware.com/discussion.html?id=7799
https://jamfnation.jamfsoftware.com/discussion.html?id=12457
https://jamfnation.jamfsoftware.com/discussion.html?id=6581

Any help would be much appreciated.

Roland

1 ACCEPTED SOLUTION

roland_huber
New Contributor II

bentoms, this is actually what I was working on during the last hours. Only two of our policies are triggered during login and not for the machines in question. Yes, we also have a JSS reachable from the cloud.

What we also have configured, are login hooks. For the Macs in question we did not run any login policies per se, but when I turned on to run the login hooks in background the issue was gone on one machine (see screenshot below). Now we need to test it if it solved the problem on a larger scale.

The login hook is the standard one from jamf at:

/Library/Application Support/JAMF/ManagementFrameworkScripts/loginhook.sh

f59a98081e1641ff8e3e78cd5d85f035

View solution in original post

18 REPLIES 18

Look
Valued Contributor III

Did you try either of these settings? Or something similar?

defaults write /Library/Preferences/com.apple.loginwindow DSBindTimeout -int 10
defaults write /Library/Preferences/com.apple.mdmclient BypassPreLoginCheck -bool YES

SincerelyJoshin
New Contributor II

What is your domain suffix?

bentoms
Release Candidate Programs Tester

roland_huber
New Contributor II

I've set both values as shown above:

defaults write /Library/Preferences/com.apple.loginwindow DSBindTimeout -int 10
defaults write /Library/Preferences/com.apple.mdmclient BypassPreLoginCheck -bool YES

Our domain suffix is not local (it is .com).

Thanks for the suggestions!

mm2270
Legendary Contributor III

Can you post a sanitized version of the following command from one of the affected Macs?

dsconfigad -show

It may help us to see if a configuration in your AD binding can be adjusted to help resolve this.

roland_huber
New Contributor II
Active Directory Forest          = domain.com
Active Directory Domain          = domain.com
Computer Account                 = computer1$

Advanced Options - User Experience
  Create mobile account at login = Enabled
     Require confirmation        = Disabled
  Force home to startup disk     = Enabled
     Mount home as sharepoint    = Enabled
  Use Windows UNC path for home  = Disabled
     Network protocol to be used = smb
  Default user Shell             = /bin/bash

Advanced Options - Mappings
  Mapping UID to attribute       = not set
  Mapping user GID to attribute  = not set
  Mapping group GID to attribute = not set
  Generate Kerberos authority    = Enabled

Advanced Options - Administrative
  Preferred Domain controller    = not set
  Allowed admin groups           = not set
  Authentication from any domain = Disabled
  Packet signing                 = allow
  Packet encryption              = allow
  Password change interval       = 14
  Restrict Dynamic DNS updates   = not set
  Namespace mode                 = domain

I had also a Preferred DC set once and Authentication from any group as enabled without any difference.

mm2270
Legendary Contributor III

Thanks. Just for kicks, can you try setting the Mount home as sharepoint setting from Enabled to Disabled on one of the Macs and then try rebooting and logging in off the network?

dsconfigad -sharepoint disable

Many many of us have needed to set that setting off and use a separate app/script that launches at login to connect users to their home shares to prevent horribly long login times while not in range of the domain. Apple's AD plug-in is frankly kind of garbage and does not gracefully handle a situation while disconnected. It will hang up while vainly trying to mount the home share for a long while until it realizes it can't do it and just give up.
Give that change a try and let us know what happens.

roland_huber
New Contributor II

I have set it to disabled and sadly it had no effect on the login time.

These machines probably don't see a DC on login time for months and only connect via VPN. OS X tries to contact one of the DCs during login time, but won't get a reply. I wonder, if there is no option to tell OS X to check once for 15 seconds and then use the locally cached account (without further delay on waiting for other DCs to respond) ?

mm2270
Legendary Contributor III

Actually, my understanding was that the DSBindTimeout option mentioned above should be telling the plugin to only try for the set 10 seconds and then give up. If its not doing that after being set, then you may want to look at opening up a support case with Apple if you can. Do you have an Apple support agreement of any kind you can leverage? Something doesn't sound right.
Other than the "Allowed admin groups" option, the only difference I see with your dsconfigad -show and ours was the "Mount home as sharepoint" one, so I was hopeful that would help you. Sorry to hear it had no effect. We also use local cached AD mobile accounts and are not seeing such long logins while disconnected.

roland_huber
New Contributor II

Many thanks for all the help. I will contact Apple in this regard.

In case anybody has other suggestions I would be thankful, if you could post them here.

I definitely will report back, if we found a solution.

bpavlov
Honored Contributor

Do you have anything set in the search domain for the network connection you are using? Also whey version of OS X? Is possible if you have many offices that it could be the way Sites are setup in AD? Sometimes Windows clients will oversee bad configurations. Maybe its not able to communicate to the local DC? Just throwing ideas out there...

calumhunter
Valued Contributor

What OS? 10.10? 10.11?

You said your internal domain is a .com

Do your DC's have public DNS records? i.e. can you resolve your DC's off the corporate network?

roland_huber
New Contributor II

Thanks for all suggestions. - The search domain is different our our corporate domain.
- We don't have public DNS records for our corporate DCs

What I have discovered: As soon as I remove Casper (sudo jamf removeFramework) the problem is gone.

Any ideas?

bentoms
Release Candidate Programs Tester

@roland.huber Do you have any policies running at login? is the JSS externally accessible?

roland_huber
New Contributor II

bentoms, this is actually what I was working on during the last hours. Only two of our policies are triggered during login and not for the machines in question. Yes, we also have a JSS reachable from the cloud.

What we also have configured, are login hooks. For the Macs in question we did not run any login policies per se, but when I turned on to run the login hooks in background the issue was gone on one machine (see screenshot below). Now we need to test it if it solved the problem on a larger scale.

The login hook is the standard one from jamf at:

/Library/Application Support/JAMF/ManagementFrameworkScripts/loginhook.sh

f59a98081e1641ff8e3e78cd5d85f035

bentoms
Release Candidate Programs Tester

Ah ha! Makes sense. Good find @roland.huber!

Please mark the above as the answer for future searchers. :)

roland_huber
New Contributor II

Verified with users and it is solved

apizz
Valued Contributor

Thanks for sharing!