Archive for the ‘ADCS’ Category

Creating a WPA2-EAP Wireless Network with NPS, AD CS, and GPO

May 26, 2012 8 comments

I have had to deal with some networks in the past where wireless was perhaps not treated with the proper amount of concern.  I know of at least a few where the basic premise to security is just a WPA2 password – that hopefully the users don’t know.  It can’t be changed regularly because you’d have to communicate this change out to everyone.  A user with local administrator rights and Windows 7 can simply check the “show password” box on the WPA password settings, and it will show them.  Compound this with not changing passwords when a user leaves the company and you leave a fairly big hole in the side of your network.  Even worse is relying on MAC security, as this can be spoofed just by sitting there long enough and watching the packets go by and picking a MAC you want to use.

So what’s the solution?  WPA2-EAP using RADIUS, SSL via an Active Directory Certificate Authority, and GPO’s.  The general overview of what you are wanting to set up here and wanting to accomplish, is this:

  • The computer must be a domain computer and trusted.
  • The computer will, via GPO, auto-enroll for a computer based certificate.
  • AD CS will provide said certificate.  This will allow for the computer to be trusted beyond simply its SID or hostname, etc.
  • Wireless settings will be pushed out to all systems via GPO.  No one wants to go to 20 computers and enter a new SSID or configuration.  This should be automatic.  If you add a new access point or a new office, it should publish to the computer (assuming you want this – you might want to use security groups to limit who can use what AP’s in what locations, etc).
  • We don’t want users messing with the wireless settings at all.
  • There should be no password for a user to share, shoulder surf, remember, etc.
  • The user is not what we’re trusting but the computer.  This prevents the user from finding a way to use their credentials to authorize a non-domain computer by sharing, and walking away.
  • Because the computer is authenticating, it is connected as soon as the WiFi is available at boot up, even before the login.  This means that GPO’s and software deployments, etc, can be taking effect even if the machine sits at the login screen.  Contrast this with the situation where the user must login using cached credentials, then connect to the network, and then run any of these tools.  Also, a user who has no cached credentials from a previous login, can login and create a profile.

So some pre-requisites and reference links:

  • You’ve configured an Enterprise PKI for your network similar to how I have described before – Enterprise CA PKI for Domains – 2 Tier, with Root & Subordinate
  • A handy primer on how to do this –
  • WAP’s capable of using WPA2-Enterprise and RADIUS (my Netgear WNDR-3700v2 with DD-WRT will)
  • Create any groups in AD if you want to restrict access to certain computers or users in your domain.  The most likely reason you would do this is if you wanted to create say a “grpAllowedWiFi-OfficeName” per office, and then you chose which computers had access to which office.  I’m going to assume here that we are giving access to the entire network from all domain computers, as this is probably most likely.

And now the steps – there is very little that is different from the SpiceWorks HOWTO post by Tino Todino.

1) Configure your Wireless Access Point.

We’re going to do this with a DD-WRT device, as this configuration should translate well regardless of device and if your device doesn’t do it, you might be able to use DD-WRT devices to deal with this.



I have created a Virtual Interface for this access point, so that I can do this testing in parallel with what I already have in place.  Set it as an AP and give it a name – case matters, and you may want this SSID to be generic through your infrastructure.  I have also chosen to not broadcast the SSID.  This is security through obscurity, but every little bit helps.  Plus because we are going to publish these out to computers via GPO, we don’t have to worry about end-user usability.   Click SAVE/APPLY CONFIGURATION.



Security mode is going to be WPA2-Enterprise.  WPA Algorithm we’ll set to AES (TKIP I understand can be cracked).   Enter the IP’s and shared secrets of your RADIUS servers.  This shared secret will be used later.   Click SAVE/APPLY CONFIGURATION.

The Wireless Access Point is now configured.

2) Install NPS on the server

I already had NPS installed, but if you followed my setup, you only have the Network Policy Service installed and not the Routing and Remote Access Service

3) Set up RADIUS clients on the NPS

Open the NPS console on the NPS server.  Expand RADIUS CLIENTS AND SERVERS –> RADIUS CLIENTS.  Right click and choose NEW.


Enter the friendly name of this WAP, the IP, and the Shared Secret and click OK.  If you have multiple AP’s, repeat this process as needed.

4) Configure 802.1x on the NPS server

