4.2.13 Configuring Single Sign-On for Office 365 Services

Access Manager provides single sign-on access to Office 365 services such as Exchange Server, SharePoint Online, and Lync without using ADFS (Active Directory Federation Services). You can use your existing enterprise credentials to access any of the Office 365 services without sign in multiple times to access different services. You can sign in once with an existing password and Access Manager grants you access to all services.

This single sign-on access is achieved by implementing Passive or Active authentication by using WS-Federation, WS-Trust, and SAML 2.0 protocols.

A trust model is set up for Access Manager and Office 365 to communicate with each other. Access Manager as an identity provider allows Office 365 to trust it for authentication. Office 365 configured as a service provider, consumes authentication assertions from Access Manager.

Access Manager supports single sign-on to the following Office 365 applications:

  • SharePoint

  • Office 365 Portal

  • Outlook Web Access

  • Lync 2010

  • Lync 2013

  • Skype for Business 2015

  • Outlook 2013

Topics include:

Passive and Active Authentication

In a Passive authentication scenario, the user signs in through a web form displayed by the identity provider and the user is requested to log in. In Active authentication scenario, the user is authenticated using thick clients. As the thick client does not support redirection, Office 365 gets the credentials and validates the authentication with Access Manager by communicating directly with it.

Passive authentication is supported by using the WS-Federation protocol and supports sign-in to Office 365 using the web interface. The clients includes the Office 365 portal, SharePoint Online, Outlook Web Access, and the Office Web Apps. You can achieve passive authentication using either SAML 2.0 or WS-Federation protocol.

Active authentication is supported by using the WS-Trust protocol and supports sign-in to Office 365 using Office client applications. The clients includes Outlook, Lync, Word, Excel, PowerPoint, and OneNote. If you are using Microsoft Exchange, you can use SAML 2.0 but for active authentication, WS-Trust is the recommended protocol.

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 Configuring an Office 365 Domain That Supports Passive Federation by using SAML 2.0

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

Prerequisite

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

  1. Click Devices > Identity Servers > Edit.

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

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. 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 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.

Configuring Microsoft Domain Specific Consistency Attribute as Immutable ID

You can configure mS-DS-ConsistencyGuid attribute as immutable ID using the following procedure:

  1. Create a data source. For more information, see Creating a Data Source

  2. Create an attribute source. For more information, see Creating an Attribute Source

    NOTE:Specify the following details in Step 1: Provide input parameters:

    • Parameter Name: Select any name. Example: %P1%

    • Parameter Value: cn

    • Property Value: (&(Objectclass=*)(sAMAccountName=%P1%))

    • Filter Output Parameter: Add the attribute mS-DS-ConsistencyGuid

  3. Create a virtual attribute. For more information, see Creating a Virtual Attribute

    NOTE:Specify the following details in Step 1: Provide input parameters:

    • Parameter Name: Add a name. Example: P1

    • Parameter Value: Select the Parameter Value. Example: AD:mS-DS-ConsistencyGuid

    • Select a function: No Modification.

  4. Map the attribute. For more information, see Configuring Attribute Mappings

    NOTE:Ensure to configure the attribute mapping as specified in step 4 and instead of GUID select the virtual attribute that you configured in the above step while mapping it to the ImmutableID.

Configuring an Office 365 Domain to Federate with Access Manager

Prerequisite

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

  • Identity Server must be accessible from outside the firewall so that Office 365 domain can communicate with Identity Server.

  • Sign up for an Office 365 account.

  • 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 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 Identity Server Base URL SSL certificate is issued by a well-known external certification authority (CA).

  • 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.

  • Install Microsoft Azure Active Directory Module. To download, click Install the MSonline module.

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 and specify your cloud service administrator account credentials.

  3. Ensure that you have the identity server certificate in .cer format. Access Manager does not support .ctr format.

  4. Run Connect-MsolService –Credential $cred

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

    NOTE:In this example, the port is not specified with Base URL because 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/

    $dom = "namtest.com"
    $url = "https://namtest.com/nidp/wsfed/ep"
    $ecpUrl = "https://namtest.com/nidp/wstrust/sts/active12"
    $uri = "https://namtest.com/nidp/wsfed/"
    $logouturl = "https://namtest.com/nidp/jsp/o365wsfedlogout.jsp"
    $mex = "https://namtest.com/nidp/wstrust/sts/mex"
    $cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2 "<name and path of the certificate>"
    $certData = [system.convert]::tobase64string($cert.rawdata)
    $brand = "NamTest Co Bangalore"
  5. Use the following cmdlet to update the settings of the single sign-on domain.

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

NOTE:You can enable or disable auto-populating of the username on the Identity Server login page. For more information, see HTTP POPULATE LOGINNAME FROM WSFED AUTH REQUEST (This option is available in Access Manager 4.5 Service Pack 1 or later versions).

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 -x -h 127.0.0.1 -p 389 -D cn=admin,o=novell -w novell -b cn=anand,o=novell guid

    Where h is host, p is port, D is bind credential, w is password, b is search scope, and guid is the attribute to search.

    Create an Office 365 user with this GUID as the Immutable ID by 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@namnetiq.in)

    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.

Configuring objectSid as the Immutable ID

Configuring objectSid as the Immutable ID consists of the following tasks:

  1. Adding the objectSid Attribute as a Custom Attribute

  2. Creating Attribute Set

  3. Configuring the Attribute Set for WS-Federation or WS-Trust

Adding the objectSid Attribute as a Custom Attribute

  1. Click Devices > Identity Servers > Shared Settings > Custom Attributes.

  2. Under LDAP Attribute Names, click New.

  3. Specify objectSid, and select 64-bit Encode Attribute Data.

  4. Click OK.

Creating Attribute Set

  1. Click Attribute Sets.

  2. Click New, and specify a Set Name. Click Next.

  3. Click New and specify the following details:

    Field

    Description

    Local attribute

    Ldap Attribute:mail [LDAP Attribute Profile]

    Remote attribute

    URN

    Remote namespace

    http://schemas.xmlsoap.org/claims

    Remote format

    unspecified

    Attribute value encoding

    Special characters encoded

  4. Click OK.

  5. Create another Attribute Set. Click New, and specify a Set Name.

  6. Click Next > New and specify the following details:

    Field

    Description

    Local attribute

    Ldap Attribute: Ldap Attribute:objectSid#[nidsForceBinary] [LDAP Attribute Profile]

    Remote attribute

    ImmutableID

    Remote namespace

    http://schemas.microsoft.com/LiveID/Federation/2008/05

    Remote format

    unspecified

    Attribute value encoding

    Special characters encoded

  7. Click OK > Finish.

Configuring the Attribute Set for WS Federation or WS-Trust

Configure the Attribute Set for the WS-Federation or WS-Trust service provider. For more information about configuring the Attribute Set, see Configuring the Attributes Sent with Authentication and Modifying Service Providers.

