How to use Kerberos with NAM with multiple, non-trusted AD Domains



If you are not familiar with configuring Kerberos for NAM, please check the documentation first:

One of the issues with NAM’s underlying Java implementation of Kerberos is that it only supports one configuration. While this works fine in a single Domain/Forest or a multi-domain Environment with the appropriate trusts, this makes a configuration for multiple Domains that have no trust relationship a bit more difficult.

The configuration only supports one keytab file, which is the keystone to successful authentication. While it is possible to merge multiple keytab files with ktutil, this doesn’t help either, because the Java environment only seems to read the entry that is configured in bcsLogin.conf.

There is however a way to make this work, and it uses the fact that Kerberos uses a predictable shared secret between the KDC and the service that the user is authenticating to.


AD Configuration

Let’s assume we have two domains, and, that are not trusting each other. We want to use Kerberos for both domains.

We start with To configure NAM for this domain, you follow the instruction in the documentation for setting up Kerberos on the IDP:

The one thing you need to do here is to keep the password for the user account you’ve created in ad1 for this.

Once you’ve done that and tested it successfully, you can now configure Follow the instruction in the documentation to configure AD for Kerberos found here:

from step 1 to 6. There are two important things to note. The password you are using for this account must be the same one you were using for the account in ad1. And when using setspn you must make sure that you use AD2.NETIQ.COM in the service principle name, so the command in step 6 would look like this:

setspn –A http/<IDP DNS Name>@AD2.NETIQ.COM <user>

Alternatively, because of the way Active Directory handles the Service Principal Name, you could leave out the realm and simply use:

setspn –A http/<IDP DNS Name> <user>

Once you’ve set up the user account, you’re done. You can now use Kerberos from both and

If you have more than two domains, you can configure the other domains in the same way as ad2.

IDP Configuration

On the IDP side there is not much to do. You need to configure the additional AD domains as user stores and add them to the Kerberos method you want to use. Since NAM searches the user stores sequentially, you should limit this to about 10 user store. There is no technical limit, but due to the sequential search users in the domains at the bottom of the search may experience delays during login.

Alternatively, if you use one central store to authenticate against, you need to do one of the following:

  • Make sure that the Universal Principal Names of the users are synchronised to the central store and that you enter the correct attribute in the Kerberos class configuration to search against

  • Add a UPN suffix for your central store to the Kerberos class configuration. Be careful however, that the actual username remains the same one that the user has in his original domain. So for example I authenticate to NAM with a ticket that has been issued for In the Kerberos class configuration we added a UPN suffix for Then the IDP will look for the Principal Names and in the central user store.

Why is this working?

As already mentioned Kerberos uses a predictable shared secret. Basically that is an encryption key, which is used to encrypt the ticket. So if a client requests a ticket for the IDP, AD will generate the ticket and encrypt it with the key from the service account user. When receiving the ticket, the IDP will decrypt the ticket and do some validation checks. If the IDP can decrypt the ticket and the validation checks are successful, the user is authenticated from the Kerberos point of view.

The encryption key will be generated by using the password as a seed for the generating algorithm. This is predictable in the sense that the same password will always result in the same encryption keys. By using the same password in both domains, the ticket encryption will be the same, and therefore the IDP can decrypt the tickets from both domains.

In the tickets, there is no reference to the domain where the tickets have been generated, so the IDP will accept tickets from both domains.

In general, what we are doing here is nothing special, but using the basic Kerberos design.

Known issues

Password Handling/Management

Usually, when you configure a service account for Kerberos, you will need the password twice: once for the user creation and once for exporting the keytab. Afterwards you can throw away the password, as you will never need it again. With this configuration you will need to keep it in case another domain comes along and you need to configure a service account there.

In addition, you may need to pass the password to other domain admins as well, so they can configure the service accounts in their domains. Sharing passwords is never a secure thing.

Finally, if you need to change the password on those service accounts for whatever reason, you must synchronize this across multiple domains and possible multiple admins. This usually gets exponentially more difficult the more domains you have.

Key Version Number

One issue that may arise by using this across multiple domains is a mismatch in the key version numbers. The key version number is increased each time you change your password, and your IDP will not accept tickets that have a higher key version number than what is in the keytab. So if the password for the service account is touched in one of the domains, it is perfectly possible that Kerberos will stop working for that domain and that domain only.

Troubleshooting this is not easy, though the IDP logs will show a key version mismatch if set to debug. The easiest way to avoid this is to use the kvno switch when exporting the keytab file with the syntax

/kvno 0

If you set the key version number of the keytab file to zero, the IDP will accept any key version number.



How To-Best Practice
Comment List