Configuring TACACS+ PAP/CHAP authentication for the Aruba AOS-CX platform.

The documentation about this topic is hard to find. Much from HP(E), some ArubaOS, then AOS-CX versions configuration are described. Aruba has its own TACACS+ server product, called Clearpass, which probably uses RADIUS and TACACS+. It is not easy to find working configuration examples for the Aruba devices and additional TACACS+NG example setups, that are working.

AOS-CX uses PPP PAP/CHAP authentication method. Aruba community users reporting the issues with TACACS-GUI. TACACS-GUI uses TAC_PLUS implementation from Pro-Bono-Publico. The follow up user reports similar issue using Aruba's Clearpass.

TL;DR;

ARUBA CX SImulator Tacacs Integration doesn't Work ... From the TACACS GUI LOG, PAP Authentication has been successful but access to the switch is still denied, as folows: ... Did I miss something? Thank you very much for the help.

Sincerely,Gibs

This thread quesiton is still open.

This is about Authentication only. The Authorisation and Accounting parts are easy to setup once the Authentication part works. Read the official documentation of the used software.

Router

AOS-CX version used in this netlab:

RS105# show ver

ArubaOS-CX (c) Copyright Hewlett Packard Enterprise Development LP  ------------------------------------------------------------------ Version : Virtual.10.07.0004 Build ID : ArubaOS-CX:Virtual.10.07.0004 Build SHA : 6d2cadb8b3acdc132b345544abfa023a9989d39e Active Image : _ Service OS Version : BIOS Version :

Configuration

R105 router setup is using following configuration settings:

  • Hostname: R105
  • Gi1/1/1: 10.100.100.105/24
  • Gateway: 10.100.100.1
  • local user: admin
  • SSHv2 server enabled

Applied configuration, a optional banner to display locally configured credentials:

configure
!
hostname R105
banner motd !
  user: admin
  pass: aruba
!
user admin group administrators password plaintext aruba
!
ssh server vrf mgmt
ssh server vrf default
!
interface 1/1/1
    no shutdown
    ip address 10.100.100.105/24
ip route 0.0.0.0/0 10.100.100.1
!
end

AOS-CX uses in the default configuration PAP. Verify the setting using following command:

RS105# show run all | i tacacs

These are all TACACS+ configured AOS-CX default settings, use the show running-config all command to display hidden defaults in the router configuration:

RS105# show running-config all | i tacacs

tacacs-server tracking interval 300 tacacs-server tracking user-name tacacs-tracking-user tacacs-server timeout 5 tacacs-server auth-type pap aaa group server tacacs tacacs

TACACS authentication

TACACS+ server setup is using following configuration settings:

  • IP: 192.0.2.1
  • TCP port:4949
  • TACACS+ key: 123-my_tacacs_key

This will results in following configuration for the AOS-CX router:

!AOS-CX
configure
!
tacacs-server host 192.0.2.1 port 4949 key plaintext 123-my_tacacs_key
aaa authentication login default group tacacs local
!
end

TACACS+ AUTH default

The login default configuration setting, sends all authentication requests, from all, local lines (f.e. console, vty, telnet, SSH), to the TACACS+ server.

aaa authentication login default group tacacs local

This setting works the same if using IOS, using the same keyword login default. Verify.

TACACS+ AUTH SSH only

The login ssh means, in this context, that SSH reqests (only) will be sent to the TACACS server

aaa authentication login ssh group tacacs local

Authentication requests, sent NOT from SSH will use the local user database configured on that device.

TACACS+-NG

This netlab is using the TAC_PLUS-NG server project from Event-driven servers.

The AAA server is TAC_PLUS-NG. Version used:

user % tac_plus-ng -f tac_plus-ng version 21ed8983f71c8d50ff25ae133a006ae571807db1/PCRE2

Everything explained below should work the same way, using previous or future versions of TAC_PLUS-NG. It is using PPP - PAP/CHAP protocol and its authentication mechanisms.

Initial configuration

Configuration used, is taken from the 1-st in series of TAC PLUS-NG netlab. It describes the most basic flat file configuration, one can run. One working login service is configured using Blowfish encrypted password. It's user is cisco.

Initial tac_plus-ng.cfg configuraiton file:

#!/usr/sbin/tac_plus-ng
#
# AOS-CX tac_plus-ng PAP/CHAP auth example init
#
id = spawnd {
        listen = { address = 0.0.0.0 port = 4949 }
}

