Background

I recently went through the motions of setting up Active Directory Federation Services (ADFS v2) for Kreisler to allow us to begin using Office 365 with federated authentication. We have some other potential uses for federation coming later on as well. This post is not meant to dive into how we set everything up because for the most part it was relatively simple. The Office 365 documentation is very helpful and if you follow it step by step you can accomplish what you want. However, a few parts in particular were confusing for me and took a couple of tries to get right. They are:

1. SSL Requirements
2. Domain Name Forwarding and Requirements

For those not familiar ADFS does require SSL certificates and in a production environment you need to purchase at least 1 certificate and possibly 2 depending on how security conscious you are. In addition if your network is similar to ours you need to work some DNS trickery to get the desired end-user behavior.

Our ADFS Design

We don't have a large user base so having a large server farm is not required and even for small businesses (400 or less employees) this farm will support the load just fine! Our farm is composed of the following:

1. One ADFS Server
2. One ADFS Proxy

It should be noted that we decided to utilize our existing MSSQL infrastructure to host the ADFS databases and not the Windows Internal Database.

SSL for ADFS

So the documentation in Office 365 in regards to the SSL setup is somewhat confusing. Here is what it boils down to. You MUST generate the initial certificate request from your ADFS Server, even if this server is not going to be publicly facing! In addition for each certificate you generate make sure the Common Name is identical for each certificate you request. In our design we requested a single certificate. Once you get the certificate loaded life should be good, but then you have to install the Proxy. You have two options here:

1. Export the certificate from the ADFS Server, or 
2. Request a new certificate

Security Experts will say to use number two because if the public facing certificate is compromised so is your internal certificate. Then again if you don't have hundreds to throw at SSL certificates number one becomes very appetizing. You can follow standard IIS help and instructions for exporting and importing a certificate from one server to another. Once we got passed the certificate problems we were able to get the system up and running properly.

DNS for ADFS

The idea with ADFS in a Server and Proxy configuration is that internal clients will utilize Windows Integrated Authentication to login to the federation server while external clients will be redirected to a form to attempt to login. Here's the problem with this:

1. The Common Name from your SSL certificate should match the publicly accessible DNS A/AAAA record for your Federation Service. 
2. The proxy by default receives all public requests, which is normal. 
3. Internal users will still make a call to "fs.mydomain.com" which points them to the Proxy as opposed to the Server, this causes internal users to have to login.

The documentation again is somewhat light in this area. There is lots of talk about setting up HOST file definitions, which if you ask me is somewhat archaic. We took a different approach, DNS. We setup a new forward lookup zone in our Active Directory enabled DNS servers for "fs.mydomain.com" which meant that the server now becomes authoritative for our Federation Services sub-domain, so any internal requests will now get processes by our internal DNS servers and not get forwarded to external servers. The last step was to simply create an A/AAAA record for ".fs.mydomain.com" to point to the Federation Server. Now any request for "fs.mydomain.com" gets sent to our Federation Server.

Ta-Da

Again, these are just some of the larger problems we had getting things up and running but it appears to be working like a champ at this point. I'll have another post in the future to help customize your Federation Forms Login page to brand it and customize the behavior.

-Brent

We ran into an issue recently where changes were made to a GPO policy at the wrong Organizational Unit (OU) level in the domain.  As part of reverting those changes however we discovered that the Link Enabled and Enforced options were BOTH checked.  It's been a while since we have played with a lot of these settings so I wanted to document them here so I could remember them in the future.

What is Link Enabled?

Link Enabled in its simplest form tells the system to apply the policy to the container(s) both peer and children at the current level of the tree.  If the policy is link enabled essentially it will be applied to the containers below the policy.  For instance if the Default Domain Policy is Link Enabled it gets applied to all objects within the domain.

What is Enforced?

Enforced still applies the settings to the container(s) at the peer and child level, however the difference is that the settings are ALWAYS applied!  In other words if you have two policy files at the same level in the tree an Enforce policy will override any settings in the other policy.  It is always enforced!

Hopefully this helps others as it's one of those things that if you don't work with GPO's too often you can easily forget.

-Brent

If you have ever been to an airport, hotel or other public place that offers Wi-Fi service you may have also noticed that some require you to pay for access and others just require you to register.  Depending on your business this can be a good thing as it provides a source for extra revenue, or maybe just more insight into your visitors and how they access the hotspot.  On the other hand it does provide a little bit more security so you don’t end up with leaches on the network.