In the NPS console, click on the root NPS (Local) option.  On the right hand side from the drop down select “RADIUS server for 802.1x Wireless or Wired connections”.   Then click the green arrow beside “Configure 802.1x”.


Select “Secure Wireless Connections” and give it a name.  I’ve named mine “NetWise – Secure Wireless Connections”.  Click NEXT.


Select the RADIUS client(s) you want to use this configuration.  To be fair, you could have also added the client here as well I just realize.  Click NEXT.


Select Microsoft: Protected EAP (PEAP).  Click CONFIGURE.


In my case, my primary RADIUS server also happens to be my Exchange server (I’ll get around to fixing that some day…..).  As such, it has more than one SSL Certificate present.  Select the one for the RADIUS server itself, which will be the one showing the FQDN.  Also it will show “Issued:” by your internal AD CA, vs an external 3rd party.   Click OK


Click NEXT.

This is where you would configure USER groups.  Note that this is not groups of Computer objects, so this is not where/how you would restrict ComputerA from using the WAP in CityQ for example.  Click NEXT, as we’re not adding groups in the scope of this document.


On the Traffic Controls screen, click NEXT.


On the last page, you’ll see confirmation that we have created both a Connection Request Policy and a Network Policy.  Click FINISH.


5) Create a Certificate AutoEnrollment GPO.

  • Open the Group Policy Management Console
  • Either create a new GPO or modify an existing one.  I’m choosing to modify my Default Domain Policy as I want this to affect all my computers.  You might choose to create a new one so you could link it to OU’s or computer groups as desired.
  • Under Security Filtering, you would remove the “Authenticated Users” and add in the Computer/User groups if you wanted to do it that way.
  • Edit the GPO (Right Click –> EDIT)
  • Right click on “Certificate Services Client – Autoenrollment” and click PROPERTIES.
  • Change “Configuration Model” to ENABLED and check both boxes and click OK.
  • Right click on “Certificate Services Client – Certificate Enrollment Policy” and click PROPERTIES.
  • Change “Configuration Model” to ENABLED and click OK.
  • Close the GPO you’re working on to save it.  (I forget this so often, it hurts.)

6) Create a Windows Vista/7 Wireless 802.1x GPO.

  • Edit the GPO in question.  It might very well be the same one from step 5 above.
  • Right click and choose “Create a new wireless network policy for Windows Vista and later release”.image
    Note: if you don’t see this, you might already have a policy configured for Vista.  If so, you will only get the option for the Windows XP policy.  But you can only have one of each per GPO.   This could be a good design reason to want to keep the GPO’s with the policies separate from your Default Domain Policy, if you are intending to have a configuration that is not standard across the board.
  • Give your policy a name and a description, and then click ADD –> INFRASTRUCTURE.
  • Give your profile a Profile Name (ie: NETWISE CORPORATE).  Type in the name of your SSID and click ADD.  I have to assume you could put in multiples here if perhaps your SSID’s were setup like NW-<CITY> or NW-<LOC_CODE>, etc.
    Check all 3 boxes: “Connect automatically…”, “Connect to a more preferred….” (more on this later!) and “Connect even if….”.  Click the SECURITY tab.
    Click PROPERTIES next to (PEAP).
  • Check the box for “VALIDATE SERVER CERTIFICATES”.  Check the box for “CONNECT TO THESE SERVERS:” and enter the FQDN name(s) of your RADIUS servers to use for this policy, separated by a semi-colon if needed.  In the TRUSTED ROOT CERTIFICATION AUTHORITIES list, find and check the certificate for your Enterprise Root CA.
    Click OK twice to return to the 802.11 Wireless Network Policy Properties window.
  • Click on the NETWORK PERMISSIONS tab.
  • If you want to get more granular, this is where you have some greater control over the wireless settings on the client.   Some specific options:
    • You can click ADD and enter an Infrastructure/Ad-Hoc SSID and choose to allow or deny.  This is where you might add a known public SSID that you don’t want users to use (ie: “Linksys” or “Starbucks” or something.).
    • Check boxes for “Prevent connections to ad-hoc/infrastructure networks”.
    • If you’re going to prevent said access, then you might want to uncheck “Allow user to view denied networks” – this would make them simply not show up at all.
    • “Only use Group Policy profiles” locks the WiFi lists on the client down to ONLY what you have configured in Group Policy – they cannot add anything additional.  This seems pretty drastic, but it is a nice option to have.
  • Click OK
  • Close the GPO to save it.

