Kerberos application troubleshooting and best practices

Learn about the best practices to follow and how to configure and troubleshoot common Kerberos application issues.

Troubleshooting Kerberos timeout

Problem: Timeouts occur while accessing the Kerberos KDC. These return errors similar to:

Try the following solution:

  1. Ensure that the firewall ports TCP/88 and UDP/88 are open between Access Gateway and the Kerberos server (Active Directory running as an Access Gateway Kerberos service).

  2. Ensure that the use kdc host option is enabled and the associated Active Directory server is entered as IP address.

Troubleshoot Parent-Child/Sibling AD Domain

Problem: Organization has an AD Forest with Parent and multiple children domain. The IIS/SharePoint server instance is part of a child domain.

How to configure so that Kerberos authentication works with OAG

Try the following solution:

  • Create the Access Gateway SPN account in the child domain of the IIS server. This solutions works because by default all domains in a Active Directory forest trust each other.

    Otherwise, follow the single AD domain instructions.

    If you create the SPN account in the parent domain, the SPN cannot see the services in the children domain.

Troubleshooting 401 Authorization Error

Problem: 401 authorization error in Access Gateway protected application.

Typically one of three things is wrong:

  1. IIS does not have Kerberos provider enabled. Verify in IIS that the Kerberos provider is enabled for authentication.

  2. Not sending a valid username in IWA_USERNAME header. See Verify the IWA_USERNAME header is valid.

  3. The protected hostname isn't the same value as the IIS windows hostname.Validate that the application Protected Web Resource field matches the IIS windows hostname.

Always validate user and server using the Kerberos Simulator

Best practice: When configuring the Kerberos service in Access Gateway validate first.

For example:

Ensure that the Kerberos app Protected Web Resource matches the value tested in the Kerberos simulator.

Should you run setspn for each IWA app that you add in Access Gateway?

Problem: Should you run setspn for every IWA app that you add in Access Gateway?

  • No. However, you should add each IIS server to the service account for each domain.

Enable Kerberos authentication on the IIS server

Enable Kerberos authentication on the IIS server. For example:

Verify the IWA_USERNAME header is valid

When configuring the IWA_USERNAME header attribute:

  • Initially test with a static value.
  • Ensure that the domain name is in all UPPERCASE.

For example:

Support Kerberos on sibling domains

Problem: There is a parent domain and multiple children domains where each child domain has attached IIS or SharePoint servers. There must be SSO between AD domains. A best practice is to have all of the IIS and SharePoint servers attached to the parent domain. If this isn't possible, then we need to create multiple realms in Access Gateway with unique Service Principle Names (SPNs).

For example:

  1. Domain 1 - Service Principle Name - Follow the instructions from the Access Gateway console wizard.
    Domain 1 - Keytab
    Follow the instructions from Access Gateway console wizard.
  2. Domain 2- Service Principle Name - Follow the instructions from OAG console wizard, changing the “host/” value to something unique.
    Domain 2 - Keytab
    Follow the instructions from Access Gateway console wizard except change the “host/” value to something unique.

For example:

setspn -s host/gwelvis.adlab.com ELVIS\oagelvis ktpass /princ host/gwelvis.adlab.com@ELVIS.ADLAB.COM /mapuser oagelvis@elvis.adlab.com /out c:\oagelvis.keytab /rndPass /pType KRB5_NT_PRINCIPAL /crypto All