User Approved Enrollment, SplashBuddy, Enterprise Connect local account conversion thoughts and other input

Chris_Hafner
Valued Contributor II

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 ;-)

7 REPLIES 7

Chris_Hafner
Valued Contributor II

@mm2270 I would love your opinions and thought process.

float0n
Contributor

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.

Chris_Hafner
Valued Contributor II

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!

mm2270
Legendary Contributor III

@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.

Chris_Hafner
Valued Contributor II

@mm2270 Thanks! And yea, I know what you mean.

P.S> Thanks for noticing my "quoted" script. I'm that busy as well ;-)

dan-snelson
Valued Contributor II

@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.


--
Dan

Chris_Hafner
Valued Contributor II

@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 !