Hi, I've just upgraded a Trend Micro CSC-SSM module on a ASA 5510 8.0(4) to 6.3.1172.2 version.I configured url filtering policies for user and group in my Windows 2003 Domain, I installed 2 Domain Controller Agent respectively on PDC and BDC servers, and under user identification setting in Trend Micro console, I can see both servers correctly recognized with no errors. My problem is that url-filtering policies that I created are randomly applied to the users: some allowed sites are suddenly blocked, and viceversa. Looking at logs, it seems an userid verification issue, some userid can't be resolved and others are resolved discontinuosly.
I need some help to solve this issue. Thank you very much in advance.
There has been a similar issue that has been observed.
If you are facing that one it is only in 6.2.1172..2 and due to some threads running on the Agent. The symptom is that user ids are intermittently not recognized and sometimes filtered using the Default policies.
Try opening a case with TAC and they shall provide a special agent image for you that has the fix (if we are talking about the same issue).
I hope it helps.
yes I think my problem is the same one you are talking about, i opened a TAC about it but they din't talk yet about a new agent version.
I hope they will.
Anyway, could you help me about following questions:
Please mention and ask TAC for the bug with the Agent in 6.3.1172.2 that slows down pages when using AD.
1) It should not make a difference. If the Agent is on the AD server you avoid issues with network problems blocking messages between server and Agent though.
2, 3) The default values should be fine
4) Please ask the TAC engineer for that.
Hello! Were you able to fix this? We are getting an issue (our AD is a Win2008 64-bit server, BTW) where the mappings will work for about a day, then a group of users; random at best... starts mapping to the default policies and the log shows the user IP browsing out but the user ID is [NOT FOUND].
Did the remote agent special version fix your issue or something else?
Unfortunateky it didn't. I opned a TAC for the issue but it's sitll opened. I was't able yet to solve the issue. Some weeks ago was relased new version of CSC-SSM software which includes a nee agent's version too. I wasn't able yet to try it, if you can, try it and let me know as soon as you can.
ok god luck then, I iope you will be more lucky then me, I will appreciate of you could let me know the result of TAC.
Yes, I'm just trying the 6.3.1172.3 agent version since 2 weeks and it seems working better. Till now no problem yet. You should need to set Activedirectory parameter in IDagent.ini to 1.
Try and let me know.
Cisco release notes for 6.3.1172.3 state the following :
Case ID: Trend#2207 Cisco#CSCtf40408
Issue: Users may not be detected on a PC with multiple IP addresses.
Change: Allowed the client workstation to be queried directly when the log-parsing approach does not work.
A new config item "ActiveQuery" has been added in the IdAgent.ini file. In previous versions of CSC, the Domain Controller Agent might not find the UserId for the requested IP address using the previous log-parsing approach. Now, if the new "ActiveQuery" config item is set to 1, the Domain Controller Agent will perform a remote registry query to the client workstation directly to query the logon user. The default value of "ActiveQuery" is 0, which behaves the same way as previous versions.
Remember you need to edit the .ini file of the IDAgent and turn the ActiveQuery setting to '1' to enable this.
I was on 6.3.1172.0 and was having big problems with exemption groups and users working one day and then not working the next.
After installing 6.3.1172.3 it looks to have resolved this issue.
Previously Citrix users were being picked up by their login name, while now they are all coming through as 'Administrator'
Anyone else noticed this ?
Have been having the same issue for a while so I thought I'd write in some bits and bobs I'd found ..
1. I've found that the machine that is running the agent may need to be logged in, or at least logged in after a restart and before you make any changes to the exemption settings.
ie. if the system hosting the agent is restarted then any existing settings will work, however any new settings won't be applied until the machine is at least logged in and you see the agent running in the task tray.
2. If a user has logged into multiple systems the agent / CSC seems to get confuzed and allows one but not the other. Work around (not solution) I've found for this was to either make the exemption on the IP address, and if the machine was on DHCP then reserve an IP for that machine and then exempt it. This may not be the best solution for networks with more workstations then DHCP IP's, but does get you around the issue.
Easiest way of checking whats happening is to ask the user to attempt to get through to a blocked / exempt site and check the logs to see if it picks up their user name. Scanning through the logs shows you how hit and miss it is, with some users from workstations being picked up and others not .. and likewise (and strangely) some Citrix users all logging into the same system get picked up while others do not.
I was going to have a play around with the AD login settings as it I was thinking the issue could be a system is allowing a login through cached credentials and allow synching with AD after a while, but this may mean the CSC SSM isn't able to authenticate the user right away so it takes a couple synching cycles for it to go through.
However this doesn't explain why my Win7 laptop (reserved DHCP address) works fine with only an LDAP username exemption setting, while another Win7 machine also with a reserved DHCP only works with an IP exemption.
(maybe the programming of the Agent isn't that solid and is causing the issue)
I have seen a ton of problems with User ID detection on WIndows 7 and i machines. The reason this is is because the Agent cannot resolve who is logged in on that machine. The way it all works is first the Agent latches on to the Security Event log in the Domain Controller (Like an RSS Feed) and looks for certain events indicating that a user has logged into a machine (Make sure your DC's are logging Event ID 672 and 673). When the Agent sees a logon event, it then proceeds to connect to the workstation that just logged in on TCP/445 in order to connect to the remote registry service. Once connected, it uses the credentials programmed in the User Identification settings page of the CSC GUI to pull information about what user truly is logged into the machine. If this fails, then we do not classify that machine as being logged in with a user, we can only classify by IP. Stuff that could break this would be:
- Firewall in the patch between the ID Agent Machine and then user's desktop PC
- Firewall running on the Desktop PC that does not allow connectivty from the IDAgent Machine to the remote registry service (Windows firewall tend to block this)
- Remote registry service being turned OFF ont he desktop PC (seems to be the default in Vista/7 from what I have seen)
- RPC Service turned OFF on the desktop PC.
Can you check those different things and fix what ever is not right.
A quick/dirty test would be to log in via RDP to the machine that is running the IDAgent process. Log in using the Domain Admin credential you fed it in the CSC module settings page. Go to Start -> Run -> regedit. after registry editor loads, click on File -> Connect Network Registry and then enter the IP of the workstation causing you greif. If you can load the remote computers registry, then the ID agent should be able to classify it just fine. If you cannot, it will tell you timeout (firewall issue on Desktop PC) or some other error.