TACACS Auth Supported in Cumulus?


So we are testing out Cumulus Linux here in our lab, and one question I had was whether TACACS/Radius were supported for AAA? The 2.0.2 Cumulus admin guide pointed to a link on ServerFault (http://serverfault.com/questions/425020/authenticate-linux-sshd-with-tacacs-cisco-acs) which detailed securing Linux boxes with Cisco ACS, however following that guide has been difficult as certain steps according to that guide fail. For instance, I downloaded the libpam package, then I also got the tar.gz file for pam uploaded to the box. However, when I go to ./configure the directory, the command is not found. When I try to locate the command using whereis it does not appear anywhere. I went ahead and installed gcc from apt-get, but that didn't help out in getting the files installed. (There is a configure.ac file and a Makefile.am file in the directory).

I was wondering if anyone knows what the next steps are, and if TACACS is even possible on these boxes. I'm not that good with Linux, but I got this far. Any ideas on how to get TACACS working?

35 replies

Userlevel 3
You can install the standard debian wheezy pam_tacplus package, and do TACACS+ authentication with any of the common TACACS+ servers, including ACS. However, you need to create the user locally on the switch with adduser or equivalent, since unlike LDAP, TACACS+ doesn't provide information like uid/gid/home directory/shell that are needed to login on linux.

That said, I've been working on enhancements to libpam_tacplus that remove the requirement to have a local user, and it also implements command accounting. Those packages are all open source, and are about to go into early testing (I'm the only one who has used it so far except one person who tried an earlier version with ACS).

There was discussion about doing something similar for Radius, but there seems to be much lower demand for that, so not currently on our roadmap.

pam (libpam0g, libpam-modules) are installed by default the Cumulus Linux switches, so you don't need to try and build them at all.

The development environment is not installed on CL switches, normally you would build on some debian wheezy server, and then copy the .deb packages to your switch or local repository to install them. You can install a development environment on the switch, but I wouldn't recommend it.
Thanks! I was trying to do this the hard way and I downloaded the pam_tacplus package directly, SFTP'd it into the switch, then tried to tar it and configure it... then it needed autoconf, so I downloaded the various autoconf tools (automake and libtool, installed C compiler and m4 as well)... and when I tried to ./configure it I got an error... then after doing all that I realized from your post that I just needed to install the libpam-tacplus package.. Hey at least I learned my way around linux better!

Thank you for the support.
Alright, so I gave it a whirl and it's still failing 😞. I installed the libpam-tacplus package. I modified the /etc/pam.d/sshd file and added the line (auth include tacacs). I then added created the /etc/pam.d/tacacs file as follows:

auth sufficient lib/security/pam_tacplus.so debug server=10.45.142.10 secret=test@123
account sufficient lib/security/pam_tacplus.so debug server=10.45.142.10 secret=test@123 service=shell protocol=ssh
session sufficient lib/security/pam_tacplus.so debug server=10.45.142.10 secret=test@123 service=shell protocol=ssh

Verified the IP address of the TACACS server, the shared secret key, verified settings on the TACACS server... and got nowhere.

Is there something missing, are my configs correct?

Userlevel 3
If you install the standard debian package, you shouldn't have to make any changes to the /etc/pam.d changes, because they use the pam-auth-update mechanism to add themselves to the common-* files, which get included into ssh and others. If you look at common-auth, common session, and common-account, you should see pam_tacplus lines, and you should add the server and secret fields to those lines, and remove the file you added and the change to the ssh file.

For example, I just downloaded and installed debian wheezy libpam-tacplus (no configuration) on a switch, and this is what I see:

egrep tacplus /etc/pam.d/common-*
/etc/pam.d/common-account:account sufficient pam_tacplus.so
/etc/pam.d/common-auth:auth sufficient pam_tacplus.so
/etc/pam.d/common-password:password sufficient pam_tacplus.so
/etc/pam.d/common-session:session sufficient pam_tacplus.so
/etc/pam.d/common-session-noninteractive:session sufficient pam_tacplus.so

In the updated version I've been working on, only one file needs to be modified to add the server info, because I now have 5 packages all using the same info.

Alright, with your help Mr. Olson I thing I've managed to make it almost there. I think I've got the basics setup, but it's still not accepting my password. Here is a output of the syslog messages generated when I try to authenticate.

