Both TAC_PLUS_AUTHOR_STATUS_PASS_ADD TAC_PLUS_AUTHOR_STATUS_PASS_REPL are valid passed authorisation responses.

Hi there,

While testing this library with a TACACS+ server (tacacs+ package from Debian's APT repository), I encountered a problem with connection reuse.

The following snippet will raise socket.error from the authorize method:

import tacacs_plus.client, tacacs_plus.flags

c = tacacs_plus.client.TACACSClient('tacacs', 49, 'testing123')
c.authenticate('test', 'toto', authen_type=tacacs_plus.flags.TAC_PLUS_AUTHEN_TYPE_PAP)
c.authorize('test', authen_type=tacacs_plus.flags.TAC_PLUS_AUTHEN_TYPE_PAP)

It's not mandatory to specify authen_type in the c.authorize statement.

Traceback (most recent call last):
  File "example.py", line 5, in <module>
    c.authorize('test', authen_type=tacacs_plus.flags.TAC_PLUS_AUTHEN_TYPE_PAP)
  File ".../venv2/local/lib/python2.7/site-packages/tacacs_plus/client.py", line 242, in authorize
    TAC_PLUS_AUTHOR
  File ".../venv2/local/lib/python2.7/site-packages/tacacs_plus/client.py", line 136, in send
    raise socket.error

The problem goes away if I recreate a client.

Based on IETF's draft, it seems that the minor version may change for some commands if their implementation has changed between the two minor version.

Looking at the code, the comparison fail on the version check: resp_header.version is 0xc0 and header.version is 0xc1. Could the version check be relaxed to only verify the major component?

For the record, the test user is defined as follow in the tac_plus.conf configuration file:

user = test  {
  login = cleartext "toto"
  pap = cleartext "toto"
  service = exec {
    priv-lvl = 15
  }
}

Regards.

I think what is missing now is a more structured documentation, especially as inline, with sphinx autogeneration and automatic push to readthedocs.

@ryanpetrello do you guys have an account on readthedocs? The sphinx generation part is quite easy to implement thou..

Regarding the inline documentation, here is the status:

tacacs_plus/flags.py - not documented
tacacs_plus/accounting.py - not documented
tacacs_plus/authentication.py - not documented
tacacs_plus/authorization.py - not documented
tacacs_plus/client.py - documented
tacacs_plus/flags.py - not documented
tacacs_plus/packet.py - not documented

Thoughts?

As opposed to authentication.

Is this a mistake or should the docstring be updated to reflect it?
This may be a corner case because the application should surely authenticate before authorizing.

Example:

from __future__ import print_function
import tacacs_plus.client

c = tacacs_plus.client.TACACSClient('tacacs', 49, 'invalid_secret')
print(c.authenticate('test', 'bla').valid) # False
print(c.authorize('test').valid) # raise

Will result in:

Traceback (most recent call last):
  File "example.py", line 6, in <module>
    print(c.authorize('test').valid)
  File ".../tacacs_plus/client.py", line 246, in authorize
    reply = TACACSAuthorizationReply.unpacked(packet.body)
  File ".../tacacs_plus/authorization.py", line 130, in unpacked
    ) if arg_cnt else []
struct.error: unpack requires a bytes object of length 139

Regards.

Hi there,

This isn't a major issue as user code may work around it but it may be nice to look into it (because this library seems to be the only serious one available for the TACACS+ protocol) and a compatible API between different Python versions may be a nice thing to have (maybe it was simply overlooked because the code makes heavy use of six).

I think there is a small inconsistency with the handling of strings between Python 2 & 3, a simple and idiomatic user code that could be executed under both major versions would be something like:

from __future__ import print_function, unicode_literals
import tacacs_plus.client

c = tacacs_plus.client.TACACSClient('tacacs', 49, 'testing123')
print(c.authenticate('test', 'toto').valid)

This would work in Python 3 but would fails in Python 2 (in multiple places) due to unicode_literals as the library is expecting str and not unicode strings.

Regards.

@ryanpetrello do you think we can release version 2.1 on pipy?

I am using tacacs_plus-2.6 and Python 2.7.5 and get above handlers error when running:
python tacacs_client -u TACACS-ADTestUser1 -H -k -v authenticate -p

If I add the following to def main():
logging.basicConfig(level=logging.INFO)
logging.info('Started')
logging.info('Finished')

I get error regarding timed out

INFO:root:Started
INFO:root:Finished
ERROR:main:error: timed out
Traceback (most recent call last):
File "tacacs_client", line 170, in main
sys.exit(authenticate(cli, args))
File "tacacs_client", line 119, in authenticate
port=args.virtual_port)
File "/usr/lib/python2.7/site-packages/tacacs_plus/client.py", line 199, in authenticate
with self.closing():
File "/usr/lib64/python2.7/contextlib.py", line 17, in enter
return self.gen.next()
File "/usr/lib/python2.7/site-packages/tacacs_plus/client.py", line 81, in closing
self.sock
File "/usr/lib/python2.7/site-packages/tacacs_plus/client.py", line 75, in sock
self._sock.connect(conn)
File "/usr/lib64/python2.7/socket.py", line 224, in meth
return getattr(self._sock,name)(*args)
timeout: timed out

