NSS integration for TACACS+

[benschumacher]

Hello-

I've got a module that provides integration into GLIBC's NSS layer for TACACS+ based on the 'libtac' from this project. The module provides a mechanism for operators to rely solely on TACACS+ and PAM functionality to provide shell-level access to end users.

The code is working and is deployed as part of a project I was working on, and I've been working to get clearance to fully open source the code. I could spin up a separate GitHub project for it, but would be just as happy to make this additional functionality a part of this project.

Would that be interesting to to this community? It is currently maintained separately in our local VCS, but I could rework it to use the same build toolchain that is currently used by pam_tacplus, and send a pull request back to this project if that would be interesting.

I'd obviously be happy to provide more details about how it operates, as well.

Thanks, Ben

[daveolson53]

benschumacher notifications@github.com wrote:

I've got a module that provides integration into GLIBC's NSS layer for TACACS+ based on the 'libtac' from this project. The module provides a mechanism for operators to rely solely on TACACS+ and PAM functionality to provide shell-level access to end users.

The code is working and is deployed as part of a project I was working on, and I've been working to get clearance to fully open source the code. I could spin up a separate GitHub project for it, but would be just as happy to make this additional functionality a part of this project.

Would that be interesting to to this community? It is currently maintained separately in our local VCS, but I could rework it to use the same build toolchain that is currently used by pam_tacplus, and send a pull request back to this project if that would be interesting.

I'd be very interested in that. I've been working on the same issue, and have some working code, but not quite complete, because I sidetracked it for another set of projects.

Do you still require a local password entry to supply the UID, homedir, etc., or did you solve that?

Thanks,

Dave Olson olson@cumulusnetworks.com

[benschumacher]

Do you still require a local password entry to supply the UID, homedir, etc., or did you solve that?

No. The NSS layer sends an authorization query to the TACACS+ server and, assuming the user is authorized, it expects to get back AVPs that contain sufficient detail to fill out a passwd entry. Right now it requires these AVP be populated uid, gid, home, shell. I have considered giving it the ability to have defaults in the configuration file, and use those for missing values, but so far that isn't implemented.

Beyond this, it also works best if the system is running with nscd. The implementation only answers getpwnam requests, which works well for authentication/authorization of SSH sessions, but a lot of subsystems need answers to getpwuid to be functional, and this implementation relies upon nscd to fill this gap.

Cheers, Ben

[daveolson53]

benschumacher notifications@github.com wrote:

Do you still require a local password entry to supply the UID, homedir,
etc., or did you solve that?

No. The NSS layer sends an authorization query to the TACACS+ server and, assuming the user is authorized, it expects to get back AVPs that contain sufficient detail to fill out a passwd entry. Right now it requires these AVP be populated uid, gid, home, shell. I have considered giving it the ability to have defaults in the configuration file, and use those for missing values, but so far that isn't implemented.

OK, so it only works with tacacs+ servers that supply those attributes, then? Specifically, it won't work with the linux tacacs+ server, correct?

Do you have a list of tacacs+ servers that supply the attributes?

Beyond this, it also works best if the system is running with nscd. The implementation only answers getpwnam requests, which works well for authentication/authorization of SSH sessions, but a lot of subsystems need answers to getpwuid to be functional, and this implementation relies upon nscd to fill this gap.

But only if somebody have logged in to populate the cache via the getpwnam, right?

Thanks,

Dave Olson olson@cumulusnetworks.com

[benschumacher]

OK, so it only works with tacacs+ servers that supply those attributes, then? Specifically, it won't work with the linux tacacs+ server, correct?

I'm not sure which Linux TACACS+ server you're talking about, but from what I've seen most TACACS+ servers let you add custom AVP.

Do you have a list of tacacs+ servers that supply the attributes?

I have seen it work with Cisco Secure ACS 4.x, 5.x, and the open source "tac_plus" server.

But only if somebody have logged in to populate the cache via the getpwnam, right?

No.

There are plenty of ways to get the cache populated. getent passwd <username> or id <username> both will issue a call through to the getpwnam function. For our application, user's aren't expected to leave traces on the target machines, however, and we were able to tune nscd settings to work appropriately within this context.

[eugenh]

Hi benschumacher ,

I am interested in the NSS code for tacacs that you wrote. Is it publicly available ? Thank you

[aasay]

I am also interested in this if it is publicly available.

Thanks

[daveolson53]

Adam Asay notifications@github.com wrote:

I am also interested in this if it is publicly available.

I've taken up my implementation again, and it's nearly ready. I should have that in shape to share with anybody who wants it by early next week.

I have modified libpam_tacplus a fair amount, partly for my own comfort and ease of debugging. I'll have to undo a lot of that before sending a pull request.

Dave Olson olson@cumulusnetworks.com

