Show TOC

Changing User Mapping for KerberosLocate this document in the navigation structure

Prerequisites

You have configured the KDC and UME as required.

For more information, see Configuring Kerberos Authentication .

Context

AS Java needs to map the Kerberos Principal Name (KPN) to a UME user. When you configure Kerberos authentication, you can configure this mapping by choosing from the following mapping modes:

  • Principal only

    User is resolved using only the principal part of the Kerberos Principal Name (KPN). The principal token is mapped to the logon ID, the logon alias, or another UME attribute of the user.

  • Principal@REALM

    User is resolved using the full KPN as a single token. The KPN is mapped to the logon ID, the logon alias, or another UME attribute of the user, or to a virtual user. A virtual user does not exist permanently in the UME database. It is temporarily created, on request, for a single session. Its access rights are determined by the default roles and groups you specify.

  • Principal and REALM

    User is resolved by the KPN, split into principal and realm tokens. For the ADS data source, the user mapping is automatic. Otherwise, both tokens are mapped to UME attributes.

Procedure

  1. Start the SPNego configuration application.

    For more information, see Starting the SPNego Configuration Application .

  2. Select a Kerberos realm.
  3. Choose the Edit pushbutton.
  4. On the User Mapping tab, enter data as required.
    Example

    Scenario 1 : The AS Java system contains the logon IDs for the users in the same format used in the Microsoft Windows domain. For example, John Doe has a Microsoft Windows domain account john.doe@IT.CUSTOMER.DE (which corresponds to his KPN). For AS Java, the logon ID is john.doe . In this scenario, the appropriate mapping mode is Principal only , since we will use only the principal part of the KPN. The source will be logon id , since we will map the principal to the logon ID of the user.

    Scenario 2 : The AS Java system contains specific logon IDs for the users in a format not related to the Microsoft Windows domain accounts. For example, John Doe has a logon ID HADES187345, which is not similar to his KPN ( john.doe@IT.CUSTOMER.DE ). However, the email attribute is equal to the Microsoft Windows domain account name, and the AS Java attribute for John Doe is john.doe@IT.CUSTOMER.DE . In this scenario, the appropriate mapping mode is Principal@REALM , since we will use the whole KPN. The source will be the UME attribute email , since we will map the full KPN to the user's email address.

    Scenario 3 : In a multi-domain case, we probably cannot distinguish the users using only the principal part of the KPN. In most cases, it is most appropriate to use the mapping mode principal and REALM and the source ADS Data Source . With this mapping source, the users are resolved using the UME account attributes principal and realm, which are automatically assigned to the users.

    Scenario 4 : We have a corporate system with its own user database. However, these users do not exist in the AS Java UME database, and we do not want to add them permanently. Therefore, we use Principal@REALM mapping mode with the source virtual user . In this way, AS Java will create a virtual user for every user authenticated by the Kerberos login module. These virtual users exist only for the current session. They will have access rights defined by the default roles and groups assigned to them.

  5. Save your entries.