Pages

Wednesday, January 30, 2013

I was recently asked by a colleague to assist with moving a Windows Server 2008 R2 NPS server providing RADIUS services for a Cisco 4400 series Wireless LAN Controller to a newer redundant design. The redundancy was provided by 2 Windows Server 2012 NPS servers configured in 2 different sites that the Wireless LAN Controller would attempt to authenticate one after another in order and finally fall back to local authentication if both NPS servers did not response. The document I was provided was the following:

One of the first items I noticed from this document and logging onto the existing Windows Server 2008 R2 server was that it was a Domain Controller with the Active Directory Certificate Services role installed onto it:

I was never a strong supporter of collocating CA services on a domain controller because of the following:

You need to remove the CA services if you wanted to demote the Domain Controller.

Not a requirement for Windows Server 2008 but back in the Windows 2003 Server days, the server you migrate the CA services to need to be the same name as the original so if your original CA server was DC01, the new one would also have to be DC01.

With the reasons why I do not support strictly following the Cisco guide and issuing a Domain Controller template certificate to use with PEAP, the following will demonstrate how to use a CA located on a different server for wireless authentication.

Most administrators would know that you can continue to configure a NPS policy with Microsoft: Protected EAP (PEAP):

… without a certificate but if you attempt to click on the Edit button, you will be presented with the following:

A certificate could not be found that can be used with this Extensible Authentication Protocol.

If this was a domain controller, one of the solutions is to directly install CA on this NPS server and issue a Domain Controller template certificate for authentication as shown in the Cisco document. An alternative solution to this if you don’t want to install CA services on this server is to log onto an existing CA server, open the Certificate Authority MMC in the Administrator Tools, and navigate to the Certificate Templates:

Right click on the Certificate Templates folder and click on the Manage button:

The template we’re interested in is the RAS and IAS Server template:

Proceed with right clicking on the certificate template and click on Duplicate Template:

Whether you select Windows Server 2003 Enterprise or Windows Server 2008 Enterprise doesn’t matter unless you’re using an older CA (i.e. don’t select 2008 if you’re using this on a 2003 CA server) but for this example, I will select the latter:

The properties of the new duplicated will launch:

Name the template with a name of your choice, modify the Validity period if you prefer it to be longer than the defaults and enable settings such as Publish certificate in Active Directory if you like:

Navigate to the Security tab and select Authenticated Users:

Check the Enroll checkbox and click OK:

With the new certificate template created, open the Certificate Authority MMC window:

Right click on the Certificate Templates folder, select New and click on Certificate Template to Issue:

Select the template that was created earlier:

Notice how the new template is now listed:

Open the Local Computer certificate store of the NPS server and navigate to the Personal folder:

Right click on the Personal folder, select All Tasks, Request New Certificate…:

Click Next:

… then Next:

Select the new certificate template (NPS – RAS and IAS Server):

Clicking on the Enroll button will begin the process:

Note how a new certificate for Server Authentication and Client Authentication has been issued in the Personal store:

Now when you attempt to Edit the Microsoft: Protected EAP (PEAP)Authentication Method:

… the following window will be presented for you to select the certificate:

Hope this helps anyone looking for instructions on how to use a CA that is not directly installed onto the NPS server.

Tuesday, January 29, 2013

I was asked by a client today to look into an issue with their resource mailboxes that stopped auto accepting calendar booking requests from users a month ago. After carefully reviewing the settings for the resource mailboxes, creating new ones to test and also moving arbitration mailboxes to other mailbox stores without any luck, I finally stopped and thought that maybe I should check the Microsoft Exchange Mailbox Assistants (MSExchangeMailboxAssistants.exe) service because the description clearly states the following: Performs background processing of mailboxes in the Exchange store.

To make a long story short, the service was indeed stopped:

Once the service was restarted, all of the queued up resource mailbox calendar bookings began to get processed. I’m writing this blog post because while performing searches on the internet, none of the first 5 results I searched for pointed towards checking the service.