Introduction The following provides example for configuring a Cisco Secure ACS 5.X server to support TACACS+ authentication, authorization and accounting on Motorola Wireless Controllers and Access Points. In this configuration example Motorola vendor specific attributes and values will be assigned to groups on the Cisco Secure ACS server to determine each user’s role and access permissions. The attributes and values are assigned to the group using user defined services and protocols enabled on each group. Prerequisites ACS 5.x should be connected to Wings 5.x box. Components Used ACS 5.4 Wings 5.2 Configuration on ACS: Device Types The following provides an example of how to define WiNG 5 devices as  device types on a Cisco Secure ACS 5.x server. Device types allow  devices to be grouped in Cisco Secure ACS 5.x which will be used when  defining device authorization policies. Step1: Go to Cisco Secure ACS select Network Resources > Network Device Groups> Device Type >Create: Enter a Name and Description and select a Parent. Click Submit: A Network Device Group for Motorola Solutions devices has now been created: Network Devices and AAA Clients The following provides an example of how to add a WiNG 5 device as an AAA Client on the Cisco Secure  ACS 5.x server Within Cisco Secure ACS select Network Resources > Network Devices and AAA Clients >Create: Enter any Name for the Wireless Controller(s) then select a Location.  Assign the Device Type created in the previous step then enable the  TACACS+ checkbox. Enter a Shared Secret then select an IP Address  option. In this example IP Rang(s) By Mask has been selected and the  IPv4 subnet the Wireless Controllers are connected to 192.168.20.0/24  defined. Click Submit: The Wireless Controller(s) have now been defined as Network Devices and AAA Clients: Step4:Identity Groups The following provides an example of how to define identity groups on  a Cisco Secure ACS 5.x server. In  this example two groups named  MotorolaRO and Motorola RW will be defined. Users assigned to the   MotorolaRO group will be assigned to the Monitor role and Web access  permissions while users assigned to the MotorolaRW group will be  assigned to the Superuser role and All access permissions. 1 .Within Cisco Secure ACS select Users and Identity Stores . Identity Groups . Create: 2.Enter a Name and Description for the Read Only access group then click Submit: 3.Create a second group. Enter a Name and Description for the Read Write access group then click Submit: Two Identity Groups have now been created: Shell Profiles The following provides an example of how to define shell profiles on a  Cisco Secure ACS 5.x server. In this example two shell profiles named  MOTO RO and MOTO RW will be defined with attributes that determines the  role and access permissions each management user is assigned. The name  of each shell profile must match the name of the TACACS authentication  service defined in the TACACS AAA policy. In the General tab define the required TACACS+ services and protocols  to add. You can use existing services and protocols or create your own.  The following example defines services and protocol named MOTO RO will  be used to provide Read Only access into WiNG 5 devices: In the Common Tasks tab set the Maximum Privilege to Static and select a value of 1: In the Custom Attributes tab in the Attribute and Attribute Value  fields, define the attributes to be assigned to the user. In this  example Read Only users will be assigned to the Monitor role and Web  access permissions. Click Submit: Create a new Shell Profile. In the General tab define the required  TACACS+ services and protocols to add. You can use existing services and  protocols or create your own. The following example defines services  and protocol named MOTO RW will be used to provide Read Write access  into WiNG 5 devices: In the Common Tasks tab set the Maximum Privilege to Static and select a value of 1: In the Custom Attributes tab in the Attribute and Attribute Value  fields, define the attributes to be assigned to the user. In this  example Read Write users will be assigned to the Superuser role and All  access permissions. Click Submit: Shell Profiles named MOTO RO and MOTO RW have now been created: Device Authorization Policies The following provides an example of how to define device  authorization policies on a Cisco Secure ACS 5.x server. Device  authorization policies determine the shell profile each management user  is assigned based on the device type requesting authentication, location  and identity group membership. In this example two device authorization  policies named MotorolaRO and MotorolaRW will be defined. 1 Within Cisco Secure ACS select Access Policies> Default Device Admin >Authorization>Customize: Add the Customize Conditions named Identity Group.NDG:Location, NDG:  Device Type and Protocol. Under Customize Results add Shell Profile then  click OK: Click Create. In the Name field enter MotorolaRO then select the  Identity Group, NDG:Location and NDG:Device Type. Set the Protocol to  Tacacs and select the Shell Profile named MOTO RO. Click OK: Click Create>In the Name field enter MotorolaRW then select the  Identity Group>NDG:Location and NDG:Device Type. Set the Protocol to  Tacacs and select the Shell Profile named MOTO RO> Click OK: Device Authorization Policies named MotorolaRO and MotorolaRW have now been created: Motorola Solutions WiNG 5.2 AAA TACACS Policies The AAA TACACS policy defines the TACACS+ client configuration on a  WiNG 5 device. Each AAA TACACS policy can contain up to 2 TACACS+  authentication, authorization and accounting server entries in addition  to the names of the TACACS+ authentication service and protocols defined  on the Cisco Secure ACS server. The TACACS+ AAA policy also determines  the information forwarded to the accounting server. The following AAA TACACS policy example defines a Cisco Secure ACS  server for TACACS+ authentication, accounting and authorization, defines  the TACACS+ services and protocols named MOTO RO and MOTO RW and  enables CLI command and session accounting: AAA TACACS Policy Example: aaa-tacacs-policy CISCO-ACS-SERVER authentication server 1 host 192.168.10.21 secret 0 hellomoto authorization server 1 host 192.168.10.21 secret 0 hellomoto accounting server 1 host 192.168.10.21 secret 0 hellomoto authentication service MOTO protocol RO authentication service MOTO protocol RW accounting commands accounting session ! Management Polices Once an AAA TACACS policy has been defined, it must be assigned to one or more Management policies before TACACS+ can be utilized. Management policies determine the management interfaces that are enabled on each WiNG 5 device, local administrative users, roles and access permissions and external RADIUS or TACACS+ servers used to authenticate administrative users. By default each WiNG 5 device is assigned to a Management policy named default which is assigned using profiles. TACACS+ can be enabled on the default Management policy or any user defined Management policy. Most typical deployments will include separate Management policies  for Wireless Controllers and Access Points. Separate Management policies  are recommended as the management requirements and interfaces for each  device differ. In this case to enable TACACS+ on both Wireless  Controllers and Access Points, TACACS+ will need to be enabled on each  Management policy. The following Management policy examples enable TACACS+  authentication, authorization and accounting on user defined Management  policies assigned to Wireless Controllers and Access Points. TACACS+  fallback to local authentication is also enabled in the event of a WiNG 5  device cannot reach any defined TACACS+ servers for authentication: Management Policy Examples: ! management-policy CONTROLLER-MANAGEMENT no http server https server ssh user admin password 0 hellomoto role superuser access all snmp-server user snmptrap v3 encrypted des auth md5 0 hellomoto snmp-server user snmpoperator v3 encrypted des auth md5 0 hellomoto snmp-server user snmpmanager v3 encrypted des auth md5 0 hellomoto aaa-login tacacs fallback aaa-login tacacs authorization aaa-login tacacs accounting aaa-login tacacs policy CISCO-ACS-SERVER ! ! management-policy AP-MANAGEMENT ssh user admin password 0 hellomoto role superuser access all aaa-login tacacs fallback aaa-login tacacs authorization aaa-login tacacs accounting aaa-login tacacs policy CISCO-ACS-SERVER ! Verify The following provides the necessary steps required to validate  TACACS+ authentication, authorization and accounting. In this example  two user accounts have been defined on each Cisco Secure ACS server and  assigned to the appropriate groups. The users group membership  determines the role and access permissions assigned to the management  user. Username           Role                 Access Permissions monitor              Monitor           Web super user        Superuser         all Role Assignment The following provides the verification steps required to verify authentication and role assignments: Using the Web UI, login to the Wireless Controller using the monitor username and password: The user will be authenticated, authorized and assigned to the  Monitor role which provides read-only access on the Wireless Controller.  Select Configuration . Devices and attempt to edit a device. Notice no  edit functionality is available as the user is only permitted read-only access on the device: (Only view is available, Delete option is greyed out) Using the Web UI, login to the Wireless Controller using the superuser username and Password The user will be authenticated, authorized and assigned to the  Superuser role which provides full access on the Wireless Controller.  Select Configuration . Devices and attempt to edit a device. Notice the  edit functionality is now available as the user is only permitted full  access on the device: Troubleshoot: Cisco Secure ACS 5.X Within Cisco Secure ACS 5.X select Monitoring and Reports >Launch Monitoring & Report Viewer> Select Reports > Catalog >AAA Protocol . TACACS Aauthentication>Run. You would see the result for passed and failed authentication of the  user with the failure reason. For further details, Click on the  Magnifying details. ... View more

  Introduction This Document provides you the basic DOT1X configuration with ACS 4.2 using Radius protocol for Wired authentication. Prerequisites Switch 3550 ACS 4.2 Requirements Make sure that ACS and Switch are connected with each other. Components Used Switch 3550 ACS 4.2 Configuration on Switch: ##Globally enable radius auth and define Radius server. Switch(config)# radius-server host 192.168.1.3  key  cisco123 ##Enable dot1x functionality Switch(config)# dot1x system-auth-control ##Configure aaa Switch(config)# aaa new-model Switch(config)# aaa authentication dot1x default group radius ##Configure client interfaces for dot1x Switch(config-if)# switchport mode acces Switch(config-if)# switchport access vlan <vlan> Note:  Depending on IOS version you will use one of the two below commands. Switch(config-if)# authentication port-control auto or Switch(config-if)# dot1x port-control auto Switch(config-if)# dot1x pae authenticator Switch(config-if)# dot1x timeout quiet-period <secodns to wait after failed attempt> Switch(config-if)# dot1x timeout tx-period <time to resubmit request> Configuration on ACS: Add Switch as a Client on the ACS: Network Configuration > Add entry AAA client IP Address:  <IP> Shared secret:  <key> Authenticate Using:  Radius (Cisco IOS/PIX 6.0)   System Configuration > Global Authentication Setup Verify ‘Allow EAP-MD5′ is checked Verify ‘Allow MS-CHAP Version 2 Authentication’ is checked   In order to configure a user, click User Setup on the menu, and complete these steps: Enter the User information: Network-Admin <username>. Click Add/Edit. Enter the Real Name: Network-Admin <descriptive name>. Add a Description: <your choice>. Select the Password Authentication: ACS Internal Database. Enter the Password: ........ <password>. Confirm the Password: <password>. Click Submit.   Verify The Output Interpreter Tool (registered customers only) supports certain show commands. Use the Output Interpreter Tool in order to view an analysis of show command output. Enter these commands in order to confirm that your configuration works properly: show dot1x show dot1x summary show dot1x interface show authentication sessions interface <interface> show authentication interface <interface> Switch(config)# show dot1x _________________________________________________ Sysauthcontrol Enabled Dot1x Protocol Version 3 _________________________________________________ Switch(config)# show dot1x summary _________________________________________________ Interface PAE Client Status _________________________________________________ Fa0/4 AUTH _________________________________________________ Switch(config)# show dot1x interface fa0/4 detail _________________________________________________ Dot1x Info for FastEthernet0/4 _________________________________________________ PAE = AUTHENTICATOR PortControl = FORCE_AUTHORIZED ControlDirection = Both HostMode = SINGLE_HOST QuietPeriod = 5 ServerTimeout = 0 SuppTimeout = 30 ReAuthMax = 2 MaxReq = 2 TxPeriod = 10 Troubleshoot This section provides debug commands that you can use in order to troubleshoot your configuration. Note: Refer to Important Information on Debug Commands before you use debug commands. debug dot1x all debug authentication all debug radius (provides the information of radius at debug level) debug aaa authentication (debug for authentication) debug aaa authorization (debug for authorization) More Information 802.1x Wired Authentication on a Catalyst 3550 Series Switch and an ACS Version 4.2 Configuration Example ... View more

  Introduction This document shows commands for AAA/TACACS on CAT IOS Device. Login authentication to 'tacacs' and then 'local' if tacacs is not available set authentication login tacacs enable console primary set authentication login tacacs enable telnet primary set authentication login local enable console set authentication login local enable telnet More Information Issue the set authentication login local enable command in order to make sure there is a back door into the switch if the server is down. Issue the set authentication login tacacs enable command in order to enable TACACS+ authentication. Issue the set tacacs server #.#.#.# command in order to define the server. Issue the set tacacs key your_key command in order to define the server key, which is optional with TACACS+, as it causes switch-to-server data to be encrypted. If used, it must agree with the server. Note: Cisco Catalyst OS software does not accept the question mark (?) to be part of any keys or passwords. The question mark is explicitly used for help on the command syntax. Enable authentication to 'tacacs' and then 'local' if tacacs is not available set authentication enable tacacs enable console primary set authentication enable tacacs enable telnet primary set authentication enable local enable console set authentication enable local enable telnet More Information Issue the set authentication enable local enable command in order to make sure that there is a back door in if the server is down. Issue the set authentication enable tacacs enable command in order to tell the switch to send enable requests to the server. Defining TACACS Server set tacacs server <ip address> set tacacs key <key> Accounting set accounting exec enable start-stop tacacs+ set accounting connect enable start-stop tacacs+ set accounting commands enable all stop-only tacacs+ More Information In order to enable TACACS+ accounting for: If you get the switch prompt, issue the set accounting exec enable start-stop tacacs+ command. Users that Telnet out of the switch issue the set accounting connect enable start-stop tacacs+ command. If you reboot the switch, issue the set accounting system enable start-stop tacacs+ command. Users that perform commands, issue the set accounting commands enable all start-stop tacacs+ command. Reminders to the server, for example, to update records once a minute in order to show that the user is still logged in, issue the set accounting update periodic 1 command. Authorization set authorization exec enable tacacs+ none telnet set authorization enable enable tacacs+ none telnet set authorization commands enable all tacacs+ none telnet More Information In this example, the switch is told to require authorization for an exec session with TACACS+. In the event that the TACACS+ server is down, authorization is none. This applies to both the console port and the Telnet session. Issue the set authorization exec enable tacacs+ none both command In addition to the authentication request, this sends a separate authorization request to the TACACS+ server from the switch. If the user profile is configured for shell/exec on the TACACS+ server, that user is able to access the switch. This prevents users without shell/exec service configured on the server, such as PPP users, from logging into the switch. You get a message that reads Exec mode authorization failed. In addition to permitting/denying exec mode for users, you can be forced into enable mode when you enter with the privilege level 15 assigned on the server. It must runcode in which Cisco bug ID CSCdr51314 (registered customers only) is fixed. ... View more

