any tricks to prevent cached AD user account from logging in?

Are these Macs are in proper contact with your AD environment? Is this happening when on or off the network? If you mean stopping login when off network, I'm not certain there's a way to do this. The way cached mobile accounts works is that the user is still able to log on when not in contact with your DCs. Since they aren't in range of your domain controllers when off network, I think there isn't going to be a way to stop them from logging in. You might need to switch to some other account type, not cached mobile.
Eventually they won't be able to log in, because at some point when out of contact with the DCs for too long, the Mac stops allowing cached logins. But that isn't going to happen immediately.

On the other hand, while connected to the network, it should actually stop them from being able to login if their account is disabled. Unless you mean because they don't have a connection to the network until after they log in. You mentioned wireless, so I'm not sure if that's actually what's happening.

Hello MM, I believe these macs should be in proper contact with our AD enviroment. I wasn't trying to prevent login while off network, as i understand that won't be possible due to the account caching. The expected behavior i would like to see is that the macs would verify the AD user before allowing login, which is happening if the user has not logged in before, i verified this and the disabled user could not get into a new machine. Its just if they have logged in before, then they can get in regardless of the status of their AD account. We are actually using user authentication at the login screen to grant wireless connectivity to our network, so maybe that is where the break is occurring.....we do have a profile in testing thats using machine authentication to grant wireless connectivity which maybe would allow the disabled student login to be blocked...

I haven't tried to resolve this one yet.. But here are some thoughts..

Methods that spring to mind are:

1: -- Which may be unacceptable: You could Completely DELETE the account at logout - so each login is a first time login.. That solution could work in some environments.. But is completely unacceptable in others..

2: How about "Deleting the account" - But leaving the "Home Directory" still in place.. A Fresh login, would reconnect to the existing home directory -- But would use, and require, the 'new' login credentials.. (But can cause issues with other users on the same machine..)

3: -- Where you REQUIRE an active AD-authentication. And by that, I mean, somehow invalidating the locally cached credentials.. -- So a network based authentication then becomes mandatory.. How do you do that ? ( Other then by method 2 ? ) -- Not sure I haven't tried to do this.. Maybe the locally cached password state could be set to (locally) 'expired' at logout ? (But without invalidating the network password) - A fresh login would then require network authentication..

You could look at: pwpolicy expirationDateGMT mm/dd/yyyy (US date format) -might work ?

Definitely needs experimenting to test..

NB: Obviously if any of the machines are to be used off-network, then the local authentication has to be maintained..

Thanks for the reply Peter,

1. Deleting the local account at logout - Unfortunately this wouldn't work in our environment, we are not yet 1to1 with laptops, and we have many students who all have saved/stored work on the laptops throughout the year. Now if we could somehow get our students to actually utilize and save their work to their network share we could in theory do this, but i don't see it happening.

2. Deleting the account, but leaving the home directory - This could potentially work, if it didn't substantially increase logout time, and if it didn't adversely affect the potentially 100+ other cached accounts.

3.This potentially sounds the best, but as you said will require some through testing on our end. Once my other staff member returns from vacation, we may potentially look into this solution.

We block a specific generic "student" account from logging in by running the following login script (ongoing) at certain sites. I would think you could create an AD group to add these people to and then lookup AD group membership in a loginscript that would do something like ours if they're in that group. You could use some concepts from our script and add logic that checks AD group membership and such.

#!/bin/sh
# Block "student" account from logging in
if [ "$3" = 'student' ]; then

    # Display message telling user that student account has been disabled
    /usr/sbin/jamf displayMessage -message "The student account is no longer available." 

    # Pause 8 seconds
    /bin/sleep 8

    # Go to Login Window
    /usr/bin/killall -e -c loginwindow -u student

    # Kill all processes run by student
    /usr/bin/killall -u student

    # Kill jamfhelper process
    /usr/bin/killall -c jamfHelper

    # Change ownership on student folder so they can't save or access anything
    /usr/sbin/chown root /Users/student
    /bin/chmod 000 /Users/student

    # bail now to speed up login
    exit 0;

fi

@spowell01

You can try payloading a configuration profile that has an exclusion list scoped to an AD group?

-Tom