Welcome to Community Server Sign in | Join | Help

Well, it's been a very busy couple of months for me. The Professional IIS 7 book is only a couple of months away from being available, and it's been hectic getting that wrapped up. In addition I presented some talks at Tech.Ed Australia (on the Gold Coast) and Tech.Ed South East Asia (Kuala Lumpur) on IIS 7.0

Today brought a welcome surprise - a complimentary copy of Windows Home Server as a thankyou for participating in the beta program. Time to upgrade my ageing pre-RTM copy!

Windows Home Server

1 Comments
Filed under:
Windows Server 2008 RC0 and Windows Vista SP1 beta were released on Connect last night. Windows Server 2008 RC0 is available on MSDN/TechNet as well.

Well, I've been very busy wrapping up the first drafts for all the chapters for the upcoming Professional IIS 7.0 book (as well as taking part in a couple of Tech.Ed events), so there's been very little blogwise.

However I noticed today the System Center Virtual Machine Manager (SCVMM) 2007 has RTMed according to Microsoft. So, we now have a new tool for managing virtual machines hosted on Virtual Server 2005 R2 SP1.

So, what's the point of getting SCVMM? Well, you can do a P2V (Physical to Virtual) conversion of a Windows Server 2003 SP1 machine without restarting the physical box, the management console is far superior to what Virtual Server itself offers, and you can import VMWare's VMDK files if you want.

But, but, but (there's always buts aren't there) - this version won't manage Windows Server 2008 Virtualisation (aka Viridian) machines. There'll be an updated version of SCVMM to do that. We still can't virtualise 64bit guests (e.g. Exchange 2007) due to the fact that we're still managing Virtual Server 2005.

So, nice looking GUI front-end that gives you much better managed of Virtual Server 2005. But I think a lot of people doing serious virtualisation are using VMWare's products (ESX) at the moment.

1 Comments
Filed under:

Having just deployed a test Operations Manager 2007 server at home, I wanted to publish the Web Console site externally, so I wouldn't have to continually TS into my box at home, and use the regular console.

My only problem is that I have a single public IP address, and because I'm only publishing services over HTTPS, I only have a single FQDN that I can use (I'm not willing to pay for a wildcard certificate). So each service that I'm publishing needs to exist as a folder(s) off the root of my published FQDN (assuming I don't want to use non-standard ports and avoid certificate errors). My current publishing setup looks like this:

Reverse Publishing with ISA Server 2006

Unfortunately the Operations Manager 2007 Web Console website isn't located in a directory, but rather in the root of its own website. Due to what appears to be some fancy javascript employed within the site, straight reverse publishing with link translation results in a non-usable site.

Whilst it is possible to configure individual link translation elements for publishing this website, I found an easier way to get this working.

