Page1

How to Configure Office365 for Single Sign-on with NetScaler as SAML Identity Provider

   

Prerequisites: Office 365, NetScaler version: 10.5.53.9 (or higher)

Abstract: This article describes how to configure Office365 for Single Sign-on with NetScaler as SAML Identity Provider and this article also provides detailed steps to configure Windows Azure to use NetScaler as a Security Token Service (STS)/ Identity Provider (IDP).

1. Introduction:Microsoft Office 3651 provides secure anywhere access to professional email, shared calendars, instant messaging (IM), video conferencing, and document collaboration. It represents the cloud version of the Microsoft communication and collaboration products with the latest version of the Microsoft desktop suite for businesses of all sizes. Office 365 indeed includes:

• Microsoft Office: Microsoft Office Professional Plus 2010 seamlessly connectswith Microsoft Office Web Apps for a productivity experience across PCs, mobile devices, and browsers.

Note:

For additional information on Office 365 in addition to the content of this paper, refer to the Office online documentation2, the OFFICE 365 DEPLOYMENT GUIDE FORENTERPRISES 3 , the Office 365 Tech Center web site 4 , and the Office 365 Community web site (blogs, forums, wikis, etc.)5.

1 Microsoft Office 365: http://office365.microsoft.com/ 2 OFFICE 365 HELP: http://onlinehelp.microsoft.com/en-us/office365-enterprises/ 3 OFFICE 365 DEPLOYMENT GUIDE FOR ENTERPRISES: http://www.microsoft.com/download/en/details.aspx?id=26509

4 Office 365 Tech Center web site: http://technet.microsoft.com/en-us/office365/default 5 Office 365 Community web site: http://community.office365.com/en-us/default.aspx

Page 2

1.1. Objectives of this article: The first time you sign up for Microsoft Office 365, you are prompted to provide details about your organization and your organization’s Internet domain name registration. This information is then used to create a new tenant for your organization in Windows Azure Active Directory6 (Windows Azure AD).

Note:

You can create an organizational domain and user accounts using this page7 without the need to sign up for Office 365.

Windows Azure AD provides a cloud based store for directory data and a core set of identity services including user logon processes, authentication and federation services. Office 365 relies on these capabilities for the identity management of your subscription.

Note:

Microsoft offers various Office 365 plans which are intended for different types of organizations and need. One should note that not all of them support the single sign-on (SSO) feature. This feature is supported with all of the enterprise plans. In this article, the feature is illustrated through an E3 plan subscription.

Interestingly enough, organizations that subscribe to Office 365 can then use Windows Azure AD to configure SSO to allow interoperability with their existing on-premises identity management environment. This can be configured through either the Microsoft Online Portal (MOP) or the (preview of the) Windows Azure AD Management Portal8. By leveraging the SSO feature of the Windows Azure AD organization’s tenant, Office 365 in turn provides organizations with the ability to authenticate against the organization’s on-premises identity infrastructure (such as Active Directory or LDAP), allowing their users to use their corporate credentials to access their services in Office 365 that they have been provisioned for. When NetScaler is configured as an identity management solution, it can be configured for different authentication methods (like LDAP, RADIUS, Kerberos, Smartcard, 2-factor, and so on). NetScaler supports multi domain web SSO that means, if the Office 365 users are spanned across a domain forest then on NetScaler one can configure an LDAP policy with authentication pointing to a global catalog server. If the users are part of multiple domains then on NetScaler one has to configure multiple LDAP policies. To make SSO work directory synchronization is required.

6 WINDOWS AZURE ACTIVE DIRECTORY: http://technet.microsoft.com/en-us/library/hh967619.aspx

Page 3

