Enrolling Mac with staging profile

SMR1
Contributor III

We're testing a way to make it a little faster for users when they come in to get their new Mac's. We setup a staging profile, login with that account, we sign in to self-service with the user who will be getting it, at the prompt to enter local password, we put in the staging password and then run a script that switches the user on the device. We then go in to Jamf and change the user info there. The Mac shows encrypted, filevault 2 is new user and the user has a secure token. We're able to change the password, but when you log back on to jamf connect, it says incorrect password with either the current or staging password. Not sure if there is a way around this.

1 ACCEPTED SOLUTION

honestpuck
Contributor

You've got far too many moving parts in that system. I'm not surprised it's breaking.

According to your list you are enrolling each machine twice? That's not good. That's bound to break things. Why are you enrolling twice? I assume the second time must be user-initiated.

My thinking is that you have broken the FileVault encryption so that the user has an FV token but with another password on it. I assume you have tried both user names with all the passwords the machine has ever known?

I'm sorry but with all that complexity I have no idea where to start to recommend a possible fix. My advice would be to give up and let the end user enrol from the beginning. Unless you are installing a huge amount of software it's not a long time for them to wait. You're throwing away all the advantages of ADE and Jamf Connect.

View solution in original post

3 REPLIES 3

honestpuck
Contributor

Can you show us the script you run? It might also be good if you gave us a list of the steps you perform laid out one by one.

Do you have Jamf Connect connected to any particular IDP such as Google or Azure?

Are you starting off with an ADE enrolment? If so, what is in the pre-stage?

When you say "The Mac shows encrypted, filevault 2 is new user and the user has a secure token." do you get that information from Jamf or the machine itself? What does the computer record in Jamf say?

When you say "but when you log back on to jamf connect" do you mean the log in after a reboot? If it's after a reboot can you successfully use the new password in the FileVault authenticate then it fails at the IDP log in or do you go straight to IDP log in which fails and you never see the FileVault authenticate?

SMR1
Contributor III
The steps we’re following are listed below.


Do you have Jamf Connect connected to any particular IDP such as Google or Azure? We’re using Azure

Are you starting off with an ADE enrolment? If so, what is in the pre-stage? Yes

When you say, "The Mac shows encrypted, filevault 2 is new user and the user has a secure token." do you get that information from Jamf or the machine itself? What does the computer record in Jamf say? On the device, it says Filevault is on. When I look under the Disk Encryption on the device in Jamf Pro it originally listed the Filevault 2 user with the pre-stage account, but after running the script and then changing the user within the jamf console under Users and Locations, it switched to the new username. Also, for the new user I ran the command to verify the securetoken was enabled for the new user and it was.

When you say "but when you log back on to jamf connect" do you mean the log in after a reboot? If it's after a reboot, can you successfully use the new password in the FileVault authenticate then it fails at the IDP log in or do you go straight to IDP log in which fails, and you never see the FileVault authenticate? Everything looks like it goes through, but when you go to reset your password using Jamf Connect, it lets you reset it, but when you log back on to Jamf Connect, it wants you to sync with the computer password. That’s where it breaks, I assume it’s because the script changes the user info on the Mac which changes the original password. Sorry for the long email. Even after restarting the device, it won’t work, it’ll keep saying Password Incorrect.




Steps

* Enroll using tester account
* Username: test@test.com (pre-stage account)
* PW: xxx
* Sign into Mac Tester Account
* Sign into Jamf Connect with user account that you are going to switch the device to
* Will be prompted for local account type: pre-stage password
* Launch Self service and sign in with test@test.com
* Run Modify User Name2 from self service
* Enter old user: pre-stage account
* Enter New user: EX: User.Account
* Enter User Full Name: User Account
* Let policy finish and reboot
* Log In to user account
* Change user and Location in Jamf Pro
* Log out and log back in so login triggers will take affect
* Enroll as normal

Here is the script we’re using.

#!/bin/bash

###
#Gather input for Old Username, New Username, and Full Name
###

#echo Please enter the user name that you wish to change - Case Sensitive:

#read oldUser

