About Basic, NTLM and Kerberos Resources

Use the SSO > General tab to set up the basic, NTLM and Kerberos credentials. The credentials you define here are used when defining Web resource profiles with SSO autopolicies and Web resource policies.

The following outlines the basic ideas behind the handling of SSO:

•The system will do Kerberos if challenged with Negotiate header, NTLM if challenged with NTLM header and Basic Auth if challenged with Basic.

•If the system receives multiple challenges, the order of preference is:

•Kerberos

•NTLM

•Basic

•The system will first try constrained delegation if the service is configured in a service list.

•Policy configurations override any settings in the SSO > General tab.

•Disabling SSO or disabling all sections in the General tab prevents single sign-on. However, the system will continue to intermediate and display an intermediation page to the end user.

•Basic authentication intermediation can be explicitly turned off in a policy. For kerberos and NTLM, the system will always intermediate.

•Depending on the SSO used, the intermediation page will show different fields for the end user to complete:

•Basic authentication intermediation page displays username and password fields

•NTLM intermediation page displays username, password and domain fields

•Kerberos intermediation page displays username, password and realm fields

•For constrained delegation, you must define a policy and specify roles. Entering data in the General tab only is not sufficient.

•If no policies are configured for single sign-on, the system uses the default system credentials.

•If credentials are defined, the order of preference is:

•System credentials

•Variable credentials

•Fixed or static credentials

•For fixed or static credentials, you must define a policy and specify roles. Entering data in the General tab only is not sufficient.

•If there is a policy match, the credential and protocol of the policy is used. If the policy fails to authenticate, the fallback mechanism defined in the policy is used. If the policy protocol does not match the protocol of the challenge, the logic defined in the General tab is used.

•When upgrading a device or performing a new install, the default SSO policy of BasicAuthNoSSO is preserved. Even if all sections of the General tab are enabled, SSO will not be enabled until the BasicAuthNoSSO policy is deleted.

Writing the Basic, NTLM and Kerberos Resources

To set up the basic, NTLM and Kerberos resources:

1.In the admin console, select Users > Resource Policies > Web.

2.If your administrator view is not already configured to show SSO policies, make the following modifications:

1. Click the Customize button in the upper right corner of the page.
2. Select the SSO check box.
3. Select the General check box below the SSO check box.
4. Click OK.

3.Select the SSO > General tab.

4.Select Enable kerberos to enable Kerberos SSO. You can then define the type of intermediation: constrained delegation or Ivanti Connect Secure. If you do not define any intermediation types, the system attempts to figure out the realm from the hostname and performs SSO using the system credentials.

For realm intermediation, enter the following and click Add:

•Realm - Enter the Kerberos realm name. For example, KERBER.NET. The system uses KERBER.NET to obtain the list of Key Distribution Centers (KDCs).

•Site Name - (optional) Enter the Active Directory site names. Use this field to have the system contact the KDC at a specific site. For example, if site name is Sunnyvale and realm is KERBER.NET, then the system uses SunnyvaleoKERBER.NET to get a list of KDCs. Note that the Active Directory must have the sites defined and DNS should be configured to return the KDCs in the site.

•Pattern List - Enter the hostnames mapped to the Kerberos realm. You can enter wildcard characters, such as *.y.com, *.kerber.net, or *.*. Note the following:

•Make sure that realms to not have hostnames matching a subset of the patterns defined for another realm.

•You do not need to define a pattern if all servers follow the mirrored DNS namespace convention. The system determines the realm from the hostname.

•All disjoined hostname patterns must be defined.

•You can use * as the default realm. Do not list more than one * when defining multiple realms.

•KDC - Enter the hostname or IP address of the Key Distribution Centers if DNS is unavailable or if you want the system to contact a specific KDC for tickets. If you enter a KDC, the system does not use DNS to obtain the list of KDCs based on the values entered in the Site Name and Realm fields.

For constrained delegation intermediation, enter the following and click Add:

•Label - Enter a name to uniquely identify this row. No external mapping is made to the label value.

•Realm - Select the realm to use. The drop-down list is populated by values in the Realm Definition table.

•Principal Account - Enter the constrained delegation account to use to get constrained delegation tickets on behalf of the user.

•Password - Enter the constrained delegation account password.

