The project server here at work hasn’t been connecting to our internal WSUS server, and I noticed that it was missing a few security patches.  Since WSUS wasn’t working, I decided to visit Windows Update.  HA, well that doesn’t work either.  So I open up the %systemroot%WindowsUpdate.log and find the following error.

WARNING: WinHttp: SendRequestToServerForFileInformation failed with 0x80190191
WARNING: WinHttp: ShouldFileBeDownloaded failed with 0x80190191
WARNING: DownloadFileInternal failed for http://download.microsoft.com/v6/windowsupdate/redir/wuredir.cab: error 0x80190191
* WARNING: Failed to synchronize, error = 0x80244017
WARNING: WU client failed Searching for update with error 0x80244017
>>— RESUMED —COMAPI: Search [ClientId = WindowsUpdate]
– Updates found = 0
– WARNING: Exit code = 0x00000000, Result code = 0x80244017
————-
— END — COMAPI: Search [ClientId = WindowsUpdate]
——————-
WARNING: Operation failed due to earlier error, hr=80244017
FATAL: Unable to complete asynchronous search. (hr=80244017)

Doing a quick search on the error code on Google brings me to a lot of pages about proxy settings.  However, I’m not running a proxy server anywhere, and I’m not running ICF on the project server either.  What is going on?!

Then I see a link about project server with this error.

I now know that project server uses a proxy server with WSS.  How stupid can that be?  Well, basically, I added our local WSUS server to the bypass list.  I also did it for *.microsoft.com, but that still doesn’t seem to be allowing me to hit Windows Update.  Oh well, at least it can update from someplace.

 

Well, today I passed my last required MCSE test.  In three months, I’ve been able to complete the 7 required tests.  Unfortunately, I still have one more on my plate though, because I want to get the MCSE: Security certification.  Thankfully the remaining test is simply an elective exam, so I can probably kill that in a week.  Not having any of this pressure on me for the rest of the year will be nice too.  I’m definitely glad I got this out of the way before summer rolled around.

In fact, some days you learn two things!  Be warned, techno-speak is about to ensue.

Lately, I’ve been reading a lot about Windows sercurity.  Now, all the books I’ve read that have dealt with authentication bring up the differences between LM, NTLM, NTLMv2, and Kerberos.  The general idea that these books give you is that the Lan Manager and NT Lan Manager authentication methods use a hash or a challenge/response hash, while Kerberos uses time based tokens.  The key word being “time”.  Nowhere in my reading was it brought up that any versions of Lan Manager authentication had time involved. 

This leads me to my problem yesterday.  We have an NT4 domain setup to mirror a customer’s environment.  This NT4 domain contains many environments for various testing purposes.  One of these purposes is regression testing with date changes.  Prior to this week, changing the date on the machines has been fine.  However, this week we ran into problems.

Now, for those of you that aren’t familiar with NT4, it uses LM, NTLM, or NTLMv2 (SP4 or above) authentication, which according to everything I’ve read had no time restrictions, and everybody in the office was in the same boat as me.  In fact, these machines authenticated fine with date changes until this week.  The difference being a security template we had been applying to all machines that was given to us by the customer. 

To begin with, we knew that it was a problem with the security template because non-hardened machines would work fine with the date change still, while the hardened ones would throw errors.  Basically, critical application services couldn’t start after the hardening had happen.  Now, it was my job to figure out what the security template was doing to prevent these services from running.

First I went through the documentation that came with the security template to see what they changed, and tried to find the obvious answer.  Well, of course that didn’t work.  So, instead, I just started changing settings back to the original.  Thankfully I started at the bottom, and four changed settings later, I was at my solution: Network security: LAN Manager authentication level.  The security template was setting it to “Send NTLMv2 response onlyrefuse LM & NTLM”, while the default setting is Send NTLM response only.  The default setting worked, but I wanted to try the other two settings between the default and the hardened setting: Send NTLMv2 response only, and Send NTLMv2 response onlyrefulse LM.  Needless to say, neither of those settings worked either. 

Now, you may be thinking that we were having problems with NTLMv2 because our PDC and BDC on the NT4 domain aren’t at SP4 or above.  Bah, I say to that, we’re at SP6, so we can have NTLMv2 authentication on our domain.  So why was the hardened setting, or any NTLMv2 setting for that matter, not working?  Well, after much googling it appears that NTLMv2 is time dependent.  In fact, the NTLMv2 response contains a little-endian, 64-bit signed timestamp.

Let me tell you how assured I was in the books I was reading after that. 🙄  After reading about this timestamp, we wanted to figure out how much of a time delta NTLMv2 allowed (for purely scientific reasons).  After some testing with the hardened machine, it was concluded that the timestamp of the response cannot be greater than or less than 30 minutes from the challenge machine (in this case the PDC).  So, in our testing, setting the date back a month, obviously was outside of this delta.

Then, later that night I was playing with my ISA 2004 machine at home.  A little background first.  I’ve got multiple websites on multiple machines at the apartment that use port 80, so I’ve been using ISA to publish the websites.  Otherwise, all the sites would have to be on one machine, since the router only supports port forwarding, and not host header forwarding. 

So, I’ve been dealing with a problem where whenever I would set the firewall rule to “Requests appear to come from the original client”, my website wouldn’t load.  This is a nice feature for stats, so that you can actually see where visitors come from.  For the interim, I’ve had it set to “Requests appear to come from the ISA Server computer.”  So, everything from referrers to log files show the IP address of my ISA server, bleh.

Finally, last night, I had time to figure out the problem.  I knew I needed to head over to ISAserver.org, but I didn’t realize how fast it would be to find the answer.  Basically, since my ISA server, isn’t acting as a gateway on my network, it can’t be set to requests come from original IP.  However, by making the ISA server the gateway on my web server, everything works the way I want.  Unfortunately, this means that I can’t route outside of my network on the web server anymore, but since it’s just a virtual machine used to serve static webpages anyways, this isn’t a big deal.

So, to recap, NTLMv2 responses are time sensitive and ISA must be your webserver’s gateway if you want requests to appear to come from the original client.