Okta provides cloud software that helps companies manage and secure user authentication into applications, and for developers to build identity controls into applications, website web services and devices (see wiki). See this great introductory video too.
The purpose of this article is to detail my experience in getting started with the Okta (Identity Engine or OIE). I detail the various tasks to enable a new trial Okta tenant and integrate this with an on-premises Active Directory and a Salesforce account. In upcoming articles, I plan to detail how to enable new Okta services such as Fast Pass and also integrate Okta with EMM solutions such as Workspace ONE UEM and Access.
Getting Started
First go to www.okta.com/free-trial/ to start a 30 day free trial. You an import up to 10,000 users from your AD as part of your trial, but you can only activate up to 100 of them.
After starting my Okta trial, I was presented with the new Okta dashboard. I thought this was a nice overview vs previous Okta tenants and the Tasks and Security Monitoring dashboards provide a nice summary of key indicators for an identity administrator.
Creating additional accounts
I wanted to create another administrator account and also understand the user experience when a new account is provisioned. So Navigate to Directory > People and click Add Person. Enter the required information as follows. I selected the checkbox so the user would enter their password. This is easier than Azure AD where you don’t have an admin option to specify the password.
Click Save.
My user received the following welcome email:
Now click Active Okta Account and enter an appropriate password. Then click Next. You then have the option to setup additional security methods such as Okta Verify or Phone. The user is then presented with their Okta portal and welcome page.
Creating administrators
To elevate particular user accounts to Okta administrators, navigate to Security > Administrators and in the Admin field, select required user (in my case I had only one).
I selected the role Super Administrator and then select Save Changes.
At the bottom of this window, Okta shows all administrator activity summarised in once place.
The user will now be show an Admin button in their Okta portal, to easily switch to the admin console.
Importing users from a CSV file
Okta also has the ability to import users from a CSV file. This is available by navigating to Directory > People and selecting More actions > Import users from CSV.
I downloaded the example CSV and created an Okta test user (for a user I already had defined in Azure AD). The various screens to import users is detailed here:
Integrating Active Directory
So setting up users manually or via CSV is very easy, but most organisations have an on-premises Active Directory. This section details how to easily setup this up within Okta.
- Navigate to Directory > Directory Integrations and select Active Directory as shown:
2. Review the helpful installation requirements page and click Set Up Active Directory. Select Download Agent as shown:
3. Some useful information will be presented to you, which you’ll need below:
4. Copy the small Okta Active Directory agent to your nominated server and run as administrator.
5. Select your appropriate Active Directory domain and click Next.
6. Select Create or use the OktaServiceAccount (recommended) or your nominated account. Click Next. Enter the password for this user when prompted, click Next again.
7. I didn’t have any proxy server, so I simply clicked Next.
8. Now enter your Okta’s organisation URL. This will have been presented to you above in step 3.
9. Next enter your Okta administrator account as detailed in Step 3 above. Once you’ve successfully signed in select Allow Access when prompted.
10. The Okta Active Directory agent will then be installed. Click Finish.
11. The Okta Active Directory agent service will be running on your server as shown:
12. On your Okta administrator console, you’ll be prompted as follows:
13. On the Basics Settings tab, select the Organisational Units (OU’s) you would like to synchronise with Okta. In my lab, I selected just one OU as shown:
14. Leave the Okta username format as User Principal Name (UPN). Click Next.
15. On the Import AD Users and Groups confirmation window, click Next
16. On the Build User Profile tab, review the various AD attributes. If no changes, click Next
17. Click Done when prompted
Okta has also provided some advice about reviewing these accounts, Desktop SSO and Delegate authentication to Active Directory (which we’ll setup later)
18. To setup a scheduled import of users from AD to Okta, select the Provisioning tab > To Okta and change the scheduled import from Never to a scheduled time that suits your environment. In my lab, I selected Every 4 hours as shown.
19. Under User Creation & Matching next to Confirm new users, select both Auto-confirm new users and Auto-activate new users. This ensures any users added to AD are automatically added to Okta’s directory without the administrator needing to confirm them. Click Save.
20. Select the Import tab and click the Import Now button
21. Select Full import (this could take a while) and click Import.
22. Select the checkbox to select all users which have been imported. If you’re ok with everything, next select Confirm Assignments.
23. Select the option Auto-activate users after confirmation and click Confirm
24. Once you’ve imported your users, try logging into one or two test AD accounts which have been imported into Okta.
Setting up Delegated Authentication
The Okta admin console clearly explains that Delegated authentication uses Active Directory to authenticate your users when they sign in to Okta. A user’s Okta credentials are the same as their Active Directory credentials when delegated authentication is on.
1. To enable this feature navigate to Security > Delegated Authentication. Then click the password policy link as shown:
2. Select Active Directory Policy, then browse to the bottom of the page and click Add Rule
3. Enter a Rule name (in my example AD Account Updates) and then review and accept the defaults as shown. Click Create Rule
4. The rule is then activated as shown:
5. You can now test this by setting an AD account’s password within Active Directory Users and Computers. You should then be able to login to Okta with this updated password.
6. Furthermore, the user is able to change their own password via the Okta apps portal under Settings as shown below:
When I first tried testing this, I kept receiving the following error “Password requirements were not met”
Within the Okta admin console under Reports – System Log it was showing the following:
The Okta AD Agent log was able to provide more specific information. This log is located under C:Program Files (x86)OktaOkta AD AgentlogsAgent.log
The following support article was able to confirm that the Okta password policy only applies to Okta mastered users, and that Okta does not enforce any password policy requirements for AD delegated authentication users. I needed to update the AD password policy to match the Okta password policy. For my lab, I reduced the password history and password age to 0 and disabled password complexity requirements for my testing. For production, these items should match your Okta settings where possible.
Depending on your requirements, the Okta AD agent will need elevated rights. You can do this for a specific OU as per the following article. This kb article details this information too. This is the delegation of tasks from my lab Active Directory, where I elevated the rights for my Okta Service account for a specific OU.
Enabling Self Service Password Resets and Unlock Account
You can enable the ability for users to reset their account if it’s locked or they have forgotten their password.
1. First update the Active Directory Policy and enabled the feature Lock out user after 10 unsuccessful attempts, as shown:
2. Ensure your rule applies to all users and ensure Users can perform self-service is enable Password change (from account settings), Password reset and Unlock account. Also change Additional Verification is set to Only Security Question
Note: There are guidelines on the ways users should be able to initiate a recovery. See the following article for more details.
4. As per this article, you need to ensure Security Questions are enabled so users can reset their own password. Otherwise, the users will attempt to reset their own password via email and the email will contain the error “At this time your password can only be reset by an administrator”
5. To enable this for your users, navigate to Security – Authenticators – Setup.
6. Click Add Authenticators, browser to Security Question and click Add
7. Select Recovery as shown and click Add.
8. Now select the Enrollment tab and change the Eligible Authenticators – Security Question to Required. This will ensure that when a user next time logs into Okta, they will be prompted to enter a security question.
9. When the user successfully logs into the Okta portal and selects Settings, they will see the option for Security Question as shown.
10. Next, deliberately incorrectly enter a password over 10 times for a test account. The account will be shown as locked as follows.
11. On the Okta login screen you’ll see the Unlock account? text.
12. The user will be able to request their account can be unlocked via email.
13. Similarly, the user can reset their own password by clicking on the Forgot password text as shown below.
Federating Okta with Salesforce
1. Salesforce (or SFDC) is a great application to test setting up a SAML federation with Okta. Navigate to https://developer.salesforce.com/signup for a free account. I’d suggest using a personal e-mail address that has not previously been used with SFDC.
2. Go to your email and confirm your registration. Select Verify Account. This will take you to the Change Your Password Site.
3. Set a password of your choosing and provide a security question and answer
4. Select Change Password to save and you will be redirected automatically to the Setup Home page.
5. On the Salesforce home page navigate to Settings > Company Settings > My Domain
6. Edit your SFDC tenant DNS name if required. In my lab I changed the name as follows. Take a note of this URL as you’ll use this below.
7. When available, click the Deploy New Domain button to make this new domain available.
8. At this point your new org name in SFDC will be published to the internet and should become widely available for use within 12-24 hours. You should receive an email when this is completed. You can test this by trying to navigate to your new org name in a browser window.
9. Login to the Okta admin console and select Applications > Applications and select Browse App Catalog
10. Search for salesforce.com then select the application from the returned results:
11. Click Add Integration
12. Select SAML 2.0 when prompted
14. Okta does a great job of providing application specific instructions for thousands of applications. Click on View Setup Instructions to review the SFDC specific setup instructions.
15. You’ll note that Okta provides you step by step instructions including the specific values from Okta you’ll need to enter into your Salesforce tenant. For example:
16. Ensure you assign the application to your users/groups.
17. When you login with a test user you’ll see the application icon as follows. If everything is configured correctly once you click on the Salesforce application, you’ll be single signed (SSO) into SFDC.
Q. What if things don’t work?
Some applications such as Salesforce provide you an SAML Assertion Validator, which I’ve used several times to determine what errors might be occurring.
Another very useful tool is SAML-tracer which is a Firefox add-on. Here’s a nice short video showing you how to use it.
Adding a Multifactor Authentication (MFA) Policy to an Okta application
Multifactor Authentication (MFA) is an added layer of security used to verify an end user’s identity when they sign in to an application. An Okta admin can configure MFA at the organization or application level. The following article provides more details.
1. Okta details these various authentication factors as follows within the console:
2. Next review the default Authentication policies, by selecting Security – Authentication Policies. You’ll note that the Salesforce application is currently assigned the Default Policy and the Any two factors policy has no applications assigned to it.
3. Navigate to Application – select Salesforce.com – Sign On tab – scroll to the bottom of the screen to User Authentication – click Edit.
4. Change the Authentication policy from the Default Policy to Any two factors. Select Save
5. If you review the Authentication policies tab, Salesforce will be now listed under Any two factors as shown:
6. When your test user launches the Salesforce application you’ll then be prompted for a another factor (or set this up if it’s the first time) as follows:
Conclusion
Okta is incredibly easy to setup and integrate with your existing on-premises Active Directory. You can see from the instructions above, how easily you can integrate Okta with many of the popular applications such as Salesforce, Workday and Office 365. Ultimately providing your staff with an easy to use application catalog and single sign-on to all of your business applications.
Where to next? I’d say join some of the Okta communities available here. There is also a lot of discussion on Okta via the MacAdmins Slack community under the #okta channel.
References / Acknowledgements:
- Assistance from Dany Leclerc (Senior Solutions Engineer at Okta) with assistance with Fast Pass
Article originally published here
