Skip to main content
Question

Guidance on Managing Local Admin Account and FileVault Integration with Jamf Pro

  • December 19, 2025
  • 3 replies
  • 42 views
F
Forum|alt.badge.img+4

Hello,

Before asking my question, I’d like to briefly describe our current environment:

  • We are using Jamf Pro on-premises.
  • MacBook devices are enrolled using the User-Initiated Enrollment method.
  • During enrollment, a hidden local account named jamf is created on the machine.
  • All devices are domain-joined, and FileVault is enabled.
  • Users log in with their Active Directory (AD) accounts, which are configured as mobile accounts.
  • Initially, we manually create a local admin account named support during setup. This ensures that both the support account and the user’s AD account are enabled for FileVault.

Our security team has raised a concern because the support account currently uses the same password across all devices. They have requested that we either remove this account or implement automatic password rotation, similar to a managed account.

Could you advise on the best approach? How do you typically handle this scenario?

Additionally:

  • Is it possible to add the jamf account to FileVault?
  • Would frequent password changes for this account cause any issues with FileVault unlock?

Note: The reason we need an account in FileVault is that sometimes users change their AD password outside of the MacBook environment. This can lead to login and keychain issues. In such cases, we currently resolve the problem by running the following commands:

sysadminctl -secureTokenOff aduser -password - -adminUser support -adminPassword -
sysadminctl -secureTokenOn aduser -password - -adminUser support -adminPassword -

Any guidance or best practices would be greatly appreciated.

Thank you!

3 replies

howie_isaacks
Forum|alt.badge.img+23
  • howie_isaacks
  • Esteemed Contributor
  • December 26, 2025

I don’t reccomend ever authorizing your admin account to unlock the Mac. The reason is security. You should only want the authorized user to be the one who unlocks the Mac during bootup. I have been using Jamf Cloud for the last nearly 3 years so I don’t know if LAPS is available on an on-prem server. If it is, I recommend using it instead of installing a separate admin account. This has two advantages. First, the admin account is already being installed. In the user-initiated-enrollment settings, you can define the name of the managed local administrator acccount. Second, password rotation is part of using LAPS. You can set your rotation settings. Jamf Pro admins can view the audit log to know who has viewed the managed local admin account password. Binding Macs to AD is now considered to be bad practice. There really are no good reasons for doing it. I would recommend using an SSO solution if your goal is to authenticate users to internal company services.

    AJPinto
    Forum|alt.badge.img+26
    • AJPinto
    • Legendary Contributor
    • December 29, 2025

    Password rotation is not a native MDM function. Jamf Pro includes LAPS, it is designed specifically for managed accounts created during enrollment via a PreStage. Retroactively managing a manually created account with LAPS is not possible, the LAPS entitlement happens as the device enrolls and Jamf creates the account.

    Your current environment relies on several legacy workflows that are likely the root cause of your security and synchronization issues. I recommend a shift toward a modern management architecture:

    • Transition to Automated Device Enrollment (ADE), User-Initiated Enrollment (UIE) limits your management capabilities. By using ADE, you can have Jamf Pro create the local administrator account automatically during the PreStage. This allows LAPS to handle password rotation natively without the manual overhead or the risks associated with static passwords.
    • Move Away from AD Binding and Mobile Accounts Binding Macs to Active Directory is the primary cause of your FileVault and Keychain synchronization issues. macOS is designed as a 1:1 local-account operating system. Password changes made outside of the Mac environment will not sync to the local cryptotoken/FileVault layer in a bound environment.
    • Implement Modern Identity Solutions Replace the AD bind with Jamf Connect, Xcreds, or Platform SSO. These tools allow users to use their cloud identity (Entra ID, Okta, etc.) while maintaining a local account that stays in sync.

    TLDR: Attempting to script Secure Token assignments for existing accounts is notoriously difficult and usually requires user interaction. The most stable path forward is to move toward a "Zero Touch" ADE model and a modern identity provider to resolve these issues at the architectural level.

     

    As a stop gap you can look in to tools like CyberArk EPM to handle password rotation. Just be aware that the account that EPM creates needs a secure token for PW rotation, and the end user must give that account the secure token. There is no way to script granting a secure token currently. To ​@howie_isaacks’s point I dont think LAPS is available onprem, but CyberArk EPM is a 3rd party security tool so it should work fine regardless of where Jamf is hosted.

      howie_isaacks
      Forum|alt.badge.img+23
      • howie_isaacks
      • Esteemed Contributor
      • December 29, 2025

      The requirements for LAPS do not mention that the Jamf Pro server has to be Jamf Cloud.

       

      https://learn.jamf.com/en-US/bundle/technical-paper-laps-current/page/General_Requirements.html

       

      If Macs do not currently have a managed local admin account on them, the only way to get one installed is to re-enroll the Macs. This will install the managed local admin account that was defined in the user-initiated enrollment settings. I had to retroactively install the Jamf agent managed local admin account on several of my Macs that did not have it for some reason. I used a script that ran the Jamf management framework API command. Before I ran the policy with the script, I added the Macs to a group that is excluded from running my zero-touch provisioning policy after enrollment. This enabled me to not interrupt users while they were working. I turned on LAPS account creation during PreStage earlier this year. All Macs that have enrolled from February 14 onward have two LAPS accounts, the MDM LAPS account installed during PreStage, and the Jamf agent LAPS account. I have asked my support team to not log in to either account at the login screen since doing so will authorize them for FileVault. Instead, I showed them how to change the Terminal session to one of the accounts (su AdminAccountName) if they need to run commands in Terminal that require an admin account. I suggest that you abandon the old way of using admin accounts. You don’t need to log in as an admin to have admin rights. I have created a lot of policies for Self Service that my support team can activate using an extension attribute. This gives them quick access to a lot of policies that they can use to run admin tasks.

      Terms & ConditionsCookie settingsAccessibility statement