How to configure LDAP Authentication on an AudioCodes SBC

Configuring LDAP Authentication on your SBC is a great way to introduce accountability and legitimate access control against a relatively up to date authentication source such as Active Directory / LDAP.

Local admin accounts are great for when you’ve got a single administrator, but when you have multiple administrators and even situations where the local admin credentials get passed around – you really have no idea who is making changes on your device at any given time. Take the time and setup LDAP Authentication with Local Auth fallback as detailed in this post.

Let’s start off with a summary of what needs to be done:

• Set DNS servers on your LDAP server facing IP interfaces on the SBC
• Load in any TLS trust certificates required for LDAPS.
• Configure LDAP Server Group
• Configure LDAP Servers in that LDAP Server Group
• Search Base DN and LDAP Groups with permissions mapping
• Enable LDAP
• Enable web and SSH logins to use LDAP authentication

Set DNS servers on your LDAP server Facing IP on the SBC

Why do we need DNS, why can’t I just use IP?
We are going to resolve the FQDN of our LDAP servers because we need to do this for LDAPS purposes — the FQDN we specify has to match the certificate presented by the LDAP server.

Go to Setup -> IP Network -> Core Entities -> IP Interfaces on your Audiocodes SBC.

Edit the OAMP interface that you have there that faces the LDAP server and set the DNS Servers to your DNS servers — these are likely to be internal AD/DNS servers, I’m using public DNS servers because my LDAP server is on the internet.

Load in any TLS trust certificates required for LDAPS

I’m using LetsEncrypt to secure my LDAP service, so I’ll need the rootCA and subCA that make up my certificates trust chain and I’ll need to load it into the AudioCodes SBC so that the SBC trusts the certificates the LDAP service is presenting.

Go to Setup -> IP Network -> Security -> TLS Context on your Audiocodes SBC. Look to the bottom right and click the link for Trusted Root Certificates.

Import trusted CA certificates. An example of what I’m loading is located here. They should be base64 encoded certificates in .pem format, this example actually has two certificates in a single file – whether you do this or not does not actually matter here. The end result is that the chain of certificates are listed as trusted, if you haven’t got LDAPS setup on your domain controller see this Microsoft blog post (step 3) for guidance.

Configure LDAP Server Group

An LDAP Server Group is as it describes — a group of LDAP servers for a purpose, we’re going to create a ‘management’, ‘management service’ and ‘control’ LDAP Server Group (read: three groups).

We could get away with just a ‘management’ and ‘control’ LDAP Server Group but that wouldn’t allow us to receive alerts for when LDAP is down as a ‘management’ LDAP Server Group is not an ‘always on’ type of connection where as a ‘management service’ LDAP Server Group is.

Both serve different purposes – ‘management’ is authentication whereby the user details (username and password) of the person logging in are used to perform a bind to AD/LDAP to see if authentication succeeds; ‘management service’ is user authorisation whereby group membership of the user attempting to login is checked by a service account to ascertain whether they have rights to access the SBC and in what capacity.

Go to Setup -> IP Network -> Radius & LDAP -> LDAP Server Groups on your Audiocodes SBC.

Click New and give the LDAP Server Group a name and change the Type. You will need to create three, one for ‘Management’, one for ‘Management Service’ and one for ‘Control’

The other LDAP Server Group Type is ‘Control’ which is used for LDAP Call Routing purposes. When LDAP is Enabled and then the SBC is Reset, the SBC will automatically populate a default Control type LDAP Server Group – because we are configuring things so that we only need to endure a single reset, we need to create this manually.

Note: A ‘Control’ type LDAP Server Group must exist for the LDAP process on the SBC to properly initialize. 

Configure LDAP Servers in that LDAP Server Group

Now we need to populate the two LDAP Server Groups with LDAP Servers, I only have 1 LDAP server that I’m using – so that means I need to create 1 LDAP Server per LDAP Server Group.

Go to Setup -> IP Network -> Radius & LDAP -> LDAP Server on your Audiocodes SBC, click New.

The only difference between the management service and the management LDAP Server are the LDAP Server Group dropdown, LDAP Password and LDAP Bind DN.

The first LDAP Server I’ll create will be for the ‘management service’, this will use a service account to bind to LDAP and will be an ‘always on’ connection allowing me to have alarms raised when LDAP is down.

The second LDAP Server will be for ‘management’, this will use the username and password entered by the user that tries to login via SBC Web Login page or SSH. The LDAP Password needs to be set to $ (just a single dollar sign) — it is a variable for the password entered by the user.

