More IIS 6.0 Fun

Several months ago, I set up a new network environment that was not live at the time.  That environment, once up and running and ready, was then utilized by some outside consultants and developers as an ad-hoc testbed.  Ultimately, The work carried out was not entirely (I am starting to doubt this every happens) removed or cleared up, so the system was back in its original state.  Luckily (or smartly), a complete backup of the system state, the IIS metabase, and the IIS configuration and directoy structures were made before access was given.  This allowed me two options:

 

1) Figure out what got changed and how to undo those changes

2) Restore the system settings, configuration, metabase, and directory structure.

 

Time not being of the essence, I chose the former.

 

When websites utilize an anonymouse user, that user can either be the default (IWAM?) user, or any other user you choose to specify in either a domain or local machine.  When this happens, or if any other site on IIS, or Virtual site utilize a non-default anonymous user, this poses frustrating authentication problems.  There are two ways (maybe three, but I didn't have any luck with the adsutil.vbs approach of synchronizing the passwords) that I was able to resynch the ever-changing anonymous user password hash.  The first is to route out all descrpencies for each and every incarnation of the mismatch for the user in the metabase (Make sure you are able to edit the metabase directly if you want to try this dicey approach.

 

The more-straight-forward approach that is much much safer to use is to disable all authentication for each website and virtual website.  Once that is done, you can go back and start enabling the anonymous authentication.  What is happening underneath the hood, is you are allowing IIS to automagically handle all the password hashes on the metabase by removing them.  Then as you re-enable this for each website or Virtual website, IIS will automatically ensure the passwords are synchronized when you select the other sites in the Apply Changes Prompt.

 

What causes them to get out of synch!?

 

This, thus far in my experience is not terribly easy to explain.  From what I can gather in the limited testing I have done, lets say you have siteA and virtualSiteA.  If you disable the synchronization on siteA then later re-enable it, you need to select any and all virtual sites when prompted to apply the authentication changes to.  If this doesn't happen, then oldest password hash (now virtualSiteA) is going to have the only legitamite hash to authenticate against, and the rest of your sites will not operate the way you want/need them to.

 

So, before you go out and start messing with Application Pools, or deleting and recreating users, try the above (no warranties!  Use entirely at your own Risk!).

SQL Data Types

So now that I'm studying for my 70-431 exam fully, I am writing out the datatypes:

 

• Exact Numeric (Used for precision data)
• Approximate Numeric (Used rarely, and appears to me to be a hangover from C)
• DateTime
• Money
• Character
• Binary  (this includes the image type most likely usedin Sharepoint for storing documents)
• Specialized (identity for primary keys, GUIDs, are two examples here)

Constraints:

• Check Constraints (These are set on tables)
• Rules (These are being phased out if not already in 2008, do not use), can be used outside of a table
• Unique Constraints (Prevents duplicate values in columns)
• Default Constraints
• Primary Key
• Foreign Key (this constraint ensures the value exists in another table already)

 

Scheduled Tasks are a Sensitive thing!

The other day after restriction of service accounts on a network, I was faced with troubleshooting why some scheduled tasks stopped running.  The accounts that ran the tasks were no longer part of the administrators group on the local machine in an Active Directory environment.  Not even Power User or Serer Operator group will work for you here, and we are referring to Server 2003 +

 

I believe the best practice is to create a domain user, and then incorporate that account in to each local machine's local Administrators Group as necessary to perform its tasks.

Network Monitor and the SSL Handshake with DNS

Recently I found myself migrating a system to a new data centre. During that testing a user realized that their process for submitting data was not working.

Despite the website working, the submission to an ASP link over HTTPS kept returning errors that the specified file cannot be found.

After quite a bit of time, the root cause was addressed down to DNS. I missed an early-on fundamental question of whether or not they utilize the hosts file on their system they were submitting information with. As it turns out, there was a typo in the domain name entered in to the hosts file!

So what ultimately what led us back to that (It was reassured previously this was not the problem and the link was fine) was the use of Network Monitor to watch the SSL handshake.

The following link provided a nice rundown showing the mechanisms on a Windows Server:
http://support.microsoft.com/kb/257587

It was in the packet details that I realized that not only was the site certificate being sent, but it was also sending the parent Certificate Authority also. The sending of the parent CA only happens when the initial website SSL certificate does not get trusted by the connecting client. This can happen for any number of reasons, like out of date revocation lists, CA updates not applied, or, in my experience here, a typo in the LM Hosts file.

So, wait a minute, why didn't it just use DNS? Well, the specification of DNS in 1034/1035 (Forget which) has a DNS client follow a very specific method of resolving a name to an IP address.

1) Client checks the local hosts file
2) Client checks its local memory cache
3) Client queries a DNS server (a second one if no response)
(client may try to query a root server at this also depending configuration and definition of a DNS client)
4) Client waits for a response

So why does the hosts file get looked at first and not the local cache? This occurs because the history of DNS. Back before the hierarchial querying was established, ALL of the internet DNS was held in a hosts file. Once this became unmanageable, DNS in its current incarnation (more or less) was formed.