Configuring a Flexible Active Directory Profile

The SBC Core includes a configurable flexible Active Directory (AD) capable of syncing data from a remote server and using the data during call processing.

This example configuration describes how to create and configure an AD profile.

You can perform these steps from either the EMA or the CLI. The description below is limited to CLI. 

Setting up the local Certificate Authority (CA)

For local Certificate Authority (CA), add the root certificate of your AD server at the end of the file /etc/ssl/certs/ ca-certificates.crt. Follow the procedure below if the AD certificate is generated with the subject as domain name.

Update the primary IP as domain name in the domain controller in the postgres database.

• Log in to postgres database using the following command:

  Log in to the postgres database

   psql ssdb

• Update the domain name in the database. Disable the TLS flag and enable it to reflect in the cache. Add your domain name and IP address in /etc/hosts, where domain_controller_id=’<domaincontrollername>’.

  Update domain name

  update domain_controller set primaryip='<yourdomainname>'

1. Configuring to Sync Data from 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.

2. Fetch data from Remote Server

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

2.1 Creating Domain Controller

1. Configure Transparency of "all" Headers.

   set global servers domainController <controller> description <description> userName <user_name> password <password> primaryAddress 10.NN.NN.NN ldapQueryCriteria cn=* searchScope CN=Users,dc=ribbon,dc=com
   

   Note

   When defining userName and password in the above command, prepend special characters with a backslash ( \ ).

   Note

   You can configure the remote port in the Domain Controller, but not for LDAP. LDAP uses the standard port 389 for simple authentication, and port 636 for TLS.

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

   The command example below creates the 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 the flexible AD attributes. For each attribute there is an AD attribute identifier. The 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.

   If any change is done in this profile and the data has already successfully synced before the modification, then perform a sync using manual sync command, or wait until the syncInterval timer to commence and sync the data. Until sync is performed, you cannot use the new modified data as it can cause call failures.

2.2 Configure AD profile

1. This entity allows you to configure data such as 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. And the next sync is scheduled at 8th March 2019 23:59. It fetches the data from the AD server ADSERVER1. A maximum of 32 servers are allowed to be associated with the AD profile.

   Note

   Manual Sync does not change any of the delayedSync or syncInterval logic. Sync Interval commences only after a successful sync following a delayed sync.

   If delayedSync fails to sync for some reason, then the SBC 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, they must be synced. If any of the servers fail, 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 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 above status indicates that the sync operation is in progress.

   Note

   There are four types of sync status:

   1. neverDone : Indicates that data has never been synced.
   2. syncInProgress: Indicates that sync is in progress.
   3. syncCompleted: Indicates that sync has successfully completed.
   4. syncFailed: Indicates that sync operation has failed.

   The AD time stamp displays the time stamp 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 as status, check the alarm raised. The alarm will show the standard LDAP error code and its respective error string. If the debug log level is set to 'info', then additional data is logged, which helps to narrow down the issue.

3. 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 the SBC call routing logic, you must configure various parameters.

3.1 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 example, a user wants to fetch the data where the called party number is equal to the  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, which is the called number to fetch the row where the telephoneNumber AD attribute value is equal to the called number.

You can create multiple 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 the telephone number (adAttribute2 refers to telephoneNumber in the example configuration) is equal to the called number, and the  mobile (adAttribute3 refers to mobile in the example configuration) is not equal to the calling number.

 3.1 Call Parameter Filter Group Profile  (CPFPG)

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

set profiles callParamFilterGroupProfile POCCPFPG1
callParamFilterGroupProfileData 0 callParamFilterProfile POCTEST
commit

4. 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 rule checks for unixHomeDirectoryNumber (adAttribute4 refers to unixHomeDirectoryNumber in the example configuration) presence in the data that is fetched due to CPFP.

5. Apply DM PM Rule

The DM PM rule allows the SBC to modify various CPE value using other parameters which also 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 DM PM criteria (POCDMPMCRI1) is successful. If it is successful, the SBC manipulates the called number with the content of telephoneNumber (adAttribute2 refers to telephoneNumber in the example configuration) as configured.

6. 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 perform the POCINDMRULE1 DM PM rule and fetches the data based on the conditions set in the CPFPG (POCCPFPG1), and after fetching it applies the DM PM rule POCDMPMRULE1.

7. Create AD Service

When the service state is enabled, the SBC checks for the trigger criteria match configured in POCNTC1. If the trigger criteria matches, the SBC fetches the corresponding data from the local database and uses it for further call processing.

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