4.8 Configuring an Inject Kerberos Ticket Policy

This policy allows the authentication information in the Kerberos tickets to be passed to the Access Gateway.

To create and configure an Inject Kerberos Ticket policy, perform the following steps:

  1. In the Administration Console, click Policies > Policies.

  2. Select the policy container, then click New.

  3. Specify a name for the policy, select Access Gateway: Identity Injection for the type, then click OK.

  4. (Optional) Specify a description for the injection policy. This is useful if you plan to create multiple policies to be used by multiple resources.

  5. In the Actions section, click New, then select Inject Kerberos Ticket.

  6. Select an appropriate option in User Name.

    Select Credential Profile to insert the name a user enters during the authentication process.

    This is the most common value. The default contracts assign the cn attribute to the Credential Profile.

    If your user store is an Active Directory server, the SAMAccountName attribute is used for the username and stored in the cn field of the LDAP Credential Profile.

    Depending upon what a user must supply for authentication, select one of the following:

    • LDAP Credentials: If you prompt the user for a username, select this option. Then select either LDAP User Name (the cn attribute of the user) or LDAP User DN (the fully distinguished name of the user). Your Web server requirements determine which one you use.

    • X509 Credentials: If you prompt the user for a certificate, select this option. Then select one of the following options depending upon your Web server requirements:

      • X509 Public Certificate Subject: Injects the subject field from the certificate, which can match the DN of the user, depending upon who issued the certificate.

      • X509 Public Certificate Issuer: Injects the issuer field from the certificate, which is the name of the certificate authority (CA) that issued the certificate.

      • X509 Public Certificate: Injects the entire certificate.

      • X509 Serial Number: Injects the certificate serial number.

    • SAML Credential: Although this option is available for the username, most applications that use SAML assertions, use them for the user’s password. For the username, select an option that allows you to supply the user’s name, such as LDAP Credentials or LDAP Attribute.

    Your Web server requirements determine the data type you select for the username. LDAP, X509, and SAML credentials are available from the Credential Profile. If you have created a custom contract that uses a credential other than the ones listed in the Credential Profile, you can select one of the following values to insert into the Kerberos ticket as the username:

    • Authentication Contract: Injects the URI of the authentication contract the user specified for authentication.

    • Client IP: Injects the IP address associated with the user.

    • LDAP Attribute: Injects the value of the selected attribute. For Active Directory servers, specify the SAMAccountName attribute for the username. If the attribute you require does not appear in the list, click New LDAP Attribute to add the attribute.

      The Refresh Data Every option allows you to determine when to send a query to the LDAP server to verify the current value of the attribute. Because querying the LDAP server slows down the processing of a policy, LDAP attribute values are cached for a user session.

      Change the value of this option from session to a more frequent interval only on those attributes that are critical to the security of your system or to the design of your work flow. You can select to cache the value for the session, for the request, or for a time interval varying from 5 seconds to 60 minutes.

      For more information, see Section 4.1.1, Using the Refresh Data Option.

    • Liberty User Profile: Injects the value of the selected attribute. If no profile attributes are available, you have not enabled their use in the Identity Server configuration. See Managing Web Services and Profiles in the NetIQ Access Manager 3.2 SP3 Identity Server Guide.

    • Proxy Session Cookie: Injects the session cookie associated with the user.

    • Roles: Injects the roles that have been assigned to the user.

    • Shared Secret: Injects the username that has been stored in the selected shared secret store.

      You can create your own username attribute.

      1. Click New Shared Secret, specify a display name for the store, and Access Manager creates a store.

      2. Select the store, click New Shared Secret Entry, specify a name for the attribute, then click OK.

        The store can contain one name/value pair or a collection of name/value pairs. For more information, see Section 5.4, Creating and Managing Shared Secrets.

      The Refresh Data Every option allows you to determine when to send a query to verify the current value of the secret. Because querying slows down the processing of a policy, secret values are cached for a user session.

      Change the value of this option from session to a more frequent interval only on those secrets that are critical to the security of your system or to the design of your work flow. You can select to cache the value for the session, for the request, or for a time interval varying from 5 seconds to 60 minutes. For more information, see Section 4.1.1, Using the Refresh Data Option.

    • String Constant: Injects a static value that you specify in the text box. This value is used by all users who access the resources assigned to this policy.

    • Data Extension: (Conditional) If you have installed a data extension for Identity Injection policies, this option injects the value that the extension retrieves. For more information about creating a data extension, see NetIQ Access Manager Developer Tools and Examples.

    The value type you use depends upon your application setup.

  7. Specify values in the following fields:

    Domain: Select one of the following:

    • LDAP Attribute: When the user is authenticated at the Identity Serer by using a Kerberos authentication. This attribute uses userPrincipalName of the user from Active directory.

    • String Constant: When the user is authenticated at the Identity Server by using a non-Kerberos authentication. If the required domain is not available in any LDAP attribute, the administrator can specify the domain name manually.

    Target Host: Select from request: Selects the Web server FQDN that user has configured while configuring Web servers of the proxy service.

    Multi-Value Separator: Select a value separator, if the value type you have select is multi-valued. For example, Roles can contain multiple values.

    DN Format: If the value is a DN, select the format for the DN:

    • LDAP: Specifies LDAP typed comma notation:

      cn=jsmith,ou=Sales,o=novell

    • NDAP Partial Dot Notation: Specifies eDirectory™ typeless dot notation.

      jsmith.sales.novell

    • NDAP Leading Partial Dot Notation: Specifies eDirectory typeless leading dot notation.

      .jsmith.sales.novell

    • NDAP Fully Qualified Partial Dot Notation: Indicates eDirectory typed dot notation.

      cn=jsmith.ou=Sales.o=novell

    • NDAP Fully Qualified Leading Dot Notation: Indicates eDirectory typed leading dot notation.

      .cn=jsmith.ou=Sales.o=novell

  8. Click OK.

  9. (Optional) To add a second rule, click New in the Rule List.

    You can inject only one Kerberos ticket into an Identity Injection rule. However, your policy can have multiple rules. If you inject two Kerberos tickets, each in a separate rule, the Kerberos ticket in the rule with the highest priority is applied. The Kerberos ticket action in the second rule is ignored.

  10. Click OK > Apply Changes.