cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1874
Views
0
Helpful
12
Replies

ACS 4.1 to differentiate and restrict users

scott.crawford
Level 1
Level 1

Hello all,

I've bee wrestling with this issue off and on for some time, but have had limited success. There is something I don't quite understand just yet. I hope someone here can help.

I want to set up AAA on ACS 4.1 for authenticating login sessions to my swtiches, ASA and access points. That part is easy, and it even works, but here's what I 'm having trouble with:

Our ACS server points to our Windows 2003 AD database. If I set up my switches with AAA, anyone in the AD database can login to the switch. I only need about 5 people to have admin access to my switches, not the 4000 others.

Also, I need to administer my access points. I am also a wireless user. Betty Sue in accounting is a wireless user, but has no need to administer the access point to which she associates. Same thing goes with our ASA and remote access VPN connections. How do I identify how a user connects to the device and set restrictions based on this?

To put it another way:

User A is Admin, wireless user, VPN user. Needs full access to all these devices. This part is easy.

User B is accountant (or whatever), wireless user, VPN user. Should not have any access to administer the switch, AP, or ASA they are connecting to.

I hope that makes sense. I've been through the NAP documents. I think the solution is there, but I'm not bright enough or brave enough to figure it out, at least not on a live network:)

Thanks for any help.

Scott

12 Replies 12

Collin Clark
VIP Alumni
VIP Alumni

Scott-

I setup different groups in ACS. Then inside the group we set the Network Access Restrictions (NAR).

Here's an example.

We have a AAA client group that has all of our routers (called Routers). Then we created a user group called NetworkingGroup. Inside the group properties, we set the Network Access Restrictions. In the Network Access Restrictions it asks for the AAA client, which is the AAA client group that we created in the first step (Routers).

Hope that helps.

Thanks for your help.

I see how that would work for the switches and routers. I'm struggling with situations like our access points, where a regular user needs to have their credentials presented to the ACS server by the AP in order to use the wireless network, but this same user needs to be denied access if they try to launch an SSH session to the AP. Slightly different, bue in each case, the same AA client (the AP) is presenting the same credentials to the ACS server. How does the ACS server know that, if a wireless user, let them in, if an admin session, deny them?

Thanks. Apologies if this is obvious and I'm being dense.

Scott

What is your authentication for wifi users? Are you restricting them by Windows too?

Wireless folks are using LEAP, the user name and password are their user name and password in the Windows AD database.

Scott,

There are two section in NAR"s.

Ist is IP based NAR

2nd is CLI/DNIS based.

So for wireless users you need to apply only IP based NAR. By this wireless uses will NOT be able to ssh/telnet but they can connect to wireless network.

So that solve your issue ?

Check out this white paper,

http://www.cisco.com/en/US/products/sw/secursw/ps2086/products_white_paper09186a00801a8fd0.shtml

Regards,

~JG

Do rate helpful posts

Thanks for your help. I will give this a try later this week and let you know.

Scott

Hi all,

I'm very frustrated. Each explanation makes sense, but, in practice, it doesn't work. The only difference are in what ends up being logged. Here's what I have:

A user, username is UserB, defined in our Windows AD.

This user is in a user group, GroupB.

A Cisco 3550 switch, named SwitchB successfully authenticating users via our ACS 4.1 server.

On that server, this switch is in a NDG group, Switches.

I built a NAR, called Deny Switches, selected Define IP-Based restrictions and chose the NDG:Switches, port *, IP Address *.

Back under the user group config, under the Network Access Restrictions, I must select Only Allow network access when check box or no filters are processed. (I think this is what fouls me up, each option is a permit. No matter what I choses, the result is a permit.) I select the NAR I built.

I also select Per group defined Network Access Restrictions, and chose the same values in the NAR I built earlier. This setting doesn't seem to alter anything.

Any clues?

Scott,

Please do not use "Only Allow network access when" so uncheck that option.

AND enable

Configure Per Group Defined Network Access Restrictions.

Regards,

~JG

Hi,

I tried that using permitted locations and selecting other network groups, and I also tried it using denied locations and selecting the switches group, there is no difference. In both cases, ACS Passed Authentications log tells me that there was no filters activated, and I'm into the switch.

I'm confused. I'll revisit tomorrow.

Thanks

Scott

Hi Scoot,

Have you resolved your issue?

The first thing that comes to my head when you say

"I also tried it using denied locations and selecting the switches group, there is no difference. In both cases, ACS Passed Authentications log tells me that there was no filters activated, and I'm into the switch."

is that the order of your mappings under External Database Users/Database group mappings is not correct. If your username is apart of multiple groups you need to order them correctly so that the group that needs to be denied comes first.

E.g.

LDAP Group CiscoSecureGroup

Admin Admin

HR Users HR

Sales Users Sales

If user "BOB" is part of Admin and part of Sales but you want to restrict the Sales group from access the switches(NDG). After you apply your NAR to the SALES group you will still be able to gain access to the switches because your username is in the ADMIN group and the ACS looks in order of the group mappings from top down.

This is just the first thing I thought of but you might have already checked this out.

HTH

Craig

Craig,

Thanks for your input, but for now, I'm only using one group, one NAR per user. Keeping it simple.

I did make progress with Cisco TAC though. This particular version of ACS, 4.0.1, has bugs. They turned up some logging and we could see that the IP address isn't passed to the ACS, so it can't make decisions based on that particular information. Makes sense, now, glad I'm not crazy.

I'll try RADIUS (is TACACS now, no reason I can think to have to go this way), but an upgrade to 4.11 is probably in my near future.

Thanks all

Scott

All,

I'm just now getting back to this. ACS is upgraded and the NAP is configured and almost working as I need it to be, with a big exception. Maybe someone can help?

When I use telnet to login to a device, I am asked for "Username". With a sniffer, I can see that the AV Pair used to identify VTY connections is being sent with the proper value, and the user I want to be denied is denied. Subsequent requests to login are all asking for "Username", and all send the correct AV Pair, and all are rejected. Nice.

Here's the issue. When I use SSH lo login to the same device, with the same credentials, I am asked to "Login as". The first time, the AV Pair I need is sent and the user is denied. When I am asked again, I'm not asked for user name or to "login as" again, I'm only asked for the password. If I enter the correct password, the user, any user, is allowed. Not good. With the sniffer, I see that the AV Pair is only sent with the first attempt, subsequent attempts don't send the AV Pair in question, so ACS can't act on this information, and so the user who should be denied, is not.

Any ideas for how to get around this? Can SSH be setup to present the username to the login session every time? Is there a way to force the sending of this AV Pair every time? Can I set up something to say that any user has only one attempt to login?

The AV Pair in question is [061]NAS-Port-Type=5

Thanks for any help

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: