Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I am working on a Freeradius backed 802.1.x authentication infrastructure for our wireless clients. I am using a rather generic Freeradius configuration with EAP-PEAP. Our clients are predominantly Windows XP SP3 machines but a few Windows 7 32 and 64 bit laptops also exist. Our domain is at the Windows Server 2003 functional level. 802.1x authentication is working with manually configured test clients.

I want to create a GPO that autoconfigures our clients by 1) deploying the self-signed CA certificate to them as a Trusted Root Certificate, and 2) sets up our ESSID as a preferred network with the appropriate 802.1x configuration.

I am having no difficultly deploying the self-signed CA certificate to clients using a GPO. However, I cannot figure out how to configure the certificate as a Trusted Root Certificate in the GPO.

This is from the GPO settings found under Computer Configuration - Polices - Security Settings - Wireless Network (IEEE 802.11) Polices:

PEAP Properties


My self-signed CA certificate is not available in the selections under Trusted Root Certification Authorities. Trying to authenticate the client without my self-signed cert being trusted in the 802.1x PEAP settings fails due the "Validate server certificate" setting. And of course if I manually configure the client to trust my cert, the radius server's certificate can be properly validated and then 802.1x works.

My goal is to be able to assign a machine to OU where this GPO will be applied and all the resulting 802.1.x and CA settings will be made without me having to touch the client machine at all.

How can I build a GPO for 802.1x PEAP settings that will set clients to trust my self-signed CA certificate?

EDIT:

A Microsoft NPS or NAP server is not really an option for my organization at this point due to cost issues. The best way to describe our environment is a centralized location running our core services with two dozen remote sites connected via WAN links of varying speeds and reliability. We have a varying ability and success of exercising positive physical or policy control over these remote sites, hence they are my primary focus for both wireless and eventually wired 802.1x authentication. If we loose a WAN link (which happens not infrequently) I still need clients at remote sites to be able to get network access, thus necessitating a RADIUS server at most of these locations. A request for another dozen Window Servers will be denied.

Historically all of our Linux servers and network gear have been maintained as separate from our domain infrastructure. This means things like a split DNS scope with independent DNS services, independent authentication infrastructure and so-on. While I realize they're are some advantages to an domain integrated PKI infrastructure, I would need a good case as to why I should do it or or alternatively why I shouldn't use an independent PKI infrastructure.

share|improve this question

4 Answers 4

You must have the self signed certificate with only the public key install on the wireless client's "local computer" certificate trust list (CTL), not the "current user" CTL. Use mmc.exe and add the certificate snap-in and choose local computer.

share|improve this answer
up vote 1 down vote accepted

OK. Admittedly I am not a Microsoft or GPO expert by any means but this just seems weird.

This question seemed to have half the answer - the certificate needs to be available in the Trusted Root Certification Authorities on whatever domain controller gpmc is connecting to. That seems to make sense. However, even after installing the certificate on our domain controller it still was not an option that was available for selection if I ran gpmc on my workstation. On a lark, I logged into the domain controller in question and ran gpmc directly AND the certificate was available.

I tried then installing the certificate into my workstation's Trusted Root Certificate Authorities, thinking along same the lines as @Greg Askew. No dice. Still not available as an option in the PEAP settings.

You apparently need a) to have installed the certificate in the Trusted Root Certification Authorities on whatever domain controller gpmc is connecting to and b) be running GPMC on that domain controller directly.

This makes no sense to me as RSAT is RSAT is RSAT, regardless of whether you are running gpmc on a domain controller or a workstation. Go figure... a beer goes to whomever can explain this!



From my workstation - no certificate:

gpmc workstation



From the domain controller - certificate is available!

gpmc dc

share|improve this answer

Just a guess. I would think that the machine where gpmc is running needs to have the certificate in the machine Trusted Root CA folder, and/or have a GPO that deploys the certificate to the domain as a Trusted Root CA certificate.

share|improve this answer
    
I am already deploying the self-signed certificate via GPO without trouble. The issue is solely in the GPO for PEAP configuration. Regardless you had the right idea. –  kce Mar 23 '12 at 0:23

In our config we had to set up an enterprise CA and found it easiest to set up a NPS server for authentication.

share|improve this answer
    
A NPS server is not an option for us for a variety of reasons. Furthermore, unless you can make a solid case for why I should integrate my 802.1x PKI infrastructure with my domain, or alternatively why I shouldn't use an independent PKI infrastructure this answer is ultimately unhelpful. –  kce Mar 11 '12 at 23:53

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.