From xihuang at SonicWALL.com Mon Feb 1 09:15:59 2016 From: xihuang at SonicWALL.com (Justin (Xiaogang) Huang) Date: Mon, 1 Feb 2016 09:15:59 +0000 Subject: [tac_plus] MSCHAP authen fails always Message-ID: <986E29EB40FDF94594C43951F06E607C01311E@us0exc08.us.sonicwall.com> Hi shrubbery, Could you pls help to confirm this? BRs, Justin Huang TEL: 86-21-65100909 ext.42463 From: Justin (Xiaogang) Huang Sent: 2016?1?22? 10:45 To: 'tac_plus at shrubbery.net' Subject: MSCHAP authen fails always Hi, First many thanks for your great open source implementation. I?ve tried this tac_plus server(F4.0.4.28) and succeeded to authen with PAP/CHAP but always failed with MS-CHAP. I dumped some more debug info and found that the NT compatible response was generated wrongly in server. The MD4 password hash is correct. But the DES encryption is not. Here I used the data in RFC2433 B.2 as the reference. Please have a check and keep me informed if you confirm/reject it and/or make it fixed. Thanks. BRs, Justin Huang TEL: 86-21-65100909 ext.42463 -------------- next part -------------- An HTML attachment was scrubbed... URL: From darren.share at chronos.co.uk Mon Feb 1 08:40:55 2016 From: darren.share at chronos.co.uk (Darren Share) Date: Mon, 1 Feb 2016 08:40:55 +0000 Subject: [tac_plus] Need help to authenticate to SSH Message-ID: Hello, I am currently trying to put myself through a crash course with tac_plus to assist a customer. We sell an NTP server which supports TACACS+ for authentication. The server has a web interface (port 80) and and SSH interface (port 22). A relatively default tac_plus installation on a debian server is allowing us to log in to the web interface but the SSH login (with the same user) is getting rejected. According to the manufacturuer the SSH login is not supported with TACACS+ but I'm convinced it should be able to work as I can see the NTP server is sending requests to the TACACS+ server when we attempt to log in. This is the current tac_plus.conf that works with the web login (user "support" is an existing user on the debian system): accounting file = /var/log/tac_plus.acct key = testing123 user = DEFAULT { login = PAM service = ppp protocol = ip {} } group = netadmin { default service = permit login = file /etc/passwd service = exec {} } user = support { member = netadmin } If I enable debugging on tac_plus (tac_plus -C /etc/tacacs+/tac_plus.conf -g -d 256) this is what I get with a successful web login: Reading config Version F4.0.4.19 Initialized 1 tac_plus server F4.0.4.19 starting uid=0 euid=0 gid=0 egid=0 s=4 session request from 172.31.100.88 sock=5 connect from 172.31.100.88 [172.31.100.88] Waiting for packet Read AUTHEN/START size=48 validation request from 172.31.100.88 PACKET: key=testing123 version 192 (0xc0), type 1, seq no 1, flags 0x1 session_id 363537244 (0x15ab235c), Data length 36 (0x24) End header type=AUTHEN/START, priv_lvl = 0 action=login authen_type=ascii service=ppp user_len=7 port_len=7 (0x7), rem_addr_len=7 (0x7) data_len=7 User: support port: unknown rem_addr: unknown data: Supp0rt End packet Authen Start request choose_authen chose default_fn Calling authentication function Writing AUTHEN/GETPASS size=28 PACKET: key=testing123 version 192 (0xc0), type 1, seq no 2, flags 0x1 session_id 363537244 (0x15ab235c), Data length 16 (0x10) End header type=AUTHEN status=5 (AUTHEN/GETPASS) flags=0x1 msg_len=10, data_len=0 msg: Password: data: End packet Waiting for packet Read AUTHEN/CONT size=24 PACKET: key=testing123 version 192 (0xc0), type 1, seq no 3, flags 0x1 session_id 363537244 (0x15ab235c), Data length 12 (0xc) End header type=AUTHEN/CONT user_msg_len 7 (0x7), user_data_len 0 (0x0) flags=0x0 User msg: Supp0rt User data: End packet login query for 'support' unknown from 172.31.100.88 accepted Writing AUTHEN/SUCCEED size=18 PACKET: key=testing123 version 192 (0xc0), type 1, seq no 4, flags 0x1 session_id 363537244 (0x15ab235c), Data length 6 (0x6) End header type=AUTHEN status=1 (AUTHEN/SUCCEED) flags=0x0 msg_len=0, data_len=0 msg: data: End packet 172.31.100.88: disconnect And this is what I get with a failed ssh login: Reading config Version F4.0.4.19 Initialized 1 tac_plus server F4.0.4.19 starting uid=0 euid=0 gid=0 egid=0 s=4 session request from 172.31.100.88 sock=5 connect from 172.31.100.88 [172.31.100.88] Waiting for packet Read AUTHEN/START size=54 validation request from 172.31.100.88 PACKET: key=testing123 version 192 (0xc0), type 1, seq no 1, flags 0x1 session_id 1969877126 (0x7569f086), Data length 42 (0x2a) End header type=AUTHEN/START, priv_lvl = 0 action=login authen_type=ascii service=ppp user_len=7 port_len=3 (0x3), rem_addr_len=11 (0xb) data_len=13 User: support port: ssh rem_addr: 172.31.2.22 data: 0x8 0xa End packet Authen Start request choose_authen chose default_fn Calling authentication function Writing AUTHEN/GETPASS size=28 PACKET: key=testing123 version 192 (0xc0), type 1, seq no 2, flags 0x1 session_id 1969877126 (0x7569f086), Data length 16 (0x10) End header type=AUTHEN status=5 (AUTHEN/GETPASS) flags=0x1 msg_len=10, data_len=0 msg: Password: data: End packet Waiting for packet Read AUTHEN/CONT size=30 PACKET: key=testing123 version 192 (0xc0), type 1, seq no 3, flags 0x1 session_id 1969877126 (0x7569f086), Data length 18 (0x12) End header type=AUTHEN/CONT user_msg_len 13 (0xd), user_data_len 0 (0x0) flags=0x0 User msg: 0x8 0xa User data: End packet login query for 'support' ssh from 172.31.100.88 rejected login failure: support 172.31.100.88 (172.31.100.88) ssh Writing AUTHEN/FAIL size=18 PACKET: key=testing123 version 192 (0xc0), type 1, seq no 4, flags 0x1 session_id 1969877126 (0x7569f086), Data length 6 (0x6) End header type=AUTHEN status=2 (AUTHEN/FAIL) flags=0x0 msg_len=0, data_len=0 msg: data: End packet 172.31.100.88: disconnect The main difference I can see being the "port: unknown" and "port: ssh". I feel like there should be something I can set in tac_plus.conf to enable this. I've tried this with no joy: group = netadmin { default service = permit login = file /etc/passwd service = exec {} service = ppp protocol = ip { port = 22 } } Can anyone offer any suggestions? Many thanks. PS. the TACACS+ config on the NTP server itself is very simple. It's just a field for the IP address of the TACACS+ server and one for the shared secret. Regards, Darren Share ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________ From heas at shrubbery.net Mon Feb 1 17:38:10 2016 From: heas at shrubbery.net (heasley) Date: Mon, 1 Feb 2016 17:38:10 +0000 Subject: [tac_plus] Need help to authenticate to SSH In-Reply-To: References: Message-ID: <20160201173810.GB37256@shrubbery.net> Mon, Feb 01, 2016 at 08:40:55AM +0000, Darren Share: > Hello, > > I am currently trying to put myself through a crash course with tac_plus to assist a customer. We sell an NTP server which supports TACACS+ for authentication. The server has a web interface (port 80) and and SSH interface (port 22). A relatively default tac_plus installation on a debian server is allowing us to log in to the web interface but the SSH login (with the same user) is getting rejected. According to the manufacturuer the SSH login is not supported with TACACS+ but I'm convinced it should be able to work as I can see the NTP server is sending requests to the TACACS+ server when we attempt to log in. > > This is the current tac_plus.conf that works with the web login (user "support" is an existing user on the debian system): > > accounting file = /var/log/tac_plus.acct > key = testing123 > > user = DEFAULT { > login = PAM > service = ppp protocol = ip {} > } > > group = netadmin { > default service = permit > login = file /etc/passwd > service = exec {} > } > > user = support { > member = netadmin > } > > If I enable debugging on tac_plus (tac_plus -C /etc/tacacs+/tac_plus.conf -g -d 256) this is what I get with a successful web login: > please re-send these as attachments; your MUA has trashed the formatting and it is difficult to read. From heas at shrubbery.net Mon Feb 1 17:53:17 2016 From: heas at shrubbery.net (heasley) Date: Mon, 1 Feb 2016 17:53:17 +0000 Subject: [tac_plus] MSCHAP authen fails always In-Reply-To: <986E29EB40FDF94594C43951F06E607C01311E@us0exc08.us.sonicwall.com> References: <986E29EB40FDF94594C43951F06E607C01311E@us0exc08.us.sonicwall.com> Message-ID: <20160201175317.GD37256@shrubbery.net> Mon, Feb 01, 2016 at 09:15:59AM +0000, Justin (Xiaogang) Huang: > Hi shrubbery, > > Could you pls help to confirm this? when i have time. > BRs, > Justin Huang > TEL: 86-21-65100909 ext.42463 > > From: Justin (Xiaogang) Huang > Sent: 2016?1?22? 10:45 > To: 'tac_plus at shrubbery.net' > Subject: MSCHAP authen fails always > > Hi, > > First many thanks for your great open source implementation. > > I?ve tried this tac_plus server(F4.0.4.28) and succeeded to authen with PAP/CHAP but always failed with MS-CHAP. > I dumped some more debug info and found that the NT compatible response was generated wrongly in server. The MD4 password hash is correct. But the DES encryption is not. Here I used the data in RFC2433 B.2 as the reference. > > Please have a check and keep me informed if you confirm/reject it and/or make it fixed. Thanks. > > > BRs, > Justin Huang > TEL: 86-21-65100909 ext.42463 > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > _______________________________________________ > tac_plus mailing list > tac_plus at shrubbery.net > http://www.shrubbery.net/mailman/listinfo/tac_plus From darren.share at chronos.co.uk Mon Feb 1 18:18:54 2016 From: darren.share at chronos.co.uk (Darren Share) Date: Mon, 1 Feb 2016 18:18:54 +0000 Subject: [tac_plus] Need help to authenticate to SSH Message-ID: Hello, I am currently trying to put myself through a crash course with tac_plus to assist a customer. We sell an NTP server which supports TACACS+ for authentication. The server has a web interface (port 80) and and SSH interface (port 22). A relatively default tac_plus installation on a debian server is allowing us to log in to the web interface but the SSH login (with the same user) is getting rejected. According to the manufacturuer the SSH login is not supported with TACACS+ but I'm convinced it should be able to work as I can see the NTP server is sending requests to the TACACS+ server when we attempt to log in. I've attached the current tac_plus.conf that works with the web login (user "support" is an existing user on the debian system). If I enable debugging on tac_plus (tac_plus -C /etc/tacacs+/tac_plus.conf -g -d 256) with a successful web login I get the attached web.txt and with a failed ssh login I get the attached ssh.txt. The main difference I can see being the "port: unknown" and "port: ssh". I feel like there should be something I can set in tac_plus.conf to enable this. I've tried this with no joy: group = netadmin { default service = permit login = file /etc/passwd service = exec {} service = ppp protocol = ip { port = 22 } } Can anyone offer any suggestions? Many thanks. PS. the TACACS+ config on the NTP server itself is very simple. It's just a field for the IP address of the TACACS+ server and one for the shared secret so there's nothing I can change there. Regards, Darren Share ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ssh.txt URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: tac_plus.conf Type: application/octet-stream Size: 268 bytes Desc: not available URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: web.txt URL: From heas at shrubbery.net Mon Feb 1 22:21:07 2016 From: heas at shrubbery.net (heasley) Date: Mon, 1 Feb 2016 22:21:07 +0000 Subject: [tac_plus] Need help to authenticate to SSH In-Reply-To: References: Message-ID: <20160201222107.GI40258@shrubbery.net> Mon, Feb 01, 2016 at 06:18:54PM +0000, Darren Share: > Hello, > > I am currently trying to put myself through a crash course with tac_plus to > assist a customer. We sell an NTP server which supports TACACS+ for > authentication. The server has a web interface (port 80) and and SSH interface > (port 22). A relatively default tac_plus installation on a debian server is > allowing us to log in to the web interface but the SSH login (with the same > user) is getting rejected. According to the manufacturuer the SSH login is not > supported with TACACS+ but I'm convinced it should be able to work as I can see > the NTP server is sending requests to the TACACS+ server when we attempt to log > in. > > I've attached the current tac_plus.conf that works with the web login (user > "support" is an existing user on the debian system). > > If I enable debugging on tac_plus (tac_plus -C /etc/tacacs+/tac_plus.conf -g > -d 256) with a successful web login I get the attached web.txt and with a > failed ssh login I get the attached ssh.txt. > > The main difference I can see being the "port: unknown" and "port: ssh". I feel > like there should be something I can set in tac_plus.conf to enable this. I've > tried this with no joy: still mangled :) but, i'll try. I presume the first is the web login. in the second, the daemon receives "" for the password. I presume this is not the password as it doesnt match the first attachment. So, it appears that what your client is sending is wrong. as for the port; the port is port on a NAS, not the tcp port. I'm not sure that the port is used, except to differentiate sessions, though an external authorization script might use it. > group = netadmin { > default service = permit > login = file /etc/passwd > service = exec {} > service = ppp protocol = ip { > port = 22 > } > } > > Can anyone offer any suggestions? > > Many thanks. > > PS. the TACACS+ config on the NTP server itself is very simple. It's just a > field for the IP address of the TACACS+ server and one for the shared secret so > there's nothing I can change there. > > > Regards, > > Darren Share > > ______________________________________________________________________ > This email has been scanned by the Symantec Email Security.cloud service. > For more information please visit http://www.symanteccloud.com > ______________________________________________________________________ > -------------- next part -------------- > An embedded and charset-unspecified text was scrubbed... > Name: ssh.txt > URL: > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: tac_plus.conf > Type: application/octet-stream > Size: 268 bytes > Desc: not available > URL: > -------------- next part -------------- > An embedded and charset-unspecified text was scrubbed... > Name: web.txt > URL: > _______________________________________________ > tac_plus mailing list > tac_plus at shrubbery.net > http://www.shrubbery.net/mailman/listinfo/tac_plus From vadud3 at gmail.com Wed Feb 24 20:14:29 2016 From: vadud3 at gmail.com (Asif Iqbal) Date: Wed, 24 Feb 2016 15:14:29 -0500 Subject: [tac_plus] tac_plus*** buffer overflow detected *** PROBLEM In-Reply-To: <635483.39828.qm@web110606.mail.gq1.yahoo.com> References: <20101226180620.GB5102@shrubbery.net> <635483.39828.qm@web110606.mail.gq1.yahoo.com> Message-ID: On Sun, Dec 26, 2010 at 2:01 PM, MSamir wrote: > > if i make line shorter it's start with no problem > i try edit tac_plus.h and tacacs.h and change MAX_INPUT_LINE_LEN to be > 2048 demon start with no problem however > I updated MAX_INPUT_LINE_LEN to 2048 just for tac_plus.h and did a make and used that binary and it does buffer overflow anymore. --- a/tac_plus.h +++ b/tac_plus.h @@ -256,7 +256,7 @@ struct acct_reply { #undef MIN #define MIN(a,b) ((a)<(b)?(a):(b)) #define STREQ(a,b) (strcmp(a,b)==0) -#define MAX_INPUT_LINE_LEN 255 +#define MAX_INPUT_LINE_LEN 2048 Do I need to add that for tacacs.h as well? > > > > _______________________________________________ > tac_plus mailing list > tac_plus at shrubbery.net > http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus > -- Asif Iqbal PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? -------------- next part -------------- An HTML attachment was scrubbed... URL: From vadud3 at gmail.com Wed Feb 24 19:53:13 2016 From: vadud3 at gmail.com (Asif Iqbal) Date: Wed, 24 Feb 2016 14:53:13 -0500 Subject: [tac_plus] *** buffer overflow detected ***: /usr/local/sbin/tac_plus terminated Message-ID: # /usr/local/sbin/tac_plus -v tac_plus version F4.0.4.28 ACLS FIONBIO LIBWRAP LINUX LITTLE_ENDIAN LOG_DAEMON PAM NO_PWAGE REAPCHILD RETSIGTYPE RETSIGTYPE SHADOW_PASSWORDS SIGTSTP SIGTTIN SIGTTOU SO_REUSEADDR STRERROR TAC_PLUS_PORT UENABLE __STDC__ I am getting the buffer overflow when the deny-configuration is longer that 235 characters WORKS: deny-configuration = "access|access-profile|accounting-options|applications|apply-groups|bridge-domains|chassis|class-of-service|diameter|dynamic-profiles|event-options|fabric|firewall|forwarding-options|groups|interfaces|jsrc|jsrc-partition|logical-systems" FAILS: deny-configuration = "access|access-profile|accounting-options|applications|apply-groups|bridge-domains|chassis|class-of-service|diameter|dynamic-profiles|event-options|fabric|firewall|forwarding-options|groups|interfaces|jsrc|jsrc-partition|logical-systems1" Any suggestion how to increase the max length allowed? Here is the backtrace group = autoload { service = junos-exec { local-user-name = autoload # class view_config_only allow-commands = "^(request system snapshot|request pfe|file (show|delete)|file checksum md5|commit|configure (private|exclusive))" deny-commands = "^(request|test|file|configure|start shell pfe direct)" allow-configuration = "policy-options|routing-options fate-sharing|load set" deny-configuration = "access|access-profile|accounting-options|applications|apply-groups|bridge-domains|chassis|class-of-service|diameter|dynamic-profiles|event-options|fabric|firewall|forwarding-options|groups|interfaces|jsrc|jsrc-partition|logical-systems1" *** buffer overflow detected ***: /usr/local/sbin/tac_plus terminated ======= Backtrace: ========= /lib/libc.so.6(__fortify_fail+0x37)[0x7fa4d9e16ec7] /lib/libc.so.6(+0x102d80)[0x7fa4d9e15d80] /lib/libc.so.6(+0x101c37)[0x7fa4d9e14c37] /usr/local/sbin/tac_plus[0x406111] /usr/local/sbin/tac_plus[0x40612c] ======= Memory map: ======== 00400000-00418000 r-xp 00000000 fc:13 130465 /usr/local/sbin/tac_plus 00618000-00619000 r--p 00018000 fc:13 130465 /usr/local/sbin/tac_plus 00619000-0061a000 rw-p 00019000 fc:13 130465 /usr/local/sbin/tac_plus 0061a000-0061d000 rw-p 00000000 00:00 0 00d2f000-00d50000 rw-p 00000000 00:00 0 [heap] 7fa4d98f8000-7fa4d990e000 r-xp 00000000 fc:0e 391061 /lib/libgcc_s.so.1 7fa4d990e000-7fa4d9b0d000 ---p 00016000 fc:0e 391061 /lib/libgcc_s.so.1 7fa4d9b0d000-7fa4d9b0e000 r--p 00015000 fc:0e 391061 /lib/libgcc_s.so.1 7fa4d9b0e000-7fa4d9b0f000 rw-p 00016000 fc:0e 391061 /lib/libgcc_s.so.1 7fa4d9b0f000-7fa4d9b11000 r-xp 00000000 fc:0e 420185 /lib/libdl-2.11.1.so 7fa4d9b11000-7fa4d9d11000 ---p 00002000 fc:0e 420185 /lib/libdl-2.11.1.so 7fa4d9d11000-7fa4d9d12000 r--p 00002000 fc:0e 420185 /lib/libdl-2.11.1.so 7fa4d9d12000-7fa4d9d13000 rw-p 00003000 fc:0e 420185 /lib/libdl-2.11.1.so 7fa4d9d13000-7fa4d9e92000 r-xp 00000000 fc:0e 420187 /lib/libc-2.11.1.so 7fa4d9e92000-7fa4da092000 ---p 0017f000 fc:0e 420187 /lib/libc-2.11.1.so 7fa4da092000-7fa4da096000 r--p 0017f000 fc:0e 420187 /lib/libc-2.11.1.so 7fa4da096000-7fa4da097000 rw-p 00183000 fc:0e 420187 /lib/libc-2.11.1.so 7fa4da097000-7fa4da09c000 rw-p 00000000 00:00 0 7fa4da09c000-7fa4da0b4000 r-xp 00000000 fc:0e 420166 /lib/libpthread-2.11.1.so 7fa4da0b4000-7fa4da2b3000 ---p 00018000 fc:0e 420166 /lib/libpthread-2.11.1.so 7fa4da2b3000-7fa4da2b4000 r--p 00017000 fc:0e 420166 /lib/libpthread-2.11.1.so 7fa4da2b4000-7fa4da2b5000 rw-p 00018000 fc:0e 420166 /lib/libpthread-2.11.1.so 7fa4da2b5000-7fa4da2b9000 rw-p 00000000 00:00 0 7fa4da2b9000-7fa4da2c2000 r-xp 00000000 fc:0e 420168 /lib/libcrypt-2.11.1.so 7fa4da2c2000-7fa4da4c2000 ---p 00009000 fc:0e 420168 /lib/libcrypt-2.11.1.so 7fa4da4c2000-7fa4da4c3000 r--p 00009000 fc:0e 420168 /lib/libcrypt-2.11.1.so 7fa4da4c3000-7fa4da4c4000 rw-p 0000a000 fc:0e 420168 /lib/libcrypt-2.11.1.so 7fa4da4c4000-7fa4da4f2000 rw-p 00000000 00:00 0 7fa4da4f2000-7fa4da509000 r-xp 00000000 fc:0e 420167 /lib/libnsl-2.11.1.so 7fa4da509000-7fa4da708000 ---p 00017000 fc:0e 420167 /lib/libnsl-2.11.1.so 7fa4da708000-7fa4da709000 r--p 00016000 fc:0e 420167 /lib/libnsl-2.11.1.so 7fa4da709000-7fa4da70a000 rw-p 00017000 fc:0e 420167 /lib/libnsl-2.11.1.so 7fa4da70a000-7fa4da70c000 rw-p 00000000 00:00 0 7fa4da70c000-7fa4da718000 r-xp 00000000 fc:0e 416207 /lib/libpam.so.0.82.2 7fa4da718000-7fa4da917000 ---p 0000c000 fc:0e 416207 /lib/libpam.so.0.82.2 7fa4da917000-7fa4da918000 r--p 0000b000 fc:0e 416207 /lib/libpam.so.0.82.2 7fa4da918000-7fa4da919000 rw-p 0000c000 fc:0e 416207 /lib/libpam.so.0.82.2 7fa4da919000-7fa4da970000 r-xp 00000000 fc:13 130686 /usr/local/lib/libtacacs.so.1.0.0 7fa4da970000-7fa4dab70000 ---p 00057000 fc:13 130686 /usr/local/lib/libtacacs.so.1.0.0 7fa4dab70000-7fa4dab71000 r--p 00057000 fc:13 130686 /usr/local/lib/libtacacs.so.1.0.0 7fa4dab71000-7fa4dab72000 rw-p 00058000 fc:13 130686 /usr/local/lib/libtacacs.so.1.0.0 7fa4dab72000-7fa4dab7b000 r-xp 00000000 fc:0e 396262 /lib/libwrap.so.0.7.6 7fa4dab7b000-7fa4dad7a000 ---p 00009000 fc:0e 396262 /lib/libwrap.so.0.7.6 7fa4dad7a000-7fa4dad7b000 r--p 00008000 fc:0e 396262 /lib/libwrap.so.0.7.6 7fa4dad7b000-7fa4dad7c000 rw-p 00009000 fc:0e 396262 /lib/libwrap.so.0.7.6 7fa4dad7c000-7fa4dad7d000 rw-p 00000000 00:00 0 7fa4dad7d000-7fa4dad9d000 r-xp 00000000 fc:0e 420163 /lib/ld-2.11.1.so 7fa4daf8e000-7fa4daf93000 rw-p 00000000 00:00 0 7fa4daf99000-7fa4daf9c000 rw-p 00000000 00:00 0 7fa4daf9c000-7fa4daf9d000 r--p 0001f000 fc:0e 420163 /lib/ld-2.11.1.so 7fa4daf9d000-7fa4daf9e000 rw-p 00020000 fc:0e 420163 /lib/ld-2.11.1.so 7fa4daf9e000-7fa4daf9f000 rw-p 00000000 00:00 0 7fff675cd000-7fff675e2000 rw-p 00000000 00:00 0 [stack] 7fff675ff000-7fff67600000 r-xp 00000000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] Aborted -- Asif Iqbal PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kevin.Cruse at Instinet.com Fri Feb 26 17:17:02 2016 From: Kevin.Cruse at Instinet.com (Kevin.Cruse at Instinet.com) Date: Fri, 26 Feb 2016 12:17:02 -0500 Subject: [tac_plus] tacplus timeout values Message-ID: Hi All I am having some issues with our tacacs clients timing out quite frequently. We have hundreds of network devices pointing to 2 tacacs servers and many users complain they are prompted for a password a few times before getting authenticated or their session being terminated. This does not happen constantly all day long but seems rather random. I also notice there are 'tacacs' timeout messages in our logging buffers. I have a suspicion the tacacs server is busy handling requests and users get backed up in a queue and router timeout is reached before daemon can respond. I run the daemon with following command: tac_plus -C /usr/local/sbin/tacplus/tac_plus.cfg -L -p 49 -G Ok - now you are probably asking "why does he run it in foreground?"...well...I cannot prove this but it seems there were some security changes performed on our hosts which prevented me from running it without the -G. I had been running the daemon with this command: tac_plus -C /usr/local/sbin/tacplus/tac_plus.cfg -L -p 49 quite happily for sometime. We then had some maintenance work to test ldap failover and when i restarted the daemon it would not start unless i ran in foreground. i've been working with our admin team to resolve but still cannot figure out why one day it just stopped working ( We run it on centos 7 ). Anyway - im getting away from my original question. I am fielding alot of complaints about these timeouts and hope someone has had similar issues and can provide some direction. Many thanks!!! $ ./tac_plus -v tac_plus version F4.0.4.28 ----------------------------------------------------------------- Kevin Cruse US Networks Instinet LLC 309 West 49th Street New York, NY 10019 US kevin.cruse at instinet.com 212-310-4734 ========================================================================================================= <<<< Disclaimer >>>> This message is intended solely for use by the named addressee(s). If you receive this transmission in error, please immediately notify the sender and destroy this message in its entirety, whether in electronic or hard copy format. Any unauthorized use (and reliance thereon), copying, disclosure, retention, or distribution of this transmission or the material in this transmission is forbidden. We reserve the right to monitor and archive electronic communications. This material does not constitute an offer or solicitation with respect to the purchase or sale of any security. It should not be construed to contain any recommendation regarding any security or strategy. Any views expressed are those of the individual sender, except where the message states otherwise and the sender is authorized to state them to be the views of any such entity. This communication is provided on an ?as is? basis. It contains material that is owned by Instinet Incorporated, its subsidiaries or its or their licensors, and may not, in whole or in part, be (i) copied, photocopied or duplicated in any form, by any means, or (ii) redistributed, posted, published, excerpted, or quoted without Instinet Incorporated's prior written consent. Please access the following link for important information and instructions: http://instinet.com/includes/index.jsp?thePage=/html/le_index.txt Securities products and services are provided by locally registered brokerage subsidiaries of Instinet Incorporated: Instinet Australia Pty Limited (ACN: 131 253 686 AFSL No: 327834), regulated by the Australian Securities & Investments Commission; Instinet Canada Limited, member IIROC/CIPF; Instinet Pacific Limited, authorized and regulated by the Securities and Futures Commission of Hong Kong; Instinet Singapore Services Private Limited, regulated by the Monetary Authority of Singapore, trading member of The Singapore Exchange Securities Trading Private Limited and clearing member of The Central Depository (Pte) Limited; and Instinet, LLC, member SIPC. ========================================================================================================= -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 43650360.gif Type: image/gif Size: 4077 bytes Desc: not available URL: From heas at shrubbery.net Sat Feb 27 16:21:24 2016 From: heas at shrubbery.net (heasley) Date: Sat, 27 Feb 2016 16:21:24 +0000 Subject: [tac_plus] tacplus timeout values In-Reply-To: References: Message-ID: <20160227162124.GH19969@shrubbery.net> Fri, Feb 26, 2016 at 12:17:02PM -0500, Kevin.Cruse at Instinet.com: > I am having some issues with our tacacs clients timing out quite > frequently. We have hundreds of network devices pointing to 2 tacacs > servers and many users complain they are prompted for a password a few > times before getting authenticated or their session being terminated. This Do you mean that their session is terminated *after* successful login? after login and some cli commands? Are you doing tacacas authorization? Are you doing command authorization? Are doing command accounting? What are the devices? Running what o/s? Are there known tacacs/aaa PRs against that combination? When login is successful, is the prompting for the username then password slow? > does not happen constantly all day long but seems rather random. I also > notice there are 'tacacs' timeout messages in our logging buffers. I have a > suspicion the tacacs server is busy handling requests and users get backed > up in a queue and router timeout is reached before daemon can respond. I > run the daemon with following command: > > tac_plus -C /usr/local/sbin/tacplus/tac_plus.cfg -L -p 49 -G > > Ok - now you are probably asking "why does he run it in > foreground?"...well...I cannot prove this but it seems there were some > security changes performed on our hosts which prevented me from running it > without the -G. I had been running the daemon with this command: > > tac_plus -C /usr/local/sbin/tacplus/tac_plus.cfg -L -p 49 > > quite happily for sometime. We then had some maintenance work to test ldap > failover and when i restarted the daemon it would not start unless i ran in > foreground. i've been working with our admin team to resolve but still > cannot figure out why one day it just stopped working ( We run it on centos > 7 ). Anyway - im getting away from my original question. I am fielding alot > of complaints about these timeouts and hope someone has had similar issues > and can provide some direction. Many thanks!!! It should not matter, but are you doing tacacs authentication through PAM to ldap? If so, were debug options or logging of some sort left enabled on the PAM module? The daemon, will fork a new process for each client connection, so one client should not affect another, for the most part. if the connection queue is really long, perhaps it would delay a little. I rather doubt this is the problem. Cisco allows the tacacs timeout to be increased; eg: router(config-server-tacacs)#timeout ? <1-1000> Timeout value in seconds to wait for server to reply > $ ./tac_plus -v > tac_plus version F4.0.4.28