Configuring Federation with Office 365 Services for Multiple Domains

You can now federate multiple parent domains with a single Access Manager cluster. This means that if the enterprise has users in multiple domains, a single Access Manager cluster can handle the single sign-on requests for all the users for Office 365 services.

For example: Let us assume you have users spread across two domains: user1@namtest.com and user2@namnetiq.in. When user1@namtest.com and user2@namnetiq.in access Office 365 services, the same Access Manager identity provider automatically forms the response with the corresponding Issuer URI and sends it to corresponding domains configured in the Office 365 service.

Creating Multiple Domains in Office 365 and Establishing Federation with Access Manager

  1. Ensure that you meet the prerequisites for creating a domain. For more information, see Prerequisite.

  2. Create a new Office 365 domain and verify it. For more information see Adding and Verifying a Domain for Office 365.

    NOTE:Office 365 does not support creating a child domain if federation configuration for parent domain is already established by using powershell. Ensure that you add all child domains from the Office 365 admin center before establishing federation for the parent domain.

    For more information about establishing federation when there are multiple domains and a child domain, see Configuring Federation for Multiple Domains.

  3. According to the example used in section Enabling Federation Settings in Office 365 Domain, we have an existing domain named namtest.com.

    To create a new domain named namnetiq.in, run the following commands in Powershell by modifying the commands with your domain name as per your setup.

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

    2. Run Connect-MsolService –Credential $cred

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

      NOTE:

      • In the following example, port is not mentioned as it uses 443. However, if you are using port 8443, specify the port with the Base URL as follows:

        For example: https://namnetiq.in:8443/nidp/

      • When you add additional domains to Office 365 using Powershell commands, the variables $certdata, $url, $ecpurl, $logouturl,and $mex must contain the details provided for the existing domain. If you configure a new domain, change the values of $dom and the $uri

      1. $dom = "namnetiq.in"

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

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

      4. $uri = "https://namnetiq.in/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)

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

      Set-MsolDomainAuthentication -FederationBrandName -DomainName "federatedDomain.com" -Authentication Federated -PassiveLogOnUri $url -SigningCertificate $certData -IssuerUri $uri -ActiveLogOnUri $ecpUrl -LogOffUri $logouturl -MetadataExchangeUri $mex

      To configure any more domains, follow the same steps. Ensure that the Issuer URI includes the UPN of the domain. For example, if you are configuring a domain named support.in, the Issuer URI will be https://support.in/nidp/wsfed/.

  4. Go to Devices > Identity Servers > Edit > Options and ensure that the value for STS OFFICE365 MULTI DOMAIN SUPPORT AUTO is configured as true.

    This property enables users to access Office 365 services using the Issuer URI specific to the domain they belong to.

Configuring Federation for Multiple Domains

Consider a scenario where you already have users as part of namtest.com and namnetiq.in. You now need to create a child domain support.namnetiq.in under namnetiq.in. In this case no federation settings are available in Office 365 for the child domain. The federation setting for the parent domain is used. So, it is important that the Issuer URI is not automatically changed to the User Principal Name of the user. The Issuer URI must be set to the parent domain Issuer URI. For the child domain support.namnetiq.in, the Issuer URI will be https://namnetiq.in/nidp/wsfed/

  1. Click Devices > Identity Servers > Edit > Options > New.

    Property Type

    Property Value

    STS CHANGE ISSUER

    Specify the value in this format: SPentityID:UPNDomain -> new IssuerID.

    The values of SPentityID:UPNDomain are case-sensitive.

    For example, urn:federation:MicrosoftOnline:support.namnetiq.in -> https://namnetiq.in/nidp/wsfed/

    For example, urn:federation:MicrosoftOnline:support.namnetiq.in -> https://namnetiq.in/nidp/wsfed/

    In case of multiple child domains, add each parent domain and child domain separated by comma. For example, if namnetiq.in is the parent domain and support.namnetiq.in and engineering.namnetiq.in are the child domains, specify the following entries:

    urn:federation:MicrosoftOnline:namnetiq.in -> https://namnetiq.in/nidp/wsfed/, urn:federation:MicrosoftOnline:support.namnetiq.in -> https://namnetiq.in/nidp/wsfed/, urn:federation:MicrosoftOnline:engineering.namnetiq.in -> https://namnetiq.com/nidp/wsfed/

    STS OFFICE365 MULTI DOMAIN SUPPORT AUTO

    Select false.

    This ensures that the Issuer URI is formed based on the UPN of the parent domain.

  2. Click OK > Apply.

Configuring an Office 365 Domain That Supports Passive Federation by using SAML 2.0

Prerequisite

Ensure that SAML 2.0 is enabled in Access Manager.

  1. Click Devices> Identity Servers > Edit.

  2. In the Enabled Protocols section, verify whether SAML 2.0 is selected.

Configuring an Office 365 Domain to Federate with Access Manager

Prerequisite

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

  • Sign up for an Office 365 account.

  • 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. By doing this 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 Identity Server Base URL SSL certificate is issued by a well-known external certification authority (CA).

  • 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, click Install the MSonline module.

Setting Up Office 365 Services

Office 365 is preconfigured to establish federation with an external service providers.

Perform the following steps to create a trusted service provider:

  1. Click Devices> Identity Servers > Edit.

  2. Click SAML 2.0 > New >Service Provider.

  3. Select Provider Type as Office 365. Ensure that Source is selected as the Metadata Text.

  4. Specify a name for the Office 365 domain. The XML metadata is automatically populated in the Text field. Click Next.

  5. Confirm the certificates and click Finish to save the changes.

Establishing Trust Between an Identity Provider and a Service Provider

You can configure Office 365 domains federations by using the Microsoft Online Services Module. You can use the Microsoft Online Services Module to run a series of cmdlets in the Windows PowerShell command-line interface to add or convert domains for single sign-on.

Each Active Directory domain that you want to federate by using Access Manager must either be added as a single sign-on domain or converted to be a single sign-on domain from a standard domain. Adding or converting a domain sets up a trust between Access Manager and Office 365.

Adding a Domain:

To add a domain to Office 365, perform the following steps:

  1. Log in to Office 365 as an administrator.

  2. On the Administrator page, click Management > Domains > Add a domain.

  3. Specify the domain name that you want to add.

  4. Click Next.

  5. Verify the domain name.

    For more information about how to verify a domain, see Verify your domain and change name servers.

  6. Select appropriate services.

  7. Configure the DNS records on the domain registrar for other services.

    NOTE:Do not configure the new domain to the primary domain. Using the Set­MsolDomainAuthentication command to set the domain as a federated domain results in an error if the domain is the default domain.

For more information, see Add a domain to Office 365.