2015-11-18T17:45:47.693439+00:00 cumulus-sw2 PAM-tacplus[27104]: auth failed: 2
2015-11-18T17:45:47.693470+00:00 cumulus-sw2 sshd[27104]: pam_sm_authenticate: exit with pam status: 7
2015-11-18T17:45:47.709380+00:00 cumulus-sw2 sshd[27104]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=c-ehsanv.na.qualcomm.com user=c_ehsanv
2015-11-18T17:45:49.542546+00:00 cumulus-sw2 sshd[27104]: Failed password for c_ehsanv from 10.46.176.80 port 23464 ssh2
2015-11-18T17:45:49.546887+00:00 cumulus-sw2 sshd[27104]: Connection closed by 10.46.176.80 [preauth]
2015-11-18T17:45:56.187034+00:00 cumulus-sw2 sshd[27120]: PAM unable to resolve symbol: pam_sm_chauthtok
2015-11-18T17:45:56.187246+00:00 cumulus-sw2 sshd[27120]: PAM unable to resolve symbol: pam_sm_chauthtok
2015-11-18T17:45:56.187516+00:00 cumulus-sw2 sshd[27120]: pam_sm_authenticate: called (pam_tacplus v1.3.6)
2015-11-18T17:45:56.187533+00:00 cumulus-sw2 sshd[27120]: pam_sm_authenticate: user [c_ehsanv] obtained
2015-11-18T17:45:56.187543+00:00 cumulus-sw2 sshd[27120]: tacacs_get_password: called
2015-11-18T17:45:56.187551+00:00 cumulus-sw2 sshd[27120]: tacacs_get_password: obtained password
2015-11-18T17:45:56.187558+00:00 cumulus-sw2 sshd[27120]: pam_sm_authenticate: password obtained
2015-11-18T17:45:56.187565+00:00 cumulus-sw2 sshd[27120]: pam_sm_authenticate: tty [ssh] obtained
2015-11-18T17:45:56.187572+00:00 cumulus-sw2 sshd[27120]: pam_sm_authenticate: rhost [c-ehsanv.na.qualcomm.com] obtained
2015-11-18T17:45:56.187579+00:00 cumulus-sw2 sshd[27120]: pam_sm_authenticate: trying srv 0
2015-11-18T17:45:59.257438+00:00 cumulus-sw2 PAM-tacplus[27120]: auth failed: 2
2015-11-18T17:45:59.257469+00:00 cumulus-sw2 sshd[27120]: pam_sm_authenticate: exit with pam status: 7

It's contacting the authentication server and the password is passed.. but authentication failed. Here is my updated configs (I deleted all previous modifications and re-installed the libpam-tacplus package).

itnet@cumulus-sw2:/etc/pam.d$ egrep tacplus /etc/pam.d/common-*
/etc/pam.d/common-account:account sufficient /lib/security/pam_tacplus.so debug secret=test@123 service=shell protocol=ssh
/etc/pam.d/common-auth:auth sufficient /lib/security/pam_tacplus.so debug server=10.45.142.10 secret=test@123
/etc/pam.d/common-password:password sufficient pam_tacplus.so
/etc/pam.d/common-session:session sufficient /lib/security/pam_tacplus.so server=10.45.142.10 secret=test@123 service=shell protocol=ssh
/etc/pam.d/common-session-noninteractive:session sufficient pam_tacplus.so

Wonder where I'm going wrong.

Thanks.

Ok, I noticed that I had forgotton to add the radius server on the common-account config, so I updated the config there to add the server. Still no go.
Userlevel 3
The messages about pam_sm_chauthtok are normal, because tacacs+ protocol doesn't support changing/updated passwords, and that's what that function does for the PAM stack, so ignore that.

error 7 in pam is an authentication error, and the "auth failed: 2" before that indicates that the tacacs server was contacted successfully, but most likely it's not liking your account name (if I remember correctly, I can research this further). It's possible the server may not like the class of user you are asking for. Try adding
login=login protocol=ssh service=shell
to your pam_tacplus.so lines and see if that makes a difference. Also, if you have access to the tacacs server logs, they may give you more info on the failure.

Oh, and if you haven't created your local account c_ehsanv with adduser yet, be sure you do that. The password won't matter. That shouldn't be your problem here, though, that would be the next step after the password.

I tried adding login=login on the common-account and common-session lines, still didn't like it. The TACACS+ server gave back this error:

"Most probably authentication failed because of invalid passcode, for the accurate reason please see RSA SecurID Server logs"

We do use RSA SecurID tokens, I'll research if any extra steps are needed for SecurID, and I'll also check with the admin for SecurID for some logs.

Thanks for all the continued support.

And now that I've just started researching the SecurID I've common across RSA PAM modules. I don't think this is necessary as the TACACS+ server handles the authentication part.
So it looks like the issues we are having was that there was no ACS profile attached to the device. The RSA admin will create a profile for us and we will try again. I'll update if we run into more issues.
Hi,

I am trying to Configure Cumulus switch to authenticate in TACAS plus server. I have installed libpam-tacplus packages from the repo and added line (auth include tacacs) on etc/pam.d/sshd . Also i added my TACAS plus sever details by creating tacas file on etc/pam.d as:
auth sufficient /usr/local/lib/security/pam_tacplus.so debug server=192.168.0.10 secret=password
account sufficient /usr/local/lib/security/pam_tacplus.so debug server=192168.0.10 secret=password service=shell protocol=ssh
session sufficient /usr/local/lib/security/pam_tacplus.so debug server=192.168.0.10 secret=password service=shell protocol=ssh
Now, I am not able to ssh the Cumulus Switch by local user or TACAS user. My TACAS server is working fine for Cisco and Juniper switches. What should I configure/change in the Cumulus to make it work ?
Userlevel 3
It's pretty hard to debug the problem from the info provided. Where did you put these lines (in which files, and where in the files)? Can you login on the serial console? If not, you'll have to boot up single user and login as root, and remove these lines.

I'm a bit curious as to why you chose /usr/local/lib/secure/pam_tacplus.so as the location of the plugin library. Did you build this yourself, or install the standard debian package (which shouldn't use /usr/local)?

When you look at the logs on the tacacs server, what do you see for attempts to login from the cumulus switch? Unless you made a cut and paste error, the "session" line has the wrong IP address, it should be "192.168", not "192168". If that's really what's there, that likely explains your problem.

I'd strongly recommend adding "debug" to all pam_tacplus.so lines, and watch the logs (/var/log/auth.log and/or /var/log/syslog) from a different root session when you attempt to login as the tacacs user.

Also, did you add the tacacs user (whatever it is) as a local user with the adduser command?
Hi Dave,

The line is in sshd file inside /etc/.pam.d/ as i mentioned above. Also the pam_tacplus.so was created default while installing the libpam-tacplus package. I have attached the cumulus logs below. The Ip address is fine its 192.168 in the config. I also have the same user as TACAS server in Cumulus with no password.

Dec 3 03:12:46 cumulus jdoo[3061]: 'chk_acl' file doesn't exist

Dec 3 03:12:46 cumulus jdoo[3061]: 'chk_acl' exec: /usr/share/cl-utilities/acl_check.sh
Dec 3 03:13:16 cumulus jdoo[3061]: 'chk_acl' file doesn't exist
Dec 3 03:13:16 cumulus jdoo[3061]: 'chk_acl' exec: /usr/share/cl-utilities/acl_check.sh
Dec 3 03:13:46 cumulus jdoo[3061]: 'chk_acl' file doesn't exist
Dec 3 03:13:46 cumulus jdoo[3061]: 'chk_acl' exec: /usr/share/cl-utilities/acl_check.sh
Dec 3 03:14:16 cumulus jdoo[3061]: 'chk_acl' file doesn't exist
Dec 3 03:14:16 cumulus jdoo[3061]: 'chk_acl' exec: /usr/share/cl-utilities/acl_check.sh
Dec 3 03:14:46 cumulus jdoo[3061]: 'chk_acl' file doesn't exist
Dec 3 03:14:46 cumulus jdoo[3061]: 'chk_acl' exec: /usr/share/cl-utilities/acl_check.sh
Dec 3 03:15:01 cumulus CRON[6861]: PAM unable to resolve symbol: pam_sm_chauthtok
Dec 3 03:15:01 cumulus CRON[6860]: PAM unable to resolve symbol: pam_sm_chauthtok
Dec 3 03:15:01 cumulus PAM-tacplus[6861]: user not authenticated by TACACS+
Dec 3 03:15:01 cumulus PAM-tacplus[6861]: TACACS+ service type not configured
Dec 3 03:15:01 cumulus CRON[6861]: Cannot make/remove an entry for the specified session
Dec 3 03:15:01 cumulus PAM-tacplus[6860]: user not authenticated by TACACS+
Dec 3 03:15:01 cumulus PAM-tacplus[6860]: TACACS+ service type not configured
Dec 3 03:15:01 cumulus CRON[6860]: Cannot make/remove an entry for the specified session
Dec 3 03:15:16 cumulus jdoo[3061]: 'chk_acl' file doesn't exist
Dec 3 03:15:16 cumulus jdoo[3061]: 'chk_acl' exec: /usr/share/cl-utilities/acl_check.sh

The acl_check.sh file is there in /usr/share/cl-utilities already. Now i am not able to ssh from TACAS user or from local user and only can access Cumulus from console.

Userlevel 3
You shouldn't be editting /etc/pam.d/sshd, if that's what you are saying. You should be adding the pam_tacplus.so lines just before the unix.so lines in common-auth, common-session, common-account. By 'installing the pam_tacplus package", do you mean you downloaded the sources and built it? That's not the path that should exist if you just installed the standard debian pam-tacplus package (which I highly recommend). The pam_sm_chauthok message is normal, because pam-tacplus doesn't implement that. The jdoo messages aren't relevant. The line
TACACS+ service type not configured
is because you don't have
service=shell
on your pam_tacplus.so lines. Sometimes you need it, sometimes you don't, so try adding it. What messages are you seeing on the tacacs server logs?


Hi Dave,

Thanks for your help. Finally managed to make TACACS authentication work. I reinstalled the libpam-tacplus package from the cumulus user and then edited common-auth, common-session, common-account files with the lines. also added login=login in that line to make it work. Just wondering what extra parameter needs to added in the pam_tacplus.so line to log the commands in TACAS plus server executed by the user in cumulus. Right now its only logging the login activity of the user in server.
Userlevel 3
"Real" accounting to a tacacs server requires a whole new set of packages and changes to libpam-tacplus that I've been working on . We aren't quite ready for customers to try that yet, it's very lightly tested, and may cause problems on a production system.
Thanks for you reply, please let us know in the community when it is ready. 🙂
Userlevel 3
For anybody interested in being an alpha tester on the new TACACS+ packages, I can make them available. You'll need to be willing to give me feedback, and possibly to help me debug problems.

These packages give "full" accounting (all commands run under a tacacs login, plus tacacs login/logout, but not (yet) commands run through cli tools such as vtysh. I have the vtysh patches to login vtysh interactive commands, but I'm not yet prepared to make that available.

It's a modified libpam-tacplus debian package, plus an additional 4 new packages. All are open source, and I've sent information about them through the upstream tacplus mailing list, but they aren't in any upstream version.

With these changes, it's no longer necessary have local accounts for all the users who will login through tacacs authentication, as long as at least one tacacs user (tacacs0, tacacs15 would be the minimum to be practical) for mapping of tacacs privilege levels.

If you want to be part of testing this, I'll need to know what Cumulus Linux version you use (I'd prefer 2.5.4 or later), and what TACACS+ server you use. It should work with any TACACS+ server, but at the moment, I've only tested with the linux "tacacs+" server.