The bug is in code the I contributed.
reply_arguments['priv_lvl'] represents the specific user privilege level. This value should be higher than the value specified as an argument of authorize method. However, the code does the opposite:
if int(reply_arguments.get('priv_lvl', 0)) > priv_lvl: reply.status = TAC_PLUS_AUTHOR_STATUS_FAIL
It should be
if int(reply_arguments.get('priv_lvl', 0)) <= priv_lvl: reply.status = TAC_PLUS_AUTHOR_STATUS_FAIL
The default value of priv_lvl should be TAC_PLUS_PRIV_LVL_MAX (i.e 15)

Hi team, I am not sure if this suggestion could be written in the issue section.

I'm using your package in a python application for authenticate and authorizate users against AAA servers in order to give them access to specific network application as the defined profile for the user in the AAA servers (as a requirement of the company I must use their AAA servers). Following the idea, I finished the application and is in production now (by the way, works great the package), but for retrieving the permissions of the user from the authorize method of the TACACSClient class, I was forced to read the response as string and parse it to dictionary.

I was wondering if could be added like a machine_status method to the TACACSAuthorizationReply class (instance returned by the authorize method of the TACACSClient class), for covering the use of case described above.

Testing the case:

cli = TACACSClient('host', 49, 'secret', timeout=10, family=socket.AF_INET)
authen = cli.authenticate('username', 'password')
author = cli.authorize(username)
print(author.__str__())

string method of the TACACSAuthorizationReply:

Hi there,

The programmatic usage example in the README is not valid for IOS / IOS-XE devices.

The example for command authorization ([b"service=shell", b"cmd=show", b"cmdargs=version"]) is using the key cmdargs.
However, Cisco Devices use the key cmd-arg for command authorization.

So the correct example would be: [b"service=shell", b"cmd=show", b"cmd-arg=version"]

Furthermore an example for a command with more than two words would be helpful.
Example: show interfaces Vlan 20 summary

=> [b"service=shell", b"cmd=show", b"cmd-arg=interfaces", b"cmd-arg=vlan", b"cmd-arg=20", b"cmd-arg=summary"]

authen_type here is not a positional argument, so argument key should be specified.

I've been having a number of issues with the PAP and CHAP authentication methods since 2.0. I can authenticate just fine with a simple client.authenticate('username', 'password'), but then when I try to do the same with PAP (e.g. client.authenticate('username', 'password', authen_type=TAC_PLUS_AUTHEN_TYPE_PAP) ) it fails. In the same session, I then try to re-authenticate using the default ascii method with client.authenticate('username', 'password') and am returned "choose_authen: unacceptable authen method".

Hi, Not sure if this is the question related to your package or simply related to UNIX(ubuntu) administration? any advice is deeply appreciated

Pypi.org package for version 2.6 do not contain LICENSE file. Is it on purpose? If not then maybe it could be added.

https://pypi.org/project/tacacs_plus/

I installed it on ubuntu and the when I connect to the server the server validates the request. However I am confused if that is all it can do ? Is this like tac test to test if our server is authentication the credentials ? How can I integrate this with my linux in a way that if I take the ssh of some remote device I can fetch the credentials from AAA server. Thank you

Hello,
I have worked on a patch to implement the accounting part of TAC+ protocol and I would like to submit the PR. So far I have implemented only the Start part of accounting and tested against Shrubbery TAC+. I am planning to work also on Continue and Stop.

I have some questions for you:

1. Code structure: the code is in a big single file, making the development and testing quite complex. Is there a reason for it? The first PR I would like to submit would be to split the project and the tests into a modular fashion like:

tac_plus/__init__.py - version and global constanst
tac_plus/flags.py - all the protocol flags
tac_plus/packet.py - packet object and helpers
tac_plus/authentication.py - authentication object and helpers
tac_plus/authorisation.py - authorisation object and helpers
tac_plus/accounting.py - accounting object and helpers
tac_plus/aaa.py - send and receive methods, using object from above files
tests/test_tac_plus.py - tests, to be compliant with pytest and usable with python setup.py test

2. Accounting patch: after the code is more structured, I would like to post a PR for the accounting part, to avoid a too big PR where we can miss things.

Thoughts?

I tested tacacs_client authenticate method with option '-t chap' and got error with "chap_ppp_id must be a string".
I seems like a problem in bin/tacacs_client line 109&110.
With following fix, it works for me:
args.authen_type == 'chap'
-->
args.authen_type == TAC_PLUS_AUTHEN_TYPES['chap']

I have some time on my hands and I would like to refresh a little the package, address some of the issues in the queue and merge the amazing async work done by @nekonekun in #50 but I am don't remember the release process 🤦🏼 @ryanpetrello I could use some help about how to release a new version of on pypi..