Is it possible for ACS 5.1 to only allow specific AD users to authenticate the switches and routers?
Currently What I have configured is onlyfor all AD users. I can't seem to find a way to be selective.
Yes this is possible, by default the ACS 5.x comes with some Conditions in your Access Policies that make reference to the Compound Condition, Time and Date, but you can customize these Conditions and use something else like AD group membership, Username, Group of Devices, etc. The Customize option is located in the Access Policy rule at the bottom right of the page.
Here is an example of how you can configure access to some users only to the routers or switches:
Let me know if it helps!
Can you again please put the snapshot,
We want to give specific users (from internal) to access particular devices (readwrite and read-only).
Appreciate your support.
The way to control Active Directory access is via the Directory Groups tab under
Users and Identity Stores --> External Identity Stores --> Active Directory.
The way to permit TACACS+ mgmt access to your infrastructure devices is as follows:
1. Make your network admins part of a specific AD group
2. Add that AD group to the list of Directory Groups
3. In the Access Policy, click the Customize button as Mauricio suggested, and add "AD1:External Groups" to the selected critieria
4. In the policy rule, you will now be able to select your specific AD group to match against.
Additionally, you may want to verify that the identity selection is set to only check AD for the authentication portion, by default I think (if I'm not mistaken) the identity check should be AD1 (Active Directory only), but it's best to confirm that part as well.
Hope this helps.
I did used the system username and allocated the ACS default of deny/access for the shell profile and command set is also ACS
Default deny all commands.
But still that particular username still able to login into the switches .
What could have missed in the configuration?
One way to check is to go to "launch Monitoring and Report Viewer"
Select Reports > Catalog > AAA Protocol
Select TACACS Authentication and then the Details icon for the record for this user
You will be able to see all the detais for the request
- which Access Service was used
- which Authentication DB / rule was used
- which Authorization rule was matched
- which AD groups were retrieved for the user
If you share can also take a look
I have enter the
System:UserName = ABC but seems like it still hit the
Authorization Policy Matched Rule:
I would forget about using the System:Username in your access policy.
You're integrating your CSACS with AD, so you should be using specific AD group matching to evaluate TACACS+ access.
Also, I would suggest it would be wise to either disable or remove the default access policies that CSACS comes with out of the box and build your own from scratch.
My personal rule of thumb is to never rely on default system settings, as they may (as it appears in this case) be too permissive.
So, in building an access policy, there are a number of steps:
1. In the AD Directory Groups section, ensure that the groups you want to match in the policy are selected
2. In the Network Devices section, ensure that you have the appropriate devices and TACACS+/RADIUS keys defined
3. In the Policy Elements section, ensure that you have created an appropriate Shell Profile and Command Set for the Device Administration (ie: Helpdesk folks could have show (Level 1) cmd access, Admins would have the full (Level 15) cmd range)
4. In the Access Policies section, create a new service (Device Administration) with Identity and Authorization (and optionally Group Mapping if you are going to use internal ACS groups), and clearly define the criteria that will allow that access policy to be matched (if protocol = TACACS then select this service)
5. In the Access Policy rules, begin by setting the default rule to Deny (rather than the default permit, I don't understand why Cisco would ever have permit as a default action)
6. Customize the rule criteria to include AD1:External Groups, NAS IP Address, Protocol, etc etc as required to further refine the rule evaluation and matching.
7. Build the rules with the most restrictive at the top of the ruleset (ie: match those less-priviledged HelpDesk guys based on their AD group membership first and apply the shell profile and commands sets to limit them as necessary)
There is a lot of design / thought that needs to be put into AAA, especially if you have groups with varying priviledge / access levels. CSACS 5.x is actually one of the most intuitive products Cisco has come out with in years, and it does work very well.
If you can provide some additional details, I can throw together some sample policy-building screenshots in a document and either post or email it to you later today.
- Travis Hysuick
CCNA (R&S, Voice and Security), CCDA
It should all be prety self explanatory but to sahre what I see
- is select default device admin access service
- authentication is against AD (Identity Store: AD1)
- can see in steps information that "User Groups retrieval from Active Directory succeeded"
- Default authorization rule is matched
So key questions are
- what additional authoirzation rules are defined, using the AD1:ExternalGroups attribute? and which AD groups are being checked>
|Access Policies >||Access Services >||Default Device Admin >||Authorization|
- what groups were in fact retrieved? You can see this data in the authentiaction details - I think it is under the section called Others (although don't have an ACS server available I can check on)
Multiple LDAP directories can be defined in ACS 5.1 similar to ACS 3.x and 4.x. The LDAP directory configuration allows you to select groups and attributes for use in the access policy.
Refer the Link for the Configuration part: www.cisco.com/c/en/us/td/docs/net_mgmt/cisco_secure_access_control_system/5-1/migration/guide/Migration_Book/Migration_Configure.html#wp1053365