I've had a couple customers ask me how to enhance/automate their troubleshooting when an end user observes a block that they weren't expecting. The Site Review ruleset that is posted here: Re: Block Page - Email Link - add URL and other good info is a good start, but if an administrator follows the link in the received email they might not get the same rules applied (because the administrator is using a different username and is a member of different groups) and the site might behave differently through MWG. The attached zip contains rulesets to help with this challenge. Note that the impersonation ruleset currently only resets the usernames and user groups. If there are other criteria (for example source IP) used in your rulesets to determine action, you will need to modify the rulesets accordingly.
This ruleset 1) allows authenticated users that match the Impersonation Users list (administrators) to impersonate any other user (and get the same reaction from MWG) without needing the end user's password and 2) automatically generates a rule trace of the request. The rulesets are designed for an AD/NTLM environment but could be adapted for straight LDAP, or Kerberos. Users in the Impersonation Users list can impersonate another user for 2 minutes following a request that adds the parameter impersonate=<username> to any URL.
The ruleset is supplemented by a logging rule that preserves the integrity of the access log and creates a separate log that includes the original user name and the impersonated user name. Also included in the zip is a modified version of the Site Review ruleset that adds the requesting user's email address, and groups, as well as a link already configured to enable impersonation. Zip file also includes README.txt with installation instructions.Note that the readme is still pretty rough and may contain errors. If anyone uses it to install, I’d like feedback on how it could be improved.
Impersonate Log ruleset creates an impersonate.log logfile and fills it with entries that look like this:
[11/Mar/2011:15:33:00 +0000] "Administrator_as_jebeling" 192.168.197.112 403 "GET http://www.playboy.com/ HTTP/1.1" "Pornography" "Minimal Risk" "" 0 "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:22.214.171.124) Gecko/20110303 Firefox/3.6.15" "" "10"
The ruleset should be placed before the rule that writes the standard access log so that the access log reports the actual authenticated user.
Modified Site Review - Note that this also requires changes to the block pages so that parameters are properly passed from the original block page.
Message was edited by: jebeling on 9/14/11 7:41:58 AM CDT
Message was edited by: jebeling on 12/15/11 12:11:45 PM CSTMessage was edited by: jebeling on 12/15/11 12:15:44 PM CST
Please note that PDstorage timeouts are currently (7.3.0 and earlier at a minimum) “inactivity timeouts”, meaning only if the pdstorage value is not checked (…has…. Property) or read (…get…property) for the amount of time specified in the timeout, it will expire.Otherwise it will live forever. This means that once you set impersonate, it may not clear after the PDStorage timeout (default 2 minutes) if requests are continually being made by the original user id. This could happen if multiple browsers or clients are using the same credentials, or if some web page or web app is continuously updating itself, or if the timeout was extended significantly from the default of 2 minutes.
This problem should be entirely avoidable by only using impersonate when the original user is logged on to only one machine with a single browser session in a single tab.
However, if this problem does occur, it is recommended that the administrative user shuts down all browsers and any apps using HTTP through MWG, and then starts a new browser session with a single window to a static web page for example www.mcafee.com. Then, make a request for that webpage with the clearimp parameter, for example http://www.mcafee.com?impersonate=clearimp
Is it possible to use NTLM instead of LDAP with the V2 impersonation ruleset? I tried it and am getting the following error. It doesn't seem to be able to pull the list of user groups for the impersonated user.
|User-Defined.notificationMessage||Error.ID=10056; Error.Message=(10056) Internal rule engine error: property is in unexpected state.; Incident.ID=0; Incident.Origin=0; Incident.Severity=0;Incident.OriginName=; Incident.Description=;|
Nope. I won't go into the technical details, but in order to get groups using NTLM you would actually have to be able to use the credentials of the user that you want to get groups for, which kind of defeats the purpose of the ruleset.