Directory Service Sync Tool

Cisco Secure Email Cloud Gateway

🚦

Note: Directory Service Sync Tool is currently in Beta. Cisco will work with you to onboard and deploy the needed components for this service.

Cisco offers a Directory Service Sync Tool for Cloud Email Security (CES) customers. The Directory Service Sync tool facilitates LDAP sync and lookups. This is available for EU and US-based Cisco Cloud Email Security customers.

📘

How to request Directory Service Sync Tool

Cisco Cloud Email Security customers can request add-on services to be enabled on their instances:
Directory Service Sync Tool Interest and Sign Up

Architecture

Directory Service / LDAP Query and Response

3140

LDAP DR

  • The Cisco LDAP directory will be implemented in a multi-master cluster spread across at least 3 availability zones. Currently, all 3 availability zones are located in a single region.
  • All Directory servers with the same location will replicate each other using a mesh topology. So if PD1, PD2, and PD3 are all in the same location PD1 will directly forward all mod events it receives to PD2 and PD3.
  • All Directory servers in a location will hold an election to determine which server should act as the Gateway. If a Gateway server becomes unavailable a new server will automatically be assigned the Gateway role.
2304

LDAP Throughput and Connectivity

Throughput

  • The LDAP service is provisioned with 48 cores in AWS
  • Each core is capable of 2500 concurrent LDAP queries
  • The total capacity is 120K concurrent queries (before any local caching)

Connectivity

  • Each CES site has an individual connection over five (5) x /22 networks dedicated to the communications to AWS
  • The allocated bandwidth between CES and the AWS environment is 1.25 Gbps

PingOne Advanced Services

1. Introduction

This document outlines the PingOne Advanced Services (“P1AS”) and PingDirectory architecture design along with configuration detail for the solution provided to Cisco Systems Inc. that will meet the business needs to deploy and leverage P1AS as a Cisco Systems user base solution. This document will have the design for the deployment of PingDirectory on the P1AS platform.

1.1 Purpose and Scope

  • Design and Architect of P1AS Environment with 2 CDEs:
    • Development
    • Production
  • The design will address the details required to build out the consumer users’ solution, including:
    • Solution Architecture Requirements for
      • P1AS environment hosting PingDirectory
  • Networking requirements as relates to integrating P1AS with Cisco Applications for SSO handling

1.2 Reference Documentation

The following documents were used in preparing the deliverables of this project:

2. Proposed Solution

The proposed solution will use PingOne Advanced Services (“P1AS”) and PingDirectory to host a customer's profile from Cisco on-premises/cloud Active Directory using an Ideiio plugin to sync between the two (2) directories.

2.1 Solution Summary

PingOne Advanced Services
P1AS combines two highly sought values in one identity and access management solution. A global authentication authority with highly configurable capabilities, all wrapped in a dedicated cloud environment with data and resource isolation. Within the administration portal for P1AS, certain self-service tasks can be performed and other tasks can be requested via Support Service Requests - further information in relation to tasks can be found here.

PingDirectory
PingDirectory Server (PD) is a high-performance, extensible directory, and part of the Ping Data Platform. It provides seamless data management over a distributed system based on a standardized solution.

2.2 Solution Implementation Risks

  • Improper data or data format on Source directory (i.e., AD)

2.3 Security

Ping Identity provides security guidelines, which should be reviewed as part of the product implementation. For example, the PingDirectory Security Hardening Guide. These documents should be reviewed for proper hardening of the different Ping systems.

For a list/obtainment of the latest Security Hardening Guides, the different documents can be found here.

3. Current State

From the various design sessions that have taken place, Ping Identity Professional Services and Cisco Systems Architecture teams have identified and defined a list of current schema attributes which need to be synced.

3.1 Use Cases from RAD Sessions

Authorization Use Case 1:

  • TBD - Usage of data

4. Proposed Solution

The proposed solution is being split between the product areas that require configuration. The information contained in this section is the generic P1AS information - see the following sections for PingFederate and PingDirectory for specific design considerations.

737

There are several activities that can be managed via the Administration Portal - some of these are activities that the customer can “self-service” and others are requested to be raised via the Ping Support Team - the table below shows some of this below. This can also be found on the Ping Identity documentation website.

:pencil2: Note: PingAccess, PingFederate in the below table are not part of Cisco P1AS Implementation.

