I took some time to import and update quite a bit of RADIUS vendor dictionaries for 3rd party vendors into ISE. I grabbed this information from various community and open source sites but I obviously can't test it against every vendor out there since I don't have  a selection of 140+ 3rd party NADs sitting in my lab. After I imported them to ISE, I exported them and have uploaded them here.    Note: If any of these don't work or I need to update some of the attributes, please shoot me a PM and I'll make the necessary adjustments. Also if there are any vendors I should be adding, let me know.     3com 3GPP 3GPP2 Acc Acme Actelis Adtran Alcatel Alcatel-Service-Router Alcatel-Lucent AAA Alteon Alvarion APC Aptilo Arbor Arista Aruba Azaire Ascend Bay Networks BinTec Bluecoat Boingo Broadsoft Brocade British Sky Broadcasting Group British Telecom Cablelabs Cabletron Camiant Checkpoint Chillispot Citrix Clavister Cnergee Access Server Colubris Compatible Systems Corporation Cosine Dante Dell EMC Dlink Digium Dragonwave Efficient IP Eltex Epygi ERX EqualLogic Ericsson Ericsson-AB Ericsson Packet Core Networks Extreme F5 FdXtended FreeRADIUS FreeSwitch Fortinet Foundry Gandalf Gemtek H3C Hillstone HP Huawei IEA Software Infonet Issanni ITK IP Unplugged Juniper Karlnet Kineto Lancom Lantronix Livingston Local Web Lucent Manzara Meinberg Meraki Merit Meru Microsemi Microsoft Mikrotik Mimosa Motorola Motorola-Symbol Navini NetBorder Netscreen Network Physics Nexans NTUA Nokia Nomadix, Inc Nortel Packeteer (Later acquired by Blue Coat) Palo Alto Networks Patton IADs Perle Systems Propel Prosoft Proxim Wireless Purewave Networks Base Station Quiconnect Quintum Redcreek Riverbed Riverstone Networks Roaring Penguin RuggedCom Ruckus Shasta SG-1 Systems by Runcom Technologies Siemens Slipstream SofaWare VPN Edge (Now Checkpoint) Softbank SonicWall SpringTide Starent SurfNet Telebit Terena Trapeze/Juniper Travelping Tropos T-Systems-Nova Ukerna Unix USR Robotics UT Starcom Valemount Networks VersaNet Communications, Inc Waverider Walabi Wichorus WiFi-Alliance WiMAX WISPr Xedia Yubico Zeus Packet ZTE Zyxel         ... View more

This blog post is going to be going over integration ISE 2.1 and Stealthwatch via pxGrid with self-signed certificates. I personally like using CA-Signed certificates for my deployment because if I ever need to rebuild an ISE instance or pxGrid client, it's extremely easy to get it up and running again with a CA-signed certificate but this isn't always the ideal situation for everyone. For those without a PKI infrastructure or for lab environments, it's pretty easy to set up pxGrid integration without an external PKI infrastructure. I'm going to be using ISE 2.1 and StealthWatch 6.8 to demonstrate this and going through this very quickly. If you would like to read more details about pxGrid integration or various other methods of deployment, please go to the ISE Design Zone to view the ISE Guides here. In ISE, navigate to Administration>System>Deployment and click on the name of the ISE node that you would like to be running your pxGrid services. In the Edit Node screen, make sure that the box next to pxGrid is checked and click Save. Navigate to Administration>System>Certificates>System Certificates and make sure the default self-signed certificate is enabled for pxGrid by checking the box next to it and clicking Edit: After making sure that pxGrid is enabled for this certificate, click the Export button to export the certificate. You should be only exporting the public certificate, not the private key. We want to make sure that ISE will accept requests from all pxGrid clients without additional approval while we're setting this up so navigate to Administration>pxGrid Services>Settings and check the box next to Automatically approve new accounts and click Save. Switching over to Stealthwatch Management Center, click on Admin User>Administer Appliance and then navigate to Configuration>Certificate Authority Certificates. On this screen, upload the ISE self-signed certificate that you just exported. SSH to your StealthWatch Management Center using the root credentials and create a key with the following command: openssl genrsa -des3 -out selfsmc.key 2048 It'll ask you to enter a passphrase. You can choose any one you wish. In this case, I just chose cisco123. After the key is issued, we're going to create a Certificate Signing Request from it by issuing the following command: openssl req -new -key selfsmc.key -out selfsmc.csr The output will ask for the passphrase immediately (cisco123) and then you fill in some basic certificate parameters. One thing to note is that at the end, you can optionally pick a challenge password if you want to use it with this CSR. I did NOT use one: Next we will create the self-signed SMC certificate by issuing the following command: openssl x509 -req -days 365 -in selfsmc.csr -signkey selfsmc.key -out selfsmc.crt It'll again ask you for the passphrase of the key (cisco123) The next thing I'll do is decrypt the passphrase for the key file with the following commands: cp selfsmc.key selfsmc.key.org openssl rsa -in selfsmc.key.org -out selfsmc.key It'll ask for the passphrase again (cisco123) After this is completed, use WinSCP to connect to the StealthWatch Management Center using your root credentials and copy the files you just created over to you local disk: In the StealthWatch Management Center, navigate to Admin User>Administer Appliance and then navigate to Configuration>SSL Certificate. Scroll down to the SSL Identity Certificates at the bottom of the page and upload the self-signed .crt certificate you just created in the Target Certificate File field and the key file in the Private Key field. Click Upload to install the certificate as shown below: In ISE, navigate to Administration>System>Certificates>Trusted Certificates and click Import. Upload the SMC .crt file that we previously created and click Submit when done as shown below: In StealthWatch Management Center, navigate to Deploy>Cisco ISE Configuration if you are version 6.8 or Tools>Cisco ISE Configuration in version 6.7.1: Add the IP address of your ISE node and the SMC Syslog port (if different than the default). Give StealthWatch the username/password for ISE as shown below. If you have one ISE node, this should be one node but if you have a distributed deployment, this would be the MnT and PSN nodes that might send syslog traffic to the SMC. Click Save when done: You should get a pop-up stating that the Cisco ISE connection was successful. If you don't get that, check network connectivity between  ISE and the SMC and any firewalls that might be blocking ports. If all is configured correctly, you should get a green circle showing that communication with ISE is established and an Add Cisco ISE Mitigation button. Click on that button for the next step: On the Cisco ISE Mitigation menu, pick the SMC self-signed identity certificate we previously installed from the drop-down menu and then add the name and IP address of the ISE primary Admin node and optionally the secondary Admin mode and then click Save: You should get a pop-up showing that the connection to the ISE mitigation nodes were successful. In ISE, navigate to Operations>Adaptive Network Control>Policy List. We are going to need to add an ANC policy before we can start quarantining devices. Click Add. Give the policy a name of Quarantine and choose the action of Quarantine: Next we'll need to create a global exception rule for quarantining. Go to your Exceptions for your Authorization policy and create the following rule: Name: ANC (or whatever you want to call it) Conditions: Session:EPSStatus EQUALS Quarantine Then: DenyAccess (Or whatever level of access you want to give quarantined users) Navigate to Administration>pxGrid Services>Clients and you should see your SMC client. Check the box next to the SMC client and then click the Group button: Under the Client Group, remove Basic and add EPS. Then click Save. Your SMC client should now display as this: Next we will configure the Stealthwatch Management Center as a remote logging target. In ISE, navigate to Administration>System>Logging>Remote Logging Targets and click Add: Name the remote target whatever you would like and make sure the IP address is pointed towards the Stealthwatch Management Center. For the port, choose the one defined previously in the ISE configuration over in the Stealthwatch Management Center (3514 is the default). When you are done, click Submit. Navigate to Administration>System>Logging>Logging Categories and add your new remote logging target to the following: - Passed Authentications - RADIUS Accounting - Administrative and Operational Audit - Profiler You're now done configuring ISE and StealthWatch's integration. You can pull up a Host Report in your StealthWatch Management Center and you should see a Quarantine and UnQuarantine button for that host. You should also see a history of which users have logged into that host and other contextual information provided by ISE via Syslog: If you click on the Quarantine button, it should trigger your Exception policy over in ISE and quarantine the endpoint. By clicking UnQuarantine, it will remove that endpoint from it's EPS status. ... View more