No promises on fast support or turnaround, but I am interested in getting real world experience.
For this time around, I'd like to only involve people who are already using TACACS authentication, not those new to TACACS.
Userlevel 3
The TACACS+ client code is a new Early Access feature in the just announced Cumulus Linux 3.1. The docs are here:https://docs.cumulusnetworks.com/pages/viewpage.action?pageId=5118449
Very happy to see this! I was able to get TACACS authentication working using the old method that required local users to be created. I decided to give this method a try, as this is critical for us to get up and running. Unfortunately I am running into problems again. Per the documentation I installed the tacplus-client set of packages, and I edited the /etc/tacplus-servers and /etc/tacplus_nss.conf files to point to our tacacs servers (Cisco ACS). The device was added in the Cisco ACS with the pre-shared key. I ran the pam-auth-update command to disable unix authentication and only allow tacacs auth. Could not login at all. I set debugging on, and here is what I see in /var/log/syslog

OUTPUT of /var/log/syslog:
------------------------------------------------------------------------------------------------------------------------
2016-09-14T18:57:52.291485+00:00 san-af145-cls-6712-04 sshd[1985]: nss_tacplus: server[0] { addr=10.45.142.10:49, key='test123' }
2016-09-14T18:57:52.292364+00:00 san-af145-cls-6712-04 sshd[1985]: nss_tacplus: server[1] { addr=10.47.4.26:49, key='test123' }
2016-09-14T18:57:52.654114+00:00 san-af145-cls-6712-04 sshd[1985]: Invalid user evessal from 10.62.23.168
2016-09-14T18:57:52.654804+00:00 san-af145-cls-6712-04 sshd[1985]: input_userauth_request: invalid user evessal [preauth]
2016-09-14T18:57:52.662948+00:00 san-af145-cls-6712-04 sshd[1985]: Failed password for invalid user evessal from 10.62.23.168 port 4577 ssh2
2016-09-14T18:57:52.666728+00:00 san-af145-cls-6712-04 sshd[1985]: Connection closed by 10.62.23.168 [preauth]
2016-09-14T18:58:32.593370+00:00 san-af145-cls-6712-04 bash: nss_tacplus: server[0] { addr=10.45.142.10:49, key='test123' }
2016-09-14T18:58:32.594107+00:00 san-af145-cls-6712-04 bash: nss_tacplus: server[1] { addr=10.47.4.26:49, key='test123' }
2016-09-14T18:59:42.593246+00:00 san-af145-cls-6712-04 bash: nss_tacplus: server[0] { addr=10.45.142.10:49, key='test123' }
2016-09-14T18:59:42.593976+00:00 san-af145-cls-6712-04 bash: nss_tacplus: server[1] { addr=10.47.4.26:49, key='test123' }
2016-09-14T19:00:01.355263+00:00 san-af145-cls-6712-04 cron[445]: Authentication failure
2016-09-14T19:00:01.355933+00:00 san-af145-cls-6712-04 CRON[2001]: Authentication failure
2016-09-14T19:00:16.104112+00:00 san-af145-cls-6712-04 sudo: nss_tacplus: server[0] { addr=10.45.142.10:49, key='test123' }
2016-09-14T19:00:16.104962+00:00 san-af145-cls-6712-04 sudo: nss_tacplus: server[1] { addr=10.47.4.26:49, key='test123' }

I can verify that the switch can ping 10.45.142.10 and 10.47.4.26, and it can also telnet into both of these addresses on port 49. When I look into logs on the TACACS server though I don't see any connections coming through from the cumulus switch. I'll output my configs for /etc/tacplus-servers and /etc/tacplus-nss.conf

OUTPUT for /etc/tacplus_servers:
--------------------------------------------

cumulus@san-af145-cls-6712-04:~$ sudo cat /etc/tacplus_servers
# This is a common file used by audisp-tacplus, libpam_tacplus, and
# libtacplus_map config files as shipped.
#
# Any tac_plus client config can go here that is common to all users of this
# file, but typically it's just the TACACS+ server IP address(es) and shared
# secret(s)
#
# This file should normally be mode 600, if you care about the security
# of your secret key. When set to mode 600 NSS lookups for TACACS users
# will only work for tacacs users that are logged in, via the local mapping.
# For root, lookups will work for any tacacs users, logged in or not.

secret=test123
server=10.45.142.10
#login=login
debug=1

OUTPUT for /etc/tacplus_nss.conf:
--------------------------------------------------------------------------------------
cumulus@san-af145-cls-6712-04:~$ cat /etc/tacplus_nss.conf
#%NSS_TACPLUS-1.0
# Install this file as /etc/tacplus_nss.conf
# Edit /etc/nsswitch.conf to add tacplus to the passwd lookup, similar to this
# where tacplus precede compat (or files), and depending on local policy can
# follow or precede ldap, nis, etc.
# passwd: tacplus compat
# The server keyword should follow the secret keyword, and may be
# given fewer times than the server keyword, if all servers have the same
# shared secret.
# is matched up with first secret line, etc. You can use any of the
# following orders, or most other orders you can think of. There must be at
# least as many secret lines as there are server lines. This file should be
# kept as permisions 644, owned by root, since it must be readable by arbitrary
# processes, even though the secret for the TACACS+ server is present as clear
# text.
# Servers are tried in the order listed, and once a server
# replies, no other servers are attempted in a given process instantiation
#
# This configuration is similar to the libpam_tacplus configuration, but
# is maintained as a configuration file, since nsswitch.conf doesn't
# support passing parameters. Parameters must start in the first
# column, and parsing stops at the first whitespace

# if set, errors and other issues are logged with syslog
# debug=1

# The include keyword allows centralizing the tacacs+ server information
# including the IP address and shared secret
include=/etc/tacplus_servers

# The server IP address can be optionally followed by a ':' and a port
# number (server=1.1.1.1:49).
secret=test123
server=10.47.4.26
debug=1
#secret=SECRET2
#server=1.1.1.2

Any help to get this up and running would be much appreciated!

--Ehsan
Userlevel 3
Ehsan, I've never tested removing the ability to use local authentication. I would strongly suggest that you not do that. Even if everything works perfectly in normal operation, if you ever have a networking problem, you won't be able to login without rebooting and coming up in single user mode.

Can you try a test that may be a bit simpler to debug? With the config files above,
run ''

When I do that with user 'olsont' (a tacacs user), when it works, I see output like this

2016-09-14T22:35:14.602059+00:00 superm-redxp-02 su: nss_tacplus: server[0] { addr=192.168.3.189:49, key='tacacskey' }
2016-09-14T22:35:14.618665+00:00 superm-redxp-02 PAM-tacplus[23193]: 1 servers defined
2016-09-14T22:35:14.619066+00:00 superm-redxp-02 PAM-tacplus[23193]: server[0] { addr=192.168.3.189:49, key='tacacskey' }
2016-09-14T22:35:14.619410+00:00 superm-redxp-02 PAM-tacplus[23193]: tac_service='shell'
2016-09-14T22:35:14.619760+00:00 superm-redxp-02 PAM-tacplus[23193]: tac_protocol='ssh'
2016-09-14T22:35:14.620111+00:00 superm-redxp-02 PAM-tacplus[23193]: tac_prompt=''
2016-09-14T22:35:14.620478+00:00 superm-redxp-02 PAM-tacplus[23193]: tac_login='login'
2016-09-14T22:35:14.620830+00:00 superm-redxp-02 su[23193]: pam_sm_acct_mgmt: called (pam_tacplus v1.3.8)
2016-09-14T22:35:14.621174+00:00 superm-redxp-02 su[23193]: find_tac_server: trying srv 0
2016-09-14T22:35:14.621528+00:00 superm-redxp-02 su[23193]: talk_tac_server: sent authorization request
2016-09-14T22:35:14.621898+00:00 superm-redxp-02 su[23193]: find_tac_server: active srv 0
2016-09-14T22:35:14.622237+00:00 superm-redxp-02 su[23193]: pam_sm_acct_mgmt: user [olsont] successfully authorized
2016-09-14T22:35:14.622595+00:00 superm-redxp-02 su[23193]: pam_sm_acct_mgmt: returned attribute 'PRIV_LVL(=15)' from server
2016-09-14T22:35:14.622938+00:00 superm-redxp-02 su[23193]: Successful su for olsont by root
2016-09-14T22:35:14.623282+00:00 superm-redxp-02 su[23193]: + /dev/pts/0 root:olsont
2016-09-14T22:35:14.634951+00:00 superm-redxp-02 PAM-tacplus[23193]: 1 servers defined
2016-09-14T22:35:14.635385+00:00 superm-redxp-02 PAM-tacplus[23193]: server[0] { addr=192.168.3.189:49, key='tacacskey' }
2016-09-14T22:35:14.635766+00:00 superm-redxp-02 PAM-tacplus[23193]: tac_service='shell'
2016-09-14T22:35:14.636103+00:00 superm-redxp-02 PAM-tacplus[23193]: tac_protocol='ssh'
2016-09-14T22:35:14.636451+00:00 superm-redxp-02 PAM-tacplus[23193]: tac_prompt=''
2016-09-14T22:35:14.636799+00:00 superm-redxp-02 PAM-tacplus[23193]: tac_login='login'
2016-09-14T22:35:14.637138+00:00 superm-redxp-02 su[23193]: _pam_account: [start] called (pam_tacplus v1.3.8)
2016-09-14T22:35:14.637792+00:00 superm-redxp-02 su[23193]: _pam_account: username [olsont] obtained
2016-09-14T22:35:14.638175+00:00 superm-redxp-02 su[23193]: _pam_account: tty [pts/0] obtained
2016-09-14T22:35:14.638674+00:00 superm-redxp-02 su[23193]: _pam_account: rhost [unknown] obtained
2016-09-14T22:35:14.639135+00:00 superm-redxp-02 su[23193]: _pam_account: connected with fd=5 (srv 0)
2016-09-14T22:35:14.639632+00:00 superm-redxp-02 su[23193]: _pam_account: [start] for [olsont] sent
2016-09-14T22:35:14.640097+00:00 superm-redxp-02 audisp-tacplus: nss_tacplus: server[0] { addr=192.168.3.189:49, key='tacacskey' }
2016-09-14T22:35:19.367149+00:00 superm-redxp-02 su: nss_tacplus: server[0] { addr=192.168.3.189:49, key='tacacskey' }
2016-09-14T22:35:19.383810+00:00 superm-redxp-02 PAM-tacplus[23229]: 1 servers defined
2016-09-14T22:35:19.384240+00:00 superm-redxp-02 PAM-tacplus[23229]: server[0] { addr=192.168.3.189:49, key='tacacskey' }
2016-09-14T22:35:19.384613+00:00 superm-redxp-02 PAM-tacplus[23229]: tac_service='shell'
2016-09-14T22:35:19.384951+00:00 superm-redxp-02 PAM-tacplus[23229]: tac_protocol='ssh'
2016-09-14T22:35:19.385286+00:00 superm-redxp-02 PAM-tacplus[23229]: tac_prompt=''
2016-09-14T22:35:19.385645+00:00 superm-redxp-02 PAM-tacplus[23229]: tac_login='login'
2016-09-14T22:35:19.385989+00:00 superm-redxp-02 su[23229]: pam_sm_authenticate: called (pam_tacplus v1.3.8)
2016-09-14T22:35:19.386327+00:00 superm-redxp-02 su[23229]: pam_sm_authenticate: user [olsont] obtained
2016-09-14T22:35:19.386673+00:00 superm-redxp-02 su[23229]: tacacs_get_password: called
2016-09-14T22:35:21.285308+00:00 superm-redxp-02 su[23229]: tacacs_get_password: obtained password
2016-09-14T22:35:21.285816+00:00 superm-redxp-02 su[23229]: pam_sm_authenticate: password obtained
2016-09-14T22:35:21.286165+00:00 superm-redxp-02 su[23229]: pam_sm_authenticate: tty [pts/0] obtained
2016-09-14T22:35:21.286510+00:00 superm-redxp-02 su[23229]: pam_sm_authenticate: rhost [unknown] obtained
2016-09-14T22:35:21.286840+00:00 superm-redxp-02 su[23229]: find_tac_server: trying srv 0
2016-09-14T22:35:21.287584+00:00 superm-redxp-02 su[23229]: tacacs status: TAC_PLUS_AUTHEN_STATUS_GETPASS
2016-09-14T22:35:21.287955+00:00 superm-redxp-02 su[23229]: tac_auth_converse: tac_cont_send called
2016-09-14T22:35:21.325783+00:00 superm-redxp-02 su[23229]: tacacs status: TAC_PLUS_AUTHEN_STATUS_PASS
2016-09-14T22:35:21.326205+00:00 superm-redxp-02 su[23229]: find_tac_server: active srv 0
2016-09-14T22:35:21.326598+00:00 superm-redxp-02 su[23229]: pam_sm_authenticate: exit with pam status: 0
2016-09-14T22:35:21.332186+00:00 superm-redxp-02 PAM-tacplus[23229]: 1 servers defined
2016-09-14T22:35:21.332607+00:00 superm-redxp-02 PAM-tacplus[23229]: server[0] { addr=192.168.3.189:49, key='tacacskey' }
2016-09-14T22:35:21.332985+00:00 superm-redxp-02 PAM-tacplus[23229]: tac_service='shell'
2016-09-14T22:35:21.333329+00:00 superm-redxp-02 PAM-tacplus[23229]: tac_protocol='ssh'
2016-09-14T22:35:21.333711+00:00 superm-redxp-02 PAM-tacplus[23229]: tac_prompt=''
2016-09-14T22:35:21.334062+00:00 superm-redxp-02 PAM-tacplus[23229]: tac_login='login'
2016-09-14T22:35:21.334411+00:00 superm-redxp-02 su[23229]: pam_sm_acct_mgmt: called (pam_tacplus v1.3.8)
2016-09-14T22:35:21.334779+00:00 superm-redxp-02 su[23229]: do_tac_connect: reconnecting to server
2016-09-14T22:35:21.335124+00:00 superm-redxp-02 su[23229]: talk_tac_server: sent authorization request
2016-09-14T22:35:21.335478+00:00 superm-redxp-02 su[23229]: pam_sm_acct_mgmt: user [olsont] successfully authorized
2016-09-14T22:35:21.335822+00:00 superm-redxp-02 su[23229]: pam_sm_acct_mgmt: returned attribute 'PRIV_LVL(=15)' from server
2016-09-14T22:35:21.336663+00:00 superm-redxp-02 su[23229]: Successful su for olsont by olsont
2016-09-14T22:35:21.337041+00:00 superm-redxp-02 su[23229]: + /dev/pts/0 olsont:olsont
2016-09-14T22:35:21.343152+00:00 superm-redxp-02 PAM-tacplus[23229]: 1 servers defined
2016-09-14T22:35:21.343561+00:00 superm-redxp-02 PAM-tacplus[23229]: server[0] { addr=192.168.3.189:49, key='tacacskey' }
2016-09-14T22:35:21.343914+00:00 superm-redxp-02 PAM-tacplus[23229]: tac_service='shell'
2016-09-14T22:35:21.344289+00:00 superm-redxp-02 PAM-tacplus[23229]: tac_protocol='ssh'
2016-09-14T22:35:21.344644+00:00 superm-redxp-02 PAM-tacplus[23229]: tac_prompt=''
2016-09-14T22:35:21.344981+00:00 superm-redxp-02 PAM-tacplus[23229]: tac_login='login'
2016-09-14T22:35:21.345348+00:00 superm-redxp-02 su[23229]: pam_sm_setcred: called (pam_tacplus v1.3.8)
2016-09-14T22:35:21.351613+00:00 superm-redxp-02 PAM-tacplus[23229]: 1 servers defined
2016-09-14T22:35:21.353031+00:00 superm-redxp-02 PAM-tacplus[23229]: server[0] { addr=192.168.3.189:49, key='tacacskey' }
2016-09-14T22:35:21.354564+00:00 superm-redxp-02 PAM-tacplus[23229]: tac_service='shell'
2016-09-14T22:35:21.356083+00:00 superm-redxp-02 PAM-tacplus[23229]: tac_protocol='ssh'
2016-09-14T22:35:21.357434+00:00 superm-redxp-02 PAM-tacplus[23229]: tac_prompt=''
2016-09-14T22:35:21.359966+00:00 superm-redxp-02 PAM-tacplus[23229]: tac_login='login'
2016-09-14T22:35:21.360470+00:00 superm-redxp-02 su[23229]: _pam_account: [start] called (pam_tacplus v1.3.8)
2016-09-14T22:35:21.360837+00:00 superm-redxp-02 su[23229]: _pam_account: username [olsont] obtained
2016-09-14T22:35:21.361219+00:00 superm-redxp-02 su[23229]: _pam_account: tty [pts/0] obtained
2016-09-14T22:35:21.361620+00:00 superm-redxp-02 su[23229]: _pam_account: rhost [unknown] obtained
2016-09-14T22:35:21.361966+00:00 superm-redxp-02 su[23229]: _pam_account: connected with fd=5 (srv 0)
2016-09-14T22:35:21.362318+00:00 superm-redxp-02 su[23229]: _pam_account: [start] for [olsont] sent
2016-09-14T22:35:23.726194+00:00 superm-redxp-02 PAM-tacplus[23229]: 1 servers defined
2016-09-14T22:35:23.726662+00:00 superm-redxp-02 PAM-tacplus[23229]: server[0] { addr=192.168.3.189:49, key='tacacskey' }
2016-09-14T22:35:23.727100+00:00 superm-redxp-02 PAM-tacplus[23229]: tac_service='shell'
2016-09-14T22:35:23.727474+00:00 superm-redxp-02 PAM-tacplus[23229]: tac_protocol='ssh'
2016-09-14T22:35:23.727821+00:00 superm-redxp-02 PAM-tacplus[23229]: tac_prompt=''
2016-09-14T22:35:23.728157+00:00 superm-redxp-02 PAM-tacplus[23229]: tac_login='login'
2016-09-14T22:35:23.728526+00:00 superm-redxp-02 su[23229]: _pam_account: [stop] called (pam_tacplus v1.3.8)
2016-09-14T22:35:23.728977+00:00 superm-redxp-02 su[23229]: _pam_account: username [olsont] obtained
2016-09-14T22:35:23.729337+00:00 superm-redxp-02 su[23229]: _pam_account: tty [pts/0] obtained
2016-09-14T22:35:23.729703+00:00 superm-redxp-02 su[23229]: _pam_account: rhost [unknown] obtained
2016-09-14T22:35:23.730052+00:00 superm-redxp-02 su[23229]: _pam_account: connected with fd=5 (srv 0)
2016-09-14T22:35:23.730417+00:00 superm-redxp-02 su[23229]: _pam_account: [stop] for [olsont] sent
2016-09-14T22:35:23.730808+00:00 superm-redxp-02 PAM-tacplus[23229]: 1 servers defined
2016-09-14T22:35:23.731227+00:00 superm-redxp-02 PAM-tacplus[23229]: server[0] { addr=192.168.3.189:49, key='tacacskey' }
2016-09-14T22:35:23.731643+00:00 superm-redxp-02 PAM-tacplus[23229]: tac_service='shell'
2016-09-14T22:35:23.732447+00:00 superm-redxp-02 PAM-tacplus[23229]: tac_protocol='ssh'
2016-09-14T22:35:23.732635+00:00 superm-redxp-02 PAM-tacplus[23229]: tac_prompt=''
2016-09-14T22:35:23.732748+00:00 superm-redxp-02 PAM-tacplus[23229]: tac_login='login'
2016-09-14T22:35:23.732855+00:00 superm-redxp-02 su[23229]: pam_sm_setcred: called (pam_tacplus v1.3.8)
2016-09-14T22:35:26.289185+00:00 superm-redxp-02 PAM-tacplus[23193]: 1 servers defined
2016-09-14T22:35:26.289656+00:00 superm-redxp-02 PAM-tacplus[23193]: server[0] { addr=192.168.3.189:49, key='tacacskey' }
2016-09-14T22:35:26.290015+00:00 superm-redxp-02 PAM-tacplus[23193]: tac_service='shell'
2016-09-14T22:35:26.290363+00:00 superm-redxp-02 PAM-tacplus[23193]: tac_protocol='ssh'
2016-09-14T22:35:26.290721+00:00 superm-redxp-02 PAM-tacplus[23193]: tac_prompt=''
2016-09-14T22:35:26.291066+00:00 superm-redxp-02 PAM-tacplus[23193]: tac_login='login'
2016-09-14T22:35:26.291414+00:00 superm-redxp-02 su[23193]: _pam_account: [stop] called (pam_tacplus v1.3.8)
2016-09-14T22:35:26.291885+00:00 superm-redxp-02 su[23193]: _pam_account: username [olsont] obtained
2016-09-14T22:35:26.292244+00:00 superm-redxp-02 su[23193]: _pam_account: tty [pts/0] obtained
2016-09-14T22:35:26.292604+00:00 superm-redxp-02 su[23193]: _pam_account: rhost [unknown] obtained
2016-09-14T22:35:26.292978+00:00 superm-redxp-02 su[23193]: _pam_account: connected with fd=5 (srv 0)
2016-09-14T22:35:26.293823+00:00 superm-redxp-02 su[23193]: _pam_account: [stop] for [olsont] sent

All in syslog. I'm seeing much less output for your ssh case, so I'd like to see an apples to apples comparison.

If I try with an invalid user, I see much less output, such as this (using 'olsonz')

2016-09-14T22:35:40.939107+00:00 superm-redxp-02 bash: nss_tacplus: server[0] { addr=192.168.3.189:49, key='tacacskey' }
2016-09-14T22:35:47.055726+00:00 superm-redxp-02 su: nss_tacplus: server[0] { addr=192.168.3.189:49, key='tacacskey' }
2016-09-14T22:35:47.081175+00:00 superm-redxp-02 su[23276]: No passwd entry for user 'olsonz'
2016-09-14T22:35:47.081669+00:00 superm-redxp-02 su[23276]: FAILED su for olsonz by root
2016-09-14T22:35:47.082064+00:00 superm-redxp-02 su[23276]: - /dev/pts/0 root:olsonz

You should see the same kind of thing with 'getent passwd olsonz'; that's only doing the NSS lookup over tacacs. A valid user over nss will have only the server lines, but will return a passwd line:

getent passwd olsont
olsont❌1016:1001:TACACS+ mapped user at privilege level 15,,,:/home/tacacs15:/bin/bash

2016-09-14T22:42:54.167876+00:00 superm-redxp-02 getent: nss_tacplus: server[0] { addr=192.168.3.189:49, key='tacacskey' }


Dave

Understood, I won't take off Unix authentication.

Just a curiosity, you wrote:

Can you try a test that may be a bit simpler to debug? With the config files above,
run ''

Did something get cut-off here?

--Ehsan

Userlevel 3
Editting mistake on my part. It was run: 'su yourtacusername' from the switch (as non-root, of course).
Hi Dave

It has not entry for my tacacs user name:

cumulus@san-af145-cls-6712-04:~$ su evessal
No passwd entry for user 'evessal'

Furthermore, I get no return data when I type in the getent passwd evessal. Also still seeing no hits coming from this particular switch in the TACACS server (it has been configured with the pre-shared key shown in the logs).

The log output in /var/log/syslog did change slightly when I re-enabled Unix auth. I've added it below:

2016-09-14T23:14:19.590350+00:00 san-af145-cls-6712-04 sshd[1149]: nss_tacplus: server[0] { addr=10.45.142.10:49, key='test123' }
2016-09-14T23:14:19.590958+00:00 san-af145-cls-6712-04 sshd[1149]: nss_tacplus: server[1] { addr=10.47.4.26:49, key='test123' }
2016-09-14T23:14:19.891002+00:00 san-af145-cls-6712-04 sshd[1149]: Invalid user evessal from 10.71.134.17
2016-09-14T23:14:19.891698+00:00 san-af145-cls-6712-04 sshd[1149]: input_userauth_request: invalid user evessal [preauth]
2016-09-14T23:14:19.900760+00:00 san-af145-cls-6712-04 sshd[1149]: pam_unix(sshd:auth): check pass; user unknown
2016-09-14T23:14:19.901277+00:00 san-af145-cls-6712-04 sshd[1149]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=evessal2.qualcomm.com
2016-09-14T23:14:22.369875+00:00 san-af145-cls-6712-04 sshd[1149]: Failed password for invalid user evessal from 10.71.134.17 port 31579 ssh2
2016-09-14T23:14:22.403371+00:00 san-af145-cls-6712-04 sshd[1149]: Connection closed by 10.71.134.17 [preauth]
2016-09-14T23:14:26.466137+00:00 san-af145-cls-6712-04 sudo: nss_tacplus: server[0] { addr=10.45.142.10:49, key='test123' }
2016-09-14T23:14:26.466642+00:00 san-af145-cls-6712-04 sudo: nss_tacplus: server[1] { addr=10.47.4.26:49, key='test123' }
2016-09-14T23:14:26.478125+00:00 san-af145-cls-6712-04 sudo: cumulus : TTY=pts/0 ; PWD=/home/cumulus ; USER=root ; COMMAND=/bin/more /var/log/syslog
2016-09-14T23:14:26.487187+00:00 san-af145-cls-6712-04 sudo: pam_unix(sudo:session): session opened for user root by cumulus(uid=0)
2016-09-14T23:14:34.964468+00:00 san-af145-cls-6712-04 sudo: pam_unix(sudo:session): session closed for user root
2016-09-14T23:15:01.733461+00:00 san-af145-cls-6712-04 bash: nss_tacplus: server[0] { addr=10.45.142.10:49, key='test123' }
2016-09-14T23:15:01.734204+00:00 san-af145-cls-6712-04 bash: nss_tacplus: server[1] { addr=10.47.4.26:49, key='test123' }
2016-09-14T23:15:01.740781+00:00 san-af145-cls-6712-04 bash: nss_tacplus: server[0] { addr=10.45.142.10:49, key='test123' }
2016-09-14T23:15:01.741302+00:00 san-af145-cls-6712-04 bash: nss_tacplus: server[1] { addr=10.47.4.26:49, key='test123' }

Userlevel 3
OK, something isn't set up right with PAM. The pam_tacplus plugin is not getting invoked.

Can you send 'dpkg -l \*tac\* | grep cl3'? Also 'grep tacplus /etc/pam.d/*'? How did you do your install? Have you manually configured PAM?

Reply