Radius Authentication on Firewall Using ASDM/CLI for webvpn clients. ASDM Complete these steps in the ASDM in order to configure the ASA to  communicate with the radius server and authenticate WebVPN clients. Choose Configuration > Remote Access VPN > AAA Setup > AAA Server Groups. Click Add next to AAA Server Groups. In the window that appears, specify a name for the new AAA Server group and choose RADIUS as the protocol. Click OK when finished. Be sure that your new group is selected in the top pane and click Add to the right of the lower pane. Provide the server information: Interface Name—the interface that the ASA must use to reach the radius server Server Name or IP address—the address that the ASA must use to reach the radius server Server Secret Key—the shared secret key configured for the ASA on the radius server Example AAA Server Configuration on the ASA Once you have configured the AAA server group and server, navigate  to Configuration > Remote Access VPN > Clientless SSL VPN Access  > Connection Profiles in order to configure WebVPN to use the new AAA  configuration. Note: Even though this example uses WebVPN, you can set any remote access connection profile (tunnel group) to use this AAA setup. Choose the profile for which you want to configure AAA, and click Edit. Under Authentication choose the RADIUS server group that you created earlier. Click OK when finished. Command Line Interface Complete these steps in the command line interface (CLI) in order to  configure the ASA to communicate with the ACS server and authenticate  WebVPN clients. ciscoasa#configure terminal !--- Configure the AAA Server group. ciscoasa(config)# aaa-server RAD_SRV_GRP protocol RADIUS ciscoasa(config-aaa-server-group)# exit !--- Configure the AAA Server. ciscoasa(config)# aaa-server RAD_SRV_GRP (inside) host 192.168.1.2 ciscoasa(config-aaa-server-host)# key secretkey ciscoasa(config-aaa-server-host)# exit !--- Configure the tunnel group to use the new AAA setup. ciscoasa(config)# tunnel-group ExampleGroup1 general-attributes ciscoasa(config-tunnel-general)# authentication-server-group RAD_SRV_GRP Verify Use this section in order to confirm that your configuration works properly. Test with ASDM Verify your RADIUS configuration with the Test button on the AAA Server Groups configuration screen. Once you supply a  username and password, this button allows you to send a test  authentication request to the radius server. Choose Configuration > Remote Access VPN > AAA Setup > AAA Server Groups. Select your desired AAA Server group in the top pane. Select the AAA server that you want to test in the lower pane. Click the Test button to the right of the lower pane. In the window that appears, click the Authentication radio button, and supply the credentials with which you want to test. Click OK when finished. After the ASA contacts the AAA server, a success or failure message appears. Test with CLI You can use the test command on the command line in  order to test your AAA setup. A test request is sent to the AAA server,  and the result appears on the command line. ciscoasa#test aaa-server authentication RAD_SVR_GRP host 192.168.1.2 username kate password cisco123 INFO: Attempting Authentication test to IP address <192.168.1.2> (timeout: 12 seconds) INFO: Authentication Successful ... View more