id = tac_plus-ng {

        host IPv4only {
                address = 0.0.0.0/0
                welcome banner = "\n Welcome to TACACS+NG\n\n"
                key = 123-my_tacacs_key
        }

        profile netadmin {
                script {
                    if (service == shell) {
                            if (cmd == "") {
                                set priv-lvl = 15
                                permit
                                }
                        }
                }
        }

        group admin

        user cisco {
                password {
                        login = crypt $2a$10$34.ioPXaLJDD.PdEk.4Mle3g0cQw8e16thH1g0nQEC1.jW.sEHi1S
                        }
                member = admin
        }

        ruleset {
                rule {
                        script {
                                if (member == admin) { profile = netadmin permit }
                        }
                }
        }
}

The configured password for the user displayed above needs to be looked in the previous netlab about TACACS+NG authentication.

Testing authentication

Authentication test using shown configuration. This uses the default method login only. PAP and CHAP are not part of the configuration now. The authentication try is made from the node 10.100.100.10 using SSH protocol.

user % tac_plus-ng -f tac_plus-ng.cfg -d 4

9142: 10:53:30.489 0/00000000: - Version 21ed8983f71c8d50ff25ae133a006ae571807db1 initialized 9141: 10:54:01.210 0/8e6fa4f5: 10.100.100.105 authen: hdr->seq_no: 1 9141: 10:54:01.210 0/8e6fa4f5: 10.100.100.105 looking for user cisco realm default 9141: 10:54:01.210 0/8e6fa4f5: 10.100.100.105 user lookup succeded 9141: 10:54:01.210 0/8e6fa4f5: 10.100.100.105 pap login for 'cisco' from 10.100.100.10 on ssh failed (denied) (profile=netadmin) 9141: 10:54:04.171 1/df8617b1: 10.100.100.105 authen: hdr->seq_no: 1 9141: 10:54:04.171 1/df8617b1: 10.100.100.105 looking for user cisco realm default 9141: 10:54:04.171 1/df8617b1: 10.100.100.105 user lookup succeded 9141: 10:54:04.171 1/df8617b1: 10.100.100.105 pap login for 'cisco' from 10.100.100.10 on ssh failed (denied) (profile=netadmin)

The failure message from the TACACS+NG debug output:

pap login for 'cisco' from 10.100.100.10 on ssh failed (denied) (profile=netadmin)

This failure message is the first hint on how to expand the current running TACACS+NG configuration.

PAP authentication

PAP authentication is defined in the RFC 1334. For looking up implementation details or standard failure messages use the RFC 1334 - PPP Authentication Protocols.

Documentation

I write out where this is found in the documentation, in case this is a dead link in some tune. The documentation is changed constantly and the URLs are then hard to find. TAC_PLUS-NG: Configuration example 4.2.3.12 - Users:

...
user marc {
    password {
        login = clear myLoginPassword
        pap = clear myPapPassword
    }
}
...

Examine the shown example configuration above. The password option contains list of available authentication methods, per user. TACACS+NG will use Devices having specific defaults according to authentication will have a list or choice. This is configured to the additionally to already currently the working entries.

PAP configuration

Configuring PAP authentication method. The password for this authentication method is set to auth-pap in clear text:

...
    user cisco {
            password {
                    login = crypt $2a$10$34.ioPXaLJDD.PdEk.4Mle3g0cQw8e16thH1g0nQEC1.jW.sEHi1S
                    pap = clear auth-pap
            }
            member = admin
    }
...

The password for PAP is set to a different one compared to the login method. Now if that has been additionally configured, the AAA service, here TACACS+NG should be started again.

Verification

The authetication works. Using the show tacacs-server statistics command shows Auth Rejects but 3 Auth Accepts:

R105# show tacacs-server statistics

Server Name : 192.0.2.1 Auth-Port : 4949 VRF : default Authentication Statistics - - - - - - - - - - - - - - - - - - - - Round Trip Time(ms) : 3 Pending Requests : 0 Timeout : 0 Unknown Types : 0 Packet Dropped : 0 Auth Start : 13 Auth challenge : 0 Auth Accepts : 3 Auth Rejects : 10 Auth reply malformed : 0 Tracking Requests : 0 Tracking Responses : 0

Using the show tacacs server detail displays the current default is PAP:

RS105# show tacacs-server detail

! ! Output omitted for brevity ! * * * * TACACS+ Server Information * * * * Server-Name : 192.0.2.1 Auth-Port : 4949 VRF : default Shared-Secret : AQBapcSUOhduJ+J0PZqoyrvOSIhrGJFDTDpvIl1YeVeZfDeDEQAAALNP25zCzP67zZjRKO8fC5WF Timeout : 5 Auth-Type : pap Server-Group : tacacs Default-Priority : 2 Tracking : disabled Reachability-Status : unknown Tracking-Last-Attempted : N/A Next-Tracking-Request : N/A

So authenticating to the device using PAP works here. In below example the CHAP authentenication method is explained and tested.

PAP auth debug

This is the debug ran on the AAA server side

user % tac_plus-ng -f tac_plus-ng.cfg -d 4

9871: 11:01:03.978 0/00000000: - Version 21ed8983f71c8d50ff25ae133a006ae571807db1 initialized 9871: 11:01:11.296 0/45d84cdf: 10.100.100.105 authen: hdr->seq_no: 1 9871: 11:01:11.296 0/45d84cdf: 10.100.100.105 looking for user cisco realm default 9871: 11:01:11.296 0/45d84cdf: 10.100.100.105 user lookup succeded 9871: 11:01:11.296 0/45d84cdf: 10.100.100.105 pap login for 'cisco' from 10.100.100.10 on ssh succeeded (profile=netadmin)

Once configured correctly, the authetication is successful.

CHAP Authentication

AOS-CX configuration

Configure the AOS-CX component to use CHAP instead of the default PAP authentication type method:

configure
!
tacacs-server auth-type chap
end

It is not possible to use PAP and CHAP at the same time. It is a device configuration option.

TACACS+NG configuration

Using the same method as explained for PAP. Expand the tac_plus-ng configuration by adding the entry chap = clear auth-chap

    ...
    user cisco {
            password {
                    login = crypt $2a$10$34.ioPXaLJDD.PdEk.4Mle3g0cQw8e16thH1g0nQEC1.jW.sEHi1S
                    pap = clear pap-auth
                    chap = clear chap-auth
            }
            member = admin
    }
    ...

Now the configured user has 3 different authentication methods available. 2 usable for the AOS-CX platform, PAP and CHAP

  • login (bcrypt)
  • pap (clear)
  • chap (clear)

The login method is used for different TACACS+ client implementations. Each authentication method uses a different password. This is useful for tests, ensures the configured authentication method is actually used by the tested devices.

Verification

Use the show user information command to display the current user:

RS105# show user information

Username : cisco Authentication type : TACACS User group : administrators User privilege level : 15

Did not find out how to display the current line in use like f.e. vty or tty. Console local or Telnet/SSH via IP.

Verify the device is actually configured to use the authentication-type CHAP:

RS105# show running-config | i chap tacacs-server auth-type chap

Show the details, not sure what this Shared-secret: None or what it is:

RS105# show tacacs-server detail

! ! Output omitted for brevity ! * * * * TACACS+ Server Information * * * * Server-Name : 192.0.2.1 Auth-Port : 4949 VRF : default Shared-Secret : AQBapcSUOhduJ+J0PZqoyrvOSIhrGJFDTDpvIl1YeVeZfDeDEQAAALNP25zCzP67zZjRKO8fC5WF Timeout : 5 Auth-Type : chap Server-Group : tacacs Default-Priority : 2 Tracking : disabled Reachability-Status : unknown Tracking-Last-Attempted : N/A Next-Tracking-Request : N/A

Works using AOS-CX using CHAP.

CHAP auth debug

This is the debug ran on the AAA server side

user % tac_plus-ng -f tac_plus-ng.cfg -d 4

10777: 11:12:27.198 0/00000000: - Version 21ed8983f71c8d50ff25ae133a006ae571807db1 initialized 10777: 11:12:32.993 0/02f88423: 10.100.100.105 authen: hdr->seq_no: 1 10777: 11:12:32.993 0/02f88423: 10.100.100.105 looking for user cisco realm default 10777: 11:12:32.993 0/02f88423: 10.100.100.105 user lookup succeded 10777: 11:12:32.993 0/02f88423: 10.100.100.105 chap login for 'cisco' from 10.100.100.10 on ssh succeeded

Authetication using CHAP is successful.

PAP credentials encryption

Using the crypt library it is possible to encrypt the PAP credentials instead of the clear save method. The encryption has been shown in the 1st- TACACS+NG netlab. Now the method of encryption is applied to PAP credentials. This works for all man 3 crypt listed encryption methods, on a given operating system running the AAA daemon. Following pass encryption methods are supported:

  • Blowfish
  • SHA-512
  • SHA-256
  • MD5
  • 3DES

Configuration shown uses the Blowfish encryption as example.

Blowfish hash generation

The encrypted PAP password is bcrypt-pap. Generate the has using htpasswd command below:

htpasswd -bnBC 10 "" bcrypt-pap | tr -d ':\n'
$2y$10$NtwT2Cp/fjezs109gGsVdeyU4Am4q2j1IJ219/mMy.k29xNd9XXU2%

Add the generated hash to the tac_plus-ng.cfg configuration file, replacing the old entry:

...
    user cisco {
            password {
                login = crypt $2a$10$34.ioPXaLJDD.PdEk.4Mle3g0cQw8e16thH1g0nQEC1.jW.sEHi1S
                pap = crypt $2y$10$NtwT2Cp/fjezs109gGsVdeyU4Am4q2j1IJ219/mMy.k29xNd9XXU2
                }
            member = admin
        }
