Skip to main content
Solved

Create new local admin user FV2 enabled

AVmcclint
Forum|alt.badge.img+21

We're under a directive to change all our local admin passwords. I've come to the painful conclusion that I cannot change the FileVault2 password for the admin user without getting hands-on each and every computer. I ran it by my boss and he approves of creating a NEW admin account with a different name and home folder and adding that user to FV2. I discovered that JSS has an option to create a new local account as an admin and enable them in FileVault with a single policy!

I created a policy and filled out all the fields and applied it to one Mac running Yosemite but I keep getting: 

Error adding user to FileVault: Added users failed error

I looked in the system.log on the test computer and it only says:

3/18/16 2:05:17.245 PM Self Service[839]: [ERROR] -[InstallerQueueProcessBinder finishProcess] (line:190)
 --> Policy NewAdminAcct failed with: Error Domain=JAMFSoftware/SelfService Code=30 "The operation couldn’t be completed. (JAMFSoftware/SelfService error 30.)"

It did get so far as to create the account and the home folder in /Users/ BUT it did not make the user an admin even though that box is checked in the policy and it did not enable it in FileVault. Is this functionality broken in JSS? My ultimate plan would be to create a new admin user enabled in FV2, then delete the old admin account.

If someone can tell me how to change the admin password at the same time as their FV2 password via a method i can push through Casper, that would be even better.

Best answer by dwandro92

@AVmcclint - Here's an example of how to pass credentials to fdesetup without actually creating the plist file:

#!/bin/bash

# Set variables to use in this example
enabledUser="Currently Enabled User"
enabledPass="Enabled User Password"
addUser="New User to Add"
addPass="New User Password"

# Generate plist
maintPlist=$(plutil -convert xml1 -o - - <<EOF
{
    "AdditionalUsers": [
        {
            "Password": "$addPass",
            "Username": "$addUser"
        }
    ],
    "Password": "$enabledPass",
    "Username": "$enabledUser"
}
EOF
)

# Pipe plist to fdesetup and add the user
maintResult=$(echo "$maintPlist" | fdesetup add -inputplist - -verbose)

# Output the result
echo "$maintResult"

