Jason Wilcox

The Pros and Cons of Agent Identities vs DefaultAgentName

Blog Post created by Jason Wilcox Employee on Jan 4, 2018

CA Single Sign-On (CA SSO) has long had the capability to define an agent name in two ways: You can use an agent identity to map the agent name to an FQDN or IP address, or you can use DefaultAgentName. Many of our customers use both methods.

Agent identities have traditionally been used to provide a unique agent for each virtual server on a web server. This allows each virtual server to have policies that are unique to it; it also allows the application’s business requirements to reside on the server.

Alternatively, DefaultAgentName is configured when there are no virtual servers or they don’t need unique policies. DefaultAgentName is also often configured as a catch-all in addition to agent identities. The idea behind this tactic is that if CA SSO can’t determine which agent identity to map a request to, it will use DefaultAgentName. As a result, any request coming to the web server will be processed and the user will have a good experience, right?

Wrong!!

 

While on the surface this seems reasonable, when you dig under the covers a little, this is actually alarming. When a request comes to a web agent, the web agent attempts to map the incoming hostname or IP address to the configured agent identities. The result is an agent identity that may look like this:

If those agent identities were the only agents configured, only requests that came to that hostname and those two IP port combinations would be protected. Anything else on the server would be unprotected. That may be by design, but best practices state that we should deny by default, not, as we’re doing here, allow by default, which protects only listed virtual servers.

 

To solve this challenge, CA SSO has two agent parameters: DefaultAgentName and IgnoreHost. DefaultAgentName becomes that catch-all for requests to the server that the web agent can’t map directly to an agent object in the policy store. This is very useful from security and monitoring perspectives. IgnoreHost allows you to create a list of hostnames that you want the agent to ignore and not manage at all. When you use both parameters, DefaultAgentName allows you to deny by default any undefined host that somehow arrives at the server, and IgnoreHost allows you to ignore hostnames you know are mapped to the server but that you don’t want the CA SSO web agent to manage.

 

The final piece of the puzzle is creating a common set of policies and error redirection for anything that hits DefaultAgentName. Because we map all managed hostnames to an agent identity, and we use IgnoreHost for all known unmanaged hostnames, everything else should be considered an error and handled as such.

I like to define DefaultAgentName as an agent named “HostError” for each ACO. I then map “HostError” to a set of policies that redirect requests to a common error page and ensure that I capture the incoming hostname that caused the redirection. This allows for quick analysis of misconfiguration of DNS or the web server or identification of malicious attempts to bypass the web server’s security.

 

Inquiring minds want to know: Do you have standards in place that define when to use an agent identity vs DefaultAgentName? Do your standards take into account security best practices such as deny by default? Why or why not? Let us know!

 

I am a Sr. Services Architect with CA Services. Interested in learning more about CA Services expertise in the security space? Click here or comment below.

Outcomes