cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1734
Views
0
Helpful
6
Replies

Managing roles for ACE RADIUS authentication

Hi,

I have an ACE module running virtual contexts. I have configured the ACE contexts to authenticate against a RADIUS server (Windows IAS).

When I log in, I am always given the role of 'network-monitoring'. I would like to configure the RADIUS server so it authenticates users as 'Admin'.

Attached is a screeprint of the RADIUS clients set up on IAS (client names and IP addresses removed). The question here is if they should be configured as 'RADIUS Standard' or 'Cisco' in the 'Client-Vendor' field.

Also attached is a screenshot of the IAS 'Remote Access Policy' that i have set up for the network devices (these include the ACE contexts aswell as Switches and FWSM contexts). The question here is whether I need both the 'Vendor-Specific' and 'Cisco-AV-Pair' attributes. Also, how do I need to configure these attributes so they will authenticate the Switches, Routers and FWSM contexts (allowing enable level 15) and authenticate the ACE contexts (allowing the 'Admin' role).

I have also attached the RADIUS config lines that have been configured on the ACE contexts (IP address of server removed).

I would appreciate any input.

1 Accepted Solution

Accepted Solutions

Hi Khalid,

the magic line is.

aaa authentication enable default group radius-grp enable

If you find a way to transport the "enable flag" via RADIUS you could do that. We decided that an authenticated user should go directly into enable mode.

Therefore you should/could configure following.

aaa authentication login default group radius-grp local <- stays the same

aaa authentication enable default none <- changed from your configuration

That results in not being asked for the enable password.

With TACACS+ you could configure something like you did as the ACS is able to pass the "enable flag".

For RADIUS as i mentioned you could probably also send a "shell:" command but i haven't had any pressure to investigate into that so far.

If your problem is solved just flag the Thread as solved and Rate if possible.

Hope it helps

Roble

View solution in original post

6 Replies 6

Roble Mumin
Level 3
Level 3

Hi Khalid,

have a look at my screenshots for an example on how to get IAS with ACE and other Cisco Devices working.

Cisco Devices get the Client Vendor Cisco in my IAS Config, my Linux Devices get RADIUS Standard.

On the ACE you configure following.

radius-server host [ip.ad.dr.es] key 0 [your-key] auth-port 1645 acct-port 1646 authentication accounting

aaa group server radius RADIUS_VTY

server [ip.ad.dr.es]

aaa authentication login default group RADIUS_VTY local

--

Regarding Vendor-Specific attribute for IAS Config or "Cisco-AV-Pair", i used the Vendor-Specific approach.

Vendor-Specific

Attribute Number: 26

Attribute Format: Octet String

Attribute Vendor: Cisco

Attribute Value: shell:Admin=Admin default-domain

Thats how my config works flawlessly for over 2 years now.

Hope it Helps

Roble

Hi Roble,

I really appreciate your response. I have a feeling it'll work once I have modified my configuration to be on the same line as yours.

I will update you on the results (fingers crossed) once I have made the changes and tested them tomorrow.

Kind regards,

Khalid

Hi Roble,

I have been able to get Admin level role but it seems it only works with the Admin context and non of the others. Is this normal?

Kind regards,

Khalid

Hi Kahlid,

the reason is the attribute value mentioned before. I configure all my contexts starting from the admin context so that is no problem for me. What you probably need to do is add additional statments.

Following Link explains it pretty well.

http://www.cisco.com/en/US/docs/interfaces_modules/services_modules/ace/v3.00_A1/configuration/security/guide/aaa.html#wp1321929

There you can see a pattern example:

shell:= ...

With the previous example in mind you should end up with following.

shell:Admin=Admin default-domain <- Admin Context

shell:Foo=Admin default-domain <- Context Foo

shell:Bar=Admin default-domain <- Context Bar

etc. etc.

Hope it helps.

Roble

Hi Roble,

That makes sense. I will configure the other contexts aswell.

By the way, I noticed you have some 6513s using the RADIUS server with the same settings. I also have some 6513s and 6509s. I have configured them as follows:-

aaa new-model

aaa group server radius radius-grp

server auth-port 1645 acct-port 1646

!

aaa authentication attempts login 5

aaa authentication fail-message ^CCCFailed login. Five consecutive fails will revoke.^C

aaa authentication login default group radius-grp local

aaa authentication enable default group radius-grp enable

!

aaa session-id common

!

radius-server host auth-port 1645 acct-port 1646 key

radius-server source-ports 1645-1646

!

line con 0

password 7

logging synchronous

line vty 0 4

exec-timeout 30 0

password 7

transport input telnet ssh

line vty 5 15

exec-timeout 30 0

password 7

transport input telnet ssh

!

For some strange reason, when I log in, I can authenticate against the RADIUS server on IAS. When I try to go into enable mode, I am prompted for the password but the authentication fails. When I check the IAS server logs, I see the initial login request is coming into the IAS server with my username, however the enable request is coming into the IAS server with the user $enable15$.

Do you know why this is the case? How do I configure the switches to insert the username in the enable authentication request?

I have attached a screenshot of my current IAS attributes.

I would really appreciate any input you may have on this second issue.

Hi Khalid,

the magic line is.

aaa authentication enable default group radius-grp enable

If you find a way to transport the "enable flag" via RADIUS you could do that. We decided that an authenticated user should go directly into enable mode.

Therefore you should/could configure following.

aaa authentication login default group radius-grp local <- stays the same

aaa authentication enable default none <- changed from your configuration

That results in not being asked for the enable password.

With TACACS+ you could configure something like you did as the ACS is able to pass the "enable flag".

For RADIUS as i mentioned you could probably also send a "shell:" command but i haven't had any pressure to investigate into that so far.

If your problem is solved just flag the Thread as solved and Rate if possible.

Hope it helps

Roble

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: