Okta AD Integration with Azure AD Domain Services

1. Introduction

This is a experimental article, using a existing Azure Active Directory (AD) and Azure Active Directory (AD) Domain Services deployment and integrating it with a Okta solution.

2. Preparation tasks

• Azure AD
  • Related Article – Getting started with Azure Active Directory Free Edition
• Azure AD Domain Services
  • Related Article – Azure AD Domain Services Quick Install
• Azure VM domain Joined to Azure AD Domain Services
• Okta Free 30 day trail
• Create a Service Account in Azure AD (Okta AD agent will run under this account)

3. Assumptions

The following assumptions are made in following this article:

• Windows 2012 R2 Member server of the  Azure AD Domain Services
• The member server has internet access
• Okta free trail without any modifications made

 

4. Installation

4.1 Create Service Account in Azure AD

1. Log into Azure AD, Go to Users and Click “ADD USER“
2.  In “Type of user“, Choose “New user  in your organization“
3. In “User Name”, Use company Service Account Name convention e.g. okta
4. 
5. In “First Name“, “Last Name” and “Display Name“, Enter Okta
6. In “Role”, Choose “User”
7. Create a temporary password, and document the password for next step.
8. Go to http://portal.office.com, Login as the new user and set the password.
9. The default password expiry is set on the account and should be disabled by using Azure AD PowerShell.

4.2 Okta AD Agent Install

Please follow theses steps for integrating Azure AD Domain services with Okta:

1. Log onto the Domain joined Server that will run the Okta Agent
2. Go to your okta administrator url e.g. https://<Company>-admin.okta.com/admin/dashboard
3. On the top navigation bar, go to Security, Authentication
4. 
5. Click “Configure Active Directory“
6. 
7. Click, “Set Up Active Directory“
8. 
9. Click, “Download Agent“
10. 
11. Once the agent is finished downloading, run the installation.
12. In the Welcome screen, Click “Next“
13. 
14. Choose the path for the installation and click “Install“
15. In The Domain field, enter company domain and click “Next” e.g. schmarr.com
16. Choose “Use an alternate account that I specify“
17. Enter username and password and click “Next“
18. At Okta AD agent Proxy Configuration, Click “Next“
19. At Register Okta AD Agent, Choose Production and in “Enter Subdomain” add company name.
20. Click “Next“
21. Sign in with your Okta Admin Account
22. Click “Allow Access“
23. Agent Installed, Click “Next”
24. As an Example choose the following in “Basic Setting“
25. 
26. Click “Next“
27. Click “Next“
28. In “Select the attributes to build your Okta User profile“, Click “Next“
29. Done
30. 

Conclusion

The ability to add SaaS applications in Azure AD and Okta, Azure AD being the Identity store for both.

Advertisement

Integrate SharePoint with Azure AD

1. Introduction

This article will show the quick configuration tasks, that are required to make Azure AD a trusted identity provider for a SharePoint 2013 installation.

2. Assumptions

The following assumptions are made during this article:

• General knowledge of the technologies discussed in this article
• A SharePoint 2013 instance is available
  • Related article: Quick install guide for SharePoint foundation 2013
• SharePoint Instance is using SSL
  • Related article: AD CS install guide for Azure AD Domain services
• A Azure AD instance is available
  • Related article: Getting started with Azure active directory free edition
• All tasks will be done from the SharePoint Server
• The SharePoint Server have unlimited internet access
• Permissions required:
  • securityadmin on the SQL instance
  • db_owner on the SQL instance
  • Administrators group on the server
  • Global Administrator for Azure AD
• In this example the following will be used in the article (Please change to reflect own implementation):
  • Namespace name: “Company”
  • SharePoint 2013 Url: “https://sharepoint.company.com&#8221;

3. Preparation

Before starting with the article the following needs to be in place:

• Azure AD PowerShell tools installed, look here for more details.

4. Configuration

The configuration will be broken into the following sections:

• Azure AD configuration
• SharePoint configuration
• Assigning Users

4.1 Azure AD Configuration

Follow these tasks to document the Azure AD WS-Federation metadata URL for later use:

1. In the Azure Management Portal (Classic), Click Active Directory.
2. Click on the Azure AD that will be integrated with SharePoint 2013
3. Click Applications
4. On the bottom bar, Click View Endpoints
5. Document the Federation metadata document url for later use

Follow these tasks to create / configure the namespace in Azure AD :

1. In the Azure Management Portal (Classic), Click Active Directory.
2. Click Access Control Namespaces, and create a new namespace and called it “Company”
3. Click Manage on the bottom bar. This should open https://company.accesscontrol.windows.net/v2/mgmt/web.
4. Click Identity Providers, Click Add
5. Click WS-Federation identity provider, click Next.
6. In Displayname enter, “Company”
7. In Login link Text enter, “Company”
8. In WS-Federation metadata, choose URL and enter the URL that was documented in tasks above Example: https://accounts.accesscontrol.windows.net/company.onmicrosoft.com/FederationMetadata/2007-06/FederationMetadata.xml
9. Click Save
10. Click Relying party applications, then click Add
11. Enter the following in each field:
    1. Name: “Company SharePoint”
    2. Realm: “urn:sharepoint:company”
    3. Token format: SAML 1.1
    4. Token lifetime (secs) default is 600: Recommended value is 2 hours
