UAG detailed audit logging

[BenFB]

We have been requested to provide detailed audit logging for our UAG. We have the UAG pointed to a syslog server but we are finding that the logging is minimal. Can the logging be increased or is there a different way to gather this information? Maybe OPSWAT?

We are hoping to capture the following:

Username of the connecting user

IP of the connecting user

What type of authentication the user is using

Is the authentication successful (We only use RADIUS but are looking at adding X.509 Certificate and would need a way to differentiate)

Time the session is ended/timed out with the username

When a user connects this is all that we are getting on our syslog server. I replaced the UUID with X.

<150>AP:ESMANAGER 11/17 12:58:31,094[nioEventLoopGroup-8-3]INFO utils.SyslogManager[terminateSession: 304][XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX] - HORIZON_SESSION:TERMINATED:Horizon Session terminated - Session count:7574

<150>AP:ESMANAGER 11/17 12:53:30,636[pool-4-thread-1]INFO utils.SyslogManager[terminateSession: 304][] - HORIZON_SESSION:TERMINATED:Horizon Session terminated - Session count:7575

<150>AP:ESMANAGER 11/17 12:39:05,064[nioEventLoopGroup-8-1]INFO utils.SyslogManager[setAuthenticated: 286][XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX] - HORIZON_SESSION:AUTHENTICATED:Horizon session authenticated - Session count:7574

<150>AP:ESMANAGER 11/17 12:39:04,845[jersey-client-async-executor-4185]INFO utils.SyslogManager[onSuccess: 169][XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX] - RADIUS-AUTH passcode response: SUCCESS

I'm betting markbenson​ might know.

[markbenson]

Unified Access Gateway (UAG) sends syslog messages when a session starts and if the authentication for that session is successful. This is in cases where UAG is performing the authentication.

Connection Server also has logs for the actual desktop/app session up to the point of logoff.

The RADIUS server will know the details of the RADIUS Access-Request response including the reason for any failure.

syslog messages in UAG are fixed.

The OPSWAT support with UAG is for endpoint compliance checks and takes place after user authentication. It is to ensure that the client device (Windows or macOS) comlies with customer policy in terms of OS version, anti-virus signatures, OS patches, password screen lock, encrypted drives etc. Access is denied by UAG for non compliant endpoints.

Mark

[BenFB]

Thanks for responding markbenson​. Are there any plans to improve UAG logging?

Is there a way to at least map the UUID (XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX) that is in the UAG logs to something useful like a username? I tested logging in with the same username back to back and it was a different UUID with each request. With the volume of sessions that we see it's not always possible to correlate similar timestamp between the connection server and UAG.

[BenFB]

markbenson​

We did some additional testing and the connection server logs have all of the information that we need except for the client IP address. It instead shows the IP address of our load balancer. We've verified that we are sending the X-Forwarded-For (XFF) headers to the connection servers but they aren't adding that IP to the logs. Is there something on the connection server that we need to configure to support X-Forwarded-For (XFF) headers?

[ksliger_pnfp]

Check out the Horizon Toolbox fling. There is some pretty good auditing you can get from it and it pulls information directly from the event db for your environment.

Horizon Toolbox

[BenFB]

We use Horizon Toolbox but it does not contain this information. I'm told that there are plans to add support for x-forwarded-for (XFF) headers in a future UAG release that will resolve our issue.

[elcoco]

Hi,
I face the same issue. Do you know if the last version of UAG solved it ? Or how can we manage to get the info

Regards,

[ivaiva]

Hi,
Have you found a solution?

[Rude]

@ivaiva Have you given this a try?

https://flings.vmware.com/edge-services-observability