WSA Transparent User Identification runlogon user

[peter.edelen]

I'm running the Active Directory Agent 1.0.0.32.1 Build 598 and the Ironport WSA 7.5 with transparent user identification for an NTLM authentication realm. I have 3 AD DCs configured in the AD agent and the WSA configured as the client. All communication is up between the AD agent and DCs and WSA.

Upon initial logins, the AD agent is pulling the correct username and IP mappings from the DC security event logs and passing to the WSA. At this point, the AD agent and WSA have the correct mapping for any given username. The AD agent is then hitting the DC security event logs again and catching subsequent entries with the user as "runlogon" at the same IP address and replacing the original username by creating a new mapping and returning it to the WSA, so I lose the unique usernames and have 'runlogon' as the user in reporting for most users.

The timing on this is pretty short and does not match any of the configurable timers in the AD agent or CLI tui settings on the WSA.

Has anyone else dealt with this or experiencing the same issue with WSA or ASA IBF?

[Ken Stieers · Accepted solution]

Peter,

Is "Runlogon" a user in your domain?  Some sort of higher privledged account so that login scripts can do some things to the machine that a user can't?

There currently isn't a way to tell the AD agent to ignore specific login ids, so things like SMS/SCCM accounts that may login after the user does will fubar this for you too.   Each subsequent logon on the box changes who's tied to the IP of that box... which is why ADAgent doesn't work for Citrix sessions either...

Its bug that needs to be fixed.

Ken

[peter.edelen]

Ken,

Thanks.  Yes, I think it is a service account tied to their Novell login scripts.  I pretty much figured that was the case.  I have a TAC call open in case there is an undocumented workaround. We're trying to get away from browser authentication because of all the user agent and website issues.  I was surpised not to find any similar issues reported just yet.

The AD agent seems to be constantly pulling the info from the DCs despite the cache timers when I thought it was more on demand.  I'm currently running it in a test bed and a good mapping gets wiped out by the runlogon user in under 2 minutes.

Hopefully they will fix it in a coming release.  More persistent mappings and a filter would be ideal.

Thanks for your reply.

Peter

[peter.edelen]

It appears that this was an isolated incident. I've been running the AD Agent for 24 hours and have not been able to recreate the problem. The initial issue may have been related to initial turnup and/or a major desktop update was occurring during that time. I've been unable to confirm with the systems people on what may have been occurring during this period last week. Looks good.