AD logins problems

"Allow network users to login at the login window" is set.
DNS entries on the mac are pointed to my Windows DC's

We have a timeout on our AD policies of 90 days. If an AD user does not log into a machine in 90 days the machine loses its trust relationship with the domain. We reset the account in AD then un-join and the rejoin the domain to re-establish the trust relationship.
We chose 90 days because in our school district the period covers the "normal" summer break for students. Your domain admins should know what the default policy for your domain is and may be convinced to extend the time between log ins, depending on policy in your organization.

How are the AD accounts being set up on these Macs? Cached AD mobile or network only? That could make a difference.

We run a script to fix the 14 day timeout (the default setting),

#!/bin/sh
sudo dsconfigad -passInterval 0
exit 0

The pass interval can be set to anything but initially is set to 14. Setting it to 0 disables the check.
Gabe Shackney
Princeton Public Schools

From our friend, @rtrouton https://derflounder.wordpress.com/2012/03/29/diagnosing-ad-binding-problems-from-the-command-line/

This is a little bit old, but still useful. Only change I would make is step 3, 'id username', make sure username is unique and hasn't been checked before to avoid caching results.

All AD accounts are set to network only.

OK, had a feeling. Is there a valid network connection on these Macs when the user is attempting to log in and it fails? If it can't contact a DC at the login screen, login will fail since there's nothing to fall back on.
With AD cached mobile accounts, the user info/data and password gets cached locally, so if the network isn't available at the login screen, it still allows them to log in, at least for a while. If its out of contact with a DC for too long, like if its taken off the network for a month, then it eventually fails login (see the comments above from @wdpickle and @gshackney)
Is it a requirement to have them network only? I've never had a great experience using that method. AD cached mobile really works better IMO.

@MST Home folders play a big part in this. We use loca only home folders and then mall the SMBHome with a script. If the AD connector in directory utility is mapping the home (with "use UNC path to derive network home location" enabled), you can get intermittent login issues.

The AD related issues are quite broad unfortunately. I would recommend running Centrify's free AD check tool for Mac that takes a look at a load of common issues.

We sometimes change the computer object pass interval but the downside is an inability to dynamically locate stale records and prune them.

We also set (at least with lab computers) to only put the display to sleep during the day (full sleep can knock the Mac off the domain until it is restarted), and set the computers to shut down at night and startup in the mornings. This is partly to be kind to the environment, but it also means the Macs are being restarted at least once per day, reducing issues.

Feel free to share any other error messages, symptoms etc you are seeing when the issue occurs.

We have this issue here at our institution and it's unclear why it happens. It appears that the Mac's notion of the AD machine password and Active Directory's notion of the AD machine password get out of sync. All our devices use Cached Mobile settings. Presumably OS X reaches out to change the machine password and... miscommunication? There's no verification?

I can see this being more likely on mobile devices, maybe the lid gets closed or it moved before it can be finalized. But I see this a lot on desktops. In fact, I've had this happen on 2 of my own primary use Desktops.. one starting in 10.9 and then continued into 10.10, and then a different one on 10.10 and then into 10.11, and then the latest one thats only have 10.11. And this has covered these devices being in 3 different locations and subnets. My colleague? Never had it happen to him at all. It's maddening.

At this point I have an Extension Attribute that looks for a specific AD group that I'm a member of (that appears roughly first-ish in any list using "id"), if it's not found, then I consider that device as "unhealthy" which puts it into a smart group. Membership in that group kicks off a policy that unbinds the device (at least as far as the Mac is concerned.. in all cases, OS X still thinks it's bound but the AD object notes that the device has been sending bad AD machine passwords for a while), and then rebinds the device.

In most cases this has been working pretty well... Where it fails is on devices with extreme uptime (I consider > 30 days 'extreme' in our environment), AD objects that someone has accidentally re-associated with a Windows device (bad naming practices), and then the (so far) unknowns.

I'm currently experimenting with 30, 60, and 90 day password intervals... but part of me just wants to go for the zero passinterval so this silliness stops.

You are great all of You !!!! Thnak You so much for a lot of advice's. I can consider AD cached mobile since all laptops are connected through the wifi.

I never seen AD logins problems on wired computers besides one wifi. My concern is 90 day password intervals vs default 14 - I saw that in AD controller but can't figure where was the setting.

Thank You all for Your help!!!!

gshackney: how do you run that script ? per start up? what about execution frequency? Thx

I keep it as an ongoing script at the enrollment complete trigger as one of the last steps so it just needs to happen after the bind command. But once per machine should be sufficient if you apply this to units already in the field. As long as they are, and have been connected to the network/Active Directory, for 14 days or less, then you should be good, once they are off the network for more than 14 days then they will need to be rebound then have this script run.

They retain this setting though until reimage.

Gabe Shackney
Princeton Public Schools