Creating User Authentication Services

ivanti neurons for zero trust access (nzta) provides user authentication through authentication policies policies define the application of an authentication method for a specified access url nzta facilitates multi factor authentication (mfa) through the configuration of an optional secondary authentication method in a policy mfa based policies can use local authentication or time based one time password (totp) as the secondary method nzta also provides for the definition of user rules and user groups rules act as filters and define the basic criteria by which users’ credentials must match in order for authentication to proceed groups encapsulate an authentication policy with one or more user rules to provide a complete user authentication definition for your secure access policy to learn more about creating user rules and user groups , see creating user rules and user groups nzta provides three default/built in authentication policies, suitable for the primary use cases of administrative sign in, user enrollment, and user sign in admin signin this policy is used whenever admin users log in that is, for connection requests to the /login/admin/ url it is referenced by the alladminusers user rule, which associates it with the administrators user rule group user signin this policy can be used as the primary connection endpoint for all user device sign in and enrollment requests that is, for connection requests to the /login/ url it is referenced by the allusers user rule, which associates it with the users user rule group as mentioned above, users connecting an un enrolled device to this policy are automatically redirected to the enrollment signin policy these policies are fixed and cannot be deleted however, you can edit them to reference specific authentication methods mfa is supported for admin signin and user signin policies only to learn more, see the tenant admin guide furthermore, you can create additional custom authentication policies to enable bespoke authentication for specific groups of users or parts of your organization each policy should contain a unique access url to which your users connect, and each should then be configured to link to authentication methods applicable for that purpose nzta supports creating authentication services based on the following methods local authentication an authentication system that is internal to the controller you must create all users manually on the controller, and configure any required authentication policies see workflow creating a local authentication policy azure ad saml authentication an existing remote saml authentication system based on an azure ad server see workflow creating a saml authentication policy with azure ad on prem ics saml authentication an existing remote saml authentication system based on an on prem ics server see workflow creating a saml authentication policy with on prem ics time based one time password (totp) authentication a one time use password authenticator whereby a password (also known as a token) is generated by the controller and the client from a shared secret key and the current time totp is used as a secondary authentication method as part of a multi factor authentication deployment see workflow adding totp to an authentication policy for further supported saml authentication services, see the tenant admin guide in each of the scenarios listed in this guide, to ensure that your users can access the authentication mechanism defined through this process, make sure your secure access policies are configured with a user group in which your newly configured authentication policies are defined workflow creating a local authentication policy this process involves creating a local user authentication method and defining within it all user credentials necessary to identify and authenticate your end users you then configure this method as the primary authentication method in your authentication policies if you are configuring multi factor authentication (mfa) in your deployment, you can configure local user authentication as either the primary or secondary authentication method before you begin, make sure you have all user details (name and password) ready to configure a new local authentication method log into the controller as a tenant admin, see logging in as a tenant administrator docid\ bfa9xpzcjyylrirzvpscs from the nzta menu, select the secure access icon, then select manage users > authentication servers the authentication servers page appears this page lists all existing user authentication methods for example user authentication methods select create authentication server a form appears that enables you to define the authentication method adding a new local user authentication method under choose name and type specify an authentication server name select the authorization type of local click create user the create local user dialog appears to show additional local authentication settings adding local users to a new authentication method enter the following settings specify a user name , full name , and email for the user specify a password and confirm password for the user (optional) select the temporary password check box if you want the user to change their password when they first log in click create user the user is added to the list of users repeat the previous step for each required user click create authentication server the new local user authentication method is added to the list of methods and the process is complete after you have created your local authentication method, create or update your authentication policies with the new authentication method nzta provides built in policies to cover both basic cases in addition, nzta allows for the definition of custom policies to facilitate separate authentication endpoints for specific groups of users to learn more, see using user authentication policies docid\ bfa9xpzcjyylrirzvpscs repeat the following steps for each policy, starting with enrollment from the nzta menu, select the secure access icon, then select manage users > user policies the user policies page appears this page lists all existing user authentication policies user authentication policies to learn more about the policies on this page, see viewing user authentication policies docid\ bfa9xpzcjyylrirzvpscs from this page, either create a new custom policy or edit an existing policy to add a new custom policy, click create user policy the create authentication policy form appears create authentication policy to learn more about how custom policies are used for user login and enrollment, see adding custom authentication policies docid\ bfa9xpzcjyylrirzvpscs enter a policy name enter a login url using the format /login/\<path>/ the url must start with " /login/ " and cannot contain any special characters \<path> should be set to a unique value reflecting the endpoint url you want to define for this authentication policy (appended with a backslash) in the case of user sign in policies, this is the url endpoint (appended to the tenant fqdn) to which new users are invited to connect to enroll or sign in a device with the controller example value " /login/saleslogin/ " in the case of user enrollment policies, this endpoint identifies the enrollment url to which users are redirected if they attempt to connect to the equivalent sign in policy with an un enrolled device in most cases, you do not advertise this endpoint to your users example value " /login/salesenroll/ " in some enrollment circumstances, such as when using a device pre installed with an older version of ivanti secure access client , you connect directly to the enrollment policy endpoint to enroll the device for more details, see using user authentication policies docid\ bfa9xpzcjyylrirzvpscs (optional) enter a description for the authentication policy select a user type based on the intended authentication activity for this policy choose from users select this option to define the user sign in endpoint for enrolled devices this is the endpoint that you provide to your users to access the service (regardless of enrollment status) administrators select this option to define the authentication endpoint for administrator level sign in this endpoint is used for administrator login to the controller only (for policies with a user type of "users" only) select an enroll device policy from the drop down list to be linked to this sign in policy (as indicated) linking an enrollment policy to a user sign in policy this is the enrollment policy to which a user is redirected if it is determined that the device is not yet enrolled to learn more, see using user authentication policies docid\ bfa9xpzcjyylrirzvpscs under policy server details , select primary auth server from the drop down list selecting a primary authentication method for this policy (optional) where a secondary method is required for multi factor authentication, select secondary auth server from the drop down list secondary authentication methods do not apply to enrollment user type policies the relevant field is hidden in this case click create user policy to create the new policy the new policy is added to the list of authentication policies if you instead elect to update an existing custom or built in policy click the three dots adjacent to the relevant policy, then select edit the edit authentication policy form appears for built in authentication policies, all properties except primary auth server and secondary auth server (where applicable) are read only configure the primary and/or secondary authentication methods, as required set the primary auth server to be the new local user authentication method (indicated) editing the primary auth server if you are configuring a policy for mfa, set the secondary auth server to be the new local user authentication method (indicated) if you configure a secondary authentication method in a policy that is currently in use, any active user sessions must be disconnected and reconnected for the changes to take effect click update user policy the list of authentication policies updates repeat until all required authentication policies are updated to ensure that your users can access the authentication mechanism defined in the policies you configure through this process, make sure your secure access policies are configured with a user group in which these authentication policies are defined to learn more, see creating/editing secure access policies docid\ bfa9xpzcjyylrirzvpscs for more information, see the tenant admin guide workflow creating a saml authentication policy with azure ad nzta supports the use of a cloud based active directory (ad) saml service to provide authentication for your users if you choose to use ad as a saml identity provider (idp), you do not create any users locally on the controller all users will already be present in your remote saml service configuring nzta to use saml authentication requires you to create separate saml apps on the azure ad platform for the following primary activities user sign in user enrollment as part of hardening custom sign in policies and login urls, the following changes are implemented instead of requiring administrators to configure enrollment policies, administrators will only need to configure user policies as a default, all configured user policies support enrollment single saml authentication server for user authentication and enrollment the controller includes built in default authentication policies for each of these purposes, and also includes the ability to create your own custom policies for separate authentication of specific user groups you create an authentication method referencing one of the azure ad saml apps described above and then assign the method to an authentication policy of the same type (either the built in policy, or one you create) configuring nzta to use saml authentication configure nzta by performing the following steps log into the controller as a tenant admin, see logging in as a tenant administrator docid\ bfa9xpzcjyylrirzvpscs from the nzta menu, select the secure access icon, then select manage users > authentication servers the authentication servers page appears this page lists all existing user authentication methods user authentication methods click create authentication server a form appears that enables you to define the authentication method adding a user authentication method at any point during this process, you can reset the form data by selecting reset fields under choose server name and authentication type select the authentication type as saml (azure ad) the form expands to show additional settings configuring saml (azure ad) authentication settings specify an authentication server name to provide your saml idp settings, select one of the following select upload saml auth metadata file if not selected already this is selected by default the download auth service provider metadata for idp link is enabled (optional) specify a single logout url for more information, see using saml single logout to force user authentication docid\ bfa9xpzcjyylrirzvpscs by default, the controller expects a signed metadata definition file to allow an unsigned metadata file, select allow unsigned metadata click the download auth service provider metadata for idp link retain the downloaded file for later use select enter saml auth metada details manually to manually enter the required idp saml settings use this option in scenarios where a saml federation metadata file is not available or incomplete then, enter the following details configuring saml (azure ad) idp settings manually the following minimum settings are required for your saml authentication service to function correctly each setting relates to a value configured in the saml application on your idp contact your idp administrator to obtain the relevant details idp entity id the entity id is sent as the issuer value in the saml assertion generated by the idp specify the issuer value in assertions generated by the saml identity provider idp sso url a url provisioned by the saml idp to support service provider initiated single sign on use the format https //\<fqdn> idp slo service (optional) a url to specify the single log out/sign out endpoint if you want to force re authentication for increased security use the format https //\<fqdn> for more information, see using saml single logout to force user authentication docid\ bfa9xpzcjyylrirzvpscs user name template specify how the system is to derive the username from the saml assertion the default value can be used, or replaced with an alternative specifier that the controller uses from the incoming assertion for example \<assertionnamedn uid> , the nameid value where ics is the idp, the uid from x509subjectname, \<userattr attr> , attr from attributestatement attributes idp signing certificate the signing certificate to be used with the saml app on the idp type or paste in the contents of your base 64 encoded public key if this auth server is used with user policy of type “user”, then click enable enrollment enable enrollment to provide your saml idp settings, select one of the following select upload saml enroll metadata file if not selected already this is selected by default (optional) specify a single logout url for more information, see using saml single logout to force user authentication docid\ bfa9xpzcjyylrirzvpscs by default, the controller expects a signed metadata definition file to allow an unsigned metadata file, select allow unsigned metadata click the download enroll service provider metadata for idp link select enter saml enroll metada details manually to manually enter the required idp saml settings use this option in scenarios where a saml federation metadata file is not available or incomplete then, enter the following details configuring saml (azure ad) idp settings manually the following minimum settings are required for your saml authentication service to function correctly each setting relates to a value configured in the saml application on your idp contact your idp administrator to obtain the relevant details idp entity id the entity id is sent as the issuer value in the saml assertion generated by the idp specify the issuer value in assertions generated by the saml identity provider idp sso url a url provisioned by the saml idp to support service provider initiated single sign on use the format https //\<fqdn> idp slo service (optional) a url to specify the single log out/sign out endpoint if you want to force re authentication for increased security use the format https //\<fqdn> for more information, see using saml single logout to force user authentication docid\ bfa9xpzcjyylrirzvpscs user name template specify how the system is to derive the username from the saml assertion the default value can be used, or replaced with an alternative specifier that the controller uses from the incoming assertion for example \<assertionnamedn uid> , the nameid value where ics is the idp, the uid from x509subjectname, \<userattr attr> , attr from attributestatement attributes idp signing certificate the signing certificate to be used with the saml app on the idp type or paste in the contents of your base 64 encoded public key \ when editing an existing saml auth server, the 'enable enrollment' option can be enabled or disabled if the saml auth server is not being used in any ‘user policy’ if the saml auth server is being used in a ‘user policy’, then enable enrollment button will be grayed out if 'enable enrollment' is not selected, then while creation of 'user policy' of type 'user', the server you have created (without enable enrollment) will not be listed when enrollment is disabled, the enrollment saml configuration will be deleted to enable enrollment, you have to again provide enroll saml auth server configuration use the downloaded user authentication and enrollment sp metadata files to create sign in and enrollment saml apps in azure ad for details, see creating enrollment/sign in saml app in azure ad docid\ bfa9xpzcjyylrirzvpscs browse and upload the digitally signed (or unsigned) federation metadata xml definition files downloaded from azure ad confirm that your settings are correct, then select create authentication server to create the authentication method the new saml user authentication method is added to the list of methods displayed in the user authentication page, and the process completes (optional) to edit a listed authentication method, click the adjacent three dots, then select edit make any required updates and confirm (optional) to delete one (or more) an unused authentication methods, select the check box for each, then select delete you must confirm the deletion creating enrollment/sign in saml app in azure ad perform the following steps in azure ad create a saml app for the required activity (sign in or enrollment) click upload metadata file and select the file from your download this defines at least the following basic saml configuration fields identifier (entity id) this is the url of the saml endpoint on the controller this is the audience of the saml response for idp initiated sso this cannot be left blank reply url (assertion consumer service url) this is the url of the saml consumer on the controller this is the destination url in the saml response for idp initiated sso this cannot be left blank setting basic saml configuration in azure ad applications download the federation metadata xml definition for the saml app to your local workstation retain this file for later use downloading federation metadata xml files for user enrollment and user sign in saml applications repeat these steps for each activity for details on how to create saml apps in azure ad, see the azure ad saml documentation creating/updating authentication policies after you have created your saml authentication method, create or update your authentication policies with the new authentication method from the nzta menu, select the secure access icon, then select manage users > user policies the user policies page appears this page lists all existing user authentication policies user authentication policies to learn more about the policies on this page, see viewing user authentication policies docid\ bfa9xpzcjyylrirzvpscs from this page, either create a new custom policy or edit an existing policy to add a new custom policy, select create user policy the create authentication policy form appears create authentication policy at any point during this process, you can reset the form data by selecting reset fields to learn more about how custom policies are used for user login and enrollment, see adding custom authentication policies docid\ bfa9xpzcjyylrirzvpscs enter a policy name enter a login url using the format /login/\<path>/ the url must start with " /login/ " and cannot contain any special characters \<path> should be set to a unique value reflecting the endpoint url you want to define for this authentication policy (appended with a backslash) in the case of user sign in policies, this is the url endpoint (appended to the tenant fqdn) to which new users are invited to connect to enroll or sign in a device with the controller example value " /login/saleslogin/ " in the case of user enrollment policies, this endpoint identifies the enrollment url to which users are redirected if they attempt to connect to the equivalent sign in policy with an un enrolled device in most cases, you do not advertise this endpoint to your users example value " /login/salesenroll/ " in some enrollment circumstances, such as when using a device pre installed with an older version of ivanti secure access client , you connect directly to the enrollment policy endpoint to enroll the device for more details, see using user authentication policies docid\ bfa9xpzcjyylrirzvpscs (optional) enter a description for the authentication policy select a user type based on the intended authentication activity for this policy choose from users select this option to define the user sign in endpoint for enrolled devices this is the endpoint that you provide to your users to access the service (regardless of enrollment status) administrators select this option to define the authentication endpoint for administrator level sign in this endpoint is used for administrator login to the controller only from the device policy list, select a device policy (for policies with a user type of "users" only) select an enroll device policy from the drop down list to be linked to this sign in policy (as indicated) this is the enrollment policy to which a user is redirected if it is determined that the device is not yet enrolled to learn more, see using user authentication policies docid\ bfa9xpzcjyylrirzvpscs under auth servers , select primary auth server and choose the required authentication method from the drop down list only local and saml servers will be available for selection as a primary auth server (optional) where a secondary method is required for multi factor authentication, select secondary auth server and choose the required authentication method from the drop down list only local and totp servers will be available for selection as a secondary auth server click create user policy to create the new policy the new policy is added to the list of authentication policies existing user policies for existing default user policies, admin can select either existing or new saml or local auth server note the auth server for enrollment will be added automatically for existing custom user policies, user can update existing saml auth server if you intend to update an existing custom or built in policy click the three dots adjacent to the relevant policy, then select edit the update authentication policy form appears for built in authentication policies, all properties except primary auth server and secondary auth server (where applicable) are read only set the primary auth server to be the new saml user authentication method (indicated) editing the primary auth server saml authentication can be used only as a primary auth server if you are using mfa, specify either a local authentiction or totp method as the secondary auth server if you configure a secondary authentication method in a policy that is currently in use, any active user sessions must be disconnected and reconnected for the changes to take effect select update user policy the list of authentication policies updates repeat until all required authentication policies are updated at this point, the controller uses the uploaded federation metadata to contact the saml service after this process completes, a download function becomes available for each relevant policy this metadata file is required to configure trusted communication with the remote saml service refresh your browser until the download action is visible for the relevant policies select the check box for the policy metadata you want to download and clear all other check boxes select download and save the metadata file as mentioned previously, make sure you repeat this procedure for each required saml app on your azure ad platform that is, you require separate xml metadata files for the enrollment authentication policy and the login authentication policy after the user authentication workflow is complete, you can configure the azure ad platform with the xml configuration of the controller for details on how to configure azure ad, see configuring azure ad with service provider metadata from the controller docid\ bfa9xpzcjyylrirzvpscs finally, to ensure that your users can access the authentication mechanism defined in the policies you configure through this process, make sure your secure access policies are configured with a user group in which these authentication policies are defined to learn more, see creating/editing secure access policies docid\ bfa9xpzcjyylrirzvpscs for more information, see the tenant admin guide workflow creating a saml authentication policy with on prem ics you can choose to use a configured ics server (either remote or local) as an on premises saml ad authentication server for your controller if you choose to use saml authentication on your controller , you do not create any users manually all users will already be present on your remote saml server configuring nzta to use saml authentication requires you to create separate saml apps on the on premises ics server for the following primary activities user enrollment user sign in the controller includes built in default authentication policies for each of these purposes and includes the ability to create your own custom policies for separate authentication of specific groups you create an authentication method referencing one of the saml apps described above and then assign the method to an authentication policy of the same type (either the built in policy, or one you create) begin with enrollment, and then repeat the process for user sign in to configure nzta to use saml authentication through ics , perform the following steps configure your on premises ics to act as a saml ad authentication server optionally, configuring secondary authentication for on premises ics (optional) docid\ bfa9xpzcjyylrirzvpscs configuring a saml identity provider in ivanti connect secure docid\ bfa9xpzcjyylrirzvpscs configuring a metadata provider in ivanti connect secure docid\ bfa9xpzcjyylrirzvpscs define an on premises saml authentication method, see defining an on premises saml authentication method docid\ bfa9xpzcjyylrirzvpscs configure an on premises saml authentication policy, see defining authentication policies for on premises saml authentication docid\ bfa9xpzcjyylrirzvpscs after you complete the user authentication workflow, configure the saml apps on the on premises ics server with the xml metadata configuration from the matching nzta authentication policy, see configuring ics with controller metadata docid\ bfa9xpzcjyylrirzvpscs you will need to repeat this process for each required saml app on your ics server to ensure that your users can access the authentication mechanism defined in the policies you configure through this process, make sure your secure access policies are configured with a user group in which these authentication policies are defined to learn more, see creating/editing secure access policies docid\ bfa9xpzcjyylrirzvpscs configuring secondary authentication for on premises ics (optional) this section describes an optional configuration activity for saml user authentication on an on premises ics server multi factor authentication (mfa) is an authentication method by which a computer user is granted access only after successfully presenting two (or more) pieces of evidence (or factors) to an authentication mechanism the ics platform supports a number of secondary authentication solutions, and can be configured so that two authentication factors are required by users using a single nzta user authentication method before you configure the on premises ics server and controller for saml user authentication, you can choose to configure mfa (secondary) support to ics before you start this procedure, you must have fully configured a secondary authentication server for example, google otp (one time password) or nas otp for the purposes of this example, an existing local google otp server is used, but different established secondary authentication methods are also supported to configure ics for secondary authentication log in to the on premises ivanti connect secure server on the authentication menu, select auth servers the authentication servers page appears under new , select the required authentication server type for example, select time based one time password (totp) server select new server the new time based one time password (totp) server page appears enter the following parameters for the new server add a name for the server, for example google otp select the allow auto unlock check box, and set auto unlock period for example, 10 minutes select the allow new totp user registration to happen via external port check box select the allow totp authentication from remote pulse secure devices check box leave all other parameters as their default settings select save changes the new server (google otp) is added to the list of authentication servers you must now add a new user to the local system to do this in the authentication servers list, select the hyperlink for the system local entry the settings page for system local appears select the users tab select new to create a user the new local user page appears enter details for the user, and ensure that the enabled check box is selected, and that other check boxes are clear select save changes to create the user select the users menu, then select user realms the user authentication realms page appears you must now enable secondary authentication to do this in the user authentication realms list, select the hyperlink for the users entry the general page for the users realm appears under additional authentication server , select the enable additional authentication server check box set authentication #2 to google otp at the bottom of the page, select save changes you can now configure an identity provider in ics , see configuring a saml identity provider in ivanti connect secure docid\ bfa9xpzcjyylrirzvpscs configuring a saml identity provider in ivanti connect secure this section describes the steps to configure a saml identity provider (idp) on an on premises ivanti connect secure ( ics ) server the metadata for the idp is required by each saml user method on nzta to configure saml idp on the ivanti connect secure server log in to the on premises ivanti connect secure server that is identified as an identity provider navigate to system > configuration > saml > settings configure the following metadata server configuration timeout value for metadata fetch request to 300 host fqdn for saml to the fully qualified domain name, noting the host fqdn guidance below the host fqdn specified here is used in the saml entity id, used by browsers to connect to ics , and used in the urls for saml services typically if the ics is standalone, the fqdn should resolve to the ip address of the external interface / internal interface, whichever is chosen if the ics is an active passive cluster, the fqdn should resolve to the external vip / internal vip, whichever is chosen if the ics is an active active cluster behind an in line load balancer, the fqdn should resolve to the load balancer's external vip / internal vip, whichever is chosen select save changes select update entity ids and confirm this action on the warning page by selecting update entity ids navigate to system > configuration > certificates > device certificate , create a new csr, and import certificate and keys skip this step if the ics external interface / internal interface (whichever is chosen) already provides a certificate that matches the host’s fully qualified domain name navigate to authentication > signing in > sign in saml > identity provider locate the the basic identity provider (idp) configuration section under protocol binding to use for saml response select the post check box clear the artifact check box select the required signing certificate under other configurations select the accept unsigned authnrequest check box select sha 256 for signature algorithm, if ics is using 22 x version onwards under service provider related idp configuration for signin policy , select the / policy under user identity for subject name format , select email address for subject name , enter \<username> at the bottom of the page, select save changes you can now configure a metadata provider in ics , see configuring a metadata provider in ivanti connect secure docid\ bfa9xpzcjyylrirzvpscs configuring a metadata provider in ivanti connect secure this section describes the steps to configure ivanti connect secure to be a metadata provider, and to download metadata for use on the controller to configure a metadata provider in the on premises ics server log in to ivanti connect secure server navigate to authentication > signing in > sign in saml > metadata provider the saml metadata provider entity id property is pre populated it is generated by the system, based on the value for the host fqdn for saml setting on the system > configuration > saml > settings page set metadata validity to 365 days clear the do not publish idp in metadata check box select save metadata provider select download metadata and save the file to your computer this definition file is required to enable on premises saml apps on the controller you can then configure the controller to use an on premises saml server, see defining an on premises saml authentication method docid\ bfa9xpzcjyylrirzvpscs defining an on premises saml authentication method a minimum of two authentication methods are required an authentication method for a saml enrollment sign in app an authentication method for a saml user sign in app to create an on premises saml server authentication method for a specific activity, for example, device enrollment log into the controller as a tenant admin, see logging in as a tenant administrator docid\ bfa9xpzcjyylrirzvpscs from the nzta menu, select the secure access icon, then select manage users > authentication servers the authentication servers page appears this page lists all existing user authentication methods user authentication methods select create authentication server a form appears that enables you to define the authentication method creating a user authentication method at any point during this process, you can reset the form data by selecting reset vields under choose server name and authentication type select the authentication type of saml (custom) the form expands to show additional settings configuring saml (custom) authentication settings specify an authentication server name for example enrollment or signin to provide your saml idp settings, select one of the following select upload saml auth metadata file if not selected already this is selected by default the download auth service provider metadata for idp link is enabled (optional) specify a single logout url for more information, see using saml single logout to force user authentication docid\ bfa9xpzcjyylrirzvpscs by default, the controller expects a signed metadata definition file to allow an unsigned metadata file, select allow unsigned metadata click the download auth service provider metadata for idp link retain the downloaded file for later use select enter saml auth metada details manually to manually enter the required idp saml settings use this option in scenarios where a saml federation metadata file is not available or incomplete then, enter the following details configuring saml (azure ad) idp settings manually the following minimum settings are required for your saml authentication service to function correctly each setting relates to a value configured in the saml application on your idp contact your idp administrator to obtain the relevant details idp entity id the entity id is sent as the issuer value in the saml assertion generated by the idp specify the issuer value in assertions generated by the saml identity provider idp sso url a url provisioned by the saml idp to support service provider initiated single sign on use the format https //\<fqdn> idp slo service (optional) a url to specify the single log out/sign out endpoint if you want to force re authentication for increased security use the format https //\<fqdn> for more information, see using saml single logout to force user authentication docid\ bfa9xpzcjyylrirzvpscs user name template specify how the system is to derive the username from the saml assertion the default value can be used, or replaced with an alternative specifier that the controller uses from the incoming assertion for example \<assertionnamedn uid> , the nameid value where ics is the idp, the uid from x509subjectname, \<userattr attr> , attr from attributestatement attributes idp signing certificate the signing certificate to be used with the saml app on the idp type or paste in the contents of your base 64 encoded public key \ when editing an existing saml auth server, the 'enable enrollment' option can be enabled or disabled if the saml auth server is not being used in any ‘user policy’ if the saml auth server is being used in a ‘user policy’, then enable enrollment button will be grayed out if 'enable enrollment' is not selected, then while creation of 'user policy' of type 'user', the server you have created (without enable enrollment) will not be listed when enrollment is disabled, the enrollment saml configuration will be deleted to enable enrollment, you have to again provide enroll saml auth server configuration confirm that your settings are correct, then select create authentication server to create the authentication method the new saml authentication method is added to the list of methods and the process is complete (optional) to edit a listed authentication method, click the adjacent three dots, then select edit make any required updates and confirm (optional) to delete one (or more) an unused authentication methods, select the check box for each, then select delete you must confirm the deletion you can now proceed to update the required authentication policy, see defining authentication policies for on premises saml authentication docid\ bfa9xpzcjyylrirzvpscs defining authentication policies for on premises saml authentication after you have created your saml authentication method, create or update your authentication policies with the new authentication method from the nzta menu, select the secure access icon, then select manage users > user policies the user policies page appears this page lists all existing user authentication policies user authentication policies to learn more about the policies on this page, see viewing user authentication policies docid\ bfa9xpzcjyylrirzvpscs from this page, either create a new custom policy or edit an existing policy to add a new custom policy select create user policy the create authentication policy form appears add user authentication at any point during this process, you can reset the form data by selecting reset fields to learn more about how custom policies are used for user login and enrollment, see adding custom authentication policies docid\ bfa9xpzcjyylrirzvpscs enter a policy name enter a login url using the format /login/\<path>/ the url must start with " /login/ " and cannot contain any special characters \<path> should be set to a unique value reflecting the endpoint url you want to define for this authentication policy (appended with a backslash) in the case of user sign in policies, this is the url endpoint (appended to the tenant fqdn) to which new users are invited to connect to enroll or sign in a device with the controller example value " /login/saleslogin/ " in the case of user enrollment policies, this endpoint identifies the enrollment url to which users are redirected if they attempt to connect to the equivalent sign in policy with an un enrolled device in most cases, you do not advertise this endpoint to your users example value " /login/salesenroll/ " in some enrollment circumstances, such as when using a device pre installed with an older version of ivanti secure access client , you connect directly to the enrollment policy endpoint to enroll the device for more details, see using user authentication policies docid\ bfa9xpzcjyylrirzvpscs (optional) enter a description for the authentication policy select a user type based on the intended authentication activity for this policy choose from users select this option to define the user sign in endpoint for enrolled devices this is the endpoint that you provide to your users to access the service (regardless of enrollment status) administrators select this option to define the authentication endpoint for administrator level sign in this endpoint is used for administrator login to the controller only (for policies with a user type of "users" only) select an enroll device policy from the drop down list to be linked to this sign in policy (as indicated) linking an enrollment policy to a user sign in policy this is the enrollment policy to which a user is redirected if it is determined that the device is not yet enrolled to learn more, see using user authentication policies docid\ bfa9xpzcjyylrirzvpscs under policy server details , select primary auth server and choose the required authentication method from the drop down list selecting a primary authentication method for this policy alternatively, select create authentication server and create a new authentication method as per the steps described earlier in this section (optional) where a secondary method is required for multi factor authentication, repeat the previous step for secondary auth server secondary authentication methods do not apply to enrollment user type policies the relevant field is hidden in this case select add to create the new policy the new policy is added to the list of authentication policies if you instead elect to update an existing custom or built in policy click the three dots adjacent to the relevant policy, then select edit the edit authentication policy form appears for built in authentication policies, all properties except primary auth server and secondary auth server (where applicable) are read only set the primary auth server to be the new saml user authentication method (indicated) editing the primary auth server saml authentication can be used only as a primary auth server if you are using mfa, specify either a local authentication or totp method as the secondary auth server if you configure a secondary authentication method in a policy that is currently in use, any active user sessions must be disconnected and reconnected for the changes to take effect select update user policy the list of authentication policies updates at this point, the controller uses the uploaded metadata to contact the saml service after this process completes, a download function becomes available for the policy this metadata file is required to configure trusted communication with the remote saml service perform the following steps refresh your browser until the download action is visible for the relevant policy select the check box for the policy and clear all other check boxes select download and save the metadata file repeat these procedures for each required saml app on your on prem ics server that is, you require separate xml metadata files for your enrollment authentication policy and your sign in authentication policy after you have configured a user authentication policy, you can configure your ics saml app with the sp metadata configuration of the controller , see configuring ics with controller metadata docid\ bfa9xpzcjyylrirzvpscs configuring ics with controller metadata before the controller can use a saml server on an on premises ics server, you must enable communication between each separate saml app on the ics server and the controller to do this, you must configure the saml apps on the on premises ics server with the xml metadata configuration file for the controller there are a minimum of two saml apps a saml app for user enrollment for example, called enrollment a saml app during user sign in for example, called signin you download the controller xml configuration file when you selected an authentication policy alternatively, select the policy, then select download on the user authentication policies page, see viewing user authentication policies docid\ bfa9xpzcjyylrirzvpscs to configure a saml app on ics with xml from the controller log into your ics platform navigate to system > configuration > saml select new metadata provider enter a name for the metadata provider under metadata provider location configuration for location , select local for upload metadata file , select browse and select the metadata that you saved on your computer in the previous process (see above) under metadata provider verification configuration select the accept unsigned metadata check box under metadata provider filter configuration for roles , select the service provider check box select save changes navigate to authentication > signing in > sign in saml > identity provider in the configuration section, select add sp the new peer service provider page appears in the service provider configuration and certificate status checking configuration sections, make the necessary service provider specific settings for more details, refer to the "configuring sign in saml identity provider settings" section in the " ivanti connect secure administration guide" in the customize idp behavior section, select the override default configuration check box clear the reuse existing nc (pulse) session check box select the accept unsigned authnrequest check box at the bottom of the page, select save changes after the on premises ics saml service is configured to connect to the controller , you can then create a user group to apply the newly created authentication policy to your secure applications, see creating user rules and user groups docid\ bfa9xpzcjyylrirzvpscs for more information, see the tenant admin guide workflow adding totp to an authentication policy this feature is supported for client and gateway versions applicable to release 22 2r1 and later only nzta supports the use of time based one time password (totp) as a secondary authentication method in multi factor authentication deployments to use totp, first create a totp authentication method in nzta and then associate it with your user sign in authentication policies to ensure that your users can access the authentication mechanism defined in the policies you configure through this process, make sure your secure access policies are configured with a user group in which these authentication policies are defined to learn more, see creating a secure access policy to configure a new totp authentication method log into the controller as a tenant admin from the nzta menu, select the secure access icon, then select manage users > authentication servers the authentication servers page appears this page lists all existing user authentication methods for example select create authentication server a form appears that enables you to define the authentication method at any point during this process, you can reset the form data by selecting reset you can also view existing authentication methods in a pop up dialog by selecting view auth methods under choose name and type specify an authentication server name select the authorization type of totp the form expands to show additional totp authentication settings enter the following settings this release supports a server type of local only this field is read only no of attempts the maximum number of consecutive wrong attempts allowed before which the account is locked (minimum 1 attempt, maximum 5 attempts) to view user attempts and to unlock locked accounts, see unlocking locked user accounts custom message for registration page a custom message to be shown on the new totp user registration web page allow auto unlock when selected, a locked account is automatically unlocked after the specified auto unlock period (minimum 10 minutes, maximum 90 days) display qr code during user registration when selected, a qr code is displayed during user registration disable generation of backup codes when selected, the controller does not generate totp backup codes to create an authentication method based on these settings, select add the new totp user authentication method is added to the list of methods and the process is complete after you have created your totp authentication method, create or update your user sign in authentication policies with the new method nzta supports using totp only as secondary authentication , so make sure you have previously configured a primary authentication method before continuing this process secondary authentication methods do not apply to enrollment user type policies the relevant field is hidden in this case complete the following steps for your user sign in authentication policy from the nzta menu, select the secure access icon, then select manage users > user policies the user policies page appears this page lists all existing user authentication policies to learn more about the policies on this page, see the tenant admin guide click the three dots adjacent to your desired user sign in policy, then select edit the edit authentication policy form appears for secondary auth server , select your new totp authentication method from the drop down list (as indicated) alternatively, select add new server and create a new authentication method as per the steps described earlier in this section select save to update the policy if you configure a secondary authentication method in a policy that is currently in use, any active user sessions must be disconnected and reconnected for the changes to take effect unlocking locked user accounts after you have created a totp authentication method and assigned it to an active user authentication policy, you can use the authentication method configuration page to view users that have attempted authentication through totp this information enables you to unlock locked user accounts, if required to access user attempt information, perform the following steps select secure access > manage users > authentication servers click the three dots adjacent to your totp authentication method, then select edit at the bottom of the page, a users table is presented this table lists each user who has attempted to authenticate a device through totp, including the last attempt and last successful login times (optional) if a user account is locked through too many consecutive failed authentication attempts (that exceed the value configured in no of attempts ), unlock the account by selecting the checkbox adjacent to the user entry and selecting unlock the user is then free to re attempt authentication using valid authentication codes (optional) to remove a user from the list, select the checkbox adjacent to the user entry and select reset this means a user must then re register their device with the totp policy reset and unlock operations of individual users are supported only when the totp authentication method is associated with a user authentication policy to reset or unlock all users in a disassociated totp authentication method, delete the totp authentication method itself creating user rules and user groups after your authentication policies and methods are established, you can set up any required user rules each user rule identifies one or more users, either from a local authentication service or from an external saml service you associate one or more user rules with an authentication policy to form a user group creating user rules nsa includes three default user rules alladminusers this matches all users, and is referenced by the default administrators user group, which associates it with the built in admin signin authentication policy allusers this matches all users, and is referenced by the default users user group, which associates it with the built in user signin authentication policy to read more about default user groups or built in authentication policies, see the tenant admin guide this preset configuration of rules, groups, and policies is suitable for typical use cases involving whole organization authorization needs in other words, where you require only a single user authorization path that matches all users for scenarios where you require more specific user authorization checks, you can create additional rules to match specific types of users when you create a rule, you select the user attribute with which you want this rule to test nsa provides the following rule attribute types username for local authentication methods, choose this attribute type to match against locally defined user names saml (azure ad) for saml authentication methods, choose this attribute type to match against user names or groups provided by the saml service custom for saml authentication methods, choose this attribute type to match against a custom saml attribute expression to create a user rule from the nzta menu, select the secure access icon, then select manage users > user rules the user rules page appears this page lists all user rules click create user rule the create user rule form appears at any point during this process, you can reset the form data by clicking reset fields enter a rule name click select attribute type and select one of the available options username matches user names in a local authentication method when you select this option, you must then select an expression type, either matching or not matching for the user value, enter a match expression for the selected expression type for the value a comma separated list of items is supported where required wildcard matches are supported special characters are supported single and double quotes are not supported ivanti recommends that a basic asterisk wildcard is not used when you intend to associate admin roles with user groups instead, a more specific wildcard that only includes admin users is required in this case to prevent all users having total access rights saml (azure ad) matches user names or groups in a saml authentication method when you select this option, you must then select a saml attribute type , either username or group for attribute value , enter a match expression for the selected saml attribute type as a saml expression custom matches against a custom saml attribute expression when you select this option, use the type or create an expression property to enter an attribute expression supported formats include for simple user attribute key value matching, use the syntax userattr \<attr key> \[=|!=] \<attr value> for example \ userattr memberof = "cn=sales,dc=example,dc=com" \ userattr mail = "user1\@example com" \ userattr realm = "users" \ userattr department != "example department" to match against attributes that can have multiple values associated with a single attribute key, use the syntax samlmultivalattr \<attr key> \[=|!=] (\<list>) for example \ samlmultivalattr memberof = ("cn=employee,cn=users,dc=example demo,dc=com") \ samlmultivalattr memberof = ("cn=users,dc=example demo,dc=com") use brackets and and/or operators to construct logical compound expressions \ userattr groups = ("group1" or "group2") \ userattr realm = ("ztaqa") and samlmultivalattr memberof = ("cn=sales,dc=uisdp,dc=com") \ userattr realm = ("ztaqa") or samlmultivalattr memberof = ("cn=sales,dc=uisdp,dc=com") \ userattr realm != ("ztaqa") and samlmultivalattr memberof = ("cn=sales,dc=uisdp,dc=com") click create user rule the new user rule is added to the list of user rules repeat steps 3 6 for each required user rule after you have created all required user rules, you can create user groups, see creating user groups creating user groups after you have created user rules (see creating user rules docid\ bfa9xpzcjyylrirzvpscs ), you associate one or more user rules with an authentication policy to form a user group nsa includes three default user groups administrators this user group associates the default alladminusers user rule with the built in admin signin authentication policy users this user group associates the default allusers user rule with the built in user signin authentication policy to read more about built in authentication policies, see the tenant admin guide this preset configuration of rules, groups, and policies is suitable for typical use cases involving whole organization authorization needs in other words, where you require only a single user authorization path that matches all users for scenarios where you require more specific user authorization checks, you can create additional user groups to make different associations of user rules and custom authentication policies to create a user group from the nzta menu, click the secure access icon, then select manage users > user groups the user groups page appears this page lists all user rule groups click create user group a form appears to enable you to create the user group enter a user group name and an optional description , then click next select each of the listed user rules that are required in the user group, then click next select required authentication policy from the list, then click next review the summary and click create the new user group appears in the user groups list repeat steps 2 7 to create all required user groups associating user groups with admin roles an admin role defines the elements of the user interface that an associated user group can access the current user can only access an individual user interface page/workflow if their user group is associated with an admin role that permits it the tasks they can perform within that displayed element depends on the permissions set within the admin role when you are using admin roles, ivanti recommends that any user rules for administrators does not use a basic asterisk wildcard, see creating user rules docid\ bfa9xpzcjyylrirzvpscs instead, a more specific wildcard that only includes admin users is required in this case to prevent all users having total access rights the default admin roles are not created by the tenant admin using the nzta user interface rather, they are set up by the ivanti devops team for example, the devops team might define the following admin roles the administrators admin role has access to all user interface elements (full read, create, update, delete rights) the read only administrators admin role has access to all user interface elements except workflows (read only) the network administrators admin role has access to zta gateway s and insights (read only) the cxos admin role has access to insights only (read only) for more information about your assigned admin roles, please contact ivanti devops the tenant admin can view admin roles in the administration > admin roles page, and associate each role with a single user group to associate a user group with an admin role log into the controller as a tenant admin from the nzta menu, select administration , then select admin roles a list of admin roles appears this includes default admin roles and custom admin roles (rbac) for example admin roles click the three dots adjacent to the role you want to update, then select edit role a dialog appears for example edit admin roles under choose group , select the user group that you want the admin group to be associated with select save changes (optional) repeat steps 3 to 5 for each admin role role based access control for admin users with role based access control (rbac), organizations can easily add admins and assign them specific roles, with differing levels of access to the nsa admin portal in addition to an existing set of default roles, administrators can now create custom granular roles for specific functions within the nsa admin portal the following examples illustrate how an organization can leverage role based administration for a variety of scenarios to create a custom admin role log into the controller as a tenant admin, see logging in as a tenant administrator docid\ bfa9xpzcjyylrirzvpscs from the nzta menu, select administration , then select admin roles in the admin roles page, click create role the create admin role page appears create admin role enter a unique name for the role from the drop down list, select the user group that you want to associate with this role for details, see associating user groups with admin roles docid\ bfa9xpzcjyylrirzvpscs optionally, enter a description from the drop down list, select an existing role that suits your requirements under permission settings, the controller permissions list shows the list of resources the resources specific to nzta are tagged with zta and resources specific to ics are tagged with ics controller permissions select the hide, view only, or modify permissions for each resource and its attributes this determines which pages to show and which actions to allow under permission settings, the ics gateway configuration list shows the list of ics gateway resources ics gateway permissions click select gateways in the select gateways dialog, select one or more gateways / clusters from the list and click apply select gateways/clusters select the hide, view only, or modify permissions for each resource and its attributes this determines which pages to show and which actions to allow click create the newly created custom admin role is displayed in the admin roles page (optional) edit an existing admin role by clicking the adjacent three dots, and then selecting edit make any required updates and save the changes (optional) delete an unused custom admin rule by clicking the adjacent three dots, and then selecting delete you must confirm the deletion next steps after you have configured your authentication methods and policies, and added them to your user groups, proceed to configure your nzta gateways, see configuring gateways