EDIT:
I went back and re-read your original post, and have a solution that would eliminate the need to create a new management account - kind of. I should also mention that this might be more trouble than it's worth, but here goes:

  1. Set the new admin password (you could do this anytime before step 5. It doesn't neccessarily have to be done before everything else)
  2. Create a temporary account.
  3. Use your existing FV2-enabled admin account (with the old password) to add this temp account as a FileVault user, using the method described above.
  4. Remove the admin account from the FileVault user list.
  5. Use the FV2-enabled temp account to add the admin account as a FileVault user (with the new admin password), using the method described above.
  6. Remove the temp account from the FileVault user list.
  7. Remove the temporary account.
View original
    Did this topic help you find an answer to your question?

    9 replies

    stevewood
    Forum|alt.badge.img+35
    • stevewood
    • Employee
    • 1797 replies
    • March 18, 2016

    @AVmcclint This is a topic I see regularly here on JAMF Nation. I have seen situations where the admin account does not get updated after a password change (using a policy in the JSS to change the password), however I haven't seen it since my Yosemite machines got to the 10.10.5 level. Now, if I change the password to the admin account, the password for FV2 changes as well. Have you tested this recently?

    As to the error you are receiving, have you tried two policies: one to create the new admin user and a second to add that user to FileVault? I would maybe test that method just to rule out which part of the policy is failing.

    AVmcclint
    Forum|alt.badge.img+21
    • AVmcclint
    • Author
    • Esteemed Contributor
    • 1043 replies
    • March 18, 2016

    UPDATE: I figured out why it didn't create the new user as an admin. That was my goof.. I thought I checked the box for it but apparently I did not. So one problem down.
    I deleted the user and the home folder it created and I tried it again. This time i did create the user properly as an admin, it did create the home folder correctly, but it still generated the same errors did not add it to FileVault. IN FACT, when I went to System Prefererences > security, it didn't even say anything about a user not being enabled. I had to reboot the computer and login as an existing user before it would give me the "Enable user" button.
    I don't know if it makes a difference but we are using an Institutional key for FV2.

    As for running 2 policies like you suggest, I'd love to try that but there is nothing that I can find built-in to JSS that ONLY says Enable user in FileVault2. The only way to get that checkbox is to choose to create a new user, but that doesn't work because it sees the existing account already there and generates errors.

    AVmcclint
    Forum|alt.badge.img+21
    • AVmcclint
    • Author
    • Esteemed Contributor
    • 1043 replies
    • March 18, 2016

    OH, and to answer your question about changing the admin password and it automatically syncing with FV2, yes I've tried that. I made a policy that ONLY changes the account of the local admin account but upon reboot, it only accepts the old password to unlock the drive while it accepts the new password at the 2nd login screen. Do I need to let it sit for a while and reboot again before it syncs?

    If I change the password via System preferences on the computer, that always gets the passwords in sync, but I'm trying to do this so I don't have to login to each and every computer manually to do that.

    H
    Forum|alt.badge.img+16
    • hkabik
    • Honored Contributor
    • 330 replies
    • March 18, 2016

    You could split it into multiple policies using fdesetup.

    https://derflounder.wordpress.com/2015/12/20/managing-el-capitans-filevault-2-with-fdesetup/

    stevewood
    Forum|alt.badge.img+35
    • stevewood
    • Employee
    • 1797 replies
    • March 18, 2016

    @AVmcclint I do believe the computer needs to "bake" for a few minutes for the sync to happen, but I could be wrong. The machines you are testing on are 10.10.5, right?

    AVmcclint
    Forum|alt.badge.img+21
    • AVmcclint
    • Author
    • Esteemed Contributor
    • 1043 replies
    • March 18, 2016

    I saw somewhere that it was possible to pass the ID & PW of users to fdesetup via an input file but I could never find the format the file needed to be in! If I can get this to work, then that might be what I need. And it would satisfy the potential requirements of simply changing the PW of an existing account or creating a new account and deleting the old one. Thank you for pointing me in that direction. I would assume the format of the input file is the same for Yosemite as it is for El Capitan?

    Fortunately for me, it's nearly quitting time on Friday so I can go home soon and relax until Monday when I will test this out.

    D
    Forum|alt.badge.img+9
    • dwandro92
    • Contributor
    • 125 replies
    • Answer
    • March 18, 2016

    @AVmcclint - Here's an example of how to pass credentials to fdesetup without actually creating the plist file:

    #!/bin/bash

# Set variables to use in this example
enabledUser="Currently Enabled User"
enabledPass="Enabled User Password"
addUser="New User to Add"
addPass="New User Password"

# Generate plist
maintPlist=$(plutil -convert xml1 -o - - <<EOF
{
    "AdditionalUsers": [
        {
            "Password": "$addPass",
            "Username": "$addUser"
        }
    ],
    "Password": "$enabledPass",
    "Username": "$enabledUser"
}
EOF
)

# Pipe plist to fdesetup and add the user
maintResult=$(echo "$maintPlist" | fdesetup add -inputplist - -verbose)

# Output the result
echo "$maintResult"

    EDIT:
    I went back and re-read your original post, and have a solution that would eliminate the need to create a new management account - kind of. I should also mention that this might be more trouble than it's worth, but here goes:

    1. Set the new admin password (you could do this anytime before step 5. It doesn't neccessarily have to be done before everything else)
    2. Create a temporary account.
    3. Use your existing FV2-enabled admin account (with the old password) to add this temp account as a FileVault user, using the method described above.
    4. Remove the admin account from the FileVault user list.
    5. Use the FV2-enabled temp account to add the admin account as a FileVault user (with the new admin password), using the method described above.
    6. Remove the temp account from the FileVault user list.
    7. Remove the temporary account.
    AVmcclint
    Forum|alt.badge.img+21
    • AVmcclint
    • Author
    • Esteemed Contributor
    • 1043 replies
    • March 21, 2016

    Thanks @dwandro92, that script seems to work for me. I tried using an input file but it never seemed to do anything. It just sat there when I ran the command. My guess is it might be because we're using an institutional key. Either way, the script you provided was able to add a user just fine.

    Here's my planned workflow:
    1. To satisfy our InfoSec team, I'm packaging the script in a .pkg that copies it to /tmp
    2. Add the package to the policy to create a new admin user
    3. the script runs to enable that new user
    4. the script file is immediately deleted from /tmp
    5. At a later date, I'll delete the old admin account after I confirm everything is ok.
    6. I'll still need to roll into the script a kickstart command to enable ARD permissions for the new admin account. And then update all my computer lists in ARD with the new account.

    Man, there's a lot to consider when changing an admin password! Luckily the admin account I need to do all this for is not the Casper management account.

    K
    Forum|alt.badge.img+8
    • krispayne
    • Contributor
    • 69 replies
    • December 22, 2016

    I'm planning to do some of the same things as listed in this post. I made a test policy for my machine to create a new local admin called 'jssadmin' and ensured that I checked the box for allowing the user to administer the computer. Once the policy ran, the user was created, yet no admin. This is on 10.12.2.

    My ultimate goal is to change the management account (which is also our local admin account) password. I've had some strange things happen with admin accounts lately (them losing their admin privileges) so I wanted to test this functionality. I'm on JSS 9.97

    Reply


    Most helpful members this week

    Terms & ConditionsCookie settingsAccessibility statement

    Cookie policy

    We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

     
    Cookie settings