Layer7 Access Management

Expand all | Collapse all

Kerberos authentication on multiple AD domains

Jump to Best Answer
  • 1.  Kerberos authentication on multiple AD domains

    Posted 11-23-2017 08:35 AM

    To implement the Kerberos authentication against 4 AD domains, only one Web Agent is required or at least 4 Web Agents, one for each domain?

    In case, the Web Agent machine has to be registered into related AD domain?

    Finally, is there a way to have a fallback to Form Authentication in case Kerberos authentication fails?


    Thanks and regard,


  • 2.  Re: Kerberos authentication on multiple AD domains

    Posted 11-24-2017 05:42 AM
    ...following some more detail about my initial question:
    • in case of an AD forest of 4 domains

    is it possible to use only one WebAgent configured for Kerberos Authentication for all the 4 domains? In other words, the Kerberos configuration, for both WebAgent and PolicyServer, can be multi-domain?

      • if so, the server on which the WebAgent is installed lon which domain must be attested?
      • otherwise,  I should have 4 WebAgents, one per domain, but is it possible to create a sort od authentication chain to first try Kerberos authentication on all 4 domains and, if none goes well, fallback to Form Authentication?


    Thanks and regards,


  • 3.  Re: Kerberos authentication on multiple AD domains

    Posted 11-28-2017 08:40 AM

    Also, I have found the following into CA SSO documentation

    Policy Server Configuration for Kerberos Authentication - CA Single Sign-On - 12.7 - CA Technologies Documentation

    11. (Optional) If you have more than one Windows domain, specify mappings between the Kerberos realm and Windows domains. You can map one Kerberos realm to many Windows domains. When you specify the DOMAIN variable in the User DN Lookup field, this mapping is required, even when the realm and domain names are the same.

    but it is not explained in detail what it is and how it suits the operation.


    No one can help?



  • 4.  Re: Kerberos authentication on multiple AD domains

    Posted 11-30-2017 06:19 PM

    Hi Gabriele,


    Sorry for the delay in the response.

    I cannot answer your question with a certainty so I am trying to find someone who can.




  • 5.  Re: Kerberos authentication on multiple AD domains
    Best Answer

    Posted 11-30-2017 09:42 PM

    From your diagram, it appears that though there are several Active Directory domains, they are all part of the same forest. They should be able to authenticate among themselves without a problem (as far as I know).


    My past experience is with cross-forest domains and these need a cross-forest trust to work properly with Kerberos. In the case of a common single forest, there should not be a problem and no additional configuration necessary.


    You then only need a single web agent account in one of the domains - probably the top-most domain. The account will have a service principal name (SPN) associated to it reflecting the public name of the web server use for authentication.


    Finally, there is currently no fallback to forms-based authentication if Kerberos authentication fails. This product feature has been suggested and CA is looking at possibly implementing it in a future version. In the meantime, you might consider using nginx as a front-end to the web agent and configuring it to handle errors (from failed Kerberos authentication) by redirecting to a forms-based authentication mechanism.


    The policy server may need to be configured for the other KDC's (or at least have a functional DNS infrastructure with proper SRV records for Kerberos, e.g. SRV record, etc.).


    You can find a recent Kerberos troubleshooting document here:

  • 6.  Re: Kerberos authentication on multiple AD domains

    Posted 12-01-2017 11:04 AM

    Hi Brian,

    thanks for your response but on DocOps there are detailed instruction on how to configure for a single AD Domain / Kerberos Realm, in particular:

    • Policy Server service principal
    • Web Agent service principal
    • keytab file for the Policy Server
    • keytab file for the Web Agent
    • Kerberos Configuration File (krb5.ini)

    May you help to write differences in my scenario with 4 child domains (a, b, c, d.dummy.local) and with a Web Agent mapped to the root/parent domain (dummy.local) as you suggested?

    Also the Policy Server service principal and Web Agent service principal must be created only on the root / parent domain (dummy.local) or into all the domains, children included? And it/they must has/have the same credentials (uid and password)?


    Thanks and regards,


  • 7.  Re: Kerberos authentication on multiple AD domains

    Posted 12-01-2017 01:57 PM

    It's probably most helpful to think in terms of the Kerberos protocol...


    When the browser requests the Kerberos-protected resource, it will be redirected to the Kerberos Credential Collector URL, creds.kcc. The first request for this resource will receive a response of HTTP 401 and the header "WWW-Authenticate: Negotiate". At this point, if the browser is configured to perform integrated authentication for the remote domain, it will try and obtain a Kerberos ticket.


    Now, the browser will request a ticket for that remote resource from a KDC. As long as it can acquire a Kerberos service ticket, then it will make another request with the ticket in an HTTP Authorization header. This should all work without a problem in a multi-domain/multi-realm environment like you have proposed.


    Now, when the web agent or the policy server needs to decrypt a Kerberos request, they must use the same key as used to encrypt the request. Therefore, you only need one account for the web agent and one for the policy server - each configured with the correct service principal name (SPN). You definitely to not want multiple accounts across the domains with the same SPN or else a key from one KDC for the SPN may be used in a request, but a different account and key are used by the service receiving the request.


    My point is that as long as Kerberos clients (the browser, the web agent, and the policy server) can authenticate (obtain their initial Kerberos ticket-granting-ticket, krbtgt) and obtain service tickets, everything should work just fine.


    Finally, just a reminder that the .local top level domain is reserved by IETF (for multicast DNS) and is not suitable for use as a private top-level domain. I was not sure if it is just an example or if you were planning on using that on internal systems. See for more information. Typically, for examples in explanations, is used for this purpose and explicitly reserved by RFC 6761