2017-07-28

To proxy or not to proxy

Today I was asked to update the EGVP (Elektronisches Gerichts- und Verwaltungspostfach) software on a client. The software is used to send an receive encrypted emails and to verify that the senders are who they claim to be. [official site] [wikipedia]

After I found out that the old client was never installed on the system I found out that until version 2.9 the whole thing was also available as Java WebStart. After 2.9 only an installable msi-version is offered. Ok then, lets hope the new version is smart enough to import all the old settings from the WebStart version I thought ...


So I installed the new version without any problems but when I tried to start the software I was confronted with a rather confusing error message. Confusing because it does not make much sense given the circumstances.

 
 
All internet traffic is going through a proxy with basic authentication. So why was the error message saying "Proxy-Typ: DIRECT"? Clicking "Internetoptionen öffnen" only gave me the Internet Explorer proxy settings and those were correct. The documentation of the software said that basic authentication is supported and the user should be prompted for a username and password if the data was not stored in the Windows password store already. So what was going on?
 
For other pieces of software we had already added exceptions in the proxy configuration to bypass authentication so I checked with the server guys if the host the software wants to access (which I got from one of the config files rather than listening in on the traffic with wireshark) was already on the list of exceptions or not ... it was. So why was it not working then? Even odder, the proxy logs did not show any signs of the client ip actually trying to access the host at all at the time I was testing. So it must have really tried to use a direct connection rather than going through the proxy.
 
I installed the software on one of my test machines and tried to run the software with my own account rather than the account of the user who is supposed to use the software. And it just worked. No error, no nothing. What the ...
I logged onto the same machine with a test account of mine and tried again. Error. The same as with the first user.
 
Something must be different about my user compared to the others. Right, I'm using an admin account. Let's try that. And let's also test whether it makes a difference who installed the software. So I made the first user admin on another machine and used that account to install the software. Same result, same error.
 
So I knew it was not related to being admin on the client, it was not the user who installed the software and the proxy settings were the same too. So what else is there? AD group memberships and GPOs. After ruling out most of the groups I found one that was the most likely culprit. All our users (with the exception of the IT department) are members of a certain group that gets a much tighter set of GPOs than the remaining users (the IT department). So it was most likely one of those settings.
 
And bingo. After removing my test account from that "standard users" group and restarting the machine the software worked. Just like that. After adding the account to that group and restarting again the software stopped working again. I found the culprit. But which setting could it be?
 
After brainstorming with a co-worker about the issue we actually figured it out ... our regular users are not allowed to modify/access the registry by the "Prevent access to registry editing tools" group policy setting found under "User Configuration > Administrative Templates > System". This setting blocks the use of reg.exe and regedit.exe. And that is what caused this issue.
 
The EGVP software seems to be using reg.exe to query the proxy settings from the registry. And instead of throwing an error it just silently fails and falls back to trying to establish a direct connection instead.
 
To verify I remotely set the value of "DisableRegistryTools" under "HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\System" to 0 and indeed to software was able to start without any problems.
 
 
So now we have one more enforced GPO and two more users who (for the time being until the software is replaced with an Outlook AddIn in the next few weeks/months) are allowed to use regedit.exe, other than the people from the IT department.
 

No comments:

Post a Comment