Quick and easy SaaS provisioning for OpenLDAP

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.

SWA and SAML-Based SSO

On first sign-on to their Okta account, new users are prompted to download the Okta browser plugin/Chrome extension. This extension detects when the user is being prompted to log in to one of their Okta-provisioned web apps that has been set up to use the SWA option and will auto-populate and submit the login page with their Okta username and LDAP password. It's a nice complement to SSO, but it will still attempt to log in to Okta-provisioned apps that aren't set up for SAML-based SSO (those in which the user sets a password when first signing in to the app itself), in which case, it will only be of use if the password manually set in the app matches the LDAP password. As you can see, this method has some potential for confusion.

When an app is enabled for SAML-based SSO, you copy the identity provider (IDP) URL from Okta's per-app SSO setup instructions and download the X.509 certificate; then, upload them to your admin account with the SaaS service provider. As users try to log in to the app by entering their email address, but before they enter a password, the service provider will identify that the account requires SSO and redirect to the Okta SSO page. The user will then log in to their Okta account with their LDAP credentials and be redirected to the chosen web app. For as long as they remain signed in to Okta, they'll be able to log in to the app just by entering their email address. Password changes on LDAP will immediately take effect on subsequent Okta sign-ins.

If you remove a user from one of your application groups on LDAP (as shown in Figure 3), they'll still be able to access that app until the next Okta directory import occurs, which is another good reason to keep the scheduled import frequency as high as possible.

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.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy ADMIN Magazine

SINGLE ISSUES
 
SUBSCRIPTIONS
 
TABLET & SMARTPHONE APPS
Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • LDAP integration with popular groupware suites
    Your LDAP directory holds user data for the whole network. Why not save time and avoid duplication by integrating the LDAP directory with your groupware environment?
  • OpenLDAP Workshop
    Centralized user management with LDAP or Active Directory is the standard today, although many prefer to manage user data manually rather than build this kind of infrastructure. In this article, we look at a better approach with OpenLDAP.
  • Single sign-on with Keycloak
    Google and Facebook are two of the biggest providers for single sign-on on the web, with OAuth2 and OpenID, but if you don't want to put your customers' or employees' data in their hands, Red Hat's Keycloak software lets you run your own operations with the option of integrating existing Kerberos or LDAP accounts.
  • What's new in Samba 4
    In December 2012, the open source world received the first, and very long awaited, release of the Samba 4.x series.
  • Secure passwordless logins with FIDO2 and LDAP
    Log in to your account securely without a password with LDAP and a schema to establish the objects and attributes required for FIDO2 authentication.
comments powered by Disqus