12. Click Save
13. Click Rule Groups, and then Add
14. Click Generate
15. Click Add
16. Fill in all the fields as illustrated below:
17. 
18. Click Save
19. Delete the existing claim rule named upn

Extract the X.509 certificate from Azure Access Control for later use

1. In the Access Control Service pane, under Development, click Application integration.
2. In Endpoint Reference, locate the Federation.xml that is associated with your Azure tenant, and then copy the location in the address bar of a browser.
3. In the Federation.xml file, locate the RoleDescriptor section, and copy the information from the <X509Certificate> element, as illustrated in the following figure.
4. 
5. from the root of drive C:\, create folder named Certs
6. Save the X509Certificate information using notepad to the folder C:\Certs and name the file ACS.cer
7. Run the following PowerShell commands:
   1. “Connect-MsolService”
   2. “Import-Module MSOnlineExtended -Force”
   3. $replyUrl = New-MsolServicePrincipalAddresses -Address “https://company.accesscontrol.windows.net&#8221;
   4. “New-MsolServicePrincipal -ServicePrincipalNames @(“https://company.accesscontrol.windows.net&#8221;) -DisplayName “Company ACS Namespace” -Addresses $replyUrl”

4.2 SharePoint 2013 Configuration

Follow these steps to configure Azure AD as the identity provider for SharePoint 2013:

1. From the Start menu, click All Programs.
2. Click Microsoft SharePoint 2013 Products.
3. Click SharePoint 2013 Management Shell
4. Run the following PowerShell commands:
   1. $root = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2(“C:\Certs\ACS.cer”)
   2. New-SPTrustedRootAuthority -Name “Token Signing Cert Parent” -Certificate $root
   3. $cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2(“C:\Certs\ACS.cer”)
   4. New-SPTrustedRootAuthority -Name “Token Signing Cert” -Certificate $cert
   5. $map1 = New-SPClaimTypeMapping -IncomingClaimType “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn&#8221; -IncomingClaimTypeDisplayName “UPN” -SameAsIncoming
   6. $map2 = New-SPClaimTypeMapping -IncomingClaimType “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname&#8221; -IncomingClaimTypeDisplayName “GivenName” -SameAsIncoming
   7. $map3 = New-SPClaimTypeMapping -IncomingClaimType “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname&#8221; -IncomingClaimTypeDisplayName “SurName” -SameAsIncoming
   8. $map4 = New-SPClaimTypeMapping -IncomingClaimType “http://schemas.microsoft.com/ws/2008/06/identity/claims/role&#8221; -IncomingClaimTypeDisplayName “Role” -SameAsIncoming
   9. $realm = “urn:sharepoint:company”
   10. $signInURL = “https://company.accesscontrol.windows.net/v2/wsfederation&#8221;
   11. $ap = New-SPTrustedIdentityTokenIssuer -Name “ACS Provider” -Description “SharePoint secured by SAML in ACS” -realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map1,$map2,$map3,$map4 -SignInUrl $signInURL -IdentifierClaim “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn&#8221;
5. Verify that the user account that is performing this procedure is a member of the Farm Administrators SharePoint group.

   In Central Administration, on the home page, click Application Management.

6. On the Application Management page, in the Web Applications section, click Manage web applications.
7. Click the appropriate web application.
8. From the ribbon, click Authentication Providers.
9. Under Zone, click the name of the zone. For example, Default.
10. On the Edit Authentication page, in the Claims Authentication Types section, select Trusted Identity provider, and then click the name of your provider, which for purposes of this article is ACS Provider. Click OK.
11. The following figure illustrates the Trusted Provider setting.

4.3 Assigning Users

Use the following steps to set the permissions to access the web application.

1. In Central Administration, on the home page, click Application Management.
2. On the Application Management page, in the Web Applications section, click Manage web applications.
3. Click the appropriate web application, and then click User Policy.
4. In Policy for Web Application, click Add Users.
5. In the Add Users dialog box, click the appropriate zone in Zones, and then click Next.
6. In the Add Users dialog box, type user2@company.onmicrosoft.com (ACS Provider).
7. In Permissions, click Full Control.
8. Click Finish, and then click OK.

Conclusion

Azure AD is the trusted identity provider for SharePoint 2013, and Azure AD users will be able to authenticate and use SharePoint 2013 resources.

External Links

Some good extra reading articles:

• Using Microsoft Azure Active Directory for SharePoint 2013 authentication
• Understanding WS-Federation
• List of Tutorials on How to Integrate SaaS Apps with Azure Active Directory