The SBC Core includes a configurable Flexible Active Directory (AD) capable of syncing Data from Remote Server and using synced data use during call processing

This example configuration describes how to create and configure a AD profile using the following basic steps:

Though these steps can be performed from either the EMA or from the CLI, the description below is limited to CLI. 


For local 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 Subject as domain name

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

  • Login to postgess database using the below command

     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.

    update domain_controller set primaryip=’<yourdomainname>’

    where domain_controller_id=’<domaincontrollername>’

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

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 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 AD server is allowed reach to 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.

    If any change is done in this profile and the data has already successfully synced before the modification, then it is recommended to perform a sync either using manual sync command or else wait till the syncInterval timer to kick in and sync the data. Until sync is not performed, the new modified data can’t be used and it can cause call failures.

2.2 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 needs to be 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. And it  fetches the data from the AD server ADSERVER1. 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 kicks in only after a successful sync due to 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 ad profile.

    IFmultiple servers are configured that needs to be synced data from and if any of the server fails due to some reason, the SBC stop the syncing operation and set the ad sync status as failed. New data are 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, currently sync is in progress.

    Note

    There can be four types sync status namely :

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

    The AD time stamp displays the timestamp of 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 alarms that is raised. Alarm will show the standard LDAP error code and its respective error string. If the debug log level set to info, additional data can be found which will help 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 SBX’s call routing logic various entities needs to be configured.

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 e.g. if user wants to fetch the data where the called party number is equal to telephoneNumber ad attribute value. Let’s assume the above AD ATTRIBUTE MAP PROFILE is configured. So 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 is the called number which fetch 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 fetchs the data where telephone Number  (adAttribute2 refers to telephoneNumber in our example configuration) is equal to called Number AND mobile  (adAttribute3 refers to mobile in our example configuration) is not equal to calling Number.

 3.1 Call Parameter Filter Group Profile  (CPFPG)

This entity groups the multiple CPFP entities. Among multiple CPFP entities, ‘OR’ operation is applied. Which means 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 checks for unixHomeDirectoryNumber (adAttribute4 refers to unixHomeDirectoryNumber in our 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 includes the AD attribute values as well.

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 will first check if the dm pm criteria (POCDMPMCRI1) is successful, and if so then it will manipulate the called number with the content of telephoneNumber (adAttribute2 refers to telephoneNumber in our 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 corresponding data is fetched from 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


  • No labels