Converting a standard domain to a federated domain: To convert a standard domain to a federated domain, perform the following steps:

  1. Open the Microsoft Online Services Module from the Start menu.

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

  3. Run Connect-MsolService –Credential $cred.

    This cmdlet connects you to the cloud service. Creating a context that connects you to the cloud service is required before running any of the additional cmdlets installed by the tool.

    For example, if the name of the domain you are converting to a single sign-on domain is namtest.com, and the base URL of Identity Server is https://namtest.com:8443/nidp, execute the following commands at the Powershell prompt:

    1. $dom = "namtest.com"

    2. $url = "https://namtest.com:8443/nidp/saml2/sso"

    3. $ecpUrl = "https://namtest.com:8443/nidp/saml2/soap"

    4. $uri = "https://namtest.com:8443/nidp/saml2/metadata"

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

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

      NOTE: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

    7. $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 -PreferredAuthenticationProtocol SAMLP

    NOTE:Ensure that there are no spaces after the hyphen if you are copy pasting the command.

Configuring Specific Attributes as ImmutableID

By default, Office 365 uses GUID as the ImmutableID. If you want to use any other attribute as the ImmutableID of the Office 365 user, configure and then add a property name/value pair.

  1. In Administration Console, go to Identity Server and select an Identity Server.

  2. Select SAML 2.0 and then select the service provider you created.

  3. Select Options and click New.

  4. Add a property name/value pair as follows:

    Property Name: SAML2_OFFICE365_NAMEID_ATTRIBUTE_NAME

    Property Value: title

The title you specify in the Property Value must be base64 encoded and stored in the user store. This value must be used as ImmutableID while creating a user in Office 365.

Configuring Virtual Attributes as ImmutableID

Virtual attributes can be helpful in many scenarios:

  • If the attribute has clear text value, virtual attribute can be used to dynamically convert it into a base64 value

  • Retrieve the attribute from an external datasource and use it as the ImmutableID

To use virtual attribute as ImmutableID, perform the following steps:

  1. Create a virtual attribute. For information about how to create a virtual attribute, see Managing a Virtual Attribute.

  2. Go to Devices > Identity Servers > Servers > Edit > SAML 2.0 > Service Provider > Options and add the following property for Office 365:

    • Property Name: SAML2_OFFICE365_NAMEID_ATTRIBUTE_NAME

    • Property Value: Specify the name of the virtual attribute

  3. Add the virtual attribute created in step 1 to the attribute set created for the SAML 2.0 service provider configuration for Office 365. This ensures that the name specified in SAML2_OFFICE365_NAMEID_ATTRIBUTE_NAME is mapped to the virtual attribute with that value. If the virtual attribute is not added to the attribute set, Access Manager considers the name as a normal LDAP attribute name.

Configuring Desktop Email Client to Access Office 365 Emails

You can configure your desktop email client to access Office 365 emails. The email clients must use a basic authentication and a supported exchange access method such as IMAP, POP, Active Sync, and MAPI.

The following are the list of email clients supported for this configuration:

  • Microsoft Outlook 2007

  • Microsoft Outlook 2010

  • Thunderbird 8 and 9

  • The iPhone (various iOS versions)

  • Windows Phone 7

NOTE:You can download the email clients from the download section of Office 365.

These steps are explained with an example where the federated domain name is namtest.com and the base URL is https://namtest.com:8443/nidp. Replace the domain name and base URL based on your system configuration.

  1. Open the Microsoft Online Services Module.

  2. Run the following command:

    $cred=Get-Credential

    Specify your cloud service administrator account credentials.

  3. Run the following command:

    Connect-MsolService –Credential $cred

    This cmdlet connects you to the cloud service.

  4. Execute the following command to check the existing domain federation settings:

    Get-MsolDomainFederationSettings -DomainName namtest.com

    Substitute namtest.com with your domain name before executing this command.

    In the output, look for the ActiveLogOnUri parameter.

    For Identity Server base URL https://namtest.com:8443/nidp, the value of the ActiveLogOnUri must be https://namtest.com:8443/nidp/saml2/soap. The ActiveLogOnUri is dependent on the base URL of Identity Server.

    If the value of ActiveLogOnUri in the command output is https://namtest.com:8443/nidp/saml2/soap, go to Step 5 without modifying the configuration.

    (Conditional) If the ActiveLogOnUri is not https://namtest.com:8443/nidp/saml2/soap, execute the following command. Substitute namtest.com and port 8443 with your domain name and port number respectively before executing the following command.

    Set-MsolDomainFederationSettings -DomainName namtest.com -ActiveLogOnUri "https://namtest.com:8443/nidp/saml2/soap" -preferredauthenticationprotocol SAMLP
  5. Create a new email account in your email client and enter your Office 365 email ID.

    NOTE:Configure Outlook related DNS settings before using email clients. You can configure these settings after adding the domain on the Office 365 port page.

  6. The system prompts for specifying the basic authentication. Specify Access Manager credentials.

    The email account is created after successful authentication.

    NOTE:While logging in to the new email account, enter Access Manager credentials.

Configuring Desktop Email Client to Access Office 365 Emails

You can configure your desktop email client to access Office 365 emails. The email clients must use a basic authentication and a supported exchange access method such as IMAP, POP, Active Sync, and MAPI.

The following are the list of email clients supported for this configuration:

  • Microsoft Outlook 2007

  • Microsoft Outlook 2010

  • Thunderbird 8 and 9

  • The iPhone (various iOS versions)

  • Windows Phone 7

NOTE:You can download the email clients from the download section of Office 365.

These steps are explained with an example where the federated domain name is namtest.com and the base URL is https://namtest.com:8443/nidp. Replace the domain name and base URL based on your system configuration.

  1. Open the Microsoft Online Services Module.

  2. Run the following command:

    $cred=Get-Credential

    Specify your cloud service administrator account credentials.

  3. Run the following command:

    Connect-MsolService –Credential $cred

    This cmdlet connects you to the cloud service.

  4. Execute the following command to check the existing domain federation settings:

    Get-MsolDomainFederationSettings -DomainName namtest.com

    Substitute namtest.com with your domain name before executing this command.

    In the output, look for the ActiveLogOnUri parameter.

    For the Identity Server base URL https://namtest.com:8443/nidp, the value of the ActiveLogOnUri must be https://namtest.com:8443/nidp/saml2/soap. The ActiveLogOnUri is dependent on the base URL of the Identity Server.

    If the value of ActiveLogOnUri in the command output is https://namtest.com:8443/nidp/saml2/soap, go to Step 5 without modifying the configuration.

    (Conditional) If the ActiveLogOnUri is not https://namtest.com:8443/nidp/saml2/soap, execute the following command. Substitute namtest.com and port 8443 with your domain name and port number respectively before executing the following command.

    Set-MsolDomainFederationSettings -DomainName namtest.com -ActiveLogOnUri "https://namtest.com:8443/nidp/saml2/soap" -preferredauthenticationprotocol SAMLP
  5. Create a new email account in your email client and enter your Office 365 email ID.

    NOTE:Configure Outlook related DNS settings before using email clients. You can configure these settings after adding the domain on the Office 365 port page.

  6. The system prompts for specifying the basic authentication. Specify Access Manager credentials.

    The email account is created after successful authentication.

    NOTE:While logging in to the new email account, enter Access Manager credentials.

