Mobile account login problem if disabled or extended in AD

Hi Tim,

Can you share the output you get from the first few sections if the script?

Also, I'm not an ADMitMac user. But I've not had the issue you've linked using the standard AD plugin in various AD environments from 10.4 & up.

Are you sure this issue isn't with 10.7 & Admintmac?

Regards,

Ben.

Thanks will do when I get to work

Haven't tested in 10.7 but have a look at the apple kb in that url

Have done.

Seems to only apply to OD(?)

In regards to AD, I've had accounts lock out as a part of a global password policy. Either after the helpdesk unlocking the account (& that change replicating to the local dc) or the account unlocking automatically (if set).

The mac user can login as normal.

Regards,

Ben.

Its what happens in my environment because HR are so disorganised.

Scenario

Jbloggs is a contractor and he might be working just on Monday as we have been instructed so his AD account gets set to expire end of Monday.

It get written in dscl his expiry date when he logs in on Monday.

He turns up on Tuesday and HR didn't tell anyone because they forgot to tell us but its too late the account has been marked in dscl that its disabled.

It might help someone experiencing the same problem.

I can't say its an issue with OD but seems to also be an issue with AD and the Apple plugin with mobile accounts.

Thanks for your help and ps think your site is great and definitely things I can use out of that like OS checking in scripts :)

No worries.

When you say gets written to dscl.. You mean AD right?

Regards,

Ben.

No gets written to the internal mac directory services database.

I've never done this.

Could it be this sync with ad that causes the issue?

For me all macs contact ad for this info.

Regards,

Ben.

No macs are set to not sync mobile accounts.

That's not what I meant.

I never change the account expiry in the local dscl... My macs look at ad for that info.

Regards,

Ben.

Mine do too but that get written to directory services and that's what I'm saying

Ad expiry =user logs in=gets written to directory services

Account expires in directory services = account extended in AD=user still can't log in because directory services marks the account as disabled.

i've only been half following this thread, but i'm guessing the account expiry details are in the local cached account record because they're derived from whatever's in AD.

you're not setting this property in some other way, right?

what's the question/problem again?

Hmmm... To me sounds like an ad rep or DNS issue. I've never seen the issue so can confirm it works. (10.4-10.7).

Regards,

Ben.

No I'm not setting any expiry dates in dscl that's all done by AD.

Yes I think its the cached mobile account because its set in the ADmitMac plugin to login offline up to 127 times.

Reason is for laptop users.

Sorry guys didn't mean a massive reply frenzy its just something I have used for a number of years and thought it might be useful for others because it works in my environment of poor upper management.

Summary

We have many contractors coming and going all the time extending, reenabling accounts in AD etc.

1.Jbloggs has his account to expire in AD to expire end of Monday

2.When Jbloggs logs in on Monday this gets written to directory services database on the Mac. He is then told he needs to com in Tuesday

1. Jbloggs tries to log in on Tuesday but the login screen shakes and he calls IT helpdesk

2. IT look at AD and realise his account expired yesterday and Management didn't follow procedure and notify IT

3. IT extend his account in AD but he still can't log in and the login window shakes and he even reboots.

4. The problem is directory services still has Jbloggs account marked as disabled. Until the account is deleted in directory services only, he will not be able to log in. If the account is deleted through directory services, his account gets recreated again in directory services and all is good.

I have a script run as a launch daemon that will automatically find and delete disabled user. Only exception is in the script I don't include the last bit for killing the login window. This is included in my ARD default template unix command because the login window might freeze.

The reasoning for a launch daemon and script is because I am getting tired of trying to explain it to my colleagues all the time which have no interest in Macs and I can just say "reboot" :)

#!/bin/bash

# WARNING DO NOT USE THIS SCRIPT IF A USER IS LOGGED IN AND THEY ARE AT SCREENSAVER PASSWORD AUTHENTICATION. THE LAST PART OF THE SCRIPT WILL FORCE THE LOGIN WINDOW AND THE USER WILL LOSE UNSAVED DATA. INSTEAD JUST UNLOCK THEIR ACCOUNT IN ACTIVE DIRECTORY!

# This script is used to delete the user account from the database if it is marked as disabled in directory services. This is a fix for when a contractors account expired, has been extended but the user cannot log in.

# Before running this script extend the user account in Active Directory and make sure it is unlocked
for disableduser in `dscl . -list /Users AuthenticationAuthority | grep DisabledUser | awk '{print $1}' | tr ' ' ' '`; do
dscl . -delete /Users/$disableduser
done

# The command below is only to be used in a template for ARD.Killing the login window which can get stuck if an account is disabled
killall -3 HUP WindowServer

My guess is it doesn't happen to every one out there, it just happens to me be management are just so crap and as us British would say "Could'nt organise a piss up in a brewery"

It used to happen to me every monday too!!

But what I'm trying to advise is that using the AD plugin I do not see the same issues as yourself.

Do you have many DC's?

Any difference without ADMitMac?

Regards,

Ben.