1.2 Directory Synchronization: The implementation of directory synchronization is needed in order to keep the on-premises identities in sync with the organization’s Windows Azure AD tenant. One of the benefits is that it enables controlling and managing the corporate user account in the traditional way through the existing tooling that accompanies the on-premises identity infrastructure. This one feature really does provide seamless user management between the on-premises and Windows Azure AD environments. Organizations that use Active Directory, can easily implement this through the Microsoft Online Services Directory Synchronization Tool (DirSync) 9 . The DirSync tool enables service administrators maintaining Windows Azure AD, that is, Office 365, users, contacts, and groups updated with changes made in the on-premises Active Directory Domain Services (AD DS) for a single Active Directory forest. Multi-forest topologies will be supported with Windows Azure AD today for customers that meet certain prerequisites, allowing synchronizing from multiple forests, and, in the context of this article, supporting SSO with multiple AD forests. 2. A brief overview of NetScaler SAMLIDP: This section provides a brief overview of NetScaler SAML IDP implementation. NetScaler follows SAML2.0 standards. SAML standard is an XML-based standard for exchanging authentication and authorization data between security domains/realms, that is, between a Service Provider (SP), a consumer of (SAML) assertions and an Identity Provider (IdP), a producer of (SAML) assertions:

1. The SP provides (or does not provide) web resources depending on the trusted user attributes it received in the (SAML) assertions in order to feed it access control.

2. The IdP is in charge of authenticating users and providing attributes based on that authentication, which are vehicle in (SAML) assertions.

7 Windows Azure Active Directory Sign-up: http://g.microsoftonline.com/0AX00en/5 8 Preview of the Windows Azure AD Management Portal: https://activedirectory.windowsazure.com/

9 INSTALL AND UPGRADE THE MICROSOFT ONLINE SERVICES DIRECTORY SYNCHRONIZATION TOOL: http://onlinehelp.microsoft.com/en-us/office365-enterprises/ff652545.aspx

Page 4

2.1 A short introduction on SAML 2.0 standard: The OASIS SAML 2.0 standard is a suite of specifications and, as such, comprises a set of normative and non-normative documents:

• SAML V2.0 EXECUTIVE OVERVIEW10 (SAMLExecOvr);

• SECURITY ASSERTION MARKUP LANGUAGE (SAML) V2.0 TECHNICAL OVERVIEW 11 (SAMLTechOvw);

• ASSERTIONS AND PROTOCOLS FOR THE OASIS SECURITY ASSERTION MARKUP LANGUAGE (SAML) V2.012 (SAMLCore), the core specification.

SAML 2.0 defines XML-based assertions and protocols, bindings, and profiles. The term SAML Core, in relationship with the SAMLCore core specification, refers to the general syntax and semantics of SAML assertions as well as the protocol used to request and transmit those assertions from one system entity to another. SAML assertions are usually transferred from an IdP to a SP.

2.2 SAML2.0 bindings:

A SAML 2.0 binding determines how SAML requests and responses map onto standard messaging or communications protocols. In other words, it is a mapping of a SAML protocol message onto standard messaging formats and/or communications protocols.

NetScaler as an IDP supports HTTP-POST and HTTP-Redirect binding methods.

It does not support HTTP-Artifcat binding.

2.3 SAML2.0 Profiles:

A SAML 2.0 profile is a concrete manifestation of a defined use case using a particular combination of assertions, protocols, and bindings, assertions. Indeed, it describes in detail how SAML 2.0 assertions, protocols, and bindings combine to support the considered use case. The SAML 2.0 standard defines several profiles:

• Web Browser SSO profile;

• Artifact Resolution profile;

• Single Logout profile;

• Identity Provider Discovery profile;

10 SAML V2.0 EXECUTIVE OVERVIEW: http://www.oasis-open.org/committees/download.php/13525/sstc-saml-exec-overview-2.0-cd-01-2col.pdf 11 SECURITY ASSERTION MARKUP LANGUAGE (SAML) V2.0 TECHNICAL OVERVIEW: http://www.oasis-open.org/committees/download.php/27819/sstc-saml-tech-overview-2.0-cd-02.pdf

12 ASSERTIONS AND PROTOCOLS FOR THE OASIS SECURITY ASSERTION MARKUP LANGUAGE (SAML) V2.0: http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf

Page 5

• Enhanced Client or Proxy (ECP) profile and so on.