Configuring Specific Attributes as ImmutableID

By default, Office 365 uses GUID as the ImmutableID. If you want to use any other attribute as the ImmutableID of the Office 365 user, configure and then add a property name/value pair.

  1. In Administration Console, go to Identity Server and select an Identity Server.

  2. Select SAML 2.0 and then select the service provider you created.

  3. Select Options and click New.

  4. Add a property name/value pair as follows:

    Property Name: SAML2_OFFICE365_NAMEID_ATTRIBUTE_NAME

    Property Value: title

The title you specify in the Property Value must be base64 encoded and stored in the user store. This value must be used as ImmutableID while creating a user in Office 365. If the value is in a clear text format, you need to use virtual attributes to convert it into a base64 format.

To use virtual attribute as ImmutableID, perform the following steps:

  1. Create a virtual attribute. For information about how to create a virtual attribute, see Managing a Virtual Attribute.

  2. Ensure that the final value of the virtual attribute is the base64 encoded value. You can achieve it in any of the following ways:

    • Configure a virtual attribute to retrieve a value stored in the clear text format from an attribute source (LDAP or database)

    • Transform the value into the base 64 encoded format by using the advanced JavaScript option

  3. Go to Devices > Identity Servers > Servers > Edit > SAML 2.0 > Service Provider > Options and add the following property for Office 365:

    • Property Name: SAML2_OFFICE365_NAMEID_ATTRIBUTE_NAME

    • Property Value: Specify the name of the virtual attribute

    This ensures that the NAMEID value is fetched based on the property name. Currently, the name is considered as a user attribute.

  4. Add the virtual attribute created in step 1 to the attribute set created for the SAML 2.0 service provider configuration for Office 365. This ensures that the name specified in SAML2_OFFICE365_NAMEID_ATTRIBUTE_NAME is mapped to the virtual attribute with that name. If the virtual attribute is not added to the attribute set, Access Manager considers the name as a normal LDAP attribute name.

Auto-Populating the Username on the Identity Server Login Page

(Access Manager 4.5 SP1 and later)

When employees try to access an Office 365 application, they need to specify the username twice as follows:

  1. First, on the Microsoft login page

  2. Then, on the organization’s identity provider login page

Using Access Manager, you can enable auto-populating the email ID or username of a user on the corporate login page when the user accesses Office 365 applications. So that the user does not need to specify the username or email ID again.

For example, an employee named Steve Smith wants to access an Office 365 application. He performs the following steps:

  1. Launches a Microsoft’s page (www.office.com).

  2. Specifies his email ID (steve.smith@example.com).

    Steve is then redirected to the organization’s identity provider for authentication.

  3. Specifies the email ID again.

When auto-populating email ID or username is enabled, Steve does not need to perform Step 3.

Enabling Auto-Populating Email ID

  1. Click Devices > Identity Servers > Edit > General > Options.

  2. Click New and specify the following:

    Property Name: HTTP POPULATE LOGINNAME FROM SAML AUTH REQUEST

    Property Name: True

  3. Click OK > Apply.

  4. Update Identity Server.

    NOTE:Usernames are not populated if the Basic type authentication contracts are used.

Enabling Auto-Populating Username

If you want to populate only the username instead of the entire email ID, perform the following steps. For example, populate steve.smith instead of steve.smith@example.com.

  1. Click Devices > Identity Servers > Edit > General > Options.

  2. Click New and specify the following:

    Property Name: HTTP POPULATE PARSED LOGINNAME FROM SAML AUTH REQUEST

    Property Name: True

  3. Click OK > Apply.

  4. Update Identity Server.

    NOTE:If both HTTP POPULATE LOGINNAME FROM SAML AUTH REQUEST and HTTP POPULATE PARSED LOGINNAME FROM SAML AUTH REQUEST properties are set to true, then the login page will display the entire email ID.

IMPORTANT:If you have customized any JSP file, copy those changes to the login_latest.jsp file located at the following locations:

Linux: /opt/novell/nids/lib/webapp/jsp/

Windows: \Program Files\Novell\Tomcat\webapps\nidp\jsp

Verifying Single Sign-On Access

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 with the GUID of the Access Manager user.

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=<name of the user> 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".

Verifying Single Sign-on:

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.

Troubleshooting Scenarios

WS-Trust and WS-Federation Scenarios

Issue in Setting Up a Domain for Federation

If you try to set a primary domain for federation by running the Set­MsolDomainAuthentication command, it throws the following error:

Set­MsolDomainAuthentication: You cannot remove this domain as the default domain without replacing it with another default domain. Use the Set­MsolDomain cmdlet to set another domain as the default domain before you delete this domain.

To fix this issue, change the default domain by performing the following steps:

  1. In the Office 365 portal, click Organization Name on the Admin page.

  2. Click Edit.

  3. Select a new default domain.

Set-MsolDomainAuthentication : You cannot remove this domain as the default domain without replacing it with another default domain

If you get this error it indicates that you attempted to delete the default domain without replacing it with another domain.

Use the Set-MsolDomain cmdlet to set another domain as the default domain before you delete this domain.

After upgrading iOS Apps to the Latest Version, Single Sign-On to Office 365 Services Fail

To establish single sign-on from iOS apps to Office 365 services, perform the following steps:

  1. Click Devices > Identity Servers > Edit > Local > Contract.

  2. Specify a name to identity the contract.

  3. Specify the URI as http://schemas.microsoft.com/ws/2008/06/identity/authenticationmethod/password.

  4. Select Name/Password - Form - WebService method.

SAML 2.0 Scenarios

SSO to MicroSoft Services Fails

SSO fails at Microsoft with this error:

Your organization could not sign you in to this service

Perform the following steps to fix this issue:

  • Verify that the attributes are configured properly.

    You can also use the SAML tracer plug-in Firefox to review the SAML assertion sent to Office365.

  • Verify that federation settings are using the Get­MsolDomainFederationSettings ­ DomainName <YOUR DOMAIN> command.

Issue in Setting Up a Domain for Federation

If you try setting up a primary domain for federation by running the Set­MsolDomainAuthentication command, it throws the following error:

Set­MsolDomainAuthentication: You cannot remove this domain as the default domain without replacing it with another default domain. Use the Set­MsolDomain cmdlet to set another domain as the default domain before you delete this domain.

To fix this issue, change the default domain by performing the following steps:

  1. In the Office 365 portal, click Organization Name on the Admin page.

  2. Click Edit.

  3. Select a new default domain.

Office 365 Domain Scenarios