1952

Professional Services will help with initial setup including deployment and application onboarding. Additional projects can be arranged at any time for additional use cases or complicated tasks, including custom integration kits, custom data sources, migration projects, application onboarding, or significant changes to the original setup.

4.1 Infrastructure Requirements

The solution will be utilizing P1AS and therefore many infrastructure components will be governed and managed via P1AS and the Ping team. In relation to the high-level overview then please see:

  1. P1AS Infrastructure

Cisco Systems will be provisioned with two (2) environments in Ping’s Cloud:

  • DEV
  • Production
  1. Networking Requirements
  • Designated IP ranges are needed to provision the network connection to specified load balancers and AWS services that are automatically deployed to specific IP endpoints.
  • A /22 corresponds to 1024 addresses or the subnet mask of 255.255.252.0
  • A /22 is needed to connect to each of 5 deployed environments, which include Development, Test, Stage, Production, and a Custom Hub environment that serves as the VPN connection and provides routing to each other environment.
  • This requirement is intentionally designed to handle future increases in AWS services and endpoints that will need to be connected.
  • It is unwise to come close to 100% range utilization as network routing makes some IP addresses unusable.
Public Subnet IP use per Availability Zone(consumed/total)
Public base total (all AZs)75/384
Private base total (all AZs)195/384
CDE total (all AZs)270/768
1440
  1. Networking Connectivity
964
4.1.1 DNS Recommendations

P1AS all resources exposed within P1AS are exposed using a unique DNS name built and maintained so that it can be managed and predictable for the platform. This does not however mean that the customer must use these DNS names. Cisco Systems can create DNS Alias records and point them to the corresponding P1AS DNS names to ensure a branded, consistent, and familiar user experience.

DNS Information will be provided by Cisco.

EnvironmentExisting URLPre-cut over (interim)
DEVpingfederate.dev-cisco.us1.ping.cloudTBD
Productionpingfederate.prod-cisco.us1.ping.cloudTBD

P1AS uses the standard practice of creating URLs as below:

PD Private LDAP = ldaps://pingdirectory-admin.<env>-<customer>.<region>.ping.cloud
PD Private HTTPS = https://pingdirectory.<env>-<customer>.<region>.ping.cloud
PD Public HTTPS (In early access only) = https://ext-pingdirectory.<env>-<customer>.<region>.ping.cloud

In the above URLs, env should be replaced with either a specific value like dev/test/prod, Customer is Cisco and regions are US & EU

4.1.2 Firewall Ports
PingDirectory Traffic
DirectionClientClient LocationOutbound TargetTarget LocationPurposeTransportProtocolServer PortExposed Post
InboundLDAPS ClientCustomer Network, Platform HubAdministration Account SynchronizationTCPLDAPS636636
InboundSCIM Client APICustomer Network, PublicAccount SynchronizationTCPHTTPS443443

4.2 Platform Architecture

P1AS offers web-based administration to manage environments, launch individual administrative interfaces for configuration of solution capabilities, launch environments and create and remove administrators for the solution.

The platform administration interface offers administration in primary regions and child regions. Some functionality is only available in the primary region, individual environments are still managed within each region.

To log in, please refer to: https://docs.pingidentity.com/bundle/pcpt/page/psx1564511069879.html

Console links:
US1 - https://console.us1.pingplatform.cloud/environments

4.3 Logging

As part of the development of PingOne Advanced Services as a platform there are alerting, logging, and monitoring activities that are available currently as well as aspects that will be developed and made available in the future.

Alerting
Enable to be alerted upon specified application-level events. Additional application-level alerting will be defined based on the final configuration and policies implemented by the customer.

SIEM Integration
Support for the push of platform and product log data into SIEM. Logs are streamed via a webhook to a log aggregator of Suez’s choice, such as Splunk, Logstash, and Sumo. PingOne Advanced Single Sign-on logs would include the server.log and the audit.log

P1AS platform logs the server logs and Cisco Systems can request PingDirectory logs directly from the Portal.

Documentation on how to request the logs: https://docs.pingidentity.com/bundle/pingone/page/bha1582045457716.html

Documentation on how to complete the request: https://docs.pingidentity.com/bundle/pcpt/page/tdj1603150814759.html

4.4 Backup and Restore