Exact Steps on  IAS server to configure TUNNEL GROUP LOCK for webvpn users. IAS server Steps 1. Go to Remote Access Policies. 2. Go to the remote access policy, make a right click on the policy and click on the "Properties" . 3. Click on Edit Profile. 4. Click on Advanced Tab. 5. Click on Add. 6. Scroll down to "Vendor-Specific" Radius attribute. 7. Select it and click on Add. 8. Make sure Attribute Number is set to 26. 9. Click on Add. 10. Enter Vendor Code: 3076. 11. Select radio button : Yes. It confirms. 12. Click on Configure Attributes. 13. Vendor-Assigned attribute number: 085 14. Attribute format: String. 15. Attribute Value: <tunnel-group name> tunnel-group-lock with webvpn On ASA conf t# tunnel-group-list enable tunnel-group <tunnel-group_name> webvpn-attributes group-alias <tunnel-group_name> enable ... View more

Forward Syslog Messages to external Server using ACS Introduction This Document describes the steps on How to Forward the syslog messages to External Server Using ACS 5.x Prerequisites Connectivity of ACS 5.x with Syslog server. Requirements ACS 5.x Any syslog server Components Used ACS 5.4 KiwiSyslog server Configure Go to System Administration>Configuration>Log configuration>Remote Log Targets>Create step1: Give a name to the syslog server step2: You can define type(syslog) step3: Type the IP address of syslog server Step4: define port (514) Step5: Define Fcility code as LOCAL Step6: define max length as 1024 Specify which messages should be forwarded to the new created Syslog Server. In this example, I have selected Radius  Accounting as I want to forward Accounting logs. However you can select  anyother category as well. Step1: Go to System Administration>Configuration>Log Configuration>Logging Categories>Global Step2: Select Radius accounting Then move the available External Syslog Server to the Selected Targets and click submit. Step1: Go to System  Administration>>Configuration>Log Configuration>Logging  Categories>Global>Edit"Radius Accounting" Submit the changes. Verify Generate some traffic and you should now be able to see the messages on the server. ... View more