AD user logging itself out...

[DJLC]

So I'm working on some MacBooks that live on shared carts at work. I've been deleting all the config profiles pushed by Profile Manager and replacing them with the same config profile with only a minor tweak (added icon to Dock, different desktop background), except pushed by Munki.

On *most* of the systems, this works just fine and gives me my updated settings. However, on about 40% of them, this causes the AD user that students use to log itself out immediately at login. I'll enter credentials, it'll log in, display the desktop, then go back to the login screen with the same animation as in fast user switching. If I log in again, same thing endlessly.

I've tried tweaking the profile, I've tried deleting the AD user from the local directory, I've tried deleting the home folder, I've tried deleting /Library/Managed Preferences, I've tried deleting and reinstalling the profile, I've tried deleting the contents of /Library/Caches/, I've tried all of this both together and apart. No matter what I do, this user always logs itself out.

Interestingly, ONLY the K-3 student AD user account causes this issue. A staff account doesn't cause the issue. A 4th grade student user account doesn't cause the issue. Just the account shared by K-3 students.

Any advice?

 

[chrfr]

So I'm working on some MacBooks that live on shared carts at work. I've been deleting all the config profiles pushed by Profile Manager and replacing them with the same config profile with only a minor tweak (added icon to Dock, different desktop background), except pushed by Munki.

First, I'd suggest breaking out your profiles into discrete configurations: have one for your directory settings, one for your dock, one for network, etc. This makes it a lot easier to deal with in Munki. For instance, I have device groups like "lab_finder_prefs" and "lab_loginwindow". This way you can leave the parts that work in place and troubleshoot your other profiles, or update them without affecting other settings.
Are you seeing anything in the console which corresponds to the time that this user gets logged out? Are all the computers using the same version of OS X? Does your profile have a forced logout after a certain time when it is working correctly? How about manually binding one of the problematic computers to AD as a test?
I've also had some problems where machines got unbound due to other computers getting bound with the same name, but the computer still seemed to act as if it was bound to AD, and I had to force unbind them via dsconfigad.

 

[DJLC]

First, I'd suggest breaking out your profiles into discrete configurations: have one for your directory settings, one for your dock, one for network, etc. This makes it a lot easier to deal with in Munki. For instance, I have device groups like "lab_finder_prefs" and "lab_loginwindow". This way you can leave the parts that work in place and troubleshoot your other profiles, or update them without affecting other settings.
Are you seeing anything in the console which corresponds to the time that this user gets logged out? Are all the computers using the same version of OS X? Does your profile have a forced logout after a certain time when it is working correctly? How about manually binding one of the problematic computers to AD as a test?
I've also had some problems where machines got unbound due to other computers getting bound with the same name, but the computer still seemed to act as if it was bound to AD, and I had to force unbind them via dsconfigad.

All sound advice, thank you!

I'll break them out into bits and see what happens. I suppose that makes life easier when I get around to transitioning staff from PM to Munki. Originally I had settings to enforce idle logout, allow / deny login groups, and admin groups. In my troubleshooting I removed all of those bits. The bit of Console I can see shows complaints about either QuickLook, Spotlight, or AirDrop (which is disabled). I did also confirm all clients were still showing in AD, but if all else fails I'll try rebinding. All clients are at 10.10.5.

 

[satcomer]

By the way is this AD Network on Server2008,2010, 2012 etc? I had a similar problem on Server 2008s2 until the AD Admin put a clock Server into the Domain and the problem stopped!

 

[hobowankenobi]

By the way is thus AD Network on Server2008,2010, 2012 etc? I had a similar problem on Server 2098s2 until the AD Admin put a clock Server into the Domain and the problem stopped!

And if you run your own time server, be sure both AD and clients are using the your time server. In fact, even if you don't run your own, probably still wise to be sure all machines are pointed to the same time server......so they all times are sync'd. AD does not like clients that have clocks off by more that a few seconds.

Windows: It just does that.

After testing it....install a simple profile via Munki to set time server IP for all Macs. Done.

 

[StevieRay]

Sounds like there is a problem with the default User Template. I have seen this before, but typically when the drive is too full to create another user on the laptop.

 

[DJLC]

I have the server and all clients set to use the same external time server, so that should be all good. We're on Server 2012 R2; just migrated this summer. Domain and forest were bumped to 2012 functional level, if that matters at all.

What's odd is that it only happens for this one user account — not other AD user accounts. Even after deleting the home folder and removing it from the local directory, the behavior is still evident. Another user in the same OU and groups can login just fine, as can users in different OUs and groups.

I haven't had time yet to continue troubleshooting this yet. The behavior goes away if I remove the profile entirely, so I'm hoping breaking my settings out into individual profiles will solve the problem.

 

[StevieRay]

Are you using "mobile accounts"?

 

[DJLC]

Are you using "mobile accounts"?

I do have those enabled vs pure network accounts. But I'm not actually syncing homes or providing a home directory on the server.

 

[satcomer]

And if you run your own time server, be sure both AD and clients are using the your time server. In fact, even if you don't run your own, probably still wise to be sure all machines are pointed to the same time server......so they all times are sync'd. AD does not like clients that have clocks off by more that a few seconds.

Windows: It just does that.

After testing it....install a simple profile via Munki to set time server IP for all Macs. Done.

Why would you need software to set the System Preferences-> Date & Time pane and just tying the Domain IP?

 

[hobowankenobi]

Why would you need software to set the System Preferences-> Date & Time pane and just tying the Domain IP?

Not required. Yes, you can touch every machine and set things manually.

The mention of Munki (or any other device management tool) is simply a reference/acknowledgment that one can create a pref file, and push it out to all machines—without touching any of them....much less every one.

OP mentioned that he is already using Munki....so with everthing on both clients and server setup, the fastest, easiest way to distribute/install profiles/preferences.

 

[chrfr]

Why would you need software to set the System Preferences-> Date & Time pane and just tying the Domain IP?

To expand on what @hobowankenobi wrote above, using a tool like Munki allows a manager of Macs to make sure that all computers are configured a certain way. Changing settings manually is a good way to ensure that errors are made and that computers are missed. I personally manage about 250 Macs at work as part of my job and if I had to go to each one to change settings and install software updates, there would be no time to do anything else. With remote management I could easily manage twice as many computers with no real increase in workload.

 

[DJLC]

To expand on what @hobowankenobi wrote above, using a tool like Munki allows a manager of Macs to make sure that all computers are configured a certain way. Changing settings manually is a good way to ensure that errors are made and that computers are missed. I personally manage about 250 Macs at work as part of my job and if I had to go to each one to change settings and install software updates, there would be no time to do anything else. With remote management I could easily manage twice as many computers with no real increase in workload.

Indeed.

Although for me, I just advertise NTP with DHCP. Seems like the Macs respect that? I've never had a problem with time being off anyway...

 

[hobowankenobi]

Indeed.

Although for me, I just advertise NTP with DHCP. Seems like the Macs respect that? I've never had a problem with time being off anyway...

One would think this would be sensible solution....yet in my organization, with thousands of machines, there have been (reported by others) issues if clients and AD are not synced to the same time server; and having clients and AD pointed to different time servers has allowed this to happen. Others here have seem minutes of difference. I have no explanation for that, but it broke log in access.

Less about being accurate, more about be synchronized. Right or wrong.

Still....if it ain't broke, as they say.