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,t hey 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 is taken to a "Sign Up Now" page, which allows them to create 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.)
Omnilert also allows a special "Account Linking" option which helps transition from non-LDAP to LDAP logins. More info about that is provided below, see "Transitioning to LDAP".)
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 version (e.g. 3.0)
- LDAP search base DN: The DN (Distinguished Name) of your LDAP/Active Directory server. (e.g.
- 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:
- OpenLDAP example:
- Active Directory example:
- LDAP username field name: LDAP field name that holds the users username. (e.g.
- LDAP first name field name: LDAP field name that holds the users first name. (e.g.
- LDAP last name field name: LDAP field name that holds the users last name. (e.g.
- Logout redirect URL: The web address that you wish users to go to on logout from LDAP session. (Please be sure to include the
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.
Additional LDAP settings
Some additional settings are provided to set what new subscribers see when they first log in via LDAP.
- Disable account linking: Used to disable the ability to link an existing account with the LDAP account. If you're starting fresh with Omnilert, disable this feature. Account linking is only used to transition from non-LDAP to LDAP logins.
- Account link text: Used to insert specific instructions for linking an existing account to be an LDAP account. This text content will show on the 'Link Existing Account' page. (See below for info about "account linking".)
- Account new user text: Used to insert specific instructions for adding a new user to your account. This text will show on the 'Create New User Account' page.
- LDAP access only: Used to force your users to only access their accounts through your LDAP interface
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.
- "Crowd Source" the switchover. The "Account Linking" function of the LDAP login process, if not disabled, will present first-time logins with the option to enter their "old" username and password. Once the subscriber enters their old login info, their old account is transitioned to their new LDAP username.
Account linking is a handy way to transition a lot of users with little effort by letting users identify which "old username" was theirs as they log in. After a few weeks or months, most can disable this feature as all users will be transitioned.
Setting Up an LDAP Login Page
In order to log in via LDAP, your subscribers (end-users) will need a "Log In" form. This is typically hosted on your website, along with your own custom instructions and information about your communications policies.
So, the last step in setting up LDAP is to add the &sso=1 SmartCode Extension to the Subscriber login form SmartCode provided on the Tools >> SmartCode page.
When embedded into your site's HTML source, this SmartCode code will create a simple for Subscribers to log into Omnilert. By default, this script will log in Subscribers through non-LDAP passwords.
We're going to paste that default code into our favorite HTML editor and then alter it to force it to use LDAP instead of non-LDAP logins.
Then the form is rendered in a browser, it'll use LDAP and won't display any "Forgot username?" or "Forgot password?" links. (You'll want to include those password reset links for your LDAP system in your site's other content!)
Of course, the example shown here is a very basic, unstyled web page. As you can see, the SmartCode's script simply renders a form inside of your web page, giving your webmaster total control of all other content on that page.
Simply embed that modified script into any web page where you'd like to present a Subscriber login form for Omnilert.
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!
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.