Switches, Hubs, and Modems
1748265 Members
3959 Online
108760 Solutions
New Discussion юеВ

TACACS+ enable authentication 2500 Series

 
switchtower
New Member

TACACS+ enable authentication 2500 Series

Hello everyone,

I was curious if anyone has any experience or similar issues. Here is the problem:

I can enable tacacs on the switch with:

aaa authentication telnet login tacacs local
aaa authentication telnet enable tacacs local
tacacs-server key password
tacacs-server host 10.10.10.151

and I can telnet into the device using my credentials. But when I attempt to enable myself with the same credentials I'm told the password is incorrect.

The TACACS server we use is from: http://www.shrubbery.net/tac_plus/ and we use this one so we can auth against an LDAP/Kerberos setup.

Here are the logs from our TACACS servers:

Thu Jan 29 12:41:21 2009 [7533]: cfg_get_value: name= isuser=1 attr=enable rec=1
Thu Jan 29 12:41:21 2009 [7533]: cfg_get_value: no user/group named
Thu Jan 29 12:41:21 2009 [7533]: cfg_get_pvalue: returns NULL
Thu Jan 29 12:41:21 2009 [7533]: cfg_get_hvalue: name=10.10.10.156 attr=enable
Thu Jan 29 12:41:21 2009 [7533]: cfg_get_phvalue: returns cleartext password
Thu Jan 29 12:41:21 2009 [7533]: verify daemon password == NAS supersecretpassword
Thu Jan 29 12:41:21 2009 [7533]: Password is incorrect
Thu Jan 29 12:41:21 2009 [7533]: enable query for 'unknown' unknown from 10.10.10.156 rejected
Thu Jan 29 12:41:21 2009 [7533]: cfg_get_hvalue: name=10.10.10.156 attr=key
Thu Jan 29 12:41:21 2009 [7533]: cfg_get_phvalue: returns password


The TACACS server is a production server and is known to work.

If anyone has any insight or any further questions, please let me know.
2 REPLIES 2
Tabasco
New Member

Re: TACACS+ enable authentication 2500 Series

Some things to try to isolate:

set primary auth source for enable to be local
set primary auth source for login to be local.

Does enable work in both cases?
Chris Zane
New Member

Re: TACACS+ enable authentication 2500 Series

I see the same problem - looks like the procurve is not sending the username in the enable packet (i.e. user is unknown as opposed to 'czane'):


Fri Mar 20 14:30:04 2009 [3607]: connect from 128.171.132.112 [128.171.132.112]
Fri Mar 20 14:30:06 2009 [3607]: login query for 'czane' unknown-port from 128.171.132.112 accepted
Fri Mar 20 14:30:07 2009 [3602]: session.peerip is 128.171.132.112
Fri Mar 20 14:30:07 2009 [3608]: connect from 128.171.132.112 [128.171.132.112]
Fri Mar 20 14:30:09 2009 [3608]: enable query for 'unknown' unknown from 128.171.132.112 rejected


A cisco switch works fine (i.e. user in the enable query is 'czane'):

Fri Mar 20 14:29:46 2009 [3603]: connect from 128.171.132.114 [128.171.132.114]
Fri Mar 20 14:29:48 2009 [3603]: login query for 'czane' tty2 from 128.171.132.114 accepted
Fri Mar 20 14:29:49 2009 [3602]: session.peerip is 128.171.132.114
Fri Mar 20 14:29:49 2009 [3604]: connect from 128.171.132.114 [128.171.132.114]
Fri Mar 20 14:29:51 2009 [3604]: enable query for 'czane' tty2 from 128.171.132.114 accepted


Is this a bug with the procurve tacacs implementation? This "feature" is holding me up from recommending these switches to deploy on our campus.