# TACACS+ login failed



## ipinlnd (Jul 9, 2015)

Hi,
I am using TACACS+ to login into FreeBSD. I have the server on Windows and that is working correctly. I made the client on FreeBSD using pam_tacplus(8) and it authenticates just fine, but it doesn't login. It's like I sent the username and password to the server, and then the server replies that they're correct and FreeBSD gets it, but then it still doesn't login. It says "login incorrect".

My guess is that "login" service is looking somewhere else for login information and it doesn't find the TACACS+ users.

This is my /etc/pam.d/tacacs:

```
auth        sufficient    /usr/local/lib/security/pam_tacplus.so    debug server=10.0.0.9    secret=juanma

account        sufficient    /usr/local/lib/security/pam_tacplus.so    debug server=10.0.0.9    secret=juanma    service=ppp    protocol=lcp
account        sufficient    pam_login_access.so

session        sufficient    /usr/local/lib/security/pam_tacplus.so    debug server=10.0.0.9    secret=juanma    service=ppp    protocol=lcp

password    sufficient    pam_passwdqc.so
password    sufficient    pam_unix.so master use_authtok
```
And this is the /etc/pam.d/login:

```
#
# $FreeBSD: release/9.2.0/etc/pam.d/login 170510 2007-06-10 18:57:20Z yar $
#
# PAM configuration for the     "login" service
#

# auth
auth        sufficient    pam_self.so    no_warn
auth        include        system
auth        include        tacacs

# account
#account        requisite    pam_securetty.so
#account        required    pam_nologin.so
account        include        system
account        include        tacacs

# session
session        include        system
session        include        tacacs

# password
password    include        system
password    include        tacacs
```


----------



## SirDice (Jul 13, 2015)

Try swapping the includes so tacacs is processed first. It's possible the system includes 'short-circuits' the authentication if it cannot find the correct user.


----------



## ipinlnd (Jul 15, 2015)

Thanks for your answer. But that wasn't the problem.

I found out the problem. I should add the user locally. That way, it finds the user locally, and get the password from the server. That's the best I could come up with. But the problem is that it's impossible to know every user on the server. So I have to add the user, after the authentication. So I tried using pam_exec.so to run a script that adds the user locally. But, I haven't been successful so far.


----------



## SirDice (Jul 15, 2015)

Ah, that made me suddenly realize something. It's a similar issue with LDAP authentication. Authentication works but you're still kicked out. And the most likely cause of that is because the user's home directory doesn't exist. I'm not sure if TACACS supplies one (LDAP can), if it doesn't you can probably create one from a common template (/home/$username for example). Have a look at security/pam_mkhomedir.


----------



## ipinlnd (Jul 16, 2015)

Thanks,
I tried using that, but it only works for session; And the problem is that pam doesn't get to session. It's stuck at account. Whatever I do, I need to do it at _auth_. I am using pam_exec(8) right now, and my problem is that I don't know how to get the username the create the user for. I mean, at login, when user enters his/her login information, I need the username to that so that I can create a user for it.


----------



## ipinlnd (Jul 26, 2015)

I have a FreeBSD as my TACACS+ client and the login and telnet works perfectly fine. But iI have a problem with SSH. I can SSH with Cisco router with no problem. But not on the FreeBSD. It doesn't even authenticate. I get "invalid password" from server log.

```
root@alirezaee:~ # ssh -v one@10.0.0.10
OpenSSH_6.2p2, OpenSSL 0.9.8y 5 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to 10.0.0.10 [10.0.0.10] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/id_rsa type 1
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: identity file /root/.ssh/id_ecdsa type -1
debug1: identity file /root/.ssh/id_ecdsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2_hpn13v11 FreeBSD-20130515
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.2_hpn13v11 FreeBSD-20130515
debug1: match: OpenSSH_6.2_hpn13v11 FreeBSD-20130515 pat OpenSSH*
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5-etm@openssh.com none
debug1: kex: client->server aes128-ctr hmac-md5-etm@openssh.com none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA e1:50:42:b0:ad:33:a1:9e:95:78:28:f3:09:22:11:21
debug1: Host '10.0.0.10' is known and matches the ECDSA host key.
debug1: Found key in /root/.ssh/known_hosts:5
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: password,keyboard-interactive
debug1: Next authentication method: keyboard-interactive
Password:
debug1: Authentications that can continue: password,keyboard-interactive
Password:
debug1: Authentications that can continue: password,keyboard-interactive
Password:
debug1: Authentications that can continue: password,keyboard-interactive
debug1: Next authentication method: password
one@10.0.0.10's password:
Connection closed by 10.0.0.10
```


----------



## SirDice (Jul 27, 2015)

Please don't open a new thread about the same issue. 

Threads merged.


----------



## shepherdAZ (Jul 27, 2015)

We recently setup a development network for a new product using FreeBSD, and ran into a similar authentication issue. We used the base system's Heimdal Kerberos to do the authentication, but had forgotten to configure the OpenLDAP connector on some of the servers. Users authenticated fine via Kerberos, but were refused because their user account didn't exist on that local server.

Once you have setup OpenLDAP, on each server run `# pkg install nss_ldap` and `# pkg install pam_ldap`. Then make sure that your configuration in /etc/nsswitch.conf is setup correctly to use "files ldap" for both group and passwd, and that /usr/local/etc/ldap.conf, /usr/local/etc/openldap/ldap.conf, and /usr/local/etc/nss_ldap.conf files have been configured to point to your LDAP server. The PAM config will need to have an "account" line for ldap too.

If you aren't mounting user home directories from an NFS server (or equivalent), then you should still be able to login - albeit using the default shell profiles etc.


----------



## ipinlnd (Jul 31, 2015)

Thanks, but I can't use LDAP. I should do it just with TACACS+.
I found out that ssh encrypts the password and then sends it to the server. Therefore, the server doesn't understand the password and gives me a "invalid password" error. But (I don't really know why) it seems like that if the user is locally defined on the system, ssh doesn't send the encrypted password and sends it in a clear text.
So, I should find a way to add the user (just like with login) before the authentication starts. With login, I changed the login.c code so that it would add the user, but ssh doesn't use that code apparently. So I'm searching trough openssh to find a source code that gets called, when some computer is trying to ssh to this system.


----------

