PingOne for Enterprise

How AD Connect works

AD Connect is a Ping product that enables connections between Microsoft Active Directory (AD) and PingOne for Enterprise.

aze1564020475801

  1. AD Connect connects to PingOne for Enterprise through a WebSocket secure connection on port 443 and authenticates PingOne for Enterprise using SSL.

  2. PingOne for Enterprise authenticates the requesting AD Connect instance using the digital signature.

    AD Connect doesn’t need an SSL certificate. This connection is used for full-duplex communications between PingOne for Enterprise and AD Connect services.

  3. PingOne for Enterprise sends the authentication request to AD Connect using a WebSocket backchannel.

    The PingOne for Enterprise authentication request sent to AD Connect is a token that contains the username and password encrypted with the public key of the selected AD Connect instance.

    Only the intended AD Connect instance can decrypt the request token.

  4. AD Connect validates the username and password with Active Directory and sends a response token back to PingOne for Enterprise.

    The response tokens are only valid for a single use.

High availability and failover

For high availability and failover, you can install multiple instances of AD Connect. The status of the connection for each AD Connect instance is stored in and managed by PingOne for Enterprise. PingOne for Enterprise selects an AD Connect instance to use from the active list of instances and begins sending authentication requests to that instance. The load is balanced among all instances of AD Connect. New instances of AD Connect are added to PingOne for Enterprise’s active list of instances.

AD Connect with IWA

When you install AD Connect, the PingOne for Enterprise admin portal gives you the option to enable integrated Windows authentication (IWA). You specify the IP address or IP range, in IP blocks, for PingOne for Enterprise to use in identifying whether or not a user request is from your organization’s network.

The IP address needs to be (or the IP range needs to include) the IP address of the AD Connect host as identified by PingOne for Enterprise.

You can find the IP address by opening a web browser and searching for my ip.

When IWA is enabled, AD Connect listens on port 80, which doesn’t need to be externally exposed, and PingOne for Enterprise tries to use IWA to authenticate user requests coming from your organization’s network. When PingOne for Enterprise doesn’t use IWA, PingOne for Enterprise prompts the user for their credentials, and validates the credentials using the WebSocket backchannel.

Each user’s initial single sign-on (SSO) to PingOne for Enterprise always uses the WebSocket backchannel, regardless of whether or not the user is located in your organization’s network.

Optional IWA support for AD Connect works like this:

kxk1564020475803

  1. If a user within the defined IP range makes an authentication request, PingOne for Enterprise redirects the user to AD Connect’s IWA page with a token on port 80. If the user is outside of the IP range, they are directed to the PingOne for Enterprise sign on page.

  2. The user authenticates through IWA. AD Connect stores the authentication assertion and any user attributes locally, and redirects the user to PingOne for Enterprise with no data.

  3. PingOne for Enterprise retrieves the authentication assertion from IWA. It does so through the Websocket so it can retrieve the assertion securely even though AD Connect doesn’t use SSL on the IWA page.

  4. PingOne for Enterprise validates the assertion and authenticates the user. If an error occurs, the user is directed to the PingOne for Enterprise sign on page.

AD Connect with IIS

When you use AD Connect with IIS, PingOne for Enterprise directs users to the sign-on page hosted by IIS. The user enters their credentials and AD Connect submits them to Active Directory for authentication.

Because PingOne for Enterprise directs the user to the AD Connect sign-on page in the browser, the identity bridge configuration includes the URL for AD Connect with IIS.

AD Connect with IIS doesn’t use a Websocket backchannel to communicate with PingOne for Enterprise. User authentication takes place in the IIS application, which then generates a SAML assertion that is sent to PingOne for Enterprise through the browser using the redirect or POST protocols. Unlike standalone AD Connect, AD Connect with IIS requires an SSL certificate to authenticate users.

If you use multiple instances of AD Connect with IIS, you must deploy them behind a load balancer. PingOne for Enterprise directs users to the URL of the load balancer for authentication rather than the URL of a specific AD Connect with IIS instance.