Once you have deployed our RADIUS server solution from the AWS marketplace. The first step is to RDP into your new VM:

• Guide on how to RDP into an AWS instance

Next, Once you have logged into the AWS RADIUS server, you are now ready to configure it for wireless authentication with your Active Directory.

Open ‘Network Policy Server’ from the desktop or administrative tools:

The first thing you want to do is register this NPS with your active directory.  We do this by right clicking the top of the tree and then clicking ‘Register server in Active Directory’: (This can be your onprem Active Directory or AWS Directory Service).

(In this example it is shown as greyed out because I haven’t added to AD yet. If you see the same add to your domain and then come back to this step)

Next we want to create a template for your shared secrets. All of the RADIUS clients that will authenticate with the server will need this shared secret so that they can authenticate. In the long run it is easier to create a template with this in to save entering it on each RADIUS client we setup.

Expand ‘Template Management’ and right click on ‘Shared Secrets’ and click ‘New’:

Give the template a name and either enter your own shared secret or click the ‘Generate’ radial button and then click ‘Generate’ at the bottom.

Make a note of the share secret, this is needed later.

This will create you one as seen below. If you hover over the yellow warning sign you will see a message telling you that it may be too long for some clients. If this is the case you can shorten the shared secret to a more appropriate size or create your own. Click ‘OK’ to save:

Next under ‘RADIUS Clients and Servers’ right click ‘RADIUS Clients’ and click ‘New’:

Fill this out with the relevant information, under ‘Address’ enter the IP address of your first RADIUS client. This will be the address of your first wireless access points. Under ‘Shared Secret’ select the template we created earlier and click ‘OK’:

Repeat this process for any of your wireless access points you want to act as RADIUS clients. Once you have done this, any you have added will be listed:

Now that all the RADIUS clients are setup we need to setup the access policy, but first you need to make sure you have a certificate in the local computer store.

Add a Trusted Certificate to NPS

A RADIUS server must host a certificate that allows both network clients and APs to validate the server’s identity. There are three options for this certificate:

• Acquire a certificate from a trusted Certificate Authority
  As long as the CA used is trusted by clients on the network, a certificate can be purchased and uploaded into NPS to accomplish and server identity verification (required by clients). Common examples of trusted CAs include GoDaddy and VeriSign.
• Implement a Public Key Infrastructure and generate a certificate (advanced)
  A PKI can be used on the network to issue certificates trusted by clients on the network. A strong understanding of PKI is recommended for this option.
• Generate a self-signed certificate and turn off client server validation (insecure)
  A self-signed certificate can be generated for testing/lab purposes, though clients will not trust a self-signed certificate and will need to have server validation disabled in order to connect. Steps below on how to generate a self signed certificate.

Once a certificate has been acquired, these are the instructions on how to import a certificate.

1. Right-click the Start button and click Run
2. Type mmc and hit Enter
3. Hit Ctrl+M (or click File -> Add/Remove Snap-in…)
4. Select Certificates from the Available snap-ins and click Add >
5. Select Computer account and click Next, then Finish
6. Expand Certificates (Local Computer) -> Personal 
7. Right-click Personal > All Tasks > Import – Select Local Machine, click next and browse to where you’ve saved your certificate. 
8. Follow the wizard to import your certificate.

Create a Self Signed Certificate

If you don’t have a PKI or a certificate from a third party, you can create a self signed certificate using the built-in powershell module.

Open up Powershell.exe as Administrator and run the following command

New-SelfSignedCertificate -DnsName "RADIUS FQDN" -CertStoreLocation "cert:\LocalMachine\My"

Example:

New-SelfSignedCertificate -DnsName "fs.Test.local"-CertStoreLocation "cert:\LocalMachine\My"

This option is not recommended for production deployment, due to dramatically reduced security.

Now lets setup the access policy.  With the top of the tree selected, on the right hand side under ‘Standard Configuration’ you need to select ‘RADIUS server for 802.1X Wireless or Wired Connections‘ from the drop down list and then click ‘Configure 802.1X’ below:

Select ‘Secure Wireless Connections’ and give it a suitable name at the bottom and click ‘Next’:

On the next screen you should see a list of RADIUS clients which we setup earlier, so we don’t need to do anything here. Click ‘Next’:

From the drop down list select ‘Microsoft: Protected EAP (PEAP)’ and then click ‘Configure’:

Here you can specify the certificate you would like to use to secure the connection using the drop down menu.

I had already requested a certificate for this purpose which I selected. However you can use the default self-signed one for now. Click ‘OK’ and then click ‘Next’:

At this stage you can specify which domain groups will be given access to the wireless network. Click ‘Add‘ and search for any domain groups you would like to add and then click ‘Next‘:

The next page allows you to configure traffic controls. Here you can setup VLANS and access control lists to control traffic.  You will need to refer to your AP manufacturer if they support these options, as this page is optional or you can configure later if you need these settings configured. Press Next to continue

On the last page confirm your settings and click ‘Finish’:

You will now see under the ‘Network Policies’ section that a new policy has been created:

If you double click on this policy you can see the settings that are in force:

Under the ‘Conditions’ tab you can see what conditions are required to connect to the wireless network. In this example anyone who is a member of the DOMAIN\Staff group will be authorised.

At this stage you can add, edit or remove groups using the buttons below. If we were to add the DOMAIN\Domain Computers group any machine on the network could authenticate and connect to the wireless network with its machine account:

