Why, oh why, did you have to make this so difficult?
If you’re running Cisco WCS and would like to use a non-self-signed SSL certificate, you probably did what I did. Note: The following steps *look* right, but are not:
1) Dig through the WCS directories until you find the Apache SSL configuration files (in ./webnms/apache/ssl/ssl.conf).
2) Modify ssl.conf to point to your RSA Keys, Intermediate Certificate, and Signed Certificate files.
3) Restart WCS.
Yeah, that doesn’t work. Turns out WCS overwrites the contents of all of the Apache configuration files, including ssl.conf, with the files from the local “backup” directories (there are no less than 17 backup directories in WCS.)
[root@wcsbox WCS126.96.36.199]# du -a | grep backup | wc -l
So, here is the actual working procedure. For this example, I’ll be using the free .edu certificates from my pals over at ipsca.com (you guys rock!).
1) Generate a CSR and have your favorite CA sign it. When complete, you will have three files: Your key (server.key), the signed cert (server.crt) and the CA’s intermediate (intermediate.crt).
2) Edit /opt/WCS_version/webnms/apache/ssl/backup/ssl.conf and set the following directives:
I like to keep these files outside of the WCS directory so that I can re-use this config file after an upgrade. I also store a backup copy of ssl.conf in this directory. Ironically, WCS doesn’t make backup copies of these for you.
3) Restart WCS and *poof* enjoy your new signed SSL experience.
Although this is a very common approach to securing corporate wireless networks, there is little information out there on how to actually set this up. We’ll show you how to configure a strongly encrypted, authenticated wireless network that does not require you to be running your own certificate authority (CA).
Step 1: Setup the IAS Server.
Install a Windows 2003 server as a member server in your Active Directory Domain. Install the IAS service: Control Panel > Add or Remove Programs > Add/Remove Windows Components > Networking Services > Internet Authentication Service
Step 2: Obtain a signed server certificate for your IAS Box.
(This is based on the procedure found at http://support.microsoft.com/kb/321051 )
This is key. If you do not use a signed certificate, users will not be able to authenticate. WCS will fail with random “Check Engine Soon” type messages, while the logs from IAS will indicate that a bad username or password was specified.
2.1) Create a text file request.inf which containing the following:
[Version] Signature="$Windows NT$" [NewRequest] Subject = "CN=servername.example.com,OU=Servers,DC=example,DC=com,O=Example Company Name,L=Your City,s=Your State,C=US" ; KeySpec = 1 KeyLength = 1024 Exportable = TRUE MachineKeySet = TRUE SMIME = False PrivateKeyArchive = FALSE UserProtected = FALSE UseExistingKeySet = FALSE ProviderName = "Microsoft RSA SChannel Cryptographic Provider" ProviderType = 12 RequestType = PKCS10 KeyUsage = 0xa0 [EnhancedKeyUsageExtension] OID=188.8.131.52.184.108.40.206.1 ; this is for Server Authentication
Be sure to change the server name, OU, and Locale information to meet your particular installation.
2.2) Create the certificate signing request. At a dos prompt;
C:> certreq -new request.inf request.req
2.3) Send the CSR (request.req) to your favorite certificate authority for signature. If you’re a university (with a valid .edu domain), you can get a free certificate from the kind folks over at certs.ipsca.org
2.4) Import the new certificate:
C:> certreq -accept certnew.cer
If your CA uses intermediate certificates, be sure to import their intermediate certificate as follows:
1. Start Microsoft Management Console (MMC).
2. Add the Certificates snap-in that manages certificates on the local computer.
3. Certificates (Local Computer) >> Intermediate Certification Authorities >> Certificates.
4. Select Certificates and then the “Action Menu” > All Tasks > Import.
5. Browse to your Intermediate cert and import. For IPSCA certificates, use “IPSCACLASEA1.cer”
Step 3: Configure the controller to use the Radius server.
3.1) From the web interface of your WLC or WiSM, Security > AAA > Radius > Authentication. Click “New…” and enter the IP address of your IAS server and define a Shared Secret. We’ll enter this Shared Secret into the IAS server in the next step.
3.2) From the web interface, select WLANS > Select the SSID you’d like to use > Security. Define the parameters as follows:
WPA Policy: Unchecked
WPA2 Policy: Checked
WPA2 Encryption: AES Checked, TKIP unchecked
Auth Key Mgmt: 802.1X
Layer 2 Security: WPA+WPA2
Under the AAA Servers tab, select your IAS server after “Server 1” in the Authentication column.
If you would like to assign unique VLANs to users based on AD group membership, select “Allow AAA Override” under the Advanced tab.
Step 4: Configure IAS.
4.1) Start the IAS console: Start > Control Panel > Administrative Tools > Internet Authentication Service
4.2) Under the Action menu, select “Register Server in Active Directory”. You have to do this once to allow IAS to read parameters from AD.
4.3) Right-Click on “Radius Clients” and select New Radius Client. Give the client a name (eg: WISM #1) and enter the controller’s IP address. Click Next and enter the Shared Secret you specified earlier. Leave Client-Vendor as “RADIUS Standard” and leave the “Request must contain the Message Authenticator Attribute” checkbox blank.
4.4) Under Remote Access Policies, Right-Click and selct “New Remote Access Policy”. Use the wizard and create a new Wireless policy. On the User or Group Access screen, specify the group in AD which contains users you’d like to permit to access your wireless network. A good place to start is the “Domain Users” group. On the Authentication Methods screen, select Protected EAP (PEAP). Click Configure and select your signed certificate from the menu.
That’s it for the basic configuration. Your clients can now connect using PEAP. Supplicant configuration can be somewhat of a mess, especially on older operating systems. Google is your friend. Under Windows 7 and MacOS, just select the SSID from the browse list and follow the prompts. The first time you connect, you’ll be asked to accept the RADIUS server’s certificate.
Step 5: Backup your IAS Configuration
Once you have everything working as desired, be sure to backup your IAS server configuration.
C:> netsh aaaa show config > ias-server-backup.cfg
To restore the config (to a secondary server, for example):
C:Secondary_IAS_Box> netsh exec ias-server-backup.cfg
So you want to get all fancy, and assign users to different VLANs based on their Active Directory group membership? Here’s how:
1) Configure an interface in WCS into each VLAN that you wish to present to users. Be sure these VLANs are present on the 802.1q trunks feeding your controllers.
2) In WCS, Select the “Allow AAA Override” checkbox for each WLAN that you wish to configure.
3) Back over in IAS, navigate to the Remote Access Policies window. You can specify multiple policies which will be processed in the order specified. For this example, let’s assign users in the “NetworkAdmin” group to VLAN 400:
Right-Click on Remote Access Policies and select “New Remote Access Policy”. Use the Wizard and assign the policy a name, such as “Network Admin Wireless”. Select the “NetworkAdmin” group in Active Directory domin which contains the users who should be granted access to vlan 400.
On the Authentication Methods page, select Protected EAP (PEAP), click Configure, and select the signed certificate that you imported earlier. Click Finish to exit the wizard.
Back in the IAS console, bring up the properties tab of the newly created policy. Under Settings, you will have two rules:
NAS-Port-Type matches “Wireless – Other or Wireless – IEEE 802.11” AND
Windows-Groups matches “YOURDOMAINNetworkAdmin”
This policy will therefore be applied to any wireless users in the NetworkAdmin group. Be sure that the radio button at the botton of the screen is in the “Grant remote access permission” setting.
Now to assign the VLAN attriblutes: click on the Edit Profile button, and bring up the Advanced tab.
This list shows the RADIUS attributes that will be returned to WCS following a successful authentication. Add three more to the list:
Service-Type: Framed (this should already be in the list)
Tunnel-Medium-Type: 802 (as in Ethernet)
Tunnel-Pvt-Group-ID: 400 (the VLAN you wish to assign)
Tunnel-Type: Virtual LANs (VLAN)
You can add multiple policies for each user class you wish to assign. Be sure to have a catch-all class (eg: Domain Users) at the bottom of the list.