13 Replies Latest reply: Sep 17, 2015 10:33 AM by Denny Broderick
MyrkridianRhapsody Level 2 Level 2

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.

Reply by Strontium90 on Jan 17, 2014 3:37 PM Helpful

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

 

R-

Apple Consultant Network

Apple Professional Services

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


All replies

  • Strontium90 Level 4 Level 4
    expertise.serversenterprise
    Servers Enterprise

    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

     

    R-

    Apple Consultant Network

    Apple Professional Services

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


  • John Lockwood Level 6 Level 6
    expertise.desktops
    Desktops

    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

    "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
    expertise.serversenterprise
    Servers Enterprise

    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

    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

    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
    expertise.serversenterprise
    Servers Enterprise

    Hi

     

    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?

     

    HTH?

     

    Tony

  • abstert Level 1 Level 1

    Hello,

     

    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.

     

    Thanks,

    Abraham

  • hisaac Level 1 Level 1

    Question for you Strontium90, I followed your instructions on a test machine, and deleted the user.plist file. Upon logging back in, the computer did not recreate the file, and now I can only login when connected to the network. There is no cached record of the user.

     

    Any advice on how to force the Mac to recreate that .plist file?

  • TEAM HONEYBADGER Level 1 Level 1

    Check to see that the account in system preferences is still a mobile account and if not the ctrl click the account and set as a mobile account.

     

    If it is confirm the computer is on the domain.

     

    let us know if this helps

  • TEAM HONEYBADGER Level 1 Level 1

    unbinding/binding the machine is causing DNS to hand out a new IP entry

    So the issue is that there are multiple DNS entries for the computer hostname.

    Go to the active directory server and go check DNS and remove the older entry.

    If for some reason your on a windows machine and you ping the hostname in cmdline

    then you can get wrong IP address.

    Cool way to see this is if you then ping  -a 172.168.x.x you can get a completely different Computer hostname given DNS has handed out that IP again.

    Typical issue with DNS in a windows environment and your system admin should be able to resolve this no problem.

  • TEAM HONEYBADGER Level 1 Level 1

    Also I should say that the reason the credentials weren't working before when you tried to connect was due to the DNS entry of the hostname and by deleting the PLIST you then rebound and were able to recreate the plist because the domain and the machine had a trust again.

     

    Hope this helps. Let me know!

  • Denny Broderick Level 1 Level 1

    We are having the same issue on our campus.

    We are binding our Macs directly to AD, and not using a secondary binding mechanism, such as Centrify. We don't select mobile accounts other than for the users Mac laptops. The issue is with the Mac desktops, and those predominatley in public areas.


    The problem is that users who are mainly Windows users, in a 180 password change policy, will be asked to change their password the first time they attempt logon to any bound Mac on campus. Regardless of when they last changed their AD password via their PC at login.  If they do change their password at this point, they are then moved to a 42 day policy that exists somewhere,  but they can then logon to any Mac on campus without issue. Mean while they still remain in the 180 day Windows policy. Eventually if they go back to any Mac they will be notified that their password will expire in X number of days, or that it has expired

     

    I'm in a 42 day policy, so at some point  after changing my password I start seeing a message at login stating that I have X number of days before my password will expire. This message will follow me around campus to any bound Mac I attempt to logon to. However once I've change the password the message goes away.

    As a test I went a couple of days without changing my password after I'd received the message telling me that my password has expired. I could still go to a PC and logon without issue.

     

    I am not all that knowledgeable about this, but it appears the Macs are looking at a different set of accounts for the validating of credentials than the PCs are, and these follow the users to the different Macs on campus