Comware

 View Only
  • 1.  TACACS+ enable authentication 2500 Series

    Posted Jan 29, 2009 12:53 PM
    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.  RE: TACACS+ enable authentication 2500 Series

    Posted Feb 03, 2009 09:38 PM
    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?


  • 3.  RE: TACACS+ enable authentication 2500 Series

    Posted Mar 24, 2009 01:22 PM
    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.