SecureToken Archives - Mr. Macintosh

Apple releases long-awaited SecureToken documentation

We have been waiting for SecureToken Documentation since 10.13 Beta 1 and the introduction of APFS. I go into this in my previous article 3 Undocumented macOS Mojave 10.14 Enterprise Fixes. I talk about what SecureToken is and how we need SecureToken Documentation. The sysadminctl binary still doesn’t have a man page. You will see why, once you read on how Apple recommends that you use fdesetup instead of sysadminctl.

sysadminctl documentation — sysadminctl’s only documentation.

Documentation Please!

Many MacAdmins have called on Apple to give us some information explaining how the system works. Since 10.13 Beta 1 we have been left to fumble around and figure all this out on our own. The other problem was, that from 10.13.0 to 10.14.4 the system had many bugs and has even changed many times. It was really hard to keep up much less understand what was going on.

Enter macOS Deployment Reference “Use of SecureToken”

Now that we have the document, what does it say? Does it shed any light on the situation? In a word no… but it finally puts everything into words for new MacAdmins. Most of the information posted was already known and hashed out by experienced MacAdmins who have spent hours testing SecureToken. We will be able to share this document when anyone has questions about how SecureToken works.

Any key takeaways from the document?

1. If local user account creation in the macOS Setup Assistant is skipped using MDM and a directory service with mobile accounts is used instead, the directory user won’t be granted SecureToken when logging in to the Mac.

This statement is a little confusing yet could also be true depending on your setup. For example you can use MDM/DEP with the setting “Skip Account Creation” then bind to a directory service with a policy to enable FV2 on login. In this situation the management account/admin user is not granted a SecureToken. The first directory user to login will get a SecureToken by enabling FV2 . This is the perfect scenario, as you don’t need a tech waiting around to enter in the admin username and password for the first user logging in.

Editor’s Note: for the above situation. If you do not have a policy to enable FV2 on login the mobile account will not get a SecureToken. I never tested out this scenario. Big thanks for the clarification from TravellingTechGuy who put together a really nice SecureToken flow chart. You can find that chart here.

2. “Important: In macOS 10.13.5 or later when using a directory service and mobile accounts, users won’t be prompted about SecureToken during first login if there are no SecureToken accounts already available on the Mac. See below for additional information.”

In 10.13.3-10.13.4 directory users were prompted with this message even if the first user was logging in. You had to hit bypass to get that first login SecureToken. Now as this message states, if you logged in as the first user you are not prompted. The document also goes over how you can disable this pop up.

Seeing this note reminds me of an additional change to the SecureToken Pop up message in 10.14.4. When you log in the SecureToken message will not come up if the SecureToken account already on the system is not an admin. The point of this change is that the SecureToken user has to be an admin to enable the new user logging in. If the standard SecureToken user is not an admin don’t even bother to show the message because you would be unable to add the new user to FileVault anyway.

3. ” Managing which users can unlock a FileVault encrypted volume should generally be done using the command-line tool fdesetup. However, you can use the command-line tool sysadminctl specifically to modify SecureToken status for user accounts on the Mac. This should be done with caution and only when necessary.“

It’s interesting how Apple actually recommends using fdesetup instead of sysadminctl. The reason I say that is that we all use sysadminctl to create accounts and mange SecureToken.

The problem with using fdesetup to add an additional user to FileVault is, the account does not show the securetoken as enabled. Instead you should really should use diskutil apfs listCryptoUsers / or sudo fdesetup list -extended to get a proper list of enabled CryptoUsers. I am just pointing out that we are still having non consistent results when checking the FV2 status of a user when using sysadminctl.

You can try this yourself in 10.13.6 (17G6029) & 10.14.4 (18E226)

sudo fdesetup add -user adminuser -usertoadd mrmacintosh

sudo fdesetup list

adminuser,C26BADFD-6763-093E-8U73-3K13EN938AL3

mrmacintosh,93K18AE6-H187-497C-928F-3K13EN163AL3

sysadminctl -secureTokenStatus mrmacintosh

sysadminctl Secure token is DISABLED for user mrmacintosh

You can still unlock the volume in this condition and will report properly using the above command diskutil apfs listCryptoUsers / or sudo fdesetup list -extended.

Conclusion

In this article I point out a few things that still need some work. With that said, this document is a move by Apple to give us the needed documentation that we have asked for. We are also seeing more information in beta patch notes and Enterprise Content when a combo update is released. I hope this trend continues!