Open IIS Manager on the Operations Manager server. Locate the current Operations Manager Web Console website and choose to create a new Virtual Directory. Create the alias as whatever directory you wish to use externally (I'm using OpsMgr) and point the source folder to be the same as the root folder for the current website (the default is C:\Program Files\System Center Operations Manager 2007\Web Console). Ensure that the virtual directory is marked as an Application Root (a small cog icon in IIS Manager):

Configuring IIS

Now you can configure a standard Web Site publishing rule in ISA Server 2006 to publish requests to https://yourexternalFQDN/OpsMgr to http://yourInternalOpsMgr:51908/OpsMgr and your Operations Manager web console is available for use. Because I'm also publishing OWA, my web listener uses ISA Server 2006 FBA. For the Operations Manager publishing rule, configure NTLM delegation, and your users will only need to logon once (to ISA Server) to get access to the console:

The published Operations Manager 2007 Web Console

Protocol Transition is a new feature in Windows Server 2003. The Kerberos implementation in Windows Active Directory domains provides the robustness of Kerberos whilst also obviating a number of the technical issues with non-Windows Kerberos implementations (platform infrastructure, ticket renewal, ticket proxy). However Kerberos has a downside – the need to get tickets from a KDC. In the IIS world, contacting a KDC simply isn’t a possible for many internet facing scenarios. Either the KDC is not exposed to internet facing clients (blocked by a firewall), or (more commonly) a KDC is simply not locatable because the necessary SRV (service records) are only located on internal DNS servers not available to the public:

Kerberos problems for internet clients

In the diagram above '1' shows a typical problem with a non-Domain (i.e. public) client attempting to locate a KDC for a domain that a web server is in. Typically public DNS servers do not contain the necessary service records that tell a client where the KDC can be located.

Even if the client is able to locate a KDC, the '2' indicates the next hurdle - clients on the internet can not connect to the KDC to get the necessary tickets to use Kerberos Authentication to authenticate to the web server because a firewall or similar edge device blocks internet clients from directly contacting domain controllers.

Aside from an internet connection client establishing a VPN to your internal network, there are any number of technologies that allow such clients to authenticate to a web server, from Digest Authentication through to Client Authentication Certificates. However after a client has authenticated to a web server using such a technology, it can then become difficult to pass those credentials through to a backend server (Basic Authentication is an exception because it provides the web server with the user's username and password, allowing direct impersonation via LogonUser however a compromised web server in this case would allow a malicious attacker to harvest a rich database of users and their passwords).

Windows Server 2003 introduces two new technologies and two new services (not Windows Services in the sense of daemons, but services that can be leveraged) that address some of the authentication issues mentioned.

Windows Server 2003 introduces:

·         Protocol Transition – this allows a non-Kerberos Authentication mechanism to be used to authenticate to IIS, whilst IIS can use Kerberos to connect to a backend server.

·         Constrained Delegation – this allows Administrators to constrain what backend services IIS can connect to.

To facilitate these two pieces of functionality, Windows Server 2003 introduces two services that can be leveraged by your applications and by IIS:

·         Services For User to Self (S4U2S)

·         Services for User to Proxy (S4U2P)

Services for User to Self (S4USelf) and Services for User to Proxy (S4U Proxy)

Firstly let's address the necessary steps to configure Protocol Transition and Constrained Delegation in an IIS situation, and then we'll look through the actual implementation details that show how this all hangs together.

If you missed the previous parts in the series or need a refresher then you can find them at:

IIS and Kerberos Part 1 - What is Kerberos and how does it work?

IIS and Kerberos Part 2 - What are Service Principal Names?

IIS and Kerberos Part 3 -  A simple scenario

IIS and Kerberos Part 4 - A simple delegation scenario

Configuring Active Directory

To support Protocol Transition you need to be running Windows Server 2003 for your IIS server and you need to have a Windows Server 2003 functional level domain (this requires all DCs in your domain to be running Windows Server 2003. To raise the Domain Functional level, use Active Directory Domains and Trusts MMC Snapin).

To configure Active Directory using the GUI (how to configure this all programmatically is explained later) open Active Directory Users and Computers MMC Snapin.

Assuming that you are not using a custom user account for your web application pool, locate your IIS server’s computer object and bring up that machine’s properties. On the delegation tab choose both:

·         Trust this computer for delegation to specified services only  and

·         Use any authentication protocol

Configuring Active Directory

You will now need to specify the backend services that the IIS machine is permitted to delegate to. Click the "add" button and then the "users and computers" button. Enter the computer or user account that the backend service is running under (for example, if you are running SQL Server under a LocalSystem account on a remote server, enter the SQL Server's computer account. If you are running SQL Server under a custom user account, enter that user's account). A list of Service Principal Names (SPNs) registered under that account is displayed. Select the SPN that you wish IIS to be able to connect to. If you are not familiar with SPNs, or need to configure an additional SPN, then see Part 1 (Kerberos fundamentals) and Part 2 (Service Principal Names) in this series.

Add Service Principal Names

If you are running your web application pool under a custom user account, then perform the above steps for the user account, not the IIS server’s computer account.

Configuring IIS

There isn’t much to configure on the IIS box beyond what needs to be configured for straight Kerberos Delegation (see Part 3 in the series). The main difference is that the user account running the web application pool for your website needs to have SeTCBPrivilege (Act as Part of the Operating System) and SeImpersonateUser (Impersonate a User After Authentication). Your options involve either running your web application pool as LocalSystem, or granting a custom account these NT User Rights. These use rights can be assigned by editing the local security policy (start -> Run -> secpol.msc). Alternatively Group Policy can also be used.

Note: running a web application pool with any account that has SeTCBPrivilege is a security risk. Any potential compromise of your web application will result in the attacker having full privileges over your IIS server.

And that's the entire configuration that's required to support Protocol Transition natively on IIS to a backend server. Now you can authenticate to IIS using alternate authentication mechanisms, and still delegate to a backend service similar to how we configured IIS and SQL Server in Part 4 – A simple delegation scenario.

For more information on how this is actually implemented in Windows Server 2003, read on.

Services For User to Self

Services For User to Self (S4U2S) provides the ability for a service running on a server to get a Kerberos ticket for an end client, even if the end client did not authenticate using Kerberos. Instead of the service providing the end user’s TGT (Ticket Granting Ticket) or end user’s credentials (username/password) to the KDC, the service provides its own credentials.

The resulting token that is returned depends on what NT User Rights the service account has. If the service has SeTCBPrivilege (Act as Part of the Operating System) then the token returned is an Impersonation token. If the service does not have this privilege, the token is an Identification token.  (TCB in SeTCBPrivilege stands for Trusted Computing Base a.k.a. the trusted kernel of the operating system). An Identification token can be used to determine a user’s group membership and validate the user’s access to resources. An Impersonation token further allows access to kernel mode objects using the end user’s identity.

 In order to actually use an Impersonation token to impersonate an end user, the service must also have the SeImpersonatePrivilege (Impersonate a Client After Authentication). Attempting to impersonate an end user without this user right results in the Impersonation token being downgraded to an Identification token.

If the service has both SeTCBPrivilege and SeImpersonatePrivilege then the service can use the token to directly impersonate the end user (on the local system) without having the end user’s TGT or credentials. A service can do this by either directly calling LsaLogonUser (or the constructor for the .NET WindowsIdentity class that wraps LsaLogonUser), or by relying on the Kerberos SSP provided by Windows Server 2003.

Services for User to Self (S4U2S) help provide for Protocol Transition – the ability to perform Kerberos Authentication even though the end user has authenticated to our IIS server using some other protocol.

Services for User to Proxy

Services for User To Proxy (S4UTP) provides the ability for a service to obtain a Kerberos ticket on behalf of an end user that can be used to authenticate to a remote service. Whilst S4U2S discussed above allows a service to obtain a Kerberos Ticket, the Forwardable flag is not set, which does not permit the service to authenticate to remote services (e.g. a backend database) on behalf of the end user.

In order for the Kerberos ticket to be forwardable (i.e. used by the service to connect to a backend service such as a database), delegation must be enabled in Active Directory.

The actual series of events looks like the following:

Constrained Delegation

In order for the service to be able to get forwardable tickets on an end user's behalf, a flag needs to be set on the service account’s userAccountControl property in Active Directory: TrustedToAuthenticateForDelegation (T2A4D). This flag has the value 0x1000000 (or 16777216 in decimal).

Note: if the end user had authenticated initially using Kerberos, then this particular flag doesn’t need to be set. We use it only when we are using Protocol Transition and we need to get forwardable tickets.

The T2A4D is new in Windows Server 2003 Active Directory domains. In a Windows 2000 functional level domain, a different flag: TrustedForDelegation (with a value of 0x80000 or 524288 in decimal) is set. This corresponds to the "Trust this computer for delegation to any service (Kerberos Only)" option in a Windows Server 2003 domain (see below). This was the only way to configure delegation in a Windows Server 2000 domain, and is known as "unconstrained delegation".

Unconstrained Delegation

To set the T2A4D flag we choose the “Trust this computer for delegation to specific services only -> Use Any Authentication Protocol”. This means that a client can use any Authentication protocol to authenticate to our service, but then we’ll be using Protocol Transition and S4U2P to get Kerberos tickets to authenticate to these backend services.

The other Active Directory property we need to be aware of is the msAllowedToDelegateTo property. When we add a list of remote services that the service account is permitted to delegate to we populate the msAllowedToDelegateTo property of the service account.  The msAllowedToDelegateTo property is populated whenever we use Constrained Delegation. If we choose the "Keberos Only" option, then only this property is populated. If we choose the "Use Any Authentication Protocol" then both the T2A4D userAccountControl flag is set and the msAllowedToDelegateTo field is set.

msAllowToDelegateTo property in action

userAccountControl - TrustedToDelegate

When set, unconstrained delegation is permitted for the service. The service can connect to any backend service as the end user. However protocol transition is not supported – the end user must have authenticated using Kerberos.

userAccountControl - TrustedToAuthenticateForDelegation

When set, the service may use protocol transition to connect to backend services listed in msDS-allowedToDelegateTo. This flag is set when you configure “Use any authentication protocol”)

msDS-AllowedToDelegateTo

When using constrained delegation (either “Kerberos Only”, or “Use Any Authentication Protocol”) this property lists the backend services that the service can connect to.

SeTCBPrivilege

The service must have this privilege to get Impersonation tokens

SeImpersonateUser

The service must have this privilege to be able to use the Impersonation token to impersonate a user.

Now, some gotchas that you need to be aware of. As mentioned earlier but worth repeating;

  • Protocol Transition relies on using constrained delegation. You can’t use Protocol Transition in conjunction with unconstrained delegation.
  • Once you have used constrained delegation to hop to a server, all subsequent hops must also use constrained delegation. In the following example, connecting from IIS to SQL Server used Constrained Delegation. In order for SQL Server to connect to additional backend servers the msDS-AllowedToDelegateTo property in Active Directory must be explicitly configured to allow SQL Server to do so.
  • When using constrained delegation all servers in the delegation chain must be in the same domain. It is not sufficient that a domain or forest trust exists between the servers.

And that concludes this rather long Part 5. If you’re still reading this: thankyou. Please feel free to leave a comment if you feel that something was unclear or incomplete. If you feel something was incorrect, then please email me so I can avoid public embarrassment :-)

