Cisco – Is a PKI required when authenticating a Cisco Aironet AP via radius against AD

active-directoryauthenticationciscoradiuswifi

We're a small office and have a Cisco Aironet 1250 access point set to WPA-PSK. Now that we've deployed Active Directory I'd like start authenticating my users via radius instead of a PSK.

To this end I've installed NPS on my SBS 2011 server. The WiFi clients are some company-laptops, some personal iPhones, iPads, Android phones, etc. I.e. a mix of all kinds of devices, not all joined to the domain.

It appears that all authentication methods that involve radius that the Aironet supports require some kind of PKI infrastructure. I managed to easily configure our Cisco ASA 5505 to authenticate IPSEC VPN clients against the same radius server, but can't figure out how to set up the Aironet. Do I really need to install my NPS-server's cert on all those devices, like I've seen some people suggest?

Best Answer

Cisco Access points can use two common forms of 802.1X per-user authentication. 802.1X EAP would require certificates for the NPS server, the client computers, and the client users. This is most often only accomplished by using smart cards so the user's certificate follows them.

The other, and more common, method of using 802.1X to do per-user authentication is 802.1X PEAP, which uses a certificate on the NPS server so the clients can validate the server, and the user's Windows username and password for client authentication when the user logs on. Additionally, the Windows domain computer account is used for wireless authentication when no users are logged on, so it is important to remember if you are using groups in the NPS rule, include a group that has all computers in addition to all users.

Note that the access point does not get a certificate. The client is called the "supplicant" and the server needs to authenticate it. The NPS server is the "authentication server," and the clients need to authenticate it. However, the access point is called the "authenticator" and is being a middle man between the supplicant and the authentication server, so clients do not need to authenticate it. The NPS server "authenticates" the access point by virtue of the RADIUS shared secrets.

Finally, this does not need to be a publicly trusted SSL certificate. You can set up an Enterprise CA on your domain, and all computers on the domain will trust it.

Hope this helps!

-Eric

Related Solutions

Cisco Remote Access VPN authenticating via RADIUS over Site2Site VPN

The Radius server IP needs to be included on ASA1 Site to Site tunnel with other ASA where ASA1 outside interface would be the source IP in the crypto acl and radius server IP would the destination.

ASA1<---------------------->ASA2

ASA1:

Crypto acl- ASA_outside_IP to Radius_Server_IP
Nat- nat(out,out) source static ASA_OUtside_IP ASA_OUtside_IP destination static Radius_Server_IP Radius_Server_IP no-proxy-arp
route-lookup
same-security-permit intra-interface

ASA2:

Crypto acl- Radius_Server_IP to ASA1_outside_IP
Nat- nat(inside,out) source static Radius_Server_IP Radius_Server_IPdestination 
static ASA_OUtside_IP ASA_OUtside_IP no-proxy-arp route-lookup

Configuring Cisco Switch and ASA/VPN devices to authenticate with W2008R2 NPS RADIUS

You're going to want to stick with creating/ordering Network Policies to do what you're trying to do. Just use the one default Connection Request Policy that is wide open, and then secure via the NPs.

You can "divide the two" as you say, by limiting each Network Policy you've created with sufficient conditions, such that in combination, multiple conditions together achieve your objectives. It looks like you've specified only one condition on each policy - network group membership. As you've discovered, this won't work. When your RADIUS-enabled device asks your RADIUS server to authenticate your user, the RADIUS server forwards the users' credentials to AD, which successfully matches the credentials (cause they're vague at this point), and returns a positive to the RADIUS server, which in turn tells the device to allow the authentication. I'm forgetting all the proper RADIUS lingo here - but basically that's what's happening.

So, stack another condition (or more) onto your policy to get what you want. Sounds like you want the switch policy to work with users in the Domain\NetworkGroup, and only on your switches (these requests should never come from your ASA's IP, or some printer or user workstation or whatever). Under conditions, look under the RADIUS client section - ClientFriendlyName, or ClientIPv4Address, for example. If the conditions include that the request is coming only from one of your predefined switch IPs or names, it won't "authenticate" requests coming from your ASA IP.

Do the same for your vpn policy too. You should be good from there. You may want to start with clean Network Policies though. I don't think you're going to be able to use the settings to update non-compliant clients without some more work (and whole other policy type too).

Also, you can look at your RADIUS logs if you want more info on what its actually doing. I believe they're under system32\logfiles. You may have to enable it on your NPS server, if its not already. You can google for tools to help you read the log files, as they're not really user friendly. In a pinch, MS has an article that lists all the fields, in order. Look for the tools though (IASlogviewer? or something like that?).

Best Answer

Related Solutions

Cisco Remote Access VPN authenticating via RADIUS over Site2Site VPN

Configuring Cisco Switch and ASA/VPN devices to authenticate with W2008R2 NPS RADIUS

Related Topic