Apple Link to Device And Data Security Use of SecureToken.

https://help.apple.com/deployment/macos/#/apd8faa99948

If you are outside the US you can use this link

https://help.apple.com/deployment/macos/?lang=en#/apd8faa99948

Shout out to Rich Trouton ‏@rtrouton for the late night heads up on this.

Also to Neil Martin @neilmartin83 for noticing that the link does not work outside the US!

SecureToken Documentation

Mojave 10.14.4+ will now sync your AD password to FileVault if forgotten

If you use Active Directory Mobile Accounts with FileVault, password sync problems will be very familiar to you. I have good news, MacOS Mojave 10.14.4-10.14.6 can now sync AD Mobile Account password changes to FileVault when you don’t know the AD password. Apple added this new feature to macOS 10.14.4 for Mobile Accounts. In previous releases, you needed the old password to sync the password down to FileVault. Local Accounts has had this ability for years. Rich Trouton put together a great article on Resetting and Syncing FV2 Local account passwords. He mentions the methods are only for Local Accounts, NOT Mobile Accounts.

You forgot your AD password on 10.13.0-10.14.3

Users who fall into this situation are in a pinch and options to get the system to sync the new password to FileVault are limited. You could boot the system up using the PRK (Personal Recovery Key) and then have the Help Desk reset the AD password. This would get you into the system but your FV2 password would never sync. You will be forced to continue to unlock the Mac with the PRK (Personal Recovery Key), then login with the new AD password.

The only way to fix this was to have a SecureToken Admin on the system.

Do you have an admin support account that is FileVault/SecureToken enabled? Listed below are two methods to fix out of sync passwords.

1. fdesetup remove / re-add user

sudo fdesetup remove user userwhoforgotpass.

Then re-add the user by running

sudo fdesetup add user localadminuser -usertoadd userwhoforgotpass

What this would do is remove the user from the enabled FileVault user list, then add them back. The sync would happen when you are prompted for the new password when re-enabling the account for FileVault unlock.

2. Sysadminctl -secureTokenOff/On

You can also use sysadminctl. Start by turning off SecureToken and then turn it back on.

sysadminctl -secureTokenOff userwhoforgotpass -password – -adminUser localadmin -adminPassword –

Now turn SecureToken back on.

sysadminctl -secureTokenOn userwhoforgotpass -password – -adminUser localadmin -adminPassword –

The process of turning off SecureToken and then turning it back on will sync the password. Also note that you don’t have to run sysadminctl with sudo.

Problem is, some companies don’t want a FileVault enabled admin account on the system.

NOTE: diskutil apfs updatePreboot / – Does NOT sync the password!

Running diskutil apfs updatePreboot / does NOT sync the password from the OS to FileVault. If this worked in the past, it was only a coincidence. If you changed your AD password outside the Mac, password syncing to FileVault would sometimes take 2-3 restarts. This command is only really needed when you wanted to add a new FileVault user to the system. Running this command would then add the new user to the FileVault pre-boot window. You only had to run this command in 10.13. This was actually a bug and was fixed in 10.14. The new account will now automatically show up at the FV2 pre-boot window after creation.

Enter the 10.14.4 update.

I can’t file this under my previous article 3 undocumented macOS Mojave 10.14.4 Enterprise fixes. This fix was actually documented in the Enterprise Content article for 10.14.4. The problem is the wording is a little confusing, but does kind of make sense.

Reading the third line, it does seem to match our situation. If you forgot your AD password, you would have to continually unlock the Mac with the PRK. You would be forced to do this each time you turned on your Mac or restarted. Notice the wording, it does not say “Fixes”.

How to reset your AD mobile account password and have it sync to FileVault, when you don’t know the previous password.

You need to meet all of the following pre requisites.

macOS Mojave 10.14.4 or newer.
Active connection to Active Directory.
Access to the PRK (Personal Recovery Key)
You have the ability to change your password outside the Mac (2nd Mac, Windows PC, or Web Portal). Or the Help Desk can reset and issue you a temporary password which you can then use to set a new password at the loginwindow.
FileVault Automatic Login enabled

Step 1. Boot Mac with the Personal Recovery Key.

Since you don’t know the previous password you can’t even get past the FileVault Unlock Screen. You will need access to the PRK. Click the user who needs their password reset. In the password line, you will now see a ? button. Click on it, you can now type in the Personal Recovery Key. Try this neat trick to get the Macs serial number. Click the ? a second time.

