To Each His Own

Adding a Master Directory

With your master directory now set up to provide an authoritative record as to which apps should be allowed for which user, you can now set up directory integration on Okta. To get started, sign in to your Okta admin console and select Directory | Directory Integrations | Add Directory | Add LDAP Directory .

Okta walks you through this wizard-style process. You need to select a version of the Okta LDAP agent that is suitable for the server on which you intend to run it: RPM or DEB. You can copy the URL of your chosen installer and download it to your server with wget. To run the installer, enter:

$sudo dpkg -i OktaLDAPAgent-05.04.06_amd64.deb

Configure the agent to start automatically whenever the server starts. You want it to be running all the time so that your Okta directory always stays in sync with your master directory. Helpfully, Okta will email you immediately whenever it detects a change in the agent's online status.

$sudo update-rc.d OktaLDAPAgent defaults

Finally, start the agent:

$sudo service oktaldapagent start

The first time you do this, the agent will prompt you to enter your LDAP server credentials, Okta subdomain, and Okta account information. The agent will then start its process of long-polling your Okta account; the setup web page on your Okta account will automatically update when the agent starts communicating with it and will then take you to the next step of the process, which asks you to configure your directory integration settings. You will run into a couple of gotchas here, so it's worth showing a number of screen shots. Figure 5 shows the initial UID mappings.

Figure 5: Selecting your integration type, configuring the UID mapping for your LDAP user objects, and mapping user object class details, including the activate/deactivate flag that was added in Figure 4.

In the unlikely event that your LDAP user object doesn't include a uid (User Name) attribute, you'll need to add one – Okta requires it. Finally, the all-important group settings allow you to assign individual apps per user (Figure 6).

Figure 6: Adding the group search details.

Finally, you'll be prompted to select an Okta username format, which has to be in the form of an email address and can be either an email address pulled direct from your LDAP user objects or one composed of an LDAP username plus a specified domain. To verify your directory integration settings, enter an example username that corresponds to one of your real LDAP users, and Okta will attempt to import that user into its own directory (Figure 7).

Figure 7: Successful verification of directory integration settings, showing the per-app groups assigned to this user in the LDAP directory.

Activating Users

You'll now be prompted to do an initial import of your directory, which populates your Okta directory with all the users and groups that meet the filter criteria you entered in the directory integration settings. Because (in this case) your LDAP directory is the master, you do not need to marry up your LDAP-imported users with users from any other source, so you can confirm all these assignments right away.

When your new user assignments are confirmed – either as part of your initial import or as part of subsequent incremental imports that you can configure to run on a schedule of your choosing – each newly confirmed user will receive an email inviting them to sign in to their Okta account. Given Okta's background as a provisioning/SSO service, rather than an actual application, there is some scope for user confusion, so you can choose to suppress these email messages if you prefer to handle this communication yourself. However, in situations in which you want to give users control over which apps they activate in their Okta accounts, you should allow delivery of this email.

The final step in directory integration is to schedule your regular imports. In this use case, in which the LDAP directory is the master and you want to keep your Okta directory synchronized as closely with it as possible, I don't see why you wouldn't go for the most frequent option, hourly (Figure 8). You can also force an import at any time you like under the Import tab.

Figure 8: Use Import Settings to configure frequent imports from your LDAP directory.

With the Okta directory happily slaved to your master LDAP directory, you can turn your attention to the SaaS application(s) you want to provide to your users. You can use Okta purely to provision and de-provision accounts and allow your users to fend for themselves when it comes to password management, or you can give them SWA (see also the "SWA and SAML-Based SSO" box); if the app supports it, you can allow full single sign-on, so they'll use the same password for their SaaS apps as they already do for their internal apps currently linked to your LDAP directory.

Provisioning Options

From the Applications menu of your Okta account, work through all the available tabs for your chosen app. Most of the configuration is self-explanatory, and you can do whatever you please. The Sign On tab is where you'll choose between SWA and SSO (the exact options available here depend on what an individual application supports). Figure 9 shows the options available for Dropbox Business, with SAML 2.0 being their SSO protocol of choice; the setup instructions will tell you the corresponding settings to configure on your Dropbox Business admin console.

Figure 9: Configuring sign-on options for the application.

The Provisioning tab is where you'll configure Okta to provision and de-provision a users' accounts in the app automatically. The relevant options are disabled by default. The Import tab isn't relevant here – it refers to backporting existing user accounts from the app into your Okta directory and, optionally, from there into your LDAP directory. If you want to ensure that your LDAP directory remains the master of all it surveys, you should check all import settings in detail to make sure there's no way that Okta can write anything into it.

By this stage, Okta is configured to manage sign-on and provisioning for your chosen app. All that remains is to tell it which users to enact this on. Here, you rely on the fact that the LDAP directory integration pulls in all of your LDAP groups and users.