Configuring the Kerberos Domain

As an AAI administrator, you configure how users should authenticate to log in to AAI. To be able to use Single Sign On (SSO), you create a Kerberos domain. Domains control the user login, authentication method and access privileges to AAI's functions. Once the Kerberos domain is configured, if users are already authenticated to their networks, they will be able to log in to AAI without entering their credentials. They will be prompted to enter them only if, for any reason, the login fails.

Kerberos is a special type of AAI domain. It is not displayed on the AAI login page because it is not used to assign users a specific set of privileges, but to support single sign-on.

If you define Kerberos as the default domain, AAI will authenticate the user using the Kerberos ticket cache. If the user can be authenticated, the login page is bypassed entirely and the user is authenticated directly into AAI.

Users that log in this way are assigned the basic Admin/User role-based security model. By default, the first time any Kerberos user logs in to AAI, they will be granted access as a User and will have read-only access to all AAI data.

This page includes the following:

Configuring Kerberos

This section is intended for administrators with a deep knowledge of the Kerberos authentication protocol. The scope of this text does not cover information about Kerberos itself. For detailed information about Kerberos, please visit the official documentation at http://web.mit.edu/Kerberos.

To Configure Kerberos for Single Sign On in AAI

  1. Configure the Kerberos cached ticket.

    When a user logs on to their workstation, a Kerberos ticket is assigned to that identity. This ticket stores information about the person's identity, time of validity, and so on. For example, when you log on to a Windows domain, the ticket is stored in the cache. The ticket must have a session key enabled. By default, a Windows login does not have a session key enabled.

    If you are using Kerberos in the environment, the session key should be in the Kerberos ticket. AAI verifies the validity of this ticket. For information about how to enable a session key on Windows 2003 and Windows 2000 servers, please refer to the Microsoft official documentation.

    For Windows XP, the registry key is at a different location:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos

    Add the following under Kerberos:

    • Value Name: allowtgtsessionkey

    • Value Type: REG_SZ

      1. Value: 1

      2. Server authentication using the server principal and keytab

      3. Mutual authentication between server and client

  2. Create a server principal for AAI on the server on which it is running, export the keytab to a file and copy it to some location on the AAI server.

    The following steps are very generic. In your environment Kerberos might be configured differently. The following operating systems are for the Kerberos server and not the AAI server.

    On a Windows Kerberos Server

    1. Create a user called DEVAAI and give it some password. We will use password for this example. You can also use AAI server hostname instead of DEVAAI.

    2. Run the ktpass utility to map AAI to DEVAAI and extract the keytab.

      1. ktpass -princ AAI/DEVAAI -pass password -mapuser DEVAAI -out C:\temp\keytabDevaai.out

      2. The file keytabDevaai.out will be created for AAI/DEVAAI .

    3. Copy the file keytabDevaai.out to the AAI server into some folder C:\Automic_Automation_Intelligence\keytabJaws.out . This information will be used in the next section.

    Note:

    If you do not find the ktpass utility, download the Windows resource toolkit.

    On a Unix-Based Kerberos Server

    Example creating AAI/devaai:

    1. On your Kerberos server enter kadmin.local.

    2. At the kadmin.local prompt enter addprinc -pw password AAI/devaai

    3. Create a new keytab: ktadd -k /tmp/keytabJawsdev.out' AAI/devaai.

    4. Copy the keytab to the AAI server: /opt/Automic_Automation_Intelligence/keytabJawsdev.out.

  3. Add a Kerberos domain

    1. Go to the Admin - Users page.

    2. Open the Domains tab and select Add Domain.

    3. On the Add Domain dialog, enter the following:

      Name

      This is the name that the users will see in the login dialog when they log in to AAI. It must be unique. Once created, the name of the domain cannot be edited.

      Type

      Type of domain, in this case Kerberos.

  4. In Server Principal enter the following:

    Server Principal

    Kerberos user ID assigned to the AAI application.

    Keytab Location

    Full path to the Keytab file that is generated on the Kerberos KDC. This files is effectively the password for the Service Principal in a Kerberos environment.

  5. To use eEM for access control, in Options > Use eEM for access control select the appropriate eEM instance.

  6. Save your configuration.

  7. If you click the Test Configuration, AAI tries to connect to the Kerberos server with the information that you have provided.

    If there is any configuration error, AAI indicates it. Use this feature whenever you make changes, since for security reasons subsequent login errors contain little or no information.

    Depending on the setup one or more tests might fail.

    • Test 1 fails:

      1. The client machine you are adding this from does not have a valid Kerberos ticket. Please contact the Kerberos admin for more help.

      2. The realm name is not correct.

      3. The Kerberos server and port are not correct.

    • Test 2 fails:

      1. The keytab for the server principal in not in the proper place on the server machine.

      2. The server principal name is not correct. On UNIX this is case-sensitive.

    • Test 3 fails: Test 3 will fail if either of the Test1 or Test2 fails.

Once Kerberos is configured, AAI will try to authenticate users with this domain against Kerberos. If it fails, the login dialog is displayed and the user must enter their credentials.

Using Custom Kerberos Config Files

This is especially important for Windows-based AAI servers.

By default, AAI searches for the Kerberos configuration files at the default locations, for example:

  • Linux

    /etc/krb5.conf

  • Unix

    /etc/krb5/krb5.conf

  • Windows

    c:\winnt\krb5.ini

If the files are not available there, or if you want to use a different Kerberos configuration, then you must create and copy the Kerberos configuration file to the AAI server. For example:

  • Linux

    /opt/Automic_Automation_Intelligence/krb/krb5.conf

  • Unix

    /etc/krb5/ krb5.conf

  • Windows

    C:\Automic_Automation_Intelligence\krb\krb5.conf

You must then communicate the changes to the AAI server. To do this, modify the vmoptions file in the directory from where you are starting the AAI application. Add the following line to the vmoptions file:

  • Linux

    Djava.security.krb5.conf=/opt/Automic_Automation_Intelligence/krb/krb5.conf

  • For Windows

     -Djava.security.krb5.conf=C:\Automic_Automation_Intelligence\krb\krb5.conf

Restart Automic Automation Intelligence for this parameter to take effect.

Troubleshooting

If Mutual Authentication fails, the server login starts failing. If the client and server tests pass, and only the mutual authentication fails, then the server login keeps on failing. This happens when the Windows clients do not have the session key enabled. Please follow the directions given earlier to enable the session key. Then restart the client and try again.

Sometimes the login dialog comes up. If AAI is not able to do the single sign on with Kerberos, then it brings up the login dialog. The Kerberos authentication can fail sometimes if the login process takes too much time because of network delays. Please try to login again.

See also: