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 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.
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.