7) On a client that might already be connected via a WPA2 configuration or wired, refresh the group policies (gpupdate /force) and let it run.  If you have to log off or reboot, do so.


Once it applies, you’ll see that your new options are present.  Do note that you see the wireless configuration friendly name “NETWISE CORPORATE” vs the SSID of “NETWISE-ENT”.  Also, because of the check boxes when creating the GPO Wireless Policy of “Connect to a more preferred network….” you will note that I’ve stayed connected to my 802.11n 5GHz AP/SSID vs switching over to NETWISE CORPORATE automatically.  Depending on your environment, you may then want to modify this in the GPO.  Perhaps your office is next to a Starbucks and maybe they even have better signal strength on that side of your office.  This setting would tell the computer to connect to the corporate network any time it is available.

8) Troubleshooting.

Are you seeing this: image

Remember the part where I said the NPS I was on had more than one SSL certificate?  If you pick the wrong one, and the FQDN and such don’t match, you’re going to get this error.  To remedy it:

  • If you’re working wirelessless, you should TERMINATE and connect to either another WPA2 based SSID or a wireled link.
  • Connect back to your RADIUS/NPS server(s)
  • In the NPS console, click on POLICIES –> NETWORK POLICIES.  Select the Secure Wireless Connections policy (with the appropriate name) and right click and choose PROPERTIES.
  • Click on the CONTSTRAINTS tab
  • Select the EAP type listed (there should be only one) and click EDIT.
  • On the EAP Protected EAP Properties window, ensure that Certificate Issued: is showing the FQDN of the server as entered in the RADIUS properies previously and shows ISSUER: as your Enterprise Root CA.  Click OK twice to finish editing.
  • Do this on both (or more) of your NPS/RADIUS servers
  • Retry your connection.

Now, to wrap up.  Once you’re connected if you want, you can right click on the connection in the WiFi list and choose PROPERTIES:

You will note that everything is grayed out and un-modifiable:


So what we have is exactly what we set out to get.  No WPA2 passwords that can be shared.  We’re using PKI/SSL/ADCS/GPO to deploy the security so no one ever has to touch the machine(s).

Its been a good day Smile

Categories: ADCS, GPO, PKI, RADIUS, SSL, WiFi

Configuring Juniper ScreenOS/SSG to use Domain PKI

May 19, 2012 3 comments

Most of this information I took from :

1) Browse to the web URL for the SSG5 – HTTPS://NW-SSG5A.  Yup, we get an error.


2) Login to the device with ROOT credentials (ie: netscreen or similar if you’ve renamed it.).  I don’t think you can do this with a regular read-write admin user.

3) Browse to OBJECTS -> CONFIGURATION.  Click NEW:


4) Enter your info, similar to the iDRAC.  Change the keypair to RSA and the bit strength to 2048.  Click GENERATE:


It will take a while and it tells you that.  Generating a 2048 key pair takes a while.   When it’s done you’ll see:


5) Click SAVE TO FILE and do that:


6) Go to your Subordinate CA (NW-ADCS1).  Open a command prompt, and let’s generate a cert:


Remember the command line is: certreq –submit –attrib “CertificateTemplate: WebServer” NW-SSG5A_pkcs10.txt(that is what you saved in #5 above).  Save your resulting file as NW-SSG5A.cer and click SAVE.

7) On the SSG, click on OBJECTS -> CERTIFICATES.


You’re going to see the existing request.  At the top is a LOAD: CERT.  Click BROWSE and find the file…


Click OPEN.  Then click LOAD next to the BROWSE button.

8) Now you’re going to see that the SSL is present:




10) See the CERTIFICATE option that shows “DEFAULT – SYSTEM SELF-SIGNED CERT”?  Click the drop down and select the new certificate:


Click APPLY at the bottom of the page.

I got a pop up error that complained and then refreshed the page.

11) Open a new browser window, and browse to the FQDN/Hostname of the unit (ie: HTTPS://NW-SSG5A or HTTPS://NW-SSG5A.NETWISE.CA)


Look at that – no SSL error!

Categories: ADCS, PKI, ScreenOS, SSL

Configure Dell iDRAC to use Domain PKI

May 19, 2012 4 comments

So my PKI works.  But…… I don’t know what to *DO* with PKI.  Maybe I can…. Oh hell who knows.  Wait.  Network Devices!  Things that have HTTP/HTTPS administration pages, with SSL errors.  YES!  Let’s start with that.  That seems like a good enough target.

1) Browse to HTTPS://NW-ESXi1-IDRAC(  Get an SSL error, but trust it.

