Configuring AD FS as a Third-Party IdP in VMware Identity Manager: VMware Workspace ONE Operational Tutorial



VMware provides this operational tutorial to help you with your VMware Workspace ONE® environment. Workspace ONE simplifies access to cloud, mobile, and enterprise applications from supported devices. As an IT professional, you can use Workspace ONE to deploy, manage, and secure applications. At the same time, you can offer a flexible, bring-your-own-device (BYOD) initiative to your end users from a central location.


This operational tutorial provides you with discussions and  exercises to help with your existing VMware Workspace ONE® production environment. VMware provides operational tutorials to help you with

  • Common procedures or best practices
  • Complex manual procedures
  • Troubleshooting

Note: Before you begin any operational tutorial, you must first deploy a production environment. For information about deployment, see the VMware Workspace ONE Documentation.


This operational tutorial is intended for IT professionals and Workspace ONE administrators of existing production environments. Both current and new administrators can benefit from using this tutorial. Familiarity with networking and storage in a virtual environment is assumed, including Active Directory, identity management, and directory services. Knowledge of additional technologies such as VMware Identity Manager™ and VMware Workspace ONE® UEM (unified endpoint management), powered by VMware AirWatch, is also helpful.

Configuring AD FS as a Third-Party IdP in VMware Identity Manager


Active Directory Federation Services (AD FS) is a Windows Server component that provides single sign-on access to applications and systems for users using claims-based authentication. You can configure VMware Identity Manager to use Active Directory Federation Service (AD FS) as the third-party identity provider (IdP) for authentication. This tutorial reviews how to install and configure AD FS and how to add AD FS as a third-party IdP in VMware Identity Manager.

The procedures are sequential and build upon one another, so make sure that you complete each procedure in this section before going to the next procedure.


Before you can perform the procedures in this tutorial, you must satisfy the following requirements. For more information, see the VMware Identity Manager Documentation and VMware Workspace ONE UEM Documentation.

Check whether you have the following components installed and configured:

  • Workspace ONE UEM tenant 9.3 or later with admin credentials
  • On-premises VMware Identity Manager tenant
  • VMware Identity Manager login details—to retrieve your details from the Workspace ONE UEM Console; navigate to Content > Content Locker > List View and download the vIDM Tenant Details text file
  • Windows machine to install the VMware Enterprise Systems Connector.
  • Use the VMware Enterprise Systems Connector to sync a domain and at least a single domain user to login with.
  • Microsoft Active Directory Federated Services

You must also complete the following exercises, which are located in Deploying On-Premises VMware Identity Manager: VMware Workspace ONE Operational Tutorial.

  • Downloading the VMware Identity Manager Connector
  • Installing and Configuring the VMware Identity Manager Connector Service
  • Configuring your VMware Identity Manager Tenant for AD Users
  • Creating and Configuring the VMware Identity Manager Connector
  • Syncing Directory Users to VMware Identity Manager

Active Directory Federation Services (AD FS) Overview

AD FS uses claims-based authorization to implement identity federation. By default, VMware Identity Manager uses Security Assertion Markup Language (SAML), which is an assertion-based form of authorization. Conceptually, there are many parallels between SAML and AD FS. Use these similarities, outlined in the previous table, as a foundation for understanding VMware Identity Manager and AD FS integration.

1. AD FS Claims

A claim is a statement about a user that includes values about the user (for example, user principal name (UPN), email address, role, group, windows account name, and so on) which are contained in a trusted token. Trusted parties, known as relying parties, use the values stored in the claim to determine how to authorize the request.

Claims providers, such as your Active Directory, source and sign these claims. The Federation Service brokers trust between claims providers and relying parties by processing and exchanging claims between these parties to allow for authorization decisions to be made based on the statements of the claim.

  1. The client requests a trusted token for access to a relying party, such as a web-hosted application.
  2. The client authenticates against AD FS, validated by the trusted attribute store.
  3. A trusted token is returned to the client upon successfully authenticating, which presents the trusted token to the relying party.
  4. The relying party validates that the trusted token and allows access.

Installing and Configuring AD FS (Video Walk-through)

For this exercise, you need AD FS installed and configured to authenticate domain users. Because the focus of this exercise is to integrate VMware Identity Manager with an existing AD FS deployment, you will not be installing the AD FS instance from scratch.

