Sign-in Policies

Sign-in policies define the URL’s that any user needs to use for accessing the network. PPS provides support for sign-in URL’s for administrators and end users. Administrators can login to PPS using the administrator sign-in URL and configure/monitor the server. The user’s login using the user sign-in URL’s for connecting to the network. The sign-in URL’s are configured with authentication realm so that authentication of the users is performed during the sign-in process. Administrators can also use the custom sign-in pages on the sign-in URL’s so that pages displayed for the users are customized.

Configuring Administrator Sign-In Policies

To configure administrator sign-in policy:

1.Select Authentication > Signing In > Sign-in Policies.

2.To create a new sign-in policy, click New URL. To edit an existing policy, click a URL in the Administrator URLs or the User URLs column.

3.To create an administrator sign-in policy, select the Administrators option button at the top of the page. (By default, the Users option button is selected.)

4.In the Sign-in URL field, enter the URL to associate with the policy. Use the format <host>/<path> where <host> is the hostname of PPS, and <path> is any string users must enter. For example: users1.yourcompany.com/ic. To specify multiple hosts, use the asterisk (*) wildcard character. For instance:

To specify that all administrator URLs must use the sign-in page, enter */admin.

Use wildcard characters (*) only at the beginning of the hostname portion of the URL. The system does not recognize wildcards in the URL path.

5.(Optional) Enter a Description for the policy.

6.From the Sign-in Page list, select the page that you want to associate with the policy. You can select the default page, a variation of the standard sign-in page, or a custom page that you create using the customizable UI feature.

7.For administrator sign-in policies, under Authentication realm, specify which realm maps to the policy, and how users and administrators must choose from among realms. If you select:

•User types the realm name—The system maps the sign-in policy to all authentication realms but does not provide a list of realms from which the administrator can choose. Instead, the administrator must manually enter the realm name into the sign-in page.

•User picks from a list of authentication realms—The system maps the sign-in policy to only the authentication realms that you choose. The system presents this list of realms when the administrator signs in and allows a realm to be chosen from the list. (Note that the system does not provide a list of authentication realms if the URL is mapped only to one realm. Instead, only the realm you specify is displayed).

8.Click the Add button to add available realms to the Selected realms box.

9.Click Save Changes.

Configuring User Sign-In Policies

To create or configure user sign-in policies:

1.Select Authentication > Signing In > Sign-in Policies.

2.To create a new sign-in policy, click New URL. To edit an existing policy, click a URL in the Administrator URLs or User URLs column.

3.In the Sign-in URL field, enter the URL that you want to associate with the policy. Use the format <host>/<path>, where <host> is the host name of PPS, and <path> is any string users must enter. For example: users1.yourcompany.com/ic. To specify multiple hosts, use the asterisk (*) wildcard character. For example, to specify that all end-user URLs must use the sign-in page, enter */.

4.Under Authentication realm, specify the realms that must be mapped to the sign-in policy. Under Available realms, select realms from the menu. The system maps the sign-in policy only to the authentication realms that you add.

5.Under Authentication protocol set, select an authentication protocol set that you have configured previously. If endpoints will connect with a PPS agent, select the default 802.1X protocol set. The protocol set used with a realm must be compatible with the authentication server that is associated with the realm.

6.Click Add to add the new realm and authentication protocol pair.

7.Select the User may specify the realm name as a username suffix check box to allow non- PPS endpoints to access the system by entering their credentials (in the format user@realm).

8.Select the Remove realm suffix before passing to authentication server check box for users to enter their credentials with a suffix to send the username without the suffix. Most authentication servers are not compatible with a realm suffix or decorated username.

9.Click Save Changes.

Associating Authentication Realms and Protocols with User Sign-in Policies

Different types of endpoints can request authentication through PPS, including PPS agents, third-party 802.1X supplicants (including 802.1X IP phones), switches, and endpoints that request authentication with agentless access.

A PPS agent is software that can use the JUAC protocol. PPS agents include Pulse Client client, and the Java agent. By default, PPS can communicate with PPS agents, the Java agent, and endpoints with agentless access. To accommodate other types of endpoint clients, you might need to create authentication protocol sets within sign-in policies.

When you add a realm in a sign-in policy, you select an authentication protocol set to be used with that realm. There are two default authentication protocol sets. For PPS agents, use the default 802.1X authentication protocol set. For 802.1X IP phones, use the default 802.1X-Phones protocol set.

Third-party 802.1X supplicants cannot use the preconfigured 802.1X protocol set that is used by default with PPS agents. For example, some switches can request authentication using CHAP or EAP-MD5-Challenge. You must define a specific authentication protocol set for these requests.

To define an endpoint’s authentication method, you add authentication realms to sign-in policies. You configure authentication protocol sets as required, based on authentication methods that are compatible with the authentication server that you are using. PPS maps the sign-in policy to the authentication realms that you choose. Users who sign in using the URL that you provide have access only to those realms that you specify.

For non- PPS agents, you must select the protocols that the client and the authentication server are compatible with. See the below table for details of what authentication protocols are compatible with different authentication servers.

Protocols	Authentication Servers
	Certificate	Local	Active Directory	ACE	Mac Auth
EAP-GTC	-	-	-	Y	-
PAP	-	Y	Y	Y	-
CHAP, EAP-MD5-Challenge	-	Y	-	-	-
MS-CHAP	-	Y	Y	-	-
MS-CHAP-V2, EAP-MS-CHAP-V2	-	Y	Y	-	-
EAP-TLS	Y	-	-	-	-
Mac-based auth		-	-	-	Y
EAP-JUAC	Y	Y	Y	Y	-

For 802.1X, AD authentication server used as LDAP is not supported for the following protocols: MS-CHAP, MS-CHAP-V2, and EAP-MS-CHAP-V2.

The decision of what realms are available to the user within a sign-in policy is based on two factors. First, the order of realms in the list is considered. Realms at the top of the list are attempted. Second, the authentication protocol set that you choose must be compatible with the client or supplicant.

To determine a compatible realm, the system looks for a RADIUS subprotocol that is compatible with the client or supplicant’s available protocols, and the system automatically selects compatible realms. If the endpoint is using a Pulse Policy Secure agent, the system presents a list of realms. Any realm with both outer and inner protocols that match the outer and inner protocols on the client is considered compatible.

Protocol compatibility does not guarantee authentication. For example, CHAP and EAP-MD-5 challenge sign-in succeeds only if the stored password is retrievable as clear text. In addition, if the client or supplicant is configured with a non-JUAC protocol (for example, the Windows Vista supplicant), the system searches for a realm without TNC Host Checker restrictions, browser restrictions, or certificate restrictions.

If you are configuring a realm for a Windows client, with a Statement of Health Host Checker policy, you must use an authentication protocol set with the EAP-SOH protocol. When you select EAP-SOH in an authentication protocol set, EAP-SOH is always offered first, regardless of protocol ordering.

If an endpoint is using PPS agent software, the system presents the list of realms to the user or administrator when the user signs in and allows the user to choose a realm from the list. The system does not display a list of authentication realms if the URL is mapped only to one realm. Instead, it automatically uses the realm you specify.

For endpoints that use a non- PPS agent, you can select the User may specify the realm name as a username suffix check box. When the user provides a username with a suffix in the format user@realm, the suffix determines the realm assignment. If you do not select this option, the endpoint is assigned to the first realm in the list whose authentication server is a match with the endpoint’s software. For example, if the endpoint’s software is configured for tokens (EAP-Generic Token Card), and if the sign in policy permits EAP-GTC, the endpoint is assigned the first realm in the list whose authentication server supports tokens.

When an 802.1X IP phone connects through a realm with the 802.1X-Phone protocol set selected, the device is automatically directed to the proper realm for authentication based on the compatible protocol.

If you are using inner or outer RADIUS proxy with a selected realm, routing with respect to authentication protocols is different. PPS forwards all traffic to a proxy target, which rejects protocols it does not support. With an outer proxy realm, PPS ignores the authentication protocol set. For an inner proxy realm, the authentication protocol set directs PPS as it negotiates the outer protocol (EAP-PEAP or EAP-TTLS) but does not affect the inner protocol.