Single Sign-On: LDAP – Omnilert

Omnilert provides an option to authenticate Subscriber Portal logins using your LDAP instead of Omnilert's internal password system.

LDAP logins can help manage users by providing them with a unified username and password. They won’t need to remember a separate password for Omnilert. Instead, they just use the same LDAP username/password that they likely use for their email and other resources in your network.

LDAP is often used to provide a unified login with systems such as Active Directory and/or OpenLDAP.

Omnilert's LDAP setup is found in the Settings >> Single Sign-On >> LDAP menu of the Administrator Portal.

How it works...

LDAP login is used for Opt-In systems, where subscribers self-manage their contact information within the Omnilert Subscriber Portal.

When a subscriber authenticates via LDAP, the Omnilert system will check to see if the Subscriber's username is already listed in Omnilert. If a matching subscriber is found, the end-user is taken directly into the Subscriber Portal for that username.

If the LDAP username is not found, the end-user creates a new Omnilert Subscriber account to use with that LDAP login. Once the subscriber creates an account in Omnilert, they'll never see that page again. (Next time they log in, their username will be found and they'll go right into their account.)

LDAP Connection Settings

The basic settings for connecting to LDAP should be familiar to anyone who's configured LDAP access to other resources.

LDAP server address: (e.g. ldap://www.yourschool.edu)
LDAP version (e.g. 3.0)
LDAP search base DN: The DN (Distinguished Name) of your LDAP/Active Directory server. (e.g. dc=yourschool,dc=edu)
LDAP binding DN: binding/authenticating with LDAP. $1 will be dynamically substituted with username at login. $1 to indicate the variable username. The $1 will be dynamically substituted with the username at login.
- Active Directory example: myschoollogin\$1
- OpenLDAP example: uid=$1,ou=Students,dc=yourschool,dc=edu
LDAP username field name: LDAP field name that holds the users username. (e.g. uid or cn or samaccountname)
LDAP first name field name: LDAP field name that holds the users first name. (e.g. givenname)
LDAP last name field name: LDAP field name that holds the users last name. (e.g. sn)
Logout redirect URL: The web address that you wish users to go to on logout from LDAP session. (Please be sure to include the http:// or https://)

Can Omnilert use LDAPS?

Yes. LDAPS is supported and encouraged. Simply include the ldaps:// in the URL for your LDAP server.

Also, note that your LDAP server must use a registered domain name that is covered by a "Certificate Authority (CA)" certificate. (Self-made certs will likely not work.)

Firewall / IP Address Info.

Not all organizations allow open access to their LDAP server(s).

Your local IT security and/or firewall team may need to specify which IP addresses to allow.

Please contact your Omnilert Account Manager or submit a request to our support for the most recent IP list.

LDAP access only

Used to force your users to only access their accounts through your LDAP login interface.

This option disables the standard Subscriber Portal login/sign-up forms.

If setting this option, we recommend also enabling the "Hide subscriber portal signup page" option in the Subscriber Portal settings.

Transitioning to LDAP

When moving from an open, non-LDAP sign-up and login process to LDAP, you may have a long list of subscribers with self-provided usernames. Those may or may not match the usernames that LDAP will provide.

In such a case, there are 3 options for making the switch:

Start over. You could just clear out your subscribers and start anew using LDAP subscriber logins. That's a bit extreme, for sure, but if desired, it's entirely possible.
Supply a file. If you can provide Omnilert's team with a 2 column spreadsheet (old_username and new_username), we can certainly run a query to replace the old, non-LDAP usernames with new ones.
Do nothing and let old accounts expire. In some cases, it's simpler to just allow old, non-LDAP accounts to exist and expire. Eventually, in a year or so, nothing but LDAP users will remain.

Testing and Troubleshooting

With any systems integration, some troubleshooting may be needed to get things working. Omnilert provides a handy testing utility to help check that your LDAP logins work as they should and see what's being released to Omnilert.

The utility will show any bind errors, connection issues, and/or data returned when attempting to authenticate with the given settings.

Assuming a test works OK, you should be good to move forward with using your LDAP system for Omnilert subscriber logins.

If you experience errors, you may need to adjust your LDAP binding info. We suggest checking with your local LDAP admins first but also be sure to contact Omnilert support. We're happy to help where we can!

LDAP Subscriber Portal

Subscribers with LDAP logins will use a slightly different Subscriber Portal URL to access the Omnilert service.

The LDAP version of your login page will require ?sso=1 to be added to the web address.

So, if your normal portal is https://yourcompany.omnilert.net/ then your LDAP login page would be https://yourcompany.omnilert.net/?sso=1

This allows you to offer both LDAP and non-LDAP logins by simply providing a different URL for links from your website.

The LDAP login page will not include any top navigation links or "Sign-Up Page", as LDAP doesn't require such. (New subscribers that log in via LDAP will have their accounts created on-demand automatically.)

Important Note:

If you see a warning of "Your administrator does not have LDAP configured for this account!", the message indicates that LDAP has been enabled but no server URL has been entered into the Omnilert system's LDAP setup. This will disappear once a server URL is entered into the configuration screen and saved.

Note: Unlike Shibboleth/SAML, LDAP login isn't a true "Single Sign-On" system, as there's no persistent login session carried in the browser from other pages in your website. This means that end-users (Subscribers) will need to log in each time they wish to access Omnilert. However, the benefit with LDAP logins is that they can use the same username/password they already use within your network for their email and other resources. So, they don't need to remember/manage a separate login just for Omnilert.