Optional: To watch a video demonstrating this procedure, click Active Directory Federation Services integration with VMware Identity Manager, or click the video itself.

Otherwise, continue to the next step.

Downloading the AD FS Federation Metadata XML

To establish trust between VMware Identity Manager and your AD FS instance, you must download the AD FS federation metadata.  

1. Download the Federation Metadata XML

Launch Chrome Browser

Launch a Chrome browser on your desktop.

1.1. Navigate to the Federation Metadata XML Endpoint

Navigate to https://<adfs_server_name>/FederationMetadata/2007-06/FederationMetadata.xml. Replace adfs_server_name with your AD FS server, for example, adfs.corp.local.

The FederationMetadata.xml downloads and will be stored in your Downloads folder.  You will use this file when configuring VMware Identity Manager in a later exercise.

2. Finding the Federation Metadata Endpoint

To review the steps to retrieve the Federation Metadata endpoint, you must first log in to your AD FS server.

2.1. Open AD FS Management

On your AD FS server:

  1. Click the Server Manager icon from the taskbar.
  2. Click Tools.
  3. Click AD FS Management.

2.2. Locate FederationMetadata.xml Endpoint

  1. Expand Service under AD FS.
  2. Click Endpoints.
  3. Scroll down to find the Metadata section.
  4. Locate the Metadata object with the type Federation Metadata. Note the URL Path.

