Session Migration

Understanding Session Migration

This topic describes the session migration feature.

Session Migration Overview

When you enable session migration on two or more Pulse Secure servers, a Pulse Secure Desktop Client (Pulse Client) endpoint can be moved from one location to another and connect to a different Pulse Secure server without providing additional authentication. For example, a user can be connected from home through Pulse Connect Secure, and then arrive at work and connect to Pulse Policy Secure without being reauthenticated. If session migration is not enabled, Pulse Client users must be reauthenticated each time they attempt to access the network through a different Pulse Secure server.

Sessions can be migrated between Pulse Policy Secure and Pulse Connect Secure servers that are in the same IF-MAP federated network: using either the same IF-MAP server, or using IF-MAP servers that are replicas of one another.

The servers must be in the same authentication group. Authentication groups are configured through authentication realms. An authentication group is a string that you define for common usage. You can use authentication groups to group together realms with similar authentication methods. Such as, one authentication group for SecurID authentication, another authentication group for AD. A single gateway can belong to more than one authentication group, with a different authentication group per realm.

The Pulse Secure server to which a user authenticates publishes session information to the IF-MAP server. Other IF-MAP clients in the federated network can use the information to permit access without additional authentication to users.

When a user session is migrated to another Pulse Secure server, the new session information is pushed to the IF-MAP server. The IF-MAP server notifies the authenticating server, and information about the session that existed on the original server is removed leaving only session information about the current authenticating server on the IF-MAP server. The authenticating server removes information about the session from its local session table.

When a session is migrated, realm role-mapping rules determine user access capabilities. You can import user attributes when a session is migrated, or you can configure a dedicated directory server to look up attributes for migrated user sessions. To ensure that session migration retains user sessions, configure a limited access remediation role that does not require a Host Checker policy. This role is necessary because the Host Checker timeout can be exceeded if an endpoint is in hibernation or asleep. With the new remediation role, the user's session is maintained.

If additional Host Checker policies are configured on a role or realm to which a migrated session applies, the policies are performed before allowing the user to access the role or realm. Administrators of different Pulse Secure servers should ensure that Host Checker policies are appropriately configured for endpoint compatibility.

Figure illustrates the task flow for enabling session migration for Pulse Client.

Session Migration and Session Timeout

Session timeout on the authenticating server does not apply to a migrated session. Instead, session start time is applicable. The inbound server evaluates session timeout using the start time of the original session on the original server.

When a user reboots an endpoint for which session migration is enabled, the session is retained for a short time on the server. For sessions on the Pulse Policy Secure, sessions are retained until the heartbeat timeout expires. For Pulse Connect Secure sessions, the idle timeout determines how long the session is retained.

If an endpoint that is connected to a Pulse Policy Secure or Pulse Connect Secure is rebooted and the user does not sign out, when the endpoint is restarted and the user attempts to connect to the same access gateway, Pulse Client resumes the previous session without requesting user credentials if the previous session is still active.

How Session Migration Works

Session migration uses IF-MAP Federation to coordinate between servers.

When a session is established, the authenticating gateway publishes the session information, including a session identifier, to the IF-MAP server. The session identifier is also communicated to the Pulse Client.

When Pulse Client connects to a migrating gateway in the same authentication group, Pulse Client sends the session identifier to the migrating gateway. The migrating gateway uses the session identifier to look up the session information in the IF-MAP server. If the session information is valid, the migrating gateway uses the session identifier to establish a local session for the endpoint that Pulse Client is running on.

The IF-MAP server notifies the authenticating gateway that the user session has migrated, and the authenticating gateway deletes the session information from the IF-MAP server.

Session Migration and Session Lifetime

Session migration is designed to give users maximum flexibility and mobility. Users are no longer tied to the office. The workplace can travel with the user, and electronic chores such as online banking can come to work. Because of this flexibility, users might be away from their machines for long periods of time, allowing their active session to expire. Session migration requires users to have an active session on Pulse Policy Secure or Pulse Connect Secure.

You can adjust session lifetime to ensure that sessions do not time out while users are away from their machines. You adjust session lifetime on the gateway by selecting Users > User Roles > [Role Name] > General > Session Options in the admin console.

Session Migration and Load Balancers

A Pulse Client that connects to a Pulse Secure server that is behind a load balancer will attempt to migrate the network connection if the connected server fails. The Pulse Secure servers must be federated and configured for session migration. For example, a load balancer that balances to 2 Pulse Secure servers (non-clustered) balances to Server1. If Server1 fails, the load balancer then balances to Server2. A Pulse Client that is connected to Server1 is migrated to Server2 without re-authentication.

Authentication Server Support

The behavior of session migration depends to some extent on the authentication server on the inbound side.

The following list provides a summary of authentication server support:

•Local authentication server: Migration succeeds if the username is valid on the local authentication server.

•LDAP server: Migration succeeds if the LDAP authentication server can resolve the username to a distinguished name (DN).

•NIS server: Migration succeeds if the NIS authentication server can find the username on the NIS server.

•ACE server: Migration always succeeds.

•RADIUS server: Migration always succeeds. If you select Lookup Attributes using Directory Server, no attributes are present in the user context data.

•Active Directory: Migration always succeeds. The Lookup Attributes using Directory Server option might not work, depending on your configuration.

•Anonymous: No support for migrating sessions because sessions are not authenticated.

•Siteminder: No support for migrating sessions because Siteminder SSO is used instead.

•Certificate: No support for migrating sessions because sessions are authenticated using certificates.

•SAML: No support for migrating sessions because SAML SSO is used instead.

For local, NIS, and LDAP authentication servers, the inbound username must reflect an existing account.