Hold up.  You DID create a DNS name for the iDRAC right?  Because the Subject Name of the SSL, and the Host Header used, and the Host Name all have to match, we know this from basic IIS.  Go make your DNS entries now.  I’ll wait.  Good.  Should have done that ages ago anyway…

2) Click on SYSTEM -> REMOTE ACCESS on the left.  Then CERTIFICATION tab.  Then SSL option.


Click GENERATE A NEW CERTIFICATE SIGNING REQUEST (CSR) and click NEXT.  NOTE the red bar showing the Certificate Error!

3)  Enter your CSR Information:


Remember the Common Name should be your host name (not FQDN).  Your Organization name has strict requirements as to what it can contain – I think it is alpha numeric and – and _.  To simplify my life, I never use “NetWise Inc” or similar, just make it NetWise.  City and State should be filled out in full.  E-mail is optional, I’d exclude it (scratch that, got an error demanding it as I was doing this for screen shots).  Click GENERATE.

4) clip_image006

Note that it wants to call it “CSR.TXT”.  This is stupid.  Save it somewhere that is shared between where you are doing this configuration and the Subordinate CA (NW-ADCS1).


I might suggest a shared/common network location that the Administrator has access to, and rename it something with a little bit more detail.  Something like <COMMON NAME>.csr.txt.  Don’t get fancy and drop the .txt, you’ll see why later!

5) Go to  your Subordinate CA and login as a user who is member of ENTERPRISE ADMINS.  This is going to burn you sooner or later, as many accounts you use for Domain Admins are NOT part of Enterprise Admins.   Open the Certification Authority from the Admin Tools.  Expand everything nicely:


Right click on the CA (NW-ADCS1-CA) and choose ALL TASKS -> SUBMIT NEW REQUEST


Select your CSR.  Remember how I said don’t drop the .TXT?  Look at the types – *.req; *.txt; *.cmc, etc.  I don’t have Explorer set to show extensions which is why you don’t see NW-ESXi2-iDRAC.csr.txt.  But if you changed the name, you’ll not find your CSR, which is frustrating at the end of a long night of fighting with this.


Select your CSR and click OPEN.

6) What the hell?  Why is there an error????

clip_image016– and I quote:

===== QUOTE =====

Microsoft’s resolution: Generate the request some other way.

Stuff that.

Dave’s solution:

certreq -submit -attrib “CertificateTemplate: WebServer” WebServerCertReq.txt

The key is the extra attribute we add to force use of the template. The certificate is issued and we can go and import it to the web server.

===== QUOTE =====

Okay, well I can live with that .  Let’s open a command prompt and do that.  File is on M:\CA where I saved it:


When you run it, you’ll get this pop up.  I don’t yet know why.  I THINK it is because the PKI setup I used said to follow all the instructions on, says to remove the LDAP:// URI.  You can see from the command prompt behind that it is showing LDAP:.  Just pick the second one, as right now my HTTPS version seems to not bet working.  Click OK.


Save the file.  Something good like <HOSTNAME>.cer, as suggested.  Type is X.509 Certificate.  Click SAVE

7) Go back to the iDRAC configuration web page.  It’s probably timed out – so relogin and Click on SYSTEM -> REMOTE ACCESS on the left.  Then CERTIFICATION tab.  Then SSL option.




Browse to your new CER file.  If you’re not sure, it will be the one with the hostname, but the later timestamp.  Select it and click OPEN.


Click APPLY and then click OK on this message.  It WILL take 2-4 minutes before you can log back in.  It wants to close the tab, and you probably should.

8) Open a NEW BROWSER and browse to the site – would you look at that – NO SSL ERROR.


