Page History

The SBC Core is enhanced to support supports Flexible Active Directory (AD) functionality for large enterprises with a bigger subscriber base to provide a better call capacity solutionsolutions.

In Enterprise deployments, the ERE retrieves the user information from the Microsoft Active directory database and uses it for call routing and policy decisionsIt is a mechanism to retrieve user/subscriber data, used in call-routing/policy decisions, stored in Microsoft Active Directory (AD), eliminating the need to configure the same again on the SBC/PSX. This reduces the administrative overhead of provisioning and managing the user information at two places. The ERE retrieves the Subscriber subscriber information by querying the Active Directory database, which

The subscriber information includes:

• Subscriber Identity
• Display name
• Home phone number
• Mobile phone number
• Office/Lync phone number

Since LDAP is a known slow response protocol, and hence, the SBC fetches the data from the remote server and stores it in the local database instead of querying real time to the remote server. This data is later used during calls to manipulate various call parameters and use them in routing logic.

As explained above, for Flexible AD to work, the  Flexible AD configurations are classified into two categoriesas follows:

• Configuration to Sync Data from Remote Server
• Synced data use during call processing

Fetching AD Attributes from the AD Server

Fetching the Active Directory attributes involves the following:

• The ERE provides a flexible option to fetch the dynamic AD attributes from the AD server and cached locally.
• When the AD attributes are added or removed, the SBC-ERE fetches the new attributes from the AD server and stores them locally. This procedure does not require any process restarts or system down time.
• The SBC-ERE normalizes (remove space and hyphens) the attribute value, if they are of telephone number format. For example, If the "mobile" AD attribute value is "714-555-5555", the SBC ERE removes the hyphens and store the mobile AD attribute value as "7145555555".
• The SBC-ERE queries the AD server and updates the local cache when a new flexible AD attribute is configured.
• The SBC-ERE supports a configuration of 32 flexible AD attributes.
• Local AD query: The SBC provides a utility to query the locally-stored AD attributes and display the associated AD attributes. For example, The SBC-ERE has a tool/utility to query (only the configured AD attributes) the locally stored AD attributes and display the results.
• The SBC queries the AD attributes that are dynamically configured, and the result displays all the AD attributes associated with the queried AD attribute.
• The SBC-ERE continues processing the call in case the AD lookup / query fails.

DM/PM of AD Attributes

The SBC has a "Transformation Table" that performs number manipulations. This table is configured so that any of the parameters input in the table are modifiable using regular expression or replaced by values of any AD attributes. For example, an AD lookup is done on the Called Number. If it is a success, then the called number is modified to the value that is present in the "mobile" AD attribute or "msRTCSIP" AD attribute received in the AD lookup. Similarly, you can change the calling number to the "displayname" AD attribute. The DM/PM is enhanced to reflect the flex AD attributes that are configured at the SBC-ERE.

The flexible AD attributes are available to the DM/PM rules when AD service is invoked. This is applicable for both "In" and "Out" DM/PM.

Prior to this release, the pre-defined AD attributes in the SBC are available for DM/PM. With the SBC enhancement of flexible AD attributes, the dynamically configured AD attributes are also available for DM/PM.

Flexible AD Attributes for CPFP

The Flexible AD attributes for CPFP involves the following:

• In addition to the pre-defined AD attributes, the flexible AD attributes are options are available at CPFP to influence the routing decisions.
• The flexible AD attributes are dynamically available to CPFP for routing (for example; standard routing , username routing) decisions.
• The SBC-ERE presents the complete calling number for outbound calls to the mobile subscriber who is a part of enterprise. This takes higher precedence than the other outbound calls requirements
• The SBC-ERE uses the "UnixHomeDirectory" AD attribute, if present as the calling number for outbound calls.
• The SBC-ERE uses a desired number as the calling number for outbound calls, if "UnixHomeDirectory" AD attribute is not available.
• The SBC-ERE uses the "info" AD attribute, if present to route the call for the called number.
• The SBC-ERE uses the "msRTCSIP" AD attribute if present to route the call for the called number, provided the "info" AD attribute is not available.
• The SBC-ERE routes the call as per the existing routing mechanism if both "info" and "msRTCSIP" AD attributes are not preset for called number.
• The SBC-ERE uses the management interface to query the AD server
• The SBC-ERE supports VLAN tagging while communicating with the AD server.