The most important one is certainly the Web Browser SSO profile since this is the primary SAML use case for Web SSO and federation. NetScaler supports Web Browser SSO profile and the remaining Artifact, Identity provider discovery and ECP are not supported as of now. In future, NetScaler will support SLO.

3. Use case 1: In the current article user will be accessing Office365 portal and will be redirected to NetScaler for User Authentication, and after the user authentication NetScaler will create a security token/SAML Assertion that can be consumed by the Office365 application for user SSO.

3.1 Federation Settings in Windows Azure AD: The following configuration is done using Windows Azure Active Directory module using Windows PowerShell. This section configures trust between Windows Azure AD and NetScaler. To make the following configurations, install Microsoft online services module for Windows PowerShell. Download the Microsoft Online Services Module (AdministrationConfig-en.msi) from the following URL: Microsoft Online Services Module for Windows PowerShell (64-bit version)13 and click Run to execute the setup the module.

Note:

For more information about single sign-on cmdlets, see the Microsoft TechNet articles USE WINDOWS POWERSHELL CMDLETS TO MANAGE YOUR WINDOWS AZURE AD TENANT 14 and WINDOWS POWERSHELL CMDLET DESCRIPTIONS15.

The following sections describe PowerShell commands. For more help on the PowerShell commands refer to Microsoft help document (http://msdn.microsoft.com/en-us/library/azure/jj151815.aspx).

13 Microsoft Online Services Module for Windows PowerShell (64-bit version): http://go.microsoft.com/fwlink/p/?linkid=236293 14 USE WINDOWS POWERSHELL CMDLETS TO MANAGE YOUR WINDOWS AZURE AD TENANT: http://technet.microsoft.com/en-us/library/jj151805 15 WINDOWS POWERSHELL CMDLET DESCRIPTIONS: http://technet.microsoft.com/en-us/library/jj151835.aspx

Page 6

In the following section adfsns.citrix.com refers to NS AAA vserver hostname. Step1: Connect-MSolService will ask for user credentials, provide Office365 Admin user credentials. PS C:\Windows\system32> Connect-MsolService Step2: After connecting to MsOnline service, create a new domain. Make sure that the domain name matches with existing public DNS record. PS C:\Windows\system32> New-MsolDomain –name adfsns.citrix.com Step3: Get the DNS record information to create for the new managed domain with the following command:

PS C:\Windows\system32> Get-MsolDomainVerificationDns –DomainName adfsns.citrix.com PS C:\Windows\system32> Confirm-MsolDomain –DomainName adfsns.citrix.com Step4: Provide a public certificate that will be used in SAML Signing. PS C:\Users\administrator.CTXNS\Desktop\Certificates> $cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("C:\NS-IDP-Cert.cer") PS C:\Users\administrator.CTXNS\Desktop\Certificates> $certData = [system.convert]::tobase64string($cert.rawdata) Step5: Create variables and assign domain name and federation brand name. Domain variable value should match with the domain created in Step2. PS C:\Users\administrator.CTXNS\Desktop\Certificates> $dom = "adfsns.citrix.com" PS C:\Users\administrator.CTXNS\Desktop\Certificates> $fedBrandName = "Citrix India" Step6: Provide the URL of SAML IDP, when NetScaler is acting as an IDP the URL will be /saml/login. In case of NetScaler Gateway acting as a SAML IDP then the URL will be https://nsgw.fqdn.com/saml/login In case of AAATM the SAML IDP URL will be https://aaavserver.fqdn.com/saml/login. PS C:\Users\administrator.CTXNS\Desktop\Certificates> $url = "https://adfsns.citrix.com/saml/login" PS C:\Users\administrator.CTXNS\Desktop\Certificates> $uri = https://adfsns.citrix.com/saml/login

Page 7

PS C:\Users\administrator.CTXNS\Desktop\Certificates> $ecpUrl = https://adfsns.citrix.com/saml/login Note: NetScaler does not support ECP Protocol, for the configuration purpose set it to the same URL. Step7: Set-MsolDomainAuthentication, this is the critical step to configure SAML Authentication in Office365 deployment. In the following configuration, logoffURI is configured to /saml/login. In future when the SLO support is available for NetScaler IDP this URL might be changed. PS C:\Users\administrator.CTXNS\Desktop\Certificates> Set-MsolDomainAuthentication -DomainName $dom -federationBrandName $fedBrandName -Authentication Federated -PassiveLogOnUri $url -SigningCertificate $certData -IssuerUri $uri -ActiveLogOnUri $ecpUrl -LogOffUri $url –PreferredAuthenticationProtocol SAMLP Step8: Convert the Domain to Federated. PS C:\Users\administrator.CTXNS\Desktop\Certificates> Convert-MsolDomainToFederated -DomainName adfsns.citrix.com Successfully updated 'adfsns.citrix.com' domain. Verify the federation settings by using command Get-MsolDomainFederationSettings and Get-MsolFederationProperty. PS C:\Users\administrator.CTXNS\Desktop\Certificates> Get-MsolDomainFederationSettings cmdlet Get-MsolDomainFederationSettings at command pipeline position 1 Supply values for the following parameters: DomainName: adfsns.citrix.com ActiveLogOnUri : https://adfsns.citrix.com/saml/login FederationBrandName : Citrix India IssuerUri : https://adfsns.citrix.com/saml/login LogOffUri : https://adfsns.citrix.com/saml/login MetadataExchangeUri : https://adfsns.citrix.com/adfs/services/trust/mex NextSigningCertificate: PassiveLogOnUri : https://adfsns.citrix.com/saml/login SigningCertificate : <SigningCertificate> PS C:\Users\administrator.CTXNS\Desktop\Certificates> Get-MsolFederationProperty cmdlet Get-MsolFederationProperty at command pipeline position 1

Page 8

Supply values for the following parameters: DomainName : adfsns.citrix.com Source : Microsoft Office 365 ActiveClientSignInUrl : https://adfsns.citrix.com/saml/login FederationServiceDisplayName : Citrix India FederationServiceIdentifier : https://adfsns.citrix.com/saml/login FederationMetadataUrl : https://adfsns.citrix.com/adfs/services/trust/mex PassiveClientSignInUrl : https://adfsns.citrix.com/saml/login PassiveClientSignOutUrl : https://adfsns.citrix.com/saml/login TokenSigningCertificate : [Subject]

CN=ADFSNS.Citrix.com, OU=NetScaler, O=Citrix Systems Inc., L=Bengaluru, S=Karnataka, C=IN [Issuer] CN=Cybertrust Public SureServer SV CA, O=Cybertrust Inc [Serial Number] 0200000000014527F8D31D21CF2E [Not Before] 4/3/2014 7:53:11 PM [Not After] 4/3/2015 7:53:11 PM [Thumbprint] D10EFA082E9EA155A2D7BDEE978E631A5551A618

NextTokenSigningCertificate : PreferredAuthenticationProtocol :Samlp 3.2 Setting up Directory Synchronization: At this stage, you should normally setup the directory synchronization.

Note:

Directory synchronization is not further discussed in this article. For details pertaining to this topic, please refer to CONFIGURE DIRECTORY SYNCHRONIZATION 16 in the Windows Azure AD online documentation.

16 CONFIGURE DIRECTORY SYNCHRONIZATION: http://technet.microsoft.com/en-us/library/hh967629.aspx

Page 9

You can use Windows PowerShell commands to provision a user. This approach is not suitable for a production environment. Provisioning and synchronization are indeed not the same. While with provisioning, you simply create objects and/or associated resources in a directory or external system, here Windows Azure AD, the synchronization integrates the provisioning part but also enables to manage the long-term consistency/parity of state between source objects and their representation in the external system. For the sole purpose of an illustration in this article, you can create new Windows Azure AD federated users from the Microsoft Online Services Module for Windows PowerShell. To create a federated user, proceed with the following steps:

1. Connect-MSolService will ask for user credentials, provide Office365 Admin user credentials.

C:\Windows\system32> Connect-MsolService

2. Run the following command to obtain the unique string ID of the account/SKU combination that will be needed to assign a license, for example “idmgt14:ENTERPRISEPACK” in our configuration.

PS C:\Windows\system32> Get-MsolAccountSku

Page 10

3. Create the user with the following command:

PS C:\Windows\system32> New-MsolUser -DisplayName user1 –UserPrincipalName user1@shib.idmgt.archims.fr -UsageLocation FR -BlockCredential $false –ImmutableId 81372

4. Set the user’s license with the following command:

PS: C:\Windows\system32> Set-MsolUserLicense -UserPrincipalName user1@shib.idmgt.archims.fr -AddLicenses "idmgt14:ENTERPRISEPACK"

3.3 NetScaler Configuration:

Pre-Configuration Tasks: 3.3.1 Ensuring IP connectivity: Verify the connectivity from client to NetScaler, make sure that client can reach NetScaler AAA/ NetScaler Gateway vserver. Verify the connectivity from NetScaler to LDAP or KDC (in case of Kerberos authentication.) 3.3.2 Configuring Name resolution: Verify that the client can resolve AAA/ NetScaler Gateway vserver successfully. In case, if the NetScaler is configured for a LDAP server with hostname, make sure that resolution is successful. In case, NetScaler is in DMZ zone, make sure to open 389/636 (Plaintext/TLS/SSL) or 3268/3269 (global catalogue server) in internal DMZ. 3.3.3 Verifying Clock synchronization:

Page 11

Ensure that NetScaler and Office365 are in time sync. Time zones might vary but make sure that UTC times match on both ends. 3.3.4 Sending User attributes: As part of the federation, Windows Azure expects NetScaler to send two user attributes.

a) ImmutableID: Windows Azure AD requires you to select a unique identifier for each user in your user directory. You must also configure NetScaler to send this attribute on each federated login to Windows Azure AD in the SAML 2.0 NameID assertion. This identifier must not change for this user over the lifetime of the user being in your system. The Windows Azure AD Service calls this attribute the ImmutableID. The value for the unique identifier must not contain domain information and is case-sensitive. For example, do not use user@domain.com. Typically this Immutable ID can be set to ObjectGUID.