In Part 6 we’ll look at using Kerberos authentication across more than a single Active Directory forest. Subsequent parts will look at configuring additional services (such as ISA Server and Sharepoint). If there are specific scenarios you’d like me to cover, please drop me a line.

Edit: Due to blog spam - comments are disabled. Contact me through the contact form

15 Comments
Filed under: ,

Virtual Server 2005 R2 SP1 (isn't that a mouthful?) is now available for free download in both 32bit (x86) and 64bit (x64) versions.

New features include:

  • PXE boot support for guest OSes
  • A command line tool for mounting VHDs as virtual drives on other OSes
  • Support for Volume Shadow Copy snapshots as a backup mechanism
  • Virtual Server can run more than 64 guest OSes on x64 platforms
  • 128GB is now the default size for expanding disks

But, still not 64 bit guest support (thay won't be available until Longhorn Server Virtualisation codename Viridian ships next year)

Mitch talks about the problems encountered when SysAdmins struggle to provision the infrastructure necessary to support developers - and I entirely see his point-of-view.

In my opinion, it is rare for an organisation that has SysAdmins that are already skilled up on the issues required to deploy new technologies when the development teams are cranking out brand new products. Most SysAdmins are busy keeping the existing infrastructure working properly and trying to optimise it - not out learning new technologies that aren't being used yet. That's not necessarily a fault of the IT staff (though I think it would be much better if more IT staff showed initiative and self-drive) but sometimes the culture of the organisation.

on the other hand, most developers are woefully equipped in terms of understanding the implications of what they are doing. The last thing an enterprise needs is rogue DHCP servers being setup that network build/provisioning systems, or rogue IIS boxes that can be compromised (NIMDA/Code Red anyone), or Exchange servers that become open relays. I've seen first hand, developers struggle for weeks to get Exchange, MOSS, DCs etc all functioning well together. And a typical solution to solving a problem is to open access to everyone, not follow best practices. In general developers seem to care about getting the thing working to spec - not worry to much about the side effects!

So how do we address the issue? In two ways I think.

1. Multiple Environments
Firstly we can create various environments within the organisation. The less impact that the environment has on production, the more control can be handed to developers and end users. In the most extreme case, you can have a completely segmented development environment, where developers can install whatever the want, configure it exactly how they want, and reconfigure it without needing to tell anyone else.

As we move closer to larger impacts on the production network, we need to increase the level of change control measures and the involvement of other parts of the business (namely the sys admins, the network guys, the security team and so on). And when we finally come to deploy the application into production, we have the full set of change control procedures (and division of responsibility) that applies to everyone else (it's not just developers that have to jump through hoops to get Active Directory changed - all the rest of the IT staff have to as well!). This change control process means that all relevant stakeholders know what is happening in the production environment, and that the production environment moves from one known state, to another known state.

2. Better Project Management (which is a prerequisite for agile IT)
good project managers know when to engage other parts of the IT organisation. This allows SysAdmins to research the product and its optimal configuration, work how how to provision the product, and even get a delegation tool in place to allow developers to manage select parts of the infrastructure. The project plan should look something like:

Good project management

Unfortunately, in a lot of cases, it seems to look like this:

Bad project management

And that type of poor project planning results in low agility IT.

(Comments Off)
Filed under:

Previously I talked about running lots of virtual machines on a laptop (I can run about six on my Portege M400). I have some tips on overcoming some of the hurdles I have run into. I've sort of mentioned disk i/o in the previous post, so I won't dwell on that. The issue of this post is overall storage.

Maintaining a VM library takes up ever increasing amounts of storage - both for the VMs, and additional sets of installation files. Recent additions to my library have included Longhorn Server (both 32bit and 64bit) in various flavours (DCs, IIS boxes, server core etc), Exchange 2007 VMs and even an older dev environment (to support VS.NET 2003).

To help cater for this , I acquired a new Seagate Momentus 7200 RPM, 160GB SATA disk to add to the existing 100GB disk. In the first shot it is now safely housed in the Ultra Slim Select Bay adapter replacing a previous 80GB secondary disk.

The new disk in a second bay

With the addition of some additional 160 GB external disks (bus powered 2.5" laptop disks), we now have 580GB of storage available in the tablet PC.

Total storage - 580GB!

Not bad for a small 12" machine! Now I realise I could just lug one 500GB 3.5" disk around, but the enclosures are much heavier and they do require an external power supply as well. This setup is much lighter, but yields a relatively similar amount of storage space.

Portege M400 with two external disks

(the book to the left of shot is Raymond Chen's The Old New Thing, which was my other purchase today).

Now, if you're just using a desktop, storage is easy to come buy. For home, I just bought 4 x 500GB SATA II disks (at A$150 each, it's cheaper than ever to acquire a mass of storage). Two terabytes of storage (or 1.5 TB in RAID 5) for ~A$600. That's a lot of VMs!

3 Comments
Filed under:

Andrew Coates already has a review of his Microsoft Wireless Presenter Mouse 8000, so I'll add to his comments in my review.

I've been using it for about a week now, and have formed the following impressions:

The Good

  • It seems to work well with your inbuilt bluetooth chip (if you have one, e.g. in your laptop). The previous Microsoft Bluetooth Mouse (I think it was the Intellimouse Explorer for Bluetooth) pretty much insisted on you using the supplied dongle, and using the supplied bluetooth software. The dongle defeated the purpose of having an inbuilt bluetooth chip, and the supplied software didn't work with some other BT peripherals I had. So, the experience here was much. much better. It even works well with the Toshiba Bluetooth Stack (which is probably the worst in the world). Additionally because it uses the inbuilt bluetooth chip, there's no need to carry a receiver around (though one is supplied if you need it).
  • It's small (this could also be a negative) - smaller than the Logitech VX Revolution (see pictures below)
  • Like most of Microsoft's other mouses, it symmetrical, so left handed users will have no problems using it.
  • It has the additional presenter buttons on the bottom (back/forward, blank screen, volume up/down, as well as the laser pointer)
  • It comes with a hard shell case to store the mouse (and receiver) in. I don't use it, but others might find it useful to protect their A$150 investment.

Microsoft Wireless Presenter 8000 compared to other mouses

Sizes: The Microsoft Wireless Presenter Mouse 8000 (far left) compared to (from left to right): Logitech VX Revolution, Logitech MX440, Logitech MX1000, Logitech Dual Mouseman

The Bad (or perhaps "Not So Good")

  • The Intellipoint software insists on uninstalling other 3rd party mouse software (e.g. you can't use Logitech Setpoint along with the Intellipoint software)
  • The Intellipoint software doesn't seem to cope too well if you put your laptop into hibernate, and the underlying BT stack doesn't reinitialise quickly enough. Instead, Intellipoint crashes when you resume. In Vista, it's a simple click to restart the software, but you'll need to use your touchpad (or another mouse), or keyboard navigation to get to the button to restart Intellipoint
  • The mouse is small - and the shape doesn't support the middle of your hand as well as the other mouses (see below). I find that my hand feels stiff and sore after a few hours of use. I might get used to holding the mouse over time though.
  • The vertical scroll (at least in Vista) varies widely between applications - in IE a single "tick" scrolls much further than in Word. The Intellipoint software doesn't have an option to scroll "x" lines (or "x" pages) per "tick", just a slider from "scroll a little" to "scroll a lot". Unfortunately due to the inconsistency between applications, this means you need to adjust your scrolling behaviour for each application.
  • The scroll wheel doesn't have much tactile feedback/well defined "ticks" for scrolling (unlike other mouses), making it difficult to control the amount you are scrolling in applications where the scrolling is quite sensitive. The smooth scrolling wheel is handy if you are scrolling long distances, but not so useful if you just want to move a page at a time.
  • Whilst the mouse caters for both right-handed and left-handed users, I prefer the comfort of Logitech mouses that are geared towards right-handed users (with a groove for your thumb cut out of the mouse - see picture below)
  • The mouse requires two AAA batteries (the Logitech VX Revolution requires just one AA battery) making it a bit heavier than the Logitech. You also have to carry two spare batteries in case yours die "on the road"
  • The Logitech mouse automatically switches "off" if you put the receiver back into the mouse (there's a small slot to store the receiver in). You also have the option of switching it off manually. The Microsoft 8000 has an on/off switch only, which you have to remember to toggle to turn the mouse off. There's also no battery life indicator on the mouse (the Logitech briefly indicates how much battery is left when you switch it on)

Hand support for Wireless 8000 Presenter Mouse

The two Logitech mouses on the right support the whole hand better than the Microsoft Wireless Presenter 8000 Mouse, which doesn't have an "as rounded" shape

Logitech Mouse with thumb groove

The Microsoft Mouse is suitable for use by both left handed and right handed users. However the Logitech VX Revolution is more comfortable (in my opinion) if you are right handed.

Final Words
I haven't decided whether to keep the Microsoft mouse long term. The presenter features are handy if you are presenting a lot with Powerpoint (or similar application) as it saves you having to carry around a separate presentation device. It is also the smallest notebook mouse I have (though not the lightest). However ergonomically and feature-wise, the Logitech VX Revolution is superior in my mind. The one thing that really lets the Microsoft Wireless Presenter Mouse 8000 down is the inconsistent scrolling speed in applications (combined with the lack of tactile tick feeback). It's made me abandon the use of the scroll wheel in Internet Explorer (in favour of the scroll bars) until I can figure out how best to configure the mouse's settings. That's a big downer IMHO.

27 Comments
Filed under:

Early Bird registration for Tech.Ed Australia closes 27th May (two weeks away). Tech.Ed Australia will be on the Gold Coast again this year (like 2005) from 7th-10th August. At this stage I'm not sure I can make it - hopefully I can get a speaking spot again this year, or maybe work will send me - I think my boss is reading this blog! :-)

I will be at Tech.Ed South East Asia, which will again be held at the KLCC in downtown Kuala Lumpur. Tech.Ed SEA will be held from 10th-13th September.

Tech.Ed is Microsoft's premier IT-Pro (and Developer) conference (alongside PDC, WinHEC etc). Whilst the US and European Tech.Ed events are huge (I was lucky enough to present at Tech.Ed in Boston last year), the other Tech.Ed events around the world are still well worth the cost of entry. Hopefully my attendance isn't going to scare you away - in fact I hope you'll come up and say "Hi" if you're reading this and will be attending.

 

(Comments Off)
Filed under:

In Windows XP (and earlier) it was relatively quick and easy to access the "Network Connections" folder from the Start menu. In Windows Vista I've seen users click on Start Orb -> Network -> Network and Sharing Center -> Manage Netwok Connections.

But there is a faster way - a short cut to get directly to the Network Connections virtual folder.

Start -> Run -> ncpa.cpl

takes you straight to the Network Connections virtual folder. You can create your own shortcut to ncpa.cpl and add it to your Start Menu for two-click access to this folder if you want.

I was asked recently by a colleague if a website defined in IIS could have multiple SSL certificates installed, so that the website would answer requests for https://www.abc.com as well as https://www.def.com without generating an error in the user's browser that the website's name didn't match the one in the certificate.

The simple answer to the question in the subject line, is that you can't install more than one certificate in IIS 5 and IIS 6. That doesn't mean that you can't solve the problem (read on for some solutions that might work for you).

IIS associates a certificate to be used with a website based on a property in the IIS Metabase called SSLCertHash. For each website there is space for a single SSLCertHash value to be set (see Figure 1)

SSL Certificate Hash property in IIS Metabase

Figure 1

The actual value that's stored in this SSLCertHash field corresponds to the server authentication certificate's "thumbprint" property that you can view using the MMC (after adding the Certificates snapin).  See Figure 2 below:

Certificate Thumbprint

Figure 2

 So, how do we solve the problem of having two FQDNs serve the same web content over SSL/TLS without causing a warning error message in the client's browser? Well, here are some options:

  1. Create two websites, and point the home directory of each website to the same physical root folder on your server. Install one certificate into each website. This does require that you have two IP addresses (or run the websites on different ports)
  2. Use a certificate that has mulitple common names (see Figure 3 below)
  3. Use a wildcard certificate (that matches *.domain.tld)

Multiple CNs in a certificate

Figure 3

8 Comments
Filed under: ,

Unfortunately if you have a new Vista PC, and you try to use the web enrollment pages (certsrv) hosted on a Windows Server 2000 Certificate Authority (CA) or a Windows Server 2003 CA, you won't be able to enrol for a certificate (indeed if you're using Windows Server 2003 SP2 you get a message to that effect).

If you are in a domain environment, then you may be able to get around some certificate issuance via user or machine auto-enrollment. Otherwise you need to perform manual certificate issuance. Alternatively you can setup a Longhorn Server Beta 3 CA, and use the webpages from that installation to allow web enrollment for Vista machines.

Hardly an ideal situation if you ask me!

More information can be found on Microsoft's website.

Absolutely (as long as it's x64, not ia64). This topic came up at work, and there seemed to be a fair bit of confusion over what's possible and what's not. Using VMWare Server (or a Workstation version that supports 64bit guests) you can run a x64 Guest OS even though the host OS is still 32 bit. Unfortunately, neither Virtual PC nor Virtual Server 2005 R2 supports 64bit guests.

That means you can run Windows Server 2003 x64 with Exchange 2007 (which is 64bit only, except the trial edition) on Windows XP/Vista 32bit. If you're consultant like me, that spends a lot of time in other people's offices, it means you can use a laptop with a Core 2 Duo CPU (provided it also supports Intel VT - i.e. not T5200/T550) and run 64bit guest machines.

VMWare has a free tool you can download to check whether your machine can run 64bit guests.

One of the big IIS secrets that we've all been keeping under wraps is the new FTP Server that will be available for Longhorn Server. The two features that most interest me are:

  1. FTPS (FTP over SSL/TLS) support. Finally a secure publishing solution. From what I remember, the entire session can be encrypted, or just the credentials
  2. Support for multiple FTP sites on a single IP address/port (similar to "Host" headers in the HTTP world). There is no settled specification for this functionality, but the developer in the IIS PG responsible for this functionality (not sure if he wants to be exposed) is working on getting an RFC finalised. Until then, there is a platform agnostic mechanism that may (or may not) be the final ratified standard available

There's a bunch of other nice features available as well (such as synchronising website and ftp site passwords/publishing, making it easy to setup an FTP site to allow publishing to a website). You can get an overview of the features, and download the FTP Server beta from the IIS Website

The only downside to this new FTP server is that it won't ship "in box" (it didn't make the cut off date). If you install Longhorn Server from media, you'll get the old IIS 6.0 FTP Server. You'll need to download the new FTP server as an addon from the Microsoft website. Bummer.