Issues with the Directory Synchronization Tool

  • If the installation of the Directory Synchronization tool fails, check the Event Viewer. Installation may fail if the Microsoft Online Service Sign­In Assistant is already installed on the system.

  • If you need to uninstall the Directory Synchronization tool, log off and then login.

  • If the Directory Synchronization tool is slow, increase RAM of the server.

Active Profile Authentication Fails for Microsoft Exchange Clients

If the active profile authentication fails for Microsoft Exchange (Outlook) clients, verify that the necessary DNS records have been added to your DNS. For more information, see Create DNS records at any DNS hosting provider for Office 365.

Microsoft Online Services Sign-In Assistant Installation Fails If Microsoft Office Professional Plus Is Installed

Manually install Microsoft Online Services Sign-In Assistant, if its installation fails after installing Microsoft Office Professional Plus with this message:

"The Microsoft Online Services Sign In Assistant has experience an error. The error must be resolved before your subscription for this product can be verified. To retry subscription verification, first resolve error message 800704DD or try to manually install the Microsoft Online Services Sign In Assistant...." 

You can download the installer from MicroSoft Download Center.

After installation is complete, relaunch the service to verify your Office 365 license.

Single Sign-On to Office 365 Domain Fails

If single sign-on fails, ensure that the ImmutableID and the User Principal Name (UPN) matches the Office 365 user. To get Office 365 user details, log in to using Powershell and execute the following command:

Get-MsolUser -UserPrincipalName user1@namtest.com | fl *

No License to Use Office 365 Services

If you receive an error stating that the user does not have license to use Office365, Log in to Office 365 as an administrator and assign required service licenses to the user.

After Initial Successful Authentication, Unending Loop While Logging into Lync Using Wrong Username and Password

After successfully authenticating to the Office 365 client, if you attempt to log in to the Lync client by using an incorrect username and password, the Lync client uses the details from the previous successful session and tries to get a token from Access Manager. This results in an unending loop.

To resolve this issue, in the Lync client user interface, select the Delete my sign-in info option and log in again.

Single Sign-on Fails in Skype for Business 2016

Issue: Single sign-on to Skype for Business 2016 fails using the Identity Server login page. This issue occurs because Skype for Business 2016 is not compatible with the higher version of jQuery. Access Manager uses a higher version of jQuery to prevent security vulnerabilities.

Fix: To fix this issue, you must replace the higher version of jQuery with lower version (not recommended) by performing one of the following steps.

  1. In Windows, navigate to the following path, rename the jquery.min.js file to jquery.min_backup.js and rename the jquery_old.min.js file to jquery.min.js.

    C:\Program Files\Novell\Tomcat\webapps\nidp\javascript

  2. In Linux, run the following commands in the /opt/novell/nam/idp/webapps/nidp/javascript/ directory.

    $mv jquery.min.js jquery.min_backup.js

    $mv jquery_old.min.js jquery.min.js

Sample Tokens

Sample SAML Token

Request

<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="_3ae4edbc-7ab5-48c7-a08e-b8d6e395e02c" IssueInstant="2012-09-09T08:41:35Z" Version="2.0" AssertionConsumerServiceIndex="0" ><saml:Issuer>urn:federation:MicrosoftOnline</saml:Issuer><samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"/></samlp:AuthnRequest>

Response

<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Consent="urn:oasis:names:tc:SAML:2.0:consent:obtained" Destination="https://login.microsoftonline.com/login.srf" ID="idRuMHBvlVGqYUsw2Es-SbA5UeO8w" InResponseTo="_3ae4edbc-7ab5-48c7-a08e-b8d6e395e02c" IssueInstant="2012-09-09T08:41:51Z" Version="2.0">
  <saml:Issuer>https://www.netiqtst.com/nidp/saml2/metadata</saml:Issuer  
  <samlp:Status>
    <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success  />
  </samlp:Status>
  <saml:Assertion ID="idF5JceWGWYwS3bOkmJS2wJuNqitU" IssueInstant="2012-09-09T08:41:51Z" Version="2.0">
    <saml:Issuer>https://www.netiqtst.com/nidp/saml2/metadata</saml:Issuer>
    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
      <ds:SignedInfo>
        <CanonicalizationMethod xmlns="http://www.w3.org/2000/09/xmldsig#" Algorithm="http://www.w3.org/2001/10/xml-exc        n#"/>
        <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
        <ds:Reference URI="#idF5JceWGWYwS3bOkmJS          qitU">
          <ds:Transforms>
            <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
            <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
          </ds:Transforms>
          <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
          <DigestValue xmlns="http://www.w3.org/2000/09/xmldsig#">ZocFiEUYcda0cKGRNcZYZqvmnlM=</DigestValue>
        </ds:Reference>
      </ds:SignedInfo>
      <SignatureValue xmlns="http://www.w3.org/2000/09/xmldsig#">
DLk4Uv/4VlwwKVz7XdDQOdUv8ltcryLv2U3K7q57AE70wk/NNsa4kP8Xdta36Y47Oj+XTV+a+q0y
YsMNIezySxaxMqo01Fm+6PfMH7HtTVj7fQ3n+VwANqbIs3G7eaaV1pHdUs79/dBujS8baNmlZEBR
2gGVMWCHOa1fTOSZO8yPt9ume0PsYXpo2RdaoGkJCZUnVIiIWg6UtI0zEKbY6mP3JhrUJ7OVHdbz
yNBzhfTv0m71nz0JKpy+i8MeDUIu1OiqTTIZ+c2SPceYhQcj8umrdE4JCGEBYNIE52Pa1bRYgmLd
roAKn56vLDjq04VnYVRGhqP/McZwYZrx+7E7qQ==
      </SignatureValue>
      <ds:KeyInfo>
        <ds:X509Data>
          <ds:X509Certificate>