•Service List - Select the service list to use. Click Edit to define and upload service lists. The list should be an exact match with the service list in Active Directory if you want to perform constrained delegation for all the services. Hostnames must be an exact match.

For more information about constrained delegation, see http://msdn.microsoft.com/en-us/library/aa480585.aspx.

For system intermediation, enter the following and click Add:

•Label - Enter a name to uniquely identify this row. No external mapping is made to the label value.

•Realm - Select the realm to use. The drop-down list is populated by values in the Realm Definition table.

•Credential Type - Select one of the following credential types:

•System credentials - Use the set of user credentials, such as primary and secondary authorization credentials, stored on the device. If you select this option, you do not need to enter values in the Username and Password fields.

•Variable - Allow tokens such as <username> and <password> to be used in the username and Variable Password fields.

•Static - Use the username and password exactly as they are entered in the username and password fields.

•Username and Password - Enter the account username and password. If you select Variable as the credential type, you can enter the username token here. For example, <username>.

•Variable Password - If you select Variable as the credential type, enter the password token here. For example, <password>.

•Fallback to NTLM V2 - Select this option to fallback to NTLM V2 if Kerberos fails. If you do not select this option and Kerberos SSO fails, an intermediation page appears.

5.Select Enable NTLM to enable NTLM SSO. If you do not enter any configuration information, the system attempts to figure out the domain from the hostname and performs SSO using the system credentials.

Do not edit or delete the default system credential.

•Label - Enter a name to uniquely identify this row. No external mapping is made to the label value.

•Domain - Enter the Active Directory domain name here.

•Credential Type - Select one of the following credential types:

•System credentials - Use the set of user credentials, such as primary and secondary authorization credentials, stored on the device. If you select this option, you do not need to enter values in the Username and Password fields.

•Variable - Allow tokens such as <username> and <password> to be used in the Username and Variable Password fields.

•Static - Use the username and password exactly as they are entered in the username and password fields.

•Username and Password - Enter the account username and password. If you select Variable as the credential type, you can enter the username token here. For example, <username>.

•Variable Password - If you select Variable as the credential type, enter the password token here. For example, <password>.

•Fallback to NTLM V1 - Select this option to fallback to NTLM V1 if SSO fails. If you do not select this option and SSO fails, only NTLM V2 is attempted. An intermediation page appears if NTLM V2 fails.

6.Select Enable Basic Authentication to enable basic authentication SSO. If you select this option but do not set up any configuration data, the system will attempt SSO using system credentials.

Do not edit or delete the default system credential.

•Label - Enter a name to uniquely identify this row. No external mapping is made to the label value.

•Credential Type - Select one of the following credential types:

•System credentials - Use the set of user credentials, such as primary and secondary authorization credentials, stored on the device. If you select this option, you do not need to enter values in the Username and Password fields.

•Variable - Allow tokens such as <username> and <password> to be used in the Username and Variable Password fields.

•Static - Use the username and password exactly as they are entered in the username and password fields.

•Username and Password - Enter the account username and password. If you select Variable as the credential type, you can enter the username token here. For example, <username>.

•Variable Password - If you select Variable as the credential type, enter the password token here. For example, <password>.

•Pattern List - Enter the hostnames mapped to the Kerberos realm. You can enter wildcard characters, such as *.y.com, *.kerber.net, or *.*. Note the following:

•Make sure that realms to not have hostnames matching a subset of the patterns defined for another realm.

•You do not need to define a patter if all servers follow the mirrored DNS namespace convention. The system determines the realm from the hostname.

•All disjoined hostname patterns must be defined.

•You can use * as the default realm. Do not list more than one * when defining multiple realms.

•You can use * as the default domain. Do not list more than one * when defining multiple domains.

Writing a Basic Authentication, NTLM or Kerberos Intermediation Resource Policy

Basic Authentication, NTLM or Kerberos Intermediation resource policies enable you to control NTLM and Kerberos intermediation on the system. If a user accesses a Web resource that sends a basic authentication challenge, the system can intercept the challenge, display an intermediate sign-in page to collect credentials for the Web resource, and then rewrite the credentials along with the entire challenge/response sequence.

The initial HTTP request generated for an NTLM protected server should be for a request that results in HTML content. If SSO is not enabled or if the SSO credentials fail, the system responds with an HTML page to gather user credentials. If the browser is expecting non-HTML content, the browser rejects the response and the navigation to the resource fails.

