While UDT on the whole is pretty good (we wish it would share better with the other Orion modules and leverage things like the Layer 2 and Layer 3 discovery components and vice versa), we haven't had much luck with user tracking and lackluster response from SolarWinds support. Reading login events from the Windows Event logs of specified Domain Controllers, we quickly discovered that the user tracking component doesn't scale well and suffers from a few idiosyncrasies, courtesy of Microsoft:
1) The Domain Controllers must be managed with WMI in order to access the event logs. Bye-bye SNMP interface data since SolarWinds doesn't provide a "Manage with SNMP AND WMI" option yet. Maybe this is a non-starter since Microsoft intends to drop SNMP support from its server platform but nonetheless, problematic if you're storing long-term trending data and discover that it's wiped out when you change from SNMP to WMI.
2) We are a corporate enterprise of 250+ offices and 14,000+ employees. That means our DCs see several tens of thousands of login events daily. UDT had an enormously difficult time polling and collecting the user information and the logs filled and rolled quickly. This is partly an issue caused by Microsoft in the way they collect user login information but it means that UDT simply can't scale to large environments. Our sys-admins wouldn't support user auditing turned on for more than a few hours for testing because it made the logs unusable. SW needs to find another way to retrieve this data or provide a better method for collecting and purging the data. SW suggested ignoring logoff events (already set) and setting the logs to overwrite as needed (also already set) so they obviously haven't worked with UDT in a large enterprise yet.
3) UDT provides erroneous login information, again courtesy of Microsoft. When a user logs into their machine, the machine does a quick 'browse' of its neighbor systems and creates login events on all of those systems. When a user checks their Exchange mail, Outlook logs in to their mail server and creates a login event. When a user connects to a network file share, a login event is created and when a user connects via RDP or Citrix to a remote machine, a login event is created. So which machine did the user really login to?
While the ability to tie a user to a machine, IP and switchport is welcome and desperately needed, problems scaling and an inability to localize login events means the 'U' in UDT isn't ready for prime-time yet.