AAA Servers AAA Server Overview AAA Traffic Management Using the Local Authentication Server Using Active Directory Using Kerberos SSO Understanding Multidomain User Authentication Understanding Active Directory and Windows NT Group Information Support Importing and Exporting an Active Directory Mode Configuration Using the Anonymous Server Using the Certificate Server Using an LDAP Server Using the LDAP Password Management Feature Using the MAC Address Authentication Server Using an NIS Server Using a RADIUS Server Using an ACE Server Access Control with SAML Server SAML 2.0 Configuration Tasks Using a SiteMinder Server Troubleshooting the SiteMinder Server Configuration Using an SQL Auth Server Troubleshooting Oracle Error Codes Using a Time-Based One-Time Password (TOTP) Authentication Server Configuring HTTP Attribute Server AAA Server Overview This topic includes the following information: Overview Authentication Protocols Used by AAA Servers AAA Server Configuration Task Summary Overview AAA stands for authentication, authorization, and accounting. A AAA server is a database that stores user credentials—username and password—and, in some cases, group information or other user attributes. The authentication results and group or user attribute information are used Pulse Secure access management framework policy decisions. In the Pulse Secure access management framework, the sign-in page, realm, and AAA server configurations are associated. They determine user access and user role. A user submits credentials through a sign-in page, which specifies a realm, which is associated with a AAA server. If the access request meets the realm’s authentication policy, the system forwards the user’s credentials to the associated authentication server. The authentication server’s job is to verify the user’s identity. After verifying the user, the authentication server sends approval. If the realm also uses the server as a directory/attribute server, the AAA server sends the user’s group information or other user attribute information. The access management framework then evaluates the realm’s role-mapping rules to determine the user roles that apply to the session. The PulseSecure access management framework supports the following types of AAA servers: Local—You can create special purpose local databases to manually create user accounts, manage guest user access, permit anonymous access, or manage access based on digital certificates or MAC addresses. External (standards-based)—You can integrate standards-based LDAP and RADIUS servers with the access management framework. In addition to using the backend server for authentication, you can use LDAP group and RADIUS attribute information in role-mapping rules. External (other)—You can integrate compatible versions of popular third-party AAA servers with the access management framework. In addition to using the backend server for authentication, you can use Active Directory group information and SiteMinder attributes in role-mapping rules. In addition, you can use MDM device attributes in role mapping rules. Table 36 is a reference of the AAA servers supported in PPS deployments. Table 36Supported AAA Servers Authentication Protocols Used by AAA Servers Policy Secure supports multiple authentication protocols. The following authentication servers require the protocols listed: Local authentication servers—If the passwords are stored as hashed values, the protocols available are PAP and MS-CHAP v1 with or without EAP. If the passwords are stored as clear text, CHAP and MD5-Challenge are also available. Active directory—The protocols available for inner authentication are PAP, MSCHAP and MS-CHAP v2, with or without EAP. LDAP—CHAP, EAP-MD5-Challenge, MS-CHAP v1, and MS-CHAP v2 protocols can be used with an LDAP authentication server only if the administration password is in clear text. By default, challenge response protocols are disabled for LDAP servers. Use these protocols only with noninteractive devices (for example, phones), as password management is not possible if these protocols are used for authentication. Anonymous authentication server—The anonymous authentication server is not supported with the open protocols. AAA Traffic Management From 9.0R3 release, the PPS Virtual appliances and the Pulse Secure Appliances allow the administrator to choose the communicating interface or the network for each authentication server. This feature allows the AAA traffic across the following interfaces: Physical Internal Physical External Physical Management Virtual ports for Physical Interfaces VLAN ports Virtual Ports on VLAN Interfaces This feature allows to connect to remote supported authentication servers through any interfaces based on the network Topology. The following Authentication server types are supported: LDAP Active Directory RADIUS SiteMinder Configuring AAA Traffic Management Across Interfaces 1.Select Authentication > Auth Servers and configure service provider AAA configurations as needed. Figure 300Configuring AAA Traffic Management Across Interfaces  2.Click Enable Auth Traffic Control. A new window appears. 3.Click Enable Traffic Decoupling to confirm. The page navigates to the Auth server page that displays the options to configure the AAA traffic interfaces. For external port, it enables the external port to respond to incoming RADIUS client requests on the external port as well as communicate with authentication servers through that port. Figure 301Configuring AAA Traffic Management Across Interfaces 4.Select Global setting to use same interface across all supported authentication servers or select Auth Server Level to select the interface for a specific authentication server for the AAA traffic. Figure 302Figure: Global Setting Figure 303Auth Server Level Setting 5.Select the required interface and port from the list. Figure 304Auth Server Level Setting 6.Click Save. AAA Server Configuration Task Summary To integrate an authentication server: 1.Configure the authentication server. Select Authentication > Auth. Servers page and complete the authentication server configuration. 2.Create an authentication realm. Select Users > User Realms or Administrators > Admin Realms and select the authentication server when you complete the authentication realm configuration. Using the Local Authentication Server This topic describes the local authentication server. It includes the following information: Local Authentication Server Overview Configuring the Local Authentication Server Defining Framed-IP Address Managing User Accounts Creating Administrator User Accounts Importing Users from CSV File Local Authentication Server Overview The local authentication server is an authentication database that is built in to PPS. Therefore, it is considered a “local” server in contrast to a third-party enterprise AAA server that is connected over the network. Typically, you create local user accounts for temporary users who do not have accounts on your enterprise AAA servers. Temporary users include lab users or guests, but you might find the local authentication server useful to create temporary accounts for users who are normally verified by an enterprise AAA server that you plan to disable. You also use the local authentication server to create accounts for administrator users, such as system administrators and guest user access managers (GUAM). Although it is common practice to use the local authentication server for administrator accounts, it does not preclude you from using any of the supported third-party enterprise AAA servers in your administrator access management framework. The following authentication protocol sets can be used with the local authentication server: By default, the system uses hashing to store passwords. When using the default, the protocols available are PAP and MS-CHAP v1 with or without EAP. You can enable an option to store passwords as clear text. If you enable this option, CHAP and MD5-Challenge are also available. Configuring the Local Authentication Server You can create multiple local authentication server instances. When you define a new local authentication server, you must give the server a unique name and configure options for passwords and guest users. To create a local authentication server: 1.Select Authentication > Auth. Servers. 2.Select Local Authentication and click New Server to display the configuration page. 3.The Local Authentication Server configuration page. 4.Complete the configuration as described in Table 37. 5.Save the configuration. Figure 305Local Authentication Server Configuration Page Table 37Local Authentication Server Settings
Defining Framed-IP Address The Framed-IP attribute can be used in usecases, such as Access Point Name (APN), which manages the modems in broadband service provider network. APN is added as a RADIUS client and it can authenticate the modem MAC addresses with Pulse Policy Secure and assign IP Addresses associated with respective IP address configured on PPS. To define Framed-IP attribute: 1.Select Authentication > Auth.Servers and select the local authentication server. 2.Under Server Catalog, Click Attributes and create the attributes. For example, IP Address. 3.Navigate to the users page, create new user and set attribute values. 4.Navigate to Endpoint > Network Access > Radius Attributes > RADIUS Return Attributes. 5.Set the Auth Server Catalog Attribute Value (userAttr.Framed-IP). 6.Click Save Changes. Figure 306Attributes Figure 307Return Attributes Creating User Accounts You use the Users page to create local authentication server user accounts. A user account includes a username and password to be used for authentication, as well as other information used for records and account management. To create a local user account: 1.Select Authentication > Auth. Servers. 2.Select the local authentication server to which you want to add a user account. 3.Click the Users tab. 4.Click New to display the configuration page. 5.Complete the configuration as described in Table 38. 6.Save the configuration. Figure 308User Account Configuration Page Table 38User Account Configuration Settings
Managing User Accounts You use the Users page to list, modify, and delete local authentication server user accounts. To manage a user account: 1.Select Authentication > Auth. Servers. 2.Click the link for the authentication server you want to manage. 3.Click the Users tab to display the user accounts table. The user accounts table includes entries for the accounts that have been created. The Last Sign-in Statistic column shows the last successful sign-in date and time for each user, the user’s IP address, and the agent or browser type and version. Use the controls to search for users and manage user accounts: 1.To search for a specific user, enter a username in the Show users named box and click Update. : You can use an asterisk (*) as a wildcard, where * represents any number of zero or more characters. For example, to search for all usernames that contain the letters jo, enter *jo*. The search is case-sensitive. To display the entire list of accounts again, type * or delete the field’s contents and click Update. 2.To limit the number of users displayed on the page, enter a number in the Show N users box and click Update. 3.To edit the user account configuration, click the link in the Username column to display the Update Local User Account page. 4.To terminate the user session and delete the account, select the box next to the user account record and click Delete. Figure 309User Accounts Table
Figure 310Update User Account Configuration Page Creating Administrator User Accounts You use the Admin Users page to create accounts for local authentication server administrators. An administrator user can create, modify, and delete user accounts. The admin users you create on the Admin Users page can view and manage all users that have been added to the local authentication server. In contrast, admin users you create by assigning the GUAM role capability can view and manage only the user accounts they created. To create an administrator user account: 1.Select Authentication > Auth. Servers. 2.Click the link for the 3.Guest Authentication Server you want to manage. 4.Click the Admin Users tab to display the configuration page. 5.Specify a username, select an authentication realm, and click Add to create the administrator user. 6.Save the configuration. Figure 311Admin Users Configuration Page Importing Users from CSV File To bulk import users, or to add/change information about your users, you can use CSV Import feature. Prepare a CSV for import. The mandatory required field's in the CSV is Username, password, you can choose to include additional user information if possible. View our available import fields and their as-sociated formatting requirements in the CSV Import Fields table below. 1.Select Auth Servers > System Local (Administrators, System Local, Guest Authentication) > Users 2.Click the Browse button to select the CSV file 3.Enable Overwrite users to overwrite users with the same username if required. If the username exists in the local database before importing, enabling the overwrite opton will delete the old entry and re-place with the newer entry present in the CSV file. The CSV import allows you to import users in bulk with the following fields. Note that the header fields in your CSV must precisely match as shown in the CSV Fields column below in order for your import to be successful. CSV Import Fields
Using Active Directory This topic describes integration with the Microsoft® Windows® platform Active Directory™ service. It includes the following information: Microsoft Windows Platform Active Directory Service Overview Configuring Authentication and Authorization with Active Directory Service (Standard Mode) Displaying the User Accounts Table Microsoft Windows Platform Active Directory Service Overview This section describes support for using PPS with the Active Directory AAA service. It includes the following sections: Understanding Active Directory Active Directory Feature Support Interoperability Requirements and Limitations Understanding Active Directory Active Directory is a directory service used in Windows domain networks. It is included in most Windows server operating systems. Enterprise servers that run Active Directory are called domain controllers. An Active Directory domain controller authenticates and authorizes users and computers in a Windows domain network. When you use Active Directory as the authentication and authorization service for your Pulse Secure access management framework, users can sign in to PPS using the same username and password they use to access their Windows desktops. You can also use Active Directory group information in role mapping rules. From 9.1R1 onwards, Active Directory Legacy Mode configuration will not be supported. If you have an existing Active Directory authentication server using Legacy Mode, first migrate to Standard Mode and then upgrade PPS. For the detailed migration procedure, refer KB40430 Active Directory Feature Support Pulse Secure access management framework supports the following Active Directory features: Honors trust relationships in Active Directory and Windows NT environments. Supports Domain Local Groups, Domain Global Groups, and Universal Groups defined in the Active Directory forest. Supports use of Kerberos, NTLMv2, and NTMLv1 authentication protocols. Supports user principal name (UPN) format for usernames. This support is available for Web log in, PPS at Layer 3, and EAP-MS-CHAP v2. Interoperability Requirements and Limitations The following limitations apply to interoperability with Active Directory: The Pulse Secure access management framework uses Active Directory security groups, not distribution groups. Security groups allow you to use one type of group for not only assigning rights and permissions, but also as a distribution list for e-mail. Each Active Directory configuration you create for the Pulse Secure access management framework should use a different and unique machine account name. If the current Active Directory domain controller is not reachable, the user or machine authentication requests fail for a few seconds (less than 2 minutes) before attempting to authenticate users with another domain controller in the Active Directory domain. We do not support interoperation with Active Directory implementations that use the equal sign operator (=) in a group name, such as: "\=THIRD FLOOR GROUP". The Pulse Secure access management framework authentication process involves search operations that use the equal sign operator (=) when parsing server catalogs to retrieve group names, usernames and domain names, as well as user_SID and domain_SID values. You might encounter unexpected behavior that can affect normal processing of authentication services if a group name configured on your Active Directory server includes an equal sign operator (=). Active Directory versions Windows 2008, Windows 2018 R2 and later use a dynamic port range. The default start port is 49152 and the default end port is 65535. Therefore, if there is a firewall between the Pulse Secure service and the Active Directory Service, you must increase the remote procedure call (RPC) port range on the firewall. See Microsoft Knowledge Base article 929851. The Pulse Secure password management feature, which enables users to change their Active Directory passwords through the Pulse Secure service Web server, is not supported for users of trusted domains that do not trust the domain specified in the Pulse Secure Active Directory configuration. UPN format for user log in is not supported for MS-CHAP v2. Understanding the Active Directory Standard Configuration Active Directory standard configuration supports interoperability with any version of Active Directory, and is the required configuration mode to support authentication using MS-CHAP v2 with Windows 2008 R2 Active Directory Service. Machine authentication, for example, uses MS-CHAP v2. Configuring Authentication and Authorization with Active Directory Service (Standard Mode) To configure integration with Active Directory Service (standard mode): 1.Select Authentication > Auth. Servers 2.Select Active Directory / Windows NT and click New Server to display the configuration page. 3.Select Active Directory mode and complete the configuration as described in Table 39. 4.Save the configuration. Table 39Active Directory Mode Settings
You can troubleshoot the configurations using the Troubleshooting Tab for the respective server. You will be able to view this option on configuring the respective server. Using the troubleshooting option, you can validate: Domian Joint Status Authentication sucess status DNS Look-up for the respective servers Authentication Statistics Using Kerberos SSO This topic includes the following information: Kerberos SSO Support Overview Requirements and Limitations Enabling Kerberos SSO Kerberos SSO Support Overview Kerberos single sign-on (SSO) is a method of access control that allows a user to log in once to the client desktop without being prompted again for credentials. The Kerberos SSO feature uses Kerberos authentication to automatically sign in users with the same credentials they used to access their Windows desktops. After you configure Kerberos SSO, the sign-in dialog box does not appear to users. Requirements and Limitations The following requirements and limitations apply to the Kerberos SSO implementation: The SSO feature requires a Windows NT Primary Domain Controller (PDC) or Active Directory for user authentication. The Kerberos SSO feature is not supported on Windows NT Server 4.0 or earlier The clocks on PPS and the Windows Active Directory authentication server must be synchronized to within 2 minutes of each other. The Active Directory controller must be deployed in front of PPS. The Windows endpoint computers must be joined to the same domain that PPS uses for authentication. Alternatively, make sure the Windows endpoint computers are joined to a domain that has a trust relationship with the domain that PPS uses for authentication. Users must sign into their endpoint computers in the domain of the Windows Active Directory authentication server or in a trusted domain. The realm Enable SSO option is visible only if the Windows Active Directory authentication server is used for authenticating users of the selected realm. Enabling Kerberos SSO To enable Kerberos SSO: 1.Select Authentication > Auth. Servers. 2.Select New Active Directory / Windows NT and click New. 3.Complete the configuration. Enable the Kerberos authentication protocol option. 4.Configure the realm: Select Administrators > Admin Realms or Users > User Realms. Specify the realm that must use the Active Directory server to authenticate and authorize administrators and users. Select Administrators > Admin Realms > Select Realm > Authentication Policy > SSO to ensure that the Enable SSO option is enabled (the default). Understanding Multidomain User Authentication This topic provides an overview of multi domain user authentication with Active Directory and Windows NT. It includes the following information: Multi-Domain User Authentication Overview Windows NT User Normalization Kerberos Support Windows NT4 Support Multi-Domain User Authentication Overview The Pulse Secure access management framework allows for multidomain Active Directory and Windows NT authentication. The system authenticates users in the domain that you configure, users in child domains, and users in all domains trusted by the configured domain. Users in the default domain can sign into the system using just their username, or the default domain and the username in the format default-domain\username. When you enable trusted domain authentication, users in trusted or child domains can sign in using the name of the trusted or child domain and the username in the format trusted-domain\username. Note that enabling trusted domain authentication adds to the server response time. Windows NT User Normalization To support multidomain authentication, the Pulse Secure access management framework uses “normalized” Windows NT credentials when it contacts an Active Directory or Windows NT4 domain controller for authentication. Normalized Windows NT credentials include both the domain name and the username: domain\username. Regardless of how the user signs in (either using just a username or using the domain\username format), the access management framework always processes the username in domain\username format. When a user signs in using only their username, the access management framework normalizes their Windows NT credentials as default-domain\username. Authentication succeeds only if the user is a member of the default domain. When a user signs in using the domain\username format, the access management framework attempts to authenticate the user as a member of the domain the user specifies. Authentication succeeds only if the user-specified domain is a trusted or child domain of the default domain. If the user specifies an invalid or untrusted domain, authentication fails. Two variables, <NTUser> and <NTDomain>, allow you to individually refer to Windows NT domain and username values. The system populates these two variables with the Windows NT domain and username information. In role mapping rules, when you specify USER = someusername, the system treats this rule semantically as NTUser = someusername AND NTDomain = defaultdomain. Kerberos Support We recommend you configure the Pulse Secure access management framework to use the Kerberos authentication protocol with Windows domain controllers. When a user logs in to the system, the system performs Kerberos authentication and attempts to fetch the Kerberos realm name for the domain controller, as well as all child and trusted realms, using LDAP calls. You can use Kerberos differently. You can specify the Kerberos realm name when configuring an Active Directory authentication server. We do not recommend this method for two reasons: You cannot specify more than one realm name. The system cannot then authenticate against child or trusted realms of the realm you specify. If you misspell the realm name, the system cannot authenticate users against the proper realm. Windows NT4 Support The Pulse Secure access management framework does not support Kerberos-based authentication in Windows NT4 domain controllers. The system uses NTLM with a backend Windows NT4 domain controller. Understanding Active Directory and Windows NT Group Information Support This topic describes support for polling group information from Active Directory and Windows NT servers. It includes the following information: Active Directory Group Information Overview Windows NT4 Group Information Overview Active Directory Group Information Overview The Pulse Secure access management framework supports user group lookup in Domain Local, Domain Global, and Universal groups in the default domain, child domains, and all trusted domains. The system obtains group membership using one of three methods that have different capabilities: Group information in User’s Security Context—Returns information about the user’s Domain Global groups. Group information obtained using LDAP search calls—Returns information about the user’s Domain Global groups and about the user’s Universal groups if the access management framework queries the Global Catalog Server. Group information using native RPC calls—Returns information about the user’s Domain Local Group. With respect to role-mapping rules, the system attempts group lookup in the following order: Checks for all Domain Global groups using the user’s security context. Performs an LDAP query to determine the user’s group membership. Performs an RPC lookup to determine the user’s Domain Local group membership. Windows NT4 Group Information Overview The Pulse Secure access management framework supports group lookup in the Domain Local and Domain Global groups created in the default domain, as well as all child and other trusted domains. The system obtains group membership using: Domain Global group information from the user’s security context. Domain Local information using RPC calls. In the Windows NT4 environment, the system does not use LDAP-based search calls. Importing and Exporting an Active Directory Mode Configuration You can use the Maintenance > Import/Export > Import/Export users page to copy an Active Directory mode configuration from one system to another. If Active Directory credentials for joining a domain are not stored in the exported configuration, you must update the configuration to specify them. Push configuration is not supported for Active Directory mode configurations. XML Import/Export for the Active Directory mode configuration has limitations. An XML exported Active Directory configuration (standalone/cluster) can be imported to the same system from which it is exported. However, an XML exported Active Directory configuration from a standalone configuration cannot be imported into a cluster configuration. Similarly, an XML exported Active Directory configuration from a cluster cannot be imported into a standalone configuration. It is not recommended that you import a configuration into a different system than the one from which the configuration was exported. Although the import operation will be successful, the importing system will join the AD domain with the same computer name as the exporting system. When this occurs, the Active Directory disconnects the earlier join from the exporting system. To work around this, modify the value of the computer-name parameter in the XML file to be unique and then import it to another system. In cluster configurations, in addition to modifying the computer-name parameter, also modify the node parameter for each cluster member to match with the importing cluster node names. Here are the parameters you must change before importing the XML configuration file of Active Directory: <nodenames> <node>clusternode1</node> <computer-name>computer1</computer-name> </nodenames> <nodenames> <node>clusternode2</node> <computer-name>computer2</computer-name> </nodenames> You must specify the clear text password within <password-cleartext> </password-cleartext> tags, in place of <user-password-encrypted> </user-password-encrypted> tags, before you perform an XML Import of an Active Directory mode configuration. Using the Anonymous Server This topic describes integration with the anonymous server. It includes the following information: Anonymous Server Overview Configuring Authentication with the Anonymous Server Monitoring Anonymous User Sessions Anonymous Server Overview This section describes support for using PPS with the anonymous server. It includes the following sections: Understanding the Anonymous Server Anonymous Server Feature Support Interoperability Requirements and Limitations Understanding the Anonymous Server The anonymous server is a local authentication server that allows any user to access the system without providing a username and password. Instead, when a user enters the URL of a sign-in page that is configured to authenticate against an anonymous server, the PPS access management framework bypasses the standard sign-in page and immediately displays the welcome page to the user. Anonymous Server Feature Support PPS access management framework supports the following anonymous server features: Enables guest access without username or password Supports Host Checker scans before allowing a guest device to connect to the network Supports firewall enforcement roles and policies to limit the resources available to the guest user Interoperability Requirements and Limitations The following limitations apply to the anonymous server configuration and logging: You can add only one anonymous server configuration. You cannot create an administrator realm that uses the anonymous server. Anonymous administration is not allowed. During configuration, you must choose the anonymous server as both the authentication server and the directory or attribute server in the Users > User Realms > General tab. For security reasons, you might want to limit the number of users who sign in through an anonymous server at any given time. To do this, use the option on the Users > User Realms > [Realm] > Authentication Policy > Limits tab (where [Realm] is the realm that is configured to use the anonymous server to authenticate users). Configuring Authentication with the Anonymous Server To configure authentication with the anonymous server: 1.Select Authentication > Auth. Servers. 2.Select Anonymous Server and click New Server to display the configuration page. 3.Save the configuration. Monitoring Anonymous User Sessions The purpose of the anonymous server is to enable unauthenticated access. Therefore, the system does not maintain session tables, and the Anonymous Server configuration page does not have a corresponding Users tab. The system does maintain user access logs for anonymous access. The username is recorded in the user access log as “AnonUser1234”. If the user is logging in using the agentless access method, the user access log records the host’s IP address. You can view the User Access Log file by navigating to System > Log/Monitoring. Figure 312User Access Log Using the Certificate Server This topic describes integration with the certificate server. It includes the following information: Certificate Server Overview Configuring Authentication with the Certificate Server Displaying the User Accounts Table Certificate Server Overview This section describes support for using PPS with the certificate server. It includes the following sections: Understanding the Certificate Server Feature Support Interoperability Requirements and Limitations Understanding the Certificate Server The certificate server is a local server that allows user authentication based on the digital certificate presented by the user without any other user credentials. When you use a certificate server, the user experience is similar to anonymous authentication. If the certificate is secured through a hardware or a software token or through a password, the certificate server authentication is very useful. The certificate contains the full distinguished name (DN) and the system extracts the values from the DN and uses it for role mapping rules, authentication policies, and role restrictions. Feature Support The Pulse Policy Secure(PPS) access management framework supports the following certificate server features: Certificate directory services to retrieve user attributes in role mapping rules, authentication policies, and role restrictions. Load CA-created certificates on the system. Load multiple certificates from different CAs for use with different authentication realms. Interoperability Requirements and Limitations If you choose a certificate attribute with more than one value, the system uses the first matched value. For example, if you enter <certDN.OU> and the user has two values for the attribute (ou=management, ou=sales), the system uses the “management” value. To use all values, add the SEP attribute to the variable. For example, if you enter <certDN.OUT SEP=”:”> the system uses “management:sales”. Configuring Authentication with the Certificate Server To configure authentication with the certificate server: 1.Select Authentication > Auth. Servers. 2.Select Certificate Server and click New Server to display the configuration page. 3.Complete the configuration as described in Table 40. 4.Save the configuration. Figure 313Certificate Server Configuration Page Table 40Certificate Server Settings
Displaying the User Accounts Table To display user accounts: 1.Select Authentication > Auth. Servers. 2.Click the link for the authentication server you want to manage. 3.Click the Users tab to display the user accounts table. The user accounts table includes entries for the accounts that have been created. The Last Sign-in Statistic column shows the last successful sign-in date and time for each user, the user’s IP address, and the agent or browser type and version. 4.Use the controls to search for users and manage user accounts: To search for a specific user, enter a username in the Show users named box and click Update. You can use an asterisk (*) as a wildcard, where * represents any number of zero or more characters. For example, to search for all usernames that contain the letters jo, enter *jo*. The search is case-sensitive. To display the entire list of accounts again, type * or delete the field’s contents and click Update. To limit the number of users displayed on the page, enter a number in the Show N users box and click Update. To terminate the user session and delete the account, select the check box next to the user account record and click Delete. Using an LDAP Server This topic describes integration with the LDAP server. It includes the following information: LDAP Server Overview Configuring Authentication with an LDAP Server Displaying the User Accounts Table LDAP Server Overview This section describes support for using PPS with the LDAP server. It includes the following sections: Understanding LDAP Server LDAP Feature Support Interoperability Requirements and Limitations Understanding LDAP Server Lightweight Directory Access Protocol (LDAP) facilitates the access of online directory services. The Internet Engineering Task Force (IETF) designed and specified LDAP as a better way to make use of X.500 directories, having found the original Directory Access Protocol (DAP) too complex for average Internet clients to use. LDAP is a relatively simple protocol for updating and searching directories running over TCP/IP. LDAP directory consists of a collection of attributes with a name, known as a distinguished name (DN). Each of the entry’s attributes, known as a relative distinguished name (RDN), has a type and one or more values. The types are typically mnemonic strings, such as CN for common name. The valid values for each field depend on the types. The full DN is constructed by stringing together RDNs from most specific to least specific, separated by commas, as shown in the following example: cn=Bob_Employee, ou= account_mgr, o=sales, dc=Acme,dc=com. LDAP Feature Support Pulse Secure access management framework supports the following LDAP features: LDAP directory services to retrieve user attributes and group membership in role mapping rules Encrypted connections to the LDAP server using LDAP over SSL (LDAPS) or Start Transport Layer Security (TLS) Password management feature enabling users who access an LDAP server to manage their passwords using the policies defined on the LDAP server Fine-grained password policy (FGP) for Active Directory 2008 Interoperability Requirements and Limitations The following limitations apply to interoperability with LDAP: By default, challenge response protocols are disabled for LDAP servers. Use these protocols only with noninteractive devices (for example, phones), as password management is not possible if these protocols are used for authentication. To use the CHAP, EAP-MD5-Challenge, MS-CHAP-V1, and MS-CHAP-V2 protocols, the LDAP server must store the user’s password in clear text. Backup LDAP servers must be the same version as the primary LDAP server. Also, we recommend that you specify the IP address of a backup LDAP server instead of its hostname, which might accelerate failover processing by eliminating the need to resolve the hostname to an IP address. Configuring Authentication with an LDAP Server To configure authentication with an LDAP server: 1.Select Authentication > Auth. Servers. 2.Select LDAP Server and click New Server to display the configuration page. 3.Complete the configuration as described in Table 41. 4.Save the configuration. Figure 314LDAP Server Configuration Page Table 41LDAP Server Settings
Displaying the User Accounts Table To display user accounts: 1.Select Authentication > Auth. Servers. 2.Click the link for the authentication server you want to manage. 3.Click the Users tab to display the user accounts table. The user accounts table includes entries for the accounts that have been created. The Last Sign-in Statistic column shows the last successful sign-in date and time for each user, the user’s IP address, and the agent or browser type and version. 4.Use the controls to search for users and manage user accounts: To search for a specific user, enter a username in the Show users named box and click Update. You can use an asterisk (*) as a wildcard, where * represents any number of zero or more characters. For example, to search for all usernames that contain the letters jo, enter *jo*. The search is case-sensitive. To display the entire list of accounts again, type * or delete the field’s contents and click Update. To limit the number of users displayed on the page, enter a number in the Show N users box and click Update. To terminate the user session and delete the account, select the check box next to the user account record and click Delete. Using the LDAP Password Management Feature This topic describes support and limitations for LDAP password management. It includes the following information: LDAP Password Management Feature Overview Enabling LDAP Password Management LDAP Password Management Support LDAP Password Management for Windows AD Versions Troubleshooting LDAP Password Management LDAP Password Management Feature Overview The password management feature enables users who access an LDAP server to manage their passwords through the Pulse Secure access management framework using the policies defined on the LDAP server. For example, if a user tries to sign in to the system with an LDAP password that is about to expire, the system notices the user through the interface, and then passes the user’s response back to the LDAP server without requiring the user to sign in to the LDAP server separately. Users, administrators, and help desk administrators who work in environments where passwords have set expiration times may find the password management feature very helpful. If users are not informed that their passwords are about to expire, they can change them themselves through the system rather than call the help desk. Once this feature is enabled, the system performs a series of queries to determine user account information, such as when the user’s password was last set, whether the account is expired, and so on. The Pulse Secure access management framework does this by using its internal LDAP or Samba client. Many servers, such as Microsoft Active Directory or Sun iPlanet, offer an Administrative Console to configure account and password options. LDAP-based password management works with only three types of LDAP servers: Microsoft Active Directory. For Active Directory, password policy attributes can be configured in the user entry container level or any organization level above the user container. If these attributes are configured at multiple levels, the level closest to the user node takes precedence. The password management feature is not supported on the Active Directory Global Catalog because password policy attributes are not fully populated in the Active Directory Global Catalog. For Active Directory 2008, the Pulse Secure access management framework supports the Fine Grained Password Policy (FGP) configured in the AD user container. Sun Microsystems iPlanet Novell eDirectory LDAP-based password management does not work on generic LDAP servers such as OpenLDAP. The system relies on the back-end server to pinpoint the cause of error when a password change operation fails. However, although LDAP servers may report errors accurately to human operators, they do not always do so when communicating programmatically to systems. Therefore, reported errors might be generic or cryptic. The system does not support customized password policies. Enabling LDAP Password Management To enable password management, you must first create an instance of the LDAP server. Next, you associate the LDAP server with the applicable realms. Finally, you select the enable password management feature at the realm level. LDAP Password Management Support The Pulse Secure access management framework supports password management with the following LDAP directories: Microsoft Active Directory/Windows NT Sun iPlanet Novell eDirectory Generic LDAP directories, such as IBM Secure Directory and OpenLDAP The below table describes supported password management functions, their corresponding function names in the individual LDAP directories, and any additional relevant details. These functions must be set through the LDAP server itself before the system can pass the corresponding messages, functions, and restrictions to end users. The Active Directory attribute names shown are specific to the Domain Security Policy object. Similar attributes for the corresponding functions are used for the Active Directory 2008 Fine-Grained Password Policy. Refer to Microsoft documentation for details. When authenticating against a generic LDAP server, such as IBM Secure Directory, the system supports only authentication and allowing users to change their passwords. Password management functions are not supported when the CHAP family protocols are used for authentication. All functions are available when the JUAC protocol is used for authentication. Table 42Supported Password Management Functions
Note the following expected behavior: When you select the User must change password after reset option on the iPlanet server, you must also reset the user password before this function takes effect. This issue is a limitation of iPlanet. The system displays a warning about password expiration only if the password is scheduled to expire in 14 days or less. The system displays the message during each sign-in attempt. The warning message contains the remaining number of days, hours, and minutes that the user has to change the password before it expires on the server. The default value is 14 days, but you can change it on the password configuration page of the admin console. LDAP Password Management for Windows AD Versions The Pulse Secure access management framework supports password management with the following Windows servers: Microsoft Active Directory 2008 Microsoft Active Directory 2003 Windows NT 4.0 Table 43 describes supported password management functions. These functions are not supported for a layer 2 connection when CHAP, MS-CHAP, or PAP are used as authentication protocols. Table 43AD/NT Password Management Matrix
Note the following expected behavior: Changes on the Active Directory domain security policy can take 5 minutes or longer to propagate among Active Directory domain controllers. Additionally, this information does not propagate to the domain controller on which it was originally configured for the same time period. This issue is a limitation of Active Directory. When changing passwords in Active Directory using LDAP, the system automatically switches to LDAPS, even if LDAPS is not the configured LDAP method. To support LDAPS on the Active Directory server, you must install a valid SSL certificate into the server’s personal certificate store. The certificate must be signed by a trusted CA, and the CN in the certificate’s Subject field must contain the exact hostname of the Active Directory server, (for example: adsrv1.company.com). To install the certificate, select the Certificates Snap-In in the Microsoft Management Console (MMC). The Account Expires option in the User Account Properties tab only changes when the account expires, not when the password expires. Microsoft Active Directory calculates the password expiration using the Maximum Password Age and Password Last Set values retrieved from the User object and Fine-Grained Password Policy objects or the Domain Security Policy LDAP objects. The system displays a warning about password expiration only if the password is scheduled to expire in 14 days or less. The system displays the message during each sign-in attempt. The warning message contains the remaining number of days, hours, and minutes that the user has to change the password before it expires on the server. The default value is 14 days, but you can change it on the password configuration page of the admin console. Troubleshooting LDAP Password Management When you troubleshoot, provide any pertinent system logs, server logs, configuration information, and a TCP trace from the system. If you are using LDAPS, switch to the “Unencrypted” LDAP option LDAP server configuration while taking the LDAP TCP traces. Using the MAC Address Authentication Server This topic describes how to use the MAC address authentication server. It includes the following information: MAC Address Authentication Server Overview Displaying the User Accounts Table MAC Address Authentication Server Overview This section describes PPS MAC address authentication solution. It includes the following sections: Understanding MAC Address Authentication MAC Address Authentication Server Feature Support Interoperability Requirements and Limitations MAC Address Authentication Framework Configuration Overview 802.1x Framework Configuration Overview Ethernet Switch MAC Address Authentication Configuration Overview Understanding MAC Address Authentication MAC address authentication is port-based security typically deployed at the edge of the network to enable secure access for non-user devices, such as IP phones, printers, and network attached storage devices. The Pulse Secure MAC address authentication solution uses PPS 802.1x framework. When a device connects to a switch, the switch forwards the MAC address as the log in credential to PPS RADIUS server. With MAC-based authentication, the MAC address serves as both the username and the password. The RADIUS server consults the authentication server and sends back a RADIUS return attribute based on authentication results. BEST PRACTICE: MAC-based authentication is not as secure as agent access or agentless access authentication. MAC addresses are not generally guarded as secrets, so an attacker can spoof a MAC address and impersonate a device to gain network access. To reduce risk of an exploit, create a special VLAN for each device type. MAC Address Authentication Server Feature Support The MAC address authentication server is a local authentication server that supports both a local database of records and integration with LDAP servers. You can add entries manually or by reference to LDAP servers. The address table for each local MAC address authentication server is limited to 500 entries. We recommend you use LDAP for large-scale projects. Interoperability Requirements and Limitations Integration with an LDAP server requires the LDAP server to communicate with PPS internal interface. MAC Address Authentication Framework Configuration Overview The MAC address authentication framework is similar to the user access management framework. It involves configuration of a MAC address authentication server, MAC address realm, and roles. To implement the MAC address authentication framework: 1.If necessary, use the Authentication Protocols Sets page to add the protocols that your Ethernet switches use for MAC authentication to PPS 802.1x protocol set. Select Authentication > Signing In > Authentication Protocols Sets. The HP and Cisco switches can use CHAP and EAP-MD5-Challenge protocols for MAC address authentication with the username (the MAC address) as the clear text password. By default, the Nortel switch uses PAP, with a password in the format .<MAC Address>. We recommend using PAP with the Nortel switch. 2.Create LDAP server configurations for the external LDAP servers used to maintain MAC address records. 3.Create a MAC address authentication server. 4.Create Users. Radius Return Attributes from the dictionaries is pre-populated to the Server Catalog of MAC Auth server so that they are available under the custom attributes for a specific user. 5.Create roles for agentless access. 6.Create a MAC address authentication realm that uses the MAC address authentication server and role mapping rules that sort MAC address authentication requests into roles according to your security policy design. 802.1x Framework Configuration Overview The MAC address authentication solution uses Pulse Policy Secure 802.1x framework. To implement the 802.1x framework: 1.Complete the Location Group configuration. 2.Complete the RADIUS Client configuration. 3.Complete the RADIUS Return Attributes Policy configuration. Ethernet Switch MAC Address Authentication Configuration Overview The MAC address solution depends on the Ethernet switch configuration. To configure MAC address authentication on the Ethernet switch: 1.Configure the switch as an 802.1x authenticator and enable MAC RADIUS protocols. 2.Configure RADIUS client communication with PPS RADIUS server. 3.Configure Ethernet switching options and VLANs to provision VLANs for non-user devices. Configuring the EX Series Switch The nonsupplicant devices, such as VoIP phones, connect to the network through an EX Series switch using MAC RADIUS authentication. You configure the following EX Series features to support this solution: Configure the switch as an 802.1x authenticator and enable MAC RADIUS protocols. Configure RADIUS client communication with PPS RADIUS server. Configure Ethernet switching options and VLANs to provision a VLAN for VoIP phones. The following example shows commands that configure the ge-0/1/0.0 and ge-0/1/1.0 interfaces as 802.1x authenticators, enable MAC RADIUS protocols, and create a reference to the authentication profile used for integration with PPS RADIUS server: set protocols dot1x authenticator authentication-profile-name pulsesecure-access-profile set protocols dot1x authenticator interface ge-0/1/0.0 supplicant multiple set protocols dot1x authenticator interface ge-0/1/0.0 transmit-period 15 set protocols dot1x authenticator interface ge-0/1/0.0 mac-radius set protocols dot1x authenticator interface ge-0/1/0.0 maximum-requests 2 set protocols dot1x authenticator interface ge-0/1/0.0 server-fail vlan-name enterprise set protocols dot1x authenticator interface ge-0/1/1.0 supplicant multiple set protocols dot1x authenticator interface ge-0/1/1.0 quiet-period 5 set protocols dot1x authenticator interface ge-0/1/1.0 transmit-period 15 set protocols dot1x authenticator interface ge-0/1/1.0 mac-radius set protocols dot1x authenticator interface ge-0/1/1.0 supplicant-timeout 15 set protocols dot1x authenticator interface ge-0/1/1.0 maximum-requests 2 set protocols dot1x authenticator interface ge-0/1/1.0 guest-vlan guest set protocols dot1x authenticator interface ge-0/1/1.0 server-reject-vlan vlan-name guest set protocols dot1x authenticator interface ge-0/1/1.0 server-fail vlan-name enterprise The following example shows commands that configure the access profile for PPS RADIUS server and the RADIUS client connection to it: set access radius-server 10.0.1.5 port 1812 set access radius-server 10.0.1.5 secret "$9$JLZHmzF/t0I69Icrv7N24aZikmfT3/C" set access radius-server 10.0.1.5 timeout 5 set access radius-server 10.0.1.5 retry 3 set access profile pulsesecure-access-profile authentication-order radius set access profile pulsesecure-access-profile radius authentication-server 10.0.1.5 set access profile pulsesecure-access-profile radius accounting-server 10.0.1.5 set access profile pulsesecure-access-profile accounting order radius The following example shows commands that configure the Ethernet switching options and VLAN used for VoIP phones: set ethernet-switching-options voip interface ge-0/0/10.0 vlan VoIP_Phone set ethernet-switching-options voip interface ge-0/0/11.0 vlan VoIP_Phone set ethernet-switching-options voip interface ge-0/0/8.0 vlan VoIP_Phone set ethernet-switching-options voip interface ge-0/0/9.0 vlan VoIP_Phone set ethernet-switching-options voip interface ge-0/0/6.0 vlan VoIP_Phone set ethernet-switching-options voip interface ge-0/0/7.0 vlan VoIP_Phone set ethernet-switching-options voip interface ge-0/0/4.0 vlan VoIP_Phone set ethernet-switching-options voip interface ge-0/0/5.0 vlan VoIP_Phone set ethernet-switching-options voip interface ge-0/1/0.0 vlan VoIP_Phone set ethernet-switching-options voip interface ge-0/1/1.0 vlan VoIP_Phone set vlans VoIP_Phone description "VoIP Phones" set vlans VoIP_Phone vlan-id 5 The following example shows the complete configuration hierarchy for the Ethernet switch configuration: system { host-name Demo_EX; root-authentication { encrypted-password "$1$OOuTCh1K$/Z6JTJ/I9BnjTsKAoefLS."; ## SECRET-DATA } log in { user admin { full-name Administrator; uid 2000; class super-user; authentication { encrypted-password "$1$RKLp.iDP$m//eueOcF.rExsnQXuZNb/"; ## SECRET-DATA } } } services { ssh; telnet; web-management { http; } } syslog { user * { any emergency; } file messages { any notice; authorization info; } } } chassis { alarm { management-ethernet { link-down ignore; } } } interfaces { ge-0/0/0 { unit 0 { family ethernet-switching { port-mode trunk; vlan { members [ enterprise guest remediation VoIP_Phone ]; } native-vlan-id default; } } } ge-0/0/1 { unit 0 { family ethernet-switching { port-mode trunk; vlan { members [ enterprise guest remediation VoIP_Phone ]; } native-vlan-id default; } } } ge-0/0/2 { unit 0 { family ethernet-switching { port-mode trunk; vlan { members [ enterprise guest remediation VoIP_Phone ]; } native-vlan-id default; } } } ge-0/0/3 { unit 0 { family ethernet-switching { port-mode trunk; vlan { members [ enterprise guest remediation VoIP_Phone ]; } native-vlan-id default; } } } ge-0/0/4 { unit 0 { family ethernet-switching { port-mode access; } } } ge-0/0/5 { unit 0 { family ethernet-switching { port-mode access; } } } ge-0/0/6 { unit 0 { family ethernet-switching { port-mode access; } } } ge-0/0/7 { unit 0 { family ethernet-switching { port-mode access; } } } ge-0/0/8 { unit 0 { family ethernet-switching { port-mode access; } } } ge-0/0/9 { unit 0 { family ethernet-switching { port-mode access; } } } ge-0/0/10 { unit 0 { family ethernet-switching { port-mode access; } } } ge-0/0/11 { unit 0 { family ethernet-switching { port-mode access; } } } ge-0/1/0 { unit 0 { family ethernet-switching { port-mode access; } } } ge-0/1/1 { unit 0 { family ethernet-switching { port-mode access; } } } vlan { unit 0 { family inet { address 10.0.1.10/24; } } } } routing-options { static { route 0.0.0.0/0 next-hop 10.0.1.1; } } protocols { dot1x { authenticator { authentication-profile-name pulsesecure-access-profile; interface { ge-0/1/0.0 { supplicant multiple; transmit-period 15; mac-radius; maximum-requests 2; server-fail vlan-name enterprise; } ge-0/1/1.0 { supplicant multiple; quiet-period 5; transmit-period 15; mac-radius; supplicant-timeout 15; maximum-requests 2; guest-vlan guest; server-reject-vlan guest; server-fail vlan-name enterprise; } } } } } access { radius-server { 10.0.1.5 { port 1812; secret "$9$JLZHmzF/t0I69Icrv7N24aZikmfT3/C"; ## SECRET-DATA timeout 5; retry 3; } } profile pulsesecure-access-profile { authentication-order radius; radius { authentication-server 10.0.1.5; accounting-server 10.0.1.5; } accounting { order radius; } } } ethernet-switching-options { voip { interface ge-0/0/10.0 { vlan VoIP_Phone; } interface ge-0/0/11.0 { vlan VoIP_Phone; } interface ge-0/0/8.0 { vlan VoIP_Phone; } interface ge-0/0/9.0 { vlan VoIP_Phone; } interface ge-0/0/6.0 { vlan VoIP_Phone; } interface ge-0/0/7.0 { vlan VoIP_Phone; } interface ge-0/0/4.0 { vlan VoIP_Phone; } interface ge-0/0/5.0 { vlan VoIP_Phone; } interface ge-0/1/0.0 { vlan VoIP_Phone; } interface ge-0/1/1.0 { vlan VoIP_Phone; } } } vlans { VoIP_Phone { vlan-id 5; } default { vlan-id 1; interface { ge-0/0/4.0; ge-0/0/5.0; } l3-interface vlan.0; } enterprise { vlan-id 2; interface { inactive: ge-0/0/5.0; ge-0/0/6.0; ge-0/0/7.0; ge-0/1/0.0; ge-0/1/1.0; } } guest { vlan-id 3; interface { ge-0/0/8.0; ge-0/0/9.0; } } remediation { vlan-id 4; interface { ge-0/0/10.0; ge-0/0/11.0; } } } poe { interface all; } In addition to the configuration for the MAC authentication solution shown above, you can also configure the switch to send data (SNMP traps) to the Beacon Endpoint Profiler for use in profiling. The following example commands configure SNMP traps to the Beacon Endpoint Profiler. The Beacon Endpoint Profiler can use the traps to build profile entries: set snmp description EX4200-VOIP-Switch set snmp contact set snmp view jweb-view-all oid .1 include set snmp community public view jweb-view-all set snmp community public authorization read-only set snmp community public clients <BeaconEndpointProfilerIPaddressOrSubnet> set snmp trap-group Beacon version v2 set snmp trap-group Beacon categories link set snmp trap-group Beacon targets <BeaconEndpointProfilerIPaddress> Note: To verify that the Beacon Endpoint Profiler can read the EX Series MIB, run the following command from the Beacon Endpoint Profiler command line: snmpwalk -v 2c -c public <EXseriesIPaddress> Related Documentation Great Bay Software Beacon Endpoint Profiler Configuration Guide Using an NIS Server This topic describes integration with the NIS server. It includes the following information: NIS Server Overview Configuring Authentication with an NIS Server Displaying the User Accounts Table NIS Server Overview This section describes support for using PPS with the NIS server. It includes the following sections: Understanding NIS Server Feature Support Interoperability Requirements and Limitations Understanding NIS Server Network Information Service (NIS) is an authentication server that allows a central server to manage password authentication, hosts, services, and so on. When you use an NIS server as the authentication and authorization service for your Pulse Secure access management framework, users can sign in to PPS using the same username and password that is used for the NIS server. Feature Support Pulse Secure access management framework supports the following NIS server features: Password management feature enables users who access an NIS server to manage their policies defined on the NIS server. Integrates NIS map data for passwords, groups, and hosts with corresponding objects in Active Directory. Allows migration of NIS domains to Active Directory. Interoperability Requirements and Limitations The following limitations apply when defining and monitoring an NIS server instance: You can only use NIS authentication with the system if your passwords are stored on the NIS server using Crypt or MD5 formats. You can only add one NIS server configuration to the system, but you can use that configuration to authenticate any number of realms. The username submitted to the system cannot contain two consecutive tilde symbols (~~). Configuring Authentication with an NIS Server To configure authentication with the NIS server: 1.Select Authentication > Auth.Servers 2.Select NIS Server and click New Server to display the configuration page. 3.Complete the configuration as described in Table 44. 4.Save the configuration. Figure 315NIS Server Configuration Page Table 44NIS Server Settings
Using a RADIUS Server This topic describes integration with the RADIUS server. It includes the following information: RADIUS Server Overview Configuring Authentication with a RADIUS Server RADIUS Server Overview This section describes support for using an external RADIUS server. It includes the following sections: Understanding RADIUS Server Feature Support Using Challenge Expressions Using RADIUS Attributes Understanding RADIUS Accounting Interoperability Requirements and Limitations Understanding RADIUS Server A Remote Authentication Dial-In User Service (RADIUS) server is a type of server that allows you to centralize authentication and accounting for users. The following authentication schemes are supported: Access-Request–The user enters the username and password to request access to RADIUS server. Access-Accept–The user is authenticated. Access-Reject–The user is not authenticated and is prompted to reenter the username and password, or access is denied. Access-Challenge–A challenge is issued by the RADIUS server. The challenge collects additional data from the user. Feature Support Pulse Secure access management framework supports the following RADIUS features: RADIUS authentication. RADIUS attributes that can be used in role mapping. RADIUS directory services to retrieve user attributes in role-mapping rules. RADIUS accounting to track the services and the network resources used. RADIUS proxy to configure your external RADIUS server as an inner or outer proxy target. When you specify RADIUS proxy, some fields in the RADIUS server configuration page are not applicable. This feature is supported only on PPS. RADIUS Disconnect messages. Using Challenge Expressions The Pulse Secure access management framework supports the RSA Authentication Manager using the RADIUS protocol and a SecurID token (available from Security Dynamics). If you use SecurID to authenticate users, they must supply a user ID and the concatenation of a PIN and a token value. When you define a RADIUS server, the Pulse Secure access management framework allows administrators to use hard-coded (default) challenge expressions that support Defender 4.0 and some RADIUS server implementations (such as Steel-Belted RADIUS and RSA RADIUS) or to enter custom challenge expressions that allow the system to work with many different RADIUS implementations and new versions of the RADIUS server, such as Defender 5.0. The system looks for the response in the Access-Challenge packet from the server and issues an appropriate Next Token, New PIN, or Generic Passcode challenge to the user. Using CASQUE Authentication CASQUE authentication uses a token-based challenge/response authentication mechanism employing a CASQUE player installed on the client system. Once configured with CASQUE authentication, the RADIUS server issues a challenge with a response matching the custom challenge expression (:([0-9a-zA-Z/+=]+):). The system then generates an intermediate page that automatically launches the CASQUE player installed on the user’s system. PassGo Defender If you are using a PassGo Defender RADIUS server, the user sign-in process is as follows: 1.The user is prompted for and enters a username and password. 2.The username and encrypted password are sent over the network to the RADIUS server. 3.The RADIUS server sends a unique challenge string to the system. The system displays this challenge string to the user. 4.The user enters the challenge string in a Defender token and the token generates a response string. 5.The user enters the response string on the system and clicks Sign In. Using RADIUS Attributes Table 45 describes the RADIUS attributes that are supported in RADIUS role-mapping. Table 45RADIUS Attributes
Understanding RADIUS Accounting You can configure the device to send session start and stop messages to a RADIUS accounting server. The device sends a user-session start message after the user successfully signs in and the device maps to a role. Whenever a user session is terminated, the device sends a user-session stop message to the accounting server. A user session is terminated whenever the user: Manually signs out Times out because of either inactivity or exceeding the maximum session length Is denied access because of Host Checker role-level restrictions Is manually forced out by an administrator as a result of dynamic policy evaluation If users are signed into a device cluster, the RADIUS accounting messages might show the users signing in to one node and signing out of another. Table 46 describes the attributes that are common to start and stop messages. Table 46Attributes Common to Start and Stop Messages
Table 47Start Attributes
Table 48Stop Attributes
Interoperability Requirements and Limitations You must configure the third-party RADIUS server to communicate with the Pulse Secure access management framework. On the RADIUS server, configure the following settings: Hostname. Network IP address. Client type, if applicable. If this option is available, select Single Transaction Server or its equivalent. Type of encryption for authenticating client communication. This choice should correspond to the client type. Shared secret. The following are the requirements and limitations for Interim update feature: If you want a server to receive interim accounting messages, you can statically configure an interim value on the client, in which case, the locally configured value overrides any value that might be included in the RADIUS Access-Accept message. The octet count reported in the accounting messages is the cumulative total since the beginning of the user session. The interim update byte count is only supported based on a user session, not on SAM or NC sessions. Configuring Authentication with a RADIUS Server To configure authentication with the RADIUS server: 1.Select Authentication > Auth. Servers. 2.Select RADIUS Server and click New Server to display the configuration page. 3.Complete the configuration as described below. 4.Save the configuration. Figure 316RADIUS Server Configuration Page Table 49RADIUS Server Settings
Using an ACE Server This topic describes integration with an ACE Server (now named RSA Authentication Manager). It includes the following information: RSA Authentication Manager Overview Configuring Authentication with RSA Authentication Manager Displaying the User Accounts Table RSA Authentication Manager Overview This section describes support for using PPS with an ACE Server (now named RSA Authentication Manager). It includes the following sections: Understanding RSA Authentication Manager Feature Support Interoperability Requirements and Limitations Understanding RSA Authentication Manager RSA Authentication Manage (formerly known as ACE/Server) is an authentication and authorization server that allows user authentication based on credentials from the RSA SecurID® product from RSA Security Inc. When you use RSA Authentication Manager as the authentication and authorization service for your Pulse Secure access management framework, users can sign in to PPS using the same username and password stored in the backend server. Table 50 describes RSA SecurID hardware token and software token user sign-in methods. Table 50Sign-in Methods
If the RSA Authentication Manager positively authenticates the user, the user gains access to the system. Otherwise, the RSA Authentication Manager: Denies the user access to the system. Prompts the user to generate a new PIN (New PIN mode) if the user is signing in to the system for the first time. Users see different prompts depending on the method they use to sign in. If the user signs in using the SoftID plug-in, then the RSA prompts the user to create a new pin; otherwise PPS prompts the user to create a new PIN. Prompts the user to enter the next token (Next Token mode) if the token entered by the user is out of sync with the token expected by RSA Authentication Manager. Next Token mode is transparent to users signing in using a SoftID token. The RSA SecurID software passes the token through the system to RSA Authentication Manager without user interaction. ·Redirects the user to the standard system sign-in page (SoftID only) if the user tries to sign-in to the RSA SecurID Authentication page on a computer that does not have the SecurID software installed. Feature Support Pulse Secure access management framework supports the following RSA Authentication Manager features: New PIN mode ·Next-token mode Data Encryption Standard (DES)/ Secure Dial-In (SDI) encryption ·Advanced Encryption Standard (AES) encryption ·Slave Authentication Manager support ·Name locking ·Clustering Interoperability Requirements and Limitations The following limitations apply when defining and monitoring an RSA Authentication Manager instance: You can only add one RSA Authentication Manager configuration to the system, but you can use that configuration to authenticate any number of realms. You cannot customize the load balancing algorithm. When you enter the New PIN or Next Token mode, enter the required information within three minutes. Otherwise, the system cancels the transaction and notifies the user to reenter the credentials. The system can handle a maximum of 200 RSA Authentication Manager transactions at any given time. A transaction only lasts as long as is required to authenticate against the RSA Authentication Manager. For example, when a user signs into the system, the RSA Authentication Manager transaction is initiated when the user submits the request for authentication and ends once the RSA Authentication Manager has finished processing the request. The user may then keep his or her session open, even though the RSA Authentication Manager transaction is closed. Configuring Authentication with RSA Authentication Manager To configure authentication with an ACE server: 1.Select Authentication > Auth. Servers. 2.Select ACE Server and click New Server to display the configuration page. 3.Complete the configuration as described in Table 51 4..Save the configuration. Figure 317ACE server Table 51ACE Server Settings
Displaying the User Accounts Table 1.To display user accounts: 2.Select Authentication > Auth. Servers. 3.Click the link for the authentication server you want to manage. 4.Click the Users tab to display the user accounts table. The user accounts table includes entries for the accounts that have been created. The Last Sign-in Statistic column shows the last successful sign-in date and time for each user, the user’s IP address, and the agent or browser type and version. Use the controls to search for users and manage user accounts: To search for a specific user, enter a username in the Show users named box and click Update. TIP: You can use an asterisk (*) as a wildcard, where * represents any number of zero or more characters. For example, to search for all usernames that contain the letters jo, enter *jo*. The search is case-sensitive. To display the entire list of accounts again, type * or delete the field’s contents and click Update. To limit the number of users displayed on the page, enter a number in the Show N users box and click Update. To terminate the user session and delete the account, select the check box next to the user account record and click Delete. Using the SAML Server This topic describes the local SAML authentication server. It includes the following information: Overview This section describes support for using the local SAML authentication server. It includes the following sections: Understanding SAML SAML is an XML-based framework for communicating user authentication, entitlement, and attribute information. The standard defines the XML-based assertions, protocols, bindings, and profiles used in communication between SAML entities. SAML is used primarily to implement Web browser single sign-on (SSO). SAML enables businesses to leverage an identity-based security system like Connect Secure to enforce secure access to web sites and other resources without prompting the user with more than one authentication challenge. For complete details on the SAML standard, see the OASIS web site: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security SAML Feature Support When deployed as SAML service provider, PPS runs a local SAML server that relies on the SAML identity provider authentication and attribute assertions when users attempt to sign in to PPS. Note that authentication is only part of the PPS security system. The access management framework determines access to the system and protected resources. PPS supports: HTTP Redirect binding for sending AuthnRequests HTTP Redirect binding for sending/receiving SingleLogout requests/responses HTTP POST and HTTP Artifact bindings for receiving SAML responses RequestedAuthnContext context class specifications PPS currently supports SAML server as Service Provider and PPS as SAML Identity Provider (IdP) is not supported. Interoperability Requirements and Limitations Before you begin: Check to see whether the SAML identity provider implements SAML 2.0 or SAML 1.1. Check to see whether the SAML identity provider uses HTTP POST or HTTP Artifact bindings for SAML assertions. Check to see whether the SAML identity provider has published a SAML metadata file that defines its configuration. If the SAML identity provider metadata file is available, configuration is simpler and less prone to error. Complete the system-wide SAML settings if you have not already done so. Select System > Configuration > SAML > Settings. For details, see Configuring Global SAML Settings Add metadata for the SAML identity provider to the metadata provider list if you have not already done so. Select System > Configuration > SAML. For details, see Managing SAML Metadata Files The sign-in URL for which a session needs to be established for Connect Secure as a service provider is identified by the RelayState parameter (HTTP URL parameter for artifact and HTML form parameter for POST.) In a service provider initiated case, the system populates RelayState as an HTTP URL parameter while sending AuthnRequest. In the IdP-Initiated scenario (Connect Secure is a service provider and there is a third-party IdP), the IdP must be configured to set the appropriate Sign-in URL of Connect Secure in the RelayState parameter of the HTML form containing the SAML response. For more information, see the SAML Feature Support Configuring Authentication with the SAML Server To configure the SAML server: 1.Select Authentication > Auth. Servers. 2.Select SAML Server and click New Server to display the configuration page. 3.Complete the configuration as described in Table 52 4..Save the configuration. Table 52SAML Service Provider Profile
Displaying the User Accounts Table To display user accounts, refer to the steps found in Displaying the User Accounts Table. Access Control with SAML Server In a SAML deployment, a SAML service provider is configured to request authentication from a SAML identity provider. The SAML identity provider responds with assertions regarding the identity, attributes, and entitlements (according to your configuration). The exchange enforces security and enables the SSO user experience. PPS as a SAML Service Provider If you are working with a partner that has implemented a SAML identity provider, you can deploy the PPS as a SAML service provider to inter-operate with it, thereby enabling SSO for users who should have access to protected resources. In this model, the user is authenticated by the SAML identity provider. The system uses the SAML response containing the assertion to make an authentication decision. The choices the identity provider makes to implement SAML determine the deployment choices, for example whether to use SAML 2.0 or SAML 1.1, whether to reference a published metadata configuration file, and whether to use a POST or artifact profile. When you deploy the system as a SAML service provider, you create a SAML authentication server configuration that references the partner SAML identity provider, and a set of access management framework objects (realm, role mapping rules, and sign-in policy) that reference the SAML authentication server. Layer 3 Authentication and Enforcement using SAML Server Figure 318 shows how to access firewall protected resources using SAML server on PPS. Figure 318 Deployment diagram 1.End user using an user agent (either a browser or a Pulse client) authenticates to PPS 2.Pulse Policy Secure(PPS) acting as a SAML Service Provider (SP), issues a SAML authentication (SAML AuthN) request to SAML IdP through the user agent. If SAML authentication request is valid, IdP authenticates the end user and generates SAML assertion and sends it to PPS (SAML SP) through user agent. 3.Pulse Policy Secure(PPS) validates the SAML assertion and if it's valid, authentication is successful. 4.The user is first authenticated with SAML IdP. Once end user is authenticated appropriate role is assigned and the user ID is pushed to firewall. The end user can access the protected resource. Pulse Client uses embedded browser for SAML authentication. It should be enabled on the Pulse Client connection settings in PPS. Layer 2 Authentication and Enforcement using SAML Server Figure 319 shows how to access switch protected resources using SAML server on PPS. Figure 319Authentication Deployment Diagram
1.MAC address authentication is performed using either RADIUS or SNMP for Layer 2 authentication. The session is created on PPS after successful MAC authentication and the user is provided with a limited access role since the Host Checker is not performed. 2.The user must be able to access both PPS and SAML IdP after L2 authentication. For policy enforcement using MAC address authentication, see here. 3.Pulse Client or web browser is used to perform Layer 3 authentication using SAML server. 4.After successful Layer 3 authentication on PPS via SAML IdP, both Layer 2 (MAC authentication) and Layer 3 (SAML authentication) connections are bridged using MAC address. 5.Host Checker is performed and if the SAML authentication is successful the user is provided with Full Access Role. 6.The user can access protected resources. Layer 2 session is updated with the RADIUS attributes of the Layer 3 connection. The bridged session is used to perform Layer 2 access control. For more information on session bridging, see here. SAML 2.0 Configuration Tasks To use SAML server on PPS follow the below configuration steps: Configure SAML host FQDN under Configuration > SAML > Settings. This FQDN is used to generate SAML Entity Id. See Configuring System-Wide SAML Settings Configure third party SAML IdP like Ping Federate, Okta. Get SAML IdP metadata and configure it under Configuration > SAML > New Metadata Provider. Under Metadata Provider configuration, "Identity Provider" roles should be selected since it is an SAML IdP metadata. (For screenshot, refer section "Admin UI changes") Configure SAML Server under 1.Authentication > Auth. Server. See Configuring SAML Authentication server. If SAML IdP's metadata is not configured, admin needs to configure IdP's information manually. If only one IdP metadata is configured, IdP information is automatically populated. If multiple IdP metadata are configured, admin needs to selected approriate IdP's information. If admin wants to sign or encrypt the request, appropriate certificates need to be selected. After configuring SAML server on PPS, the metadata of PPS acting as an SAML SP can be downloaded from SAML server page. Configure PPS metadata on SAML IdP and configured SAML SP details on IdP. See Configuring PPS as a Configuring PPS as a SAML 2.0 Service Provider Configuring System-Wide SAML Settings This section describes tasks related to configuring system-wide SAML settings. It includes the following topics: Configuring Global SAML Settings The system-wide SAML settings impact all SAML service provider and identity provider instances. To configure global SAML settings: 1.Select System > Configuration > SAML. 2.Click the Settings button to display the configuration page. 3.Complete the settings described in 4.Click Save Changes. Table 53SAML Global Configuration Guidelines
Managing SAML Metadata Files You use the System > Configuration > SAML pages to maintain a table of SAML metadata files for the SAML service providers and identity providers in your network. Using SAML metadata files makes configuration easier and less prone to error. You can add the metadata files to the system by: Uploading a metadata file. Retrieving the metadata file from a well-known URL. To add metadata files: 1.Select System > Configuration > SAML. 2.Click New Metadata Provider to display the configuration page. 3.Complete the settings described in Table 54 4.Save the configuration. Table 54SAML Metadata Provider Configuration Guidelines
The Refresh button downloads the metadata files from the remote location even if these files have not been modified. This operation applies only to remote locations; local metadata providers are ignored if selected. To refresh a metadata file: 1.Select System > Configuration > SAML. 2.Select the metadata file to refresh and click Refresh. To delete a metadata file: 1.Select System > Configuration > SAML. 2.Select the metadata file to delete and click Delete. Configuring PPS as a SAML 2.0 Service Provider This topic describes how to configure the system as a SAML service provider. When the system is a SAML service provider, it relies on the SAML identity provider authentication and attribute assertions when users attempt to sign in to the device. Note that authentication is only part of the security system. The access management framework determines access to the system and protected resources. The system supports: HTTP Redirect binding for sending AuthnRequests HTTP Redirect binding for sending/receiving SingleLogout requests/responses HTTP POST and HTTP Artifact bindings for receiving SAML responses RequestedAuthnContext context class specifications Before you begin: Check to see whether the SAML identity provider uses HTTP POST or HTTP Artifact bindings for SAML assertions. Check to see whether the SAML identity provider has published a SAML metadata file that defines its configuration. If the SAML identity provider metadata file is available, configuration is simpler and less prone to error. Complete the system-wide SAML settings if you have not already done so. Select System > Configuration > SAML > Settings. For details, see “Configuring Global SAML Settings” Add metadata for the SAML identity provider to the metadata provider list if you have not already done so. Select System > Configuration > SAML. For details, see “Managing SAML Metadata Files” The sign-in URL for which a session needs to be established for the system as a service provider is identified by the RelayState parameter (HTTP URL parameter for artifact and HTML form parameter for POST.) In a service provider initiated case, the system populates RelayState as an HTTP URL parameter while sending AuthnRequest. In the IdP-Initiated scenario (Connect Secure is a service provider and there is a third-party IdP), the IdP must be configured to set the appropriate Sign-in URL of the system in the RelayState parameter of the HTML form containing the SAML response. For more information, see the SAML 2.0 specification. To configure the system as a SAML service provider: 1.Select Authentication > Auth. Servers. 2.Select SAML Server from the New list and then click New Server to display the configuration page. 3.Complete the settings as described in Table 52 4.Save the configuration. After you save changes for the first time, the page is redisplayed and now has two tabs. Use the Settings tab to modify any of the settings pertaining to the SAML server configuration. Use the Users tab to monitor user sessions. Next steps: Configure the access management framework to use the SAML authentication server. Start with realm and role mapping rules. Configure a sign-in policy. When using a SAML authentication server, the sign-in policy can map to a single realm only. Configuring a Role Mapping Rule Based on a SAML Attribute You can use role mapping rule custom expressions to include SAML Attribute statement as a factor in role determination. PPS uses attributes from attribute statement in "User Name Template" under Authentication > Auth. Server > SAML Server. To configure role mapping rules: 1.Select Users > User Realms. 1.Create a new realm or edit a realm you have already created. 2.Click New Rule to display the configuration page. 3.Select Custom Expression and click Update to redisplay the configuration page with the controls related to custom expressions. 4.Click Expressions to display the server catalog dialog box.
1.Select samlAuthnContextClass, select an operator, and click Insert Expression. 2.Edit the expression template to match the AuthnContextClassRef data expected from the SAML IdP. 3.Save your changes to the variable expression and return to the rule configuration page. 4.Select the expression, roles for the rule, and the stop option (if desired). 5.Save your changes to the rule configuration and return to the realm configuration page. 6.Reorder the rules if necessary. 7.Save the realm configuration. Using a SiteMinder Server This topic describes integration with the SiteMinder server. It includes the following information: SiteMinder Server Overview Configuring the Back-End SiteMinder Server Configuring Authentication with a SiteMinder Server Displaying the User Accounts Table SiteMinder Server Overview This section describes support for using PPS with the SiteMinder server. It includes the following sections: Understanding SQL Auth Server Feature Support Interoperability Requirements and Limitations Understanding SiteMinder Server CA SiteMinder server is an authentication and authorization server. When you configure the Pulse Secure access management framework to authenticate users with a SiteMinder policy server, the system passes the user’s credentials to SiteMinder during authentication. Once SiteMinder receives the credentials, it may use standard username and password authentication, RSA Authentication Manager SecurID tokens, or client-side certificates to authenticate the credentials. The system also passes a protected resource URL to SiteMinder during authentication to determine which SiteMinder realm it should use to authenticate the user. When the system passes the protected resource URL, SiteMinder authorizes the user’s URL against the realm that is associated with the resource and allows the user to seamlessly access any resources whose protection levels are equal to or less than the URL that was passed. Feature Support The Pulse Secure access management framework supports the following SiteMinder features: Single Sign-on Using SMSESSION Cookies Automatic Sign-In Authentication Schemes Single Sign-on Using SMSESSION Cookies The Pulse Secure access management framework enables single sign-on (SSO) to SiteMinder-protected resources using SMSESSION cookies. An SMSESSION cookie is a security token that encapsulates SiteMinder session information. Depending on your configuration, either the SiteMinder Web agent or the system creates an SMSESSION cookie and then posts the cookie to the following locations so the user does not have to reauthenticate to access additional resources. Pulse Secure access management framework-If the user tries to access a SiteMinder resource within the session (for example, from the system file browsing page), the system passes its cached SMSESSION cookie to the Web agent for authentication. The user’s Web browser-If the user tries to access a SiteMinder resource from outside the session (for example, when using a protected resource on a standard agent), SiteMinder uses the cached SMSESSION cookie stored in the user’s Web browser to authenticate/authorize the user. Automatic Sign-In If you enable the Automatic Sign-In option, the system can use an SMSESSION cookie generated by another agent to enable single sign-on from a SiteMinder resource. When a user accesses the system sign-in page with an SMSESSION cookie, the system verifies the SMSESSION cookie. Upon successful verification, the system establishes a session for the user. You can use the following authentication mechanisms when you enable automatic sign-in through the system: Custom agent-The system authenticates the user against the policy server and generates a SMSESSION cookie. When you select this option, you can enable SSO on other SiteMinder agents that use the same policy server. To enable SSO on these agents, update each of them to accept third-party cookies. If you select this option and the user enters his system session with an SMSESSION cookie, the system attempts automatic sign-in when the user enters the session. HTML form post-The system posts credentials to a standard Web agent that you have already configured. The Web agent then creates SMSESSION cookies. If you select this option, you cannot use SecurID New Pin and Next Token modes or client-side certificate authentication. If you select this option and the user enters his session with an SMSESSION cookie, the system attempts automatic sign-in when the user enters the session. Delegated authentication-The system delegates authentication to a standard agent. If this option is enabled, the system tries to determine the FCC URL associated with the protected resource. The system then redirects the user to the FCC URL with the system sign-in URL as the target. Upon successful authentication, the user is redirected back to the system with an SMSESSION cookie and the system does an automatic sign-in for the user. Authentication Schemes The Pulse Secure access management framework works with the following types of SiteMinder authentication schemes: Basic username and password authentication—The user’s name and password are passed to the SiteMinder policy server. The policy server authenticates them to another server for authentication. RSA Authentication Manager SecurID token authentication—The SiteMinder policy server authenticates users based on a username and password generated by an RSA Authentication Manager SecurID token. Client-side certificate authentication—The SiteMinder policy server authenticates users based on their client-side certificate credentials. If you choose this authentication method, the Web browser displays a list of client certificates from which users can select. If you choose to authenticate users with this method, you must import the client certificate through the System > Certificates > Trusted Client CAs tab. Interoperability Requirements and Limitations The following requirements and limitations apply: The Automatic Sign-in feature is not supported for administrator roles. This feature is only available for end users. If you use the Authenticate using custom agent option, update all other Web agents to accept the device generated cookie, and apply a software patch to all other Web agents. Pulse Policy Secure(PPS) supports SiteMinder server version 6.0, version 5.5, and version 12.0. If you run older agents than the supported agents, you might experience cookie validation problems, including crossed log entries and intermittent user timeouts. You can choose which SiteMinder server version you want to support when you create a server instance. You can choose version 5.5, which supports both versions 5.5 and 6.0, or you can choose version 6.0, which supports only version 6.0, or version 12.0. There is no difference in the SiteMinder authentication server functionality based on which version you select. This option only controls the version of the SDK to use. We recommend you match the compatibility mode with the version of the policy server. When you use SiteMinder to authenticate, the primary and backup policy servers must run the same SiteMinder server software version. A mixed deployment (where the primary server runs a different server software version than the backup) is not supported. SiteMinder does not store the IP address in the SMSESSION cookie, and therefore cannot pass it to the system. SiteMinder sends the SMSESSION cookie to the system as a persistent cookie. To maximize security, the system resets the persistent cookie as a session cookie once authentication is complete. When you use SiteMinder to authenticate, the Pulse Secure access management framework disregards any system session and idle timeouts and uses session and idle timeouts set through the SiteMinder realm instead. When you use SiteMinder to authenticate, users must access the system using a fully qualified domain name. This is because the SiteMinder SMSESSION cookie is only sent for the domain for which it is configured. If users access the system using an IP address, they might receive an authentication failure and will be prompted to authenticate again. You can update all your standard Web agents to the appropriate SiteMinder Agent Quarterly Maintenance Release (QMR) to accept the cookies. If you are running SiteMinder version 5 Web agents, use the QMR5 hot fix. The system is compatible with version 5.x and later SiteMinder agents. Older versions of SiteMinder agents are susceptible to cookie validation failures. You can set the Accept Third Party Cookie attribute (AcceptTPCookie) to yes in the Web agent’s configuration file (webagent.conf) or to 1 in the Windows Registry for the IIS Web server. The location of the attribute depends on the SiteMinder version and Web server you are using. Refer to the documentation provided with your SiteMinder server. Configuring the Back-End SiteMinder Server The following sections do not give complete SiteMinder configuration instructions—they are only intended to help you make SiteMinder work with the Pulse Secure access management framework. For in-depth SiteMinder configuration information, refer to the documentation provided with your SiteMinder policy server. Configuring the SiteMinder Agent Configuring the Authentication Scheme Configuring the SiteMinder Domain Configuring the SiteMinder Realm Configuring a Rule or Response Pair to Pass Usernames Configuring the SiteMinder Agent A SiteMinder agent filters user requests to enforce access controls. For instance, when a user requests a protected resource, the agent prompts the user for credentials based on an authentication scheme and sends the credentials to a SiteMinder policy server. A Web agent is simply an agent that works with a Web server. When configuring SiteMinder to work with the Pulse Secure access management framework, you must configure the system as a Web agent in most cases. If you select the Delegate authentication to a standard agent option, you must set the following options in the agent configuration object of the standard Web agent to host the FCC URL: <EncryptAgentName=no> <FCCCompatMode=no> To configure the system as a Web agent on the SiteMinder policy server: 1.In the SiteMinder Administration interface, click the System tab. 2.Right-click Agents and select Create Agent. 3.Enter a name for the Web agent and a description. You must enter this name when creating a SiteMinder realm. 4.Select the Support 5.x agents option for compatibility with the system. 5.Under Agent Type, select SiteMinder and then select Web Agent from the list. This setting is required for compatibility with the system. 6.Under IP Address or Hostname, enter the name or IP address of the system. 7.In the Shared Secret box, enter and confirm a secret for the Web agent. Note that you must enter this secret when configuring the system. 8.Click OK. Configuring the Authentication Scheme Within SiteMinder, an authentication scheme is a way to collect user credentials and determine the identity of a user. You may create different authentication schemes and associate different protection levels with each. For example, you may create two schemes—one that authenticates users based solely on the users’ client-side certificates and provides them a low protection level, and a second that uses RSA Authentication Manager SecurID token authentication and provides users a higher protection level. To configure a SiteMinder authentication scheme: 1.In the SiteMinder Administration interface, select the System tab. Right-click Authentication Schemes and select Create Authentication Scheme. 2.Enter a name for the scheme and (optionally) a description. You must enter this name when configuring the SiteMinder realm. 3.Under Authentication Scheme, select one of the following options: Basic Template HTML Form Template SecurID HTML Form Template-If you are using SecurID authentication, you must choose SecurID HTML Form Template (instead of SecurID Template). Choosing this option enables the Policy Server to send ACE sign-in failure codes. X509 Client Cert Template X509 Client Cert and Basic Authentication You must select HTML Form Template to handle reauthentication. If you select X509 Client Cert Template or X509 Client Cert and Basic Authentication, you must import the certificate through System > Certificates > Trusted Client CAs. 4.Enter a protection level for the scheme. Note that this protection level carries over to the SiteMinder realm that you associate with this scheme. 5.Select Password Policies Enabled for this Authentication Scheme if you want to reauthenticate users who request resources with a higher protection level than they are authorized to access. 6.Select Scheme Setup tab, and enter the options required by your authentication scheme type. 7.If you want the system to reauthenticate users who request resources with a higher protection level than they are authorized to access, you must enter the following settings: Under Server Name, enter the hostname (for example, sales.yourcompany.net). Select the Use SSL Connection check box. Under Target, enter the sign-in URL defined plus the parameter “ive=1” (for example, /highproturl?ive=1). The system must have a sign-in policy that uses */highproturl as the sign-in URL and only uses the corresponding SiteMinder authentication realm. Clear the Allow Form Authentication Scheme to Save Credentials check box. Leave Additional Attribute List empty. 8.Click OK. If you change a SiteMinder authentication scheme on the policy server, you must flush the cache using the Flush Cache option on the Advanced tab. Configuring the SiteMinder Domain Within SiteMinder, a policy domain is a logical grouping of resources associated with one or more user directories. Policy domains contain realms, responses, and policies. When configuring the Pulse Secure access management framework to work with SiteMinder, you must give user access to a SiteMinder resource within a realm, and then group the realm into a domain. To configure a SiteMinder domain 1.Select the System tab, right-click Domains and select Create Domain, or click Domains and select an existing SiteMinder domain. 2.Add a realm to the domain. Configuring the SiteMinder Realm Within SiteMinder, a realm is a cluster of resources within a policy domain grouped together according to security requirements. When configuring SiteMinder to work with the Pulse Secure access management framework, you must define realms to determine which resources the users might access. To configure a SiteMinder Realm: 1.In the SiteMinder Administration interface, In the SiteMinder Administration interface, select the Domains tab. 2.Expand the domain that you created. 3.Right-click Realms and select Create Realm. 4.In the Agent field, select the Web agent that you created. 5.In the Resource Filter field, enter a protected resource. This resource inherits the protection level specified in the corresponding authentication scheme. 6.For the default protection level, enter /ive-authentication. You must enter this resource when configuring the system. If you use sign-in policies with nondefault URLs such as */nete or */cert, you must have corresponding resource filters in the SiteMinder configuration. 7.From the Authentication Schemes list, select the scheme that you created. 8.Click OK. Configuring a Rule or Response Pair to Pass Usernames Within SiteMinder, you can use rules to trigger responses during authentication or authorization. A response passes DN attributes, static text, or customized active responses from the SiteMinder policy server to a SiteMinder agent. When you configure SiteMinder to work with the Pulse Secure access management framework, you must create a rule that triggers when a user successfully authenticates. Then, you must create a corresponding response that passes the user’s username to the system Web agent. To create a new rule: 1.Select the Domain tab. 2.Expand the domain that you created and then expand Realms. 3.Right-click the realm that you created and select Create Rule under Realm. 4.Enter a name and (optionally) description for the rule. 5.Under Action, select Authentication Events and then select OnAuthAccept from the drop down list. 6.Select Enabled. 7.Click OK. To create a new response: 1.Expand the domain that you created. 2.Right-click Responses and select Create Response. 3.Enter a name and (optionally) a description for the response. 4.Select SiteMinder and then select the Web agent. 5.Click Create. 6.From the Attribute list, select WebAgent-HTTP-Header-Variable. 7.Under Attribute Kind, select Static. 8.Under Variable Name, enter IVEUSERNAME. 9.Under Variable Value, enter a username. 10.Click OK. Configuring Authentication with a SiteMinder Server To configure authentication with SiteMinder server: 1.Select Authentication > Auth.Servers. 2.Select SiteMinder Server and click New Server to display the configuration page. 3.Complete the configuration as described in Table 55. 4.Save the configuration. 5.After you have saved the configuration, the page that is redisplayed includes an Advanced tab. 6.Click the Advanced tab to display the configuration page. 7.Complete the configuration as described in Table 56 8.Save the configuration. Figure 320SiteMinder Server Configuration Page Table 55SiteMinder Server Settings
Table 56SiteMinder Advanced Configuration Options
Displaying the User Accounts Table To display user accounts: 1.Click the link for the authentication server you want to manage. 2.Click the Users tab to display the user accounts table. The user accounts table includes entries for the accounts that have been created. The Last Sign-in Statistic column shows the last successful sign-in date and time for each user, the user’s IP address, and the agent or browser type and version. Use the controls to search for users and manage user accounts: To search for a specific user, enter a username in the Show users named box and click Update. TIP: You can use an asterisk (*) as a wildcard, where * represents any number of zero or more characters. For example, to search for all usernames that contain the letters jo, enter *jo*. The search is case-sensitive. To display the entire list of accounts again, type * or delete the field’s contents and click Update. To limit the number of users displayed on the page, enter a number in the Show N users box and click Update. To terminate the user session and delete the account, select the check box next to the user account record and click Delete. Troubleshooting the SiteMinder Server Configuration
Solution Review the system log file. The system tracks failures of cookie validation and key rollovers. Review the Policy Server Authentication log files. Review the Standard Web Agent log file if you selected the Authenticate using HTLM Form POST option. Confirm that the system time is synchronized with the SiteMinder server system time. If the two system times are too divergent, the timeout settings might not function correctly, and might reject attempts to sign in. In the SiteMinder server, confirm that you have defined the proper Session Timeout options max timeout and idle in the SiteMinder Realm dialog. To view the CA SiteMinder error codes select System > Log/Monitoring > User Access page. For information on the CA SiteMinder error codes, see the SiteMinder documentation. Using an SQL Auth Server This topic describes integration with the SQL Auth server. It includes the following information: SQL Auth Server Overview Configuring Authentication with an Oracle SQL Auth Server SQL Auth Server Overview This section describes support for using the SQL (also known as Oracle Database server) as a PPS authentication server. It includes the following sections: Understanding SQL Auth Server The SQL Auth server is widely deployed in the enterprise. Some enterprises use the SQL Auth server to store user credentials (usernames and passwords), MAC addresses, and other organizational information, such as group affiliations that are often the basis for authorization decisions. To support authentication and authorization against SQL Auth server databases, PPS supports an authentication server configuration that configures an Oracle Instant Client connection as well as relevant queries to the backend SQL Auth server. Feature Support Policy Secure uses Oracle Instant Client 11.2.0.2.0 to communicate with the SQL Auth server. The SQL Auth server version must support this version of the client. The Pulse Secure access management framework depends on the SQL Auth server features described in this section. You can use the SQL queries for authentication, authorization and role mapping, or both. SQL SELECT Statements The authentication transaction is based on an SQL query that returns a password (and possibly other information) based on the name entered by the user attempting to log in. While a sample SQL query is provided in the original configuration file, you must configure the SQL entry of the configuration file with a query appropriate to your database. The query you enter must be either an SQL SELECT or an SQL EXECUTE statement that contains additional syntax elements that are preprocessed by the SQL authentication module. The SQL authentication module executes SQL statements in parameterized form. This means that the SQL statement is compiled once, with parameter markers (usually question marks) as placeholders for data items that vary from one execution to the next. Only upon execution of the statement are the actual data values supplied. The SQL statement you compose must not include parameter markers directly. Instead, include the names of the parameters where parameter markers would appear, in an appropriate format. This is an example of a parameter marker: 1.SELECT password, profile, fullname FROM usertable WHERE username = :username 2.The SQL authentication module translates the SQL statement provided, replacing parameter names with parameter markers prior to passing the SQL statement to the database engine. 3.The SQL statement can be very simple. Basically, all that is required is to look up a password and possibly some optional information based on a username. The SQL statement can also be quite complex; it can include inner joins, and it can contain expressions. The underlying database engine is responsible for handling the SQL statement; the SQL authentication module performs no interpretation of the SQL statement other than to translate parameter names to parameter markers. SQL Stored Procedures A stored procedure is a sequence of SQL statements that form a logical unit and perform a task. You can use stored procedures to encapsulate a set of queries or operations that can be executed repeatedly on a database server. For example, you can code operations on an employee database, such as password lookup, as stored procedures that can be executed by application code. Stored procedures can be compiled and executed with different parameters and results. Stored procedures can use any combination of input parameters (the values passed to the stored procedure at execution time) and output parameters (the values set or returned by the stored procedure to the calling application or environment).
As shown in the example, the procedure is called myCalledProcedure with input variables as username and ipAddr, output parameters as password, ipAddr, and filterId. The names of the output parameters are the names of the attributes added to the server catalog used for role mapping and return attributes. The parameter consists of a colon (:), the name of the parameter, and a format specifier. SQL Format Specifiers Table 57 describes the SQL statement format specifiers with parameters in called procedures. Table 57SQL Statement Format Specifiers
SQL Statement Parameters Table 58 describes the SQL statement parameter names and types. Table 58SQL Statement Parameter Names and Types
SQL Password Hash Format Table 59 describes the different SQL password types. Table 59Password Hash Format
Interoperability Requirements and Limitations The following limitation applies when defining and monitoring an SQL Auth server instance: The maximum number of connections to an Oracle database is limited to 50 connections for L2 and L3 log ins (concurrent and open RADIUS protocol), without any browser log ins. You must enter the SQL keywords in uppercase letters. Configuring Authentication with an Oracle SQL Auth Server To configure authentication with an SQL Auth server: 1.Select Authentication > Auth.servers. 2.Select SQL Auth Server and click New Server to display the configuration page. 3.Select the SQL Vendor as Oracle. Complete the configuration as described in 4.Save the configuration. Figure 321SQL Auth Server Configuration Page Table 60SQL Auth Server Settings
Configuring Authentication with MySQL Auth Server To configure authentication with an SQL Auth server: 1.Select Authentication > Auth.servers. 2.Select SQL Auth Server and click New Server to display the configuration page. 3.Select the SQL vendor as MYSQL. 4.Complete the configuration as described in Table 61 5.Save the configuration. Figure 322MySQL Auth Server Configuration Page Table 61MySQL Auth Server Settings
Configuring Authentication with MSSQL Auth Server To configure authentication with an SQL Auth server: 1.Select Authentication > Auth.servers. 2.Select SQL Auth Server and click New Server to display the configuration page. 3.Select the SQL vendor as MSSQL. 4.Complete the configuration as described in Table 62 5.Save the configuration. Table 62MSSQL Auth Server Settings
Troubleshooting Oracle Error Codes Table 63 describes the Oracle error codes, cause, and action. Table 63Oracle Error Codes
Using a Time-Based One-Time Password (TOTP) Authentication Server This topic describes PPS integration with the Time-Based One-Time Password (TOTP) Authentication Server. It includes the following information: Overview Configuring Authentication with a TOTP Authentication Server Displaying the User Accounts Table Displaying the User Accounts Table Viewing/Generating Backup Codes Overview This section describes support for using the Local/Remote PPS TOTP authentication server. It includes the following sections: Understanding TOTP Interoperability Requirements and Limitations Understanding TOTP Time-based One-time Password Algorithm (TOTP) is an algorithm that computes a one-time password (token) from a shared secret key and the current time. Google Authenticator is one of such implementations of TOTP algorithms. PPS supports TOTP authentication by using the Google Authenticator algorithm for generation of shared secret key and token. Many third-party apps are available for almost all mobile and desktop operating systems for the generation of TOTP tokens. Interoperability Requirements and Limitations Before you begin: TOTP authentication server users’ configuration is automatically synchronized within all nodes in a single cluster. If there are multiple clusters behind a DNS load-balancer, then the admin has to manually perform binary export/import user's configuration to all the nodes in different clusters. TOTP feature is configurable across clusters. First time users have to register a new TOTP user-account via web. End-users cannot use Pulse Desktop applications and Pulse Mac applications for new user registration. CAUTION: Users with more than one TOTP account will be reset when the system software is upgraded. In such case, users have to re-register with TOTP. Two standalone nodes or separate clusters can be synced. For now, binary import/export of user configuration option can be used. For the users who are already using custom sign-in pages: For TOTP authentication to work, existing custom sign-in pages need to include following sign-in pages: TotpAuthRegister.thtml TotpAuthRegister-mobile-webkit.thtml TotpAuthRegister-ipad.thtml TotpAuthRegister-stdaln.thtml TotpAuthRegister-new-ux.thtml TotpAuthTokenEntry.thtml TotpAuthTokenEntry-new-ux.thtml TotpAuthTokenEntry-mobile-webkit.thtml TotpAuthTokenEntry-ipad.thtml TotpAuthTokenEntry-stdaln.thtml These files can be downloaded from sample custom sign-in pages URL: https://<<PPS>>/dana-admin/download/sample.zip?url=/dana-admin/auth/custompage.cgi?op=Download&samplePage=sample Configuring Authentication with a TOTP Authentication Server To configure the TOTP server as Local: 1.Select Authentication > Auth. Servers. 2.Select Time based One-Time Password (TOTP) Server and click New Server to display the configuration page. 3.Complete the configuration as described in Table 64. 4.Save the configuration. Figure 323TOTP Authentication Server Page – Local Table 64TOTP Auth Server Settings - Local
To configure the TOTP server as Remote: 1.Select Authentication > Auth. Servers. 2.Select Time based One-Time Password (TOTP) Server and click New Server to display the configuration page. See Figure 324 3.Complete the configuration as described in Table 65. 4.Save the configuration. If PPS is configured to use Remote TOTP server, then the remote server should have a valid certificate issued by a Trusted CA. Figure 324TOTP Authentication Server Page - Remote Table 65TOTP Auth Server Settings - Remote
Configuring Admin/User Realm to Associate a TOTP Authentication Server as Secondary Authentication Server For example, to configure a user realm: 1.Select Users > User Realms > New User Realm. 2.Complete the settings for the user-realm. 3.Check the Enable additional authentication server option. 4.Under Additional Authentication Server, select any already created TOTP authentication-server from the Authentication #2 dropdown, as shown in Table 65. Whenever admin selects TOTP authentication-server as the additional authentication server, then the Username: Predefined as <USER> and Password: specified by user in sign-in page options are set by default. 5.Click on Save Changes. Figure 325Configuring Admin/User Realm to Associate a TOTP Auth. Server as Secondary Auth. Server Using Google Authenticator Application to Register to a TOTP Server The admin can associate an end-user to a realm that has a secondary authentication server configured as TOTP authentication server. For first time registration via web, perform the following steps: For example: Admin associates an end-user User1 to a user-realm that has the TOTP authentication-server configured as the secondary authentication-server. When User1 for the first time, performs a login to the above configured user-realm: 1.After successful authentication with primary authentication-server, User1 is shown the TOTP registration page. See Figure 326 2.User1 is given a TOTP registration key in text form/QR image form and 10 backup codes. User saves 10 backup codes in a safe place for using it later during authentication when end-user device (where Google Authenticator app is installed) is not available (in emergency). 3.Now, User1 opens the device where Google Authenticator app is installed, then either scans the QR image (or) manually adds a new user (for example: GA-User1) by entering the above given secret registration key. 4.The Google-Authentication app (for GA-User1) generates a new 6-digit number called as a token once in every 30 seconds. 5.Enter the current token in the registration page. Click on Sign In. On successful authentication with that token, User1 will be taken to his/her home page. Figure 326First Time Registration to a TOTP Server For already registered user, perform the following steps: 1.The already-registered user (For example: User1), whose realm was associated with secondary authentication server configured as TOTP authentication server, accesses PPS URL via web (User1 has already registered TOTP user in Google Authenticator app.) 2.After successful authentication with primary authentication server, user1 is shown TOTP Token entry page as seen in Figure 327 3..User1 opens Google Authentication app that was installed in mobile (or PC), enters the current token to the 4.Authentication Code. If mobile is not available, user can enter any of the unused backup codes. 5.On successful authentication with the token, User1 can enter any of the unused backup codes. A backup code can be used only once to successfully authenticate with the TOTP authentication server. Once used, the same backup code cannot be reused. Figure 327Google Authentication Token Displaying the User Accounts Table To display user accounts: 1.Select Authentication > Auth.Servers. 2.Click the link for the authentication server you want to manage. 3.Click the Users tab to display the user accounts table. The Last Sign-in Statistic column shows the last successful sign-in date and time for each user, the user’s IP address, and the agent or browser type and version. The “Last Attempted” column shows the last time and date a user attempted to login. The “Last Successful Login” shows the last successful sign-in date and time for each user. 4.Under the “User Information” column, there are details available for a user’s “Realm”, “Primary AuthServer” and the “Status” columns There are 3 possible states for the “Status" column: Active: TOTP user’s account is in use (that is user has used this account less than stale period of this TOTP authentication server) Locked: TOTP user account has been locked due to maximum number of wrong login attempts Unregistered: TOTP user has seen registration page, but yet to complete the registration by entering the correct token in the registration page. Use the controls to search for users and manage user accounts: To search for a specific user, enter a username in the Show users named field and click Update. TIP: You can use an asterisk (*) as a wildcard, where * represents any number of zero or more characters. For example, to search for all usernames that contain the letters jo, enter *jo*. The search is case-sensitive. To display the entire list of accounts again, type * or delete the field’s contents and click Update. To limit the number of users displayed on the page, enter a number in the Show N user’s field and click Update. To unlock a user, select the specific user and click Unlock. To reset a user’s credentials, select the specific user and click Reset. Figure 328Displaying the User Accounts Table To unlock a TOTP user’s account: 1.Go to the Users tab. The list of users is displayed. 2.Select the user whose account you choose to unlock. 3.Click on the Unlock button. Figure 329Unlocking a User To reset a TOTP user’s account: 1.Go to the Users tab. The list of users is displayed. 2.Select the user whose account you choose to reset. 3.Click on the Reset button. This removes the user entry from the table. Figure 330Resetting a User Viewing/Generating Backup Codes To view/generate TOTP backup codes after successful login to a TOTP server via web: 1.User successfully authenticates to primary auth-server and TOTP auth-server via web. 2.Click on the Preference option on the top of the page. 3.In the Preference page, under TOTP Backup codes, click on either View or Generate to obtain user's TOTP backup codes Figure 331View/Generate Backup Codes Exporting/Importing TOTP Users To export/import TOTP users: 1.Select Authentication > Auth. Servers. 2.Click the link for the authentication server you want to manage. 3.Click the Users tab to display the user accounts table. The user accounts table includes entries for the accounts that have been created. 4.Use the Export and Import buttons located at the bottom of the user accounts table to export and import TOTP users data. Figure 332Export/Import TOTP Users Configuring HTTP Attribute Server PPS retrieves endpoint/user information and uses it for compliance assessments and role assignment. The configured HTTP attribute server has to be mapped as a "Device Attributes" under the realm configuration and role mapping rules can be used to assign the roles based on the attributes received from the attribute server. To configure authentication with HTTP Attribute server: 1.Select Authentication > Auth.servers. 2.Select HTTP Attribute Server and click New Server to display the configuration page. 3.Enter the name of the server. 4.Select the required template from the drop down. 5.Enter the hostname/IP address of the third-party server. 6.Click Test Connection to validate the connection between PPS and third-party server (McAfee ePo/Nozomi Networks). 7.Save the configuration. Figure 333HTTP Attribute Server Configuration Page Related Documentation For McAfee ePO integration, see Pulse Policy Secure: McAfee ePO Integration Guide. For Nozomi networks integration, see Pulse Policy Secure: Nozomi Integration Guide. |
What aspect of AAA is responsible for determining what a user can and Cannot do with network resources?
Postagens relacionadas
direito autoral © 2024 mesadeestudo Inc.