Pretty neat trick so users can tell the Help Desk the Macs serial number. (Key Escrow or MDM required).

After booting the system with the Personal Recovery Key the process will stop at the login window. On 10.13.0-10.14.3 systems you are prompted to reset the password at the login window.

Mobile Account Password reset pop-up for 10.13.0-10.14.3 systems after booting with the PRK.

This feature is for Local Accounts Only. To change your AD Mobile Account password from the Mac you must give Active Directory the OLD password. You can only do this with System Preferences > Users & Groups > “Change Password” or dscl. As you can see above the interface does not have a box for Old Password.

10.14.4 will now show a new pop up for Mobile Accounts after booting with the PRK.

This is the new 10.14.4 Mobile Account password reset message, but you still can’t reset the AD password here.

The Mac now realizes that you are trying to reset a Mobile Account Password. You will no longer see the Reset Password pop up. This is because AD requires that you enter in the OLD password. Since you don’t know it, you will not be able to reset your password. This is why macOS will not show you the password reset window anymore for mobile accounts. If you use the PRK from a Local Account you will get password reset window with password fields like you would normally expect.

Step 2. Reset the AD Password.

As noted above you for this to work you can reset your AD password one of two ways.

Call the Help Desk and have them reset the password and then issue you a temporary password.
Reset the password on a 2nd Mac, Windows PC, Web Portal etc.

Either way will work for the password change system to work.

If you called the Help Desk and had them reset your AD Password they can now give you a temporary password. Your account will be flagged “Password must be changed on next login“. Enter in your username and then type in the temporary password. Hit enter and you will now get a new pop up window.

Enter in your new password. Click Reset Password when ready. You will be greeted with the login keychain message. You will receive this message anytime you change the password outside the Mac. Click “Create New Keychain” and the Mac will continue to login.

Step 3. Restart to complete the FileVault sync.

You will need to restart at least one more time to complete the sync process.

On this next restart you will need to enter in the PRK ONE MORE TIME.

NOTE: I am still trying to figure out if having to use the PRK twice is a bug or not. I think it is because you don’t have to do this extra step with local accounts.

After you perform one last PRK boot, enter in the username and new password and you will be at the desktop once again. The process is now complete, you can restart to confirm. Use your new AD password to unlock the volume and the system will now auto boot you to the desktop.

Conclusion

This is my 3rd article on password fixes/improvements/problems in 10.14.4

macOS Mojave 10.14.4 update fixes AD Mobile Account/FileVault password change sync issue.

10.14.4 Update breaks local account password reset when using FileVault Recovery Key

MacAdmins who use Active Directory Mobile Accounts want a working password change system that functions seamlessly with FileVault. Now that we have a working native AD Plugin, will this stop the mass exodus to Local Accounts? Only time will tell.

3 Undocumented macOS Mojave 10.14 Enterprise Fixes

In this article, I will talk a little bit about the current state of Apple’s Documentation. After that, I will show you 3 Undocumented 10.14 Mojave fixes that can help you as a MacAdmin.

Documentation, Documentation, and Documentation. Say it three times fast! MacAdmins just want Apple to provide proper documentation for features, controls and security settings and Enterprise Fixes. In some cases, Apple provides excellent documentation. An example of this would be the T2 Security Chip Security Overview released in October of last year. In other cases when it comes to binaries like sysadminctl not so much.

I tried to searching for something that specifically mentions SecureToken or sysadminctl and came up empty.

The best that I could find was a document called “If you see authentication server errors when turning FileVault on in macOS High Sierra“. This article does not even mention SecureToken. You can get a few nuggets of information by checking the sysadminctl binary options but sysadminctl doesn’t have a man page. I even performed a search on developer.apple.com/documentation as you can see in the picture above. I will be writing about sysadminctl next week. Maybe I can create a MacAdmins version of a sysadmincatl man page! Yet when I search for “SmartCard” three documents show up. SmartCard support is a small piece in the overall macOS pie, yet has multiple documents! Side Note: Shout out to all my peeps in the MacAdmins.slack.com #SmartCard channel (about 5 people) 🙂

Documentation is getting better.

If you have been keeping track, Apple documentation is getting better. If you look at the “What’s new in the updates for macOS Mojave” page you will see a large number of fixes. Eagle eye MacAdmins will be first to spot “Enterprise Content”, this is the stuff MacAdmins are interested in.

