Administration

As business and systems change over time, so should the administration of managed systems, and they must be handled in a structured, secure, and seamless way.

Identities must be properly authenticated by applying user logins, setting passwords, including 2-factor authentication, as well as other mechanisms.

Managing identities’ passwords can often be a cumbersome process, involving frustrated users and overloaded helpdesks. Instead, Omada Identity includes simple and secure processes for password management. The Administration processes cover the following information:

• Onboarding of new systems and applications
• Performing application management of IGA solutions
• Managing passwords

Managing target systems

Important

In Omada Identity, an application and a system use the same Object Data Type system. However, an application has the Is logical system flag, which indicates it's an application. An application is a logical construct that consists of one or more systems. A system is representing a target system such as Active Directory, SAP, etc.

Create, modify, or terminate target system resources

Resources on the target system are read from a connected system and into Omada Identity using the available data collector interfaces.

Resources are first loaded into ODW, and then either all resources are created in Enterprise Server or during the Onboard application process, which is then used in Enterprise Server to create target system resources.

In Omada Identity, target system resources require data enrichment from the following:

• Ownership
• Show or hide in request access
• Status and validity
• Provisioning relevant attributes
• Approval levels
• Delegation
• Exclusive management
• Post validity

In addition, out-of-the-box, System Owners and Resource Owners have read access to the following:

• Managed systems
• Resources
• Technical identities (related to system ownership)
• Applications
• Accesses (related to system/resource ownership)
• Compliance dashboard (for managed systems)

Onboard an external system

info

The following process is specific to Omada Identity.

The System onboarding process enables Data Administrators to connect and onboard systems from one central view in the Omada Identity portal. For example, in the Compliance Workbench and after finishing the configuration tasks, data imports can be started, and information can be reviewed for further reconciliation.

The checklist ensures a structured and error-free configuration every time new systems must be added, by consequence reducing implementation time and complexity.

Progress bar

The progress bar that shows the overall status of a System onboarding process on the relevant user’s Onboarded system view, is also shown in the following two views, Systems and My systems.

In the Systems view, the color of the progress bar determines the current state of the relevant system.

Color	Meaning
	All required tasks are set to OK, and the system is ready to be included as part of a data import. If there are required tasks related to provisioning that you have not completed, the progress bar still appears in green. This is due to provisioning taking place after data has been imported.
	The system has pending tasks which must be specified before the system can be included as part of a data import.
	At least one task related to the relevant system is in a warning state and requires attention.
	At least one task related to the relevant system is in an error state and requires attention.

The screenshot below shows the Systems view.

System detail view

The System detail view is an individual page for each of the registered systems in Omada Identity.

The view contains a checklist of the tasks, as well as settings that must be configured to begin onboarding or importing data from the new system.

When the mandatory tasks are completed, the page automatically updates the task status and the overall progress bar, providing a quick overview of the configuration progress.

The tasks checklist includes:

• System definition settings
• Resource management
• Data import
• Provisioning

The screenshot below shows the system onboarding view.

System definition

In the System detail view, in the System definition section, in the Connection details view, you can enter system-specific connection details, for example: LDAP paths for Active Directory (AD), hostname, and port number for SAP, and others. The following examples can provide guidance when configuring:

In the System definition section, you can find where System owners are assigned, and which attributes should be imported from the specified system. For example:

Resource management

In Omada Identity, the System Onboarding wizard automatically creates relevant resource types based on the target system such as a Security group and Distribution group for AD.

The screenshot below shows an example of resource types created based on the target system.

For every system, a default Resource Folder is created where the approval level and ownership of resources is defined.

Data import threshold values

The Configure import thresholds view for an import enables you to configure the values in percentages. These values can stop the data import in the case that a large amount of data changes in the source system.

The fields you can configure are:

• New objects

• Modified objects

• Deleted objects

  

tip

Default account rules can assist with matching account and identities, as well as determining account types. Additional rules can also be defined, and custom join rules can also be developed and enabled.

Data imports can also be launched from within this section, and subsequently, the information with the number of matched or classified accounts is available, and the Account Ownership survey can be executed.

Provisioning to the target system

In the following example in the Enable provisioning view, provisioning to the target system is enabled. This can be done by using one of the following:

• Omada Provisioning Service (OPS)
• Manual workflow tasks
• Microsoft Identity Manager Synchronization service (MIM).

info

The following information is optional and only for reference.

In the target system, in the General settings view, you can enable password reset as well as select a password policy.

Additionally, when OPS is used for provisioning, thresholds can be configured for provisioning tasks. For example:

In the Connector settings view, initial passwords and connection details can be maintained.

A system-specific Data model is provided with the default properties, and this can be extended.

Moreover, task mappings are used to map the attributes in the Omada Identity Data model to the attributes in the target system. Omada Identity provides default task mappings and they're also extensible.

For example:

Task mapping details can also be reviewed. For example:

When all the optional tasks have been completed, and to save the configuration to OPS, click Commit settings.

Application onboarding

This section describes how application onboarding is performed using the Onboard application process in Omada Identity.

The goal of this section is to define roles using a meaningful name and description, as well as the ability to compound the permissions in the target system into application-specific roles.

In Enterprise Server – and before managers and end-users can begin requesting access to resources through self-service processes – it's critical that the resources are well described so that users are able to find the appropriate rights to request.

Typically, however, this is not the case in the actual systems, and therefore an onboarding process is needed to enhance the data before it's included in the self- service processes.

The Onboard application process handles this through the following activities:

• Definition of applications in Enterprise Server

  An application can consist of resources from several target systems. For example, a system that uses AD groups for access control, results in the application consisting of resources from both AD and the system itself.

• Maintenance of the application roles

  When this occurs, raw data from the systems is imported from ODW and enriched with adequate business descriptions and other relevant attributes that enable end-users to find the data during the Access request process.

• Verify data

  During this activity, an onboarding admin verifies the data, and if the data is good, they approve the new application’s data. Once these activities are completed, the data is transferred to the relevant data objects in Enterprise Server and becomes available to the Access request process.

Stakeholder(s) in the process

• IT Owner of the application.
• Business Owner of the application.
• Application onboarding admins

Pre-conditions

• Target systems must be adequately onboarded.
• Target system resources must be available in Enterprise Server or ODW.
• An IT Owner must be defined.
• Users must be added to the Application onboarding admins group
• The application must be configured correctly, and the Default Resource Type, Default Resource Folder, Account Role, Account Type properties must be present.
• Application onboarding configuration is performed (definition of what data can be read, modified, hidden by process step, etc.).

Post-conditions

• Application has been onboarded.
• Application roles have been created and are available for use in access request.

Data objects

• Systems
• Application
• Target system resources
• Application Roles

Process flow

1. The IT Owner of the application initiates the process and chooses the system that they are the owner of.
2. The IT Owner defines related physical systems.
3. Optionally, the IT Owner can also define additional owners.
4. The IT Owner selects access resources from Enterprise Server or ODW to be used in the application.
5. The Business Owner of the application models application roles.
6. Optionally, the Business Owner can define other Business Owners.
7. Members of the Application Onboarding Admins main user group must approve the modification to the application and related roles.

The following diagram shows the Onboard application process flow.

Frequency of process runs

• When necessary.

Exceptions

The Onboard application process fails if roles are defined, whereby child roles would violate an SoD constraint.

Best practices, considerations & recommendations

• It is recommended to recertify the definitions of roles regularly.

The following table includes key terms within the Onboard application process.

Term	Description
Logical system	An application or a logical system that can contain more than one physical system, making it possible to create application resources across systems that can be requested.
Physical system	A uniquely definable IT system such as a (specific) corporate AD.
Access resource	Resource objects. These represent actual permissions in the physical systems, for example, an AD group.
Application resource (app resource)	An application is a logical business resource (as viewed from the business-oriented user’s perspective). An application resource can contain one or more access resources as children.
Business owner	A System owner from a business-oriented perspective.
IT owner	A System owner from a technical perspective.

Managing passwords

Omada Identity has several features that serve to manage passwords.

For example, the Reset password process is a service that enables users to reset their passwords without having to contact the helpdesk. A user can also reset his/her password through an anonymous webpage, or through the Omada Identity portal.

Prerequisites

• Administrators have defined the required password policy.
• Administrators have defined the default challenge questions.
• Password reset has been enabled for the systems.

Overview

The following tables sum up the different processes involved by the password resets:

