username script

Could you edit that post and put your script into the script tags? The button for that looks like >_

@JPDyson sorry about that

Can you post the original script from before updating it?

As an aside, matching against a string of text like that might not be the best way to do things as there isn't any fault tolerance for unexpected changes to verbiage. You might be better off comparing UID's to a number, i.e

#!/bin/sh
currentUser=`ls -l /dev/console | cut -d " " -f 4`
currentUID=$(dscl . -read /Users/$currentUser UniqueID | awk 'BEGIN {FS=":"} {print $2}')

if [[ $currentUID -le 1000 ]]
    echo "This console user is not in AD"
    exit 1
else
    /usr/local/jamf/bin/jamf recon -endUsername $U
fi
 exit 0

Not to mention that the id command will work correctly against local non AD accounts. If I do something like
id administrator or whatever against a local account on my Mac, it returns a valid result. id should not be used if trying to determine if an account is directory based vs local. A method similar to above mentioned by @andrew.nicholas would serve you much better.

The one I use is the following, but I don't know if this works with anything other than cached AD mobile accounts.

dscl . read /Users/$user OriginalAuthenticationAuthority 2>/dev/null

The OriginalAuthenticationAuthority key doesn't exist with local only accounts. I pipe errors to /dev/null/ then just check to see if we got a result back (non null value) from the command.

This seems to work for me...

#!/bin/bash

#Get the current logged in user to console
U=`stat -f%Su /dev/console`

ADWORK=`id $U`
if [[ "$ADWORK" == "id: $U: no such user" ]]; then
    echo "This console user is not in AD"
    exit 1
else
    /usr/local/jamf/bin/jamf recon -endUsername $U
fi

exit 0

@mm2270 it doesn't look like non mobile accounts get records created in /Users

i get the following:

<dscl_cmd> DS Error: -14136 (eDSRecordNotFound)

I have used the UID is greater than 1000 to determine if account is an AD account or not at quite a number of sites and it has been reliable so far.

@calumhunter Yeah, that makes sense, and its kind of what I figured. I'm under the impression that most environments are using cached mobile accounts these days.
The only reason I do it the way I posted above is because it was discussed on other threads that talked about determining AD vs local account that it's pretty easy to spoof the UID of an account, if someone was trying to fool a process. Its much less likely that someone would write in the 'OriginalAuthenticationAuthority' key into the local account record.
But, whatever works!

I've got another way, posted here.