i. When creating accounts, you must ensure the ImmutableID is processed the same way or the user will not be able to logon to the Microsoft Cloud services. For instance, with Active Directory, the DirSync tool automatically uses the Active Directory objectGUID for the ImmutableID value and processes the ImmutableID the same way. We mimic here the approach.

b) UserID: Windows Azure AD requires that the user ID should be sent in the SAML assertion. For example, user@shib.idmgt.archims.fr, is sent. With Active Directory, the value is stored in the LDAP UserPrincipalName attribute. With AD LDS, we will use instead the mail attribute that we’ve provisioned earlier with the user e-mail address.

The following section describes how to configure NetScaler as SAML Identity Provider and enable form based authentication against an LDAP/Active Directory server.

1. Load NetScaler with 10.5.53.9 or higher version. 2. Create an authentication vserver <av1>, and bind SSL server certificate and CA

certificate to bring up the virtual server. 3. Create an LDAP/AD Action as specified below.

add authentication ldapAction ldap1 -serverIP 1.2.3.4 -ldapBase "cn=users,dc=ctxns,dc=com" -ldapBindDn "cn=Administrator,cn=users,dc=ctxsns,dc=com" -ldapBindDnPassword Password -ldapLoginName UserPrincipalName -ssoNameAttribute objectGUID -attribute1 mail

