Kerberos application troubleshooting and best practices

Use the information here to configure and troubleshoot common Kerberos application issues and best practices.


Troubleshooting Kerberos timeout

Problem: Time outs occur while access the Kerberos KDC and return errors similar to:

Try the following solution(s):

  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 Ensure IWA_USERNAME header is set properly.

  3. The protected hostname is not 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 we execute setspn for every IWA app that we add in Access Gateway?

Problem: Should we execute setspn for every IWA app that we add in Access Gateway

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

Ensure Kerberos authentication is enabled on the IIS server

On the IIS server ensure that Kerberos authentication is enabled. 
For example:

Ensure IWA_USERNAME header is set properly

When configuring the IWA_USERNAME header attribute

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

For example:

Supporting Kerberos on sibling domains

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

of problem

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, howeverchange 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/ ELVIS\oagelvis
ktpass /princ host/ /mapuser /out c:\oagelvis.keytab /rndPass /pType KRB5_NT_PRINCIPAL /crypto All