The link you used to download the Federation Metadata XML was your ADFS hostname (for example,https://adfs.corp.local) followed by your Federation Metadata endpoint as shown in the screenshot (/FederationMetadata/2007-06/FederationMetadata.xml). This is how the Federation Metadata endpoint was found.

Logging In to the Workspace ONE UEM Console

To perform most of the steps in this exercise, you must first log in to the Workspace ONE UEM Console.

1. Launch Chrome Browser

Launch Chrome Browser

On your desktop, double-click the Google Chrome icon.

3. Authenticate In to the Workspace ONE UEM Console

  1. Enter your Username, for example, administrator.
  2. Click Next. After you click Next, the Password text box is displayed.
  1. Enter your Password, for example, VMware1!
  2. Click Login.

Note: If you see a Captcha, be aware that it is case sensitive.

Logging In to the VMware Identity Manager Console

To perform most of the steps in this exercise, you must first log in to the VMware Identity Manager console.

1. Launch Google Chrome (If Needed)

If Google Chrome is not already open, launch Google Chrome by double-clicking the icon from the desktop.

2. Open a New Browser Tab

Click the Tab space to open a new tab.

4. Login to Your VMware Identity Manager Tenant

  1. Enter the Username, for example, Administrator.
  2. Enter the Password, for example, VMware1!.
  3. Click Sign In.

Creating a Third-Party Identity Provider

In order for AD FS to authenticate our users, you must create a third-party identity provider (IdP) within VMware Identity Manager and use the FederationMetadata.xml downloaded from your Federation Service to establish trust between between AD FS as the identity provider and VMware Identity Manager as the service provider.  

1. Copy the ADFS Federation Metadata XML

  1. Click the File Explorer icon from the taskbar.
  2. Click Documents.
  3. Right-click the FederationMetadata.xml.
  4. Select Edit with Notepad++.

1.1. Copy the Federation Metadata Contents

  1. Right-click and click Select All.
  2. Right-click and click Copy.

2. Create Third-Party Identity Provider in VMware Identity Manager

Navigate to your VMware Identity Manager Administration Console in Chrome.

  1. Click Identity & Access Management.
  2. Click Identity Providers.
  3. Click Add Identity Provider.
  4. Click Create Third Party IDP.

2.1. Enter Identity Provider Name and SAML Metadata

Open the FederationMetadata.xml file you downloaded earlier and copy the full XML text contained within the document.

  1. Enter AD FS for the Identity Provider Name. This is a display name that will be used for this third-party identity provider.
  2. Paste the XML text contained in your FederationMetadata.xml file into the SAML Metadata field.
  3. Click Process IdP Metadata.  This configures certain settings in your identity provider based on the specifications that are noted within the Federation Metadata.

2.2. Confirm Processed IdP Metadata

After selecting to Process the IdP Metadata, notice that the SAML AuthN Request Binding and the Name ID format mappings have been automatically configured. These values were taken from the FederationMetadata.xml, which informs VMware Identity Manager how to send requests to our third-party identity provider to process authentication requests.

2.3. Configure Users and Networks for the Identity Provider

  1. Scroll down until you see the section for Just-in-Time user Provisioning.
  2. Deselect the check box for Just-in-Time User Provisioning.  
    Just-in-Time user provisioning allows users to be created within VMware Identity Manager dynamically when they authenticate using this third-party identity provider, if they do not already exist. This can be useful for dynamically adding any missed users or new users who have not been synced but still belong to your domain(s) that will be using this third-party identity provider.
  3. Select your domain users, for example, corp.local.  
    This determines which users will be allowed to use this third-party identity provider when authenticating.
  4. Select ALL RANGES for the Network.

2.4. Configure Authentication Methods for this Identity Provider

We need to specify which authentication methods this third-party identity provider will use to authenticate our selected users.

  1. Scroll down until you see the section for Authentication Methods.
  2. Enter SAML Password for the Authentication Method.
  3. Select urn:oasis:names:tc:SAML:2.0:ac:classes:Password for the SAML Content.
  4. Click the Add (+) button to add another Authentication Method.
  5. Enter SAML Kerberos for the Authentication Method.
  6. Select urn:oasis:names:tc:SAML:2.0:ac:classes:Kerberos for the SAML Content.
  7. Click the Add (+) button to add another Authentication Method.
  8. Enter Windows Authentication for the Authentication Method.
  9. Select urn:federation:authentication:windows for the SAML Content.

The Authentication Methods column acts as a display name for the SAML Context.  When creating Access Policies, the Authentication Methods column name will display as options for which authentication methods to use to authenticate our users.  Note that these names must be unique across your VMware Identity Manager tenant, and cannot share names with the default Authentication Methods.

The SAML Context informs the Identity Provider (AD FS in this instance) how the user should be authenticated. The SAML Context will be inserted as part of the SAML Assertion (under the AuthnStatement section). This SAML Assertion will be signed and sent to AD FS as a request to authenticate users when they attempt to login to VMware Identity Manager using this third-party identity provider.

For reference, here is a sample of a SAML Assertion that will be signed and sent to AD FS when users attempt to authenticate. Notice the AuthnStatement section, which details when the authentication request was made and contains how the user is attempting to authenticate (using Kerberos, in this example).

2.5. Configure Single Sign-Out and access Service Provider Metadata

  1. Scroll down to find the additional configuration options.
  2. Enable the Single Sign-Out Configuration, which will also sign users out of their identity provider session when they sign out from Workspace ONE.  You can optionally provide a Sign-Out URL, which will re-direct users to the provided URL upon logging out, and a Redirect Parameter, which will send URL parameters to the Sign-out URL which can be used by the identity provider to perform certain actions based on the provided parameters. In this example, we want our users to be re-directed to our Identity Provider (AD FS) using SAML single logout with no additional parameters so these will remain blank.
  3. Right-click the Service Provider (SP) Metadata link.
  4. Click Copy link address.
    You will be providing the Service Provider Metadata URL to ADFS in an upcoming step to establish trust between the two parties as an Identity Provider and Service Provider.

2.6. Add the Third Party Identity Provider

Click Add to save the configuration of your third-party identity provider for AD FS.

Configuring Access Policies in VMware Identity Manager

This section helps you configure access policies with specific authentication methods in VMware Identity Manager. These authentication methods are used to authenticate domain users with your third-party identity provider instead of using the default access policy rules.

1. Edit the Access Policy

  1. Click Identity & Access Management.
  2. Click Policies.
  3. Click Edit Default Policy.
  4. Click the default_access_policy_set to edit it.

2. Create A New Policy Rule for Domain Users

  1. Click the Configuration tab.
  2. Click Add Policy Rule.

2.1. Configure the Policy Rule

This policy rule will allow domain users to login using the AD FS authentication methods set up earlier as part of your third-party identity provider configuration.

  1. Select ALL RANGES for the network range.
  2. Select All Device Types for the content origin.
  3. Enter Domain Users into the user groups search box.
  4. Click the domain users group, for example, Domain Users@corp.local.

2.2. Configure the Authentication Methods for the Policy Rule

  1. Scroll down to find the additional configuration options.
  2. Select Authenticate using... as the action.
  3. Set the first authentication method as SAML Kerberos.
  4. Set the fallback authentication method as Windows Authentication.
  5. Click Add fallback method.
  6. Set the second fallback authentication method as SAML Password.
  7. Click Save.

This Policy Rule first attempts to authenticate users through Kerberos with AD FS. Should that fail or be inapplicable, Windows Authentication is attempted. Lastly, if all other methods have failed or been inapplicable, Password authentication is attempted.

2.3. Re-Order the Policy Rules

The policy rule that handles AD FS authentication for domain users must be processed first, otherwise the All Users policy that you configured for Password (Local Directory) will attempt to apply for your domain users instead of your intended policy.

  1. Click and drag the handle for the policy rule you created for AD FS to the top of the list.
    Note: This is the rule with the Authentication column listed as SAML Kerberos+2.
  2. Click Next.

3. Save the Updated Policy Rules

Click Save.

Configuring Relying Party Trust in AD FS

After you have configured your third-party identity provider in VMware Identity Manager and retrieved your service provider metadata, the next step is to configure a relying party trust in AD FS for VMware Identity Manager. This configuration uses your service provider metadata to establish trust between AD FS as the identity provider and VMware Identity Manager as the service provider. 

For this exercise, you must log in to your AD FS server.

1. Add Relying Party Trust

Return to AD FS Management.  If closed, you can either navigate to Server Manager and select Tools > AD FS Management or search for AD FS Management from the Start menu.

  1. Expand Trust Relationships.
  2. Click Relying Party Trusts.
  3. Click Add Relying Party Trust.

This opens the Add Relying Party Trust Wizard. Click Start to begin this process after the wizard displays.

1.1. Start Add Relying Party Trust Wizard

Click Start.

1.2. Select Data Source

Provide the Service Provided Metadata URL that you previously copied when creating your third-party identity provider in VMware Identity Manager to establish trust between ADFS and VMware Identity Manager.  

  1. Select Import data about the relying party published online or on a local network.
  2. Right-click in the Federation Metadata address text box and click Paste.
  3. Confirm your Federation Metadata URL that you copied is pasted and matches the shown format of https://{yourtenant}
    NOTE: Replace {yourtenant} with the name of your actual tenant.
  4. Click Next.

Note: After clicking Next, it may take a few seconds to query the Federation Metadata XML. Be patient while this loads.

1.3. Specify Display Name

You have the option to change your display name or add any notes about the relying party here. For this exercise, click Next.

1.4. Configure Multi-Factor Authentication

Multi-factor Authentication (MFA) requires a user to complete two or more authentication challenges from multiple categories: Knowledge (something they know, like a password), possession (something they have, like a FOB or device), and inherence (something they are, such as biometrics).  

Multi-factor Authentication configuration is out of scope for this exercise, so click Next to continue without configuring it.

1.5. Choose Issuance Authorization Rules

Issuance Authorization Rules specify if a user is permitted to receive claims, or authentication requests, for this relying party.  You can either permit all users or deny all users from accessing this relying party.

  1. Select Permit all users to access this relying party.  In our case, we want our domain users to use this relying party to authenticate.
  2. Click Next.

1.6. Review and Continue with Relying Party Trust Wizard

Review information about the relying party before clicking Next.  Notice that certificates were also included with the Service Provider Metadata, which will be used to encrypt the SAML assertions from VMware Identity Manager.

1.7. Finish Relying Party Trust Wizard

  1. Keep the Open the Edit Claim Rules dialog for this relying party trust when the wizard closes option enabled.
  2. Click Close.

2. Add Claim Rules for Relying Party

To properly authenticate your users, you must add Claim Rules for your relying party. Claim Rules control the flow of claims and are responsible for taking one or more incoming claims, applying conditions to these claims, and then producing one or more outgoing claims. Claim Rules and the Claims Engine are responsible for determining if incoming claims should be passed through as they are received, filtered to meet specific business logic criteria, or transformed into a new set of claims before they are issued as an outgoing claim.  

In short, think of Claim Rules as the logic that inspects, processes, and transforms incoming claims to outgoing claims which determine who and how users are authenticated.  For more detailed documentation, check out the Role of Claim Rules.

In this exercise, you must create two types of Claim Rules.  

  1. Send LDAP Attributes as Claims:  The outgoing claim contains LDAP attribute values from your attribute store (Active Directory, in this case) that can be used for authentication.
  2. Send Claims using a Custom Rule:  Uses the claim rule language to generate and transform your claim to handle specific business logic requirements needed to authenticate the user in VMware Identity Manager.

2.1. Add Issuance Transform Rules for LDAP Attributes

Claim Rules are processed in chronological order by the claims engine, so the order of our rules is important.  For example, the output of one rule can be used as the input of the next rule, so depending on your business logic, you may need to carefully craft how your claims will be passed through, processed, or transformed.

2.1.1. Add Issuance Transform Rule

From the Edit Claim Rules dialog:

  1. Ensure the Issuance Transform Rules tab is selected.
  2. Click Add Rule.

2.1.2. Choose Rule Type

  1. Select Send LDAP Attributes as Claims for the Claim Rule Template.
  2. Click Next.

2.1.3. Configure Claim Rule

  1. Enter Get Attribute Email Address for the Claim Rule Name.
  2. Select Active Directory as the Attribute Store.
  3. Select E-Mail-Addresses from the LDAP Attribute drop-down menu.
  4. Select E-Mail Address from the Outgoing Claim Type drop-down menu.
  5. Click Finish.

For this claim rule, you have mapped the E-Mail-Addresses LDAP attribute as E-Mail Address to your outgoing claim type and have issued the claim.

2.2. Add Issuance Transform Rules for Custom Claims Rule

The Get Attribute Email Address Claims Rule is now created.  Next, create a Custom Claims Rule.

Click Add Rule to get started.

2.2.1. Choose Rule Type

  1. Select Send Claims Using a Custom Rule as the Claim Rule Template.
  2. Click Next.

2.2.2. Configure Claim Rule

  1. Enter Transform Email Address as the Claim Rule Name.
  2. Enter the following text for the Custom rule.  
    Note: Replace the {YOUR_TENANT_NAME} text at the end for the spnamequalifier with your VMware Identity Manage tenant. This rule transforms the outgoing Email Address claim and issues both the email.
    c:[Type == ""] => issue(Type = "", Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType, Properties[""] = "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress", Properties[""] = "{YOUR_TENANT_NAME}");
  3. Click Finish.

2.3. Apply Claim Rules

  1. Click Apply.
  2. Click OK to close the Edit Claim Rules dialog box.

Logging In as a Domain User

To confirm that the previous configurations are working, log in to Workspace ONE on a Windows machine using a domain user.

1. Authenticate as a Domain User in the Browser

  1. Open Google Chrome.
  2. Navigate to your VMware Identity Manager tenant URL (https://{yourtenant}
    Note: Replace {yourtenant} with the name of your tenant.
  3. Enter a username which is one of the domain users you synced.
  4. Deselect Remember this setting.
  5. Click Next.

Note: The authentication may take several seconds to process, be patient after clicking Next.

1.1. Confirm Authentication was Successful

Notice that the user was logged into the VMware Identity Manager tenant without having to enter their credentials. Upon logging in as a domain user, the third-party identity provider attempted to authenticate the user using Kerberos first. After the Claim is processed in AD FS, the claim is transformed using the Claim Rules created earlier and responds in a manner that VMware Identity Manager is able to process, as a result, authorizing the user to login using SAML.

  1. Click the user drop-down menu.
  2. Click Sign Out.

Note: Signing out may take several seconds to process from AD FS. Wait until you are taken back to the VMware Identity Manager login page.

This clears the login cookie for the user you logged in as.  The next exercise demonstrates using the VMware Workspace ONE App to login, so the cookie needs to be cleared first.

2. Authenticate as a Domain User in the VMware Workspace ONE App

  1. Launch the VMware Workspace ONE app.
  2. Enter your VMware Identity Manager tenant URL.
  3. Click Continue.

2.1. Log In as a Domain User

  1. Enter a domain user, for example, holuser
  2. Click Next.

2.2. Confirm Authentication was Successful

As seen in your browser session, the claim is transformed and the outgoing claim authorizes the user to access Workspace ONE using SAML without having to enter their credentials.

After successfully authenticating, you should see a message indicating that your workspace is being configured, and eventually that the workspace is ready. Click Enter.

3. Clear Authorization Cookies (If Needed)

The authorization cookies last 8 hours after you authenticate to VMware Identity Manager. If you need to re-authenticate again to test, you can either shorten the re-authentication timers of the Access Policy rules you configured, or you can clear your authorization cookies so that the browser and VMware Workspace ONE app sessions are removed which forces the user to authenticate again.

  1. Open Google Chrome and click the Options icon.
  2. Click Settings.

3.2. Clear Cookies

  1. Select the beginning of time for the period.
  2. Ensure Cookies and other site data is selected.
  3. Click Clear Browsing Data.

3.3. Confirm or Inspect Cookies

To check if any cookies exist or to see which cookies are being stored for your VMware Identity Manager session, navigate back to Google Chrome:

  1. Right-click anywhere to pull up the options menu.
  2. Click Inspect. Alternatively, you can use Ctrl + Shift + i to view the console.
  3. Select the Application tab.
  4. Find the Cookies section under Storage. If there are no cookies listed, then you currently have no authorization cookies for your VMware Identity Manager tenant. If they do exist, you can see them after you select your tenant URL under Cookies.
  5. You can also use the Delete button to remove all cookies for this page.


This section reviews some issues you may experience while attempting to integrate a third-party identity provider with VMware Identity Manager and what troubleshooting steps you can take.

1. Cannot Log In to the VMware Identity Manager Tenant


When the Access Policies are configured incorrectly, authentication may fail for some or all users.  This can cause even your local accounts to be unable to log in to the tenant to resolve the issue.


To log in to the tenant and bypass the configured Access Policies causing the authentication issue, append ?login to your default login URL:


2. VMware Identity Manager: Cannot Update Identity Provider


While adding or editing an identity provider and attempting to add or update an authentication method, you see the error “Cannot update Identity Provider”.  This prevents you from adding or editing authentication methods when you click save.


The SAML context name must be unique in your VMware Identity Manager tenant, including names used by the default authentication methods.  Rename your SAML context name for the chosen authentication method and click save.

3. VMware Identity Manager: Federation Artifact not found


When attempting to login to VMware Identity Manager, you see the error 404.idp.not.found, federationArtifact.not.found Federation Artifact not found, or another error that indicates that an identity provider or federation artifact could not be found to authenticate the users . This occurs when no access policies are set up to handle authenticating the network range, device type, user group, or attempted authentication methods or if the claim rules for the relying party are misconfigured.


  • In the access policy rules, create an access policy that includes the network range, device type, user group and authentication method you are attempting to log in with. Ensure these authentication methods are enabled and active for your identity providers and that they are applying to the network range and user group you are expecting.
  • Ensure your relying party trust claim rules were properly configured based on the examples provided. The claim values are case sensitive. Also, ensure you properly replaced your spnamequalifier in the custom claims rule with your VMware Identity Manager tenant.

4. AD FS Error: Contact your Administrator


When users attempt to authenticate using claims-based authentication to AD FS, they see a login page that displays Error: Contact your administrator. This occurs because AD FS cannot properly authenticate the claim.


  • Ensure you properly established trust between AD FS as the identity provider and VMware Identity Manager as the service provider. Re-export the FederationMetadata.xml files or URLs and ensure you uploaded the correct metadata for each component.
  • Ensure your relying party trust claim rules were properly configured based on the examples provided. The claim values are case sensitive, and ensure you properly replaced your spnamequalifier in the custom claims rule with your VMware Identity Manager tenant.
  • Ensure your authentication methods configured for the access policies applied to your domain users are correctly using the authentication methods setup for the AD FS identity provider.
  • Ensure you are not attempting to authenticate local users from VMware Identity Manager that do not exist within your Active Directory. Local users should be authenticated using the Password (Local Directory) authentication method, not authentication methods configured for AD FS because AD FS will fail to find these local user accounts in AD.

5. AD FS: Failed Authentication Requests and Viewing Logs


When users attempt to authenticate using claims-based authentication to AD FS from VMware Identity Manager, they are being redirected to AD FS for their credentials appropriately but then receive an error that they could not be authenticated. AD FS may be configured incorrectly, causing issues with consuming incoming claims, generating outgoing claims, or other issues that would cause authentication to fail.


  • After installing and configuring AD FS, Server Manager will contain an AD FS Dashboard from the left menu. From here, an Events view is available which can be configured to log events of different severities (Informational, Warning, Error, or Critical) within a certain time period. This view can be configured by clicking Tasks > Configure Event Data, which is next to the Events view from this AD FS Dashboard.
  • Alternatively, you can use Event Viewer to view the AD FS logs. From Event Viewer, find the logs by navigating to Applications and Services Logs > AD FS Tracing > Debug. To begin receiving logs, right-click the Debug file and select Enable Log.  If you want to stop tracking events this way, you can right-click the Debug file and select Disable Log to return it to the original state.

Both solutions allow you to see traces of your authentication attempts. Failures and issues are typically noted with the severity levels of Error or Critical, so try inspecting your logs to see what is causing your authentication to fail. Typical authenticate issues could be:

  • The third-party identity provider configuration in VMware Identity Manager is not sending a name ID format that the identity provider (AD FS) is expecting to query a user from the attribute store with.
  • The third-party identity provider and/or access policies in VMware Identity Manager are using authentication methods that the identity provider (AD FS) is not handling or cannot handle due to the authentication methods allowed for intranet versus extranet. These intranet versus extranet authentication methods can be viewed in AD FS by navigating to AD FS Management > AD FS > Authentication Policies > Primary Authentication. By default, extranet authentication uses forms authentication whereas intranet uses Windows authentication. Therefore, if you are attempting to authenticate users in your Intranet by using forms authentication, this will fail until you update the Primary Authentication settings to also allow forms authentication for intranet requests.
  • The relying party trust was misconfigured in AD FS. If you imported the service provider metadata from VMware Identity Manager, this should not be an issue.
  • The relying party claim rules were misconfigured. The exact configuration issues depend on what claim rule templates you used, but double-check that you have access to the attributes you are expecting in the claim as well as your attribute store. If you are using custom claim rules, double-check that your claim engine logic is correct and without syntax issues and that it is returning an outgoing claim that your service provider is expecting. Service providers will require different configurations, so it is best to find documentation for that service (for example, VMware Identity Manager, Okta, Ping) and see what they are expecting in their claims from AD FS to properly authenticate users.

Summary and Additional Resources


This operational tutorial provided steps to add AD FS as a third-party IdP in VMware Identity Manager, configure access policies in VMware Identity Manager, and configure a relying party trust in AD FS. It also reviewed how to install and configure AD FS.

Terminology Used in This Tutorial

The following terms are used in this tutorial:

application store A user interface (UI) framework that provides access to a self-service catalog, public examples of which include the Apple App Store, the Google Play Store, and the Microsoft Store.
auto-enrollment Auto-enrollment simplifies the enrollment process by automatically enrolling registered devices following the Out-of-Box-Experience.
catalog A user interface (UI) that displays a personalized set of virtual desktops and applications to users and administrators. These resources are available to be launched upon selection.
cloud Asset of securely accessed, network-based services and applications. A cloud can also host data storage. Clouds can be private or public, as well as hybrid, which is both private and public.
device enrollment The process of installing the mobile device management agent on an authorized device. This allows access to VMware products with application stores, such as VMware Identity Manager.
identity provider (IdP) A mechanism used in a single-sign-on (SSO) framework to automatically give a user access to a resource based on their authentication to a different resource.
mobile device management
(MDM) agent
Software installed on an authorized device to monitor, manage, and secure end-user access to enterprise resources.
one-touch login A mechanism that provides single sign-on (SSO) from an authorized device to enterprise resources.
service provider (SP) A host that offers resources, tools, and applications to users and devices.
virtual desktop The user interface of a virtual machine that is made available to an end user.
virtual machine A software-based computer, running an operating system or application environment, that is located in the data center and backed by the resources of a physical computer.

For more information, see the VMware Glossary.

Additional Resources

About the Authors

This tutorial was written by:

  • Camilo Lotero, Senior Technical Marketing Manager, End-User-Computing Technical Marketing, VMware
  • Shardul Navare, Senior Technical Marketing Architect, End-User-Computing Technical Marketing, VMware
  • Justin Sheets, Senior Technical Marketing Manager, End-User-Computing Technical Marketing, VMware


The purpose of this tutorial is to assist you. Your feedback is valuable. To comment on this tutorial, contact VMware End-User-Computing Technical Marketing at