Problems getting PAM Authentication to work with tac_plus-ng

[mattablaze]

Hey there, I've been spending a bunch of time in the google groups trying to find an answer to this and I'm having no luck.

The relevant configs that I think are in play here are:         mavis module = external {                 exec = /usr/local/sbin/pammavis pammavis -s ssh                 childs min = 4                 childs max = 64         }

        user backend = mavis         login backend = mavis         pap backend = mavis

        user testuser {                 password login = mavis                 password pap = login                 member = admin         }

Creating a test user with cleartext password works just fine so it has to be a problem with authentication.          user demo {                 password login = clear demo                 password pap = login                 member = admin         }

The default config that comes with tac_plus-ng might be throwing me off.  Is it possible to post a sample config of what a true-PAM authentication looks like or point me in the right direction?  I've tried the example that is listed in your documentation, but I'm still coming up blank.

From the debug logs, I see: 133486: 20:03:11.105 0/82c29a72: 10.94.0.14 authen: hdr->seq_no: 3 133486: 20:03:11.105 0/82c29a72: 10.94.0.14 looking for user testuser realm heck 133486: 20:03:11.105 0/82c29a72: 10.94.0.14 user lookup succeded 133486: 20:03:11.105 0/82c29a72: 10.94.0.14 looking for user testuser in MAVIS backend 133486: 20:03:11.416 0/82c29a72: 10.94.0.14 result for user testuser is NAK [311 ms] 133486: 20:03:11.416 0/82c29a72: 10.94.0.14 looking for user testuser realm heck 133486: 20:03:11.416 0/82c29a72: 10.94.0.14 user lookup succeded 133486: 20:03:11.416 0/82c29a72: 10.94.0.14 shell login for 'testuser' (realm: heck) from 192.168.176.99 on ssh failed (profile=admin)

In previous solutions using PAM, I've always had to do some edits to the /etc/pam.d/* files to get the association to work correctly.  In the documentation, it doesn't mention any of that and I assume it's because MAVIS handles this, and that's one area I'm not too familiar with. 

[mattablaze]

I also found a post that looks like similar problem to mine, but it's 14 years old.

I created /etc/pam.d/mavis with: auth required pam_unix.so nodelay account required pam_unix.so password required pam_unix.so session required pam_unix.so

and that didn't change anything, still getting a NAK for user lookup via MAVIS.

This is on Debian 11.11 We use LDAP on the backend for authentication, of which PAM should be able to use it - other legacy (shrubbery.net) TACACS servers are setup similar.

[MarcJHuber]

Hi,

I see nothing obviously wrong in your config. My best guess is that you'll need to run pammavis as root (via sudo, for example).

I've added a PAM sample config in 7a10fdcd90d48d3f7e69c2962b77ae07ab7f66d6 (tac_plus-ng/sample/tac_plus-ng-pam-demo.cfg).

Cheers,

Marc

[mattablaze]

Hmm. Thanks for providing that example. I do see a couple difference sbetween what you posted and my config.

This line you wrote:

mavis module demo = external { exec = /usr/local/sbin/pammavis pammavis -s sshd }

Is that the same as

    mavis module = external {
            exec = /usr/local/sbin/pammavis pammavis -s ssh
            childs min = 4
            childs max = 64
    }

The word "demo" in your example maps to the profile name, I assume? I don't think the profile is even getting executed since the MAVIS user lookup fails first. Or are they somehow conjoined and I need to explicitly define it that way?

And the word "sshd" at the end compared to mine "ssh" is different.

And last - to clarify, I don't need anything in /etc/pam.d/mavis?

[MarcJHuber]

Hi,

my bad ... the various "demo" names are mostly unrelated, the only one relevant is the "profile = demo" part which refers to the demo profile.

Please check whether /etc/pam.d/ssh actually exists. If not, PAM may fall back to /etc/pam.d/other which eventually denies authentication. I'd add a /etc/pam.d/mavis file containing

@include common-auth @include common-account @include common-password

(at least that would work on Ubuntu) and remove the "-s ssh" option from pammavis.

I'll push an updated sample configuration in a couple of minutes, I hope things will become clearer then.

Cheers,

Marc

[mattablaze]

I've been running several different tests with what you described above. I haven't been able to make this work with PAM at all. I'm still seeing what looks like a lookup failure. I've tested removing the "-s ssh" from the pammavis line: exec = /usr/local/sbin/pammavis pammavis