This assumes that if you did all the stuff in my previous PKI post ( to set up the Root CA and Subordinate CA, with GPO options, that you are doing this later on, on a computer that has refreshed its GPO’s, to get the trusted Root and Intermediary CA’s for your network.  If you have NOT, then you SHOULD EXPECT to get an SSL error here, as it has no idea that it should trust the Subordinate CA that just issued your certificate.  This ALSO means that if you have a non-domain computer such as a personal laptop that you bring to the office, you SHOULD EXPECT to get SSL errors, unless you have told it to trust your ROOT/Subordinate as well.  This CAN be done, but it is WAY out of scope for this.

Categories: ADCS, Dell, PKI, SSL

Enterprise CA PKI for Domains – 2 Tier, with Root & Subordinate

May 19, 2012 3 comments

I’ve been fighting with wanting a PKI working in my environment for a while.  For all the typical reasons:

  • Required for 802.1x WiFi authentication
  • Required for 802.1x Wired authentication
  • Required for RADIUS
  • Required for IPSEC between domain systems
  • Required for internal web sites that have SSL based traffic without a 3rd party SSL including:
    • Actual web sites – ie: those hosted and created on IIS/Apache
    • Application/utility web sites – ie: Open Manage (OMSA, IT Assistant, OME, etc), Veeam Enterprise Manager, etc.
    • Hardware with administration pages – ie: Juniper ScreenOS/SSG, Dell PowerConnect switches, Dell iDRAC, Digi CM32, etc.

I finally got around to finding a way to make it work.  I don’t propose that this is 100% functional at this point, but it’s working. I also don’t suggest that this is ideal – there likely is a better way.  By all means – let me know if there is!  Thanks in advance.  I cobbled together a little here and a little there and made it functional for me.  I’m sure there is more to do…..

With that said – the meat of this post…..

Would you like to know why companies don’t have PKI infrastructures?  Because it is FRUSTRATING AS HELL.  Wizardry might be easier.  Seriously, I could make dragons teleport in and breath flaming acid on Orcs easier.

Okay, so here is the VERY high level of what you want to know:


1) Best link to get started:

a. READ IT VERY FREAKING CAREFULLY.  There is a lot of stuff that if you skim it, you’re missing some CRITICAL stuff.  Or if you think you know better, you’ll mess it up – and realize why in step 43.  For example:

· “Log off the Subordinate CA”.  “Log onto the Root CA, do blah blah”.  “Log off the root CA”.  “Log onto the DC and edit the GPO to include the certificate”, “Log back onto the Subordinate CA”


o You’re logging OFF the first box, so that after you modify the GPO, you’re re-processing the GPO when you login.  If you don’t, the stuff you added to the GPO isn’t there!  Go figure.

o If you don’t log off the DC after editing the GPO, there’s a good chance you didn’t close the GPO.  Or save it.  Or set it up to push out the next pass.

· Think about your naming.  You will NEVER be able to change it.

· I have NO idea how to do any sort of dual server clustering of your Subordinate CA’s.  You will almost certainly want some HA of it, especially in a corporate environment

2) After you do the above…. Now what?  There’s no good details on how to TEST it.  You also haven’t added in the Web Requestor, the Network Device Enrollment, etc.  We’ll get to that.

3)– this is a great resource.  Not just this link, and this 5 part series, but in general.  Read it a few times.  Digest the information.  Let it sink in.  Read it again.  Then realize it is NOT digested.

4) Go find a computer.  Go login as a member of ENTERPRISE ADMINS.  Start MMC, add the CERTIFICATE option and choose COMPUTER -> LOCAL COMPUTER.



b. Look at that – we have some options.  All we care about (and that you’ll have at this point is COMPUTER and *maybe* IPSEC.  Click COMPUTER and NEXT.


c. OOOH!  Look at that!



d. I bring to you – certificates!  It works!


5) Sooner or later you’re going to want to create a certificate request.  I can’t seem to do mine via the MMC – because I was getting the error shown here:

Rather than fight with it, I have accepted Dave’s Solution.  Smile  It works fine for me, I’ll cope for now.  This is a “to be fixed” thing though for me.

6) – you’re probably going to set it up like me so it uses Domain Credentials and Trusted Computer to do enrollment.  Think about that for a second.   That works GREAT if your computers are all Windows, and all Domain Joined and all Local.  Now how are you planning on getting a certificate for your Juniper Router, at a remote site, that isn’t connected with a VPN because of DMZ?  How is your user going to request a Cert for DirectAccess, when he’s off network, and trying to setup for the first time?  There are a LOT of VERY LONG TERM design issues to think about here.  For now, I’m stumbling.

Categories: AD, ADCS, GPO, PKI, SSL