8 Replies Latest reply: Mar 25, 2014 6:23 PM by abstert
MyrkridianRhapsody Level 2 Level 2 (470 points)

Hello to all,


I have an issue plaguing the school I administrate. Basically certain users cannot log in to active directory bound machines. They are told they need to change their password. I will give background.


Particularly, in the Library and certain kiosk machines, we have Macs that are bound to an Active Directory domain (I don't administrate this, just the Macs). These Macs have some prefs being set by a Mac OS X server, but nothing regarding Open Directory... all Active Directory. The majority of the machines are running 10.7.5. They bind/unbind perfectly as expected, and the majority of users can log in just fine. In the Library, there are a wall of Macs, and right on the other side, PCs. Every so often, we get someone who cannot log into ANY Mac. They are told they need to change their password before they can log in, even though they have changed it recently (Active Directory is set to force users to change their password every 180 days). They will then get frustrated, go over to a PC and log in just fine there.


Now I have found a few things.


1. I have an account that I have credentials to that is displaying the issue as of now. So I can easily test.


2. On a few occasions, the user with the problem has reported being able to authenticate and login with their OLD password. Unfortunately at this moment I do not know the old password for the account that can reproduce the issue, but I may have it shortly.


3. I can reproduce the issue on any Mac bound to the domain, no matter what Mac OS and when it was bound. For example, I just imaged a brand new machine with 10.9, bound it to Active Directory (Did not bind it to OS X Server), and still will be told to reset my password on the affected account.


4. Other accounts seem to be able to log in just fine, so it doesn't appear to be a binding issue.


IMO, it seems as though the 180 day policy that Active Directory has set is somehow being cached by the Macs. What I mean is, when someone has an AD account set up and then logs in to a Mac, at that point it grabs the 180 day policy and runs with it. Even if you change your password, it just keeps your old password as your login password and waits for the 180 days to end, and at that point tells you to change your password.


So the passwords seem to be out of sync. I may be wrong on that diagnosis but in the end that is what it seems like to me. If anyone has any knowledge or help they can provide on this issue, it would be greatly appreciated.

  • Strontium90 Level 4 Level 4 (3,535 points)

    Are your caching the accounts on the Mac systems?  Basically, in your AD bind configuration is the "Create mobile account at login" box checked?  If so, you may have a stale cached record.  Instead of hitting the domain, the system is referencing the cached record on the system.  Are you using network homes?

    Screen Shot 2014-01-17 at 6.34.48 PM.png



    Apple Consultant Network

    Apple Professional Services

    Auther "Mavericks Server – Foundation Services" :: Exclusively available in Apple's iBooks Store

  • John Lockwood Level 5 Level 5 (5,785 points)

    I have seen cases where after the Mac screensaver has activated the user is unable to unlock it with valid AD credentials. Rebooting and relogging in then works, I have also been told (if enabled) going to the fast user switching screen from the screensaver and then logging in with the same valid user details also works.


    Unplugging the network cable, waiting and then trying again to unlock the screensaver sometimes helps as well as then it uses the local cached credential and does not try to talk to the AD server.


    Note: The password has not expired and user is entering correctly when this happens.


    I get the impression the Kerberos ticket may have expired and is not being renewed sometimes.


    With Kerberos as used by both OD and AD it is important that all the computer clocks are closely synced although I don't believe this is the cause of all the above cases.

  • MyrkridianRhapsody Level 2 Level 2 (470 points)

    "Are your caching the accounts on the Mac systems?  Basically, in your AD bind configuration is the "Create mobile account at login" box checked?


    Yes it is checked. We did this to keep accounts available in the case of a network outage and also to keep data in tact if there were a power outage.


    "Are you using network homes?"


    No. We are using local homes, meaning that students can log in on every Mac in the Library, however they are going to get a different desktop/home folder every time depending on which machine they have logged into.


    When you say "stale cached record" what do you mean? I don't think it can be anything on a local machine since I have tested with a newly-imaged machine and had the same results (that also should answer John Lockwood's response). Also I know clocks are synced, and further I can log in with other accounts successfully (even ones that aren't locally cached).

  • Strontium90 Level 4 Level 4 (3,535 points)

    The fact that the issue is following you to other machines in the mystery and the condition I have not seen.  Unless, the same user has accessed both machines in the past.  This does not explain how it would track to a freshly imaged device however...


    The "stale cached record" is in reference to the .plist file that is created for the user (in /var/db/dslocal/nodes/Default/users) when they cache the account.  I've seen many conditions (usually with laptops) where the user will never re-associate with the domain and effectively continue to work off the local cached account record.  In some cases, the file needs to be purged from the machine and the user need to log in to create it.


    A possible test you can perform is to flush the cached record from the machine, reboot, and then try logging in as the user. A new cache file should be created when you login for the first time.

  • MyrkridianRhapsody Level 2 Level 2 (470 points)

    Yes, my testing which involved reproducing the issue on a freshly imaged machine has ruled out that this is a local issue to any particular subset of machines. I went ahead and deleted the .plist for the account that is having the issue, but the same issue occured when I attempted to log back in.


    It seems to me that the issue cannot be local to any machine, unless there is something consistent across ALL of them. The only thing that would be consistent would be the way they are bound to the domain. Otherwise there must be a problem in the way the Macs communicated with the AD server, the AD server itself, etc.


    Not sure where to go from here or what to even try next.

  • MyrkridianRhapsody Level 2 Level 2 (470 points)

    So somehow I got my problematic account to log in on my newly imaged machine, and it now works on all machines. Steps I performed are here:


    1. Unchecked all boxes in Directory Utility > Services > Active Directory > Advanced Options.

    2. Clicked "unbind".

    3. Deleted the problematic account's "stale cached record"

    4. Restarted.
    5. Binded again to the AD server with no boxes checked.
    6. Logged in, but Finder would not launch. Dock launched, so I was able to open system prefs and then log out.
    7. Checked each box one by one to see if one would ressurect the problem.
    8. After this I could not reproduce the problem and it works on all machines bound to the domain.


    I am not sure what fixed this. I am guessing the act of turning all of the advanced options of and unbinding/binding reset something. Once I then authenticated with the problematic account, it fixed the issue for all other Macs. Not sure how else to explain it. Any ideas?

  • Antonio Rocco Level 6 Level 6 (10,285 points)



    Number 6 sounds like a problem I've seen recently in a fairly large AD environment where a handful of users from amongst a thousand or so were affected.


    This particular environment had a folder structure that placed users' home folders two levels down from the share itself. There was a policy that gave traverse rights all the way down from the parent share to users' home folders. Above this in the interface was an additional 'stale/out of date' policy that denied access to the parent folders upstream from the users' folder. Once this stale policy was removed and the new policy that allowed traverse rights re-applied/re-propagated the user was able to log in. Even though 'gpupdate /force' is supposed to refresh policies within 15 minutes it took a while (some 4-5 hours) before it finally took.


    Maybe the above might go some way in explaining what you saw?





  • abstert Level 1 Level 1 (0 points)



    I have a few questions to help troubleshoot further.  When you are logging in with these accounts and you get a prompt to change your password, what is the exact message you see?  It may be that the Keychain is out of sync with the login and it wants the old password to update the login keychain with the new one.


    Let me know and we can narrow it down.