Platform Changes

The Flexible AD functionality is applicable for SBC with ERE (SWe and hardware-based).

Capacity Changes

The SBC-ERE supports a minimum of 100,000 subscriber entries.

AD Query Process Flow

The ERE performs the following steps to communicate to the configured Active Directory servers and load the data into the local database.

1.   Fetch the AD Profile information which is enabled.
2.   Fetch the AD Attribute Profile configured in the AD Profile.
3.   Fetch the each domain controller information configured in the AD Profile.
4.   If the useTLS flag is enabled, then openLDAP queries over TLS. 
5.   Perform LDAP query to the domain controller.
6.   Read the LDAP response and format it and write into the file. If the response has more pages, then it reads all the pages, format it and write into the file.
7.   Repeat the step 3 to step 6 for all the domain controllers, if multiple domain controllers are present.
8.   Fetch the postgres database table and load the file containing LDAP response.
9. Update the inUse table name to the new table in AD Profile Status.

AD Sync

The SBC fetches the data from remote server in the following ways:

• Manual Sync - This option is provided to trigger manual sync request on a condition the AD Profile sync attribute is enabled.
• Delayed Sync -This parameter is configured in AD Profile and is a date and time string parameter. This value is always greater than current system time during configuration. So when the system time is equal to the configure date and time, the SBC triggers to fetch the data from remote AD server when the AD Profile sync attribute is enabled.
• Sync Interval – This parameter is configured in the AD Profile and its value is in the range of 60 minutes to 43200 minutes (30 Days). This gets triggered only after a successful sync due to delayed sync configuration.
   For example,
   If the delayed sync is configured as 6^th March, 02.45 AM and sync interval is configured as 1440 minutes (24 hrs),
  then
  the delayed sync is triggered at the time configured and from that time this sync interval time. In other words, 1440 minutes is calculated. So at 7^th March, 02.45 AM the SBC trigger the sync request again. This sync interval triggers the sync operation at regular interval.

For more information to fetch the data from the remote server, refer to < Configuration Guide page.The list of all the required configuration is in this page Flex AD Support SBX-72926 : TOI>

Ad Storage

The SBC queries the Active Directory and gets all the attribute information and stores into the postgres database. These attributes are added dynamically using the json datatype in postgres, allowing the data to be stored in a flexible manner easily accessible. The SBC uses two tables for HA mechanism so that whenever there is an AD sync , the SBC stores into the other table and making that table also accessible.

AD Lookup

A new lookup type and service type is added to Number Translation Criteria (NTC) and service definition respectively. In a prerouter layer, the PES looks for services to be executed. If an AD lookup type matches the service definition,it is executed as follows:

1.   Perform In DM/PM rule configured in the NTC.
2.   Fetch the CallParameterFilterProfile Group configuration and form a dynamic query.
3.   Fetch the data from the inUse ad user info table.
4.   Perform Out DM/PM rule configured in the number translation criteria.
5.   Perform routing.
   
   

 Use Cases

The subscriber information retrieved from Microsoft AD is enabled in the following use cases.

• Forwarding the calls to other numbers of the user based on policy 
• The ERE translates the dialed number with users Home / Mobile or Lync phone numbers for completing the calls based on policy configurations,
• Populating caller Display name
• The ERE queries the display name based on AD users Mobile or Home phone number and set the same in policy response. The called party can see caller name, even when caller name is not set by PSTN network.
• Determining AD Subscriber has Lync voice line or not
• ERE queries the subscriber information to determine, whether user has Lync voice (msRTCSIP-Line) or being served by the PBX infrastructure. This information is then used to route the calls appropriately to Microsoft Lync or ERE.