10.14.2

10.14.3

10.14.4

Check out that first one under 10.14.4! As noted in my previous article, I fought to get that one fixed since 10.14.0. It’s really great to see that fix get mentioned in the Enterprise Content area.

What do you mean undocumented fixes ?

Apple is constantly fixing things behind the scenes. MacAdmins continue to file radars, call Apple Care, test beta releases, submit feedback and submit Apple Enterprise Support tickets. Defects and bugs ARE getting fixed but are not listed in Apple’s Enterprise Content listing. I am not totally sure why certain fixes do not make the list.

Maybe Apple wants to keep the list short while focusing on the major fixes. I wish Apple would list more of them, even if they posted them in an enterprise only area. An example of this would be AppleSeed for IT. If you are part of an Enterprise or School you can be selected to join the program. I highly recommend joining if you are not a member already. You can read the FAQ about joining eligibility here. Inside you will find links to macOS beta downloads and beta documentation. Each beta release (Sometimes up to 6 releases per combo update) will show what has been fixed between updates. This is great information for any MacAdmin to have so you can stay on top of what’s going on.

3 Apple Enterprise fixes included in 10.14.0 – 10.14.4

1. macOS 10.14 Mojave can now provide FV2 Authenticated Restarts for Combo and startOSinstalls.

In 10.14 macOS Updates and Upgrades are now able to perform Authorized Restarts. This feature was not an option in previous releases. This is a pretty big deal, especially for #MacEDU and Enterprise customers who have computer labs.

Previously if you installed a macOS update and the system was FV2 encrypted it would restart but STOP at the FV2 unlock screen. If you performed this update remotely you would lose control of the machine. Things get worse at FV2 login window because firmware will shut the Mac down after 5 minutes of inactivity. The same problem will happen when you start a macOS Upgrade. You will be disappointed after returning from lunch thinking the update is complete only to find the Mac turned OFF. You then power the Mac back on only to find the installer has just started with 40 minutes remaining. With 10.14 if you kick off a combo update or macOS upgrade the installer will perform an Authorized Restart and you will never get stuck at the FV2 prompt again!

For startosinstall you just have to store the mojave.app in a folder like /Users/Shared. Then kick it off with this command – sudo /Users/Shared/Install\ macOS\ Mojave.app/Contents/Resources/startosinstall –nointeraction The –nointeraction option will prevent license agreement message.

2. Installing software updates using the -R restart option at the login window now properly restarts the Mac to the installer. (10.14.4)

When Apple released the T2 security chip they also added additional options to the softwareudpate binary so it could handle BridgeOS updates. Installing a combo update on a T2 Mac is now a multi-step process. Using softareupdate step one remains unchanged, it will download the combo update from Apple which in turn stores in /Library/Updates. For step two, the Mac reaches out to Apple’s personalization service (gs.apple.com) verify the BridgeOS and combo update. When the verification is complete you will have a new folder in /Library/Updates called PersonalizedManifest.

You are automate the entire process by using sudo softwareupdate -iaR. Options -i will install the update, -a will download all updates and -R will perform an automated restart. The process works just fine if you are the logged in user. If the system needs to update the BridgeOS the Mac will shutdown and then will power back on with the T2 Chip to install the BridgeOS update. If the system does not require a BrigeOS update the system will restart to the update installer. The problem comes in if you try to automate the install from the login window using the softwareupate -R or –restart option. Softwareudpate will run run through the process listed out above only to stop at the very end and be unable to restart.

Looks great until the very end, when at the login window the system will NOT restart!

Once all your Macs are updated to 10.14.4, you can now use the -R restart for all situations. Softwareupdate can now restart the Mac if it’s at loginwindow.

3. 10.14 FV2 Authorized restarts can use the PRK (Personal Recovery Key) again.

When 10.13 arrived you could no longer perform FV2 Authenticated restarts using the PRK (Personal Recovery Key). This feature was just flat out broken. This previously worked in 10.12 Sierra and below. NOTE: You could still perform an Authorized restart with your FV2 name and password. An example of a PRK Authorized restart would be if you are a JAMF Pro customer and had a policy that installed a package but it also required a restart. You could select the option “Perform Authenticated Restart” Jamf would then send a fdesetup authrestart using the PRK. The package would install and then the system would perform an FV2 authorized reboot so the user did not have to enter in the password at the FV2 unlock screen.

