From @bbot
1) In all cases where there was always a delay. I found that it was not finding a domain at all because it somehow lost it's AD binding. (This happens quite often and we usually find out when a user comes down and says I can't reset my password). Looking at the GUI showed it was bound to AD, and the record was still in AD, but somehow it lost its' link. Rebinding fixed this issue.
Why it's finding the wrong domain is beyond me.
Yes! I see this a lot here too! And strangely it keeps happening to the same device, and not on other devices. I just assumed it was our poorly configured DCs & AD.
I have quite a few laptops that looses its binding. I have a rebind script that I use along with a smart group using EA criteria.
#!/bin/sh
# adbindingTest.sh
#
# Created by jkim on 9/24/15.
#
#Replace ADACCOUNT with an account that exists in the domain.
id ADACCOUNT 1>/dev/null
if [ $? == 0 ] ; then
echo "<result>Yes</result>"
else
echo "<result>No</result>"
fi
And the rebind script. The credentials are plane text and you can use
#!/bin/sh
# ADBindScriptADM2.sh
#
#
# Created by jkim on 10/21/14.
#
#domain info
domain="domain.org"
username="Username"
password="Password"
ou="OU=ou,DC=dc,DC=domain,DC=org"
#unbind first
dsconfigad -force -remove -u "localAccount" -p "password"
#get serial for computer name
SN=`ioreg -l | grep IOPlatformSerialNumber | awk '{ print $4 }' | sed 's/"//g' | tr [:lower:] [:upper:]`
SN_CUT=`echo $SN`
echo "Serial Number: $SN_CUT"
#set hostname, localhostname, and computername to serial Number
scutil --set HostName "$SN_CUT"
scutil --set LocalHostName "$SN_CUT"
scutil --set ComputerName "$SN_CUT"
#bind to AD
dsconfigad -force -add "$domain" -username "$username" -password "$password" -computer "$SN_CUT" ou="$ou" -groups "domain admins" -mobile enable -mobileconfirm disable -localhome enable -useuncpath enable -alldomains enable -packetsign allow -packetencrypt allow -passinterval 14 -namespace domain
We have a case open with Apple as well for screen unlock delays (wake from sleep). We're an AD shop, using mobile accounts on laptops and FileVault is in the mix as well.
Our DC's are all behind a firewall so this issue seems to crop up on machines that are moving off and on our intranet. I'd be curious if anyone is having this problem who has at least a read-only DC open to the world.
It seems like after a while OpenDirectory loses track of the node state for our domain so (for example) if you're off campus it takes 20-30 seconds before it times out and authenticates from cached credentials. At this point you can bring the machine back on the intranet and it still won't jive with the domain and you get the same long timeout upon unlocking the machine from sleep.
I've found restarting the OpenDirectory service restores functionality (or just rebooting the machine) until the next time it goes haywire. Also, I haven't used 10.11.2 long enough to determine if there's any improvements to this issue. But we've seen this behavior from at least OS X 10.9.
We've also implemented DSBindTimeout set to 10 seconds which does help with login times from cold boots.
We're still seeing delays. I've been on 10.11.2 for a couple days and it feels as if the delays are less frequent. Also checked in with two other El cap users and they're saying the same thing.
We also have an open case with Apple and are waiting to hear back from them after giving them all of our logs.
The issue is much more frequent when switching between access points. (for example, going to a meeting on a different floor or building) Most likely due to having to find the authentication server again.
@chrisbju Still seeing delays after trying to set mdns_timeout and pdns_timeout to 1 or 0.
Issue seems to be much less frequent on El Capitan as of late...
This is basically gone for me in OS X 10.11.3!
Can someone else confirm?
Because this is such a sporadic issue for us, we can't really tell so far. But the most prominent people having this issue are not on 10.11.3 yet... so that's something. Here's to hoping this is going to help us out!
Can anybody else confirm the 10.11.3 fixes here?
Also be worth asking if anybody has tried 10.11.4 beta?
In my case the problem is still there with 10.11.3.
Not tried the 10.11.4 beta
We had same issue after upgrading to ElCap.
Enable the setting "Local-only users may log in" in Configuration Profiles > Login Window (Access) did the trick for us with slow/delayed logins.
I'm currently running 10.11.3 with ADS and this happens on one of our systems but not all which is quite confusing.
How many are using AD ending in .local ? We are still seeing this in 10.11.4, not tried 10.11.5 beta yet.
We have an intermittent issue with our macbooks (OSX 10.11.6) that run a network login.
When a user tries to login with their AD credentials, authentication fails on the first try. On the second try login works. This only happens on a mac they haven't logged into before.
The macbooks are bound to AD and we're using a login window configuration profile.
I think the issue occurs when the wifi switches over to the users credentials as I haven't seen the problem on wired clients.
Anyone had any experience with this issue?
Ive tried adjusting, DSBind Timeout, made sure that the config profile and user wifi credentials are looking at the same DNS server, specified preferred DC in directory services but the problem seems to persist.
Forgive me if posting in the wrong space, I have had a look for threads similar to my issue and cannot find any.
@Crowe87 this is a well known issue that we experienced ourselves and had to learn the hard way.
It has to do with the deriving of the UNC path setting in Directory Bindings. Just uncheck that box. You can update this setting on already deployed machines by running the following command:
sudo dsconfigad -useuncpath disable
If you use this to derive the user's network folder, you'll also want to disable the sharepoint setting as well:
sudo dsconfigad -sharepoint disable
We use a script developed by amsys to mount user network folders on the Desktop when they login to a machine: https://github.com/amsysuk/public_scripts/tree/master/mount_SMBHome
@aporlebeke Thanks for the reply mate.
Tried adding in these commands but the problem still persists.
What I've noticed is when the little orange dot does not appear in user name field the login fails. On occasion it will be there when the computer connects using the loginwindow credentials, but most of the time it will not appear until the second time you try to log in.
Still seeing randomly lost bindings and random lockouts on wake from sleep across our enterprise with multiple domains. It's not the AD, its the crappy implementation of the AD plug-in on macOS. You could write your own before Apple will fix it.
It's gotten to a point I have to customize my krb5 and hosts file looping back all unreachable DC to 127.0.0.1 (on one of our domains we have over 100 DC and mostly unreachable) to get any sort of semblance of functionality out of AD. Why Apple can't fix this over the course of the last decade is simply beyond me.
