In this section:

Related articles:


The SBC Core includes a configurable Flexible Active Directory capable of syncing data from a remote server and using synced data during call processing.

This example configuration describes how to create and configure an Active Directory profile using the following basic steps:

Refer to Ad Profile - CLI and Profiles - Ad Profile, for details. The description below is limited to CLI. 

Create an AD Profile to Sync Data from the Remote Server

Create an AD profile to sync the data from the Remote server. Perform these steps from either the EMA or from the CLI. Refer to Ad Profile - CLI and Profiles - Ad Profile, for details.

Fetch Data From a Remote Server

Perform the following steps to fetch the data from the remote server.

Creating Domain Controller

  1. Configure Transparency of "all" Headers.

    set global servers domainController ADSERVER1 description WESTFORLOCATION userName ribbon\\testuser password asdbasdb primaryIP 10.23.45.66 ldapQueryCriteria cn=* searchScope CN=Users,dc=ribbon,dc=com
    Note

    The remote port is configured in the Domain Controller, but the LDAP does not use it.  It uses the standard ports 389 for simple authentication and port 636 for TLS.

  2. Configure ACL rule and management interface static route for the domain controller’s IP. This ensures that mgmt. interface is used to send the LDAP query and packets from the AD server is allowed reach the application.

    The command example below creates static route and ACL rule where the Domain Controller IP is 10.23.45.66 and the management gateway IP is 10.54.51.1

    system mgmtStaticRoute 10.23.45.66 32 10.54.51.1 mgmtGroup mgmtIntf1 preference <1..99>
commit
set addressContext default ipAccessControlList rule test precedence <1.. 65535> mgmtIpInterfaceGroup mgmtGroup sourceIpAddress 10.23.45.66 sourceAddressPrefixLength 32 state enabled
commit

  3. Configure Flexible AD attributes. For each attribute there is an AD attribute identifier. This AD attribute identifier is used as reference in all other entities.

    set profiles adAttributeMapProfile DEFAULT_AD_ATTRIBUTE_PROFILE adAttributeList adAttribute1 adAttributeName cn
commit
set profiles adAttributeMapProfile DEFAULT_AD_ATTRIBUTE_PROFILE adAttributeList adAttribute2 adAttributeName telephoneNumber
commit
set profiles adAttributeMapProfile DEFAULT_AD_ATTRIBUTE_PROFILE adAttributeList adAttribute3 adAttributeName mobile
commit
set profiles adAttributeMapProfile DEFAULT_AD_ATTRIBUTE_PROFILE adAttributeList adAttribute4 adAttributeName unixHomeDirectoryNumber
commit

    In the above example, 

    adAttribute1 refers to cn in all other entities like dmpm criteria, dmPm Rule and call parameter filter profile. Similarly, adAttribute2 refers to telephoneNumber, and so on.

    Note

    If any change is done in this profile and the data has already successfully synced before the modification, then perform a sync either using manual sync command or else wait until the sync Interval timer to kick in and sync the data. Until sync is performed, you cannot use the new modified data and the calls fail.

Configure AD profile

  1. This entity allows the user to configure data like sync state, delayed sync, sync interval and the remote servers list from which the data is fetched.

    % set profiles adProfile DEFAULT_AD_PROFILE sync enable syncInterval 1440 delayedSync 2019-03-07T23:59:00 adServerList 1 dcServer ADSERVER1

    In the above example, the configuration performs the first sync at 7th March 2019 23:59. The next sync is scheduled at 8th March 2019 23:59. It  fetches the data from the active directory server ADSERVER1. A maximum of 32 servers are allowed to be associated with the AD profile. 

    Use the following command to trigger a manual sync:

    request system admin <systemName> adManualSync
    Note

    Manual Sync does not change any of the delayedSync or syncInterval logic. The Sync interval commences only after a successful sync, due to a delayed sync.

    If delayedSync fails to sync for some reason, then SBX retries the sync operation after 1 minute of the failure. To stop the syncing operation, disable the sync parameter in the AD profile.

    If multiple servers are configured for syncing the data from, and if any of the server fails due to some reason, the SBC stop the syncing operation and sets the AD sync status as failed. New data is stored locally only after all the servers are synced successfully.

  2. View the sync status by executing the following command:

    % show table system adSyncStatus
AD SYNC
MODULE     AD SYNC
NAME       STATUS          AD TIME STAMP
------------------------------------------------
Ad Server  syncInProgress  2019-03-06:16:48:32
Ad Server  syncInProgress  2019-03-06:16:48:32

    The status shown indicates that sync is in progress.

    Note

    The four types of Sync status are listed below:

    • neverDone: Data has never been synced.
    • syncInProgress: Sync is in progress.
    • syncCompleted: Sync is successfully completed.
    • syncFailed: Sync operation has failed.

    The AD time stamp displays the timestamp of the last successful Sync operation.

  3. View the alarm raised when there is any issue with syncing data from the remote server.

    % show status  alarms currentStatus
    Note

    If the adSyncStatus command output shows syncFailed, check the alarms raised. The alarms show the standard LDAP error code and its respective error string. If the debug log level is set to info, additional data is available, which helps to narrow down the issue.

Using Synced data During call processing