10.12, 10.11 & 10.10 – Works!

sudo fdesetup authrestart = Enter a password for ‘/’, or the recovery key:

10.13 – Doesn’t work

sudo fdesetup authrestart = Enter the user name: ( hit the enter key to toggle Recovery Key Entry) = Error: Missing user name. Error: Unable to restart (error = -54).

10.14 – Works again!

sudo fdesetup authrestart = Enter the Username: (again hit the enter key to toggle Recovery Key Entry) Enter the current recovery key:

I hope that at least one of the fixes I mentioned in this article helps you. In the future I would love to see more documented Enterprise fixes listed in the combo update patch notes. Until then though, I will continue to document said fixes and let you know about them when I can.

If you have any questions or comments, please feel free to reach out!

10.14.4 update fixes AD Mobile Account/FileVault password change sync

Before we get started I’m am going to talk a little bit about how macOS and Active Directory work together. I will also go into some history behind the built-in AD Connector. In the end, I will explain the current problems we are having with Active Directory Mobile Account password syncing and how Apple fixed the issue.

If your company or school uses Active Directory, you most likely use Mobile Accounts. To get Mobile Accounts to work you first have to bind the Mac to Active Directory, once bound the Mac is now trusted. You can now log in with any Active Directory user and access to Global Groups, Kerberos and Directory Contacts.

Sounds great right? It was!

Once you log in, the system caches your AD account to the local directory. If you then disconnect the Mac from the network you can still log and continue to work. When the time comes to change your AD password you could change it on a 2nd Mac, a Windows device or even a Web Portal.

How did the AD password change work?

If you changed your password on the Mac it would first check if any password requirements are set at the domain level. If you passed the requirements the password would be immediately changed in Active Directory. The password would then change at the local offline level of your Mac. If you changed your password outside the Mac (Web Portal etc..) the system would receive the password change the next time you connected the Mac to the network and logged in. You would then be promoted to Update or create a new Login Keychain.

Active Directory & FileVault 2

The AD password change system changed in 10.7 with the addition of FileVault 2. Now when you changed your password an extra step had to be performed. Once the password was changed in AD it would then change the locally cached password and then had to sync that password down to your FV2 account. When you turned on your Mac, you could then use the same password as your AD account to unlock the volume and start booting the system. The AD password sync system worked pretty well from 10.7 all the way up to 10.12 Sierra. Users would sometimes have issues here and there when the Mac dropped off the domain but usually a rebind and would save the day.

10.13, APFS and SecureToken

Apple introduced the next-generation file system called APFS (Apple File System). We first got to test it out in 10.12 Sierra in beta form. APFS was standard for all SSD drive installations on 10.13 High Sierra installs. You could still opt out with commands and spinning hard drives would still use HFS. When 10.14 arrived APFS was standard across all hard drives. The introduction of APFS brought an added undocumented security feature called SecureToken. If you wanted to enable FileVault 2 you had to have SecureToken enabled for said account. You could no longer you use the PRK (Personal Recovery Key) or even a local admin to add extra users to unlock the volume like you could with HFS. You have to grant the 2nd user a SecureToken before they could become an authorized CryptoUser. To get the token in the first place you had to be the first user logging into macOS at the SetupAssistant.

10.13 was the start of syncing issues for Mobile Accounts.

The main problem with this new system was that the SecureToken system was not tested. Mobile account users, in particular, had nothing but problems with this new system. From 10.13.0-10.13.3 AD Mobile Account password syncing to FV2 flat out did not work. During this time frame we had multiple high priority tickets in with Apple Enterprise Support. When 10.13.4 hit Apple finally fixed the issue and password syncing started to somewhat work again. I say somewhat because everyone still reported issues but at least it worked SOME of the time now. 10.13 still had problems when you changed the password off the Mac.

Enough of the history lesson, get to the 10.14 problem!

Once 10.14 hit we were hoping that the problems we had on 10.13 Mobile Accounts would fixed. Unfortunately, we were wrong, way wrong. The problem worse when 10.14.0 released. How could it be worse than 10.13 and how did miss the problem in 10.14 beta? On 10.13 as I mentioned above we had to deal with of Mobile Account syncing of FV2 passwords. The user would change the password outside the system and it would not make it down to FV2. The good thing is we actually have fix for this!