[eugenh]

Hi Dave, Any news on your implementation availability ? Thanks

[daveolson53]

eugenh notifications@github.com wrote:

Any news on your implementation availability ?

It's functional with some issues, and not completely cleaned up.

I broke a couple of things in the cleanup I already did. If you want that early version, I'll tar it up. I have a long weekend, so I can do send what I have by the end of today, or with more cleanup next week.

It's got slightly different issues on debian jessie than wheezy, but it works on both.

Dave Olson olson@cumulusnetworks.com

[regevran]

Hello,

I only read roughly your discussion, but I can share what I had to solve, and how I did it and hope it helps.

The problem I faced was this: logging into linux machine when the user exists only on the tacacs server.

The solution was:

• upon connection attempt: create a temporary linux user.
• authenticate the login using pam_tacacs at the remote server.

I didn't changed pam_tacacs, I wrote nss module.

If you want more explanations, code, etc, let me know. It was about a year ago, so I'll need to refresh my memory.

Ran.

On 23 September 2015 at 18:37, daveolson53 notifications@github.com wrote:

eugenh notifications@github.com wrote:

Any news on your implementation availability ?

It's functional with some issues, and not completely cleaned up.

I broke a couple of things in the cleanup I already did. If you want that early version, I'll tar it up. I have a long weekend, so I can do send what I have by the end of today, or with more cleanup next week.

It's got slightly different issues on debian jessie than wheezy, but it works on both.

Dave Olson olson@cumulusnetworks.com

— Reply to this email directly or view it on GitHub https://github.com/jeroennijhof/pam_tacplus/issues/28#issuecomment-142641855 .

[eugenh]

Hi regevran,

The nss module is supposed to solve the problem when connecting with a user that does not exist on local machine, but only on tacacs server. So isn't your nss module doing that ? Could you please share your code if you wrote it under an open source license then ? I will have a look and see how it works. Thanks

[eugenh]

I think the nss module should provide with user information to sshd when it asks for getpwnam for the user trying to connect. if the user doesn't exist in /etc/passwd, getpwnam will fail, but if you configure your nss module into /etc/nsswitch.conf, getpwnam could use your nss module to retrieve user info and reply accordingly to sshd

[regevran]

As far as I remember, openssh sent some hardcoded, invalid password, to pam_tacplus when the user wasn't found in /etc/passwd, regardless of what was configured in the nss.

I didn't want to fix openssh. This is the reason I had to create a temporary user.

Ran.

On 24 September 2015 at 11:00, eugenh notifications@github.com wrote:

I think the nss module should provide with user information to sshd when it asks for getpwnam for the user trying to connect. if the user doesn't exist in /etc/passwd, getpwnam will fail, but if you configure your nss module into /etc/nsswitch.conf, getpwnam could use your nss module to retrieve user info and reply accordingly to sshd

— Reply to this email directly or view it on GitHub https://github.com/jeroennijhof/pam_tacplus/issues/28#issuecomment-142845968 .

[eugenh]

Hi Ran, Yes I did hit the same problem. The idea is that sshd sends INCORRECT as password, if getpwnam fails. Your module should avoid that altogether, if getpwnam will return success, because your module return success if configured in /etc/nsswitch.conf. So sshd isn't checking just /etc/passwd but actually calling getpwnam which calls a compat/db library that reads from /etc/passwd if compat/db is configured in /etc/nsswitch.conf. So we can use this mechanism to make sshd really believe the user exists.

[regevran]

This is what I wasn't able to achieve: I wrote my own nss module, that surly returned success. But whatever I did, it did not convince openssh to accept this user, it kept sending the INCORRECT password.

Ran.

On 24 September 2015 at 11:20, eugenh notifications@github.com wrote:

Hi Ran, Yes I did hit the same problem. The idea is that sshd sends INCORRECT as password, if getpwnam fails. Your module should avoid that altogether, if getpwnam will return success, because your module return success if configured in /etc/nsswitch.conf. So sshd isn't checking just /etc/passwd but actually calling getpwnam which calls a compat/db library that reads from /etc/passwd if compat/db is configured in /etc/nsswitch.conf. So we can use this mechanism to make sshd really believe the user exists.

— Reply to this email directly or view it on GitHub https://github.com/jeroennijhof/pam_tacplus/issues/28#issuecomment-142852763 .

[regevran]

Anyhow my solution is not generic as I saw yours is, so I don't think there is a point sharing it. (unless you insist).

Ran.

On 24 September 2015 at 11:29, Ran Regev regev.ran@gmail.com wrote:

This is what I wasn't able to achieve: I wrote my own nss module, that surly returned success. But whatever I did, it did not convince openssh to accept this user, it kept sending the INCORRECT password.