There are many vendors of systems and access points to provide this type of service, however I stumbled across a Microsoft document that provides information to setup and configure this type of service using existing Windows based servers.  It specifically targets Windows 2003 and Windows XP, but I am sure that is an updated version for 2008 and Vista.  On the other hand it is important to note that it does not contain any information about supporting Apple or Linux based machines.  Even if this solution does not work for you it may be worth the time to read just to understand some concepts and background on how a system to handle this could be implemented.

So without further ado the document can be found here.  If you have used this system or something similar please post your experience and comment on the system as I would be curious how it worked out for you.

-Brent

I was recently searching for links to many of the Microsoft Posters that are available in PDF format.  These posters are usually very large and can be printed out either on a printer or taken to a store like Kinko's or the UPS Store to be printed on poster paper.  This list will change or get added to as I find new posters or the links change.

Posters:

1. Exchange 2007 Component Architecture
2. Windows Server 2008 Components
3. TechNet Active Directory Jigsaw
4. Windows Server 2008 Active Directory Components
5. .NET 3.5 Namespace Poster

Again, most of these posters are meant for printing on paper large than 8.5x11.

-Brent

When using Windows XP SP3 with remote desktop on a Windows Vista or Server 2008 computer that requires NLA or Network Level Authentication you might run into the following error:

"The remote computer requires Network Level Authentication, which your computer does not support. For assistance, contact your system administrator or technical support."

The problem arises because the Security Provider in Windows XP designed to handle NLA is turned off by default. Don't ask me why. The provider is called "CredSSP" and according to Microsoft here is what it does:

"CredSSP is a new Security Service Provider (SSP) that is available in Windows XP SP3 by using the Security Service Provider Interface (SSPI). CredSSP enables a program to use client-side SSP to delegate user credentials from the client computer to the target server. (The target server is accessed by using server-side SSP). Windows XP SP3 involves only the client-side SSP implementation. The client-side SSP implementation is currently being used by Remote Desktop Protocol (RDP) 6.1 Terminal Services (TS). However, the client-side SSP implementation can be used by any third-party program that is willing to use the client-side SSP to interact with programs that are running server-side SSP implementations in Windows Vista or in Windows Server 2008."

However, the good news is Microsoft also provides a very detailed process on how to turn on CredSSP. I have provided a link to the KB article that describes how to turn on CredSSP. Follow the process under "How to Turn on CredSSP" and the message should be resolved.

http://support.microsoft.com/kb/951608

-Brent

NOTE: When referring to the PDC or Primary Domain Controller I am referring to the PDC Emulator Master that is a member of the FSMO Roles. The original concept of a PDC was discontinued prior to Windows 2000's release

I ran across this problem at home, where I have a Hyper-V server that runs all of my other servers, one of which is our home Domain Controller. It is also the Primary Domain Controller which means that by default it provides NTP and Time Synchronization services for the rest of the Domain, and in some cases the network. By default when you setup a new domain the NTP Service is installed and configured. If for some reason this is not the case see the following TechNet article:

http://technet.microsoft.com/en-us/library/cc786897.aspx

If you are not familiar with Hyper-V you should know that Hyper-V just like VMWare installed "Integration" or "Client" tools, which is really just a fancy term for Drivers and Services that enhance the client-to-host communications. Typically as part of these tools the time service for the Client Server will synchronize itself with the host machine, primarily because the host machine has the Motherboard which has the CMOS Battery that allow the computer to keep time. Again, this is a great idea; otherwise your clients might get out of whack.