In this post, I'm going to walk through the BYOD policy configuration. This policy will be pushing certificate to my users via the SCEP profile we previously created inside ISE. I'll walk through some of the different options you can configure in this policy but overall, I'm going to keep the policy itself pretty simple. First, I'm going to modify the identity source sequence for this specific policy. In ISE, navigate toAdministration>Identity Management>Identity Source Sequences and edit theMyDevices_Portal_Sequence. In this policy, add the AD server in the Selected column and make sure it is on the top of the list: After saving this identity source sequence, we're next going to edit the Guest_Portal_Sequence and add the AD server to the top of the Selected column: After saving the identity source sequences, I will modify the My Devices portal. Navigate to Administration>Device Portal Management>My Devices and edit My Devices Portal (default) . One thing to note: If you don't want to have to edit the default portal, you can always copy it or create a completely new one. Under the Portal Settings page, make sure that you choose MyDevices_Portal_Sequence from the Authentication method drop-down: That's the only thing I'm going to change in this page but I'd like to point out some different things you can change depending on your environment. Portal Settings - HTTPS port: The default is 8443 but you can change it to whatever you would like for this portal. Just be sure to update any ACLs or firewalls to open these ports. Allowed interfaces - Pretty self explanatory. I usually just keep this at default but if you have an ISE appliance and a large ISE deployment, you might want to direct this traffic to a different interface Certificate group tag - This is a unique identifier that helps ISE identify the certificate that has to be used when communicating with this portal Fully qualified domain name (FQDN) - FQDN for this portal. You need to make sure that this matches with DNS if you fill this option in Endpoint identity group - This is the logical group that the endpoints will be placed in after being registered Purge endpoints in this identity group - How many days this endpoints will remain in this identity group before being timed out Authentication Method - This is the identity source sequence that will be used Idle timeout - This is the timeout for the portal Display language - Pretty self explanatory Login Page Settings - Maximum failed login attempts before rate limiting - Default is 5 Time between login attempts when rate limiting - Default is 2 minutes Include an AUP - You can check this box if you'd like to include it as a link or on the page and you can also require acceptance of the AUP. Acceptance Use Policy (AUP) Page Settings - Here you can choose to include an AUP page, require scrolling to the end of the AUP, and specify to show the AUP on the first login, every login or during a certain amount of days starting at the first login Post-Login Banner Page Settings - This is where you can specify to include a post-login banner page Employee Change Password Settings - This is where you can specify that internal users can change their own passwords Support Information Page Settings - You can include certain fields for support information such as the MAC address, IP address, policy server, etc and even display empty fields You can also navigate to the Portal Page Customization tab and further customize the look and the content of the My Devices portal for your users. After you have completed any customizations, you can preview it as well: Now that we have finished modifying the MyDevices portal, I'm going to create a native supplicant profile. Navigate to Policy>Policy Elements>Results>Client Provisioning>Resources and click Add>Native Supplicant Profile . I am creating a native supplicant profile for my mobile devices here so I named it MOBILE-TLS. I could specify IOS or Android here but I'm instead going to keep ALL selected under Operating System . Under Wireless Profiles , click Add . I configure it with the following: SSID Name - SecurityLabCorp Security - WPA2 Enterprise Allowed Protocol- TLS Certificate Template - BYOD After saving this profile, I'll configure the client provisioning policy. Navigate to Policy>Client Provisioning . There I will create the following rules to use the supplicant profile I just crated for IOS and Apple devices: I'm going to create some ACLs in the wireless controller specifically for our BYOD policies. I'm going to create an ACL for Google, NSP, and Blackhole. Androids are a little bit of a special case in which they need to be treated differently than IOS because no two Androids are the same and because the supplicant-provisioning app is required to configure the certificate for Android. Android devices require it to be downloaded from the Android App Store. There are ways to lock the ACL down a bit more but I'm going to be a little more open in my ACLs. Part of the reason is because logging in for BYOD access already requires AD credentials. If you'd like to know the logic behind the ACLs I'm creating, please click here to view the official How To guide. I'm using the ACLs directly from this document. In the wireless controller, I'm going to navigate to Security>Access Control Lists>Accss Control Lists and create the following ACLs: Back in ISE, I'm going to create an ACL for future policies. I'm going to navigate to Policy>Policy Elements>Results>Authorization>Downloadable ACLs and create the following ACL: Name: BLACKHOLE ACL: permit udp any eq bootpc any eq bootps permit udp any any eq domain permit icmp any any permit ip any host 10.1.100.21 deny ip any any Using the ACLs I created both in the wireless controller and in ISE, I'm going to create authorization profiles. I am going to navigate to Policy>Policy Elements>Results>Authorization>Authorization Profiles and create the following profiles: Name: BLACKHOLE Check ACL and choose BLACKHOLE from the drop-down Check Airespace ACL Name and type in BLACKHOLE Note: For extra security, you can also create a blackhole VLAN and add it to this authorization profile Name: BYOD-SUPP Check the box for Web Redirection and from the drop-down, choose Native Supplicant Provisioning. In the ACL section, type in ISE-ONLY. In the Value field, choose BYOD Portal (default) N ame: BYOD-SUPP-ANDROID Check the box for Web Redirection and from the drop-down choose Native Supplicant Provisioning. In the ACL section, type NSP-ACL-GOOGLE . In the Value field, choose BYOD Portal (default) After finishing with our authentication profiles, I will create the reusable compound conditions for my policies. I'll navigate to Policy>Policy Elements>Conditions>Authorization>Compound Conditions and create the following conditions: Name: BYOD-SUPP Conditions: Network Access:EapAuthentication equals EAP-MSCHAPv2 AD1:ExternalGroups equals BYOD-User <- In my policy and possibly even in a production environment, I only want select individuals to be able to utilize BYOD which is why I'm specifying a different group than Domain Users. Name: ANDROID-BYOD-SUPP Conditions: Network Access:EapAuthentication equals EAP-MSCHAPv2 AD1:ExternalGroups equals BYOD-User Session:Device-OS equals Android Name: BYOD-REG Conditions: NetworkAccess:EapAuthentication equals EAP-TLS Endpoints:BYODRegistration equals Yes Now that I've completed the configuration of my policy elements, I'm going to configure the policy now. I'll navigate to Policy>Policy Sets and edit the WirelessDot1x policy I previously created. Under the Authorization Policy, I'm going to add the following rule on the top of all other rules: Rule Name: Wireless-Blacklist If: Blacklist <- Default logical group that should exist in ISE already Then: BLACKHOLE After adding that rule, I'm going to create the following rules under my Vendor-Access rule in the following order: Rule Name: Android BYOD-Supplicant If: Leave at Any Condition(s): Wireless_802.1X and ANDROID-BYOD-SUPP Then: BYOD-SUPP-ANDROID Rule Name: BYOD-Supplicant If: Leave at Any Condition(s): Wireless_802.1X and BYOD-SUPP Then: BYOD-SUPP Rule Name: BYOD-REG If: Leave at Any Condition(s): Wireless_802.1X and BYOD-REG Then: EMPLOYEE-ACCESS Go ahead and make sure the default rule is at DenyAccess After saving the policy, you can test it out by navigating to Operations>RADIUS Livelog and trying to login to the corp SSID with an Android and iOS device. You should see it hitting the BYOD-SUPP-ANDROID policy: After going through the BYOD flow and downloading the Network Assistant Setup from the Google Marketplace, this is what it should show on the RADIUS Livelog: In terms of user experience, this is what the flow looks like from the perspective of the end-user on my Android test device: Step 1 - Redirect and AUP Step 2 - Adding Device Information Step 3 - Prompt and link to install the Cisco Network Assistant from the Google Marketplace Step 4 - Installation of Cisco Network Assistant Step 5- Network Setup Assistant downloads and installs the certificate from ISE Step 6 - Connecting to the Network With iOS devices, the flow is a bit different. From the perspective of the RADIUS Livelog, much is the same: From the user perspective, the flow is almost identical except with Apple, the supplicant is native to Apple IOS so there is no need to download the Network Setup wizard. You will get to Step 3 and this is what it will look like in iOS: Note: I am using the default portal in ISE for BYOD. If you would like to customize it, you may navigate to Administration>Device Portal Management>BYOD to customize this portal. Alternatively, you may use the online ISE portal builder by clicking here and creating a portal you can upload in minutes ... View more