Ran.

On 24 September 2015 at 11:20, eugenh notifications@github.com wrote:

Hi Ran, Yes I did hit the same problem. The idea is that sshd sends INCORRECT as password, if getpwnam fails. Your module should avoid that altogether, if getpwnam will return success, because your module return success if configured in /etc/nsswitch.conf. So sshd isn't checking just /etc/passwd but actually calling getpwnam which calls a compat/db library that reads from /etc/passwd if compat/db is configured in /etc/nsswitch.conf. So we can use this mechanism to make sshd really believe the user exists.

— Reply to this email directly or view it on GitHub https://github.com/jeroennijhof/pam_tacplus/issues/28#issuecomment-142852763 .

[eugenh]

Hi Ran, So in fact your solution is not a solution since it's not working ? Where and when did you create your temporary user ?

[regevran]

it is WORKING. :-)

It is implemented in our switch.

But now that you are asking the questions, I dig in the code and see that there is more than I thought.

I'll update soon.

Ran.

On 24 September 2015 at 11:40, eugenh notifications@github.com wrote:

Hi Ran, So in fact your solution is not a solution since it's not working ? Where and when did you create your temporary user ?

— Reply to this email directly or view it on GitHub https://github.com/jeroennijhof/pam_tacplus/issues/28#issuecomment-142858312 .

[eugenh]

Well you said you couldn't convince SSHD to accept the user from getpwnam. So I can only assume that somehow you created the user before SSHD gets into action (accepting the new connection). So if you want to add your user in PAM, that's too late already because SSHD calls pam_start pam_authenticate after it checks if the users exists. So my curiosity now is where and when you created the user

[regevran]

I'm so glad you asked, and I'm so glad I'm writing documentation!

Hold your horses, I'm reading what I wrote a year ago, sharing will follow.

Ran.

On 24 September 2015 at 11:50, eugenh notifications@github.com wrote:

Well you said you couldn't convince SSHD to accept the user from getpwnam. So I can only assume that somehow you created the user before SSHD gets into action (accepting the new connection). So if you want to add your user in PAM, that's too late already because SSHD calls pam_start pam_authenticate after it checks if the users exists. So my curiosity now is where and when you created the user

— Reply to this email directly or view it on GitHub https://github.com/jeroennijhof/pam_tacplus/issues/28#issuecomment-142860466 .

[regevran]

Please take a look https://docs.google.com/document/d/1lCgh662XtO9QE7PoEsnz9vtTXK79tIt8QPApVERZ9Lg/pub .

Note that I'm using useradd and sed to complete the task, not sure this is a must, you might want to manually write these parts.

Let me know what do you think.

Ran.

On 24 September 2015 at 11:54, Ran Regev regev.ran@gmail.com wrote:

I'm so glad you asked, and I'm so glad I'm writing documentation!

Hold your horses, I'm reading what I wrote a year ago, sharing will follow.

Ran.

On 24 September 2015 at 11:50, eugenh notifications@github.com wrote:

Well you said you couldn't convince SSHD to accept the user from getpwnam. So I can only assume that somehow you created the user before SSHD gets into action (accepting the new connection). So if you want to add your user in PAM, that's too late already because SSHD calls pam_start pam_authenticate after it checks if the users exists. So my curiosity now is where and when you created the user

— Reply to this email directly or view it on GitHub https://github.com/jeroennijhof/pam_tacplus/issues/28#issuecomment-142860466 .

[eugenh]

Looks good. So you have a nss module that will actually add the user , and pam module that will cleanup after the session has ended ? So you add this module to pam account directive and when sshd will call pam_end you get called with a pam session end and you remove the user ? Also, it looks like your nss module does not really interrogate tacacs+ server for the existence of the user, but assumes the user is valid all the time ?

[regevran]

So you have a nss module that will actually add the user , and pam module that will cleanup after the session has ended ?

Exactly.

So you add this module to pam account directive and when sshd will call pam_end you get called with a pam session end and you remove the user ?

Yes

Also, it looks like your nss module does not really interrogate tacacs+ server for the existence of the user, but assumes the user is valid all the time ?

Not sure I understand the question... If the user is illegal at the server, the pam module returns deny to ssh and everything is fine.

The main problem was to make the regular procedure work once there is no local user on the machine. The nss solved it by creating (randomly selected name/password) a user just before the ssh procedure is taking place. Once the user is added, everything continues as if it was there before, including the situation the user/password pair supplied to tacacs is incorrect.

[eugenh]

"Also, it looks like your nss module does not really interrogate tacacs+ server for the existence of the user, but assumes the user is valid all the time ? Not sure I understand the question... If the user is illegal at the server, the pam modules returns deny to ssh and everything is fine." -->The NSS module was supposed to interrogate tacacs server for the uid, gids, home directory and shell of the user. So basically the NSS would fail if the user does not exist on tacacs server. So that would solve the other problem as well, when tacacs is disabled , either modify /etc/nsswitch.conf to remove your module from there and leave only "files", or the nss_rf would return always failure when tacacs is disabled. Why do you have to add the user to /etc/passwd ? Isn't adding it to /etc/rfpasswd enough ? If the nsswitch will check this file and return success.

[regevran]

The temporary user I create has its own home directory, uid and gid, but they are not important. In our product we have our own shell. The parameters needed to initiate it are retrieved from the tacacs at login time. These parameters have nothing to do with the linux shell.

[eugenh]

I understand that , but in theory, this is what should happen, what I said earlier, that's what the nss does. So actually if the NSS module can make the decision that the user is invalid at NSS check time, it should. It's not appropriate to actually check the user existence at the authentication time. Sure, your solution works and user is denied access, but according to the login scheme, unnecessary steps are being avoided if NSS actually checks the user existence with the tacacs server.

[regevran]

The NSS module was supposed to interrogate tacacs server

I disagree. If the nss checks with the tacacs server, the normal flow is not taking place. The normal flow is nss-->ssh-->pam-->tacacs server. You suggest: nss-->tacacs-->???

but in theory, this is what should happen

I solved a private case that I faced. Did not solved the general problem.

[eugenh]

yes the flow is SSH->NSS->Tacacs->NSS->SSH->PAM->Tacacs->SSH Check this man page for nss_ldap how nss interrogates ldap for user information http://linux.die.net/man/5/nss_ldap

[gthouret]

If individual uid/gid aren't really required there is another solution...

In my implementation of pam_tacplus I use the libnss-ato module so that any pam_tacplus authenticated users get mapped to a single valid local unix account. This works for openssh. I had been trying to use sudo with pam_tacplus for authenticated users to gain root privileges but couldn't get that to work.

[regevran]

ok. I wasn't familiar with libnss-ato up till this moment... In first glance it seems it will do the trick. Since I'm in another project at the moment, and what I did is good enough, I guess I get back to it if and when problem occur.

[eugenh]

Hi gthouret, It looks good, but after the tacacs module authenticated the real user name we want to a common user, how do we separate privileges for pam_acct_mgmt e.g. ? Can we create the user after and somehow change user to this new user such that the shell is started as the proper user (and not the common one ) ? Having them all mapped to a single user means all these virtual users have the same privileges, which I do not want (that's why I'm using tacacs to separate user on a role and privileges basis ).

[gthouret]

No I agree that's a different use case. This solution works for my use case. It's an embedded device so the privilege model is somewhat simplified, it is acceptable to have a single user and single set of privileges. It's just used as a way of enabling SSH access into the shell and generating an accounting record on the tacacs server to record the login.

[benschumacher]

Since I started this thread.... biggest part that has held me back is my lack of skills with autotools. I'll work on getting my version up ASAP. My version conforms w/the description earlier:

The NSS layer sends an authorization query to the TACACS+ server and, assuming the user is authorized, it expects to get back AVPs that contain sufficient detail to fill out a passwd entry. Right now it requires these AVP be populated uid, gid, home, shell. I have considered giving it the ability to have defaults in the configuration file, and use those for missing values, but so far that isn't implemented.

Hopefully within the week.

[joakim-tjernlund]

I am interested in this too. Don't have time ATM to look into what you have done but I will

[webbk]

Hi - I am yet another one who would be interested in this. I would be interested in looking at it, whether it was building or not. -Thanks.

[daveolson53]

webbk notifications@github.com wrote:

I am yet another one who would be interested in this. I would be interested in looking at it, whether it was building or not. -Thanks.

What I have isn't quite the same as what has been getting discussed in the thread.

I now have something that is fully functioning, but not cleaned up in terms of minimizing diffs against the upstream pam_tacplus repo.

I can send that out to anybody who wants it. The compressed tarball of everything (adding a mapping library to libpam_tacplus, NSS library, auditing library, and sudo patch), is about 1.3 MB.

Here's the writeup (not yet reviewed by anybody, so may have issues). I'm demo'ing this to some folks later this week, so may have some cleanups after that.

The binary tarball is something I can strip down to just the config files and attach as well; the writeup below assumes it's binary + config files.

I've done all my testing on debian wheezy, with a bit on debian jesse,.

The tacacs+ server needs no special configuration or attributes added, the only requirement is that account lookup also returns the privilege attribute. What I've done should work with any tacacs+ server, free or commercial, but testing with anything other than the debian tacacs+ packaged server has not yet been done (it should happen fairly soon).

The full planned TACACS+ implementation is now functioning, with no hacks.

