Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
- Cisco Community
- :
- About spindoctor64
03-01-2019
Stats
Member since
01-24-2012
13
Posts
5
Helpful
3
Solutions
Created by
spindoctor64
in Switching
in Switching
02-22-2019
10:51 AM
02-22-2019
10:51 AM
use “no errdisable detect cause gbic-invalid” command
Most likely Cisco Bug: CSCuj31712 - certain Vendor SFP force ports to err-disable:
https://quickview.cloudapps.cisco.com/quickview/bug/CSCuj31712
... View more
Created by
spindoctor64
in Policy and Access
in Policy and Access
05-29-2012
07:41 AM
05-29-2012
07:41 AM
aaa accounting only has to do with logging the commands, not whether the commands are authorized. You generally also want your authentication and authorization to come from the same place, such as the ACS only. Your config: aaa new-model aaa authentication login default group tacacs+ local <--Check TACACS+ to validate users and assign priv level when logging in aaa authentication enable default none !aaa authorization console !aaa authorization config-commands !aaa authorization template !aaa authorization exec default group tacacs+ local !aaa authorization commands 15 default local none <--Check local device for command authorization aaa accounting exec default start-stop group tacacs+ <----------------\ aaa accounting commands 15 default start-stop group tacacs+ <----\ Accounting commands log everything to ACS aaa accounting connection default start-stop group tacacs+ <---------/ aaa accounting system default start-stop group tacacs+ <-------------/ aaa session-id common When a user logs into your device, TACACS+ validates that the user has an account, AND assigns the initial privilege level. You would need to configure a privilege level of 15 on the ACS to be able to skip directly to the privileged exec mode (# prompt). Once that is done, you would also want to change your command authorizations to come from the ACS instead of the local device: aaa authorization commands 0 default group tacacs+ local none aaa authorization commands 1 default group tacacs+ local none aaa authorization commands 15 default group tacacs+ local if-authenticated I hope this helps. --Chris
... View more
Created by
spindoctor64
in Policy and Access
in Policy and Access
05-29-2012
06:58 AM
05-29-2012
06:58 AM
Assuming Cisco ACS v5.x: Create a new Shell Profile: Policy Elements > Authorization and Permissions > Device Administration > Shell Profiles Click the Create button at the bottom of the page. On the General tab, give the profile a name, then go to the Common Tasks tab. Under Privilege Level, set both the Default Privilege and the Maximum Privilege to 15. Click the Submit button at the bottom of the page. Create a new Command Set: Policy Elements > Authorization and Permissions > Device Administration > Command Sets Click the Create button at the bottom of the page. Check the box next to "Permit any command that is not in the table below" Click the Submit button at the bottom of the page. Create a new Authorization policy: Access Policies > Access Services > Default Device Admin > Authorization Click the Create button at the bottom of the page. Under Results: Set the Shell Profile to the one you just created Set the Command Sets to the one you just created Click the OK button at the bottom of the window. Click the Save Changes button at the bottom of the page. I hope this helps, --Chris
... View more
Created by
spindoctor64
in Policy and Access
in Policy and Access
05-25-2012
07:43 AM
05-25-2012
07:43 AM
On my SSG, I have the following: set auth-server "Local" id 0 set auth-server "Local" server-name "Local" On the SSG webGUI, I go to Configuration > Admin > Administrators and there is a drop-down for "Admin Auth Server." I have "Local/CiscoACS" selected. I don't know if your firewall has the same sort of setting, but that's the best I can come up with. I hope it helps! --Chris
... View more
Created by
spindoctor64
in Policy and Access
in Policy and Access
05-25-2012
06:35 AM
05-25-2012
06:35 AM
Marlon, I have pasted in a config below that I did for our ScreenOS firewalls to work with Cisco ACS v5.2. This config may not work since yours is Junos, but it might get you closer to figuring it out. Also, if you haven't been on the Juniper J-Net to ask around there, give it a shot. (forums.juniper.net) Good luck! --Chris Title: Configuration Example - Juniper SSG and Cisco ACS v5.x Product: Juniper SSG320M (Cisco ACS v5.x) Version: ScreenOS 6.3.0r10.0 (Cisco ACS v5.2.0.26.8) Network Topology: [Juniper SSG320M] ----- [Cisco 3560 Switch] ----- [Cisco ACS VM] Description: Purpose - Authenticate SSG administrators using TACACS+ instead of local logins Description - This configuration is for Cisco ACS v5.x, JTAC only had the v3.3 configuration. ACS v5.x is a Linux-based VM with a completely new user interface and structure. Configuration: Configure the Juniper (CLI) 1. Add the Cisco ACS and TACACS+ configuration set auth-server CiscoACSv5 id 1 set auth-server CiscoACSv5 server-name 192.168.1.100 set auth-server CiscoACSv5 account-type admin set auth-server CiscoACSv5 type tacacs set auth-server CiscoACSv5 tacacs secret CiscoACSv5 set auth-server CiscoACSv5 tacacs port 49 set admin auth server CiscoACSv5 set admin auth remote primary set admin auth remote root set admin privilege get-external Configure the Cisco ACS v5.x (GUI) 1. Navigate to Policy Elements > Authorization and Permissions > Device Administration > Shell Profiles Create the Juniper Shell Profile. Click the [Create] button at the bottom of the page Select the General tab Name: Juniper Description: Custom Attributes for Juniper SSG320M Select the Custom Attributes tab Add the vsys attribute: Attribute: vsys Requirement: Manadatory Value: root Click the [Add^] button above the Attribute field Add the privilege attribute: Attribute: privilege Requirement: Manadatory Value: root Note: you can also use 'read-write' but then local admin doesn't work correctly Click the [Add^] button above the Attribute field Click the [Submit] button at the bottom of the page 2. Navigate to Access Policies > Access Services > Default Device Admin > Authorization Create the Juniper Authorization Policy and filter by Device IP Address. Click the [Customize] button at the bottom Right of the page Under Customize Conditions, select Device IP Address from the left window Click the [>] button to add it Click the [OK] button to close the window Click the [Create] button at the bottom of the page to create a new rule Under General, name the new rule Juniper, and ensure it is Enabled Under Conditions, check the box next to Device IP Address Enter the ip address of the Juniper (192.168.1.100) Under Results, click the [Select] button next to the Shell Profile field Select 'Juniper' and click the [OK] button Under Results, click the [Select] button below the Command Sets (if used) field Select 'Permit All' and ensure all other boxes are UNCHECKED Click the [OK] button to close the window Click the [OK] button at the bottom of the page to close the window Check the box next to the Juniper policy, then move the policy to the top of the list Click the [Save Changes] button at the bottom of the page Verification: Login to the Juniper CLI and GUI using an ACS Internal User account, and attempt to change something to verify privilege level.
... View more
Created by
spindoctor64
in Security Management
in Security Management
05-24-2012
10:15 AM
05-24-2012
10:15 AM
1. Put all the devices that the NetAdmins are permitted to modify in one Device Group 2. Put all the NetAdmin user accounts in one Identity Group 3. Create a rule that lets NetAdmins logging into their Device Group access the device: Go to: Access Policies > Access Services > Default Device Admin > Authorization Click the Customize button at the bottom of the screen. In the popup window, under Customize Conditions, move Identity Group and NDG:Device Type to the Selected: box on the right Click OK Click the Create button Under Conditions: Check the box next to Identity Group: Use the Select button to choose your NetAdmin Identity Group Check the box next to NDG:Device Type: Use the Select button to choose the Device Group your NetAdmin devices belong to Under Results: Use the Select button to choose a Shell Profile; probably use Permit Access Under Command Sets: Use the Select button to choose a Command Set (Build at Policy Elements > Authorizations and Permissions > Device Administration > Command Sets ) Click the OK button. Check the box next to this new rule, and use the ^ button to move it to the top of your list of rules. 4. Create a rule that denies access to NetAdmins trying to log into any other device: Click the Create button Under Conditions: Check the box next to Identity Group: Use the Select button to choose your NetAdmin Identity Group Under Results: Use the Select button to choose a Shell Profile; probably use DenyAccess Under Command Sets: Use the Select button to choose a Command Set; probably use DenyAllCommands Click the OK button. Check the box next to this new rule, and use the ^ button to move it directly below the rule created in step 3. I hope this helps, and in the future try posting ACS-type questions to the AAA, Identity and NAC forum instead of the Security Management forum. --Chris
... View more
Created by
spindoctor64
in Policy and Access
in Policy and Access
05-23-2012
02:00 PM
05-23-2012
02:00 PM
Steve, I'm going to outline the assumptions first, then describe how to associate AD groups to ACS identity groups. BTW, I'm using ACS v5.2 on a VM, so 5.3 might be a little different. ASSUMPTIONS 1. Assume a simple setup, where you have two ACS identity groups, one for admins and one for read-only: Users and Identity Stores > Identity Groups Admin Read-Only 2. Your ACS is joined to a domain, and you have added two AD groups to the Directory Groups tab (not the Directory Attributes tab as you stated above): Users and Identity Stores > External Identity Stores > Active Directory > Directory Groups tab mydomain.com/Group Accounts/Admins mydomain.com/Group Accounts/Users 3. Your Search Sequence checks AD for accounts: Users and Identity Stores > Identity Store Sequences > Password Based is checked Authentication and Attribute Retrieval Search List AD1 has been added to the Selected box on the right 4. The ACS is set to use the Search Sequence from Step 3: Access Policies > Access Services > Default Device Admin > Identity Single result selection is selected Identity Source: Assuming all that is correct: ASSOCIATE AD GROUPS TO ACS IDENTITY GROUPS 1. Navigate to Access Policies > Access Services > Default Device Admin > Group Mapping 2. Select the radio button for 'Rule based result selection,' and click OK on the pop-up dialog 3. Click Create, and give the first rule a meaningful name, such as 'AD-Admin to ACS-Admin' Check the box for Compound Condition Dictionary: AD-AD1 Attribute: ExternalGroups Under Value: (Click the Select button, and select your AD Admin group) mydomain.com/Group Accounts/Admins Under Current Condition Set, click 'Add v' to add the condition to the field Under Results: (Select your ACS Admin internal identity group) Identity Group: All Groups: Admin Click OK at the bottom of the page to close the window and add the rule. 4. Click Create, and give the second rule a meaningful name, such as 'AD-Users to ACS-Read-Only' Check the box for Compound Condition Dictionary: AD-AD1 Attribute: ExternalGroups Under Value: (Click the Select button, and select your AD Admin group) mydomain.com/Group Accounts/Users Under Current Condition Set, click 'Add v' to add the condition to the field Under Results: (Select your ACS Read-Only internal identity group) Identity Group: All Groups: Read-Only Click OK at the bottom of the page to close the window and add the rule. 5. Click the Save Changes button at the bottom of the screen I hope this helps solve your problem, or gets you on the right track. --Chris
... View more
Created by
spindoctor64
in Policy and Access
in Policy and Access
05-23-2012
08:51 AM
05-23-2012
08:51 AM
Your aaa authentication config looks right to me. As I'm sure you know, according to your config, if the ACS is available, then your switch should never look locally for authentication. (If ACS can't find a valid account, it will send back a deny message, and the switch will not allow access, regardless if the user account is present locally) So I'm kinda stuck there. Any chance you could 'debug aaa authentication,' login and enable, then paste a (sanitized) log results? Otherwise, there should be log entries that say something like: May 23 15:45:11.888 ZULU: TAC+: (-000000000): received author response status = PASS_ADD May 23 15:45:11.999 ZULU: AAA/AUTHEN/LOGIN (00000000): Pick method list 'default' The first one indicates successful communication with the ACS, and the second verifies that TELNET logins map to the default method (aaa authentication login default group tacacs+ local)
... View more
Created by
spindoctor64
in Policy and Access
in Policy and Access
05-23-2012
07:12 AM
05-23-2012
07:12 AM
If you can send your 2950 aaa config, it might help, but I'm guessing you need something like the following to make the switch check TACACS (ACS) first, then look local when going into priv exec: aaa authentication enable default group tacacs+ local Just a guess, since I've never seen that error, but if you can show your aaa config it would help eliminate that as a problem. --Chris
... View more
Created by
spindoctor64
in Policy and Access
in Policy and Access
05-22-2012
07:52 AM
05-22-2012
07:52 AM
In ACS v5.x, there is a screen for integrating the ACS with AD. (Users and Identity Stores > External Identity Stores > Active Directory) Just enter the local domain name (domain.com) and a valid AD administrator account username and password, and the ACS will connect to the domain. This allows you to use existing AD credentials to login and administer your network devices. Tying the ACS to AD really only takes one screen and less than a minute, but you will still have to tell the ACS which AD groups get which permissions (for example, read-only or read-write access), and you will have to setup a search sequence (Users and Identity Stores > Identity Store Sequences) to tell ACS to first look at AD for credentials, then check the local ACS user database for valid accounts. The permissions part is still fairly quick, and it only takes me about 45 minutes to build an ACS from scratch including all AD integration and custom RADIUS attributes for some of our devices. The authentication would occur like this: User SSH/telnet/console to device Device contacts ACS using TACACS or RADIUS User receives login prompt and enters AD credentials Devices sends credentials to ACS ACS validates credentials in AD ACS sends authentication OK message to Device Device logs user in. Command Authorization looks something like this: User enters a command Device sends command authorization request to ACS ACS looks at which AD group the user belongs to and looks up permissions configured in ACS for that group Based on the permissions you have assigned, ACS either sends an allow or deny message to the Device Device allows or denies the user command. Criteria: We use an ACS 5.2 virtual machine and have had it work perfectly with Server 2003 and Server 2008. AD is hosted on our local domain controller (Bonus: no planting of flowers required!) Dependencies: Issue: The Device looks to ACS. ACS looks to AD. If AD fails, users cannot use their AD credentials to login. Device ---> ACS ---> AD Solution: Configure the Device to look at ACS first, then a local table if ACS is not available. Also, configure the ACS to look at AD first, then a local ACS account list if AD is not available. (You can configure local user accounts on the Device and in the ACS) Device ---> ACS ---> AD Device ---> ACS ---> AD ---> ACS local Device ---> ACS ---> AD ---> ACS local ---> Device local The new version of Cisco ACS is UNIX-based, and you can download a free trial to load up and try before you buy. It is far FAR superior to the old ACS v3.3 that we had for years. I hope this helps for your design document! --Chris
... View more
Created by
spindoctor64
in Policy and Access
in Policy and Access
01-26-2012
09:46 AM
01-26-2012
09:46 AM
I searched for a long time unsuccessfully trying to find a resolution to my SSG320M and Cisco ACS v5.x TACACS dilemma. I finally got it working in my network, so I'm posting the resolution here in case anyone else is looking. Configure the Juniper (CLI) 1. Add the Cisco ACS and TACACS+ configuration set auth-server CiscoACSv5 id 1 set auth-server CiscoACSv5 server-name 192.168.1.100 set auth-server CiscoACSv5 account-type admin set auth-server CiscoACSv5 type tacacs set auth-server CiscoACSv5 tacacs secret CiscoACSv5 set auth-server CiscoACSv5 tacacs port 49 set admin auth server CiscoACSv5 set admin auth remote primary set admin auth remote root set admin privilege get-external Configure the Cisco ACS v5.x (GUI) 1. Navigate to Policy Elements > Authorization and Permissions > Device Administration > Shell Profiles Create the Juniper Shell Profile. Click the [Create] button at the bottom of the page Select the General tab Name: Juniper Description: Custom Attributes for Juniper SSG320M Select the Custom Attributes tab Add the vsys attribute: Attribute: vsys Requirement: Manadatory Value: root Click the [Add^] button above the Attribute field Add the privilege attribute: Attribute: privilege Requirement: Manadatory Value: root Note: you can also use 'read-write' but then local admin doesn't work correctly Click the [Add^] button above the Attribute field Click the [Submit] button at the bottom of the page 2. Navigate to Access Policies > Access Services > Default Device Admin > Authorization Create the Juniper Authorization Policy and filter by Device IP Address. Click the [Customize] button at the bottom Right of the page Under Customize Conditions, select Device IP Address from the left window Click the [>] button to add it Click the [OK] button to close the window Click the [Create] button at the bottom of the page to create a new rule Under General, name the new rule Juniper, and ensure it is Enabled Under Conditions, check the box next to Device IP Address Enter the ip address of the Juniper (192.168.1.100) Under Results, click the [Select] button next to the Shell Profile field Select 'Juniper' and click the [OK] button Under Results, click the [Select] button below the Command Sets (if used) field Select 'Permit All' and ensure all other boxes are UNCHECKED Click the [OK] button to close the window Click the [OK] button at the bottom of the page to close the window Check the box next to the Juniper policy, then move the policy to the top of the list Click the [Save Changes] button at the bottom of the page 3. Login to the Juniper CLI and GUI, and attempt to change something to verify privilege level.
... View more
Labels:
Created by
spindoctor64
in Switching
02-22-2019
02-22-2019
use “no errdisable detect cause gbic-invalid” command Most likely Cisco
Bug: CSCuj31712 - certain Ve...
05-29-2012
aaa accounting only has to do with logging the commands, not whether the
commands are authorized.You...
05-29-2012
Assuming Cisco ACS v5.x:Create a new Shell Profile: Policy Elements >
Authorization and Permissions ...
Created by
spindoctor64
in Policy and Access
05-25-2012
05-25-2012
On my SSG, I have the following: set auth-server "Local" id 0 set
auth-server "Local" server-name "L...
Created by
spindoctor64
in Policy and Access
05-25-2012
05-25-2012
Marlon,I have pasted in a config below that I did for our ScreenOS
firewalls to work with Cisco ACS ...
05-24-2012
1. Put all the devices that the NetAdmins are permitted to modify in one
Device Group2. Put all the ...
Created by
spindoctor64
in Policy and Access
05-23-2012
05-23-2012
Steve,I'm going to outline the assumptions first, then describe how to
associate AD groups to ACS id...
05-23-2012
Your aaa authentication config looks right to me. As I'm sure you know,
according to your config, if...
05-23-2012
If you can send your 2950 aaa config, it might help, but I'm guessing
you need something like the fo...
Created by
spindoctor64
in Policy and Access
05-22-2012
05-22-2012
In ACS v5.x, there is a screen for integrating the ACS with AD. (Users
and Identity Stores > Externa...
Created by
spindoctor64
in Policy and Access
01-26-2012
01-26-2012
I searched for a long time unsuccessfully trying to find a resolution to
my SSG320M and Cisco ACS v5...
Public Statistics
| Date Registered | 01-24-2012 10:35 AM |
| Date Last Visited | 03-01-2019 02:02 AM |
| Total Messages Posted | 13 |
| Total Helpful Votes Received | 5 |
