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
Hi Ankit, Yes, You can integrate Nexus with ACS 4 as well. You will have to add this custom attribute either in the group setup or user setup. you pass back a TACACS custom attribute with a value of roles="roleA" . For a full access user, you use: cisco-av-pair*shell:roles="network-admin" cisco-av-pair*shell:roles="network-admin"(The
* makes it optional) shell:roles="network-admin" Let me know if you have further questions: Best Regards: Minakshi (Do rate the helpful posts )
... View more
Hi JOhn, Its not possible in Identity,You can only restrict the access in the AUthorization, By choosing the external groups:AD attribute from customize: Best Regards: Minakshi (Do rate the helpful posts )
... View more
Hi Denis, First of all we need to understand one thing, what is config-commands, Commands 1 and commands 15, This will help you understand these aaa commands. Config-commands----Commands that we can run under configuration Mode, For example: when you login to the router, enter the priv mode and then enter the configuration mode> Type question mark> It will give you the list of the commands that can be run on Config mode. Similarly , when you enter priv mode (# mode also known as level 15) > Type question mark, It will also display you list of commands that you can run on that mode. You can always check the level, By following command: #show privilege level. and in the same way, You can check what command can be run on what level. Now Moving on the aaa commands: aaa authorization config-commands--- This command will check the authorization for the commands on the configuration Mode. aaa authorization exec default group tacacs+ local--- This command will provide the user level 15 access directly, bypassing enable authentication aaa authorization commands 1 default group tacacs+---This command will check the authorization of the commands that can be run on level 1. aaa authorization commands 15 default group tacacs+ local----- This command will check the authorization for the commands that can be run on level 15
I hope this helps: BR Minakshi (Rate the helpful posts)
... 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>.
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
Dot1x Protocol Version 3
Switch(config)# show dot1x summary
Interface PAE Client Status
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
Hi William, Did you try to use a different browser and through a different machine to check if you are able to create the policy. In case if you are using IE browser , latest version. Kindly enable the compatiability view. Under Menu bar>Tools> Compatibility view. Let me know if it works for you. Also, Do login to CLI mode and check if all the services are running in CLI. #sh app status acs Share the output with me. Regards Minakshi (Do Rate the post if it helps)
... 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