#echo Please enter the user name that you wish to rename it to - Case Sensitive:

#read newUser

#echo Please enter the users full name - Case Sensative:

#read userFullName

#echo $oldUser
#echo $newUser
#echo $userFullName


#!/bin/bash

oldUser=$(osascript -e '
tell application "Finder"
activate
try
display dialog "Please enter the user name that you wish to change - Case Sensitive:" with title "Modify User Name" default answer "Old User Name"
set oldUser to the (text returned of the result)

on error number -128
set oldUser to ""

end try
return oldUser

end tell')

newUser=$(osascript -e '
tell application "Finder"
activate
try
display dialog "Please enter the user name that you wish to rename it to - Case Sensitive:" with title "Modify User Name" default answer "New User Name"
set newUser to the (text returned of the result)

on error number -128
set newUser to ""

end try
return newUser

end tell')

userFullName=$(osascript -e '
tell application "Finder"
activate
try
display dialog "Please enter the users full name - Case Sensative:" with title "Modify User Name" default answer "User Full Name"
set userFullName to the (text returned of the result)

on error number -128
set userFullName to ""

end try
return userFullName

end tell')

echo $oldUser
echo $newUser
echo $userFullName

# Test to ensure account update is needed
###
if [[ "${oldUser}" == "${newUser}" ]]; then
echo "New and Old user are the same, no updates needed"
exit 0
fi

# Query existing user accounts
###
readonly existingUsers=($(dscl . -list /Users | grep -Ev "^_|com.*|root|nobody|daemon|\/" | cut -d, -f1 | sed 's|CN=||g'))

# Ensure old user account is correct and account exists on system
###
if [[ ! " ${existingUsers[@]} " =~ " ${oldUser} " ]]; then
echo "${oldUser} account not present on system to update"
exit 1
fi


# Captures current "RealName" this is the displayName
###
fullRealName=$(dscl . -read /Users/${oldUser} RealName)

# Formats "RealName"
###
readonly origRealName=$(echo ${fullRealName} | cut -d' ' -f2-)

# Updates "RealName" to new username (Yes JCAgent will overwrite this after user/system association)
###
sudo dscl . -change "/Users/${oldUser}" RealName "${origRealName}" "${userFullName}"

# Captures current NFS home directory
###
readonly origHomeDir=$(dscl . -read "/Users/${oldUser}" NFSHomeDirectory | awk '{print $2}' -)

# Updates NFS home directory
###
sudo dscl . -change "/Users/${oldUser}" NFSHomeDirectory "${origHomeDir}" "/Users/${newUser}"

# Updates name of home directory to new username
###
mv "${origHomeDir}" "/Users/${newUser}"

# Actual username change
sudo dscl . -change "/Users/${oldUser}" RecordName "${oldUser}" "${newUser}"

# Links old home directory to new. Fixes dock mapping issue
###
ln -s "/Users/${newUser}" "${origHomeDir}"

# Success message
read -r -d '' successOutput <
Success ${oldUser} username has been updated to ${newUser}
Folder "${origHomeDir}" has been renamed to "/Users/${newUser}"
RecordName: ${newUser}
RealName: ${userFullName}
NFSHomeDirectory: "/Users/${newUser}"

SYSTEM RESTARTING in 30 seocnds to complete username update.
EOM

echo "${successOutput}"

Sleep 30

#System Restart
osascript -e 'tell application "Sysem Events" to restart'
exit 0

honestpuck
Contributor

You've got far too many moving parts in that system. I'm not surprised it's breaking.

According to your list you are enrolling each machine twice? That's not good. That's bound to break things. Why are you enrolling twice? I assume the second time must be user-initiated.

My thinking is that you have broken the FileVault encryption so that the user has an FV token but with another password on it. I assume you have tried both user names with all the passwords the machine has ever known?

I'm sorry but with all that complexity I have no idea where to start to recommend a possible fix. My advice would be to give up and let the end user enrol from the beginning. Unless you are installing a huge amount of software it's not a long time for them to wait. You're throwing away all the advantages of ADE and Jamf Connect.