Jump to content
Welcome to our new Citrix community!

Generating syslog message from authentication policy

Doug Hall

Recommended Posts

We have v13 Gateways used for ICA proxy connections.  There is  a log action that generates an informational syslog message (for example -  "Client IP is " + CLIENT.IP.SRC).  If this is configured as a log action on a responder policy (bound to the VPN server) that checks for the existence of a cookie it works.  If it configured as a log action on an authentication policy nothing happens.   We see the policy hits increment but there is no syslog record written.  It would be ideal to generate the syslog message as part of the authnentication so that we can include the username and domain in the message.  Any ideas how to get this working?  Doug

Link to comment
Share on other sites

What log action do you have attached ro your authentication policy and how is your authentication policy bound?

If using nfactor, how complex is your authentication flow: single factor/cascade/two-factor...

AAA vserver or system authentication.

Exact firmware version in case it is a version specific behavior.


I can't mock up a test until later to see if its an issue on the authe policy, but if we assume it might be a config problem and not a bug, I would check these things first:

If your log action includes the username parameter, try switching your log action to a simple static string like "Authe policy hit occurred." And see if it logs; but not with the dynamic string. Its possible the policy hit happens to do the authentication BEFORE we know who the user is, so there is no "aaa.user.username" or whatever value defined at the policy hit (before the user actually authenticates). 

If it works on the static string but not the dynamic one, its probably an issue like the value being logged doesn't exist yet because its before the authentication occurs. 

If it doesn't work on the static or dynamic string for the log action on the authentication policy, but it does work on the responder policy, then the issue is likely with the authentication policy itself.  One confirm if that policy is actually being hit and not some other policy in the policy cascade being hit first (or a case where we think its doing two-factor but isn't).


It might require a next factor policy hit that confirms you got to this point to do the logging after the first event occurs.  

Link to comment
Share on other sites

  • 2 years later...

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Create New...