What?	When?	Where?	Pre-conditions
Initial password	New identities receive their initial password automatically when onboarded.	When onboarding a new identity.	Admins have defined a password policy.
Enroll to the password self-service reset	Identities want to reset their password by themselves, answering challenge questions.	Services > Password reset enrollment	User is onboarded and active. Admins have set up the default challenge questions in Questions in challenge view.
Unauthenticated password reset	Identities are logged out of their accounts and want to reset their password by themselves.	Anonymous webpage passwordreset.aspx	User has enrolled in the password reset.
Authenticated password reset – reset on behalf of another user	Admins want to reset passwords on behalf of other identities.	Services > Reset password User is onboarded and active.	Users belong to the admins' context.
Authenticated password reset – Change password	Users are logged in, and want to change their password.	Services > Reset password	User is onboarded and active, and remembers previous password.
Password filter	When changing a password in Windows AD or Azure AD, the password is synchronized to the user’s other accounts in systems managed by Omada Identity.	The password filter component uses the Password Filter technology in the Windows Domain controllers.	The Omada Password Filter component must be installed on all active domain controllers used by the system.

Initial password

The goal of the Initial password process is meant to send automatically to new joiners an email with the initial password necessary to sign in.

Pre-conditions

When onboarding a new system, the system's resource type must contain an attribute set with the Initial password property:

This creates by default the necessary event definitions and email templates.

Process flow

1. A manager or system owner onboards new identities (see Initial join for more information).
2. When the access requests for new joiners are provisioned, the event definitions are triggered, and the relevant emails with the initial passwords are sent to the new identities.

Best practices, considerations & recommendations

The EnableAccountCreationNotification customer setting allows you to turn off events and notifications.

Password reset enrollment

For the Password reset enrollment process and during an unauthenticated password reset request, the user must answer challenge questions to verify his or her identity, as well as provide authentication.

Each identity with an active user in Omada Identity can enroll to reset their password through the Services menu, in the Enroll password reset view.

Stakeholders

• Active identities.

Pre-conditions

Administrators have:

• Set the number of challenge questions to answer in the PWRNoEnrollQuest customer setting,
• Set the default Questions in challenge.

Process flow

1. In the menu, go to Services.

2. Open the Enroll to password reset view.