Page 12

add authentication ldapPolicy ldap1 ns_True ldap1

4. Bind the LDAP Policy to authentication vserver. bind authentication vserver av1 –policy ldap1

5. Before creating SAMLIDP Profile, please get the certificate and private key that are used at Federation configuration and create an SSL certkey out of it and use it in the SAMLIDP configuration as shown below. add ssl certkey adfsns-cert –cert /nsconfig/ssl/adfs-ns.cer

Note: Make sure that the same certificate is configured in Windows Azure configuration Step 3. 6. Create SAML IDP Profile and bind that policy to NetScaler Authentication vserver.

add authentication samlIdPProfile NSIDP -samlSPCertName adfsns-cert -samlIdPCertName adfsns-cert -assertionConsumerServiceURL "https://login.microsoftonline.com/login.srf" -samlIssuerName "https://adfsns.citrix.com/saml/login" -rejectUnsignedRequests OFF -audience urn:federation:MicrosoftOnline -NameIDExpr http.req.user.name.b64encode -Attribute1 IDPEmail -Attribute1Expr "http.req.user.attribute(1)" -Attribute1FriendlyName UserID -Attribute1Format URI

In the preceding command, “samlIssuerName”represents a unique string that identifies NetScaler’s identity at Office365 for federation. SAMLSPCertName is the certificate entity used to verify AuthnRequests from Office365. SAMLIDPCertName represents certificate entity to sign assertion that is sent by NetScaler to Office365. The preceding command also has definitions for attributes that get sent with the assertion. add authentication samlIdPPolicy NSIDP -rule true -action NSIDP bind authentication vserver av1 –poliy NSIDP –pr 10

