When you configure an Office 365 domain with WS-Trust protocol by using the wizard, the following two domains are created:
A domain preconfigured for active authentication using WS-Trust protocol
A domain preconfigured for passive authentication using WS-Federation protocol
To use the SAML 2.0-based domain, 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 explains how to configure a domain using WS-Trust and WS-Federation:
Ensure that WS-Trust and WS-Federation protocols are enabled in Access Manager:
Click Devices > Identity Servers > Edit.
In Enabled Protocols, ensure that WS-Trust and WS-Federation are selected.
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.
Click Devices > Identity Servers > Edit > WS-Trust > Service Provider Domain.
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 selected for WS-Trust. This method ensures that an email address/password is accepted for authentication.
Click the domain name to make further modifications. See Modifying Service Providers.
Select 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 the Attribute Set information and authentication response for the passive authentication.
NOTE:You have to check and confirm the assigned attribute set. Also, check the contract assigned in the WS-Fed domain as the default is assigned a non-secure form. If required, change to the Secure Name/Password form.
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.
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, go to Install the MSonline module.
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.
From the Start Menu launch Windows Azure Active Directory Module for Windows PowerShell.
Run $cred=Get-Credential and specify your cloud service administrator account credentials.
Ensure that you have the identity server certificate in the .cer format. Access Manager does not support the .ctr format.
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 in Base URL as it uses the default port 443. If you use a different port, specify the port in Base URL, such as 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"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.
Prerequisite:
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.
Go to Microsoft Online Services.
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>.
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 consists of the following tasks:
Adding the objectSid Attribute as a Custom Attribute
Creating Attribute Set
Configuring the Attribute Set for WS-Federation or WS-Trust
Click Devices > Identity Servers > Shared Settings > Custom Attributes.
Under LDAP Attribute Names, click New.
Specify objectSid, and select 64-bit Encode Attribute Data.
Click OK.
Click Attribute Sets.
Click New, and specify a Set Name. Click Next.
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 |
Click OK.
Create another Attribute Set. Click New, and specify a Set Name.
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 |
Click OK > Finish.
Configure the Attribute Set for the WS-Federation or WS-Trust service provider. See Configuring the Attributes Sent with Authentication and Modifying Service Providers.