The Right Stuff

We are working with a DSL connection here and offer some services to the outside world, for example Remote Desktop login to each roommate's workstation. This web site is also served through this DSL connection. That's what Bill Gates must have meant when he talked about the vision of "information on your fingertips"¹.

Simple consumer DSL line like ours have an annoying "feature": The provider disconnects the line every 24 hours to force redialing the connection and thus allowing him to assign a new public IP address. This prevents offering large scale services and forces businesses to buy a more expensive connection package with static public IPs. Because nobody on the internet knowns our current IP address (as it changes every day) we use a Dynamic DNS service to update the IP addresses of our domains (www.it99.org, www.pixelplastic.de and some others).

There are Dynamic DNS clients that monitor the connection and issue an IP update to Dynamic DNS service like DynDNS. Current routers even come with such a client. I was trying the demo version of DirectUpdate to see how it works.

This is the DirectUpdate management screen. Notice that the window is not resizable by means of the standard minimize, maximize and restore buttons (). What happens if you log in with a resolution of 640x480 and the window floats around off-screen? You're lost. One might say that this a very uncommon case today as CRTs with this resolution are pretty much dead, but we had such a display connected to the old server.

After installing DirectUpdate everything worked fine, DynDNS updates were issued and the service ran reliably. However, the security event log filled up with strange "Audit Policy Change" events. These events occurred at random times. Each time the Logon/Logoff and Account Logon audit, which forces Windows to log successful and failed logon attempts to the security event log, was completely disabled. All other audit settings remained untouched.

Event ID: 612
User:  NT AUTHORITY\SYSTEM
Audit Policy Change:
New Policy:
Success Failure
  -  - Logon/Logoff
  -  - Object Access
  -  - Privilege Use
  -  - Account Management
  -  - Policy Change
  -  + System
  -  - Detailed Tracking
  -  - Directory Service Access
  -  - Account Logon
Changed By:
User Name: ARWEN$
Domain Name: WG
Logon ID: (0x0,0x3E7)

I've reset the Windows Audit Policy to log Logon/Logoff and Account Logon events each time a 612 event was logged but after some hours the policy change would occur again. Tracing the system events using Filemon, Regmon and Process Explorer gave no clue about the source of the error. Time to open a support case using a voucher that Torsten kindly let me use.

The Microsoft support clerk recommended disabling all non-Microsoft services (there were about four) on the system. Lo and behold, the Audit Policy Change events didn't appear again. After gradually re-enabling these services I found that DirectUpdate was the source of the policy changes. The next step was to prevent DirectUpdate from issuing policy change requests. As there's no setting on the UI regarding policy, I had to dig deeper.

DirectUpdate installs as a Windows service. Because it appears easier for the developers if DirectUpdate the service runs under the SYSTEM account, the most powerful account in Windows that's allowed to perform every operation. Why should a service that's sole purpose is to monitor IPs and sending HTTP requests run in such an unrestricted environment? I changed the service to run under the Network Service account, a restricted user for the very purpose of running services under it:

The new Network Service account [...] has a greatly reduced privilege level on the server itself and, therefore, does not have local administrator privileges.

1. Open the Services MMC Snap-In by running services.msc
2. Search for the "DirectUpdate engine" service
3. Right-click, select Properties and open the Logon tab
4. Enable the This account radio button, then Browse and enter NetworkService or browse for the localized Network Service name
   
5. Click OK
6. Grant the following rights to the Network Service account
   
   • Change in the DirectUpdate log file folder
   • Change in C:\Program Files\DirectUpdate\Dump\
   • Full Access in HKEY_LOCAL_MACHINE\SOFTWARE\Fraggers.net
7. Restart the service

This did the trick. DirectUpdate runs peacefully and the Security Policy doesn't get changed anymore. So, thanks again Torsten for allowing me to contact Microsoft Support on the issue!

¹ Phew, this is the ugliest Microsoft site I've ever seen.

Now playing: Yonderboi - Splendid Isolation - Motor