Use Case2: The following section describes how to configure NetScaler as SAML Identity Provider and enabled for Kerberos authentication. This deployment mode will work when the client is part of the domain and it can reach the domain controller to acquire a Kerberos token. In this use-case, user is authenticated based on the Kerberos token and then LDAP authentication is configured to obtain user properties such as email and ObjectGUID. In this use case, for Windows Azure AD configurations follow the steps that are explained in sections 3.1 and 3.2

1. Load NetScaler with 10.5.53.x or higher version. 2. Create an authentication vserver <av1> and bind ssl certkey and CA certificate to

bring up the vserver. 3. Create a Negotiate Action and Policy.

Page 13

add authentication negotiateAction neg1 –domain CTXNS.COM –domainUser Service_Account –domainUserPasswd Password.

add authentication negotiatePolicy neg1 ns_true neg1 4. Create an LDAP Policy with authentication disabled for LDAP attribute extraction.

add authentication ldapAction ldap1 –serverIP 1.2.3.4 –ldapBase “cn=users,dc=ctxns,dc=com” –ldapBindDn “cn=Administrator,cn=users,dc=ctxns,dc=com” –ldapBindDnPassword Password –ldapLoginName UserPrincipalName –ssoNameAttribute objectGUID –authentication disabled –attribute1 mail

add authentication ldapPolicy ldap1 ns_True ldap1 5. Bind the LDAP Policy to authentication vserver. Second factor is configured with

authentication disabled to get user AD properties like ObjectGUID and email. bind authentication vserver av1 –policy neg1 bind authentication vserver av1 –policy ldap1 –secondary

Before creating SAMLIDP Profile, get the certificate and private key that are used at Federation configuration and create a SSL certkey out of it and use it in the SAMLIDP configuration as shown in the following step. 6. Create SAML IDP Profile and bind that policy to NetScaler Authentication vserver.

add authentication samlIdPProfile NSIDP -samlSPCertName adfsns-cert -samlIdPCertName adfsns-cert -assertionConsumerServiceURL "https://login.microsoftonline.com/login.srf" -samlIssuerName "https://adfsns.citrix.com/saml/login" -rejectUnsignedRequests OFF -audience urn:federation:MicrosoftOnline -NameIDExpr http.req.user.name.b64encode -Attribute1 IDPEmail -Attribute1Expr "http.req.user.attribute(1)" -Attribute1FriendlyName UserID -Attribute1Format URI

add authentication samlIdPPolicy NSIDP -rule true -action NSIDP bind authentication vserver av1 –poliy NSIDP –pr 10

Troubleshooting: Sample SAML Request sent by Office365: <samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="_9e1ba0a7-058c-4c7a-a53a-9067ce312825" IssueInstant="2014-09-05T23:00:13Z" 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> Sample SAML Response sent by Office365: In the preceding snippet, user’s attributes sent by NetScaler are highlighted for

