Administrator account scrambled into Network account?

[CrepuscularDave]

For some years now we've been encountering the odd mac where even though newly-enrolled, the local admin password does not work. With no way to login, we were reduced to Recovery Console, wipe and re-enroll.  To mitigate this we created a backup admin account to allow us a way in, but with the advent of Secure Token things have got weirder. Has anyone experienced this?  Here is our setup:

1. Our student macs are enrolled with a prestage where a single local admin account "Admin1" is created before setup assistant.
2. A Jamf policy then creates a second admin account, "Adminbak". 
3. Setup assistant does NOT create a local account, instead we later bind the macs to ADS and network users then logon.  Adminbak was created to be the first account created after setupassistant, so it would get Secure Token. Our onsite techs can then logon to each machine with Adminbak to enable bootstrap.

Here are our symptoms:
4. We are finding that Admin1 has Secure Token instead. We don't know how this is, since accounts created before setupassistant shouldn't get Secure Token.  But we''ll pass that by, as we can live with it.
5. Admin1 password wobbles, will not logon to desktop. Also cannot ssh to it or su to it.
6. Adminbak logs on but does not have Secure Token. Admin1 is the only account with Secure Token, even though it is created by prestage. Hence nobody else can get Secure Token.
7. Although Admin1 exists, there is no home directory.
8. We cannot change the password of Admin1 from Adminbak. We get an error message "One of the parameters provided was incorrect". 
9. We cannot delete Admin1, probably because it has Secure Token and no other account does. Attempting to remove it through Jamf Record does not work either.
10. If we run "dscl . -authonly Admin1 [known password]" to validate the password we do not get the error "eDSAuthFailed" as we would expect if the password was wrong. Instead we get "eDSAuthMethodNotSupported".
11. Today we attempted to run "resetpassword" from Recovery Console and change all passwords. This failed with the error "Could not verify credentials because directory server does not support this authentication method", and also left us in the state where the Mac failed Activation. The only solution was to refresh with AppleConfigurator2

The last two symptoms have caused us to conclude that although Admin1 should be a local account, macOS is treating it as a mobile account, and trying to logon to ADS, where there is no account called "Admin1". Hence why we cannot change the password through "resetpassword".

Is this familiar to anyone else? We don't know if it's a macOS or Jamf issue. We are certain that when it has occurred there is no way out of it other than wipe and re-enroll, but it would be good to find the cause and therefore prevent it in the first place.

Cheers

DaveB

[AJPinto]

Secure Token generation typically can only happen when an account interactively logs in to macOS. Depending on how an account is created DHCL can be told to force generate the first Secure Token which is generally not a good thing to happen, especially if you don't know the password. Jamf does not use this flag when creating an admin account using Pre-Stage, so your first admin account (created with Pre-Stage) should not have a Secure Token until you log in to macOS with it. Since your Pre-Stage Admin account has a Secure Token and no one is logging in with it, something does absolutely seem strange.

Jamf should be able to tell you if an account is a local account or a mobile account. Generally speaking, without a ton of scripting there is not a way to make a local account into a mobile account. MacOS is not really designed to use domain binding anymore and has not been for a very long time. When you log in to a mac, macOS first checks the local keychain. If it sees credentials that match what you are using it lets you log in. If it does not see credentials for what you are using, it will shake (bad credentials). If you are domain bound or have PSSO enabled macOS will check the IDP to see if the user's credentials exist (never mind Okta nor Azure support on demand account creation yet). I don't see how the local account could become a mobile account, but you could skip AD binding the device to check that.

Have you tried removing and re-adding your local admin account in the Pre-Stage?

Depending on your Jamf Settings, the Jamf Binary may also make a local admin account. Both this Jamf Binary account, and the Pre-Stage account should be able to have their passwords checked out in the Jamf Console or using LAPS. Any luck with checking out Managed Admin Account passwords?

[CrepuscularDave]

Yes, we already create a Management account (called Jamfadmin) in the User Initiated Enrollment setting.  Plus two admin accounts - one during Prestage and one by Jamf Policy. 

Regarding your assertion that Secure Token needs an account to login before it is granted. We have experienced otherwise.  Previously we did not create an admin account during Prestage, but by Jamf Policy. Because on our student devices an account is not created during setupassistant, this always resulted in the first account created after setupassistant being granted Secure Token immediately upon creation by Jamf.  It did not require that account to be interactively logged in. This is literally what happened - all our student devices had a single account with Secure Token - the first admin account created by Jamf Policy.

However, this caused us problems with our Staff enrollments. Because the staff user's account was created during setupassistant, and before the admin account was created by Jamf Policy, the user was not only granted Secure Token, but also admin privileges. To comply with our CyberSecurity Accreditation our users must not have admin privileges (only in exceptional circumstances).  So we had to move the admin account to the Prestage, to ensure that Staff accounts were created as Standard.

Because staff machine enrollment always involves an interactive login, Bootstrap is always enabled, which then allows Jamf's account Jamfadmin to manage the device. For student devices we still have to log in once interactively with the account that has Secure Token, to enable Bootstrap. A week ago we enrolled 48 new student devices, and on 46 of them the initial admin account created during Prestage was automatically granted Secure Token, even though at no point did our technicians log that account in, until the enrollment had completed, and then only to enable Bootstrap. If we ssh'd in prior to that, we could see that the account already had Secure Token.

2 Machines out of the 48 could not be logged into, because Admin1's password did not work. They could be logged into by our secondary Admin account (Adminbak) which is still created by Jamf Policy. But that account did not get Secure Token, because Boostrap was not enabled, and Bootstrap was not enabled because the only account with Secure Token could not be interactively logged in with. 

Incidentally I am not the only person who has encountered this, as you can see from this blog post. Unfortunately the post is primarily concerned with how to create a secondary account (which we already do), not with the underlying cause.
http://jamesisin.com/a_high-tech_blech/index.php/2012/05/the-mac-that-broke-the-administrator-accoun...