Chatee ahora con Soporte
Chat con el soporte

Active Roles 8.2 - Feature Guide

Introduction About Active Roles
Main Active Roles features Technical overview of Active Roles
About presentation components Overview of service components About network data sources About security and administration elements About Active Directory security management Customization using ADSI Provider and script policies About dynamic groups About workflows Operation in multi-forest environments
Examples of use
Administrative rules and roles
About Managed Units About Access Templates About Access Rules About rule-based autoprovisioning and deprovisioning
Configuring and administering Active Roles Overview of Active Roles Synchronization Service Support for AWS Managed Microsoft AD FIPS compliance LSA protection support STIG compliance

SAML 2.0 authentication in Active Roles

Starting from version 8.2, Active Roles provides SAML 2.0 authentication support to the Web Interface by integration with a Redistributable Secure Token Server (RSTS). RSTS acts as both a WS-Federation provider for Active Roles and a SAML 2.0 consumer for your identity provider. As a broker between your IdP and Active Roles, you must prepare for a few design considerations when planning to use it.

For more information on configuring SAML 2.0 authentication for Active Roles, see Configuring SAML 2.0 authentication in the Active Roles Administration Guide.

Associated Active Directory

When a user authenticates via SAML 2.0 to Active Roles, they actually authenticate to the RSTS application. RSTS then attempts to validate that the user exists in an associated Active Directory. When a user authenticates to Active Roles, regardless of the authentication type, they may only authenticate with an account that exists in the Active Directory domain that the Active Roles Server is joined to, or any other trusted domains. However, when authenticating with SAML 2.0, the account must exist in the specific domain that is set as the Associated Active Directory. It will not authenticate users in additional trusted domains.

The Default Active Directory domain will always be the same domain that Active Roles is joined to. If you need to authenticate users whose AD accounts exist in other domains that have a trust relationship with the domain the Active Roles Server is joined to, you can add additional Active Directory providers and external federation providers associated with those Active Directory providers.

Claims Mapping

After a user successfully authenticates to the SAML 2.0 provider, RSTS will attempt to locate an account for that user in the associated Active Directory domain. When doing so, it will only check the first of the following claims:

  1. Email

  2. Name

  3. NameID or NameIdentifier

NOTE: One Identity recommends only using the required NameID claim to send the appropriate value. RSTS will search the Associated Active Directory for an account that has that value in the following 3 attributes:

  1. objectGUID

  2. userPrincipalName

  3. sAMAccountName

After a successful match, RSTS will send a WS-Federation response to Active Roles which contains the following claims generated from the Active Directory account.

Claim

Schema (Claim value)

AD attribute

NameIdentifier

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier

ObjectGUID

UPN

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn

Domain\SamAccountName

EmailAddress

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress

Mail

Name

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name

DisplayName

NOTE: When configuring the Claims Mapping in Active Roles, One Identity recommends always using GUID as the Claim Type and http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier as the Claim value.

Voluntary threshold for managed object count

By default, Active Roles does not limit the number of managed objects you can manage. However, as the license fee is based on the managed object count, you may need to verify that the object count stays under a certain threshold. To do so, you must specify a threshold value for the number of managed objects.

Once you configure this voluntary threshold, the scheduled task that counts the managed objects will raise an alert whenever it detects that the current number of managed objects exceeds the configured threshold value. Active Roles will indicate this alert in the Product Usage Statistics page of the Active Roles Console, and can also send a notification over email.

Getting started

For more information on how to configure the threshold, see Voluntary thresholds for the managed object count in the Active Roles Administration Guide.

About the installation label

To identify your Active Roles installation in the Managed Object Statistics report, you can set a label for your deployment in the Active Roles Console.

This is useful, for example, if you have several Active Roles deployments installed in your organization (for example, separate pilot, non-production and production environments) and you want to easily distinguish them visually.

Once configured, the installation label appears in the title of the Managed Object Statistics report.

Getting started

For more information on how to configure an installation label for Active Roles, see Installation label in the Active Roles Administration Guide.

About safe mode

Active Roles provides a troubleshooting mode called "Safe mode" that starts Administration Service in a limited state.

When you enable Safe mode, Administration Service:

  • Disregards all custom policies, workflows, scripts, scheduled tasks and other custom-made assets that may prevent Active Roles from starting and operating normally.

  • Rejects connections from any users that do not have Active Roles Admin privileges.

While Safe mode is active, only Active Roles Admins can connect to Administration Service, so that they can troubleshoot problems by changing the existing Active Roles configuration or removing any customizations that could cause issues. Once troubleshooting is finished, Active Roles Admins can also turn off Safe mode and resume normal Active Roles operation.

Getting started

You can enable Safe mode from the Active Roles Management Shell.

To enable or disable Safe mode

  1. On the computer running the Active Roles Administration Service, log in with a user account that has administrator rights on the computer.

    NOTE: You can enable or disable Safe mode only with a user account that has local administrator rights on the computer running Administration Service.

  2. Start the Active Roles Management Shell from the Windows Start menu or the Apps page of the operating system.

  3. To enable safe mode, enter the following commands in the Management Shell command-line interface:

    Set-ARService -SafeModeEnabled $true

    Restart-ARService

  4. To enable safe mode, enter the following commands in the Management Shell command-line interface:

    Set-ARService -SafeModeEnabled $false

    Restart-ARService

Documentos relacionados

The document was helpful.

Seleccionar calificación

I easily found the information I needed.

Seleccionar calificación