The problem comes in when your Primary Domain Controller (PDC) which is providing time service to client machines is on the same domain as the host computer that is not a domain controller. The problem is that the time service continues to synchronize the host machine with the client, but in reality the host should be getting its time information from the PDC. The PDC in turn should synchronize with an external NTP Server or Pool. (Read: http://en.wikipedia.org/wiki/Primary_Domain_Controller).

So, over time the clock of both machines either speeds up or slows down, but either way does not keep proper time. Eventually this causes major problems, especially for laptops that travel and instead try to sync with another time server as a last resort, because once you bring it back on the domain and it is outside of the 10 minute difference window it stops all communication.

My Fix:

I actually have two. The first tells the host machine to look at an NTP Pool and not talk to the Domain to get time information. The second disables the Hyper-V Time Synchronization service, there-by allowing the virtual machine to look to an external NTP pool and get the right time. See below for the steps:

NOTE: These changes all take place from the host machine and not the virtual domain controller!

Fix 1 – Change NTP Settings:

NOTE: This solution modifies the registry. Make sure you know what you're doing, as no one else can be held responsible for killing YOUR computer.

• Stop the Time Service, you can use the Service Control Manager MMC Snap-In or at the cmd prompt: "net stop w32time"
• Open the registry editor, Start, Run, "regedit"
• Browse for the following key: "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters"
• Change the key "Type" from "NT5DS" to "NTP". If you do not have NT5DS I would stop now!
• By default Windows uses the Microsoft NTP Pool. For most this is fine. If you want to use a more open source and larger pool I suggest doing the following:
  • Change the key "NTP Server" to "north-america.pool.ntp.org" (See http://www.pool.ntp.org for other pools around the world)
  • Browse for the following key: "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config"
  • Change the key "AnnounceFlags" from "10" to "5"
• Close the registry editor
• Start the Time Service, you can again use the MMC Snap-In or "net start w32time"
• Normally it can take a while for the time to update itself, but we can override this and force it to run. Do the following:
  • From the cmd prompt: "w32tm /resync /rediscover"
  • If it fails to sync the first time run it again, I have had problems where this sometimes fails the first time.

Fix 2 – Disable Integration Service Time Settings:

1. Open the Hyper-V MMC Snap-In
2. Select the Virtual Machine running your Active Directory
3. Right-Click on the machine and select "Settings"
4. Under "Management" select "Integration Services"
5. Un-Check Time Synchronization

So from the steps above the obvious choice should be Fix 2, its much simpler and you don't have to deal with the registry or the time service. Just remember that the virtual machine by default will not have a battery to keep track of the time. So if you take a DC offline for a day or two, the clock will be totally off, because you have disabled the time synchronization service. Lastly, if you have multiple virtual domain controllers on different host machines you only need to make the change to the domain controller that serves as the PDC Emulator, because everything else will flow downhill and get the proper time.

-Brent

As many people have found out over the past couple of months Microsoft has released the newest version of the Remote Desktop Client. The current version is 6.1. However, as many more of you have found out, the 6.1 client is not supported or released for Windows Server 2003. For many users and admins this is not an issue, but for those of use using Terminal Servers 2008 on a Windows Server 2008 box it raises a few problems. The biggest problem is that the 6.1 client is required to utilize RemoteApps (Similar to Citrix). For common user use this is not a big issue, however for administrative and testing purposes it can be a problem.

The 6.1 RDC is available for the following systems:

1. Windows Server 2008
2. Windows Vista SP1
3. Windows XP SP3

I have been able to find a solution, while not support or sanctioned by Microsoft it seems to do the trick. After users complained (and rightly so) about not being able to get the 6.1 client for Windows XP SP2 Microsoft released a Hotfix to allow those users to install and use it. Personally I recommend upgrading to SP3 as it is pretty solid and stable. I have not had a lot of users experiencing problems with it. So to install the RDC 6.1 for Windows Server 2003 do the following:

1. Visit: http://www.microsoft.com/downloads/details.aspx?FamilyId=6E1EC93D-BDBD-4983-92F7-479E088570AD&displaylang=en
2. Download the XP SP2 Client
3. Once Downloaded the application needs to be run in XP SP2 compatibility mode
   1. Right-Click the installer
   2. Select Properties
   3. Check the "Enable Compatibility box"
   4. Select "Windows XP"
   5. Apply and Close
4. Run the installer – follow the prompts and complete the installation

Ta-da RDC 6.1 for Windows Server 2003

This applies to IIS 6.0 and not 7.0 that I am aware of.  I will see if this has been handled differently in

IIS 7.0 later.

I found a few good resources while doing this research today.  This is a long standing problem.  This post provides resources and links to help solve the problem.

A typical scenario looks like this:

You have a single server with many websites and you need to use a certificate for SSL traffic on two of the five websites.  You do not need to use SSL at all on the remaining sites.

Solution:

You need to use a wild card certificate, assuming that all of the sites reside in the same domain space.  Just for clarification a wildcard certificate certifies a domain namespace, like www.brentpabst.com or www.microsoft.com.  Anything that exists as a domain.  What this does in essence is certify that *.brentpabst.com is OK.  So if you have any number of levels of sub-domains you could, in theory, install this certificate and it would be valid.  I found both a MSDN and a link to the Singapore .NET User's Group on the subject.

Microsoft TechNet: http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/596b9108-b1a7-494d-885d-f8941b07554c.mspx?mfr=true

Muang's Blog: http://sgdotnet.org/blogs/maungmaung/archive/2007/01/22/Multiple-_2800_SSL_2900_-Web-Sites-in-IIS-_2800_Part-2_2900_.aspx

If you have not done so already and work with IIS 6.0 in most of your day to day work you would do well to have the IIS 6.0 Resource Kit.  You can download it here.  In general as a SysAdmin or Engineer I also recommend having the Windows Server 2003 Administration Tool Pack.  These are all invaluable tools!

Hope it helps!