It's running against a tacacs+ (linux opensource) server running on VM "tacastest" in MV

That is, given a tacacs server with accounts set up, and a few configuration changes on tacacs client, any TACACS+ user can login via console or ssh, sudo, etc., without a local account. Accounting records (start and stop) are sent to the TACACS+ server for each exec system call done through that login (or non-interactive ssh) session.

The only TACACS+ feature not implemented is pre-command authorization (it is not currently planned) . Normal linux permissions/rules apply.

ls -l, ps, who, etc. all show the name of the TACACS+ user (in normal cases).

This is all done through a new tacacs mapping library used with pam, nss, and sudo.

The essential configuration on the client (aside from installing new packages) are modifications to the pam.d files, /etc/nsswitch.conf, sudoers.d/tacplus, and adding at least one tacacs account to the local password file (tacacs0). Normally there will be at least two, tacacs0 and tacacs15.

The TACACS+ server supplies privilege level for the account, and that level (0-15) is used to map the loginname (e.g., olsontac) to the local tacacs account(s). For privilege level 15, the mapping is to tacacs15, and if that isn't found, then tacacs14, etc. on down to tacacs0, until the first <= privilege mapping is found.

The mapping information is maintained in the binary file /run/tacacs_client_map, created at login, and cleaned up at logout.

At the moment, I don't have debian packages for any of these, although packaging is being worked on. All the work is based on libpam_tacplus sources (v1.3.9) from git.

The binary install tarball (on the monsters) ~olson/tac-backup/tacplus-allworks-2015-10-15.tgz can be extracted in / on the client, and then ./setup-tacacs-client run. The config files are still setup to use my VM (host tacastest) as the TACACS+ server, and that's where all the logging including accounting goes.

