11.2 Configuring Active and Passive Authentication By Using WS-Trust and WS-Federation Protocols

Using the wizard, when you configure an Office 365 domain with WS-Trust protocol it creates the following two domains:

  • A domain preconfigured for active authentication using WS-Trust protocol

  • A domain preconfigured for passive authentication using WS-Federation protocol.

If your business needs demand using a domain based on SAML 2.0 protocol, you can configure a domain manually using the steps in Section 11.3, Configuring an Office 365 Domain That Supports Passive Federation Using SAML 2.0 Protocol

The following sections cover the details about how to configure a domain by using WS-Trust and WS-Federation protocols:

11.2.1 Prerequisite

Use the following steps to verify that WS-Trust and WS-Federation protocols are enabled in Access Manager:

  1. In the Administration Console, click Devices > Identity Servers > Edit.

  2. In the Enabled Protocols section, ensure that WS-Trust and WS-Federation protocols are selected.

11.2.2 Configuring an Office 365 Domain By Using WS-Trust Protocol

When you configure a new Office 365 domain by using the WS-Trust protocol, it creates a domain preconfigured for Active authentication and also creates a WS-Federation Service Provider that is preconfigured for Passive authentication.

  1. In the Administration Console, click Devices > Identity Servers > Edit > WS-Trust > Service Provider Domain.

  2. Click New > Office 365 Domain and specify a name to identify the domain. This domain is by default configured with ImmutableID and Attribute Set information and a Service Provider with the same name as the Office 365 domain is automatically created.

    An authentication method Name/Password - Form-WebService is created and this is selected for WS-Trust. This method ensures that an email address/password is accepted for authentication.

    Click the domain name to make further modifications.

    For more details, see link Section 9.5.5, Modifying Service Providers

  3. Click the WS-Federation tab and verify that a new Service Provider with the same name as the Office 365 domain is created. This Service Provider is preconfigured with Attribute Set information and Authentication Response for the Passive authentication.

11.2.3 Configuring an Office 365 Domain to Federate with Access Manager

Prerequisite

Ensure that the following requirements are met before configuring an Office 365 domain:

  • The Identity Server must be installed outside the firewall for it to access Office 365 domain.

  • Sign up for an Office 365 account. For information about signing up, see Sign in to Office 365.

  • To single-sign on to any of the Office 365 applications, ensure that you download it from the Office 365 portal.

  • Create a federated domain in Office 365 and prove ownership of it. This ensures that you add your company domain into the Office 365 domain. For more information, see Adding and Verifying a Domain for Office 365.

  • Ensure that the Windows 7 or Windows 8 workstations do not have the Active Directory Federation Service 2.0 snap-in installed.

  • Ensure that the SSL certificate is issued by a well-known external certification authority (CA).

  • If you are using Microsoft Lync and/or Microsoft Outlook thick clients with WS-Trust, replace the default self-signed SSL server certificate included with Access Manager with one that is signed by a public Certificate Authority (CA). This enables Office 365 to establish a trusted SSL session with Access Manager. For more information see, Managing Trusted Roots and Trust Stores.

    NOTE:If you are using Microsoft Lync, ensure that you enable federation. For more information, see Lync External Access.

  • Install Microsoft Live Sign-in Module to help manage and establish a remote session with the Office 365 account that is created to manage the Office 365 domain. To download, go to Microsoft Downloads Center.

  • Install Microsoft Azure Active Directory Module. To download, go to Manage Azure AD using Windows PowerShell.

Enabling Federation Settings in Office 365 Domain

Run the following commands in Powershell by modifying the commands with your domain name as per your setup. The domain name in the example is namtest.com.

  1. From the Start Menu launch Windows Azure Active Directory Module for Windows PowerShell.

  2. Run $cred=Get-Credential. Enter your cloud service administrator account credentials.

  3. Run Connect-MsolService –Credential $cred

    For example, if the name of the domain is namtest.com and the Base URL of the Identity Server is https://namtest.com/nidp/, execute the following commands at the Powershell prompt:

    NOTE:In this example, the Base URL the port is not specified as it uses the default port 443. If you are using a different port, specify the port with the Base URL.

    For example: https://namtest.com/nidp/

    1. $dom = "namtest.com"

    2. $url = "https://namtest.com/nidp/wsfed/ep"

    3. $ecpUrl = "https://namtest.com/nidp/wstrust/sts/active12"

    4. $uri = "https://namtest.com/nidp/wsfed/"

    5. $logouturl = "https://namtest.com/nidp/jsp/o365wsfedlogout.jsp"

    6. $mex = "https://namtest.com/nidp/wstrust/sts/mex"

    7. $cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("name and path of the certificate")

      NOTE:

      • If the certificate used has a .crt extension ensure that you convert it to a .cer extension file.

      • While executing this command, ensure that you specify the path to the certificate within the double quotes. For example: “C:\local\netiq-off365-sign.cer”

    8. $certData = [system.convert]::tobase64string($cert.rawdata)

  4. Use the following cmdlet to update the settings of the single sign-on domain.

    Set-MsolDomainAuthentication -FederationBrandName $dom -Authentication Federated -PassiveLogOnUri $url -SigningCertificate $certData -IssuerUri $uri -ActiveLogOnUri $ecpUrl -LogOffUri $logouturl -MetadataExchangeUri $mex

Verifying Single Sign-On Access

Prerequisite:

  • You need at least one user in Office 365 to verify that single sign-on is set up. If you have an existing user, ensure that the Immutable ID matches the GUID of the Access Manager user.

    For instance if your user store is eDirectory and you want to retrieve the GUID of an existing Access Manager user, execute the following command on the eDirectory server terminal:

    ldapsearch -D cn=<context> -w <password> -b <search base> cn=<fqdn of the administrator> GUID | grep GUID

    Create an Office 365 user with this GUID as the Immutable ID using the following command in Powershell:

    new-msolUser -userprincipalName "user1@domain name" -immutableID "GUID of user1" - lastname "lastname of user 1" -firstname user1 -DisplayName "user1 users" -BlockCredential $false -"LicenseAssignment testdomain:ENTERPRISEPACK" -usageLocation "two letter country code[example: US,IN,DE,BE,GB etc]" -Password "password of the user" - LicenseAssignment validlicense.

Procedure to verify:

To verify that single sign-on is set up correctly, perform the following procedure in a server that is not added to the domain.

  1. Go to Microsoft Online Services

  2. Log in with your corporate credentials. (For example : user1@namtest.com)

    If single sign-on is enabled, the password field is dimmed. You will instead see the following message: You are now required to sign in at <your company>.

  3. Select the Sign in at your company link.

    If you are able to sign in without errors, single sign-on is set up successfully.