In this next post, I'm going to walk through the policy creation for dot1x for wired and wireless access. As stated in a previous post, I'm going to be using PEAP-EAP-TLS but there are many different methods you can use. I'm also going to configure differentiated access based on a user's role to demonstrate some of the possibilities with ISE. To start building the policy, we're going to have to create the allowed protocol list to use in our policy. If you use the default, you'll be pretty much allowing most protocols for authentication which is usually not preferred. Navigate to Policy>Policy Elements>Results>Authentication>Allowed Protocols and click Add: On this Allowed Protocol list, name it whatever makes sense to you. In this case, I named mine PEAP-EAP-TLS and I unchecked all the boxes, except for EAP-TLS (Used for BYOD in later policies) and PEAP with EAP-TLSand MS-CHAPv2 (Used for later) as the inner method: Create another Allowed Protocols List named HostLookup and only check the box for Process Host Lookup and uncheck everything else. Next we are going to configure the DACLs use in our policy. Navigate to Policy>Policy Elements>Results>Authorization>Downloadable ACLs and click Add. I will create the following DACLs: Name: COMPUTER-ONLY ACL: permit udp any eq bootpc any eq bootps permit udp any any eq domain permit ip any host 10.1.100.40 deny ip any any Name: WLC-ONLY ACL: permit udp any eq bootpc any eq bootps permit udp any any eq domain permit ip any host 10.1.100.41 deny ip any any Name: EMPLOYEE-ONLY ACL: permit udp any eq bootpc any eq bootps permit udp any any eq domain permit ip any host 10.1.100.21 permit ip any host 10.1.100.40 deny ip any host 10.1.10.3 deny ip any 10.1.100.0 255.255.255.0 permit ip any any Name: GUEST ACL: permit udp any eq bootpc any eq bootps permit udp any any eq domain permit ip any host 10.1.100.21 permit ip any host 10.1.100.40 deny ip any 10.0.0.0 255.0.0.0 deny ip any 172.16.0.0 255.240.0.0 deny ip any 192.168.0.0 255.255.0.0 permit ip any any Name: ADMIN-ACCESS ACL: permit ip any any The next thing I'm going to do is to create my authorization profiles. These profiles are used as the in your authorization policy to essentially give permissions to the endpoint. Some of the more commonly used attributes in an authorization profile are: DACL VLAN Voice Domain Permission Posture Discovery Centralized Web Authentication Auto SmartPort Filter-ID Reauthentication MACSec Policy NEAT Local Web Authentication Wireless Controller ACL ASA VPN There's a lot of options you can choose and configure in an authorization profile and I might go into them in more detail in future posts but for now I'm going to use some of the more common attributes that you'd see in a typical enterprise environment such as DACL, VLAN assignment, etc. To create our authorization profiles, I'm going to navigate to Policy>Policy Elements>Results>Authorization>Authorization Profiles and click Add During my creation of my authorization profile, I usually create it so that I can use for both my wired and wireless policies if possible. For my lab, I'm going to create several authorization profiles with the following elements: Name: AD-ONLY - Check DACL Name and choose COMPUTER-ONLY from the drop-down. This is for wired access - Check VLAN and choose ID/Name 50 - Check the box next to Airespace ACL Name and enter COMPUTER-ONLY <- this is the ACL we configured in the WLC previously. As I stated in the previous post, the wireless controller does not support dACLs so we have to let the WLC know which ACL to use locally. Name: GUEST-ACCESS - Check DACL Name and choose GUEST from the drop-down - Check VLAN and choose ID/Name 70 - Check the box next to Airespace ACL Name and enter GUEST Name: ADMIN-ACCESS - Check DACL Name and choose ADMIN-ACCESS - Check VLAN and choose ID/Name 50 - Check the box next to Airespace ACL Name and enter ADMIN-ACCESS Name: WLC-ONLY <- This will be used later for our profiling policy in a later post - Check DACL Name and choose WLC-ONLY - Check VLAN and choose ID/Name 100 The next thing I'm going to configure is the authorization conditions for our policy. These rule-based conditions form the basis of the ISE policies. A simple condition consists of an attribute, operator, and a value.  Compound conditions are typically made up of two or more simple conditions. Most of the time, your ISE policy is built from compound conditions. You can create conditions from within the policy pages or as separate policy elements to be reused by other types of ISE policies. For the purposes of troubleshooting policies, it's typically better to create your conditions on the policy set itself but to make the policy more readable and neater, creating the reusable conditions is better. You have to decide which way is "right" for you but I personally do not see either way as a wrong way of doing it. In my lab, I'm going to create the reusable compound conditions to later use in my policy. To do so, navigate to Policy>Policy Elements>Authorization>Compound Conditions and click Add. I am going to create the following compound conditions: Name: WIRED-MACHINE-DOT1X Conditions: Radius:Service-Type equals Framed Radius:NAS-Port-Type equals Ethernet ad1:ExternalGroups equal Domain Computers Network Access:EapTunnel equals PEAP <- This is to specify that the outer authentication method is PEAP Network Access:EapAuthentication equals EAP-TLS <- This is specifying the inner authentication method as EAP-TLS Name: WIRED-ADMIN-DOT1X Conditions: Radius:Service-Type equals Framed Radius:NAS-Port-Type equals Ethernet ad1:ExternalGroups equals Domain Admins Network Access:EapTunnel equals PEAP Network Access:EapAuthentication equals EAP-TLS Name: WIRED-EMPLOYEE-DOT1X Conditions: Radius:Service-Type equals Framed Radius:NAS-Port-Type equals Ethernet ad1:ExternalGroups equals Employee Network Access:EapTunnel equals PEAP Network Access:EapAuthentication equals EAP-TLS Name: WIRED-VENDOR-DOT1X Conditions: Radius:Service-Type equals Framed Radius:NAS-Port-Type equals Ethernet ad1:ExternalGroups equals Vendor Network Access:EapTunnel equals PEAP Network Access:EapAuthentication equals EAP-TLS Name: WIRELESS-MACHINE-DOT1X Conditions: Radius:Called-Station-ID Ends With SecurityLabCorp <- If you remember when we configured our WLC, we specified the Called-Station ID as AP Mac Address:SSID in our AAA RADIUS server configuration. Because of that, we can pull out the SSID that the endpoint is connected to from the RADIUS request and make policies based upon that. Since the Called-Station-ID includes the AP MAC address as well, you want to make sure you specify "Ends With" here or else condition will fail. Radius:NAS-Port-Type equals Wireless - IEEE 802.11 ad1:ExternalGroups equals Domain Computers Network Access:EapTunnel equals PEAP Network Access:EapAuthentication equals EAP-TLS Name: WIRELESS-ADMIN-DOT1X Conditions: Radius:Called-Station-ID Ends With SecurityLabCorp Radius:NAS-Port-Type equals Wireless - IEEE 802.11 ad1:ExternalGroups equals Domain Admins Network Access:EapTunnel equals PEAP Network Access:EapAuthentication equals EAP-TLS Name: WIRELESS-EMPLOYEE-DOT1X Conditions: Radius:Called-Station-ID Ends With SecurityLabCorp Radius:NAS-Port-Type equals Wireless - IEEE 802.11 ad1:ExternalGroups equals Employee Network Access:EapTunnel equals PEAP Network Access:EapAuthentication equals EAP-TLS Name: WIRELESS-VENDOR-DOT1X Conditions: Radius:Called-Station-ID Ends With SecurityLabCorp Radius:NAS-Port-Type equals Wireless - IEEE 802.11 ad1:ExternalGroups equal Vendor Network Access:EapTunnel equals PEAP Network Access:EapAuthentication equals EAP-TLS Now I'm going to be creating my policy from the elements we previously created. Navigate to Policy>Policy Sets and click on + on the left-hand side to create a new policy set. For my policy set, I'm going to create it for wireless dot1x so I'm going to name it WirelessDot1x . Since I'm using policy sets in my ISE deployment, I need to create a top-level condition or conditions to be met in order for this policy set to be used. For the top-level conditions, I will choose the following: Device:Device type equals Wireless Controllers Radius:Called-Station-ID ends with SecurityLabCorp [Alternatively, you could also use the existing simple condition of WirelessDot1x ] Under the Authentication Policy, click on the arrow next to the default policy and choose Insert new row above. The policy logic is simple: If {condition} then {result}. In the case of authentication policy, it'sFor this authentication policy, I created the following policy: Name: Dot1x- If Wireless_802.1x (Add Condition From Library>Compound Condition - This is a prebuilt condition in the existing library) then Allowed Protocols: PEAP-EAP-TLS (Allowed Protocol list we created before) At this point, I would click on the Action downward arrow and choose to Insert Row Below. This is where I would get more specific with my rules and conditions. I would add the following rows: Name: AD Certificate, If Network Access:Authentication Method EQUALS x509_PKI ANDCERTIFICATE:Subject Alternative Name CONTAINS securitydemo.net then use AD_CA_AltName <- which specifies to user just the CA for this authentication. Name: BYOD Certificate, If Network Access:Authentication Method EQUALS x509_PKI then use Cert_CommonName <- this specifies to use the BYOD certificate Default: Ad1 <- AD as the catchall for this ruleset On the Default Rule, I'm going to change it to use the ALL_IDENTITY_SEQ sequence we previously created. In a production environment, you would probably lock this down more. Next, I am going to create the Authorization Policy and click on the arrow next to the Default Policy and choose Insert new row above. The policy logic is still the same as the above. In this policy, I'm going to create the following policies in the following order: Rule Name: Computer-Only If: Leave at Any Condition(s): Select Condition from Library>Compound Conditions>WIRELESS-MACHINE-DOT1X Then: Standard>AD-ONLY Rule Name: IT-Admin-Access If: Leave at Any Condition(s): Select Condition from Library>Compound Conditions>WIRELESS-ADMIN-DOT1X Then: Standard>ADMIN-ACCESS Rule Name: Employee-Access If: Leave at Any Condition(s): Select Condition from Library>Compound Conditions>WIRELESS-EMPLOYEE-DOT1X Then: Standard>EMPLOYEE-ACCESS Rule Name: Vendor-Access If: Leave at Any Condition(s): Select Condition from Library>Compound Conditions>WIRELESS-VENDOR-DOT1X Then: Standard>GUEST-ACCESS Click Save to save your policy set. We can test out this policy by navigating to Operations>RADIUS Livelog. You can have a test computer that's already joined to the domain and has the certificate pushed down from the group policy. If everything is working correctly, you should see it automatically jumping on the wireless and accepted thanks to the group policy setting the dot1x policy on the wireless NIC and telling the computer to automatically connect to the SSID when it's seen. Depending on which AD user you're signed in as, you should see a different authorization profile assigned by user: Now try logging off the computer as the user but leaving the computer turned on. If everything is configured correctly, the computer should be granted access based on the AD-ONLY authorization profile which means the computer has access to AD only for authentication/GPO/patching/etc like you would want it to have in a production environment: Now we're going to create another policy set which will do the same thing for wired access. Navigate to Policy>Policy Sets and click on + to create a new policy set. This time I am going to name it Wired and have it match the following for the top-level condition: Device Type equals Switches NAS-Port-Type equals Ethernet Under the Authentication Policy, we're going to create a top condition for MAB. This will come in handy later for profiling and other things: Name: Wired MAB If Condition(s): Select Existing Condition>Compound Condition>Wired_MAB Allowed Protocols: HostLookup Use: Internal Endpoints and If User Not Found Continue I'll create another authentication policy rule for dot1x under the MAB policy. The authentication policy will be: Name: Wired Dot1x If Condition(s): Select Existing Condition From Library>Compound Conditions>Wired_802.1x Allowed Protocols: PEAP-EAP-TLS At this point, I would click on the Action downward arrow and choose to Insert Row Below. This is where I would get more specific with my rules and conditions. I would add the following rows: Name: AD Certificate, If Network Access:Authentication Method EQUALS x509_PKI ANDCERTIFICATE:Subject Alternative Name CONTAINS securitydemo.net then useAD_CA_AltName <- which specifies to user just the CA for this authentication. Name: BYOD Certificate, If Network Access:Authentication Method EQUALS x509_PKI then useCert_CommonName <- this specifies to use the BYOD certificate Default: Ad1 <- AD as the catchall for this ruleset On the Default Rule, I'm going to change it to use the ALL_IDENTITY_SEQ sequence we previously created. In a production environment, you would probably lock this down more. Moving onto the authorization policy, I'm going to create the following policy rules: Rule Name: Computer-Only If: Leave at Any Condition(s): Select Condition from Library>Compound Conditions>WIRED-MACHINE-DOT1X Then: Standard>AD-ONLY Rule Name: IT-Admin-Acess If: Leave at Any Condition(s): Select Condition from Library>Compound Conditions>WIRED-ADMIN-DOT1X Then: Standard>ADMIN-ACCESS Rule Name: Employee-Access If: Leave at Any Condition(s): Select Condition from Library>Compound Conditions>WIRED-EMPLOYEE-DOT1X Then: Standard>EMPLOYEE-ACCESS Rule Name: Vendor-Access If: Leave at Any Condition(s): Select Condition from Library>Compound Conditions>WIRED-VENDOR-DOT1X Then: Standard>GUEST-ACCESS Editors note: Ignore the CiscoAP rule. That's part of my profiling policy that I'll show later Click Save to save your policy set. You can once again test this policy by using the same domain PC that used in the previous policy set test and plug it into one of the dot1x ports on the switch we previously configured. After doing so, navigate to Operations>RADIUS Livelog in ISE. If you haven't logged into the PC but it's turned on, you should see the AD-Only authorization profile being assigned to the endpoint: After logging into the computer, you should see the profile change and access granted based on the user you log in as: That concludes our dot1x policy creation! In this post, we did quite a bit: We created reusable conditions, DACLS we will condition to use in other policies, and authorization profiles. After that, we used a combination of those policy elements to create our policy and then test it. ... View more