MIIFBzCCA++gAwIBAgIRAKdqzGh19tecryvMuy+QhgAwDQYJKoZIhvcNAQEFBQAwcjELMAkGA1UE
BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG
A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxGDAWBgNVBAMTD0Vzc2VudGlhbFNTTCBDQTAeFw0xMjA5
MDcwMDAwMDBaFw0xMjEyMDYyMzU5NTlaMFExITAfBgNVBAsTGERvbWFpbiBDb250cm9sIFZhbGlk
YXRlZDERMA8GA1UECxMIRnJlZSBTU0wxGTAXBgNVBAMTEHd3dy5uZXRpcXRzdC5jb20wggEiMA0G
CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCX6k7wnFUoyPtqSj06xyQMHQtoxASBtHGASaOMxfZJ
rHQ4wbJUqMEtrxYcz4JxFrLzE8qvlY5r7cwxx/yvsiFwHq2HdRY6KU6I2u0eRF/tRwf3rl222/Xl
7wRbgdL43zd0yypjub9FKXlCxkaKucA1P+EVGTd7H8dFjMuf0iKZYvBFg9tcJWBGpFOw5iwe/rjK
6gQSXf13+Tpb6915lsusJfPMe3t04wA4XuyLlcJ/Jrxrj9xrEtwkmUcudTvEZRvJFnz3NYXcW0J8
6a0JZSEiHlVHrIY/44fVEQFjkrfr2u5RKGBJzl35xb2x5mkUSzzy4CSL5p0fCsVOve7LKx/fAgMB
AAGjggG3MIIBszAfBgNVHSMEGDAWgBTay+qtWwhdzP/8JlTOSeVVxjj0+DAdBgNVHQ4EFgQUEj/C
c5rqiBWiSzo9B8iJPdJnCpYwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwNAYDVR0lBC0w
KwYIKwYBBQUHAwEGCCsGAQUFBwMCBgorBgEEAYI3CgMDBglghkgBhvhCBAEwRQYDVR0gBD4wPDA6
BgsrBgEEAbIxAQICBzArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8uY29tL0NQ
UzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9Fc3NlbnRpYWxTU0xD
QS5jcmwwbgYIKwYBBQUHAQEEYjBgMDgGCCsGAQUFBzAChixodHRwOi8vY3J0LmNvbW9kb2NhLmNv
bS9Fc3NlbnRpYWxTU0xDQV8yLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2Eu
Y29tMCkGA1UdEQQiMCCCEHd3dy5uZXRpcXRzdC5jb22CDG5ldGlxdHN0LmNvbTANBgkqhkiG9w0B
AQUFAAOCAQEAJoS/fE0gBMWvzQBsRRuSMBHMNbgDXP1fVPwJZnkfIHbb/wXwYK7AqA5efOe1Alqz
QD94kJ+W6JZm4ripePJk7QLnK2imqJb0E7LdmWQ3D05WQNsZKUklfR+9elP6xBN5ycXqtiEItScm
hE7H2gynz4/ejLXZv8XsBkfsYnT0wWUmyTsqYPLmVk7ELfPiPGZsQcvpmSO9eoTQ8zabkQGjquzM
NgGtXOMQBQgNO/7IMghgmSR0NduPguZoL31Ox84yKdf6Hl5cvbnH2W4c0n8vTkgCwUkB8ONY1Tge
6TFPwzS98PzV08nxKSJW1hckasLQAYcw++bC7Blz+Nc7YyrNPw==
          </ds:X509Certificate>
        </ds:X509Data>
      </ds:KeyInfo>
    </ds:Signature>
    <saml:Subject>
      <saml:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent" NameQualifier="https://www.netiqtst.com/nidp/saml2/metadata" SPNameQualifier="urn:federation:MicrosoftOnline">bzM2NkBuZXRpcXRzdC5jb20=</saml:NameID>
      <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
        <saml:SubjectConfirmationData InResponseTo="_3ae4edbc-7ab5-48c7-a08e-b8d6e395e02c" NotOnOrAfter="2012-09-09T09:41:51Z" Recipient="https://login.microsoftonline.com/login.srf"/>
      </saml:SubjectConfirmation>
    </saml:Subject>
    <saml:Conditions NotBefore="2012-09-09T05:55:12Z" NotOnOrAfter="2012-09-09T11:28:30Z">
      <saml:AudienceRestriction>
        <saml:Audience>urn:federation:MicrosoftOnline</saml:Audience>
      </saml:AudienceRestriction>
    </saml:Conditions>
    <saml:AuthnStatement AuthnInstant="2012-09-09T08:41:51Z" SessionIndex="idF5JceWGWYwS3bOkmJS2wJuNqitU">
      <saml:AuthnContext>
        <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</saml:AuthnContextClassRef>
        <saml:AuthnContextDeclRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</saml:AuthnContextDeclRef>
      </saml:AuthnContext>
    </saml:AuthnStatement>
    <saml:AttributeStatement>
      <saml:Attribute xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" Name="IDPEmail" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
        <saml:AttributeValue xsi:type="xs:string">o3662@netiqtst.com</saml:AttributeValue>
      </saml:Attribute>
      <saml:Attribute xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" Name="ImmutableID" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
        <saml:AttributeValue xsi:type="xs:string">bzM2NkBuZXRpcXRzdC5jb20=</saml:AttributeValue>
      </saml:Attribute>
    </saml:AttributeStatement>
  </saml:Assertion>
</samlp:Response>

Sample WS-Trust Token

<saml:Assertion AssertionID="nsts150b8594-0aff-424f-8113-46045d943171" IssueInstant="2014-05-09T07:00:18.019Z" Issuer="https://namnetiq.in/nidp/wsfed/" MajorVersion="1" MinorVersion="1" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:exc14n="http://www.w3.org/2001/10/xml-exc-c14n#" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" xmlns:xs="http://www.w3.org/2001/XMLSchema">
   <saml:Conditions NotBefore="2014-05-09T07:00:18.019Z" NotOnOrAfter="2014-05-09T07:06:18.019Z">
      <saml:AudienceRestrictionCondition>
         <saml:Audience>
          urn:federation:MicrosoftOnline
         </saml:Audience>
      </saml:AudienceRestrictionCondition>
   </saml:Conditions>
   <saml:Advice/>
   <saml:AuthenticationStatement AuthenticationInstant="2014-05-09T07:00:18.019Z" AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:password">
      <saml:Subject>
         <saml:NameIdentifier Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" NameQualifier="urn:federation:MicrosoftOnline">
          TLP1nEzIc0EEtEyz9ZxMyA==
         </saml:NameIdentifier>
         <saml:SubjectConfirmation>
            <saml:ConfirmationMethod>
             urn:oasis:names:tc:SAML:1.0:cm:bearer
            </saml:ConfirmationMethod>
         </saml:SubjectConfirmation>
      </saml:Subject>
   </saml:AuthenticationStatement>
   <saml:AttributeStatement>
      <saml:Subject>
         <saml:NameIdentifier Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" NameQualifier="urn:federation:MicrosoftOnline">
          TLP1nEzIc0EEtEyz9ZxMyA==
         </saml:NameIdentifier>
         <saml:SubjectConfirmation>
            <saml:ConfirmationMethod>
             urn:oasis:names:tc:SAML:1.0:cm:bearer
            </saml:ConfirmationMethod>
         </saml:SubjectConfirmation>
      </saml:Subject>
      <saml:Attribute AttributeName="UPN" AttributeNamespace="http://schemas.xmlsoap.org/claims">
         <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema">
          namtest@namnetiq.in
         </saml:AttributeValue>
      </saml:Attribute>
      <saml:Attribute AttributeName="ImmutableID" AttributeNamespace="http://schemas.microsoft.com/LiveID/Federation/2008/05">
         <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema">
          TLP1nEzIc0EEtEyz9ZxMyA==
         </saml:AttributeValue>
      </saml:Attribute>
   </saml:AttributeStatement>
   <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
      <ds:SignedInfo>
         <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
         <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
         <ds:Reference URI="#nsts150b8594-0aff-424f-8113-46045d943171">
            <ds:Transforms>
               <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
               <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
            </ds:Transforms>
            <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
            <ds:DigestValue>
             0Zvo3DbV0Qq7m9q7ER4Hol24bmA=
            </ds:DigestValue>
         </ds:Reference>
      </ds:SignedInfo>
      <ds:SignatureValue>
       SqWAA39fYb3VJPBebZ6bsiUh0C+8ElbgDv2yG6xq3WLYUX/DoQ6RLfsb/1mVmMQBcGqhUxhcDRAT