3. Provide answers to the default set of challenge questions (or click the dropdowns to select other ones:

   

4. Click Submit.

   Once your answers are registered, you can follow the Unauthenticated reset password process to reset your password by yourself.

Post-conditions

• The user gets a notification upon successful enrollment (if the PWREnrollSuccessNotif customer setting is active).

Unauthenticated password reset

The goal of this process is to allow an anonymous user to reset a password using a page that does not require authentication. Instead, the user resets their password while answering predefined security questions. It is primarily intended for users that have forgotten their passwords.

note

If the current password is known, the administrative password reset can be used.

The process entails the user accessing the Omada Identity password reset web page that does not require authentication. The user then resets his or her password while answering security questions and specifying a new password which is validated against password policies.

The Unauthenticated password reset process is not based on a regular Omada Identity process template, the process is defined within the web page. The web page can also be deployed to the internet via reverse proxy or firewall rules.

Pre-conditions

• User must enroll in password reset process.
• User must know answers to challenge questions.

Process flow

1. The anonymous user opens the webpage ./passwordreset.aspx and enters their user name in the Enter user name tab. The user name is matched to the identity ID in Omada Identity.

   

2. Click the Answer challenge questions tab, and answer the challenge questions:

   

3. Click the Enter a new password tab.

4. In the New password field, enter the new password, ensuring that it meets all the requirements.

5. To finish resetting the password, click Submit.

The process validates if the new password satisfies the relevant password policy. If so, OPS creates the provisioning request.

info

The password reset is processed asynchronously, which means that the user will not get an immediate response if the reset succeeded or not. Omada Identity informs the identity in case of error or success.

Post-conditions

• Password is reset.
• User can login again.

Best practices, considerations & recommendations

• In case challenge questions are wrongly answered too many times (this is configurable), the user is locked out.
• Advancement of password enrollment and authentication, for example, through a mobile app authentication.
• Only active identities can reset their passwords.

Authenticated password reset (on behalf of another user)

The Authenticated password reset process enables the reset of passwords for other managed identities. The process can be used to change a users’ own user password while still knowing the current password.

info

Only passwords that share the same password policy can be reset at a time.

The Authenticated password reset process can be executed by Administrators, Operation Administrators and Platform administrators, or relevant managers, to reset passwords on behalf of managed identities, in this case the existing password must not be known.

Pre-conditions

• The identity has its account(s) assigned.
• The system(s) are enabled for password reset.
• The password policies are defined and assigned to the relevant systems.
• The authorization role element Password reset access modifier is selected.

Data objects

• Password Policy
• Account Types
• System enabled for password reset

Process flow

In an authenticated password reset procedure, a manager or an operation administrator can select and reset the passwords of all of his/her owned and managed identities:

1. In the Reset Password view, in the Identity tab, in the Identity field, enter the relevant identity of the account whose password must be reset.

2. Click the Accounts tab.

   

3. In the Accounts tab, the user must select the relevant account grouped by password policy. You can do this by selecting the checkbox next to the name. Only accounts that share the same password policy can be reset at the same time.

   

4. Click the New password tab.

5. The manager or operation administrator must answer a new password on behalf of the identity, which must satisfy the password policy. The Current password must be filled in only if the manager (or operation administrator) wants to reset his/her own password.

   

info

The password reset is processed asynchronously, which means the user will not get an immediate response if the reset succeeded or not. Omada Identity informs the identity in case of error or success.

Post-conditions

• The user’s password has been reset/changed.
• The user can log in again.

Best practices, considerations & recommendations

• In the Reset Password view, a process initiator can select his/her own identity, all of the owned identities as well as all of his/her managed identities.
• A user must select the account grouped by password policy, only accounts that share the same password policy can be reset at the same time, and if the user wants to reset or change his / her own password, then the user must enter his/her existing password.

Authenticated password reset (Change own password)

The Change Password process is a self-service process that enables users to change the password for their personal account(s).

In contrast to the Reset password process, only a given user (identity) can change his or her own password. During the process the user is asked to provide both the current and the new password, and the reset only involves the password for the personal account(s).

Also, in contrast to the Unauthenticated password reset process, the Change Password process does not require the user to answer a challenge question as the user is already logged on.

Pre-conditions

• The Password change process has been added to the dashboard by the System Administrator.
• The identity has its personal account(s) assigned.
• The system(s) are enabled for password reset and has SSPR mappings configured.
• One of the four password validators (AD, Azure AD, Basic, or LDAP) must be enabled in the Master settings:

Password validator	Master setting
AD	PWRLDAPCLIENT
Azure AD	PWRAZUREADCLIENT
Basic	PWRBASICCLIENT
LDAP	PWRADCLIENT

For AD, Azure AD, and LDAP, you need to configure the relevant customer setting with the System ID which should validate the password:

Password validator	Customer setting
Azure AD	PWRAZURESYSTEMID
LDAP	PWRLDAPSYSTEMID
AD	PWRADSYSTEMID

• The default password policy should apply to each of the target systems.

Data objects

• Default Password Policy
• Account Types
• Systems enabled for password reset

Process flow

1. Go to your default dashboard and choose Change password from the Enroll to password reset service.

   

2. In the Change password view, enter the current password and the new password. Make sure that the new password conforms to the password policy set for the system.

   

3. Click Submit. The password is now changed.

Post-conditions

• The user’s password on personal accounts has been changed.
• The user can log in with the new password.

Exceptions

• In Omada Identity Cloud, normal users cannot validate their current password against onPrem Active Directory.
• You can disable the need to know the previous password by setting the PWREnforcePWValidation customer setting to False.

Password filter

The Omada Password Filter allows for the synchronization of a user’s passwords for their account in either Microsoft Active Directory or Azure Active Directory and their personal accounts in applications that are managed by Omada Identity.

This means the Omada Password Filter catches password change events on domain controller level and sends the password to Omada Identity which distributes that password to systems that are enabled for password reset.

It must be noted that administrative accounts, privileged accounts and other non- personal accounts are excluded from password synchronization.

Important

For the Omada Password Filter to work, in the General settings for a connected system, the password reset setting must be enabled, and any connected OPS connector must have the ability to set a new password.