Managed Systems falling off Active Directory

[Lhsachs]

I had an issue with a customer who works from home (~425 miles away from main office) He had been unable to log into his managed system, and came in to the help desk. After logging in as the local admin, I checked and the mac it was showing as bound to AD. Looking in AD - the system wasn't there. Yes, it had been more than 30 days since AD saw the system - and it was dropped… I then unbound the mac. After restarting, I ran Casper Remote to bind the Mac to AD. I checked AD – computer back in AD. I then successfully logged in creating a managed mobile user - that I later deleted. The customer was able to log in again.

This issue brings up a few questions:

1. Binding to AD – Macs bound to AD that are dropped from AD. Casper still shows them as bound.
2. Local account vs managed accounts - if you have remote users do you create local accounts for them?

How do you handle users of this nature?

We just started giving people who work from home a great deal a remote access point - a wireless router that has them working on the corporate network…so my question may be moot for here...

[jhbush]

If it's gone from AD it's likely that it was tombstoned. We have a policy in AD that does that to machines that have not logged in for thirty days or more. They can be reactivated, but as you mentioned they still show as bound in the JSS.

[jarednichols]

Can you exclude tombstoning from a particular OU? I'm not familiar enough with AD to that extent. It would seem to make sense (to me) to change it for OUs where machines may go that long without contacting AD.

[bentoms]

We had this same. F
To we did the following;

1. Disabled the Macs from changing their passwords (don't have a link to hand sorry).
2. We found that manually syncing the DC's resolved. This lead us to find out we had issue with our DC's syncing. Once that was corrected, we've not bad an issue for 10 months.

The thinking I that when the mac clients were changing there password or bound to the domain, DC syncing would overrite the records from another DC deleting or not changing the passwords.

[Walter]

@bentoms

We have seen Macs sporadically lock AD users out. I'm wondering whether this is the cause. There are logs indicating the machine password change failed. Could it be that AD syncing clobbered the new machine password in AD. So now a machine tries what it thinks is the new password while AD perhaps still holds the old one, and thus the client can no longer authenticate to AD?

This happens most often at inopportune times when screen lock enables as I walk from my desk to a meeting. When I arrive at the meeting I can't unlock the screen.

What problems did you find with your AD DC's sync'ing, and what symptoms did you notice that pointed you in that direction? I'm not in the AD management group but a colleague of mine overseas that group. I'd like to provide some info for them to look for in their logs to see if we might be having this or a similar issue with DC sync and machine password changes.

[nkalister]

By default, the machine account password changes every 14 days- if anything goes wrong in that process, the machine losses the ability to talk to AD.
There is a -passinterval switch for dsconfigad that controls how often the machine password is updated. Setting this to 0 will prevent any attempts to change the password.

[Lhsachs]

In this case it was due to the fact that he was off the network for so long...working from home via vpn... the remote access point will resolve his issue.

Do any of you choose to create local users for cases like this? (I'm at a tech firm where management is the 'herding cats fun' of all users are admins...)