k6JA3djHbZCrZh7qblc8uBr+nm1SzpS/BO7todTLu+g835WGSKdpnpSoTjhO285MjsoomnrL+A4S
33F5Ld5OVOTPoar1wpBPFOgm7k9SnzjU0h7yIpP7YlzX1uF2sPvNeDRhkNEIsWwSPUY9mw04An9V
AsC1Cb1Q7+vEtCxggJ4A6nxk8G9bvPRisk7H5fTihf0THNEzu5s6KnyGHCc6k2/jWHHF4Appg/aJ
Ze1yQR9MKagNe60sAU2U83GM8WUst+o3+PvI3A==
      </ds:SignatureValue>
      <ds:KeyInfo>
         <ds:X509Data>
            <ds:X509Certificate>
             MIIFSTCCBDGgAwIBAgIGb+MI39nZMA0GCSqGSIb3DQEBCwUAMIHGMQswCQYDVQQGEwJVUzEQMA4G
A1UECBMHQXJpem9uYTETMBEGA1UEBxMKU2NvdHRzZGFsZTElMCMGA1UEChMcU3RhcmZpZWxkIFRl
Y2hub2xvZ2llcywgSW5jLjEzMDEGA1UECxMqaHR0cDovL2NlcnRzLnN0YXJmaWVsZHRlY2guY29t
L3JlcG9zaXRvcnkvMTQwMgYDVQQDEytTdGFyZmllbGQgU2VjdXJlIENlcnRpZmljYXRlIEF1dGhv
cml0eSAtIEcyMB4XDTE0MDUwNjA5MDYwNVoXDTE1MDIyNjEyMDQwNFowOTEhMB8GA1UECxMYRG9t
YWluIENvbnRyb2wgVmFsaWRhdGVkMRQwEgYDVQQDEwtuYW1uZXRpcS5pbjCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMzjEinlOiwzMpKBQO+H2sb+HifrmVi7JDzhRfOKJakG+nXsgVx2
QRToN0UbvoeqlDtaTZSKrFb0mc/E3aEkgSU67DAzWvtm3nUSboJc4QVWQlJmXIP989K2H1DastwE
Srg6iw0MMUuz9ZadP3BQjV4VVB9qX81D32lD4Ti1gJYUDg5tpaUnftddiR+rZQROea3ABC0+oeZa
7w+jVFUOAP+uG2iJ4zksIO+F3wIXDNZMYQwFlTvnCTO6/4cRW1XoGxh0BbZGdYn0qHzAOu9okT2B
gnz+aTaMGSIPpPr+PXjB31XqeAhBRoXgrddWIt1DawyrJETPOrzfMhd1i+QSXHcCAwEAAaOCAccw
ggHDMAwGA1UdEwEB/wQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMA4GA1UdDwEB
/wQEAwIFoDA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLnN0YXJmaWVsZHRlY2guY29tL3Nm
aWcyczEtOC5jcmwwWQYDVR0gBFIwUDBOBgtghkgBhv1uAQcXATA/MD0GCCsGAQUFBwIBFjFodHRw
Oi8vY2VydGlmaWNhdGVzLnN0YXJmaWVsZHRlY2guY29tL3JlcG9zaXRvcnkvMIGCBggrBgEFBQcB
AQR2MHQwKgYIKwYBBQUHMAGGHmh0dHA6Ly9vY3NwLnN0YXJmaWVsZHRlY2guY29tLzBGBggrBgEF
BQcwAoY6aHR0cDovL2NlcnRpZmljYXRlcy5zdGFyZmllbGR0ZWNoLmNvbS9yZXBvc2l0b3J5L3Nm
aWcyLmNydDAfBgNVHSMEGDAWgBQlRYFoUCY4PTstLL7Natm2PbNmYzAnBgNVHREEIDAeggtuYW1u
ZXRpcS5pboIPd3d3Lm5hbW5ldGlxLmluMB0GA1UdDgQWBBQANClvlYFFU3cAkvFQz/TxuttEUTAN
BgkqhkiG9w0BAQsFAAOCAQEAySHcxqGpgrm9HSiSIFzDOdC9BraZdjh+fIUBeKRUBmSjSByPJIHj
OGuBnY8FtuPY8/e1KhzwhZcuUhY3zwVQzbWStWLraySJyO1SzRRJC4onLbx42ARdKbRgxA/JDsmY
aTnyYq+ZOLm6XUtDweFEDkklAy2sO8gru54ogJ0iD/JyX/dgZEH/v9lGjdNFUDwG4dLz++a2Ol/U
UfqJye7Rb5UgNkewcG9KjydiTgP7Mv6m8/JjzOl31ejIVVqwz30fo+agirrIWWG2Ogtk0JUFrY73
coKTzspPszxMGN2FJpRSymtO+cqVlEuAK6/SCr2mhBvxg4GJuXuzSLp2kSrIfA==
            </ds:X509Certificate>
         </ds:X509Data>
      </ds:KeyInfo>
   </ds:Signature>
</saml:Assertion>

Sample WS-Federation Token