The backup and restore activities are handled as part of the management of the P1AS platform and infrastructure.

The backup times for the Ping Products that capture the configuration and data associated with the implementation are on a standard basis. Ping Directory will perform full backups every 6 hours. Restores will be handled by the onboarding team before go-live and the global support organization will handle restores post-go-live.

5. PingDirectory Design

5.1 Key Design Decisions

The following are key design decisions for PingDirectory implementation of this project:

  1. Names of custom object classes will be prefixed with “cisco” for all customer users representing custom object classes.
  2. Migration of data into PingDirectory is done via 3rd party product (by Ideiio).
  3. Sync plugin will be during all CRUD operations and will be checked for any data difference between two (2) directories.
  4. No user provision will be happening directly on PingDirectory after go-live.
  5. No customer user password is stored in PingDirectory.

5.2 Directory Information Tree

The following diagram shows how the PingDirectory Directory Information Tree will be modeled:

The following describes the Directory Information Tree design:

  1. All customer users will be migrated to their own application branch.
    For example, all customer users will be placed at this ou “ou=people,ou=customer,ou=Organizations,o=Cisco”.
  2. For each application, there will be a service account associated which will be created under “ou=serviceaccounts,ou=Organizations,o=Cisco”.

5.3 Object Classes

A custom object class “ciscoPerson” will be created to represent all Cisco users. The following diagram shows the inheritance. The custom object class will be created as a structural object class inherited from superclass Top.

232

5.4 Directory Attributes

As part of the migration, each application user will be synced under their own application branches. To have a simple 1-1 mapping between AD & PingDirectory a decision has been made to use default attributes and to keep the attribute naming context the same in PingDirectory. It's been highlighted that the default attributes in PingDirectory are multivalued attributes, and Cisco will be maintaining the Singleness within the PingDirectory.

The following attributes of the "ciscoPerson" object class will be used:

Attribute NameData TypeUnique ConstraintSingle/Multi-ValuedSearchable/Indexed
uidDirectory StringY (Unique within each branch only)SingleY
proxyAddressesDirectory StringYMultiY
mailDirectory StringYMultiY
mailRoutingAddressDirectory StringNMultiN
mailHostDirectory StringNMultiN
mailLocalAddressDirectory StringNSingleN
memberOfDirectory StringN/AN/AY
objectGUIDDirectory StringYSingleN

The complete schema will be captured in a separate document “Cisco-LDAPSchema-SCIM-Definitions.xlsx”

5.5 Data Load

Data will be synced from ActiveDirectory to PingDirectory by using a 3rd party product that will be hosted in the Cisco environment. Ideiio has developed a custom sync product to go with the said third-party product and will be responsible for syncing the data across.

No flat or LDIF files will be used for data migration.

5.6 Data Security

5.6.1 Data Security at Rest

To ensure data is secured at rest, all data stored in PingDirectory will be encrypted using the AES256 encryption algorithm. The encryption key will be generated using a common passphrase provided when generating the encryption key. The same passphrase will be used on all PingDirectory server nodes in a single environment. This will ensure all PingDirectory server nodes within a single environment will have the same encryption key.

5.6.2 Data Security in Transit

To ensure data are secured in transit, only the following secured protocols will be enabled:

  1. HTTPS
  2. LDAPS

PingDirectory will be configured to use SSL certificates issued by the P1AS internal certificate authority. A unique certificate will be issued for each server.

5.7 Replication

The Advanced Services PingDirectory will be implemented in a multi-master cluster spread across at least 3 availability zones. Currently, all 3 availability zones are located in a single region.

All PingDirectory servers with the same location will replicate each other using a mesh topology. So if PD1, PD2, and PD3 are all in the same location PD1 will directly forward all mod events it receives to PD2and PD3.

All PingDirectory servers in a Location will hold an election to determine which server should act as the Gateway. If a Gateway server becomes unavailable a new server will automatically be assigned the Gateway role.

When a Gateway receives a change that was made locally, it will forward that change to all of the other Gateway servers in the cluster.

When a Gateway server receives a change from another Gateway server, it will forward that change to all local servers.

2304

Need help with Directory Service Sync Tool and setup/configuration?

  • You can open a TAC case for assistance with the setup and configuration of the Directory Service Sync Tool: Cisco Support Case Manager