DevelopMENTAL Madness

Wednesday, November 12, 2008

IIS 6.0 with Windows Authentication PITA

A small thing really, but one that cost me a full day of digging and my scalp is sore from all the scratching and hair pulling. It all started when the test server was hosed (rebuilt) without asking me if it affect anything I was doing. Without going to much into the history, an application that should have been on production was on staging and being used as the production application. 

Stop right there - don't start pointing fingers cause I've got no control over this other than the continual protesting that I have been doing. Not to mention that the person who requested the rebuild of the server has been in meetings where I have said, "It's on test and needs to be deployed to production - the users are using test as production.".

Anyway, I find about it from the users and am tasked with getting the server configured. I'm no IIS guru/god, but I'm hardly a neophyte. However, I don't have a lot of IIS experience in an intranet environment because usually when I work in these envrionments there is someone dedicated to this role. 

First, I verfied IIS was configured the same way as our development environment, which was working correctly. Then I dug through the security event logs and found this message:

Unknown user name or bad password

Also, the authentication method logged was kerberos - at the time this meant nothing to me for reasons I mentioned above. How was I supposed to know they weren't using kerberos? But it turns out that was the key.

Apparently, this is by design. IIS is configured to use kerberos for Windows Authentication by default. But when your application pool is using a local machine account (the default) your application cannot access the domain controller. The key is to tell IIS to use NTLM instead of kerberos. This support link will tell you how to resolve this:



Labels: , , ,

Wednesday, November 05, 2008

Sending DateTime Parameters from AJAX to WCF Operations (methods)

Yesterday I got stuck on a problem with a DateTime parameter I was attempting to submit to a WCF operation (method). I was trying to call call the operation using POST and the format was JSON. I was getting the value from the javascript Date object like this:

var eventDate = new Date();
var json = { date : "/Date(" + eventDate.getTime() + ")/" };
// value of date would be "/Date(65746416843)/"

(yes that number is completely off the top of my head)

But after the POST operation the date on the server side was 7 hours ahead. I knew it was because I am live in the MST time zone (-7), but I couldn't find how to get WCF to parse the date with the time zone adjustment.

Here's what I finally figured out, since I was using the ExtJs library I was able to do this:

var json = { date: "/Date(" + eventDate.getTime() + eventDate.getGMTOffset() + ")/" };

The result was json.date was "/Date(65465463546-0700)/". By appending the GMT offset WCF correctly parsed the date as it was entered.

If you're not using a javascript library you can use the javascript method getTimezoneOffset(). It will return the offset in number of minutes, so you will need to divide the result by 60 and format the string to get the correct format for your date string before you submit it to WCF.

Here's a link to the documentation, look under "Advanced information" and then "Date time wire format". http://msdn.microsoft.com/en-us/library/bb412170.aspx

Labels: , , ,