Going a step further you can create another policy to deny access to the wireless network. The easiest way to create another policy is to duplicate the first one. Do this by right clicking the first policy and clicking ‘Duplicate Policy’:

Under ‘Overview’ tick the ‘Policy enabled’ box and change the ‘Access Permission’ to ‘Deny access’:

Under the ‘Conditions’ tab click on the current windows group and click ‘Edit’. Remove the DOMAIN\Staff group and add the group containing users you don’t want to have access to the wireless network. Click ‘OK‘ and then click ‘OK’ again:

On the ‘Network Polices’ page right click the newly created deny policy and move it to the top if it isn’t there already so that it has the processing order of ‘1’.

Policies are processed from the top down so the deny policy will be processed first. Denying any user who meets the conditions of the policy even if they are also a member of the group that is listed in the allow policy:

You can at this stage click on the ‘Accounting‘ section and enable this RADIUS server to act as an accounting server too, keeping logs of any connection requests. This is either in the format of a log file or an SQL database.

The next step is to configure the wireless access points to pass authentication requests to our newly configured RADIUS server. The setup and process will differ depending on the brand of access point you are using.

Cisco Meraki RADIUS Authentication

I am going to use Cisco Meraki MR access points in this example.

(Optional) Deploy a PEAP Wireless Profile using Group Policy

For a seamless user experience, it may be ideal to deploy a PEAP wireless profile to domain computers so users can easily associate with the SSID. Though optional for user auth, this is strongly recommended for machine authentication.

The following instructions explain how to push a PEAP wireless profile to domain computers using a GPO, on a Domain Controller running Windows Server:

1. Open the domain Group Policy Management snap-in.
2. Create a new GPO or use an existing GPO.
3. Edit the GPO and navigate to Computer Configuration > Policies > Windows Settings > Security Settings > Public Key Policies > Wireless Network (IEEE 801.X) Policies.
4. Right Click Wireless Network (IEEE 801.X) Policies and choose Create a New Windows Vista Policy.
5. Provide a Vista Policy Name.
6. Click Add for Connect to available networks.
7. Choose Infrastructure.
8. On the Connection tab, provide a Profile Name and enter the SSID of the wireless network for Network Name(s). Click Add.
9. Click the Security tab. Configure the following:
   • Authentication: WPA2-Enterprise or WPA-Enterprise
   • Encryption: AES or TKIP
   • Network Authentication Method: Microsoft: Protected EAP (PEAP)
   • Authentication mode: Computer Authentication (for machine auth)

10. Click Properties.
11. For Trusted Root Certification Authorities select the check box next to the appropriate Certificate Authorities and click OK.

12. Click OK to close out and click Apply on wireless policy page to save the settings.
13. Apply the GPO to the domain or OU containing the domain member computers (refer to Microsoft documentation for details).

Once you’ve deployed the wireless profile to users or manually setup one on a test machine, we can now test connecting.

Now enter a username and password for a valid domain account that is a member of the group you specified earlier in the allow policy.

Depending on the model of phone you will get more of less detail at this stage. On an Android phone you need to manually specify the certification authority certificate when joining the network that will validate the server certificate we selected earlier during the setup process. This has to be installed manually first. For testing purposes you can use the drop down list and select ‘Don’t validate’:

On an iOS device initially you will just be asked for a username and password and then asked if you trust the server certificate. If you have preinstalled the CA certificate beforehand and enabled full trust for it you won’t be asked.

Providing all the details are valid the device will connect to the wireless network as it would with any other:

For any windows domain joined devices such as tablets or laptops you will have 2 options to connect depending on your setup.

First, If you specified DOMAIN\Domain Computers earlier in the conditions of the allowed policy the devices will be able to authenticate using their machine accounts.

You can just click the wireless network and it will seamlessly connect authenticating in the background with its machine account. Using group policy or SCCM you can deploy the wireless profile centrally making each Windows device connect automatically without user intervention. However this does require an initial connection to the network (wired or wireless) to receive the GPO or SCCM update.

If you didn’t specify the DOMAIN\Domain Computers group earlier a user account is required to access the network. The second option is when a user tries to connect to the wireless network they will be asked for a username and password. If they are already logged in as a domain user they can select the option to connect using the currently logged in user. Providing the user is a member of the correct group the device will connect to the wireless network, authenticating with that users credentials.

Eliminating the need for a pre-shared key gives you much more control over who has access to your wireless network. Other conditions can be specified under a policy as well as windows groups such as times of the day, IP address ranges, etc. If a user leaves or is compromised there account can be disabled or their password changed to deny them further access to the wireless. Policies can be tailored to your specific needs giving you’re a lot more flexibility.

AWS RADIUS Server Firewall Ports

The following firewall ports will need to be open for each of your wireless access points (APs) to allow them to access your RADIUS / NPS server in AWS:

RADIUS Authentication and Authorization

UDP: 1812 / 1645

RADIUS Accounting

UDP: 1813 / 1646

To setup AWS firewall rules refer to – AWS Security Groups

You also need to make sure the RADIUS server in AWS can communicate with your Active Directory

Support

If you have any questions about the setup of our RADIUS authentication solution in AWS, leave your comments below and we will reply within 24 hours.

Want some help (hire us)?

If you would like us to implement the RADIUS server into your environment for wireless authentication and fully configure it and get it up and running, get in contact with us and we will get you up and running asap