160255: 17:31:10.289 0/d106c472: 10.4.0.14 looking for user testuser realm heck 160255: 17:31:10.289 0/d106c472: 10.4.0.14 user lookup succeded 160255: 17:31:10.289 0/d106c472: 10.4.0.14 looking for user testuser in MAVIS backend 160255: 17:31:10.501 0/d106c472: 10.4.0.14 result for user testuser is NAK [212 ms]

I don't have an /etc/pam.d/ssh file. I created the /etc/pam.d/mavis with what you listed above. No change.

It might help to explain our env just a little bit. All of our servers, including this one that tacacs-ng is running on is tied into LDAP using nsssd. We have had no issues using PAM before with this type of setup. The unknown piece here is "MAVIS" and I've spent some time reviewing the documentation and much of it is over my head.

I'm contemplating just switching to LDAP, and forgoing setting up the PAM integration if I can't figure this out. Is there any debugs that I can look at that might provide more detailed information on what is failing here? PAM seems like a black box for me sometimes.

[mattablaze]

Oh I did notice that there is an /etc/pam.d/sshd file which contains the following:

# PAM configuration for the Secure Shell service

# The directives below are common between Deb10/11/12; reference a stock copy of the file for directive descriptions

@include common-auth

account    required     pam_nologin.so

@include common-account

session [success=ok ignore=ignore module_unknown=ignore default=bad]        pam_selinux.so close

session    required     pam_loginuid.so

session    optional     pam_keyinit.so force revoke

@include common-session

session    optional     pam_motd.so  motd=/run/motd.dynamic
session    optional     pam_motd.so noupdate

session    optional     pam_mail.so standard noenv # [1]

session    required     pam_limits.so

session    required     pam_env.so # [1]
session    required     pam_env.so user_readenv=1 envfile=/etc/default/locale

session [success=ok ignore=ignore module_unknown=ignore default=bad]        pam_selinux.so open

@include common-password

[mattablaze]

And with pam debugs enabled in the /etc/pam.d/mavis file, I see these messages. This test user can login to other network devices using an older version of tacacs which uses pam, with no issues, so I don't think it's a real auth (perm denied) problem.

Oct 23 17:46:03 tacacs-stg2-0000 pammavis: pam_sss(mavis:auth): authentication success; logname= uid=0 euid=0 tty= ruser= rhost= user=testuser Oct 23 17:46:03 tacacs-stg2-0000 pammavis: pam_sss(mavis:account): Access denied for user testuser: 6 (Permission denied)

[MarcJHuber]

Hi,

please post the output of

printf "0 TACPLUS\n4 testuser\n49 INFO\n=\n" | /usr/local/sbin/pammavis
printf "0 TACPLUS\n4 testuser\n8 yourtestuserpassword\n49 AUTH\n=\n" | /usr/local/sbin/pammavis

The former will likely succeed (as PAM isn't involved), while the latter might give some insight regarding the authentication failure.

Cheers,

Marc

[mattablaze]

Sure. The username is changed here, but otherwise the log is intact:

>/etc/pam.d# printf "0 TACPLUS\n4 testuser\n49 INFO\n=\n" | /usr/local/sbin/pammavis
0 TACPLUS
4 testuser
49 INFO
9 1474
10 1474
24 1474,503
19 /home/testuser
54 /bin/bash
6 ACK
=0

and

>/etc/pam.d# printf "0 TACPLUS\n4 testuser\n8 <redacted>6\n49 AUTH\n=\n" | /usr/local/sbin/pammavis
0 TACPLUS
4 testuser
8 <correct pass>
49 AUTH
17 Permission denied
6 NAK
=0

[mattablaze]

Hey @MarcJHuber , think we found the problem.

We had an "ldap_access_filter = " setup in nssd.conf that was only sending auth request from specific groups, and my test user wasn't in there. Once we added it, then auth started working. Thank you for pointing me in the right direction, we would have been going around in circles for longer.

[MarcJHuber]

Hi,

thanks for reporting, I was just on the way to suggest trying pamtester for further investigation as the "Permission denied" result originated in pam_chauthtok(), Glad you've resolved the issue!

Looks safe enough to push the "Close with comment" button.

Cheers,

Marc