In this post, I am going to configure my wireless controller to use ISE for AAA, set up my SSIDs, and configure other basic settings. I'm going to start from the initial installation of the Virtual Wireless Controller and go through those steps. After I have that completed, I will set up all the initial configurations you will need in order to have the Wireless Controller use ISE. For this lab, I imported the vWLC importing the OVA into my ESXi environment. Before starting the virtual machine, I made sure to edit the settings on the network adapter of the VM to ensure they are trunk ports. After configuring the network adapters, start the VM. Console into the VM and you should be able to start the setup script for your Wireless Controller. This is what I put down for each option: Would you like to terminate autoinstall? - yes System Name: vWLC Administrative User Name: admin Administrative Password: networknode Service IP Address Configuration: static Service Interface IP address: 1.1.1.1 Service Interface Netmask: 255.255.255.252 Management Interface IP Address: 10.1.100.41 Management Interface Netmask: 255.255.255.0 Management Interface Default Router: 10.1.100.1 Management Interface VLAN Identifier: 100 Management Interface Port Number: 1 Management Interface DHCP Service IP Address: 10.1.100.1 Virtual Gateway IP Address: 2.2.2.2 Mobility/RF Group Name: MobilityGroup Network Name (SSID): SecurityLabCorp Configure DHCP Bridging Mode: Yes Allow Static IP Addresses: Yes Configure a RADIUS Server: No Country Code: US Enable 802.11b: Yes Enable 802.11a: Yes Enable 802.11g: Yes Enable Auto-RF: Yes Configure NTP Server: Yes NTP Server IP address: 24.56.178.140 Polling Interval: 3600 Configure IPv6? No Save Configuration? Yes After the Wireless Controller has finished installing, navigate to the Wireless Controller GUI through the browser at https://management-ip-address/ and login with the credentials you created in the previous step. Click on the Advanced link to navigate to the advanced settings If you are using an evaluation version of the wireless controller or you need to add your licenses, navigate to Management>Software Activation>Licenses and under Adder Licenses , add 5 licenses and click Set Count . Accept the EULA that pops up: I usually like to put my access point on the same subnet as the wireless controller so I don't have to configure anything special in my DHCP pool to let the AP know where the wireless controller is. This is also a lab environment so I'm keeping it as simple as possible. If your AP does not associate with your wireless controller, check the following: That the AP is getting an IP address That you have licenses on the wireless controller Console into the AP and login with the default credentials of Cisco/Cisco. Enter EXEC mode and issue the following commands: clear capwap private-config clear lwapp private-config reload If the above does not work, check the wireless controller logs by navigating toManagement>Logs>Messages Logs in the WLC GUI to see if you can determine if the wireless controller is seeing the AP trying to associate with it. Look at the console output of the AP and see if there are any messages or warnings that indicate what the problem is. If that does not work, check the version number of firmware of the AP. Some older APs have expired certificates or require a complete wipe and restore After the AP has associated itself to the wireless controller, navigate to Wireless>Access Points and click on the AP: If the AP has been previously joined to another wireless controller and still has leftover settings, I would recommend performing a hardware reset of the AP on this menu. If everything appears to be fine, choose FlexConnect from the AP Mode drop-down in this menu and click Save . If you don't change the AP Mode to FlexConnect, you will have issues with trying to broadcast SSIDs so that's important to change. Enable Fast SSID Change as well. When this is enabled, the controller allows clients to move between SSIDs quicker. The way it does so is that when a client sends a new association for a different SSID, the client entry in the controller table is cleared before the client is added to the new SSID. To enable this setting, navigate to Controller>General and make sure that the Fast SSID Change is enabled. It's recommended to disable DHCP Proxy on your wireless controller so you can have DHCP in bridging mode and have all the DHCP packets from the wireless clients forwarded to ISE. You can do this on a per-interface basis or globally on the wireless controller. Since this a lab environment, I am going to disable it globally by navigating to Controller>Advanced>DHCP and unchecking the box next to Enable DHCP Proxy. Click Save. ISE will use SNMP to query the wireless controller for certain attributes to help identify and profile the endpoints that connect to the network. In order to enable this, we will need to configure SNMP communities on the WLC. Navigate to Management>SNMP>General and ensure that SNMP v2 is enabled: After that, I will navigate to Management>SNMP>Communities and delete the two default community strings. After clicking New to create a new community string, I use the SNMP community string I configured in ISE (networknode) and I configure the IP address with the address of my ISE server. I also make sure that the status of this community is Enabled : Next, I navigate to Management>SNMP>Trap Recievers and click New again. I use networknode as my commumity name, put the IP address of my ISE node in and make sure that the status is set to Enable before I apply my changes: Now that I've set up SNMP, I'm going to configure ISE as my RADIUS server on the wireless controller. Navigate to Security>RADIUS>Authentication. On this page, we'll make sure that Auth Called Station ID Type is set to AP MAC Address:SSID in the drop-down. Click New . On this New RADIUS Authentication Server page, I ensure that the following is configured: New RADIUS server is the IP address of my ISE server I am using the shared secret that I previously configured in ISE for this NAD (networknode). I'm ensuring that Enable is selected in the drop-down for RFC 3576 - This is the RFC for Dynamic Authorization Extensions The port number for is 1812 Server Status is Enabled The Management box is unchecked: After completing the Authentication configuration, navigate to Security>RADIUS>Accounting . On this page, ensure that the Auth Called Station ID Type is AP MAC Address: SSID from the drop-down. Click New . On the New RADIUS Accounting Servers page, I'm going to configure ISE as my RADIUS server with the following settings: IP address of ISE Shared secret that I previously configured in ISE for this NAD Server Status is Enabled The port number is 1813 Network User is checked: Now that I've configured the RADIUS AAA servers on the wireless controller, I'm going to configure my interfaces. Navigate to Controller>Interfaces and click New to adda new interface. In this scenario, the VLAN is going to be my User VLAN (VLAN 50). For your own lab or production network, give the interface a name and VLAN ID that makes sense to you: After clicking Apply, I will find myself in the Edit Interfaces page. On this page, I can specify the port number on the wireless controller for this interface ("1"), configure the interface IP address, subnet mask and default gateway. I can also specify a DHCP server as well as enabling or disabling DHCP Proxy Mode. The default should be "Global" but if you are in a production environment and don't want to globally disable it like I did, I would recommend just changing it on the interface itself that you're going to use for the ISE SSIDs: Not pictured here but in my lab, I created another interface for the Guest VLAN (VLAN 70). After I finished configuring it, I wanted to make sure all my interfaces were in an interface group so I navigated to Controller>Interface Groups and clicked New. I made sure to add all my interfaces to this new interface group: In the current and previous versions of code, wireless controllers have never supported dACLs. Because of that, we still need to define ACLs on our wireless controller. ISE can still use these ACLs as long as we call it out by name in the Authorization Profiles that we create in ISE. I'll go over this in more detail in my next blog post but it's something to be aware of. I'm going to navigate to Security>Access Control Lists>Access Control Lists and click New. These are the ACLs I'm going to start with and I'll try to explain the logic in each. Note: The WLC's perspective of Inbound/Outbound is nonintuitive. It's from the perspective of the WLC facing towards the wireless client, NOT from the perspective of the client. So inbound direction means a packet coming from your endpoint to your wireless client and outbound means a packet coming from the WLC to the client. This is the ACL that will be used for my WebAuth redirects in the future. Here's the breakdown of the rules: 1 - Allows the endpoint to get an IP address 2 - Allows the endpoint to use DNS which will be necessary to communicate with ISE 3 - Allows the endpoint to communicate with ISE 4 - Allows outbound traffic from my server subnet to the client. This could be DNS and DHCP relies or anything coming from ISE. You can lock this down more if you'd like but in my next ACE, I lock down any other traffic leaving the endpoint. 5 - Everything else is denied This is the ACL Iwill use for corporate computers that a user is not logged into. Typically, you don't want your corporate PCs to have no access at all to the network if no one is logged into them since you would still want them to receive group policy updates, patches, etc and prevent "chicken before the egg" scenarios with new users trying to authenticate to the network. Here's a breakdown of the rules: 1- Allows the endpoint to get an IP address 2- Allows the endpoint to use DNS 3- Allows the endpoint to communicate with ISE 4- Allows the endpoint to receive traffic from my server subnet 5 - Everything else is denied This rule is a lot like my ISE-Only rule but in a production environment, you might be specifying specific AD and WSUS servers instead of the blanket ACEs I used for a lab. You also might specify specific ports (i.e. "389"). My lab is a lot simplier so I just re-used rules from my previous ACL but a production environment will likely look different and for the purposes of organizing my rules, I wanted a separate ACL for this purpose. This is going to be my ACL for employees. I denied them for certain devices just to show that ISE was providing differentiated access based on the user's role. Here's a breakdown of the rules: 1 - Allows an endpoint to get an IP address 2 - Allows an endpoint to use DNS 3 - Allows an endpoint to communicate with ISE 4 - Allows an endpoint to communicate with my AD server 5 - Allows an endpoint to receive traffic from my server subnet 6 - Denies my employee endpoint from talking to my ESXi host because I've determined that my regular employees shouldn't log into ESXi 7 - Denies my employee from sending traffic to the rest of my server subnet since there is no reason they should be trying to communicate with the rest of the servers on that subnet. 8 - Permits everything else This is my ACL for guest on the network. Here's a breakdown of the rules: 1 - Allows an endpoint to get an IP address 2 - Allows an endpoint to use my DNS server 3 - Allows an endpoint to communicate with my ISE server - This could be locked down further to ports 8443. 8449, etc but this is a lab so I'm not going to worry as much about it. 4 - This permits traffic back from any 10.0.0.0/8 subnet to this endpoint. 5 - This permits this endpoint to communicate with my AD server - You can lock this down if you want but if you want to force updates or posturing for even your clients, I typically use my AD server in the environment to push them down. In a production network, you would NOT be doing this and it's safe to remove this rule in your own lab. 6- Denies the endpoint from reaching any of my internal subnets - You could further add more ACEs that include other RFC 1918 addresses but I'm only using the 10.0.0.0/8 space so there was no need for my lab 7 - Permits everyth ing else so the Guest has internet access This one is pretty self-explanatory. I'm going to let my domain admins have access to everything. In production, you would probably want to lock this down. Typically, it's best practice to give your domain admins an account for every day use (non-Domain Admin user) and an account that's part of the Domain Admins group which they can use for specific purposes. If you're in an environment like this, you might want to create the above rule permitting access to all internal resources but blocking access to external ones like the internet Now that we've finished creating our ACLs, I'm going to move onto creating my SSIDs. Navigate to WLANs and you can click on the WLAN name you created during setup of the wireless controller or click New to create a new one. Either way, you will be in the Edit page for this SSID. Typically, I like to make sure the SSID is enabled and for the interface, I put this SSID in the interface group that I just created: Next, I'll move to Security>AAA Servers on this Edit page. Make sure the Authentication and Accounting Servers are enabled and choose your ISE server from the drop-down for both. If you have multiple ISE PSNs configured, you would add them here as well: On the Edit page, navigate to the Advanced tab. This is typically what I change on this page: Check the box next to Allow AAA Override Check the DHCP Addr Assignment box Change the NAC State to Radius NAC in the drop-down Uncheck the box next to Flexconnect Local Switching - This is only for my lab environment. Production *will* be different. Under Radius client profiling, check the boxes for both HTTP and DHCP profiling Click Apply when done. I am going to add Guest and Hotspot SSIDs. From the WLANs page, click New and create the following: I'm going to change the interface group again to the group I previously created as well as enabling the SSID: The big key difference on this SSID is that on Security>Layer 2 , I'm going to change the following: Set Layer 2 Security to None in the drop-down Check the box next to MAC Filtering Check the box next to Fast Transition Uncheck the box for Over the DS : On the Security>AAA Servers tab, I'm going to add my ISE servers just like I did in the previous SSID: On the Advanced tab, the configuration is exactly the same as the previous SSID: For the Hotspot SSID, the configuration is exactly the same as the Guest SSID. The only difference will be the name so if you would like to configure that SSID, feel free to repeat the last few steps. I won't go through the steps of creating that SSID since it would just be repetitive at this point. The last thing we will need to do on this WLC to set it up is configure Web-Auth Captive-Bypass. The reason this is important is because certain devices (i.e. Apple iOS devices) have a mechanism for which they can determine that a device is connected to the internet, based on an HTTP WISPr request made to a designated URL. This mechanism is used for the device to automatically open a web browser when a direct connection to the internet is not available and enables the user to provide his/her credentials to access the internet. This HTTP request triggers the web authentication interception in the controller as any other page requests are performed by a wireless client and this leases to a regular web authentication request. Problem is that if the web authentication is being used with any of the controller splash page features (i.e URL provided by a configured RADIUS server - or ISE in our case), the splash page may never be displayed because the WISPr requests are made at very short intervals and as soon as one of these queries is able to reach the designated server, any web redirection or splash page display process that is performed in the background is aborted and the device processes the page request which results in breaking the splash page functionality. To avoid issues, it's best practice to configure the controller to bypassthe WISPr detection process so the web authentication interception is only done when a user requests a web page leading to a splash page load in user context. To do this, login to the CLI of the wireless controller. Enter the following command: config network web-auth captive-bypass enable Back on your WLC GUI, click on the Save Configuration link on the top of the screen. This will save your configuration so it will be intact on the next reboot. Then navigate to Commands>Reboot and choose Reboot . ... View more

