Authentication and Directory Servers

aaa server overview understanding the role of aaa servers in the access management framework 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 the group or user attribute information is used by the access management framework for policy decisions in the 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 access management framework supports the following types of aaa servers local you can create special purpose local databases to manually create user accounts, permit anonymous access, or manage access based on digital certificates 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 in role mapping rules in addition, you can use mdm device attributes in role mapping rules the following table is a reference of the aaa servers supported in ivanti connect secure deployments the following table lists the supported aaa servers ivanti connect secure local "local authentication server" , "certificate server", "saml server" no special features to manage guest users supports an authentication server configuration when deployed as a saml service provider different ivanti connect secure features support a local saml server when deployed as a saml identity provider external (standards based) "ldap server", "radius server" external (other) "active directory", "mdm server", "rsa ace server" aaa server configuration task summary to integrate an authentication server configure the authentication server select authentication > authentication > auth servers page and complete the authentication server configuration create an authentication realm select users > user realms or administrators > admin realms and select the authentication server when you complete the authentication realm configuration aaa traffic management ivanti connect secure virtual appliances and 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 crl and ocsp traffic flow configuring aaa traffic management across interfaces select authentication > auth servers and configure service provider aaa configurations as needed click enable auth traffic control a new window appears click enable traffic decoupling to confirm the page navigates to the auth server page that displays the options to configure the aaa traffic interfaces 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 select the required interface and port from the list for clusters, select applicable interfaces and associated ports click save upgrading from previous releases the aaa traffic was routed through the management port this option was available on both the default network and the administrative network the aaa traffic can be routed through internal, external, management, virtual ports and vlan ports if send aaa traffic via management port was enabled, then by default, immediately after upgrade, the aaa traffic is routed through the management port for all authentication servers as a global setting the selected interfaces may be modified as required using the global settings or the auth server level settings configuring aaa traffic management on upgrade the ivanti connect secure interface had the option "send aaa traffic via management port" as shown in figure under system > traffic segregation this option routes the aaa traffic through the management port by default if send aaa traffic via management port was enabled, then the following changes are observed the aaa traffic management options are available under authentication > auth severs the aaa traffic management is enabled by default the physical port is automatically set to management port or default vlan using the local authentication server this topic describes the local authentication server local authentication server overview this section provides an overview of the feature and its limitations understanding the local authentication server the local authentication server is an authentication database that is built in to the system 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 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 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 to create a local authentication server select authentication > auth servers select local authentication and click new server to display the configuration page complete the configuration as described in the following table save the configuration the following table lists the local authentication server configuration guidelines settings guidelines name specify a name that is useful to you password options minimum length specify a number of characters the valid range is 0 99 6 is the default maximum length specify a number of characters the valid range is 0 99 8 is the default the maximum length cannot be less than the minimum length minimum digits specify the number of digits required in a password do not require more digits than the value of the maximum length option minimum letters specify the number of letters required in a password do not require more letters than the value of the maximum length option if you enable the previous option, the combined total of the two options cannot exceed that of the value specified in the maximum length option uppercase and lowercase required select this option if you want all passwords to contain a mixture of uppercase and lowercase letters require passwords to contain at least two letters if you also require a mix of uppercase and lowercase letters special characters select this option if you want password should contain any special characters password position select this option to validate the new password with old password based on password position default is 8 positions, example if previous password is test12345678, then change password cannot be a e ph 2345 the matched characters based on position are highlighted different from username select this option if the password cannot equal the username different from previous password select this option if a new password cannot equal the previous password stored as cleartext select this option if you are using open authentication protocol sets chap and eap md5 challenge work with local authentication servers only if you select this option be aware of the security implications of storing passwords as cleartext password management allow users to change passwords select this option if you want users to be able to change their passwords in addition to selecting local authentication password management options, you must select the enable password management option for the associated realm authentication policy force password change select this option to specify the number of days after which a password expires the default is 64 days prompt users to change password select this option to specify when to prompt the user to change passwords account lockout enable account lockout for users select this option to manage user authentication failures for admin users of local authentication server maximum wrong password attempts specify the number of consecutive wrong password attempts after which the admin user account will be locked the default value is 3 retries account lockout period specify the time in minutes for which admin user account will remain locked the default value is 10 minutes 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 select authentication > auth servers select the local authentication server to which you want to add a user account click the users tab click new to display the configuration page complete the configuration as described in the following table save the configuration the following table lists user account configuration guidelines settings guidelines username do not include " " in a username you cannot change a username after you create the account full name specify the user's full name password specify a password make sure that the password you enter conforms to the password options specified on the local authentication server configuration page confirm password confirm the password one time use select this option to limit the user to one login after one successful login, the user's login state is set to disabled, and the user receives an error message when attempting subsequent sign ins however, you can manually reset this option to allow the same user to log in again enabled select this check box if it is not already selected if the one time use option has been implemented, this option is listed as disabled after the user has logged in successfully if a permanent or one time user is logged in and you disable this option, the user is immediately logged out of the system and receives an error message require user to change password select this option to force users to change their passwords at the next login if you force the user to change passwords, you must also enable the local authentication password management options managing user accounts you use the users page to list, modify, and delete local authentication server user accounts to manage a user account select authentication > auth servers click the link for the authentication server you want to manage 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 the status column for the user shows the account locked warning icon if the user account is locked 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 edit the user account configuration, click the link in the username column to display the update local user account page to terminate the user session and delete the account, select the box next to the user account record and click delete to unlock a user account, select the locked out account and click unlock the account locked warning icon will disappear after successful unlock to view the admin user access logs, select system > log/monitoring > admin access > log select a user to display the user account configuration page you can use this page to modify the account settings, or to disable or quarantine the account creating administrator user accounts you use the admin users page to create a special admin user account that enables the account holder to manage the local authentication server users table these special admin users can sign in to a special page that enables them to create, modify, and delete user accounts to create a special admin user account select authentication > auth servers > system local click the admin users tab to display the configuration page specify a username, select an authentication realm, and click add to create the administrator user save the configuration using the admin user sign in page to manage the local authentication users table the special admin users created using the feature shown in the previous section can manage the local authentication server accounts table for example, if an admin user named adminuser is provisioned to manage user accounts for the users realm, when adminuser signs into the users realm sign in page, a user admin button appears on the toolbar at the top of the page the following figure depicts shows the toolbar the following figure depicts the sign in page toolbar the special admin user can click the user admin button to display the user admin page, which shows the local authentication server users table the following figure depicts the user admin page the special admin user can select accounts and delete them and can create user accounts the same account management guidelines apply as when using the admin console for creating and modifying user records the following figure depicts the new local user configuration page using active directory this topic describes integration with the microsoft® windows® platform active directory™ service microsoft windows platform active directory service overview this section describes support for using ivanti connect secure with the active directory aaa service 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 access management framework, users can sign in to ivanti connect secure 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 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 ics for the detailed migration procedure, refer kb40430 https //forums ivanti com/s/article/kb40430?language=en us if you upgrade to 22 5r2 1, with smbv1 disabled, ad domain join fails after upgrade do a reset join on troubleshooting page post upgrade for more information, see forum link https //forums ivanti com/s/article/with smbv1 disabled ivanti connect secure fails to authenticates due to domain join failure in 22 5 r2 version active directory feature support 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 and ntlmv2 authentication protocols supports user principal name (upn) format for usernames this support is available for web login supports user principal name (upn) format for usernames the upn should be able to pass validation against the domain joined by the ics system either directly or by trust relationship if a upn is rejected it will not be retried against other domains interoperability requirements and limitations the following limitations apply to interoperability with active directory the 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 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 active directory implementations that use the equal sign operator (=) in a group name, such as "\\=third floor group" the 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 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 ivanti secure access client 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 password management feature, which enables users to change their active directory passwords through the web server, is not supported for users of trusted domains that do not trust the domain specified in the active directory configuration configuring authentication and authorization with active directory service to configure integration with active directory service select authentication > auth servers select active directory / windows nt and click new server to display the configuration page select active directory mode and complete the configuration as described in table docid\ xspmmkliydjkgpv mrnqi save the configuration the following table lists active directory mode settings settings guidelines mode select active directory mode this table describes active directory mode base configuration name specify a name to identify the server within the system domain specify the netbios domain name for the active directory domain the system uses dns to discover domain controllers in the active directory forest it sends authentication requests to the domain controller at the closest site ensure that your dns servers are configured to resolve the active directory domain controller fully qualified domain name (fqdn) and service (srv) records kerberos realm specify the fqdn of the active directory domain for example, if "secure" is the domain name (netbios name), then secure net is the kerberos realm name domain join configuration username specify a username that has permission to join computers to the active directory domain use the "delegate control" workflow in active directory to assign the following user account permissions to the username or to a group to which the user belongs write write all properties change password reset password validate write to dns hostname read and write dns host attributes delete computer objects create computer objects password specify the password for the special user save credentials if this setting is not enabled, the credentials entered will be destroyed after successfully joining the domain this option is useful when managing clusters for example, you might want to save the credentials for a cluster node you have yet to add if you do not enable this option, you must manually enter the credentials when you add the new cluster node container name specify the container path in active directory in which to create the machine account changing this field triggers a domain rejoin action the default is computers, which is a standard container created during installation of the ad server the ad computers container is the default location for new computer accounts created in the domain if desired, you may specify a different container or ou to specify nested containers, use a forward slash ( / ) as the container separator for example outer ou/inner ou do not use backslashes in the path using backslashes causes an invalid dn syntax error computer name specify the machine account name the default computer name is derived from the license hardware in the following format 0161mt2l00k2c0 we recommend the computer name string contain no more than 14 characters to avoid potential issues with the ad/nt server do not include the '$' character update join status / reset join the following colors are used to indicate status gray the domain join action has not been attempted this is the default status that appears when you are using the page to create a new active directory configuration yellow attempting to join the active directory domain this is the default status that appears after saving configuration settings or when any domain join settings are changed in an existing configuration green the attempt was successful this status indicates that this server can now be used to authenticate users red the attempt to join the active directory domain was not successful click update join to get the latest join status of nodes if the status appears persistently red, click reset join to reinitiate the domain join process the reset join action requires active directory administrator credentials for cluster nodes, you might need to click update join multiple times to obtain the latest join status of nodes transient network issues might also cause the join status indicator to appear red before restarting the join process, ensure that it is not caused by network issues make sure your dns servers can resolve queries to the active directory domain controller and that the active directory credentials are valid and have the appropriate permissions additional options authentication protocol the system attempts authentication using the protocols you have enabled in the order shown on the configuration page for example, if you have selected the check boxes for kerberos and ntlmv2, the system sends the credentials to kerberos if kerberos succeeds, the system does not send the credentials to ntlmv2 if kerberos is not supported or fails, the system uses ntlmv2 as the next protocol in order kerberos select this option to enable the kerberos authentication protocol kerberos is the most secure method and is required for kerberos single sign on authentication kerberos must be enabled if you plan to use ivanti secure access client single sign on or browser based agentless single sign on (spnego) enable ntlm protocol select this option to enable ntlm if you plan to use any of the following features machine authentication using, ivanti secure access client, or windows native 802 1x supplicants ms chap based authentication protocols for any 802 1x supplicants user password management role mapping rules based on group membership trusted domain lookup contact trusted domains select this option to contact domain controllers of trusted domains directly without proxying authentication requests and group membership checks through the domain controller if this option is not selected network contact with trusted domains is not permitted, but pass through authentication using the primary domain is still permitted trusted domain user's group lookup for kerberos sso trusted domain user's password based authentication does not work only groups from the domain in which this system is a member are available for use in role mapping when a group search is performed in the server catalog window if you want to restrict trusted domain users and computers from logging in when this option is not selected, you can define a custom expression based on the ntdomain variable and use it in role mapping rules for example, if ivanti connect secure belongs to the domain named corporate, you can define a custom expression as ntdomain=corporate and use the custom expression in the role mapping rule of the realm domain connections maximum simultaneous connections per domain enter the maximum number of simultaneous domain connections (1 to 10) this field specifies the maximum number of simultaneous connections that the auth daemon should open to the domain controller of one domain a value of greater than 1 can improve the scalability with simultaneous authentication requests however, this field value should be judiciously used, especially if trusted domain setting is enabled this value dictates how many authentication processes are created per domain for example if the maximum domain connection is configured as 4 and there are 5 trusted domains, there could be as many as 5 4+1 = 21 auth processes hence if there are many trusted domains, the domain connection value needs to be controlled by the administrator, failing which there could be too many auth processes created only for ad authentication purpose by default, this field value is set to 2 if trusted domain setting enabled if trusted domain is not enabled, then the default value is set to 5 if contact trusted domains is enabled, a value above 6 may degrade overall system performance machine account password change enable periodic password change of machine account select this option to change the domain machine account password for this configuration change machine password frequency specify a frequency in days for example, every 30 days user record synchronization this feature is available only on ivanti connect secure enable user record synchronization select this option to retain the bookmarks and individual preferences regardless of which system you log in to logical auth server name specify a logical authentication server name save changes click the button to save the changes made active directory ipv6 support active directory server for authentication and authorization for ad mode auth server in ics supports both ipv6 and ipv4 based backend active directory servers if active directory server is configured with ipv6 only, then ics is forced to use ipv6 if ipv6 is disabled in the backend server or in ics, then ics is forced to use ipv4 in case of a dual network in both the ics and backend server, ics would use both the protocols ipv6 and ipv4 for different authentication protocols like kerberos, ntlm, etc ics dns server preferred mode settings do not apply to ad mode auth server since, internal third party samba library selects the available networks based on dns resolution and other runtime protocol checks all features supported in ipv4 for active directory auth server are supported via ipv6 interface also displaying the user accounts table to display user accounts select authentication > auth servers click the link for the authentication server you want to manage 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 field 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 field and click update to terminate their user session and delete the account, select the check box next to the user account record and click delete troubleshooting the active directory service to troubleshoot the active directory service select authentication > auth servers > ad server name > troubleshooting select the appropriate functions described in the following table the following table lists the active directory server troubleshooting functions function description basic verification verifies whether the domain is properly joined and if the winbindd service is running the number of winbindd processes is displayed, along with the ongoing cpu and memory usage for each process for example, if user authentication is slow or fails randomly, use this function to check the number of winbindd processes and the cpu, memory and file descriptor usage select restart ad services to correct faulty processes test user authentication prompts for a username and password and attempts to log in if successful, the groups the user belongs to are displayed only the regular password authentication is done test user password change prompts for a username and the old and new password for a user and attempts to change the password on the ad server list domain info lists each domain and all trusted domains selecting a domain lists each domain controller for the domain, its ip address, and whether it is reachable for example, if user authentication fails consistently and the domain is shown as successfully joined in the ad server settings page, the domain trust may be broken use this function to check the trusted domains also, if the domain join fails consistently or user authentication to a trusted domain fails consistently, the domain might not be reachable or the dns configuration may be incorrect use this function to verify whether the domains and trusted domain are reachable change machine password sends a request to the domain controller to change the machine password a confirmation prompt is displayed to confirm the change restart ad services restarts the winbindd process, which may restore proper authentication, specifically during load and longevity scenarios a confirmation prompt is displayed to confirm the restart (users cannot log in during a restart reset join reinitiates the domain join process a confirmation prompt is displayed to confirm the reset and allows you to clear the samba cache and keytab files before the reset this is the same function shown on the ad server's settings page and requires active directory administrator credentials for example, if user group changes are not reflected in the user authentication, run this function with clear samba cache enabled samba diagnostics logs displays diagnostic logs page where you can download the samba logs load output displays up to the last 500 lines of the troubleshooting output for the current session save output file saves all the troubleshooting messages for the current session clear output file erases all the troubleshooting messages saved in the output file (they cannot be retrieved) jitc aaa certification enabling jitc mode to enable the jitc mode navigate to system > configuration > security > inbound ssl options click on turn on jitc mode checkbox once turn on jitc mode is enabled, turn on ndcpp mode and turn on fips mode are also automatically enabled click save changes for more details about the deployment of ics in the jitc mode, refer to the ics ndcpp and jitc certification deployment guide important factors to consider password strengthening when jitc is enabled, ics does not allow an administrator to configure a password exactly same as previously configured 5 passwords an error message is displayed in this case notification for unsuccessful admin login attempts with jitc mode on, ics shows a banner with the count of unsuccessful login attempts this includes any change in the admin status that would have happened since the last successful login upon clicking on the banner, the administrator is directed to the status page, which provides more details about status or configuration change since last log in these configuration changes are cleared before the next login so that admin can see different set of configuration changes, if anything happened from the last login re authentication of admin users ics will force the administrator to re authenticate with ics whenever the following conditions occur add role delete role modify the role delete the realm update the realm during dpe (dynamic policy evaluation) configuration change notification for details about configuration changes and status information since last login, go to system > status >admin notification understanding multidomain user authentication this topic provides an overview of multidomain user authentication with active directory and windows nt multi domain user authentication overview the 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 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 = john, the system treats this rule semantically as ntuser = john and ntdomain = defaultdomain kerberos support we recommend you configure the 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 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 active directory group information overview the 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 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 join domain for active directory based authentication server without using a domain admin account with active directory on windows server, the system can join domain (for an active directory based authentication server) without using a domain administrator account for more details refer to kb2624 https //forums ivanti com/s/article/kb2624?language=en us using the certificate server this topic describes integration with the certificate server certificate server overview this section describes support for using ivanti connect secure with the certificate server 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 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 select authentication > auth servers select certificate server and click new server to display the configuration page complete the configuration as described in the following table save the configuration the following table lists certificate server settings settings guidelines name specify a name to identify the server within the system user name template specify a username template specify how the system should construct a username you may use any combination of certificate variables contained in angle brackets and plain text this value populates the \<user> and \<username> session variables for use throughout the rest of the system configuration user record synchronization this applies only to ivanti connect secure enable user record synchronization select this option to retain the bookmarks and individual preferences regardless of which system you log in to logical auth server name specify a logical authentication server name displaying the user accounts table to display user accounts, refer to displaying the user accounts table docid\ xspmmkliydjkgpv mrnqi using an ldap server this topic describes integration with the ldap server ldap server overview this section describes support for using ivanti connect secure with the ldap server 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 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 (fgpp) for active directory 2008 interoperability requirements and limitations the following limitations apply to interoperability with ldap 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 the ldap authentication configuration is enhanced to locate the nearest microsoft domain controllers, which are spread across the globe, by resolving dns srv records to configure authentication with an ldap server select authentication > auth servers select ldap server and click new server r to display the configuration page complete the configuration as described in the following table save the configuration the following table lists ldap server settings settings guidelines name specify a name to identify the server within the system enable domain name (enabled) select this option if you want to fetch a list of servers from the dns server domain name when you enable domain name, specify the ldap domain name that can be mapped to domain controllers by dns service enable domain name (disabled) clear this option if you want to manually enter all the domain controllers host names ldap server specify the ldap server name or the ipv4/ipv6 address backup ldap server1 (optional) specify the parameters for backup ldap server1(server name or the ipv4/ipv6 address) default port number 389 (unencrypted connection) the specified backup ldap server is used for failover processing the authentication request is first routed to the primary ldap server, and then to the specified backup servers if the primary server is unreachable backup ldap port1 specify the parameters for backup ldap port1 \<font color="#000000"> backup ldap server2 \</font> (optional) specify the parameters for backup ldap server2 (server name or the ipv4/ipv6 address) \<font color="#000000"> backup ldap port2 \</font> specify the parameters for backup ldap port2 ldap port specify the ldap port for the ldap server default port number 389 (unencrypted connection) default port number 636 (ssl connection) ldap server type select the backend ldap server type from the following choices \<font color="#000000"> generic \</font> \<font color="#000000"> active directory \</font> connection select one of the following options for the connection to the ldap server unencrypted the device sends the username and password to the ldap directory service in cleartext ldaps the device encrypts the data in the ldap authentication session using the secure socket layer (ssl) protocol before sending it to the ldap directory service start tls the device allows both secure and plain requests against an ldap server on a single connection if you select ldaps or start tls , the validate server certificate option is displayed for the configured ldap server(s) and its referral servers select this option if the ssl connection uses digital certificate security if you enable validation for the referral servers, make sure your network dns supports reverse lookup zone if you want to verify the server certificates, the root ca and intermediate cas must be imported under trusted server cas by default , validate server certificate option is enabled to validate the server's certificate connection timeout (seconds) specify the time to wait for connection to the primary ldap server, and then to each backup ldap server default 15 seconds search timeout (seconds) specify the time to wait for search results from a connected ldap server test connection (optional) to verify the connection between ivanti secure access client and ldap servers, click the test connection button we recommend using the test connection function only after saving changes on the ldap server configuration page authentication required? authentication required to search ldap select this option to require authentication when performing search or password management operations if you use active directory, you must select the authentication required to search ldap check box and provide the full dn and password of primary and backup administrator accounts that can reach active directory you can enable password management on any ldap server this feature enables users who authenticate through an ldap server to manage their passwords through the system using the policies defined on the ldap server to enable password management on any ldap server, you must provide primary and backup administrator accounts (with write privileges to the directory) for the administrator dn and backup administrator dn admin dn specify the administrator dn for queries to the ldap directory password specify the password for the ldap server backup admin dn specify the backup administrator dn for queries to the ldap directory, as a fallback when primary admin dn fails (due to account expiration) the interaction with ldap directory stops when both primary and backup administrator accounts fail backup admin password specify the backup administrator password for the ldap server finding user entries base dn specify the base dn under which the users are located for example, dc=sales,dc=acme, dc=com filter specify a unique variable that can be used to do a fine search in the tree for example, samaccountname=\<username> or cn=\<username> include \<username> in the filter to use the username entered on the sign in page for the search specify a filter that returns 0 or 1 user dns per user; the device uses the first dn returned if more than 1 dn is returned health check enable health check this option enables a periodic health check for the server and gives the details in event logs frequency of health check specify the frequency to preform the health check in every "x" minutes, default value is 60 minutes and range is 5 1440 minutes test username and password specify the test credentials and click validate user credential health check process might be performance intensive and can lead to huge logs so be conscious while enabling the option and choosing the frequency remove domain from windows users names? strip domain from windows username select this option to pass the username without the domain name to the ldap server determining group membership base dn specify the base dn to search for user groups filter specify a unique variable which can be used to do a fine search in the tree for example, samaccountname=\<username> or cn=\<groupname> member attribute specify all the members of a static group for example, member or unique member reverse group search select this option to start the search from the member instead of the group this option is available only for active directory server types query attribute specify an ldap query that returns the members of a dynamic group for example, memberurl nested group level specify how many levels within a group to search for the user the higher the number, the longer the query time, so we recommend that you specify to perform the search no more than two levels deep nested group search select one of the following options nested groups in server catalog this option is faster because it can search within the implicit boundaries of the nested group search all nested groups with this option, the device searches the server catalog first if the device finds no match in the catalog, then it queries ldap to determine if a group member is a subgroup displaying the user accounts table to display user accounts, refer to displaying the user accounts table docid\ xspmmkliydjkgpv mrnqi using the ldap password management feature this topic describes support and limitations for 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 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 notifies 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 access management framework does this by using its internal ldap or samba client many servers, such as microsoft active directory, offer an administrative console to configure account and password options ldap based password management works with the following 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 access management framework supports the fine grained password policy (fgpp) configured in the ad user container 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 access management framework supports password management with the following ldap directories microsoft active directory/windows nt table docid\ xspmmkliydjkgpv mrnqi 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, the system supports only authentication and allows 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 (policy secure only) the following table lists supported password management functions function active directory edirectory authenticate user unicodepwd userpassword allow user to change password if enabled server tells us in bind response (uses ntsecuritydescriptor) if passwordallowchange == true log out user after password change yes yes force password change at next login if pwdlastset == 0 if pwdmustchange == true expired password notification useraccountcontrol== 0x80000 check date/time value password expiration notification (in x days/hours) if pwdlastset now() < maxpwdage 14 days (read from domain attributes) if now() passwordexpirationtime< 14 days (the system displays warning if less than 14 days) disallow authentication if "account disabled/locked useraccountcontrol== 0x2 (disabled) accountexpires useraccountcontrol == 0x10 (locked) lockouttime bind errorcode 53 "account expired" bind errorcode 53 "login lockout" honor "password history "server tells us in bind response server tells us in bind response enforce "minimum password length "if set, the system displays message telling user minpwdlength if set, the system displays message telling user passwordminimumlength disallow user from changing password too soon if pwdlastset now() < minpwdage, then we disallow server tells us in bind response honor "password complexity "if pwdproperties == 0x1, then enabled complexity means the new password does not contain username, first or last name, and must contain characters from 3 of the following 4 categories english uppercase, english lowercase, digits, and non alphabetic characters (ex !, $, %) server tells us in bind response note the following expected behavior 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 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 an mdm server this topic describes integration with the mobile device management (mdm) servers understanding mdm integration mdm vendors provide enrollment and posture assessment services that prompt employees to enter data about their mobile devices when the user installs the mdm application on the device and completes enrollment, the mdm pushes the device certificate to the device after enrollment, the mdm maintains a database record that includes information about the enrollee attributes related to device identity, user identity, and posture assessment against mdm policies the access management framework mdm authentication server configuration determines includes details on how the system communicates with the mdm web restful api service and how it derives the device identifier from the certificates presented by endpoints after you have configured the mdm authentication server, you can configure a realm that uses the mdm data for authorization, and you can use mdm device attributes in the role mapping rules that are the basis for your network access and resource access policies feature support the device access management framework supports integration with the following mdm solutions vmware workspace one(formerly airwatch) ivanti (formerly mobileiron) microsoft intune samsung knox configuring an mdm server the authentication server configuration is used by the system to communicate with the mdm in the device access management framework, the mdm server is used as the device authorization server to configure the authentication server select authentication > auth servers to navigate to the authentication server configuration pages select mdm server and click new server to display the configuration page complete the configuration as described in the following table save the configuration the following table lists authentication server configuration guidelines settings guidelines name specify a name for the configuration type select one of the following options vmware workspace one(formerly airwatch) ivanti (formerly mobileiron) microsoft intune samsung knox manage connect secure has to be registered with pulse one for using pulse workspace as an mdm auth server port selection choose the communicating interface/network for each auth server independently this enables you to communicate using internal, external, or management interface server (applicable to vmware workspace one(formerly airwatch) and ivanti (formerly mobileiron)) server url specify the url for the mdm server this is the url the mdm has instructed you to use to access its restful web api (also called a restful web service) you must configure your firewalls to allow communication between these two nodes over port 443 viewer url specify the url for the mdm report viewer this url is used for links from the active users page to the mdm report viewer request timeout specify a timeout period (5 60 seconds) for queries to the mdm server the default is 15 seconds server (applicable to microsoft intune) tenant id specify azure ad tenant id client id specify web application id that has been registered in azure ad client secret specify secret key of the web application registered in azure ad request timeout specify a timeout period (5 60 seconds) for queries to the mdm server the default is 15 seconds administrator (applicable to vmware workspace one(formerly airwatch) and ivanti (formerly mobileiron)) username specify the username for an account that has privileges to access the mdm restful web api password specify the corresponding password tenant code airwatch only copy and paste the airwatch api tenant code samsung knox manage server url specify samsung knox manage tenant url client id specify api client that has been registered in samsung knox manage client secret specify client key of the api client registered in registered in samsung knox manage request timeout specify a timeout period (5 60 seconds) for queries to the mdm server the default is 15 seconds device identifier device identity policy secure only select an option on whether to require that the mdm certificate is presented by the endpoint when signing in require certificate require that the device certificate pushed to client devices during enrollment be used at sign in if this option is selected, and the client device does not have a certificate, authorization fails use this option when you require endpoints to adhere to your certificate security requirements use mac if present in some cases, the mdm certificate might be configured without a device identifier when the endpoint uses an 802 1x framework to authenticate, policy secure can obtain the mac address from the radius return attribute callingstationid the system can then use the mac address as the device identifier the always use mac address option is not present in ivanti connect secure a device certificate is required to determine device identity id template construct a template to derive the device identifier from the certificate attributes the template can contain textual characters as well as variables for substitution the variables are the same as those used in role mapping custom expressions and policy conditions enclose variables in angle brackets like this \<variable> for example, suppose the certificate dn is cn=\<device udid>, uid=\<user id>, o=company with this configuration, the certificate could identify both the user and the device in this example, the device id template is \<certdn cn> id type select the device identifier type that matches the selection in the mdm scep certificate configuration uuid the device universal unique identifier this is the key device identifier supported by mobileiron mdm serial number the device serial number udid the device unique device identifier this is the key device identifier supported by airwatch mdm device id this is the key device identifier supported by microsoft intune and samsung knox display the active users page the active users page lists data about current sessions, including access to realms that use the mdm server for device authorization to display the active users page, select systems > active users the following figure shows the active users page for ivanti connect secure click the icon in the device details column to navigate to the mdm report viewer page for the device using a radius server this topic describes integration with the radius server radius server overview this section describes support for using an external radius server 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 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 disconnect messages this feature is applicable for ivanti connect secure using challenge expressions the 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 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 the user is prompted for and enters a username and password the username and encrypted password are sent over the network to the radius server the radius server sends a unique challenge string to the system the system displays this challenge string to the user the user enters the challenge string in a defender token and the token generates a response string the user enters the response string on the system and clicks sign in using radius attributes the following table describes the radius attributes that are supported in radius role mapping attribute description arap challenge response contains the response to the challenge of a dial in client sent in an access accept packet with framed protocol of arap arap features includes password information that the network access server (nas) must send to the user in an arap feature flags packet sent in an access accept packet with framed protocol of arap arap password appears in an access request packet containing a framed protocol of arap only one of user password, chap password, or arap password must be included in an access request, or one or more eap messages arap security identifies the arap security module to be used in an access challenge packet arap security data contains the actual security module challenge or response, and is in access challenge and access request packets arap zone access indicates how to use the arap zone list for the user access accept provides specific configuration information necessary to begin delivery of service to the user access challenge sends the user a challenge requiring a response, and the radius server must respond to the access request by transmitting a packet with the code field set to 11 (access challenge) access challenge response is not qualified over ipv6 access reject transmits a packet with the code field set to 3 (access reject) if any value of the received attributes is not acceptable access request conveys information specifying user access to a specific nas, and any special services requested for that user accounting request conveys information used to provide accounting for a service provided to a user accounting response acknowledges that the accounting request has been received and recorded successfully acct authentic indicates how the user was authenticated, whether by radius, the nas itself, or another remote authentication protocol acct delay time indicates how many seconds the client has been trying to send this record acct input gigawords indicates how many times the acct input octets counter has wrapped around 2^32 over the course of this service being provided acct input octets indicates how many octets have been received from the port during the current session acct input packets indicates how many packets have been received from the port during the session provided to a framed user acct interim interval indicates the number of seconds between each interim update in seconds for this specific session acct link count indicates the count of links known to have been in a given multilink session at the time the accounting record is generated acct multi session id indicates a unique accounting id to make it easy to link together multiple related sessions in a log file acct output gigawords indicates how many times the acct output octets counter has wrapped around 2^32 during the current session acct output octets indicates how many octets have been sent to the port during this session acct output packets indicates how many packets have been sent to the port during this session to a framed user acct session id indicates a unique accounting id to make it easy to match start and stop records in a log file acct session time indicates how many seconds the user has received service acct status type indicates whether this accounting request marks the beginning of the user service (start) or the end (stop) acct terminate cause indicates how the session was terminated acct tunnel connection indicates the identifier assigned to the tunnel session acct tunnel packets lost indicates the number of packets lost on a given link chap challenge contains the challenge handshake authentication protocol (chap) challenge sent by the nas to a ppp chap user chap password indicates the response value provided by a ppp chap user in response to the challenge callback id indicates the name of a location to be called, to be interpreted by the nas callback number the dialing string to be used for callback called station id allows the nas to send the phone number that the user called, using dialed number identification service (dnis) or similar technology calling station id allows the nas to send the phone number that the call came from, using automatic number identification (ani) or similar technology class sent by the server to the client in an access accept and then sent unmodified by the client to the accounting server as part of the accounting request packet, if accounting is supported configuration token used in large distributed authentication networks based on proxy connect info sent from the nas to indicate the nature of the user's connection event timestamp records the time that this event occurred on the nas, in seconds since january 1, 1970 00 00 utc filter id indicates the name of the filter list for this user framed appletalk link indicates the appletalk network number used for the serial link to the user, which is another appletalk router framed appletalk network indicates the appletalk network number which the nas can probe to allocate an appletalk node for the user framed appletalk zone indicates the appletalk default zone to be used for this user framed compression indicates the compression protocol to be used for the link framed ip address indicates the address to be configured for the user framed ip netmask indicates the ip netmask to be configured for the user when the user is a router to a network framed ipv6 pool contains the name of an assigned pool used to assign an ipv6 prefix for the user framed ipv6 route indicates the routing information to be configured for the user on the nas framed ipx network indicates the ipx network number to be configured for the user framed mtu indicates the maximum transmission unit to be configured for the user, when it is not negotiated by some other means (such as ppp) framed pool indicates the name of an assigned address pool used to assign an address for the user framed protocol indicates the framing to be used for framed access framed route indicates the routing information to be configured for the user on the nas framed routing indicates the routing method for the user, when the user is a router to a network idle timeout sets the maximum number of consecutive seconds of idle connection allowed to the user before termination of the session or prompt keep alives uses snmp instead of keepalives login ip host indicates the system with which to connect the user when the login service attribute is included login ipv6 host indicates the system with which to connect the user when the login service attribute is included login lat group contains a string identifying the lat group codes that this user is authorized to use login lat node indicates the node with which the user is to be automatically connected by lat login lat port indicates the port with which the user is to be connected by lat login lat service indicates the system with which the user is to be connected by lat login service indicates the service to use to connect the user to the login host login tcp port indicates the tcp port with which the user is to be connected when the login service attribute is also present ms arap challenge only present in an access request packet containing a framed protocol attribute with the value 3 (arap) ms arap password change reason indicates the reason for a server initiated password change ms acct auth type represents the method used to authenticate the dial up user ms acct eap type represents the extensible authentication protocol (eap) type used to authenticate the dial up user ms bap usage describes whether the use of bap is allowed, disallowed, or required on new multilink calls ms chap cpw 1 allows the user to change password if it has expired ms chap cpw 2 allows the user to change password if it has expired ms chap challenge contains the challenge sent by a nas to a ms chap user ms chap domain indicates the windows nt domain in which the user was authenticated ms chap error contains error data related to the preceding ms chap exchange ms chap lm enc pw contains the new windows nt password encrypted with the old lan manager password hash ms chap mppe keys contains two session keys for use by the microsoft point to point encryption (mppe) ms chap nt enc pw contains the new windows nt password encrypted with the old windows nt password hash ms chap response contains the response value provided by a ppp ms chap user in response to the challenge ms chap2 cpw allows the user to change password if it has expired ms chap2 response contains the response value provided by an ms chap v2 peer in response to the challenge ms chap2 success contains a 42 octet authenticator response string ms filter transmits traffic filters ms link drop time limit indicates the length of time (in seconds) that a link must be underutilized before it is dropped ms link utilization threshold represents the percentage of available bandwidth utilization below which the link must fall before the link is eligible for termination ms mppe encryption policy signifies whether the use of encryption is allowed or required ms mppe encryption types signifies the types of encryption available for use with mppe ms mppe recv key contains a session key for use by the mppe ms mppe send key contains a session key for use by the mppe ms new arap password transmits the new arap password during an arap password change operation ms old arap password transmits the old arap password during an arap password change operation ms primary dns server indicates the address of the primary domain name server (dns) server to be used by the ppp peer ms primary nbns server indicates the address of the primary netbios name server (nbns) server to be used by the ppp peer ms ras vendor indicates the manufacturer of the radius client machine ms ras version indicates the version of the radius client software ms secondary dns server indicates the address of the secondary dns server to be used by the ppp peer ms secondary nbns server indicates the address of the secondary dns server to be used by the ppp peer message authenticator signs access requests to prevent spoofing access requests using chap, arap, or eap authentication methods nas ip address indicates the identifying ip address of the nas that is requesting authentication of the user, and must be unique to the nas within the scope of the radius server nas ipv6 address indicates the identifying ipv6 address of the nas that is requesting authentication of the user, and must be unique to the nas within the scope of the radius server nas identifier contains a string identifying the nas originating the access request nas port indicates the physical port number of the nas that is authenticating the user nas port id contains a text string that identifies the port of the nas that is authenticating the user nas port type indicates the type of the physical port of the nas that is authenticating the user password retry indicates how many authentication attempts a user is allowed to attempt before being disconnected port limit sets the maximum number of ports to be provided to the user by the nas prompt indicates to the nas whether it should echo the user's response as it is entered, or not echo it proxy state indicates that a proxy server can send this attribute to another server when forwarding an access request the attribute must be returned unmodified in the access accept, access reject or access challenge reply message indicates that the text that can be displayed to the user service type indicates the type of service the user has requested, or the type of service to be provided session timeout sets the maximum number of seconds of service to be provided to the user before termination of the session or prompt state indicates that the packet must have only zero or one state attribute usage of the state attribute is implementation dependent telephone number using the calling station id and called station id radius attributes, authorization and subsequent tunnel attributes can be based on the phone number originating the call, or the number being called termination action indicates the action the nas should take when the specified service is completed tunnel assignment id indicates to the tunnel initiator the particular tunnel to which a session is to be assigned tunnel client auth id specifies the name used by the tunnel initiator during the authentication phase of tunnel establishment tunnel client endpoint contains the address of the initiator end of the tunnel tunnel link reject indicates the rejection of the establishment of a new link in an existing tunnel tunnel link start marks the creation of a tunnel link tunnel link stop marks the destruction of a tunnel link tunnel medium type indicates the transport medium to use when creating a tunnel for those protocols (such as l2tp) that can operate over multiple transports tunnel medium type indicates the transport medium to use when creating a tunnel for those protocols (such as l2tp) that can operate over multiple transports tunnel password specifies a password used to access a remote server tunnel preference indicates that if radius server returns more than one set of tunneling attributes to the tunnel initiator, you should include this attribute in each set to indicate the relative preference assigned to each tunnel tunnel private group id indicates the group id for a particular tunneled session tunnel reject marks the rejection of the establishment of a tunnel with another node tunnel server auth id specifies the name used by the tunnel terminator during the authentication phase of tunnel establishment tunnel server endpoint indicates the address of the server end of the tunnel tunnel start marks the establishment of a tunnel with another node tunnel stop marks the destruction of a tunnel to or from another node tunnel type indicates the tunneling protocol(s) to be used (in the case of a tunnel initiator) or the tunneling protocol in use (in the case of a tunnel terminator) user name indicates the name of the user to be authenticated user password indicates the password of the user to be authenticated, or the user's input following an access challenge 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 the following table describes the attributes that are common to start and stop messages the next table describes the attributes that are unique to start messages the following table lists the attributes common to start and stop messages attribute description user name (1) specifies the string that the device administrator specifies during radius server configuration nas ip address (4) specifies the device's ipv4 address nas ipv6 address specifies the device's ipv6 address nas port (5) the device sets this attribute to 0 if the user signed in using an internal port, or 1 if an external port is used framed ip address (8) specifies the user's source ipv4 address framed ipv6 address specifies the user's source ipv6 address nas identifier (32) specifies the configured name for the device client under the radius server configuration acct status type (40) the device sets this attribute to 1 for a start message, or 2 for a stop message in a user session or a sub session acct session id (44) specifies the unique accounting id that matches start and stop messages corresponding to a user session or to a sub session acct multi session id (50) specifies the unique accounting id that you can use to link together multiple related sessions each linked session must have a unique acct session id and the same acct multi session id acct link count (51) specifies the count of links in a multilink session at the time the system generates the accounting record the following table lists start attributes attribute description acct authentic (45) the device sets this attribute to radius if the user is authenticated to a radius server local if the user is authenticated to a local authentication server remote if the user is authenticated through any other radius server the following table lists stop attributes attribute description acct session time (46) specifies the duration of the user session or the sub session acct terminate cause (49) the device uses one of the following values to specify the event that caused the termination of a user session or a sub session user request (1) user manually signs out idle timeout (4) user is idle and times out session timeout (5) user's maximum session times out admin reset (6) user is forced out from active users page interoperability requirements and limitations you must configure the third party radius server to communicate with the 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 select authentication > auth servers select radius server and click new server to display the configuration page complete the configuration as described in table docid\ xspmmkliydjkgpv mrnqi save the configuration the following table lists radius server settings settings guidelines name specify a name to identify the server within the system nas identifier specify the name that identifies the network access server (nas) client to the radius server if you use the radius proxy feature, the nas identifier field is not used proxy passes on the entire radius packet including the nas identifier from the client primary server radius server specify the name or ip address of the radius server authentication port specify the authentication port value for the radius server default port number 1812, 1645 (legacy servers) nas ip address specify the nas ip address if you leave this field empty, the internal ip address is passed to radius requests you can also fill this field with ipv6 address if you configure the nas ip address, then the system passes the value regardless of which cluster node sends the requests if you use the radius proxy feature, this field is not used proxy passes on the entire radius packet including the nas ip address from the client timeout (seconds) specify the interval of time to wait for a response from the radius server before timing out the connection retries specify the number of times to try to make a connection after the first attempt fails users authenticate using tokens or one time passwords select this option to prompt the user for a token instead of a password for example, you can use this option to dynamically prompt for a password or token based on sign in policies by configuring two instances of the same authentication server you can use one instance for wireless users with this option enabled and that prompts the user for a token, and another instance for wired users with this option disabled and that prompts the user for a password if you are using radius proxy feature, this option is not used backup server (required only if backup server exists) radius server specify the secondary radius server the authentication request is first routed to the primary radius server, then to the specified backup server if the primary server is unreachable accounting messages are sent to the radius server by each cluster node without consolidation radius accounting follows these assumptions if the cluster is active/passive, all users are connected to one node at a time if the cluster is active/active and does not use a balancer, users are connected to different nodes but are static if the cluster is active/active and uses a balancer, the balancer usually enforces a persistent source ip in this case, users are always connected to the same node radius does not support load balancing authentication port specify the authentication port shared secret specify the shared secret accounting port specify the accounting port load balance auth requests between primary and backup servers select this option to load balance radius requests between the primary and backup servers in a round robin fashion accounting requests will not be load balanced radius accounting user name specify the user information to the radius accounting server you can enter any of the applicable session variables applicable variables include those that are set the time after the user signs in and maps to a role the default variables for this field are as follows user logs the username to the accounting server realm logs the realm to the accounting server role sep="," logs the list of comma separated roles assigned to the user role logs the role to the accounting server if you assign the user to more than one role, the system separates them with commas interim update interval (minutes) select this option to achieve more precise billing for long lived session clients and during network failure if you are using the radius proxy feature, the fields in this section are not used the minimum interim update interval is 15 minutes the data statistics (bytes in and bytes out) for radius accounting might not be sent for a j sam/w sam/nc session if the session is less than 30 seconds long and the applications keep the connections open all the time send interim updates for sub sessions created inside parent sessions enable this checkbox to send interim updates for sub sessions (child sessions) created inside parent sessions use vpn tunnel assigned ip address for framed ip address/framed ipv6 address attribute value in radius accounting select the use nc assigned ip address for framed ip address/framed ipv6 address attribute value in radius accounting check box to use the ip address returned from ivanti connect secure for the framed ip address attribute two ip addresses are recorded one prior to authenticating with ivanti connect secure, and one returned by vpn tunneling after authentication select this option to use the vpn tunneling ip address for the framed ip address/framed ipv6 address attribute instead of the pre authenticated (original) ip address framed ipv6 addresses based attribute fetching and parsing nas ipv6 address login ipv6 host radius disconnect this feature is applicable for connect secure enable processing of radius disconnect requests select this option to process radius disconnect requests the radius disconnect requests received from the backend radius server will terminate sessions that match the attributes in the request you must not configure multiple radius authentication servers with the same backend server details radius disconnect over ipv6 is not qualified the radius attributes that are used for session identification are framed ip address (for sessions with vpn tunnel only) acct session session id acct multi session id user name next token specify the appropriate next token new pin specify the new pin generic login specify the generic login challenge to the user custom radius rules this feature is applicable for connect secure (optional) click new radius rule to add a custom challenge rule that determines the action to take for an incoming packet when a user enters his or her username and password, the initial authorization request is sent to the server the server may respond with a challenge or reject packet in the add custom radius challenge rule window, you select the packet type (challenge or reject) and then specify what action to take for example, you can show a login page with a specific error message to the user, or automatically send an access request packet back to the server to create a custom challenge rule select the incoming packet type access challenge sent by the radius server requesting more information in order to allow access access reject sent by the radius server rejecting access specify an expression to evaluate, based on the radius attribute, and click add if you specify more than one expression, the expressions are "anded" together to remove an expression, click the delete icon next to the expression choose the action to take by selecting one of the following radio buttons show new pin page user must enter a new pin for the token show next token page user must enter the next tokencode show generic login page display an additional page to the user in response to an access challenge sent by the server sometimes a radius server returns a challenge packet and requires the user to enter additional information to continue the login process for example, a server receives the initial username and password and sends an sms message to the user's mobile phone with a one time password (otp) the user enters the otp in the generic login page show user login page with error display the standard login page with an embedded error message this option lets you bypass the standard message string sent by connect secure and display a custom error message to the user enter your custom message in the error message text box there is no maximum character limit for this message send access request with additional attributes send an access request packet with the specified attribute/value pair(s) select an attribute, enter its value and click add to delete an attribute, click the delete icon next to the attribute/value pair you must set user password to \<password> otherwise an "invalid username or password" message appears click save changes to save your edits, then click close to close this window your custom rules appear in the table under the custom radius authentication rule section to delete a rule, select the check box next to the rule and click delete displaying the user accounts table to display user accounts, refer to the steps found in the displaying the user accounts table docid\ xspmmkliydjkgpv mrnqi section using an ace server this topic describes integration with an ace server (now named rsa authentication manager) rsa authentication manager overview this section describes support for using ivanti connect secure with an ace server (now named rsa authentication manager) understanding rsa authentication manager rsa authentication manager (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 access management framework, users can sign in to ivanti connect secure using the same username and password stored in the backend server the following table describes rsa securid hardware token and software token user sign in methods method action using a hardware token and the standard system sign in page the user browses to the standard system sign in page, and then enters the username and password (consisting of the concatenation of the pin and the rsa securid hardware token's current value) the system then forwards the user's credentials to the authentication server using a software token and the standard system sign in page the user browses to the standard system sign in page, and then enters the username and password (consisting of the concatenation of the pin and the rsa securid software token's current value) the system then forwards the user's credentials to the authentication server 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 for a new pin (new pin mode) if the user is signing in to the system for the first time or requires a pin reset, ivanti connect secure prompts the user to create a new pin prompts for the next token (next token mode) if the token code entered by the user is out of sync with the token expected by the rsa authentication manager, ivanti connect secure prompts the user to enter the next available token code the user must wait for the token value to change on their hardware token or securid app, and then manually enter the new code feature support 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 select authentication > auth servers select ace server and click new server to display the configuration page complete the configuration as described in the following table save the configuration the following table lists the ace server settings settings guidelines name specify a name to identify the server within the system ace port specify the default port of the authentication server if no port is specified in the sdconf rec file, the default port is used configuration file current config file specify the rsa authentication manager configuration file you must update this file on the device anytime you make changes to the source file imported on display the date on which the config file is imported import new config file use the choose file button to upload the sdconf rec configuration file node verification file node save the configuration to redisplay the configuration page the updated page includes a section that lists a timestamp for the negotiation of the node secret between the system and the backend rsa server the negotiation and verification automatically occur after first successful login do not expect entries in the table until at least one user has authenticated successfully user record synchronization this feature is available only on connect secure enable user record synchronization select this option to retain the bookmarks and individual preferences regardless of which system you log in to logical auth server name specify a logical authentication server name enabling rsa risk based authentication (rba) support with ics cluster rsa securid risk based authentication is a token less, multi factor enterprise authentication solution ics integration with risk based authentication works with the usage of custom sign in pages open the ics login page ics immediately delegates authentication to rsa server by redirecting the user rsa authentication manager (am) server to authenticate user is now prompted for step up authentication based on the risk score for example the user is challenged to answer enter additional security questions if the user logs in from a different endpoint once successfully authenticated to rsa am, the user is redirected back to ics with a one time token key, validated by ics each agent in rsa am is linked to an agent id in the integration file download this file from rsa am and add to custom sign in page package in case of cluster (for example 2 node cluster) two integration files (node1 js and node2 js) are required in the custom sign in page package and it can be used in loginpage thml for example if the cluster node names are "node1" & "node2", add the similar lines inside the body (before the end) of loginpage thtml <% if loginnode == "node1" %> \<script src='<% home %>/node1 js' type="text/javascript">\</script> <% else %> \<script src='<% home %>/node2 js' type="text/javascript">\</script> <% end %> \<script>window\ onload=redirecttoidp;\</script> in case of standalone ics, the above conditional check with loginnode is not required if the integration file name is am integration js, then add the integration file as part of custom sign in page package and the below changes in loginpage thtml in custom signin page would be sufficient \<script src='<% home %>/am integration js' type="text/javascript">\</script> \<script>window\ onload=redirecttoidp;\</script> also, all the related loginpage thtml (like loginpage ipad thtml in custom) needs similar changes to reflect the rba login experience for browser based login from different devices displaying the user accounts table to display user accounts, refer to the steps found in the displaying the user accounts table docid\ xspmmkliydjkgpv mrnqi section using the saml server this topic describes the local saml authentication server saml server overview this section describes support for using the local connect secure saml authentication server 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, ivanti connect secure runs a local saml server that relies on the saml identity provider authentication and attribute assertions when users attempt to sign in to connect secure note that authentication is only part of the ivanti connect secure security system the access management framework determines access to the system and protected resources connect secure supports http redirect binding for sending authnrequests http redirect binding for sending/receiving singlelogout requests/responses http post for receiving saml responses requestedauthncontext context class specifications interoperability requirements and limitations before you begin check to see whether the saml identity provider implements saml 2 0 check to see whether the saml identity provider uses http post 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 docid\ w8him5gdqsv75bqt xjlr 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 docid\ w8him5gdqsv75bqt xjlr 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 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 2 0 specification configuring authentication with the saml server to configure the saml server select authentication > auth servers select saml server and click new server to display the configuration page complete the configuration as described in the following table save the configuration you can configure multiple realms with one realm having machine auth and another realm with saml authentication for more information on user tunnel mode configured with saml authentication, see kb45726 https //forums ivanti com/s/article/kb45726 the following table lists saml service provider profile settings guidelines name specify a name to identify the server instance settings saml version 2 0 override global host fqdn if selected, connect secure supports to override host fqdn for this saml server sa entity id this value is prepopulated it is generated by the system, based on the value for the host fqdn for saml setting on the system > configuration > saml > settings page configuration mode select manual or metadata if a metadata file or location is available from the saml identity provider, use the metadata option to make configuration simpler and less prone to error to upload or set the location for the published metadata file, select system > configuration > saml and click the new metadata provider button identity provider entity id the identity provider entity id is sent as the issuer value in the assertion generated by the saml identity provider if you use the metadata option, this setting can be completed by selecting the identity provider entity id from the list the list is populated by the identity provider entities defined in metadata files added to the system > configuration > saml page if you complete this setting manually, specify the issuer value in assertions generated by the saml identity provider typically, you ask the saml identity provider administrator for this setting identity provider single sign on service url the identity provider sso service url is a url provisioned by the saml identity provider the setting is required to support service provider initiated sso if missing, the system cannot successfully redirect the user request if you use the metadata option, this setting can be completed by selecting the sso service url from the list the list is populated by the identity provider entities defined in metadata files added to the system > configuration > saml page if you complete this setting manually, ask the saml identity provider administrator for this setting user name template specify how the system is to derive the username from the assertion if the field is left blank, it uses the string received in the nameid field of the incoming assertion as the username 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 "management" to use all values, add the sep attribute to the variable for example, if you enter \<certdn out sep=" ">, the system uses "management\ sales" the attributes received in the attribute statement in the incoming assertion are saved under userattr these variables can also be used with angle brackets and plain text if the username cannot be generated using the specified template, the login fails if the nameid filed of the incoming assertion is of type x509nameformat, then the individual fields can be extracted using system variable "assertionnamedn" currently supported nameids are email, x509 subject, win domain qualified if a saml request is received with a different nameid format, then processing of the request fails with unsupported nameid format error message allowed clock skew (minutes) specify the maximum allowed difference in time between the system clock and the saml identity provider server clock saml is a time sensitive protocol the time based validity of a saml assertion is determined by the saml identity provider if the saml identity provider and saml service provider clocks are askew, the assertion can be determined invalid, and you will receive the following error "saml transferred failed please contact your system administrator detail failure no valid assertion found in saml response " we recommend you use ntp to ensure the clocks are synchronized and that you set an allowed clock skew value that accommodates any expected or permissible skew support single logout single logout is a mechanism provided by saml for logging out a particular user from all the sessions created by the identity provider select this option if the system must receive and send a single logout request for the peer saml identity provider if you use the metadata option, the single logout service url setting can be completed by selecting the slo service url from the list the list is populated by the identity provider entities defined in metadata files added to the system > configuration > saml page the system sends single logout requests to this url in addition, if you use the metadata option, the single logout response url setting is completed based on your selection for single logout service url if the identity provider has left this setting empty in its metadata file, the system sends the single logout response to the slo service url if you complete these settings manually, ask the saml identity provider administrator for guidance the support single logout service for the identity provider must present a valid certificate sso method post when configured to use the post binding, the system uses a response signing certificate to verify the signature in the incoming response or assertion the certificate file must be in pem or der format the certificate you select should be the same certificate used by the identity provider to sign saml responses complete the following settings to configure saml using the http post binding response signing certificate if you use the metadata based configuration option, select a certificate from the list the list is populated by the identity provider entities defined in metadata files added to the system > configuration > saml page if you configure these settings manually, browse to and upload the certificate to be used to validate the signature in the incoming response or assertion if no certificate is specified, the certificate embedded in the response is used enable signing certificate status checking select this option to check the validity of the signing certificate before verifying the signature this setting applies to any certificate used for signature verification if this option is enabled, the response will be rejected if the certificate is revoked, expired, or untrusted if this option is selected, the certificate ca must be added to the trusted client ca store if this option is not enabled, then the certificate is used without any checks select device certificate for signing select the device certificate the system uses to sign the authnrequest sent to the identity provider sso service if you do not select a certificate, the system does not sign authnrequest select device certificate for encryption select the device certificate the system uses to decrypt encrypted data received in the saml response the public key associated with the device certificate is used by the identity provider for encryption authentication context classes use the add and remove buttons to select authentication context classes to be sent in the authentication requests to the saml identity provider these are included in the requestedauthncontext element in the oasis standard, an authentication context is defined as "the information, additional to the authentication assertion itself, that the relying party may require before it makes an entitlements decision with respect to an authentication assertion " this feature supports all authentication context classes specified in the saml 2 0 oasis authn context specification for example, if you select x509, the system sends the following context \<samlp\ requestedauthncontext> \<saml\ authncontextclassref xmlns\ saml="urn\ oasis\ names🇹🇨saml 2 0\ assertion"> urn\ oasis\ names🇹🇨saml 2 0🇦🇨classes\ x509\</saml\ authncontextclassref> \</samlp\ requestedauthncontext> in response, the saml idp sends the context data along with the authentication results the system stores the context data in the session cache and as a system variable named samlauthncontextclass the system variable can be used in role mapping rules and resource policy detailed rules specify a comparison attribute within the requestedauthncontext element the comparison attribute specifies the relative strengths of the authentication context classes specified in the request and the authentication methods offered by a saml idp the following values defined in the saml 2 0 oasis core specification can be selected exact requires the resulting authentication context in the authentication statement to be the exact match of at least one of the authentication contexts specified minimum requires the resulting authentication context in the authentication statement to be at least as strong as one of the authentication contexts specified maximum requires the resulting authentication context in the authentication statement to be stronger than any one of the authentication contexts specified better requires the resulting authentication context in the authentication statement to be as strong as possible without exceeding the strength of at least one of the authentication contexts specified select the same value that is configured on the saml idp if none is specified in the saml idp configuration, the implicit default is exact service provider metadata settings metadata validity enter the number of days the metadata is valid valid values are 0 to 9999 0 specifies the metadata does not expire do not publish sa metadata select this option if you do not want to publish the metadata at the location specified by the entity id field download metadata this button appears only after you have saved the authentication server configuration use this button to download the metadata of the current saml service provider user record synchronization enable user record synchronization allow users to retain their bookmarks and individual preferences regardless of which device they log in to logical auth server name specify the server name if you have enabled user record synchronization displaying the user accounts table to display user accounts, refer to the steps found in " displaying the user accounts table docid\ xspmmkliydjkgpv mrnqi using a time based one time password (totp) authentication server this topic describes the ivanti connect secure's integration with the time based one time password (totp) authentication servers totp authentication server overview this section describes support for using the local/remote ivanti connect secure totp authentication server understanding totp time based one time password (totp) algorithm as defined in rfc6238 is an authentication mechanism where a one time password (a k a token) is generated by the authentication server and client from a shared secret key and the current time ics can act as totp authentication server any third party totp applications (for example, windows authenticator or google authenticator) available on the mobile and desktop client platforms generate totp tokens the totp authentication option is natively available on ics without any additional products or license requirements customers can use totp authentication as part of their mfa policy, and strengthen their authentication mechanism for secure access scenarios 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 authserver can be exported and imported using xml however, totp user accounts cannot be imported via xml use rest apis or admin ui option to export/import totp users refer exporting/importing totp users docid\ xspmmkliydjkgpv mrnqi totp feature is configurable across clusters first time users have to register a new totp user account via web end users cannot use ivanti desktop applications and ivanti mac applications for new user registration 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 totpauthtokenentry thtml totpauthtokenentry mobile webkit thtml totpauthtokenentry ipad thtml totpauthtokenentry stdaln thtml these files can be downloaded from sample custom sign in pages url https //<\<pcs>>/dana admin/download/sample zip?url=/dana admin/auth/custompage cgi?op=download\&samplepage=sample configuring authentication with a totp authentication server configuring the totp authentication server settings to configure the totp server as local select authentication > auth servers select time based one time password (totp) server and click new server to display the configuration page complete the configuration as described in the following table save the configuration the following figure depicts the totp authentication server page local the following table lists the totp auth server settings local settings guidelines name specify a name to identify the server within the system server type totp server can be configured as local or remote select local local totp context is created locally and user database is maintained locally on the same device time skew specify maximum time difference between ivanti connect secure and end user device while authenticating a user's token (minimum 1 minute, maximum 5 minutes) number of attempts allowed specify maximum number of consecutive wrong attempts allowed after which account will be locked (minimum 1 attempt, maximum 5 attempts) custom message for registration page specify a custom message which can be shown on new totp user registration web page allow auto unlock when checked, locked account will be automatically unlocked after specified period (minimum 10 minutes, maximum 90 days) allow new totp user registration to happen via external port when unchecked (default), new totp user registrations will happen only via internal port accept totp authentication from remote ics devices when checked, rest access to this totp server is allowed from other ivanti connect secure devices display qr code during user registration when checked, displays qr code during user registration disable generation of backup codes when unchecked, generates backup codes to configure the totp server as remote select authentication > auth servers select time based one time password (totp) server and click new server to display the configuration page see figure 16 complete the configuration as described in the following table save the configuration if ics is configured to use remote totp server, then the remote ics should have a valid certificate issued by a trusted ca the following figure depicts the totp authentication server page remote the following table lists totp auth server settings remote settings guidelines name specify a name to identify the server within the system server type totp server can be configured as local or remote select remote remote in this configuration, authentication checks take place on the remote totp server the user local device (ics to which user is logging in) will act merely as a proxy between the user's client device and totp server the communication to the remote device happens on rest api allow new totp user registration to happen via external port if this option is not selected, new totp user registrations happen only via company intranet network host name/ip specify remote host name or ip address where the totp server is configured the ip address or host name must match the common name mentioned in the remote totp server certificate totp server name this is the name of the totp server configured on the remote totp server rest api login enter the rest api login name rest api password enter the rest api password rest authentication realm enter the realm name, which refers to the realm that should be used for authenticating the rest user (using the auth server mapped to the realm) warning this field is mandatory if the realm field is not entered, user logins fail after upgrade test connection this button is used to validate the connection to the remote totp server customer needs to upload proper certificate to the remote totp server wildcard certificate is also supported configuring admin/user realm to associate a totp authentication server as secondary authentication server for example, to configure a user realm select users > user realms > new user realm complete the settings for the user realm check the enable additional authentication server option under additional authentication server, select any already created totp authentication server from the authentication #2 dropdown, as shown in the following figure 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 click on save changes the following figure depicts configuring 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 log in to the above configured user realm after successful authentication with primary authentication server, user1 is shown the totp registration page see the following figure 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) 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 the google authentication app (for ga user1) generates a new 6 digit number called as a token once in every 30 seconds 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 the following figure depicts first time registration to a totp server for already registered user, perform the following steps the already registered user (for example user1), whose realm was associated with secondary authentication server configured as totp authentication server, accesses ics url via web (user1 has already registered totp user in google authenticator app ) after successful authentication with primary authentication server, user1 is shown totp token entry page as seen in figure 19 user1 opens google authentication app that was installed in mobile (or pc), enters the current token to the authentication code if mobile is not available, user can enter any of the unused backup codes 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 the following figure depicts the google authentication token displaying the user accounts table to display user accounts select authentication > auth servers click the link for the authentication server you want to manage click the users tab to display the user accounts table the user accounts table includes entries for the accounts that have been created see the following figure the "last attempted" column shows the last time and date a user attempted to log in the "last successful login" shows the last successful sign in date and time for each user 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 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 the following figure depicts displaying the user accounts table to unlock a totp user's account go to the users tab the list of users is displayed select the user whose account you choose to unlock click on the unlock button the following figure depicts unlocking a user to reset a totp user's account go to the users tab the list of users is displayed select the user whose account you choose to reset click on the reset button this removes the user entry from the table the following figure depicts resetting a user viewing/generating backup codes to view/generate totp backup codes after successful log in to a totp server via web user successfully authenticates to primary auth server and totp auth server via web click on the preference option on the top of the page in the preference page, under totp backup codes, click on either view or generate to obtain user's totp backup codes the following figure depicts view/generate backup codes exporting/importing totp users to export/import totp users select authentication > auth servers click the link for the authentication server you want to manage click the users tab to display the user accounts table the user accounts table includes entries for the accounts that have been created see the following figure use the export and import buttons located at the bottom of the user accounts table to export and import totp users data enter the password to password protect the end user file and this password should adhere to ivanti password policy to import the user data enter the password if file is password protected windows hello for business sso server overview windows hello for business (whfb) is microsoft’s passwordless authentication solution for windows devices it enables users to sign in using biometrics (such as fingerprint or facial recognition) or a pin, with authentication backed by cryptographic keys securely stored on the device traffic control is supported for the whfb whfb supports multiple deployment models, including key trust certificate trust cloud kerberos trust saml based authentication on azure ad–joined devices on a windows system that is azure ad–joined and configured with windows hello for business, the ivanti secure access client (isac) can authenticate to the ivanti connect secure (ics) gateway using enhanced saml based authentication after signing in to windows using whfb (biometric or pin), users can seamlessly establish a vpn session to ics without re entering credentials this behavior is enabled by azure ad authentication state reuse browser based single sign on (sso) via saml integration between isac and azure ad–backed identity flows as a result, the client leverages the existing authenticated session to obtain a saml assertion, allowing transparent authentication to ics this feature is supported only on windows 10 and windows 11 operating systems with the windows isac desktop client it is not supported on macos isac clients or on windows versions earlier than windows 10, as microsoft no longer provides support for those operating systems configuring the whfb authentication server settings to configure the server as windows hello for business select authentication > auth servers select windows hello for business (whfb) sso server and click new server to display the configuration page complete the configuration as described in the following table save the configuration the following figure depicts the whfb authentication server page the following table lists the whfb auth server settings settings guidelines name specify a name to identify the server within the system client id client id of provider you can get this from azure ad configuration tenant id tenant id of provider you can get this from azure ad configuration time skew specify maximum time difference between ivanti connect secure and end user device while authenticating a user's token (minimum 1 minute, maximum 5 minutes) user name template enter the user name template as shown in example \<userprincipalname> or \<mail> or \<id> allowed clock skew (minutes) 0 5 minutes azure ad enforces a maximum of 5 minutes user record synchronization enable user record synchronization allow users to retain their bookmarks and individual preferences regardless of which device they log in to logical auth server name specify the server name if you have enabled user record synchronization under user realm configuration select this server as primary authentication using a rsa server (rest api) this topic describes integration with an rsa server (rest api) rsa authentication manager overview rsa authentication manager (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 access management framework, users can sign in to ivanti connect secure using the same username and password stored in the backend server the following table describes rsa securid hardware token and software token user sign in methods method action using a hardware token and the standard system sign in page the user browses to the standard system sign in page, and then enters the username and password (consisting of the concatenation of the pin and the rsa securid hardware token's current value) the system then forwards the user's credentials to the authentication server using a software token and the standard system sign in page the user browses to the standard system sign in page, and then enters the username and password (consisting of the concatenation of the pin and the rsa securid software token's current value) the system then forwards the user's credentials to the authentication server 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 for a new pin (new pin mode) if the user is signing in to the system for the first time or requires a pin reset, ivanti connect secure prompts the user to create a new pin prompts for the next token (next token mode) if the token code entered by the user is out of sync with the token expected by the rsa authentication manager, ivanti connect secure prompts the user to enter the next available token code the user must wait for the token value to change on their hardware token or securid app, and then manually enter the new code upload certificate and configuring the rsa authentication server settings to configure the server as rsa select authentication > auth servers select rsa server (rest api) server and click new server to display the configuration page complete the configuration as described in the following table save the configuration the following figure depicts the rsa authentication server page the following table lists the rsa auth server settings settings guidelines name specify a name to identify the server within the system rest server url base url of the rsa authentication manager rest api (e g , https //rsa am example com) client id enter the unique id of the ivanti connect secure (ics) this value must also be configured as the hostname for the corresponding authentication agent in rsa authentication manager enter the hostname of the ivanti connect secure (ics) appliance you can find the hostname under system > network > overview ensure that the same hostname and the ip address of the ics appliance are configured as an authentication agent in rsa authentication manager in rsa 8 7 setup > system settings > authentication settings > rsa securid authentication api in rsa 8 8 access > authentication agents > agent credentials access id enter the access id configured for the ics appliance in rsa authentication manager access id used to authenticate api requests from the ics to rsa authentication manager in rsa 8 8 navigate to access > authentication agents > agent credentials in rsa 8 7 navigate to setup > system settings > authentication settings > rsa securid authentication api access key secret access key corresponding to the access id enter the access key configured for the ics appliance in rsa authentication manager in rsa 8 8 navigate to access > authentication agents > agent credentials in rsa 8 7 navigate to setup > system settings > authentication settings > rsa securid authentication api communication port port used for rest api communication (default 5555) root ca certificate ca certificate used to validate the connection to the rsa authentication manager test connection sends an initialize request to the rsa authentication manager to verify connectivity (does not require saving) user record synchronization enable user record synchronization allow users to retain their bookmarks and individual preferences regardless of which device they log in to logical auth server name specify the server name if you have enabled user record synchronization certificates referenced by an xml configuration import must already be present on the system do not include certificates and dependent configurations in the same xml file, as the import order is not guaranteed import the certificates first, and then import the configuration that references them integrating ics with rsa authentication manager using rest api prerequisites ensure the following conditions are met before proceeding rsa authentication manager version rest api functionality is supported in rsa authentication manager beginning with release 8 2 as of now, only version 8 6 and above are within the supported lifecycle, whereas all earlier versions are considered end of support (eos) ics supports rsa 8 8 and 8 7 network access ics must be able to communicate with rsa am over the configured rest port (default tcp port 5555) certificate requirement sha‑1 certificates are not supported by ics always use ca signed certificates in production environments ensure system clocks are synchronized between ics and rsa am restart services if configuration changes do not take effect traffic control feature is not supported on the auth server enable rest api on rsa authentication manager log in to the rsa security console navigate to setup > system settings > rest api settings enable rest api access note the following port number (default 5555) access id access key configure firewall rules ensure the following network requirements allow tcp traffic from ics to rsa am default rest api port tcp 5555 verify connectivity using basic network tools (e g , telnet or nc) compatibility with existing configuration on rsa auth manager existing rsa authentication agents configured on ics remain usable existing user configurations are unaffected obtaining the rsa root ca certificate the root ca certificate is used to establish secure ssl communication between ivanti connect secure (ics) and rsa authentication manager the rsa root ca certificate can be exported directly from the rsa authentication manager security console using a web browser log in to the rsa security console or operations console in the browser address bar, click the not secure or certificate icon displayed next to the rsa authentication manager url in the certificate information dialog, click on the certificate in the certificate viewer , select the details tab under certificate hierarchy , select the rsa root ca certificate click export in the save as dialog enter a file name for the certificate select base64 encoded ascii, single certificate as the file format click save