That setup file will be needed after installing from debs also for the tacacs accounts, changing nsswitch.conf, and the audit.rules file (all normally done by admin manually, although I'll probably do some of it at install time; still have to figure that out).

The /etc/pam.d files in the tarball above will also be needed. The mechanism used by pam_auth-update wouldn't work for me, at least on wheezy, because of where I need to insert new libs. I'll check it out again on jessie, but I expect the same.

The pam files in the tarball all assume the customer hasn't customized anything.

Basically, the mapping of tacacs user (e.g. "olsontac") to a local user (e.g. "tacacs15") means that tacacs15 is in the local password file, but the password there isn't used, and you can do things like "ps -fu olsontac" and get the right results, and as user olsontac, you can do "sudo id", etc., with user tacacs15 in sudoers or (as I have it set up) in /etc/sudoers.d/tacplus, allows the tacacs user accounts to "just work".

sudo is mostly stock on host tacastest, so you won't be able to sudo for most accounts except the tacacs priv=15 accounts. If you want to see logs, etc., you'll need to su to root. The root password is: "Iam4users".

tacacs accounting is done to /var/log/tac_plus.acct using the default tacacs+ server config, and regular tacacs server logging goes to whichever files syslog is configured to use.

Accounting records work for any tacacs login and anything that user runs after through su, sudo, etc., because it uses the audit userid (similar to pam_loginuid), and session (/proc/PID/sessionid), which remain constant, unless the user logs in again. On debian wheezy, once root, you can alter that, because you can re-set the sessionid and auid, but on jessie, you can't, if configured correctly.

There are some weirdnesses, as when two different tacacs users with the same privilege level login. Lookups based on name will work correctly, but lookups based on UID will return the loginname of the first of the tacacs users to login at that privilege level. So if olsontac logs in, then olsont, and they are mapped

to UID 1002, then ls -l, ps -el, etc. will show any UID 1002 as "olsont".

Dave Olson olson@cumulusnetworks.com

[liorl]

Hi Dave,

I am interstinging in your code , can you please send me instructions how to download it ?
my email is; levinskylior@gmail.com

Regards, Levinsky Lior

[daveolson53]

Lior Levinsky notifications@github.com wrote:

Hi Dave,

I am interstinging in your code , can you please send me instructions how to download it ?

my email is; levinskylior@gmail.com

I've note put them in any upstream repository yet, because I keep finding new things to clean up. I'll send you a tarball under separate email.

I should have something upstream this week.

Dave Olson olson@cumulusnetworks.com

[liorl]

Thanks בתאריך 23 בנוב 2015 18:47,‏ "daveolson53" notifications@github.com כתב:

Lior Levinsky notifications@github.com wrote:

Hi Dave,

I am interstinging in your code , can you please send me instructions how to download it ?

my email is; levinskylior@gmail.com

I've note put them in any upstream repository yet, because I keep finding new things to clean up. I'll send you a tarball under separate email.

I should have something upstream this week.

Dave Olson olson@cumulusnetworks.com

— Reply to this email directly or view it on GitHub https://github.com/jeroennijhof/pam_tacplus/issues/28#issuecomment-158992427 .

[joakim-tjernlund]

daveolson53, I am about to start my own adventure in this area for our embedded devcie. Could you commit what you have somewhere?

benschumacher, I think you had done work in this area too? Is it available somewhere?

[daveolson53]

joakim-tjernlund notifications@github.com wrote:

daveolson53, I am about to start my own adventure in this area for our embedded devcie. Could you commit what you have somewhere?

I'm back in the middle of another project at work. I'll forward you the tarballs for debian, and the notes that go with it; should be buildable on other linux variants, just needs some hand-effort for the things that postinst rules handle.

Basicly, everything works for me, but with minimal testing.

Dave Olson olson@cumulusnetworks.com

[daveolson53]

Dave Olson olson@cumulusnetworks.com wrote:

joakim-tjernlund notifications@github.com wrote:

daveolson53, I am about to start my own adventure in this area for our embedded devcie. Could you commit what you have somewhere?

I'm back in the middle of another project at work. I'll forward you the tarballs for debian, and the notes that go with it; should be buildable on other linux variants, just needs some hand-effort for the things that postinst rules handle.

Basicly, everything works for me, but with minimal testing.

That is, I'll send it to you directly, if you'll send me your email address. The full compressed tarball is about 3.8MB.

I'll make an effort to get this all up on github in the next week or so.

Dave Olson olson@cumulusnetworks.com

[benschumacher]

All-

I'm obviously terrible at getting things done on this front, but thanks to another recent contact by @joakim-tjernlund, I have uploaded the code I wrote to GitHub. You can find it here:

https://github.com/benschumacher/nss_tacplus

I'm trying to adopt a "the perfect is the enemy of the good" mindset.

It's clearly not where I'd prefer it to be pre-sharing w.r.t. documentation, integration w/pam_tacplus codebase, etc., but at least it's available for others to look at. I'm terrible w/autotools (and I've moved onto another team in my day job), which is why I haven't made much progress in getting this in better shape.

Hope this helps others get started. I'll get a README up ASAP, too.

[eugenh]

Hi Ben,

Thank you for your post. I will have a look. I know it took you long enough and thank you for getting the time to share this. While you were away I started my own libnss_tac but without actually communicating with tacacs server. I just made it that returns users exists on all occasions. Truth is the idea didn't work so well as now I cannot actually create any users since they all exist already and other issues. I kinda abandoned the work as I have been caught in other stuff but I hope at some point will get back to it and also look on your implementation. Thanks again

[azharfazil]

Hi Dave,

Can you share it with me as well.

thanks.

[daveolson53]

azharfazil notifications@github.com wrote:

Hi Dave,

Can you share it with me as well.

Sure. Send me your email address (at the address below), and I'll send it to you.

Dave Olson olson@cumulusnetworks.com

[azharfazil]

Hi Guys,

Just to confirm. For this logic above to work , the tacacs+ server need to allow authorization request without valid authentication? Especially in ssh case , where if the authorization failed (from the nss) it will send a bad password in the authentication request (INCORRECT as password).

Azhar

[oferbochan]

Hi Dave,

can you please share it with me Also,

Thanks Ofer

Ofer.bochan@gmail.com

[daveolson53]

oferbochan notifications@github.com wrote:

can you please share it with me Also,

I have everything cleaned up and ready to go as of earlier today, to the point where I can test it again.

I need to do some more testing, and I should have it all on github by Friday. I'm sure there will be lots of questions about it once I push it. I'll let people know when it's pushed and ready for people to clone and look at.

As it stands, everything compiles cleanly and generates debian packages that install and "work" on jessie. I've done no work with other distributions, but earlier versions of the code were compiled and tested on centos, with some success. Only tested for amd64 so far, but armel will get tested soon (not by Friday).

There are 8 runtime packages, and 4 dev packages:

audisp-tacplus_1.0.0-1_amd64.deb libtac2_1.4.0-2_amd64.deb libnss-tacplus_1.0.1-1_amd64.deb libtac2-bin_1.4.0-2_amd64.deb libpam-tacplus_1.4.0-2_amd64.deb libtacplus-map1_1.0.0-1_amd64.deb libsimple-tacacct1_1.0.0-1_amd64.deb sudo_1.8.10p3-cl3u1_amd64.deb

libpam-tacplus-dev_1.4.0-2_amd64.deb libtac-dev_1.4.0-2_amd64.deb libsimple-tacacct-dev_1.0.0-1_amd64.deb libtacplus-map-dev_1.0.0-1_amd64.deb

I haven't done a meta-package yet for the runtime, although I likely will do that.

Sorry for the long delays; changes in priorities had me working on other things for quite a while.

Here is the (early) documentation:

TACACS+ functionality and mechanisms for non-local TACACS use

Authentication (login, su, sudo, ssh, etc) and command accounting are implemented. Command accounting is done at start and stop and is done at the exec() system call family. Within a single command that does not run other commands (for example changes to configurations in an editor, or actions with clagctl, vtysh, etc.), no additional accounting is done at this time.

Command authorization is not implemented, except at the most basic level. By default, tacacs privilege level 15 users are allowed to run any command via sudo (and the commands will generate accounting records). TACACS+ users at other privilege levels are not allowed to run sudo, and are limited to commands that can be run with their normal linux permissions.

It is not necessary to add TACACS+ users to the local password file, and it is recommended that you do not do so. A new library is provided to map TACACS+ users by privilege leve onto predefined tacacs0...tacacs15 users in the local password file, and back from those local users onto the TACACS users.

Implementing TACACS+ clients requires the following 8 packages:

audisp-tacplus_1.0.0-1_amd64.deb      libtac2_1.3.9-1_amd64.deb
libnss-tacplus_1.0.1-1_amd64.deb      libtac2-bin_1.3.9-1_amd64.deb
libpam-tacplus_1.3.9-1_amd64.deb      libtacplus-map1_1.0.0-1_amd64.deb
libsimple-tacacct1_1.0.0-1_amd64.deb  sudo_1.8.10p3-cl3u1_amd64.deb

libpam-tacplus is an extensively modified version of a standard debian package. sudo is a slightly modified version of the standard debian package, with modifications to be able to lookup TACACS+ authenticated users, and use their TACAC password.

libtac2 was separated out of libpam, and provides the basic tacacs server utility and communication routines. libtac2-bin provides a simple program called "tacc" to test those routines (as well as a manpage).

libtacplus-map1 provides the mapping functionality between local tacacs0...tacacs15 users and the actual TACACS+ usernames from the TACACS+ server. This library also sets the immutable sessionid and auditing uid, so that the original user can be tracked through multiple processes, and through privilege changes through suo, sudo, etc., so that accounting records are correct. It also sets the auditing loginuid to be immutable, if supported by the kernel. It creates and maintains a status database in /run/tacacs_client_map to manage and lookup the mappings.

libnss-tacplus provides an interface between libc username lookups to the mapping functions, and then to the TACACS+ server

libsimple-tacacct1 provides a simple interfaces for programs to communicate to the TACACS+ server to send accounting records. It is used by audisp-tacplus

audisp-tacplus provides an audisp plugin to the auditd accounting system, and is used to provide the TACACS+ accounting. It is not normally necessary to make changes to the two configuration files (see Configuration in the Appendix).

TACACS+ Authentication

Initial authentication is via PAM modules, and an updated version of the libpam-tacplus package. The PAM configuration in /etc/pam.d is updated via pam-auth-update when this package is installed.

TACACS+ Accounting

A audisp module has is used to do TACACS+ accounting, using a plugin to auditd/audisp. It uses the libtacplus_map.so library interfaces that are part of my modified lipam_tacplus package. It also requires libnss_tacplus.

It works with a modified version of pam_tacplus and the libnss_tacplus library, that allows tacacs users to login without a specific account in the password file, and mapping to to tacacs0...tacacs15 local users.

The plugin maps the auid in the accounting record to a tacacs loginname, based on the auid and sessionid.

It makes a new connection to the TACACS+ server each time, because libtac is single threaded. libtac doesn't support multiple connects at the same time due to use of globals, and it doesn't have support for persistent connections at this time.

Minimal auditd and audisp configuration is done to to enable the audit records necessary for accounting (and they are installed as part of this package).

A maximum of 240 bytes of command name and command arguments will be sent in the accounting record, due to the 255 byte tacacs+ field length limitation. Communication with the TACACS+ servers is done via the ibsimple-tacacct1 library, via dlopen(). The only configuration required is the IP address of the server and it's encryption key (found in /etc/tacplus_servers).

There are two configuration files, one for the audisp plugin (normally /etc/audisp/plugins.d/audisp-tacplus.conf), and one for the tacacs+ server configuration (normally /etc/audisp/audisp-tac_plus.conf; a different file can be configured in audisp-tacplus.conf).

Additionally, there is an auditctl rules file, (normally /etc/audisp/plugins.d/audisp-tacplus.rules) loaded when auditd starts. The rules are generated at package install using augenrules

The configuration files are described in the appendix

See the audisp.8 and auditd.8 man pages for more information.

NSS plugin

The tacplus_nss package supplies an NSS plugin that allows a TACACS+ authenticated user to login without any local account on the system, when used with pam_tacplus. It provides is the getpwnam() entry point, and uses the TACACS+ authenticate and accounting functions. It uses the mapped tacplus information if the user is not found in the local password file.

Normal use is to have tacplus as the last lookup method for "passwd" in /etc/nsswitch.conf, although it will work in any position. nsswitch.conf is modified to make this change when the libnss_tacplus package is installed.

The plugin asks the TACACS+ server if the user is known, and then asks for attributes, so it can determine the user's privilege level. It makes a new connection to the TACACS+ server each time.

If the username is not found, a mapped lookup is performed using the libtacplus_map.so exported functions. The lookup is done by appending the privilege level to "tacacs", and looking that name up in the local password file; that is, privilege level 15 looks for local user "tacacs15". If found, the password structure is filled in with the information for that user, except that pw_name is filled in with the original (login) name. If not found, the privilege level is decremented and checked again, until tacacs0 is reached. This allows setting up, e.g. only tacacs0 and tacacs15 in the passwd file if desired.

Limitations

If two or more TACACS+ users (say, olsont and george) are logged in at the same time at the same privilege level, everything works, and accounting records are maintained correctly. However, since local to the switch, both users are mapped to the same user (e.g., tacacs15), a name lookup against the uid of tacacs15 can only return one of the two users (olsont and george). The current algorithm is to return the first name matching the uid from the mapping file. This could be the first or the second user that logged in.

Thus, a command such as "ps -u george" will return processes belong to both george and olsont, and 'ls -lt' on files created by either george or olsont will return the same name. So if the match of the tacacs15 uid returns "george", then after george creates the file /tmp/me and olsont creates the file /tmp/you, the command "ls -l /tmp/me /tmp/you", will show both files with george as the owner.

This is an inherent limitation of using the uid for the base user from the password file.

The auditting information can be used to determine which processes and files were created by which user, either by looking at the audit log on the switch, or the TACACS server accounting logs.

Appendix: Troubleshooting

To check if everything is setup correctly to reach the TACACS+ server, local password in configuration files, the getent command can be useful. For example (here "olsont" is a TACACS user, cumulus is a local password file user):

getent passwd olsont # lookup username through all NSS methods

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

getent -s compat passwd olson # lookup user only in local databases

(returns nothing)

getent -s compat passwd cumulus

cumulus:x:1000:1000:cumulus,,,:/home/cumulus:/bin/bash

getent -s tacplus passwd olsont # lookup user only for TACACS+

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

getent -s tacplus passwd cumulus # lookup user only for TACACS+

(returns nothing)

If things do not seem to be working one of the first things to try is to add debugging in /etc/tacplus_servers and in /etc/tacplus_nss.conf (debug=1). The logging will normally be put into /var/log/syslog. It can also be added to individual pam_tacplus lines in pam.d/common*

Appendix: Configuration

The file /etc/tacplus_servers is the only file that needs to modified after installation. At a minimum, the IP address of the TACACS+ server and the shared encryption key need to be in this file.

/etc/nsswitch.conf is modified to enable tacplus lookups via libnss_tacplus when the libnss_tacplus package is installed. If you overwrite it, you'll have to make the change to add "tacplus" to the "passwd" line.

/etc/tacplus_nss.conf sets the basic paramaters for libnss_tacplus. It has a debug variable to allow debugging NSS lookups.

Most of the /etc/pam.d/common-* files are updated to add lines for the tacplus authentication. They are update via pam-auth-update when libpam-tacplus is installed. You can further edit these lines, but be aware that if pam-auth-update is run again after changes are made, the update will fail. Normally the file /usr/share/pam-configs/tacplus should be editted instead, and afterwards pam-auth-update run again.

Auditing configuration file variables and syntax

Recognized options in the configuration file are the same as the command line arguments for libpam_tacplus, but not all pam_tacplus options are supported.

Option Management group Description

---

debug ALL output debugging information via syslog(3); note, that the debugging is heavy, including passwords!

secret=STRING ALL can be specified more than once; secret key used to encrypt/decrypt packets sent/received from the server

server=HOSTNAME auth, session can be specified more than once; server=IP_ADDR adds a TACACS+ server to the servers list default is 5 seconds

login=STRING auth TACACS+ authentication service, this can be "pap", "chap" or "login" at the moment. Default is pap.

acct_all session if multiple servers are supplied, audisp_tacplus will send accounting start/stop packets to all servers on the list, otherwise only to the first responding server.

service account, session TACACS+ service for accounting

protocol account, session TACACS+ protocol for accounting

Dave Olson olson@cumulusnetworks.com

[oferbochan]

Thank you,

could you please advise where i can download this packages ?

Ofer On 29 Jun 2016, at 9:39 AM, daveolson53 notifications@github.com<mailto:notifications@github.com> wrote:

audisp-tacplus_1.0.0-1_amd64.deb