Introduction to user management

Tip

Use the Action search to navigate Automate

Overview

Automate supports various types of users:

Administrators	Administrator users access the system to perform admin tasks Can be assigned to any hierarchy (provider, customer, or site)
End users	End users are provisioned with services Can be created at any level of the hierarchy, but can only be assigned services at a site.
End User + Admin	A single user account can be configured as both an End User (with services) and as an Administrator by assigning an Authorized Admin Hierarchy containing a self-service role to the user - see: Authorized Admin Hierarchy Roles.

An Automate user exists only on Automate and represents local data associated with that user, including their user details. This user can exist on different hierarchies, and can be created independently, either on Automate directly, or imported from an external source, such as LDAP.

Non-automate users exist on the UC applications, such as Cisco UCM, CUC, Microsoft, Avaya, or Webex. These users represent UC application data and are always associated with an Automate user since they are created once the corresponding Automate user is sent downstream to the UC application. Users brought in from the UC applications are provisioned with phones and/or services only at a site on Automate.

Related topics

• User provisioning use cases
• Multi-vendor users

• User authentication methods

• View users

• Add admin user

• Update a user

• User management scenarios

• User sync source

• User field mapping

• Localization Language

Users and the provisioning workflow

Users are impacted during user provisioning operations, such as LDAP sync, CUCM sync, or user bulk loading.

A typical “top-down” approach to user provisioning progresses from LDAP to Automate user, to provisioned user.

1. Sync user from LDAP into Automate. An Automate user is created.

2. Move the Automate user to a site via Move Users.

3. Push the user to the UC applications. The corresponding provisioned user is created either via Quick Add User or the Users page in the Automate GUI

Note

You don’t need to send all Automate users to a UC application, such as Cisco UCM, and have a corresponding provisioned user created; this is the administrator’s decision, based on criteria associated with each user. It is recommended that you filter out any users from LDAP that are not eligible for UC services. It is possible that some ineligible users can’t be filtered due to missing attributes and thus get synced into Automate. These users remain un-provisioned.

Additional functionality of Automate user

Automate users also allow:

LDAP sync	The workflows to manage syncing users from LDAP.
LDAP authentication	Enabling and disabling LDAP authentication.
SSO	Enabling and disabling SSO authentication.
Provisioning status	Tracking where the user comes from (LDAP, CUCM, manual configuration), and the hierarchy the user was originally added to.
Moving users	Between hierarchy nodes.

Automate user and corresponding provisioned user

All provisioned users have a corresponding Automate user. This allows the user to sign in to Automate (using either local authentication, LDAP authentication, or SSO authentication), and to track the provisioning status.

You can create a provisioned user via the Admin Portal, bulk load, or sync from the UC application, such as a Cisco UCM sync.

An Automate user instance is created automatically. If staging is not required (such as when configuring a user directly on a site, using bulk loading), the admin doesn’t need to add an Automate user explicitly (as a separate step).

Provisioned users at a site provide all of the UC application provisioning logic by distributing the user configuration to each of the UC applications, and combine most of the data associated with a user into one logical entity:

• Cisco UCM users

• Phones

• Lines

• Extension Mobility profiles

• Remote destinations

• Voicemail

• Webex users

A provisioned user is simply a representation of data in the UC applications. Each provisioned user is created when the UC application end user is created, and disappears when the UC application end user is deleted (either on the UC application, such as Cisco UCM directly or from Automate). This user is removed even if there are phones, lines, or profiles remaining that were previously associated with the corresponding user.

When the UC application data is created (such as the Cisco UCM end user), you can view the user in the summary list view. When the UC application data is deleted (such as the Cisco UCM end user), the provisioned user disappears.

A provisioned user is based on data in the UC applications. An Automate user is associated with local data. Any user with a UC applications end user instance displays in the Users list view, regardless of whether they are associated with any other data (such as phone or line).

Note

Any changes on the UC application, such as adding or deleting end users, appear in Automate only after syncing. Refer to the “Data Sync” section of the Guide for more information on data syncing.

Provisioned users are a representation of the data in the UC applications and may be updated either in Automate or in the UC applications directly.

How users are added to Automate

Users may be added to Automate from these sources:

• Synced in from LDAP, and promoted to a user (including flow through provisioning)

• Synced from Cisco UCM

• Synced from Azure (Microsoft users)

• Bulk loaded, via a Bulk loader template

• Manually created

Note

Conflicts between users synced from different sources are handled according to the strategy described in Manage duplicate usernames. For information about user password management, depending on the source of the user, see Password Management.

Users are typically associated with a site. You can create move filters to automatically assign users to sites once they are synced from LDAP or from CUCM. Bulk loaded and manually created users can be moved using filters or by individually selecting users.

Cisco users associated with a site can be added to the UCM that appears in the network device list (NDL) assigned to that site.

For details around how Microsoft users are synced in from Azure and then moved to the sites, refer to Microsoft users

Authentication on log in

Authentication (auth) methods define how a user is authenticated when logging in to Automate, either Automatic, LDAP, SSO, or Local.

If an identity provider (IdP) server is deployed at a hierarchy node above the site, you can configure Automate to provide single sign-on (SSO) support for users created or synced at that hierarchy node.

Note

Typically, Microsoft users will not need to log in to Automate. Their default auth method is Automatic. When the default auth method is set to LDAP, Automate checks with the LDAP server to verify the user’s credentials. Once verified, the user is logged in to Automate.