Once data is successfully synced, the application can use it during call processing. To use the synced data for SBXs call routing logic, you must configure various entities.

Configure Call Parameter Filter Profile(CPFP)

  1.  This entity is configured to build a condition using various call parameters to query the local database. For e.g. if user wants to fetch the data where the called party number is equal to telephoneNumber ad attribute value. If the above AD ATTRIBUTE MAP PROFILE is configured the CPFP entity is configured as:
set profiles callParameterFilterProfile POCTEST callParameterFilterProfileData 1 adAttributes adAttribute2 operation = adCpe calledNumber

 The adAttribute2 refers to telephoneNumber as configured in the AD attribute map profile. The operation is equal to Call Parameter Element (CPE) type. The called number fetches the row where the telephoneNumber AD attribute value is equal to the called number.

Create multiple such conditions. If multiple conditions are configured, then it is treated as an “AND” operation.

set profiles callParameterFilterProfile POCTEST callParameterFilterProfileData 1 adAttributes adAttribute2 operation = adCpe calledNumber
set profiles callParameterFilterProfile POCTEST callParameterFilterProfileData2 adAttributes adAttribute3 operation =/= adCpe callingNumber

In the example above, the application fetches the data where telephone Number  (adAttribute2 refers to telephoneNumber in the example configuration) is equal to called Number AND mobile (adAttribute3 refers to mobile in the example configuration) is not equal to calling Number.

 Call Parameter Filter Group Profile  (CPFPG)

This entity groups the multiple CPFP entities. Among multiple CPFP entities, ‘OR’ operation is applied. If any one of the CPFP data fetch is successful, then that data is used for the call.

set profiles callParamFilterGroupProfile POCCPFPG1
callParamFilterGroupProfileData 0 callParamFilterProfile POCTEST
commit

Apply DM PM criteria

This entity is a precondition to apply the DM PM sub-rule. If a DM PM criteria is successful then the DM PM sub-rule is processed.

set profiles digitParameterHandling dmPmCriteria POCDMPMCRI1 criteriaType parameter parameterType adAttribute4 parameterPresenceCheck exists 
commit

This checks for unixHomeDirectoryNumber (adAttribute4 refers to unixHomeDirectoryNumber in the example configuration) presence in the data that is fetched due to CPFP.

Apply DM PM Rule

The DM PM rule allows the SBC to modify various CPE values using other parameters which includes the AD attribute values.

set profiles digitParameterHandling dmPmRule POCDMPMRULE1 subRule 0 criteria POCDMPMCRI1 ruleType digit digitManipulation numberType calledNumber digitStringManipulation numberOfDigits 10 startDigitPosition 0 replacement digitString adAttribute2 numberOfDigits 10 startDigitPosition 0

This DM PM sub-rule first checks if the dmpm criteria (POCDMPMCRI1) is successful, and if so, it manipulates the called number with the content of telephoneNumber (adAttribute2 refers to telephoneNumber in the example configuration) as configured.

Apply Number Translation Criteria

This Number Translation Criteria binds all the entities to form the trigger criteria.

set profiles digitParameterHandling numberTranslationCriteria POCNTC1 trunkGroup TG_SIPART_IAD TITAS Sonus_NULL Sonus_NULL lookupType AD callParameterFilterGroupProfile POCCPFPG1 outDmRule POCDMPMRULE1 inDmRule POCINDMRULE1
commit

The above criteria triggers when the ingress trunk group is TG_SIPART_IAD and the gateway is TITAS. The SBC performs the POCINDMRULE1 DM PM rule and fetches the data based on the conditions set in the CPFPG (POCCPFPG1). After fetching it, the SBC applies the DM PM rule POCDMPMRULE1.

Create Active Directory Service

When the service state is enabled, the SBC checks for the trigger criteria match configured in POCNTC1. If the trigger criteria matches, the corresponding data is fetched from the local Database and used for further call processing.

set global servers adService POCADSERV1 priority 1 criteria triggerCriteria POCNTC1
commit
set global servers adService POCADSERV1 flags active enable
commit

Workaround for Adding Domain Controller (DC) Root Certificate of the AD Server in the SBC

Use the following steps as a workaround for adding the DC root certificate of the AD server in the SBC:

  1. Add the root certificate of your AD server at the end of the file /etc/ssl/certs/ ca-certificates.crt in the SBC.

  2. Update the primary IP as the domain name in the DC. 

    set global servers domainController <domain controller id> userName <username of the ad server> password <password of the ad server> primaryAddress <ip address or FQDN of the ad server> secondaryAddress <back up ip address or FQDN of the ad server> ldapQueryCriteria <ldap Query Criteria> searchScope <search scope>
> commit

  3. Change the configuration in the DC data using CLI.

  4. Enable the TLS in the DC. 

    set global servers domainController <domain controller id> userTLS enable remotePort <remote port that is being used for tls>

  5. Add the domain name and IP address in /etc/hosts.

  6. Reboot the SBC.

  7. Try the LDAP manual sync. 

    system admin <systemName> adManualSync

  8. Check sync status with the AD server. 

    show table system adSyncStatus

  9. If issues persist, try curl: 

    curl --tlsv1.2 --user int
svcADRead ldaps://<serverFQDN>:636/<query>