With the Kerberos Intermediation resource policy, backend web applications protected by Kerberos are accessible to end users. For example, a user logs in to a device using Active Directory as the authentication server and the authentication protocol is Kerberos. When the user browses to a Kerberos-protected server, the user is single-signed on to the backend server and is not prompted for credentials. Or, if a user logs in to a device using an authentication protocol other than Kerberos and then browses to a Kerberos-protected server. Depending on the settings in Kerberos Intermediation resource policy and the configured Kerberos authentication server, the user will either be authenticated by the rewriter or the user will be prompted to enter a username and password.

To write a Basic Authentication, NTLM or Kerberos Intermediation resource policy:

1.In the admin console, select Users > Resource Policies > Web.

2.If your administrator view is not already configured to show SSO policies, make the following modifications:

1. Click the Customize button in the upper right corner of the page.
2. Select the SSO check box.
3. Select the Kerberos/Basic Auth/NTLM check box below the SSO check box.
4. Click OK.

3.Select the SSO > Kerberos/NTLM/BasicAuth tab.

4.Click New Policy.

5.Enter a name to label this policy (required) and a description of the policy (optional).

6.In the Resources section, specify the resources to which this policy applies.

If you want to automatically post values to a specific URL when an end user clicks on a bookmark, the resource that you enter here must exactly match the URL that you specify in the Users > User Roles > Role > Web > Bookmarks page of the admin console.

7.In the Roles section, specify:

•Policy applies to ALL roles - To apply this policy to all users.

•Policy applies to SELECTED roles - To apply this policy only to users who are mapped to roles in the Selected roles list. Make sure to add roles to this list from the Available roles list.

•Policy applies to all roles OTHER THAN those selected below - To apply this policy to all users except for those who map to the roles in the Selected roles list. Make sure to add roles to this list from the Available roles list.

8.In the Action section, specify:

•Disable SSO - Disables automatic SSO authentication for this user role and, instead, prompts the user for sign-in credentials.

•Basic - This option uses the Basic Authentication Intermediation method to control SSO behavior.

•Enable Intermediation - Select the credentials to use. If this pull-down menu is blank, no basic authentication SSO settings are defined in the SSO General tab.

•Disable Intermediation - When you select this option, the system does not intermediate the challenge/response sequence.

The system always intermediates requests to Web proxies that require basic authentication, even if you select Disable Intermediation.

Although you are given an option to disable basic authentication intermediation, we do not recommend this option, as it is a very insecure authentication method and, in some cases, can transmit user credentials over the network in clear (unencrypted) text.

•NTLM - This option specifies that the system use the Microsoft NTLM Intermediation method to control SSO behavior.

•Select the credentials to use. If this pull-down menu is blank, no NTLM SSO settings are defined in the SSO General tab.

•Select the Fallback to NTLM V1 option to try both NTLM V1 and NTLM V2. If you do not select this option, the system falls back only to NTLM V2. An intermediation page appears if SSO fails.

•Kerberos - This option specifies that the system use the Kerberos Intermediation method to control SSO behavior.

•Select the credentials to use. If this pull-down menu is blank, no kerberos SSO settings are defined in the SSO General tab

•Select the Fallback to NTLM V2 option to fallback only to NTLM V2 if kerberos fails. If you do not select this option, a Kerberos intermediation page appears if Kerberos SSO fails.

•Constrained Delegation -This option specifies that the system use the constrained delegation intermediation method to control SSO behavior.

•Select the credentials to use. If this pull-down menu is blank, no constrained delegation SSO settings are defined in the SSO General tab.

•Select the Fallback to Kerberos option to fallback to Kerberos if constrained delegation fails. If you select this option, an intermediation page appears if constrained delegation fails. If you do not select this option and constrained delegation fails, an error page appears.

•Use Detailed Rules - To specify one or more detailed rules for this policy.

9.Click Save Changes.

10.On the Basic Auth, NTLM and Kerberos policies page, order the policies according to how you want to evaluate them. Keep in mind that once the system matches the resource requested by the user to a resource in a policy's (or a detailed rule's) Resource list, it performs the specified action and stops processing policies.

Check the activity events listed in the user log if you encounter any problems.