ºÚÁϺ£½Ç91Èë¿Ú

To bind a user to a device, the ºÚÁϺ£½Ç91Èë¿Ú agent either provisions a new local user account to the device or takes over an existing local user account. Taking over an existing account allows ºÚÁϺ£½Ç91Èë¿Ú to manage that account, rather than create another account on the device. 

If you want to provision a new local user account, see Connect New Users to Resources. 

Prerequisites:

• To take over an existing user account on a device, the ºÚÁϺ£½Ç91Èë¿Ú agent needs to be installed and the device needs to be active. See Get Started: Devices for more information. 
• The user must be connected to the device in the Admin Portal. For more information, see Connect New Users to Resources.
• You need the local usernames of the accounts you want ºÚÁϺ£½Ç91Èë¿Ú to take over so you can ensure the ºÚÁϺ£½Ç91Èë¿Ú Username or Local User Account field in the User Details tab matches the local username on the device. If the Username or Local User Account fields don't match the name of the local account, you end up creating an additional profile on the device with the Local User Account as the username. If you need help finding the names of local accounts, see Find Names of Local Accounts on Devices.
  • Additionally, the Local User Account field must be unique in the directory for successful account takeover. For example, if there are two "John" users on two separate devices, one of those users must be renamed.

Considerations:

• The ºÚÁϺ£½Ç91Èë¿Ú username is what your end users use to log in to devices and other resources you connect to ºÚÁϺ£½Ç91Èë¿Ú. Your end users won’t see the Local User Account name. When an end user logs in to their device, they see their ºÚÁϺ£½Ç91Èë¿Ú Display Name (first and last name). 
• Learn about ºÚÁϺ£½Ç91Èë¿Ú username requirements and considerations in Naming Conventions for Users.
• ºÚÁϺ£½Ç91Èë¿Ú usernames must be unique across your organization and can’t match existing Local User Accounts.
• The ºÚÁϺ£½Ç91Èë¿Ú username and Local User Account fields can only be edited before you bind a user to a device. Once bound, you have to unbind a user to edit the ºÚÁϺ£½Ç91Èë¿Ú username again. See Unbind Users from a Resource. 
• Local user accounts aren’t case sensitive.
• To complete the takeover process, users need to be bound to the device.
• As this process is writing the user’s password through Mac Keychain and the Windows Data Protection APIs, users will be logged out of all resources after account takeover. This is expected behavior. Some examples of these resources include 1Password, Dropbox, Google Drive, Slack, Microsoft Office, Google Workspace, Microsoft Teams, Chrome, Firefox, Edge browsers, etc.

• For macOS devices, there are additional considerations. See MacOS Account Takeover Considerations below.  

Take Over an Existing Account with the ºÚÁϺ£½Ç91Èë¿Ú Username Field

If your user’s local account on the device matches their ºÚÁϺ£½Ç91Èë¿Ú username exactly, for example, if it is the user’s company email, then you can take over the existing account and the user will keep their username and use their ºÚÁϺ£½Ç91Èë¿Ú password to log in. 

To take over an existing user account with the ºÚÁϺ£½Ç91Èë¿Ú Username field: 

1. Log in to the .
2. Go to USER MANAGEMENT > Users.
3. Select an existing user or create a new user. See Get Started: Users for more information.
4. On the Details tab in Users, enter a name for Username. Make sure it matches the name of the local account you want to take over. See Prerequisites. 
5. (Optional) To bind the user to a device, go to the Devices tab, then select the device you want the user account to take over. 
6. Click save user. 

Take Over an Existing Account with the Local User Account Field

If your org’s local account naming convention isn’t ideal for an employee’s username, you can use the Local User Account field to take over their account. Then you can use the ºÚÁϺ£½Ç91Èë¿Ú Username field to give the employee a friendly username they can use to log in to all of their other ºÚÁϺ£½Ç91Èë¿Ú-protected resources such as LDAP and RADIUS. 

To use Local User Account to take over an account:

1. Log in to the .
2. Go to USER MANAGEMENT > Users.
3. Select an existing user or create a new user. See Get Started: Users.
4. On the User panel’s Details tab, click + Local User Account.
5. After you read how you can use Local User Account to take over a device, click okay, got it. 
6. Enter a name for Local User Account. Make sure it matches the name of the local account you want to take over. See Prerequisites. 
7. (Optional) To bind the user to a device, go to the User panel’s Devices tab, then select the device you want the user account to take over. 
8. Click save user. 

If taking over an existing user account fails, double check that you’ve met the prerequisites. If you still have issues, see Agent Doesn’t Start or Synchronize Changes for additional troubleshooting steps.
 

MacOS Account Takeover Considerations

For account takeover to update the "local items," Keychain, and FileVault correctly on macOS devices, users need to log out, then log back in to their device after their ºÚÁϺ£½Ç91Èë¿Ú identity has been bound to their endpoint.

As this process writes the user’s password through Mac Keychain and the Windows Data Protection APIs, users will be logged out of all resources after account takeover. This is expected behavior. Some examples of these resources include 1Password, Dropbox, Google Drive, Slack, Microsoft Office, Google Workspace, Microsoft Teams, Chrome, Firefox, Edge browsers, etc.

For the KeyChain and FileVault to be updated correctly when an account is taken over by ºÚÁϺ£½Ç91Èë¿Ú, users must log out and log back in to their device after they are connected to the device in ºÚÁϺ£½Ç91Èë¿Ú. When users log back in to their device, they will be asked for their previous password and their current password.

After the user enters their previous and current passwords, they will be logged in to their device. A successful account takeover is indicated by the appearance of the ºÚÁϺ£½Ç91Èë¿Ú Menu Bar app in the top right of the Mac computer screen.  

Best Practices for Devices with a Single Local User Account

We no longer recommend binding a secondary account to a macOS device as a best practice. Previously, ºÚÁϺ£½Ç91Èë¿Ú recommended binding a secondary account to macOS devices as a preventative measure against complete lockouts in the event that a single, local ºÚÁϺ£½Ç91Èë¿Ú-managed user was deleted from the device. However, ºÚÁϺ£½Ç91Èë¿Ú has made improvements to user deletion and suspension on macOS, such that the last remaining Secure Token user on the device cannot be deleted or suspended.

In cases where a device has its only local account taken over by ºÚÁϺ£½Ç91Èë¿Ú, and admins subsequently need to remove the user's access to the device, our recommendation is to leverage the lock device security command. This method requires that the device be enrolled in ºÚÁϺ£½Ç91Èë¿Ú MDM. The admin must record the PIN used to lock the device in order to access the device later. See Lock a macOS device.