Page 14

reference. Users attribute that are sent to Office365 are ObjectGUID (immutable id) and E-mail ID (UserID). <samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" Destination="https://login.microsoftonline.com/login.srf" ID="_83b7987327d0791cf8f874cf8c880be9" InResponseTo="_ed0055bd-7e5f-4ece-bff2-6fb694bfb98a" IssueInstant="2014-10-05T20:02:04Z" Version="2.0"><saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">https://adfsns.citrix.com/saml/login</saml:Issuer><samlp:Status><samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"></samlp:StatusCode></samlp:Status><saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="_83b7987327d0791cf8f874cf8c880be" IssueInstant="2014-10-05T20:02:04Z" Version="2.0"><saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">https://adfsns.citrix.com/saml/login</saml:Issuer><ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:SignedInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"></ds:CanonicalizationMethod><ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"></ds:SignatureMethod><ds:Reference URI="#_83b7987327d0791cf8f874cf8c880be"><ds:Transforms><ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"></ds:Transform><ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"></ds:Transform></ds:Transforms><ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"></ds:DigestMethod><ds:DigestValue>5QIAxKtoDbE2oN1cI2McEzMBRgY=</ds:DigestValue></ds:Reference></ds:SignedInfo><ds:SignatureValue>cK3YvxmemlnYC7uC+I0/RqdFDngJMfZqYo8MoZCYdx8a2yuTNHXqoAeaW6JbA7jzXiYcSUFlNgg5E4UHkJ+GVAcfKXNfiTVyP+a8sE5KpdzCOkVKl0WOQYzy+wzT4PhL7WJ8CtkULVmFmUBjgpkNT8SfZSJQCypUs8eZBNgZPdo7uNh2yj1TNdbF8zBCkIIuA4dNRptx2PK1BLKGDCXbWCXAWXZj38ZqOm56ge+/W2yE3bSujj+z4WVLkYgbKFyFu96Rhxe+fE777Yi6rAZrj91TrVkHyAQmyWZ666DHIO8yKFf5zYfkVY3yV4AcCrasA94lfx/G3zpM66zAto41bg==</ds:SignatureValue><ds:KeyInfo><ds:X509Data><ds:X509Certificate>Signing_Certificate</ds:X509Certificate></ds:X509Data></ds:KeyInfo></ds:Signature><saml:Subject><saml:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">DfTBHEaKVkmo2UHknHauug==</saml:NameID><saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"><saml:SubjectConfirmationData InResponseTo="_ed0055bd-7e5f-4ece-bff2-6fb694bfb98a" NotOnOrAfter="2014-10-05T20:07:04Z" Recipient="https://login.microsoftonline.com/login.srf"></saml:SubjectConfirmationDat

Page 15

a></saml:SubjectConfirmation></saml:Subject><saml:Conditions NotBefore="2014-10-05T19:57:04Z" NotOnOrAfter="2014-10-05T20:07:04Z"><saml:AudienceRestriction><saml:Audience>urn:federation:MicrosoftOnline</saml:Audience></saml:AudienceRestriction></saml:Conditions><saml:AuthnStatement AuthnInstant="2014-10-05T20:02:04Z" SessionIndex="586ae8e8310d222bf766c9637fe32b05"><saml:AuthnContext><saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml:AuthnContextClassRef></saml:AuthnContext></saml:AuthnStatement><saml:AttributeStatement><saml:Attribute FriendlyName="UserID" Name="IDPEmail" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"><saml:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">u1test@adfsns.citrix.com</saml:AttributeValue></saml:Attribute></saml:AttributeStatement></saml:Assertion></samlp:Response>

• To troubleshoot the integration problems install Windows connectivity analyzer tool to isolate the issue. (web link to download: https://testconnectivity.microsoft.com/)

• NetScaler specific logs. • NetScaler specific counters. • Error: 800478A2 • Reference link for SAML implementation: http://technet.microsoft.com/en-

us/library/dn641269.aspx • Office365 error codes: http://support.microsoft.com/kb/2615736

Page 16