In this blog post, I'm going to set up my 3650 switch with basic Layer 2, Layer 3 and dot1x configurations. I'll walk through some of the basic configurations and explain why I'm configuring it as I am. I'm starting with a completely unconfigured switch so to start, I like to configure it with a username, SSH, etc: conf t username admin privilege 15 password networknode enable password networknode ip domain-name securitydemo.net ip domain-lookup ip name-server 10.1.100.40 hostname Sw1 crypto key gen rsa 1024 ip ssh version 2 ip ssh authentication-retries 2 line vty 5 15 transport input ssh login local Next, I'll configure the my Layer 3 configuration. I also include an ip helper-address to the ISE server (10.1.100.21) so ISE can collect additional DHCP profiling information: ip routing vlan 10 name MGMT vlan 50 name USER_VLAN vlan 70 name GUEST_VLAN vlan 100 name SERVER_VLAN interface vlan 10 ip address 10.1.10.1 255.255.255.0 ip helper-address 10.1.100.21 no shut interface vlan 50 ip address 10.1.50.1 255.255.255.0 ip helper-address 10.1.100.21 no shut interface vlan 70 ip address 10.1.70.1 255.255.255.0 ip helper-address 10.1.100.21 no shut interface vlan 100 ip address 10.1.100.1 255.255.255.0 ip helper-address 10.1.100.21 no shut ip route 0.0.0.0 0.0.0.0 10.1.10.99 <- This is the inside interface of my ASA 5506 ip ftp source-interface vlan100 ip tftp source-interface vlan100 For ports that are directly connected to my server and ASA, I'll start by giving them a base configuration without restriction. In a production environment, you usually have policies already set up and you can restrict this with d0t1x and profiling but in my lab, I don't have any policies set up yet so I need these servers and the ASA to continue to have access: interface range g1/0/1-6 switchport switchport mode trunk switchport trunk native vlan 10 spanning-tree portfast trunk no shut The next thing I configure is DHCP. In a production environment, you usually see DHCP centralized on a server and I could easily do so for my lab as well. I would only need to add a second ip helper address to make it work but for the save of simplicity, I'll just go ahead and configure it locally on the switch: ip dhcp excluded-address 10.1.10.1 10.1.10.100 ip dhcp excluded-address 10.1.50.1 10.1.50.100 ip dhcp excluded-address 10.1.70.1 10.1.70.100 ip dhcp excluded-address 10.1.100.1 10.1.100.100 ip dhcp pool VLAN10 network 10.1.10.0 255.255.255.0 dns-server 10.1.100.40 <-- My AD server default-router 10.1.10.1 ip dhcp pool VLAN50 network 10.1.50.0 255.255.255.0 dns-server 10.1.100.40 default-router 10.1.50.1 ip dhcp pool VLAN70 network 10.1.70.0 255.255.255.0 dns-server 10.1.100.40 default-router 10.1.70.1 ip dhcp pool VLAN100 network 10.1.100.0 255.255.255.0 dns-server 10.1.100.40 default-router 10.1.100.1 Next we are going to configure our AAA commands which basically will configure ISE as the RADIUS server on the switch and it should use ISE for network AAA. I will also configure the switch to send certain RADIUS attributes to ISE. Note: ISE uses ports 1812 and 1813 for authentication and accounting. Older RADIUS devices have been known to use ports 1645 and 1646 for these ports. This is not the case with ISE: aaa new-model radius server ise address ipv4 10.1.100.21 auth-port 1812 acct-port 1813 key networknode <- This is the shared key that we configured on ISE when we added this NAD radius-server dead-criteria tries 3 <- Sets the condition to determine when a RADIUS server is considered unavailable. With this configuration, the switch dynamically tries 3 times radius-server deadtime 30 <- Sets the number of minutes during which a RADIUS server is not sent requests. aaa group server radius ise-group server name ise <- We configure this a few lines back. If you have multiple ISE nodes, you'd add them all to this RADIUS group aaa authentication login console local <- Going to keep console login local for now aaa authentication login vty local <- Keeping VTY login local as well for now aaa authentication enable default enable aaa authorization exec default local <- Keeping EXEC mode local for now aaa authentication dot1x default group ise-group <- Specifying to use our RADIUS group for dot1x authentication aaa authorization exec vty local <- Keeping EXEC VTY authorization local for now aaa authorization network default group ise-group <- Specifying our RADIUS group for network authorization aaa authorization auth-proxy default group ise-group <- Required for VLAN/ACL assignment aaa accounting dot1x default start-stop group ise-group <- Specifying our RADIUS group for dot1x accounting aaa accounting auth-proxy default start-stop group ise-group  <- Enables accounting for dynamic ACLs and VLANs that can be downloaded aaa session-id common aaa accounting update periodic 5 <- Updates the accounting information periodically every 5 minutes aaa server radius dynamic-author <- This enables ISE to act as an AAA server when interacting with the client client 10.1.100.21 server-key networknode <- Use the same password you set up in ISE server-key networknode <- You may not need to do this with your version of IOS but I noticed that in XE 3.07.01E, I had to add this extra separate line with the server key radius-server vsa send accounting <- Tells the switch to send accounting vendor-specific attributes radius-server vsa send authentication <- Tells the switch to send authentication vendor-specific attributes Note: To see a list of vendor-specific attributes, check out this list here radius-server attribute 6 on-for-login-auth <- Used to identify the Service-Type this RADIUS request is used for radius-server attribute 6 support-multiple <- Supports multiple Service-Type values for each RADIUS profile radius-server attribute 8 include-in-access-req <- This is to send the IP address of a user to the RADIUS server in the access request. radius-server attribute 25 access-request include <- This is to  include the class attribute in the access request which specifies the authorization action radius-server attribute 31 mac format ietf upper-case <- This is to specify the MAC address in the Calling Station ID. I recommend using IETF on this one radius-server attribute 31 send nas-port-detail <- This includes all NAS port details in the Calling Station ID ip radius source-interface vlan 100 captive-portal-bypass <- This might only be necessary if you are using your 3650 as a wireless controller as well. I'll explain this command a bit more in the WLC configuration post. dot1x system-auth-control <- Globally enables 802.1x SystemAuthControl (port-based authentication) Now that I'm done with the RADIUS configuration, I'm going to add SNMP, logging, and additional configurations to provide ISE more details about the endpoints that connect to this switch. I like to configure the switch to send MAC notifications, syslog logging and SNMP so the ISE profiler is able to collect information on the network endpoints: mac address-table notification change mac address-table notification mac-move mac address-table notification change interval 0 authentication mac-move permit <- Enables MAC move on a switch between any authentication-enabled ports (MAB, 802.1X or Web-Auth) snmp-server enable traps mac-notification change move threshold snmp-server enable traps mac-notification change snmp-server enable snmp linkdown linkup snmp-server host 10.1.100.21 version 2c networknode mac-notification snmp-server community networknode ro <- This is the SNMP community string we previously configured in ISE no snmp-server group networknode v1 snmp-server trap-source vlan100 snmp-server source-interface inform vlan100 lldp run logging origin-id ip <- This specifies that the IP address of the sending interface will be used as the message origin identifier logging source vlan100 logging host 10.1.100.21 transport udp port 20514 logging monitor informational no ip dhcp snooping information option <- Disables the switch from adding Option 82 into the packet before forwarding it to ISE. If this option is enabled, it will send the giaddr field with a zero value to ISE. ip dhcp snooping ip dhcp snooping vlan 10,50,70,100 epm logging <- Sets up standard logging functions on a switch to support possible troubleshooting/recording for ISE functions ip device tracking <- This allows the switch to maintain an IP device tracking table. You must enable this feature to use web-based authentication ip device tracking probe use-svi <- This configures the with to send an non-RFC compliant ARP Probe. The IP source will not be 0.0.0.0 but it will be the SVI in the VLAN where the host resides. If it's a Windows machine, it'll no longer see the probe as defined by RFC 5227 and therefore will not flag a potential duplicate IP device-sensor accounting <- This command enables the addition of sensor protocol data to account records and enables the generation of additional accounting events when new sensor data is detected. device-sensor notify all-changes <- Enables client notifications and accounting events for all TLV changes where either a new TLV is received or a previously received TLV is received with a new value in the context of a given sessions. In order to have URL-Redirection on the switch for Web-Auth, you must enable HTTP/HTTPs on the switch. You also need to define ACL local default ACLs on your switch: ip http server ip http secure-server ip access-list ext ACL-DEFAULT deny udp any any eq domain deny udp any eq bootpc any eq bootps deny tcp any host 10.1.100.21 eq 8443 deny tcp any host 10.1.100.21 eq 8905 permit tcp any any eq 80 permit tcp any any eq 443 deny ip any any Note: This ACL-DEFAULT ACL will be for our WebAuth Redirect. Whatever is "permitted" in this list will be redirected so in order to have the computer get an IP address, be able to use DNS and access ISE, we must create "deny" statements. You can lock this down further by configuring the allowed ports between ISE and the device to be 8443 and 8905 which would be the WebAuth portals. The logic of the ACL is a little backwards compared to what you think of when you think of an ACL but it's only for the WebAuth for the switches. The last thing I will do is configure the interfaces that will be ISE-protected. In the following configuration, I will break it up a bit to explain what I am configuring on the port-level: interface range g1/0/7-48 description ISE dot1x Port switchport access vlan 70 switchport mode access spanning-tree portfast spanning-tree bpduguard enable Under the port configuration, the following set of commands enables re-authentication via RADIUS Session-Timeout: authentication event fail action next-method authentication event server dead action reinitialize vlan 50 authentication event server dead action authorize voice authentication timer reauthenticate server authentication timer inactivity server The following command allows voice and multiple endpoints on the same physical access port: authentication host-mode multi-auth This command enables pre-auth access before AAA response which is subject to the port ACL: authentication open These commands are here to specify that IOS Flex-Auth authentication should perform 802.1X first and then MAB: authentication order dot1x mab authentication priority dot1x mab These commands enable port-based authentication on the interface: authentication port-control auto authentication violation restrict This command enables re-authentication on the interface: authentication periodic This command enables MAC Authentication Bypass (MAB) on the interface: mab This command enables 802.1x authentication in the interface: dot1x pae authenticator This command sets the retransmit period to 10 seconds: dot1x timeout tx-period 10 These commands enable the SNMP trap for added and removed MACs on the interface: snmp trap mac-notification change added snmp trap mac-notification change removed We configure the default ACL on the interface which will prepend dACLs from the ISE server: ip access-group ACL-DEFAULT in In the end, the final configuration should resemble the following: username admin privilege 15 password networknode enable password networknode ip domain-name securitydemo.net hostname Sw1 crypto key gen rsa 1024 ip ssh version 2 ip ssh authentication-retries 2 line vty 5 15 transport input ssh login local ip routing vlan 10 name MGMT vlan 50 name USER_VLAN vlan 70 name GUEST_VLAN vlan 100 name SERVER_VLAN interface vlan 10 ip address 10.1.10.1 255.255.255.0 ip helper-address 10.1.100.21 no shut interface vlan 50 ip address 10.1.50.1 255.255.255.0 ip helper-address 10.1.100.21 no shut interface vlan 70 ip address 10.1.70.1 255.255.255.0 ip helper-address 10.1.100.21 no shut interface vlan 100 ip address 10.1.100.1 255.255.255.0 ip helper-address 10.1.100.21 no shut ip route 0.0.0.0 0.0.0.0 10.1.10.99 <- This is the inside interface of my ASA 5506 ip ftp source-interface vlan100 ip tftp source-interface vlan100 interface range g1/0/1-6 switchport switchport mode trunk switchport trunk native vlan 10 spanning-tree portfast trunk no shut ip dhcp excluded-address 10.1.10.1 10.1.10.100 ip dhcp excluded-address 10.1.50.1 10.1.50.100 ip dhcp excluded-address 10.1.70.1 10.1.70.100 ip dhcp excluded-address 10.1.100.1 10.1.100.100 ip dhcp pool VLAN10 network 10.1.10.0 255.255.255.0 dns-server 10.1.100.40 <-- My AD server default-router 10.1.10.1 ip dhcp pool VLAN50 network 10.1.50.0 255.255.255.0 dns-server 10.1.100.40 default-router 10.1.50.1 ip dhcp pool VLAN70 network 10.1.70.0 255.255.255.0 dns-server 10.1.100.40 default-router 10.1.70.1 ip dhcp pool VLAN100 network 10.1.100.0 255.255.255.0 dns-server 10.1.100.40 default-router 10.1.100.1 aaa new-model radius server ise address ipv4 10.1.100.21 auth-port 1812 acct-port 1813 key networknode radius-server dead-criteria tries 3 radius-server deadtime 30 aaa group server radius ise-group server name ise aaa authentication login console local aaa authentication login vty local aaa authentication enable default enable aaa authorization exec default local aaa authentication dot1x default group ise-group aaa authorization exec vty local aaa authorization network default group ise-group aaa authorization auth-proxy default group ise-group aaa accounting dot1x default start-stop group ise-group aaa accounting auth-proxy default start-stop group ise-group aaa session-id common aaa accounting update periodic 5 aaa server radius dynamic-author client 10.1.100.21 server-key networknode server-key networknode radius-server vsa send accounting radius-server vsa send authentication radius-server attribute 6 on-for-login-auth radius-server attribute 6 support-multiple radius-server attribute 8 include-in-access-req radius-server attribute 25 access-request include radius-server attribute 31 mac format ietf upper-case radius-server attribute 31 send nas-port-detail ip radius source-interface vlan 100 captive-portal-bypass system-auth-control mac address-table notification change mac address-table notification mac-move snmp-server enable snmp linkdown linkup snmp-server host 10.1.100.21 version 2c networknode mac-notification snmp-server community networknode ro no snmp-server group networknode v1 snmp-server trap-source vlan100 snmp-server source-interface inform vlan100 lldp run logging origin-id ip logging source vlan100 logging host 10.1.100.21 transport udp port 20514 logging monitor informational no ip dhcp snooping information option ip dhcp snooping ip dhcp snooping vlan 10,50,70,100 epm logging ip device tracking ip device tracking probe use-svi device-sensor accounting device-sensor notify all-changes ip http server ip http secure-server ip access-list ext ACL-DEFAULT deny udp any any eq domain deny udp any eq bootpc any eq bootps deny tcp any host 10.1.100.21 eq 8443 deny tcp any host 10.1.100.21 eq 8905 permit tcp any any eq 80 permit tcp any any eq 443 deny ip any any interface range g1/0/7-48 description ISE dot1x Port switchport access vlan 70 switchport mode access spanning-tree portfast spanning-tree bpduguard enable authentication event fail action next-method authentication event server dead action reinitialize vlan 50 authentication event server dead action authorize voice authentication timer reauthenticate server authentication timer inactivity server authentication host-mode multi-auth authentication open authentication order dot1x mab authentication priority dot1x mab authentication port-control auto authentication violation restrict authentication periodic mab dot1x pae authenticator dot1x timeout tx-period 10 snmp trap mac-notification change added snmp trap mac-notification change removed ip access-group ACL-DEFAULT in ... View more

