Alright, so this is a real noodle-scratcher here. We're completely lost as to what is going on so I figured I'd put it out there and maybe someone will be able to help.
Just upgraded all of our systems to 10.11.6 a few weeks ago using our process which we've been testing and using for months. We create our base images using AutoDMG and during first-run our admin account was created using this script:
#!/bin/sh
. /etc/rc.common
dscl . create /Users/macadmin
dscl . create /Users/macadmin RealName "macadmin"
dscl . passwd /Users/macadmin <PASSWORD>
dscl . create /Users/macadmin UniqueID 501
dscl . create /Users/macadmin PrimaryGroupID 80
dscl . create /Users/macadmin UserShell /bin/bash
dscl . create /Users/macadmin NFSHomeDirectory /Users/macadmin
cp -R /System/Library/User Template/English.lproj /Users/macadmin
chown -R macadmin:staff /Users/macadmin
We've apparently been using this method for some time now (I've only been here since December, and it's been in use much longer) and it's never been a problem.
This past weekend our systems ran Apple software updates and installed Security Update 2016-001 (we tested it locally and found it was fine, so we let it go out). We received word on Tuesday that another admin couldn't log into the macadmin account that was created. When attempting to log in the password would be accepted but the spinning wheel would not go away..it just sat there forever. The only way to stop it was to kill the loginwindow remotely or reboot the machine. This is occurring on EVERY machine where the update was pushed out.
Now for the confusing part! We found that running "rm -rf /Users/macadmin" from ARD allows you to log in magically. This is great, we don't use this account for anything except diagnostics and on machines without AD binding. We create a policy and scope it to a small lab that just runs that command. It runs fine, but we still cannot log in. After logging in with an AD account we see that the folder is removed and the account is still there. Pushing the command with ARD again allows us to log in. D:
So we decide to go farther and create a small script that completely removes the macadmin account:
#!/bin/sh
/usr/local/jamf/bin/jamf deleteAccount -username macadmin -deleteHomeDirectory
Add this to a policy that creates the account after this script runs (using the built-in account creation tool in the JSS) and it doesn't work. We tried using two policies (one to remove using the built-in JSS account tool and one to add using it also), we also tried using CreateUserPkg to create the account and it also didn't work. The accounts were created in both instances, but we were still unable to login. Going back to ARD and running the "rm -rf /Users/macadmin" command allows us to login again. Adding that line to the script doesn't help. !!!!
At this point we're beating our heads on the desk.
So finally we decided to create the macadmin account with the "jamf createAccount" command after the "jamf deleteAccont" command in ARD and it worked! Account gets recreated and I can log in, great! So I run both of those commands via Casper Remote to test again and, finally, that works too! Now we're on to something...
I created a policy with the following script:
#!/bin/sh
/usr/local/jamf/bin/jamf deleteAccount -username macadmin -deleteHomeDirectory
sleep 5
/usr/local/jamf/bin/jamf createAccount -realname macadmin -username macadmin -password <password>
And this worked! Somehow, that worked and using all other methods (which basically did the same steps) didn't.
I have so many questions here...
- Why did the accounts die in the first place? We've never had an issue creating accounts in the past with the script (We've since moved to adding the account via the built-in method in Casper)
- Why were certain commands only working when run in ARD and not in Casper Remote or in a policy?
- Why didn't the built-in account creation and deletion work...but scripting them did?
Sorry for the novel, we were just so confused by this. I spent an entire day working on a solution to this...thankfully I fixed it this morning with the script above. Now to figure out WHAT cause this.