Remove Mobile Accounts on Login

I would try a combination of a LaunchAgent and LaunchDaemon. Make the LaunchAgent touch a file, maybe a log or something that it can write to, which is being watched by the LaunchDaemon. Have the LaunchDaemon run the script, which will have the necessary permissions to delete accounts.

As for your script, it's not looking complete or properly formed to my eyes. What is the : in this line supposed to be doing?

if [[ "$CurrentUser" == "localadmin" ]]; then
    :

Also, why are you capturing a variable for LocalUsers when you aren't using it in the script?

The : just tells it to do nothing. If a local admin signs in, I don't want it to remove the mobile accounts. I also captured the local users just as a placeholder for now in the event I want to use it later.

I'll take a look at the launch daemon and see what I can come up with. Thanks!

You could look at Outset. That has worked great for me on login items.

Here's how I would probably solve this, but it's only a suggestion.

Since it sounds like you want to not run the mobile account removal when either the local admin logs in, or the current user is determined to be the only mobile account on the system, I would use the following script in the LaunchAgent

#!/bin/bash

## Pause for 3 seconds before running, to ensure we can see who the current user is
sleep 3

loggedInUser=$(stat -f%Su /dev/console)

localAdminAccount="localadmin"

MobileUsers=$(dscl . list /Users UniqueID | awk '$2 > 1000 {print $1}' | grep -v "${loggedInUser}")

if [[ "$loggedInUser" == "$localAdminAccount" ]]; then
    echo "Local account logged in. Exiting..."
    exit 0
else
    if [ ! -z "$MobileUsers" ]; then
        printf '%s
' "$MobileUsers" > /Users/Shared/mobileaccts
    else
        echo "No accounts to remove. Exiting..."
        exit 0
    fi
fi

In the above, if the MobileUsers variable isn't empty, it's writing the results of that variable to /Users/Shared/mobileaccts, but you could write that to any other location that makes sense and where the LaunchAgent can write to. Wherever it writes to, I would then have a corresponding LaunchDaemon use that file as it's WatchPath item.
As evident, if the current user is the localadmin account, or if the results of the MobileUsers variable is empty (meaning the only mobile account is the current user), it exits, doing nothing, so the LaunchDaemon also doesn't get triggered.

The script run by the LaunchDaemon could do something like this when called:

#!/bin/bash

if [[ $(cat /Users/Shared/mobileaccts) != "" ]]; then
    while read User; do
        /usr/bin/dscl . delete /Users/"$User"
        /bin/rm -r /Users/"$User"
        echo "$(date "+%Y.%m.%d %H:%M:%S") Removing $User"
    done < <(cat /Users/Shared/mobileaccts)
else
    exit 0
fi

## Clean up the contents and prep the file to await next run
echo "" > /Users/Shared/mobileaccts
chmod 775 /Users/Shared/mobileaccts

Essentially, it reads the contents of the file that were written to that triggered the script to run, and if not empty, loop over the users placed into the list (usually will only be one account) and proceed to delete them.
Lastly, it will empty the contents of the file and change the permissions on it so the LaunchAgent will be able to write to it again next time around.

I didn't actually test any of the above, so naturally be careful to test it thoroughly if you decide to use it.

As long as the users don't have admin access why not keep it simple and just use a launchagent to monitor folder changes in "/Users/"? The script ran via the launchagent would simply remove the last user and profile if it saw a new one. It seems like this would work for even non-mobile accounts if needed.

Edit: Neevermind...I reread and saw your comment about wifi authentication. That's actually an issue on my list to look into figuring out. Also it would probably have to be a launchdaemon rather than launchagent. Ugh...I need to go back to sleep.

@mm2270 Thanks for that feedback. I am going to start digging into your solution and see what I can come up with. @jhuls Yup. It's going to be fun. If I come up with anything, i'll post here as an update. :)

@dhanes How about checking Make Available Offline within the policy?
Then the policy should launch if the device is offline. We use this with some Install Cached policies.

@kwsenger @dhanes already mentioned in his OP that he tried that and it wasn't working,

• Policy on Login (available offline)
  • Simply not working. Nothing in logs either

Although I might be inclined to dig further into why that isn't working, since technically speaking, it should work. Nothing about the process should really require a connection back to the domain.