The LDAP Bind DN despite the name can be a few different things as per below:

• Distinguished Name : cn=username,ou=users,dc=example,dc=com
• User with domain: example\username
• UserPrincipalName (UPN): username@example.com

It is important to note that OpenLDAP, only supports Distinguished Name. Active Directory supports all three options.

For Active Directory, I recommend using the service account’s userPrincipalName (UPN) for the ‘management service’ LDAP Bind DN field. I also recommend having the user login with their UPN.

Much like the $ is a variable for the password, it is also a variable for the username in the LDAP Bind DN field. This means you can assemble the LDAP Bind DN parameter in different ways depending on how you plan to bind to LDAP source.

• Distinguished Name : cn=$,ou=users,dc=example,dc=com
• User with domain: example\$
• UserPrincipalName (UPN): $

When using ‘Distinguished Name’ and ‘User with domain’ examples, some of the content is static and so may not be suitable if admin users are in different OU structures or admin users are from multiple domains hence the recommendation to use UPN.

Search Base DN and LDAP Groups with permissions mapping

On the same page, at the bottom we have where we need to configure the LDAP Group mappings and the Search Base DNs.

Now because we have a ‘management service’ LDAP Server Group and a ‘management’ LDAP Server Group, the search base DN and the management LDAP Groups are configured on the management service LDAP server. In the screenshot above, that is the ‘mitch.life User Authorisation’ LDAP Server Group. If we did not have a ‘management service’, then this configuration would be done on the ‘management’ LDAP server Group.

The Base DN is where your users are located – typically, in Active Directory, the Administrators will create a new Users OU structure & hierarchy. When in doubt, choose the top level. i.e dc=mitch,dc=life

The levels are: Monitor, Admin, Security Admin, End User.

Security Administrator is the highest level of administrator on the SBC, so set this for your administrator users. AllUsers is the name of my group in AD. memberOf=cn=AllUsers,ou=groups,dc=mitch,dc=life

Enable LDAP

We need to Enable LDAP and add in the LDAP Authentication Filter, because we are using memberOf and LDAP Groups, our LDAP Authentication Filter just needs to capture the username inputted by the user as they login and map it to an attribute. Because the user will enter in their username in UPN format. i.e user@example.com – we need to map it to the userPrincipalName attribute. The LDAP authentication filter should be set to: userPrincipalName=$

All other settings in the screenshot are defaults, upon setting LDAP Service Enable, you will need to save, and then you can set the LDAP Authentication Filter. For LDAP to be work, a SBC Reset is required but we will action this later once all the configuration is complete.

Enable web and SSH logins to use LDAP authentication

We now want to use what we’ve setup to allow logins to the SBC, we also want to test our configuration before we turn off local authentication as a primary means of logging into the SBC for administration.

Go to Setup -> Administration -> Web & CLI -> Authentication Server on your Audiocodes SBC.

• Set ‘Use Local Database’ to ‘Always’.
• Set ‘Default Access Level’ to ‘0’
• Set ‘Use LDAP for Web/Telnet Login’ to ‘Enabled’.

Save and Reset the SBC and test out LDAP authentication — if all works, be sure to set ‘Use Local Database’ back to ‘When No Auth Server Defined’ so that Local Admin access becomes available only if there are LDAP connectivity issues.

Tips for Testing

Check and see if your ‘management service’ LDAP Server has connected. Keep in mind that your ‘management’ LDAP Server will always have “LDAP_CONNECTION_BROKEN” because it is not ‘always on’.

Go to the AdminPage and set LDAPDebugMode to 3. (https://SBCIP/AdminPage) and then view Troubleshoot Message Logs / Syslog.

During a packet capture, if you are using an unencrypted port — you should be looking for the below in the following order:

1. A bindRequest from the SBC for the user who is logging in.
2. A bindResponse from AD indicating ‘success’.
   • If you receive a success, your ‘management’ LDAP Server config is validated.
3. A searchRequest from the SBC that includes:
   • your search base (dc=mitch,dc=life)
   • your LDAP authentication filter (which if you are using userPrincipalName=$ will be userPrincipalName=<username entered by user>)
   • your management attribute (in this case memberOf).
4. A searchResEntry from AD for the user (if found) and in this response is the Attributes Values for memberOf which include a listing of all group memberships. This is mapped against the Management LDAP Group configured under the ‘management service’ LDAP Server configuration.