In this blog post, I'm going to add my network access devices (NADs) to my ISE deployment. These are the devices that will be sending RADIUS requests and profiling information to ISE  about endpoints on the network and, depending on the policy, ISE will be returning an authorization profile which will give the access device instructions on how to treat that endpoint. The first thing I like to do prior to adding the NADs is to create logical grouping for them such as their location, device type, etc. Navigate to Administration>Network Resources>Network Device Groups. We have a default grouping of All Device Types and All Locations. For my lab, I'm going to create the following groups: Switches, Virtual Switch, and Wireless Controller under the parent group of All Device Types. I will also create the SecurityLab group under the parent group of All Locations as detailed in the below screenshot: After creating my groups, I'm going to add my NADs. To add these devices, navigate to Administration>Network Resources>Network Devices and clickAdd. While I'm adding my devices, I always make sure to add the device to the logical groups I created for Device Type and Location: Check the box next to RADIUS Authentication Settings and keep everything at it's default except add a secret in the Shared Secret field. In this case, I'm going to use networknode as my secret: Check the box next to TACACS+ Authentication Settings and enter your preferred shared secret: Check the box next to SNMP Settings. You have several SNMP settings you can choose but for the purpose of the lab, I'm going to stick with selecting 2c on the SNMP Version drop-down. Under the SNMP RO Community field, enter the community string of your choosing. You can adjust the polling interval and originating PSN if you choose to do so but since this is a lab, I only have one PSN so there's no need to make any adjustments: Leave the Trustsec box unchecked for now. We will go over that in a separate TrustSec. ClickSubmit when you are done configuring your NAD. Do the above for all the NADs in your deployment or lab. ... View more