The following instructions will change or Sync the password for the CryptoUser account that belongs to the AD user. This will only work if the user KNOWS the old password since the command will prompt for the current password.

1. diskutil apfs list (Grab the disk label for Volume Macintosh HD usually disk1s1)
2. sudo fdesetup list -extended (grab the UUID of the OS USER) You can also use diskutil apfs listCryptoUsers /
3. diskutil apfs changePassphrase disk1s1 -user UUIDhere (add in the UUID of the OS USER from the pevious command and put it in UUIDHere.

That’s cool, but you still haven’t told us why is the situation worse in 10.14?

The local cached offline password is never changed!

The problem is the issue is undetectable UNTIL the user attempts to authenticate OFF the network. When they try the current password it will NOT work. They will then have to call the helpdesk, who then changes the AD password making the situation even worse. This is the situation for 10.14.3 and below.

When connected to the network = Current AD Password works!
When Disconnected from the network = ONLY previous password works.
FV2 password = Previous Password.

Things get even more annoying is if the user actually uses the old password to authentiate the Screen Saver while offline. The system will accept the password but then immediately prompt the user to unlock the Login Keychain. This is due to the keychain being set to the current AD password. You would be in a never-ending keychain password cycle.

Do you have a fix for the offline sync issue?

The good news is we do, as long as you have a SecureToken enabled Admin user. All you need to do is turn off SecureToken and then turn it back on. Something in this system will then sync the offline cached password. Shout out to @annemacro on MacAdmins Slack for figuring this out!

sudo sysadminctl -secureTokenOff useraccount -password – -adminUser adminuseraccount -adminPassword –
sudo sysadminctl -secureTokenOn useraccount -password – -adminUser adminuseraccount -adminPassword –

Now that 10.14.4 is out the password sync mechanism now working. As long as you update systems to 10.14.4 before users change their AD password they will not have this issue going forward. I have not had the chance to actually test the 10.14.4 update on a system that is already out of sync. The good news is that even if it doesn’t fix the issue when it is already happening you now have the tools to fix it yourself. The next time the user changes their password they will not experience the issue.

Why did this take so long to fix?

The answer to this question is pretty simple. Everyone missed the bug from beta 1 all the way through into 10.14.0. I performed hours and hours of testing in beta. I was so concerned about that the FV2 password did not sync that I did not even think to test the offline password. Even worse, neither did anyone else including Apple. It was not until around 10.14.2 when I had an enterprise ticket in with Apple and finally got a response.

“This bug will not be fixed until the next release of macOS”

When I read the reply to this support ticket I was in complete shock. Are you going to tell me that we are going to flat out have a NON FUNCTIONING MOBILE ACCOUNT SYSTEM FOR THE ENTIRE 10.14 RELEASE? I could not believe it. The Apple Enterprise Support Engineer I was working with also agreed and he was fantastic to work with and helped work through the issue with me. At this point what else would a #MacAdmin do but RANT in MacAdmins Slack!!! The best way to do this is to document and explain the issue to others. You can then rally other MacAdmins to file Enterprise tickets or Radars. This will draw attention to the issue and generate heat inside Apple Enterprise Support. In the end that’s exactly what happened. We were not the only company that Used Mobile accounts. Those same companies let Apple know that we needed a fix ASAP. Apple realized this was important and fixed this issue for us in 10.14.4. (Thank you Apple!)

Where does that leave Mobile Accounts?

Before 10.13 Mobile Accounts worked very well. We had thousands of Macs connected to AD utilizing Mobile accounts and did not have any issues. Once 10.13 hit things started to go downhill. The problem is, it seems like Apple is not spending enough time on Mobile Accounts. The MacAdmins community has started to realize this and starting at the end of 2017 and into 2018. This began what I call “The great Mobile Account exodus to Local Accounts”. NoMAD and Enterprise Connect make using local accounts while still having the ability to use AD resources easy. Mobile Accounts still serves it’s purpose but it seems the writing is on the wall.

Thanks

If you stuck around to read the entire article I really do appreciate it. If you are at WWDC 2019 or JNUC 2019 I will buy you a beer or non-alcoholic beverage. Just mention coupon code #ISURVIVEDMOBILEACCOUNS.

I hope to write many more articles like this in the future. Over the past 15 years MacAdmins have helped me get to where I am today. I hope I can give back to the community and help the next generation of MacAdmins rise through the ranks! Drop me a note at com gmail mrmacintoshblog