Posted on 08-28-2018 05:53 AM
OK, We've finally moved on. JAMF was right and imaging is at least a giant pain in the rear. We're beyond imaging now and will launch User Based enrollment in two weeks. To help meet the functionality we desire, I've come up with a new method for onboarding our students and I'd like to throw it out there for some advice. Heck, I borrowed the scripts I'm using from here anyways. Now, all of the components work, but it's not fully automated and I'd bet some of you can help me out.
OK, here is the basic workflow:
• Student User brings in BYOD, unmanaged computer
• Student is guided to the enrollment URL, downloads certificates/approves MDM
• ... Machine enrolls and SplashBuddy launches and shows the progress of the enrollment policies I've created.
So far so good, but we need to migrate the current user to a new local account based on AD credentials (Without being bound to AD). Fortunately, we're Enterprise Connect users. I can guide the students through launching Enterprise Connect, allowing it to synchronize the local user account password. This stores the local EC credentials in the user keychain, which, I am going to use since plistbuddy 3 doesn't seem to be coming out in the next week. I don't like this, but it works.
The student then launches the following script (Either via Self-Service or some automated method). This script was developed by Dan K. Snelson, to convert a mobile account to a local user account. I was able to take that and poke holes in it unitl I could convert the users local admin account, into a Standard user account, using Enterprise Connect-AD credentials. I don't particularly like using the keychain (i.e. asking users to approve access ot the user keychain is a bad idea in general, but hey... working is working).
#!/bin/sh
####################################################################################################
#
# ABOUT
#
# Convert Mobile Account to Local Account
# Based on: https://jamfnation.jamfsoftware.com/discussion.html?id=12462#responseChild73117
#
# This script is (originally) designed to remove a mobile user account and re-create
# a local account with the same username and the password from user-input.
# It will also give read/write permissions to the user's home folder.
#
####################################################################################################
#
# HISTORY
#
# Version 1.0, 28-Apr-2016, Dan K. Snelson
# Version 1.1, 02-May-2016, Dan K. Snelson
# Removed code and verbiage about the user's keychain
# Version 1.2, 03-May-2016, Dan K. Snelson
# Fixed error when no users with 5nn UID existed
# Version 1.2 Brewster Edition 27-July-2018, Chris Hafner
# Modified to allow account conversion from personal local, to EC User local account.
#
####################################################################################################
# Import general functions
source /Users/Shared/Client-Side-Functions.sh
####################################################################################################
ScriptLog "###############################################"
ScriptLog "### Convert Personal Local Account to Brewsterized Local Account ###"
ScriptLog "###############################################"
### Variables
loggedInUser=`python -c 'from SystemConfiguration import SCDynamicStoreCopyConsoleUser; import sys; username = (SCDynamicStoreCopyConsoleUser(None, None, None) or [None])[0]; username = [username,""][username in [u"loginwindow", None, u""]]; sys.stdout.write(username + "
");'`
UserUID=`/usr/bin/dscl . read /Users/"${loggedInUser}" UniqueID | grep UniqueID: | cut -c 11-`
userRealName=`/usr/bin/dscl . -read /Users/"${loggedInUser}" | /usr/bin/grep RealName: | cut -c11-`
user_home_location=`/usr/bin/dscl . -read /Users/"${loggedInUser}" NFSHomeDirectory 2>/dev/null | /usr/bin/sed 's/^[^/]*//g'`
# Echo variables
ScriptLog "Variables ..."
ScriptLog "* loggedInUser=${loggedInUser}"
ScriptLog "* UserUID=${UserUID}"
ScriptLog "* userRealName=${userRealName}"
ScriptLog "* adminStatus=${userIsAdmin}"
ScriptLog "* ec_user=${ec_user}"
#This will set the "adminStatus" to nothing in all circumstances. I've just left the line here in case I change my mind later. Proper #adminStatus would be -admin for a non-standard user.
#if [[ $(/usr/bin/dsmemberutil checkmembership -U "${loggedInUser}" -G admin) != *not* ]]; then
# adminStatus=""
# userIsAdmin="Yes"
#else
# adminStatus=""
# userIsAdmin="No"
#fi
if [[ -d "/Applications/Enterprise Connect.app" ]]; then
/usr/bin/security find-generic-password -l "Enterprise Connect" "${user_home_location}"/Library/Keychains/login.keychain > /dev/null 2>&1
if [[ $? -eq 0 ]]; then
ec_user=`/usr/bin/security find-generic-password -l "Enterprise Connect" | grep "acct" | awk -F "=" '{print $2}' | tr -d """`
ec_userPW=`/usr/bin/security find-generic-password -l "Enterprise Connect" -w`
fi
fi
#Rename home directory
ScriptLog "* Moving Home Directory ..."
mv $user_home_location /Users/$ec_user
# Delete the currently logged-in user account
ScriptLog "* Deleting ${loggedInUser} account from client-side directory ..."
sysadminctl -deleteUser "$loggedInUser" -keepHome
Gets the current highest user UID
ScriptLog "* Discovering the highest available UID ..."
maxid=$(dscl . -list /Users UniqueID | awk '{print $2}' | sort -ug | tail -1)
if [ -z ${maxid} ]; then
newid=501
else
newid=$((maxid+1))
fi
# Create local user account ...
ScriptLog "* Create ${loggedInUser} local account in client-side directory ..."
/usr/sbin/sysadminctl -addUser "${ec_user}" -fullName "${ec_user}" -UID "${newid}" -password "${ec_userPW}" -home "/Users/${ec_user}" "${adminStatus}"
# Reset ownership on home directory and append location
ScriptLog "* Correct permissions for ${loggedInUser} ..."
/usr/sbin/chown -R "${ec_user}":staff /Users/"${ec_user}"
#Delete the user's keychain folder... if left uncommented
#ScriptLog "* Delete ${loggedInUser} keychain ..."
#/bin/rm -Rf /Users/"${ec_user}"/Library/Keychains/*
#Sleep for five seconds ..."
ScriptLog "* Sleep for five seconds ..."
/bin/sleep 5
# Force logout
ScriptLog "* Force logout ..."
/bin/ps -Ajc | /usr/bin/grep loginwindow | /usr/bin/awk '{print $2}' | /usr/bin/xargs /bin/kill -9
ScriptLog "---"
ScriptLog "- $loggedInUser account converted from personal to stu###"
ScriptLog "---"
exit 0
So... I'm sure some of you can see a few issues here. One, the process isn't fully automated. If I have time (or good advice). I would love to automate more of the process, but that comes down to launching enterprise connect, verifying that the user has allowed Enterprise Connect to modify the login keychain/password, and then launching this script. I would also love to avoid using the user keychain, but as a side benefit, I've left the keychain intact during the conversion. This means that the user keychain is completely functional on the 'new' user account. Unfortunately, I have only done so much testing given the wild nature of what might be showing up.
So the question is: What really stupid things am I doing here, and/or do you have any thoughts on making the user experience better than Wait for SplashBuddy to finish, launch EC, then launch Self-Service and convert your account.
Thanks in advance for the advice, and for all the items I've used as part of this process. They've all come from here ;-)
Posted on 08-29-2018 05:17 AM
@mm2270 I would love your opinions and thought process.
Posted on 08-29-2018 05:55 AM
I guess this is more of a big picture question, but why are you taking student owned, byod computers and managing them with jamf? Or even going to all the effort and converting their account on their personal mac to a new local account? It seems like a certain invasion of privacy, expensive (those jamf device licenses are going to add up!), and extra overhead for you to actually coordinate and figure out and make work seamlessly.
Posted on 08-29-2018 07:43 AM
Ah... OK. Sorry. Here's the broad picture We are a private, international boarding school (9th to Post-Grad) that developed a very early 1:1 program (est. 1993). We have had a variety of laptop purchasing and distribution programs over those years (leasing, purchasing, etc). We moved to a BYOD platform about 6 years ago, using JAMF solutions to manage our faculty, staff and student devices. We have a highly developed and technologically integrated curriculum that, has been dependent on students having devices that were fully configured for class use.
I could give years of history and the evolution of how we've provided these solutions, but I'll give you the current transition. We have been, running a high-speed imaging (full wipe) for students annually. This helped ensure that there were no technology hurdles as we entered the school year (Schools can lose up to a week or two, getting students fully prepared in some BYOD circumstances). After all, getting students into a 100% clean state was the easiest way to guarantee this.
Now, we are FAR more open with our students and their use of technology than other schools often are and that would be a great discussion to have separately from this thread. However, it's important to know that this ISN'T a program where students are asked to bring a computer to do online work or take notes. For us, it's completely common to have students editing video in the first week of an English class to demonstrate an understanding of summer reading concepts, or to begin working through Reading Support applications and the like. Anyways, this is a long-running and highly successful program where we have dealt with all privacy concerns, security, and cost for decades (JAMF give's us a great discount, but it's not chump change).
As for me... I make this environment absolutely sing, (A phrase I stole from someone else's comments here on jamfnation... somewhere) and yes, it IS a lot of work. , but that's what I do. Now, to the problem at hand.
•) We are recreating the user accounts because our students continually have issues remembering which username and password to use if something like PaperCut asks for their name and password. Since we do NOT bind to AD I've had to come up with creative ways to get their 'short names' to match the naming convention we use for authentication to various services. This and everything I've mentioned above work in all of my tests. I'm just looking for holes in what I'm doing before we go live (in 11 days). I had planned to move to user-initiated enrollment for the next school year, but Apple's introduction of the T2 chip in laptops, as well as the pain imaging now causes in 10.13 led me to accelerate this for this year. Besides, being able to onboard students without deleting all their stuff is extra awesome! We always have to balance reliability with usability right!
Posted on 08-29-2018 11:16 AM
@Chris_Hafner I would love to give some feedback. Right now I'm kind of buried in projects. But as soon as I have some time I will take a closer look at your script/process above.
In the meantime, can you edit your post and make sure the script tags are around the script? It looks like you used the "quote" tag, which is messing up some of the script formatting, making it a little harder to read than it should be.
Posted on 08-29-2018 12:04 PM
@mm2270 Thanks! And yea, I know what you mean.
P.S> Thanks for noticing my "quoted" script. I'm that busy as well ;-)
Posted on 08-29-2018 01:33 PM
@Chris_Hafner I like this one better than mine:
Updated MigrateADMobileAccounttoLocalAccount script now available to fix migration bug
Sounds like DEP will never be an option as the machines are all BYOD, not sure how much more automated you can get.
Posted on 08-29-2018 01:44 PM
@dan.snelson Interestingly, we are DEP as well for our Fac/Staff units. Call it half and half roughly 300 macOS DEP units and ~350 macOS BYOD (Sometimes students use DEP loaners, that one's fun!). On a side note, I REALLY hate the inconsistency of DEP enrollment. Yet, you're correct, unless we go back to buying the computers for our students (don't see that happening) then DEP is not an option for them. As for the script from Per, it's good but it didn't have the framework to fit my purposes. Since the machines aren't bound to AD (and never have been) starting from your script made a lot more sense. I had already sorted out how to pull the EC cred's out of the Keychain for another project and mostly just slapped it in here with a few minor tweaks. I'd prefer to use Apple's recommended methods for verifying user credentials without exposing the user keychain but it requires plistbuddy, which is between development cycles.
By next year, I'll have this sorted somehow behind a nice GUI. Perhaps it will be JAMFs new utility instead of SplashBuddy.
Thanks for the post !