I recently set this up for a client and was very impressed with the results. I’m guessing that the reason you are reading this is for assistance with your own Okta deployment but I’ll give you a quick overview of what it is all about anyway.
Okta SSO
In a nutshell Okta allows your users to sign in to their machines one single time using their Active Directory credentials and are then automatically authenticated to any other sites/applications configured within Okta.
For Example I might want everyone on the network team to be able to login in our Cisco Meraki site but do not want them to have a separate set of credentials for this. Using Okta all I have to do is add the Cisco Meraki application, integrate it with Okta and then assign it to the users that I have imported from Active Directory. Its that simple, and works very well.
I have spent some time getting to know the system and setting it up for a clients Office 365 environment. Below is how to set everything up step-by-step.
Install and Configure the Okta Active Directory Agent
1. Download the agent by logging in to the console going to Admin
2. Select Directory > Directory Integrations.
3. Click Add Directory and then select Add Active Directory.
4. Click Set Up Active Directory.
5. Click Download Agent.
6. Double click the file to launch the installer.
7. Click Yes at the message Do you want to allow the following program to make changes to this computer?.
8. Choose an installation destination.
9. Select the AD domain you want to manage with this agent.
10. Select Create or use the Okta Service account (recommended) and complete the prompt to set a password.
11. Note: Select Use an alternate account that I specify if you want to assign the Okta AD Agent to run as an existing domain user.
12. (Optional) If appropriate for your environment, specify a proxy server through which your AD agent will connect.
13. To register the AD Agent with the Okta service, enter your Okta subdomain name, and then click Next.
14. Enter the username and a password, and then click Sign in. (It says service account but use an Okta super admin account here)
15. Click Allow Access.
16. Note: If the error message displays The underlying connection was closed. Could not establish trust relationship for the SSL/TLS service channel, see Troubleshooting.
17. Click Finish.
18. When the Active Directory agent has started, click Next.
19. (First time installations for this domain only) At the Connect an Organization Unit to Okta screen, select the OUs from which you want to import users and groups. You can change these and other settings at any time.
20. Select the Okta Username format as email address. (These should all be correct in the Domain Active Directory but we should check).
21. Click Next.
22. In the Build User Profile tab, select the attributes that you want to use to build your Okta user profiles.
23. Click Next.
24. When the initial Active Directory agent configuration is complete, click Next.
25. Click Done.
Configuring Directory Integrations
1. Click Directory> Directory Integrations> Active Directory> Settings
2. Change the Schedule Import option to Every Hour.
3. Tick the box that states Auto-activate after confirmation
4. Click Save Settings.
5. Scroll down to Attribute Mappings and click edit mappings
6. Change the appuser.email field to map to the login field and click Save Mappings.
Running a full import
1. To run a full import click Directory> Directory Integrations> Import
2. Click Import now> Select a Full Import
3. Users will be imported
Adding users from AD to Okta
1. Users should now appear as below. Notice the icon denoting the username from the (left) Imported User Column. This accurately states test.martin@domain.local. Then Notice how the username will change in the Okta User Assignment column. The username will become the users email address.
2. Select the user and click confirm assignments
Configure Office 365
1. Make sure the machine you are using has both the Microsoft Online Services Sign-In Assistant and the Windows Azure AD Module for PowerShell (I had to install this using msiexec /i AdministrationConfig-EN.msi) installed before beginning. To do this you need to check Windows PowerShell V2.0 in Add/Remove Windows features and install .net 3.5.
2. Login to Okta and select Applications> Add Application
3. In the search dialog, type in Office 365 and then click the Add button.
4. Enter the tenant name and the company domain as below and click Next.
5. Change the Sign On Method to WS-Federation and then click View Setup Instructions
6. Click view setup instructions and copy the text from the section that relates to the domain not being federated.
7. Open a PowerShell Window as an administrator and run the below lines of code:
$UserCredential = Get-Credential
*You will be asked to enter your Office 365 Admin details here*
Connect-MsolService -Credential $UserCredential
*Now paste in the code that you copied from step 6*
If you get any errors, contact Okta support immediately.
Check the command worked by running:
Get-MSolDomain
You should see that the domain is federated as below:
8. Leave the Application username format as Okta username and then click Next. We could have chosen Let Okta configure WS-Federation automatically for me at this point. I chose not to for a few reasons a) this requires the API to be working and is an added complication b) I can see any errors quite clearly in the PowerShell window.
9. Click Next
10. Click Next
11. Click Done
Provisioning in Office 365
1. Login to Okta and go to Applications> Provisioning
2. Click Edit> Enable provisioning features.
3. Enter admin credentials for Office 365 and click test API credentials
4. Leave as Profile Sync *beware if you do change this option you cannot change it back!*
5. Change the User Import schedule to every hour
6. Click Save
Importing users from Office 365 in to Okta
1. Click Applications> Office 365> Import
2. Click Import Now
3. The list of imported users should look something like the below. What we are aiming for is as many Exact Matches as possible.
4. We will use the test.martin@testdomain.co.uk as our example for connecting and Office 365 user to Okta.
5. Select the User you want to link from Okta to Office 365 and click Confirm Assignments
6. The user should now be able to select the relevant Office 365 application once logged in to Okta. Once selected they will then be logged in automatically.
You should see the Okta redirect after selecting an application.
The application is then loaded.
Configuring Desktop Single Sign-On
1. From your Administrator Dashboard, go to Security > Authentication > Active Directory.
2. In the Desktop Single Sign-On section, click the Domainload the Desktop SSO installer link.
3. Double-click the installation file OktaSsoIwa-x.x.x.
4. Click Run.
5. Click Next.
6. At the Web Application Pool Identity dialog box, select Create or use the OktaService account, then click Next.
7. On the Register Okta Desktop Single Sign-On screen, select an environment (Production, Preview, or Custom), enter your Okta customer subdomain name, and then click Next.
8. On the Okta Sign In page, enter the username and password, and then click Sign In.
9. To grant permission to access the Okta API, click Allow Access.
10. At the message Installation completed, click Finish.
11. Return to your browser and reload the Security > Authentication > Active Directory page.
12. We now need to add the FQDN of the server running the IWA to the local intranet zone for all computers. The best way to do this is to edit the Default Domain GPO as follows:
User Configuration>Policies>Administrative Templates>Windows Components>Internet Explorer/Internet Control Panel/Security Page/Site to Zone Assignment List
Then add the FQDN of the server i.e. domaindc11.domaincf.local and set the value to 1 (For Intranet).
13. Google Chrome requires a whitelist to be configured to allow Integrated Windows Authentication. We can configure this in group policy by doing the following:
User Configuration>Policies>Administrative Templates>Google>Policies for HTTP authentication>Authentication server Whitelist then add an entry for the FQDN of the server.
Check that the authentication is working on a desktop machine by opening the Okta console and going to Security>Authentication>Active Directory>Scroll domain to Integrated Windows Authentication and copy the IWA redirect URL. You need to add authenticated.aspx to the end of this text.
So on the client machine you will be pasting http://DOMAINDC11/IWA/Authenticated.aspx
You should see the below:
14. Once you have tested and it is working ok return to the SSO settings in Okta and select On. Then click Save.
Whitelisting the Public IPs used for SSO
1. When I first configured SSO everything seemed to be working except for the redirection. This is because the client machine I was testing from was routing via the Bluecoat proxy.
2. To check the IPs users are connecting in under go to Reports>System Log and expand the ‘User login to Okta’
3. Click Expand All and you should see the IPs that are trying to connect in to Okta.
4. In our case, we can see the IP is 149.5.x.x which relates to our proxy service Bluecoat:
5. In order to allow users originating from these IPs to use the IWA desktop single sign on service we need to whitelist these IPs. To do this go to Security>Network>Edit
6. Now add the new IP or IP range as a new line and click save:
7. In reality opening up such a large range belonging to a proxy service provider is a big security risk. So, in this instance it is better to force the Bluecoat system to bypass the Okta IPs used.
8. To do this login to the Bluecoat system and bypass the following sites:
domain.oktapreview.com
login.okta.com
domain-admin.oktapreview.com
Configuring SSL for the IWA
1. We first need to make a number of registry edits as we are running a Windows 2008 R2 Server:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client\DisabledByDefault : 0 (DWORD)
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client\Enabled : 1 (DWORD)
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server\DisabledByDefault : 0 (DWORD)
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server\Enabled : 1 (DWORD)
Okta’s explanation for this is:
If your IWA Web App is installed on a server running Windows Server 2008 R2 SP1 and you want to use SSO IWA over secured connections (HTTPS), you must first enable the TLS 1.2 protocol for incoming (e.g. IIS) connections. This is necessary because the AD agent, which tries to use TLS 1.2 whenever possible, may lose connectivity with IWA Web Apps installed on Windows Server 2008 R2 SP1 servers that are not enabled for TLS 1.2 incoming connections. Windows Server 2008 R2 SP1 supports TLS 1.2 protocol outgoing connections by default. However, support for incoming connections is disabled by default.
2. On the same server that hosts your Okta IWA Web App, open Internet Information Services (IIS) Manager and select the server under Connections.
3. In the center pane of the IIS Manager, double-click the Server Certificates icon.
4. Under Actions (on the right side), click Create Domain Certificate.
5. Enter information in the Distinguished Name Properties dialog box, and then click Next.
6. In the Online Certification Authority dialog box, do the following:
Click Select, select a certificate authority, and then click OK
Enter a name in the Friendly name field, and then click Finish.
7. Under Connections, expand Sites, and then select Default Web Site.
8. Under Actions, click Bindings.
9. In the Site Bindings dialog box, click Add.
In the Add Site Binding dialog box, do the following:
Select https in the Type drop-domain menu.
In the SSL certificate menu, select the friendly name that you specified previously.
Click OK.
10. Close the Site Bindings dialog box.
11. Under Connections, expand Sites > Default Web Site, and then select IWA.
12. In the center pane of the IIS Manager, double-click the SSL Settings icon.
13. On the SSL Settings page, select Require SSL. You can leave the Client certificates option as Ignore.
14. Under Actions, click Apply.
15. Log in to your Okta org and go to Security > Authentication > Active Directory.
16. Scroll domain to Desktop Single Sign On and click Edit.
17. In the Integrated Web Authentication (IWA) Web Applications section, click the domain arrow to expand the section.
18. Change the IWA redirect URL from http to https.
19. Click Save.
20. Test the configuration as described in Testing Your IWA Web App.
21. This process worked ok but as we used IIS to create the CSR it did not let us add any additional alternative SAN names. So domaindc11.domaincf.local is ok but domaindc11 is not. To get around this we should manually create a domain certificate for domaindc11 with the relevant DNS names added.
Configuring Multifactor Authentication
1. From the dashboard go to Security>Authentication
2. Click the Multifactor tab
3. Under Factor Type click Edit
4. Click Okta Verify and click Save.
5. We now need to set a policy to force users to enroll for MFA. Go to Security> Policies> Okta Sign-On and click Add New Okta Sign-On Policy.
6. Name the policy and give it a description. Then choose a group to assign it to and click Add. Click Create Policy and Add Rule.
7. The rule creation wizard appears, name the rule and tick the box for Prompt for Factor.
8. When the user next logs in they are prompted to setup MFA. This entails the user domainloading the Okta verify app, scanning the code and verifying.
Plan to switch over from Microsoft MFA to Okta Verify MFA
1. Inform user that we are about to change their authentication method and that if they restart their Outlook/ActiveSync session they will not be able to login – temporarily.
2. Disable users Microsoft MFA
3. The account on their phones and Outlook should continue working. If it stops working user will be able to login to Outlook using their Office 365 password.
4. Enable Octa verify as outlined above and instruct user to login to Octa and complete the enrollment process using their phone.
5. Ask user to bring phone in so that we can update their password to their Office 365 password. (Unless they are happy to do this themselves).
6. Update users Outlook to use their Office 365 password.
7. Next time user logs in to Office 365 they will be redirected to Octa which will force them to use MFA.
Modern Authentication & Okta MFA
1. If we want to use MFA with applications that support modern authentication we need to first enable it in Exchange Online.
Connect to Exchange online in the usual way:
$UserCredential = Get-Credential
2.
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $UserCredential -Authentication Basic -AllowRedirection
3.
Import-PSSession $Session
4. Verify the current state of the authentication method:
Get-OrganizationConfig | Format-Table -Auto Name,OAuth*
5. Enable modern authentication:
Set-OrganizationConfig -OAuth2ClientProfileEnabled $true
Users will now be prompted for their MFA login details when opening Outlook.
How will the experience change for users?
Office based users
- Whilst in the Office users will benefit from true SSO and once logged in to their machines using their Active Directory credentials they will also be authenticated in Okta.
- Typical user behavior would be to login to Windows then to open Chrome and go to the Office 365 login. In this instance they would then be automatically redirected to Okta which then signs them in.
- Alternatively a user can go to their Okta dashboard and see all applications for which they have SSO enabled. To login to an application the user simply selects it from the list.
- Unless we enable modern authentication Outlook 2016 users will not be prompted for MFA. Users should use their Office 365 credentials to login to Outlook.
- ActiveSync users should use their Office 365 credentials to login to their mailboxes from mobile devices.
External Users
- Users outside of the office will not be able to experience true SSO as they will not be able to reach the SSO server.
- Typical user behavior for external users will be to open Chrome and go to Office 365 to login. They will then be redirected to Okta. At this stage they will have to login with their Okta credentials (same as their Active Directory login).
- Outlook and ActiveSync behavior is the same for internal and external users.
Removing the Okta federation from Office 365
1. Turn off the Desktop SSO mode by going to Security>Authentication.
2. Click Edit under Desktop Single Sign-On, click Off and then save.
3. Open the Okta admin console and click Applications>Applications. Change the application status to Deactivate.
4. You will get a warning stating that assigned users may be deprovisioned. This is fine as we have provisioning disabled for removing Office 365 users.
5. Click Deactivate Application, then Delete Application
6. Click Inactive and then change the drop domain to delete (this will remove the entire Office 365 setup from Okta).
7. You now need to wait up to an hour before this takes effect in Office 365. At this point you should be able to login to Office 365 normally using your username and password. You may see the below image in which case you just need to wait a while longer.
8. The domain has however become defederated:
9. Run the below command and then enter your credentials:
$UserCredential = Get-Credential
10. Run the below command to connect to your Office 365 environment using these credentials
Connect-MsolService -Credential $UserCredential
11. Run the below command to check the current state of the environment:
Get-MsolDomain
12. Run the below command to remove the federated domain and set it back to being managed by Office 365 again.
Set-MsolDomainAuthentication -Authentication Managed -DomainName testdomain.co.uk
13. If there are issues with any users and they keep trying to redirect back to Okta run the below command on the user account:
Convert-MsolFederatedUser -userprincipalname test.martin@testdomain.co.uk
References
1. https://help.okta.com/en/prod/Content/Topics/Directory/Okta%20Active%20Directory%20Agent.htm
2. https://support.okta.com/help/Documentation/Knowledge_Article/Office365-Deployment-Guide
6. https://help.okta.com/en/prod/Content/Topics/Security/MFA.htm
7. https://help.okta.com/en/prod/Content/Topics/Security/MFA_App_Level.htm
