Skip to main content
Jamf Nation, hosted by Jamf, is a knowledgeable community of Apple-focused admins and Jamf users. Join us in person at the ninth annual Jamf Nation User Conference (JNUC) this November for three days of learning, laughter and IT love.

Self Service Prompting Users for Local Administrator Credentials

Symptoms

When a user executes a policy in Self Service, the following message appears:
"Type your password to allow Self Service to make changes."

The user is required to enter local administrator credentials.

Products Affected

Casper Suite

Explanation

When Self Service is first opened, the client computer's management account is used so that users don't have to enter local administrator credentials to execute policies.

There are several reasons why Self Service might prompt users for local administrator credentials:

  • Self Service was open for a long period of time before the policy was executed.
  • The End-User Authentication settings in the JSS require users to authenticate locally to install Self Service items.
  • The management account specified for the computer in the JSS is incorrect.
  • There is a version mismatch between Self Service and the JSS.
  • The server time is ahead of the time on the client computer. This causes Self Service to prompt users for local administrator credentials because the request is coming from a past event.

Resolution

Follow the steps below to troubleshoot the issue.

Step 1:

Have the user close Self Service, and then re-open it.

Step 2:

Ensure that the End-User Authentication settings in the JSS do not require users to authenticate locally to execute Self Service policies.

  1. Log in to JSS with a web browser.
  2. Click the Settings tab.
  3. Click the Computer Management Framework Settings link.
  4. Click the Self Service tab.
  5. Click the End-User Authentication tab.
  6. Ensure that the End users do not need to authenticate locally to install Self Service items option is selected.

Step 3:

Ensure that the management account for the computer in the JSS is correct.

  1. Log in to JSS with a web browser.
  2. Click the Inventory tab.
  3. Perform a search for the client computer.
  4. In the search results, click the Details link across from the computer.
  5. Click the Ellipsis (...) button to edit the Computer Information category, and re-enter credentials for a local administrator account.

Step 4:

Confirm that the Self Service application is the same version as the JSS.

Step 5:

Ensure that the server and client are either connected to the same Network Time Protocol (NTP) server, or the server time is equal or behind the time of the client computer.

Note: Even if the Maximum Clock Skew setting in the JSS is disabled, having a server time that is ahead of the time on the client computer causes Self Service to prompt users for local administrator credentials.

Like Comment
Order by:
SOLVED Posted: by sympoz

We're actually seeing a return of this issue on 10.9.1. The steps listed above have been confirmed.

thanks \-
Sam

Like
SOLVED Posted: by sillers

We had that problem with JSS 8.71 and OSX Mavericks clients too. Update to JSS 8.73 fixed that problem.

Like
SOLVED Posted: by seabash

This article should include an overlooked explanation: management account is not a local admin.

Our support staff occasionally get calls about this issue, though not widespread (Prod JSS 8.73). A recent encounter revealed the afflicted Mac's mgmt account was not a local admin (unclear why/when this happened).

After confirming the fix, we now have a policy to mitigate this issue. Here's the gist...

Used an existing Extension Attribute (EA), which lists local admins and looks like so...

#!/bin/bash
#
# Extension Attribute reports local admins on Mac
#

locAdmins=`dscl . -read /Groups/admin GroupMembership | cut -c 18- | tr ' ' '\n' | uniq | grep -v root`

if [ $locAdmins == null ]; then
    echo "<result>Missing Admin Group</result>"
else
    echo "<result>$locAdmins</result>"
fi

Created a Smart Group comprised of Macs with the named EA criteria of "not like" [our mgmt account name].

Repurposed our existing "edit admins" script, which looks like so...

#!/bin/bash
#
##################################
# editadmins.sh
# -------------------------------
# Add/revoke admin group membership for users on a given Mac
# Note: "LANID" equates to simple names derived from our AD domain
# Version 1.2
##################################

shopt -s nocasematch

# JAMF parameter variables
if [ "$4" != "" ] && [ "$ADMINTASK" == "" ]; then
ADMINTASK="$4"
fi

if [ "$5" != "" ] && [ "$LANID" == "" ]; then
LANID="$5"
fi

# Check if user is already a member of admin group
ADMINSTATE=`/usr/sbin/dseditgroup -o checkmember -m "$LANID" admin | awk '{ print $1 }'`

# Grant Admin
if [ "$4" == "Add" ] && [ "$ADMINSTATE" == "yes" ]; then
    /bin/echo "$LANID is already in admin group. No action taken." | /usr/bin/logger -t editadmins
    exit 0;
elif [ "$4" == "Add" ] && [ "$ADMINSTATE" == "no" ]; then
    /usr/sbin/dseditgroup -o edit -n . -a "$LANID" -t user admin
    /bin/echo "Added $LANID to admin group" | /usr/bin/logger -t editadmins
    jamf recon
    exit 0;
fi

# Revoke Admin
if [ "$4" == "Revoke" ] && [ "$ADMINSTATE" == "no" ]; then
    /bin/echo "$LANID was not in admin group. No action taken." | /usr/bin/logger -t editadmins
    exit 0;
elif [ "$4" == "Revoke" ] && [ "$ADMINSTATE" == "yes" ]; then
    /usr/sbin/dseditgroup -o edit -n . -d "$LANID" -t user admin
    /bin/echo "Revoked $LANID from admin group" | /usr/bin/logger -t editadmins
    jamf recon
fi

exit 0

Note: this takes parameter variables ($4, $5) in policy script fields, e.g. "Add", "username", and acts on on them. It's a bit clumsy, but works for us.

Hope this helps others.

Like
SOLVED Posted: by druocco

Is there possibly an update to this article? Been some years since it was issued and it seems like the steps no longer apply.

Like