<wst:RequestedSecurityToken xmlns:wst="http://schemas.xmlsoap.org/ws/2005/02/trust">
      <saml:Assertion AssertionID="idjTptEEQd5CuKy-0M-MBCY9lDHVQ" IssueInstant="2014-05-09T06:44:07Z" Issuer="https://namnetiq.in/nidp/wsfed/" MajorVersion="1" MinorVersion="1" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion">
         <saml:Conditions NotBefore="2014-05-09T06:29:07Z" NotOnOrAfter="2014-05-09T06:59:07Z">
            <saml:AudienceRestrictionCondition>
               <saml:Audience>
                urn:federation:MicrosoftOnline
               </saml:Audience>
            </saml:AudienceRestrictionCondition>
         </saml:Conditions>
         <saml:AuthenticationStatement AuthenticationInstant="2014-05-09T06:44:07Z" AuthenticationMethod="name/password/uri">
            <saml:Subject>
               <saml:NameIdentifier Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">
                TLP1nEzIc0EEtEyz9ZxMyA==
               </saml:NameIdentifier>
               <saml:SubjectConfirmation>
                  <saml:ConfirmationMethod>
                   urn:oasis:names:tc:SAML:1.0:cm:bearer
                  </saml:ConfirmationMethod>
               </saml:SubjectConfirmation>
            </saml:Subject>
         </saml:AuthenticationStatement>
         <saml:AttributeStatement>
            <saml:Subject>
               <saml:NameIdentifier Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">
                TLP1nEzIc0EEtEyz9ZxMyA==
               </saml:NameIdentifier>
               <saml:SubjectConfirmation>
                  <saml:ConfirmationMethod>
                   urn:oasis:names:tc:SAML:1.0:cm:bearer
                  </saml:ConfirmationMethod>
               </saml:SubjectConfirmation>
            </saml:Subject>
            <saml:Attribute AttributeName="UPN" AttributeNamespace="http://schemas.xmlsoap.org/claims">
               <saml:AttributeValue>
                XX
               </saml:AttributeValue>
            </saml:Attribute>
            <saml:Attribute AttributeName="ImmutableID" AttributeNamespace="http://schemas.microsoft.com/LiveID/Federation/2008/05">
               <saml:AttributeValue>
                XX
               </saml:AttributeValue>
            </saml:Attribute>
         </saml:AttributeStatement>
         <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
            <ds:SignedInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
               <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" xmlns="http://www.w3.org/2000/09/xmldsig#"/>
               <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"/>
               <ds:Reference URI="#idjTptEEQd5CuKy-0M-MBCY9lDHVQ" xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
                  <ds:Transforms xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
                     <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"/>
                     <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"/>
                  </ds:Transforms>
                  <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"/>
                  <DigestValue xmlns="http://www.w3.org/2000/09/xmldsig#">
                   vOVgMA5UmoGFqXL4ENvYPsH/aP0=
                  </DigestValue>
               </ds:Reference>
            </ds:SignedInfo>
            <SignatureValue xmlns="http://www.w3.org/2000/09/xmldsig#">
             
hwPIdSGG+M29sih+5MiWEf862d5K/zSST3XVn1kIwWN3HaLi/yAnGiOUf6nzNJxE99pudElUdy3R
Kc5z8iQAu3gekVG1Nk4n2mDKZVet1kKEcgHGsfdwGxCkz5bpsPsaMB+pJyvFqu/RlRXIqsZtVrxv
7PwOIwUPxJQesNhJrdoJNsKxr65ckj2EeL5scCrDh9mYvtMCh/Qa0C3ALXUm+hBfj21hqw1Qp58I
m68DFTwh35pDkm4AXVxSRCm/9FKuoPGSXeU+O016Gv/FISLiEma+48dN0awlJvxzPI/cUayyJU2N
3EZp7LpZLfErushLBQQ9YmDNmevpCQoN4cZtuA==

            </SignatureValue>
            <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
               <ds:X509Data xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
                  <ds:X509Certificate xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
                   
MIIFSTCCBDGgAwIBAgIGb+MI39nZMA0GCSqGSIb3DQEBCwUAMIHGMQswCQYDVQQGEwJVUzEQMA4G
A1UECBMHQXJpem9uYTETMBEGA1UEBxMKU2NvdHRzZGFsZTElMCMGA1UEChMcU3RhcmZpZWxkIFRl
Y2hub2xvZ2llcywgSW5jLjEzMDEGA1UECxMqaHR0cDovL2NlcnRzLnN0YXJmaWVsZHRlY2guY29t
L3JlcG9zaXRvcnkvMTQwMgYDVQQDEytTdGFyZmllbGQgU2VjdXJlIENlcnRpZmljYXRlIEF1dGhv
cml0eSAtIEcyMB4XDTE0MDUwNjA5MDYwNVoXDTE1MDIyNjEyMDQwNFowOTEhMB8GA1UECxMYRG9t
YWluIENvbnRyb2wgVmFsaWRhdGVkMRQwEgYDVQQDEwtuYW1uZXRpcS5pbjCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMzjEinlOiwzMpKBQO+H2sb+HifrmVi7JDzhRfOKJakG+nXsgVx2
QRToN0UbvoeqlDtaTZSKrFb0mc/E3aEkgSU67DAzWvtm3nUSboJc4QVWQlJmXIP989K2H1DastwE
Srg6iw0MMUuz9ZadP3BQjV4VVB9qX81D32lD4Ti1gJYUDg5tpaUnftddiR+rZQROea3ABC0+oeZa
7w+jVFUOAP+uG2iJ4zksIO+F3wIXDNZMYQwFlTvnCTO6/4cRW1XoGxh0BbZGdYn0qHzAOu9okT2B
gnz+aTaMGSIPpPr+PXjB31XqeAhBRoXgrddWIt1DawyrJETPOrzfMhd1i+QSXHcCAwEAAaOCAccw
ggHDMAwGA1UdEwEB/wQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMA4GA1UdDwEB
/wQEAwIFoDA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLnN0YXJmaWVsZHRlY2guY29tL3Nm
aWcyczEtOC5jcmwwWQYDVR0gBFIwUDBOBgtghkgBhv1uAQcXATA/MD0GCCsGAQUFBwIBFjFodHRw
Oi8vY2VydGlmaWNhdGVzLnN0YXJmaWVsZHRlY2guY29tL3JlcG9zaXRvcnkvMIGCBggrBgEFBQcB
AQR2MHQwKgYIKwYBBQUHMAGGHmh0dHA6Ly9vY3NwLnN0YXJmaWVsZHRlY2guY29tLzBGBggrBgEF
BQcwAoY6aHR0cDovL2NlcnRpZmljYXRlcy5zdGFyZmllbGR0ZWNoLmNvbS9yZXBvc2l0b3J5L3Nm
aWcyLmNydDAfBgNVHSMEGDAWgBQlRYFoUCY4PTstLL7Natm2PbNmYzAnBgNVHREEIDAeggtuYW1u
ZXRpcS5pboIPd3d3Lm5hbW5ldGlxLmluMB0GA1UdDgQWBBQANClvlYFFU3cAkvFQz/TxuttEUTAN
BgkqhkiG9w0BAQsFAAOCAQEAySHcxqGpgrm9HSiSIFzDOdC9BraZdjh+fIUBeKRUBmSjSByPJIHj
OGuBnY8FtuPY8/e1KhzwhZcuUhY3zwVQzbWStWLraySJyO1SzRRJC4onLbx42ARdKbRgxA/JDsmY
aTnyYq+ZOLm6XUtDweFEDkklAy2sO8gru54ogJ0iD/JyX/dgZEH/v9lGjdNFUDwG4dLz++a2Ol/U
UfqJye7Rb5UgNkewcG9KjydiTgP7Mv6m8/JjzOl31ejIVVqwz30fo+agirrIWWG2Ogtk0JUFrY73
coKTzspPszxMGN2FJpRSymtO+cqVlEuAK6/SCr2mhBvxg4GJuXuzSLp2kSrIfA==

                  </ds:X509Certificate>
               </ds:X509Data>
            </ds:KeyInfo>
         </ds:Signature>
      </saml:Assertion>
   </wst:RequestedSecurityToken>