Skip to main content
Jamf Nation, hosted by Jamf, is the largest Apple IT management community in the world. Dialog with your fellow IT professionals, gain insight about Apple device deployments, share best practices and bounce ideas off each other. Join the conversation.

Getting the currently logged in user

I am trying to create an extension attribute to grab the currently logged in user on my student machines. I am using a similar script to the Last User extension script template:

#!/bin/sh
user=`ls -l /dev/console | awk '/ / { print $3 }'`
if [ $lastUser == "" ]; then
    echo "<result>Current User</result>"
else
    echo "<result>$user</result>"
fi

I have my inventory set to check at login so I can set the extension attribute to the user short name as they sign on. However, when I collect inventory at login, I only get "root" as the currently signed in user. After the user signs in, I can run "sudo jamf recon" from an ssh session as the local admin and it appropriately records the current user in the extension attribute. Why does it show "root" when I run the script at login, vs when I run the script after the user has signed in? Is the inventory collected prior to a user technically being logged in when I have inventory set to collect at login? Is there another way to collect extension attributes outside of an inventory update? I have also tried to create a policy that runs at login, which just issues the command "jamf recon" but I get the same result.

Like Comment
Order by:
SOLVED Posted: by elund

Here is what I have used to find out the currently logged in user.

#!/bin/bash

\# Get the username of the currently logged in user loggedInUser=/bin/ls -l /dev/console | /usr/bin/awk '{ print $3 }'\

echo "<result>$loggedInUser</result>"

exit 0

Like
SOLVED Posted: by mkunesh

Thanks for the reply. This does grab the currently logged in user except for running an inventory collection at login. If I have the inventory be collected after the user is logged in, then the currently logged in user is correctly reported. However, if i have the inventory collection run at login, the currently logged in user is reported as root. The reason I need it at login is I want to create smart groups based on who is logged in. I have another extension attribute to grab the user's group membership, which is what I will actually use once this is sorted out (1st grader vs an 8th grader, for example). However in order to test membership, I need their shortname. Even using your script exactly as entered returns "root" as the Current User extension attribute when inventory is collected at login.

Like
SOLVED Posted: by elund

Sorry missed that part. Good question though.

Like
SOLVED Posted: by bentoms

If running at login try:

sudo jamf recon -endUsername $3

This will update the username in the computers record.

Like
SOLVED Posted: by mkunesh

I need to store their shortname in a variable so I can call it when I run dsmemberutil checkmembership.

Like
SOLVED Posted: by bentoms

@mkunesh, details matter. :)

If you run a policy at login or via self service, then $3 will return the logged/logging in users name.

Or: https://macmule.com/2014/11/19/how-to-get-the-currently-logged-in-user-in-a-more-apple-approved-way/

Like
SOLVED Posted: by mkunesh

This is an extended attribute that I am trying to use, it is not a script run at login. In my OP I listed the extension attribute script which is failing to properly ascertain the currently logged in user; it is instead grabbing root. In order to collect the information as an extended attribute, an inventory update is needed, which a policy can perform at login. I may switch to using a login script due to the extension attribute not working properly. My goal was to create smart groups based on the currently logged in user's group, instead of continually modifying a login script to act on the currently logged in user's group.

Like
SOLVED Posted: by JPDyson

Extension Attributes are populated at your inventory interval; they may process when no user is logged in, or a different user might log in after they process, and you wouldn't know it until the next interval. Capturing the user at login is a better design (leaving aside that it's also more efficient, not requiring full inventory).

Like
SOLVED Posted: by sean

Personally, I've always been in favour of 'stat' over 'ls' and piping, etc:

stat -f%Su /dev/console

If no one is logged in, then as you have noticed, /dev/console is owned by root. You need to be careful about when a script runs, since if it runs at login, but prior to the ownership of /dev/console being passed to user, then you will still get a reply of root; again as you have noticed.

As mentioned, $3 can be used to get the username with jamf's command. Another method is the the login hook, which uses $1 as the users shortname.

http://support.apple.com/en-us/HT2420

That said, unless JAMF have changed anything recently, then they use the login and logout hooks themselves.

You can also get last logged in user from the loginwindow plist file. This will still return the user name even after they have logged out, so possibly not what you require here:

defaults read /Library/Preferences/com.apple.loginwindow.plist lastUserName

As Ben commented, methods mentioned above can become a problem, but only in very particular circumstances. In fact, Fast User Switching itself isn't so much the issue, but running multiple desktops (consoles) with ScreenSharing is when it goes awry. What is worth mentioning though, is that the above discussed methods are only run at Login. That's to say, these won't be called on a re-authentication. Eg. Unlocking the Screen Saver or using Fast User Switching to authenticate as a user that is already logged in in the background. Neither of these will update the loginwindow plist and LoginHook script won't run, as they are not log in events.

With the various options discussed, work out when you actually need the script to run as this looks like it is more of the issue than actually which command line you are using to get your reply. If you don't allow Fast User Switching, then it becomes immediately easier.

You should be able to set a login policy in Casper that launches a script during login, refers to $3 and then runs the dsmemberutil against that reply.
You may be able to achieve your desired result by creating a script launched by launchd, e.g. /Library/LaunchAgents/mydomain.item.plist

As to your originally posted script, this should never work as expected. You're running an 'if' statement against a variable that hasn't been set. If you are suppose to be running your 'if' statement against the owner of /dev/console, then you don't need to. /dev/console will never be unowned so will never be blank.

Like