Symantec Access Management

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,

Gabriele

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?

Gabriele

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.

Regards,

Ujwol

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. _kerberos._udp.example.com SRV record, etc.).

You can find a recent Kerberos troubleshooting document here:

https://communities.ca.com/docs/DOC-231177811

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,

Gabriele.

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 https://en.wikipedia.org/wiki/.local for more information. Typically, for examples in explanations,  example.com is used for this purpose and explicitly reserved by RFC 6761 https://tools.ietf.org/html/rfc6761.