...

Verification

If you configured auth-type to CHAP before this step to, this needs to be set to the default setting PAP on the AOS-CX router.

This authentication succeeded, verifying the current tacacs autheticaiton settings, it is set to PAP:

R105# show tacacs-server detail

! ! Output omitted for brevity ! * * * * TACACS+ Server Information * * * * Server-Name : 192.0.2.1 Auth-Port : 4949 VRF : default Shared-Secret : AQBapcSUOhduJ+J0PZqoyrvOSIhrGJFDTDpvIl1YeVeZfDeDEQAAALNP25zCzP67zZjRKO8fC5WF Timeout : 5 Auth-Type : pap Server-Group : tacacs Default-Priority : 2 Tracking : disabled Reachability-Status : unknown Tracking-Last-Attempted : N/A Next-Tracking-Request : N/A

PAP auth debug

This is the debug on the AAA server side:

user % tac_plus-ng -f tac_plus-ng.cfg -d 4

28110: 12:04:45.927 0/00000000: - Version 21ed8983f71c8d50ff25ae133a006ae571807db1 initialized 28110: 12:04:53.053 0/07e502d2: 10.100.100.105 authen: hdr->seq_no: 1 28110: 12:04:53.053 0/07e502d2: 10.100.100.105 looking for user cisco realm default 28110: 12:04:53.053 0/07e502d2: 10.100.100.105 user lookup succeded 28110: 12:04:53.053 0/07e502d2: 10.100.100.105 pap login for 'cisco' from 10.100.100.10 on ssh succeeded (profile=netadmin)

The encrypted PAP credentials verified successfully. Access granted.

For configuring the same for CHAP, read the official TACACS+NG documentation.

Full TACACS+NG configuration

This is the fully working configuration explained in examples above. 3 fully working authentication methods:

  • login - Blowfish encrypted
  • pap - Blowfish encrypted
  • chap - clear

At the end of the netlab the final, resulting and fully working configuration file tac_plus-ng.conf:

#!/usr/sbin/tac_plus-ng
id = spawnd {
    listen = { address = 0.0.0.0 port = 4949 }
}

id = tac_plus-ng {

        host IPv4only {
                address = 0.0.0.0/0
                welcome banner = "\n Welcome to TACACS+NG\n\n"
                key = 123-my_tacacs_key
        }

        profile netadmin {
                script {
                        if (service == shell) {
                                if (cmd == "") {
                                        set priv-lvl = 15
                                        permit
                                }
                        }
                }
        }

        group admin

        user cisco {
        password {
            login = crypt $2a$10$34.ioPXaLJDD.PdEk.4Mle3g0cQw8e16thH1g0nQEC1.jW.sEHi1S
            pap   = crypt $2y$10$NtwT2Cp/fjezs109gGsVdeyU4Am4q2j1IJ219/mMy.k29xNd9XXU2              
            chap  = clear auth-chap

        }
                member = admin
        }

        ruleset {
                rule {
                        script { 
                                if (member == admin) { profile = netadmin permit }
                        }
                }
        }
}

That's all folks.

disable auth-type

This is something unrelated to the shown configuration above. While trying to configure and test AAA using ArubaOS-CX in the documentation, this shows interesting behaviour. So here the documentation how to use and configure the TACACS+ user authentication type using AOS-CX.

De-Configure auth-type, remove it:

no tacacs-server auth-type

And this is what how the device acts after successful authentication:

R105# show tacacs-server

Cannot execute command. Internal error. R105# show tacacs-server detail Detailed information about TACACS servers statistics Information about TACACS server statistics vsx-peer Displays VSX peer switch information R105# show tacacs-server detail Cannot execute command. Internal error. R105# show running-config Cannot execute command. Internal error.

It is possible to authenticate, everything else on the CLI fails. The most interesting is, that nothing is seen on the AAA server side, literally nothing when running with active debug output while authentication succeeds. Additionally it is using the correct credentials that are in the AAA configuration at server side, for the user cisco. Almost like if the credentials have been cached by the AOS-CX router used. Finally removing auth-type is somehow not a valid configuration here. It is part of the hidden defaults on AOS-CX.

The only useful option to disable auth-type, would be if a aditional auth-type would be availble, f.e.: the login type, which is the default for many other networking vendors. And if consistently implemented then a 3-rd auth-type option would be available.

Summary

Reading the TACACS+NG documentation helped to configure a working PAP and CHAP authentication using AOS-CX. Before writing this down here in a blog entry I had no experience how to configure this. Much like you, reading just now this here.

References

Related TACACS+NG posts: