How to Use Azure AD for credential verification
On this page
It is possible to expose Azure AD as a secure LDAP after Azure AD Domain Services has been enabled. This article will not cover how to configure Azure AD but will address how to configure the Curity Identity Server to leverage the secure LDAP (LDAPS) interface of Azure AD as a Data Source and with that used as a Credential Manager for credential verification.
An installation of the Curity Identity Server. If you do not have an installation of the Curity Identity Server, follow this tutorial installation of the Curity Identity Server and configure the installation by running Curity Basic Setup Wizard as outlined in this tutorial Curity Basic Setup Wizard.
Azure AD needs to be set up with Azure AD Domain Services. With that fully configured it is possible to enable secure LDAP as outlined in the Microsoft documentation.
Curity can be configured to use LDAP as a Data Source out-of-the-box. With some specific configurations we can allow Curity to connect to a secure LDAP and then use that Data Source in a Credential Manager that will verify a users credentials in the authentication process.
Server Trust Store
Curity needs the Azure AD certificate in order to communicate with Azure AD and the secure LDAP interface.
If the certificate is not available it can be obtain directly in the Curity Admin UI. Go to Facilities → Keys and Cryptography → Trust Anchors, then add a new Server Trust Store. Select the host option and enter the Azure AD secure LDAP host and port, Ex.
aaddscontoso.com:636, click Next, give it a name and then click Ok.
Obtain certificate using
Alternatively the certificate can be obtained using
openssl. Execute the following from a command prompt:
openssl s_client -connect aaddscontoso.com:636 \-showcerts </dev/null 2>/dev/null | openssl x509 \-outform PEM > azure_ad_ldap_server.pem
The downloaded certificate can be added using the File option, browse to
azure_ad_ldap_server.pem, no password should be needed.
The certificate can also be added using the Text option and is simply a copy and paste of the certificate itself. This is described in the Curity Admin UI.
The bulk of the configuration on the Curity Identity Server side in using Azure AD for authentication lies in configuring an LDAP Data Source. It is not a complicated configuration but naturally all things need to align with how Azure AD, Azure AD Domain Services and secure LDAP is configured.
In the Curity Admin UI, go to Facilities, click + next to Data Sources. Give it a name,
Azure_AD for example. The below table shows an example configuration for the LDAP Data Source.
|Client ID||CN=John Doe,OU=AADDC Users,DC=aaddscontoso,DC=com|
|Default Root||OU=AADDC Users,DC=aaddscontoso,DC=com|
|Disable Hostname Verification||disabled|
|Ldap Server Type||active-directory|
Make sure to use the correct host for your environment and that the port used (636 is default) is accessible from the Curity Identity Server.
The Client ID and Secret is needed if anonymous bind is not allowed. Note the format of the Client ID and make sure the user has permissions to bind to the secure LDAP.
Default Root is the base of the LDAP tree where Curity will start its lookup when performing verification of the credentials.
The rest of the configurations can be left as default. Additional configurations could obviously be made as needed but are not covered by this tutorial.
With a Data Source created we can now create a Credentials Manager for Azure AD. Go to Facilities and then add a new Credential Manager.
Give it a name,
Azure_CM for example. Set the Algorithm Type to
plaintext and the Data Source to the newly created Data Source.
With the Trust Store configured, Data Source and the Credential Manager created we can now leverage Azure AD and its secure LDAP interface to check the credentials of a user in the authentication process.
As an example, an HTML Form Authenticator could be used for authentication where it is configured to use the Credential Manager that is configured to use Azure AD as the Data Source.