From aaron.wasserott at viawest.com Thu Mar 6 23:05:23 2014 From: aaron.wasserott at viawest.com (Aaron Wasserott) Date: Thu, 6 Mar 2014 23:05:23 +0000 Subject: [tac_plus] Create TACACS server hierarchy? Message-ID: <1FD1A2FED7E41F4ABD1D2E2BDDEA519B08447C@mbx030-w1-co-6.exch030.domain.local> Is there a way to create a TACACS server hierarchy? For example, point a network device at tacacs server B, if the user does not exist there, then forward request to tacacs server A to complete? Ideally with server B handling all of the communication, such that a network device only needs to be configured for server B for AAA. This is for a lab situation, where I would like people who don't normally have network device access to be able to manage their own devices. I would point all my lab network devices to a lab tacacs server, and if they were not granted additional permissions in the lab, it would fail-back to the level of auth they would normally have (ie, none). From alan.mckinnon at gmail.com Thu Mar 6 23:42:20 2014 From: alan.mckinnon at gmail.com (Alan McKinnon) Date: Fri, 07 Mar 2014 01:42:20 +0200 Subject: [tac_plus] Create TACACS server hierarchy? In-Reply-To: <1FD1A2FED7E41F4ABD1D2E2BDDEA519B08447C@mbx030-w1-co-6.exch030.domain.local> References: <1FD1A2FED7E41F4ABD1D2E2BDDEA519B08447C@mbx030-w1-co-6.exch030.domain.local> Message-ID: <531907DC.7090002@gmail.com> On 07/03/2014 01:05, Aaron Wasserott wrote: > Is there a way to create a TACACS server hierarchy? For example, point a network device at tacacs server B, if the user does not exist there, then forward request to tacacs server A to complete? Ideally with server B handling all of the communication, such that a network device only needs to be configured for server B for AAA. > > This is for a lab situation, where I would like people who don't normally have network device access to be able to manage their own devices. I would point all my lab network devices to a lab tacacs server, and if they were not granted additional permissions in the lab, it would fail-back to the level of auth they would normally have (ie, none). > _______________________________________________ > tac_plus mailing list > tac_plus at shrubbery.net > http://www.shrubbery.net/mailman/listinfo/tac_plus > > Sounds like you want TAC_PLUS_AUTHEN_STATUS_FOLLOW which is part of the Tacacs protocol but to the best of my knowledge not supported in tac_plus (at least, none of the docs mention it). Search for this file in Internet drafts with your favourite search engine: draft-grant-tacacs-02.txt January, 1997 It's mentioned in section "Aborting a session" in that file. If you want to implement such a scheme, I reckon you should first verify your devices support it - Tacacs support varies hugely amongst vendors and some of them are truly abominable. You can't rely on any mentioned feature being available or not as the draft above never made it to a full proper internet standard. -- Alan McKinnon alan.mckinnon at gmail.com From aaron.wasserott at viawest.com Fri Mar 14 16:17:00 2014 From: aaron.wasserott at viawest.com (Aaron Wasserott) Date: Fri, 14 Mar 2014 16:17:00 +0000 Subject: [tac_plus] do_auth and aaa authorization not working with Foundry ServerIronXL load-balancers Message-ID: <1FD1A2FED7E41F4ABD1D2E2BDDEA519B1D2263@mbx030-w1-co-6.exch030.domain.local> I have many ancient Foundry ServerIronXL load-balancers. They work fine with basic TACACS AAA but when I implement do_auth I cannot login. I noticed some interesting behavior, that if I either turn off authorization or enable do_auth debugging it will work. Below are tacacs debug outputs for the 3 scenarios with do_auth. 1) with authorization and it fails. 2) without authorization and it passes. 3) with authorization and with debugging and it passes. Doing a compare, between scenario 1 and 3 it appears the root issue is that without debugging, do_auth will send AUTHOR/PASS_REPL and with debugging it will send AUTHOR/PASS_ADD. If you paste the entire debug output (with header) below into a text editor, this in on line 115. Shortly after that on line 138 there are other differences, and w/o debugging it either sends or receives (I can't tell) data not sent/received with debugging. Also notice that w/o debugging it never receives the username. Then w/o debugging it gets a null packet when it expects a continue, pointing to the ServerIron not liking something sent to it. I am hoping to find a way to modify how do_auth communicates with the ServerIron's that leaves debugging off, and authorization on. Thanks, ------ Here are the AAA configs I have on the ServerIronXL running version 7.4.01mT12 that works: aaa authentication enable default tacacs+ enable aaa authentication login default tacacs+ enable aaa authentication login privilege-mode aaa accounting commands 0 default start-stop tacacs+ aaa accounting exec default start-stop tacacs+ tacacs-server host 10.99.11.10 tacacs-server key 1 $S!--+sU@ tacacs-server retransmit 1 tacacs-server timeout 2 Adding the following breaks it unless debugging is enabled: aaa authorization exec default tacacs+ none I am running tac_plus version F5.0.0a1 and do_auth version 1.92 on Ubuntu 12.04 x64. Here are the tacacs debug outputs from scenario 1 and 3 I mentioned above. ### do_auth AND aaa authorization WITHOUT -D --- FAILS session request from 10.99.1.11 sock=2 connect from 10.99.1.11 [10.99.1.11] Waiting for packet Read AUTHEN/START size=36 validation request from 10.99.1.11 PACKET: key=password version 192 (0xc0), type 1, seq no 1, flags 0x1 session_id 534387377 (0x1fda1ab1), Data length 24 (0x18) End header type=AUTHEN/START, priv_lvl = 0 action=login authen_type=ascii service=login user_len=0 port_len=4 (0x4), rem_addr_len=12 (0xc) data_len=0 User: port: tty4 rem_addr: 10.33.144.34 data: End packet Authen Start request choose_authen returns 1 Writing AUTHEN/GETUSER size=55 PACKET: key=password version 192 (0xc0), type 1, seq no 2, flags 0x1 session_id 534387377 (0x1fda1ab1), Data length 43 (0x2b) End header type=AUTHEN status=4 (AUTHEN/GETUSER) flags=0x0 msg_len=37, data_len=0 msg: 0xa User Access Verification 0xa data: End packet Waiting for packet Read AUTHEN/CONT size=24 PACKET: key=password version 192 (0xc0), type 1, seq no 3, flags 0x1 session_id 534387377 (0x1fda1ab1), Data length 12 (0xc) End header type=AUTHEN/CONT user_msg_len 7 (0x7), user_data_len 0 (0x0) flags=0x0 User msg: testuser User data: End packet choose_authen chose default_fn Calling authentication function Writing AUTHEN/GETPASS size=28 PACKET: key=password version 192 (0xc0), type 1, seq no 4, flags 0x1 session_id 534387377 (0x1fda1ab1), 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=26 PACKET: key=password version 192 (0xc0), type 1, seq no 5, flags 0x1 session_id 534387377 (0x1fda1ab1), Data length 14 (0xe) End header type=AUTHEN/CONT user_msg_len 9 (0x9), user_data_len 0 (0x0) flags=0x0 User msg: P at ssw0rd! User data: End packet login query for 'testuser' tty4 from 10.99.1.11 accepted Writing AUTHEN/SUCCEED size=18 PACKET: key=password version 192 (0xc0), type 1, seq no 6, flags 0x1 session_id 534387377 (0x1fda1ab1), Data length 6 (0x6) End header type=AUTHEN status=1 (AUTHEN/SUCCEED) flags=0x0 msg_len=0, data_len=0 msg: data: End packet 10.99.1.11: disconnect session request from 10.99.1.11 sock=2 connect from 10.99.1.11 [10.99.1.11] Waiting for packet Read AUTHOR size=62 validation request from 10.99.1.11 PACKET: key=password version 192 (0xc0), type 2, seq no 1, flags 0x1 session_id 67398558 (0x4046b9e), Data length 50 (0x32) End header type=AUTHOR, priv_lvl=5, authen=1 method=tacacs+ svc=1 user_len=7 port_len=4 rem_addr_len=12 arg_cnt=2 User: testuser port: tty4 rem_addr: 10.33.144.34 arg[0]: size=13 service=shell arg[1]: size=4 cmd* End packet Writing AUTHOR/PASS_REPL size=30 PACKET: key=password version 192 (0xc0), type 2, seq no 2, flags 0x1 session_id 67398558 (0x4046b9e), Data length 18 (0x12) End header type=AUTHOR/REPLY status=2 (AUTHOR/PASS_REPL) msg_len=0, data_len=0 arg_cnt=1 msg: data: arg[0] size=11 priv-lvl=15 End packet authorization query for 'testuser' tty4 from 10.99.1.11 accepted 10.99.1.11: disconnect session request from 10.99.1.11 sock=2 connect from 10.99.1.11 [10.99.1.11] Waiting for packet Read AUTHEN/START size=36 validation request from 10.99.1.11 PACKET: key=password version 192 (0xc0), type 1, seq no 1, flags 0x1 session_id 629145972 (0x25800174), Data length 24 (0x18) End header type=AUTHEN/START, priv_lvl = 0 action=login authen_type=ascii service=login user_len=0 port_len=4 (0x4), rem_addr_len=12 (0xc) data_len=0 User: port: tty4 rem_addr: 10.33.144.34 data: End packet Authen Start request choose_authen returns 1 Writing AUTHEN/GETUSER size=55 PACKET: key=password version 192 (0xc0), type 1, seq no 2, flags 0x1 session_id 629145972 (0x25800174), Data length 43 (0x2b) End header type=AUTHEN status=4 (AUTHEN/GETUSER) flags=0x0 msg_len=37, data_len=0 msg: 0xa User Access Verification 0xa data: End packet Waiting for packet 10.99.1.11: exception on fd 2 Read -1 bytes from 10.99.1.11 tty4, expecting 12 Error 10.99.1.11 tty4: Null reply packet, expecting CONTINUE 10.99.1.11: disconnect ### do_auth AND aaa authorization AND -D --- SUCCESS session request from 10.99.1.11 sock=2 connect from 10.99.1.11 [10.99.1.11] Waiting for packet Read AUTHEN/START size=36 validation request from 10.99.1.11 PACKET: key=password version 192 (0xc0), type 1, seq no 1, flags 0x1 session_id 1510741470 (0x5a0c15de), Data length 24 (0x18) End header type=AUTHEN/START, priv_lvl = 0 action=login authen_type=ascii service=login user_len=0 port_len=4 (0x4), rem_addr_len=12 (0xc) data_len=0 User: port: tty2 rem_addr: 10.33.144.34 data: End packet Authen Start request choose_authen returns 1 Writing AUTHEN/GETUSER size=55 PACKET: key=password version 192 (0xc0), type 1, seq no 2, flags 0x1 session_id 1510741470 (0x5a0c15de), Data length 43 (0x2b) End header type=AUTHEN status=4 (AUTHEN/GETUSER) flags=0x0 msg_len=37, data_len=0 msg: 0xa User Access Verification 0xa data: End packet Waiting for packet Read AUTHEN/CONT size=24 PACKET: key=password version 192 (0xc0), type 1, seq no 3, flags 0x1 session_id 1510741470 (0x5a0c15de), Data length 12 (0xc) End header type=AUTHEN/CONT user_msg_len 7 (0x7), user_data_len 0 (0x0) flags=0x0 User msg: testuser User data: End packet choose_authen chose default_fn Calling authentication function Writing AUTHEN/GETPASS size=28 PACKET: key=password version 192 (0xc0), type 1, seq no 4, flags 0x1 session_id 1510741470 (0x5a0c15de), 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=26 PACKET: key=password version 192 (0xc0), type 1, seq no 5, flags 0x1 session_id 1510741470 (0x5a0c15de), Data length 14 (0xe) End header type=AUTHEN/CONT user_msg_len 9 (0x9), user_data_len 0 (0x0) flags=0x0 User msg: P at ssw0rd! User data: End packet login query for 'testuser' tty2 from 10.99.1.11 accepted Writing AUTHEN/SUCCEED size=18 PACKET: key=password version 192 (0xc0), type 1, seq no 6, flags 0x1 session_id 1510741470 (0x5a0c15de), Data length 6 (0x6) End header type=AUTHEN status=1 (AUTHEN/SUCCEED) flags=0x0 msg_len=0, data_len=0 msg: data: End packet 10.99.1.11: disconnect session request from 10.99.1.11 sock=2 connect from 10.99.1.11 [10.99.1.11] Waiting for packet Read AUTHOR size=62 validation request from 10.99.1.11 PACKET: key=password version 192 (0xc0), type 2, seq no 1, flags 0x1 session_id 504562638 (0x1e1303ce), Data length 50 (0x32) End header type=AUTHOR, priv_lvl=5, authen=1 method=tacacs+ svc=1 user_len=7 port_len=4 rem_addr_len=12 arg_cnt=2 User: testuser port: tty2 rem_addr: 10.33.144.34 arg[0]: size=13 service=shell arg[1]: size=4 cmd* End packet Writing AUTHOR/PASS_ADD size=30 PACKET: key=password version 192 (0xc0), type 2, seq no 2, flags 0x1 session_id 504562638 (0x1e1303ce), Data length 18 (0x12) End header type=AUTHOR/REPLY status=1 (AUTHOR/PASS_ADD) msg_len=0, data_len=0 arg_cnt=1 msg: data: arg[0] size=11 priv-lvl=15 End packet authorization query for 'testuser' tty2 from 10.99.1.11 accepted 10.99.1.11: disconnect session request from 10.99.1.11 sock=2 connect from 10.99.1.11 [10.99.1.11] Waiting for packet Read ACCT size=84 validation request from 10.99.1.11 PACKET: key=password version 192 (0xc0), type 3, seq no 1, flags 0x1 session_id 344350923 (0x148660cb), Data length 72 (0x48) End header ACCT, flags=0x2 method=6 priv_lvl=0 type=1 svc=1 user_len=7 port_len=4 rem_addr_len=12 arg_cnt=3 User: testuser port: tty2 rem_addr: 10.33.144.34 arg[0]: size=9 task_id=3 arg[1]: size=15 timezone=GMT+00 arg[2]: size=13 service=shell End packet Writing ACCT size=17 PACKET: key=password version 192 (0xc0), type 3, seq no 2, flags 0x1 session_id 344350923 (0x148660cb), Data length 5 (0x5) End header ACCT/REPLY status=1 msg_len=0 data_len=0 msg: data: End packet 10.99.1.11: disconnect session request from 10.99.1.11 sock=2 connect from 10.99.1.11 [10.99.1.11] Waiting for packet Read ACCT size=119 validation request from 10.99.1.11 PACKET: key=password version 192 (0xc0), type 3, seq no 1, flags 0x1 session_id 899685447 (0x35a01c47), Data length 107 (0x6b) End header ACCT, flags=0x4 method=6 priv_lvl=0 type=1 svc=1 user_len=7 port_len=4 rem_addr_len=12 arg_cnt=5 User: testuser port: tty2 rem_addr: 10.33.144.34 arg[0]: size=9 task_id=3 arg[1]: size=15 timezone=GMT+00 arg[2]: size=13 service=shell arg[3]: size=14 elapsed_time=2 arg[4]: size=19 reason=User Request End packet Writing ACCT size=17 PACKET: key=password version 192 (0xc0), type 3, seq no 2, flags 0x1 session_id 899685447 (0x35a01c47), Data length 5 (0x5) End header ACCT/REPLY status=1 msg_len=0 data_len=0 msg: data: End packet 10.99.1.11: disconnect From shashank.bhute at techprocess.co.in Fri Mar 14 05:11:47 2014 From: shashank.bhute at techprocess.co.in (Shashank Bhute) Date: Fri, 14 Mar 2014 10:41:47 +0530 Subject: [tac_plus] Prompt for password change at first login. Message-ID: <53228F93.2090703@techprocess.co.in> Hi Team, I have successfully setup tacacs+ on RHEL server. It is using PAM for authentication. Whenever I login to the router, it logins directly using PAM. Is there any option such that the user should be prompted for password change at first login ? -- Regards, Shashank "Unless indicated otherwise, the information contained in this message is privileged and confidential, and is intended only for the use of the addressee(s) named above and others who have been specifically authorized to receive it. If you are not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this message and/or attachments is strictly prohibited. TechProcess Payment Services Limited. accepts no liability for any damage caused by any virus transmitted by this email. Furthermore, the company does not warrant a proper and complete transmission of this information, nor does it accept liability for any delays. If you have received this message in error, please contact the sender and delete the message. Thank you." -------------- next part -------------- An HTML attachment was scrubbed... URL: From heas at shrubbery.net Fri Mar 14 22:38:50 2014 From: heas at shrubbery.net (heasley) Date: Fri, 14 Mar 2014 22:38:50 +0000 Subject: [tac_plus] do_auth and aaa authorization not working with Foundry ServerIronXL load-balancers In-Reply-To: <1FD1A2FED7E41F4ABD1D2E2BDDEA519B1D2263@mbx030-w1-co-6.exch030.domain.local> References: <1FD1A2FED7E41F4ABD1D2E2BDDEA519B1D2263@mbx030-w1-co-6.exch030.domain.local> Message-ID: <20140314223850.GG44053@shrubbery.net> Fri, Mar 14, 2014 at 04:17:00PM +0000, Aaron Wasserott: > I have many ancient Foundry ServerIronXL load-balancers. They work fine with basic TACACS AAA but when I implement do_auth I cannot login. I noticed some interesting behavior, that if I either turn off authorization or enable do_auth debugging it will work. > > Below are tacacs debug outputs for the 3 scenarios with do_auth. 1) with authorization and it fails. 2) without authorization and it passes. 3) with authorization and with debugging and it passes. Doing a compare, between scenario 1 and 3 it appears the root issue is that without debugging, do_auth will send AUTHOR/PASS_REPL and with debugging it will send AUTHOR/PASS_ADD. If you paste the entire debug output (with header) below into a text editor, this in on line 115. Shortly after that on line 138 there are other differences, and w/o debugging it either sends or receives (I can't tell) data not sent/received with debugging. Also notice that w/o debugging it never receives the username. Then w/o debugging it gets a null packet when it expects a continue, pointing to the ServerIron not liking something sent to it. > > I am hoping to find a way to modify how do_auth communicates with the ServerIron's that leaves debugging off, and authorization on. i believe something is missing; the do-auth script is exiting with value 2 but not writing the AVPs or the AVPs are empty. There are many debugging messages in the script that are commented out. you should uncomment them and try the script; there are only two places where it exits with code 2. it may be that it should be exiting with code 1. From heas at shrubbery.net Fri Mar 14 23:47:11 2014 From: heas at shrubbery.net (heasley) Date: Fri, 14 Mar 2014 23:47:11 +0000 Subject: [tac_plus] Prompt for password change at first login. In-Reply-To: <53228F93.2090703@techprocess.co.in> References: <53228F93.2090703@techprocess.co.in> Message-ID: <20140314234711.GH44053@shrubbery.net> Fri, Mar 14, 2014 at 10:41:47AM +0530, Shashank Bhute: > Hi Team, > > I have successfully setup tacacs+ on RHEL server. It is using PAM for authentication. > > Whenever I login to the router, it logins directly using PAM. Is there any option such that the user should be prompted for password change at first login ? > the daemon does not support password changing ATM. From aaron.wasserott at viawest.com Fri Mar 14 23:45:19 2014 From: aaron.wasserott at viawest.com (Aaron Wasserott) Date: Fri, 14 Mar 2014 23:45:19 +0000 Subject: [tac_plus] do_auth and aaa authorization not working with Foundry ServerIronXL load-balancers In-Reply-To: <20140314223850.GG44053@shrubbery.net> References: <1FD1A2FED7E41F4ABD1D2E2BDDEA519B1D2263@mbx030-w1-co-6.exch030.domain.local> <20140314223850.GG44053@shrubbery.net> Message-ID: <1FD1A2FED7E41F4ABD1D2E2BDDEA519B1D75A4@mbx030-w1-co-6.exch030.domain.local> I enabled debugging and recompiled do_auth.py. However I found two lines that generate an error. I couldn't figure out how to fix them so I left them commented out. There were 14 other DEBUG lines I uncommented that compiled successfully. ### Line 339: File "do_auth-debug.py", line 339 log_file.write('Hello World!' + '\n') ^ IndentationError: unindent does not match any outer indentation level ### Line 375: File "do_auth-debug.py", line 375 return_pairs = av_pairs[2:] ^ IndentationError: unindent does not match any outer indentation level Here is the log output from do_auth.log. Both of them are with 'aaa authorization exec' enabled on the ServerIron: ### do_auth.log with -D switch off service=shell cmd* priv-lvl=15 Thing:priv-lvl Thing:15 not len(the_command) > 0 Returning:priv-lvl=15 2014-03-14 17:27:36: User 'testuser' granted access to device '10.99.1.11' in group 'test-group' from '10.33.144.34' Exiting status 2 ### do_auth.log with -D switch on service=shell cmd=show cmd-arg=users cmd-arg=wide cmd-arg= show users wide 2014-03-14 17:39:59: User 'testuser' allowed command 'show users wide' to device '10.99.1.11' in 'test-group'->'command_permit' -----Original Message----- From: heasley [mailto:heas at shrubbery.net] Sent: Friday, March 14, 2014 4:39 PM To: Aaron Wasserott Cc: tac_plus at shrubbery.net Subject: Re: [tac_plus] do_auth and aaa authorization not working with Foundry ServerIronXL load-balancers Fri, Mar 14, 2014 at 04:17:00PM +0000, Aaron Wasserott: > I have many ancient Foundry ServerIronXL load-balancers. They work fine with basic TACACS AAA but when I implement do_auth I cannot login. I noticed some interesting behavior, that if I either turn off authorization or enable do_auth debugging it will work. > > Below are tacacs debug outputs for the 3 scenarios with do_auth. 1) with authorization and it fails. 2) without authorization and it passes. 3) with authorization and with debugging and it passes. Doing a compare, between scenario 1 and 3 it appears the root issue is that without debugging, do_auth will send AUTHOR/PASS_REPL and with debugging it will send AUTHOR/PASS_ADD. If you paste the entire debug output (with header) below into a text editor, this in on line 115. Shortly after that on line 138 there are other differences, and w/o debugging it either sends or receives (I can't tell) data not sent/received with debugging. Also notice that w/o debugging it never receives the username. Then w/o debugging it gets a null packet when it expects a continue, pointing to the ServerIron not liking something sent to it. > > I am hoping to find a way to modify how do_auth communicates with the ServerIron's that leaves debugging off, and authorization on. i believe something is missing; the do-auth script is exiting with value 2 but not writing the AVPs or the AVPs are empty. There are many debugging messages in the script that are commented out. you should uncomment them and try the script; there are only two places where it exits with code 2. it may be that it should be exiting with code 1. From lslater at yorku.ca Mon Mar 17 18:58:55 2014 From: lslater at yorku.ca (Linda Slater) Date: Mon, 17 Mar 2014 14:58:55 -0400 Subject: [tac_plus] tac_plus with pam-ldap to AD implementation Message-ID: Hi I have read and tried many of the information listed in the many postings but I am still having an issue. I am running on ubuntu 12.04lts. I want my users to log into the Cisco router devices using their AD credentials The server that TACplus is running on has been joined to the AD test domain. I have also confirmed that I can bind to the remote LDAP server. Note I have also tested this with krb5 _kerboros) and that also works. My tacacs.conf file for my tacplus user pointing to PAM login = PAM. When my test user tries to login to the Cisco router , the username and password that is accepted happens to be the username and password that is in the /etc/passwd file on the ubuntu server rather than the AD username and password? How do I get PAM to communicate with the remote LDAP server? Note I have configured my ldap files per the posting by Adam. I get the following error message pam_ldap: reconnecting to LDAP server... pam_ldap: reconnecting to LDAP server (sleeping 1 seconds)... note: AD and LDAP server are functioning and respond when I use the ldapsearch command. kerberos , kinit,klist ,etc. Regards Lin -------------- next part -------------- An HTML attachment was scrubbed... URL: From aaron.wasserott at viawest.com Mon Mar 17 19:25:29 2014 From: aaron.wasserott at viawest.com (Aaron Wasserott) Date: Mon, 17 Mar 2014 19:25:29 +0000 Subject: [tac_plus] tac_plus with pam-ldap to AD implementation In-Reply-To: References: Message-ID: <1FD1A2FED7E41F4ABD1D2E2BDDEA519B1DAC14@mbx030-w1-co-6.exch030.domain.local> Here are the 3 PAM/LDAP files we have running if they help. I am not sure how the 3rd one is getting linked into the mix, but to get LDAPS working we had to put it in place. This is on a CentOS 6.5 box, and users authenticate against ActiveDirectory. ### /etc/pam.d/tac_plus #%PAM-1.0 auth sufficient /lib/security/$ISA/pam_unix.so likeauth nullok auth sufficient /lib/security/$ISA/pam_ldap.so config=/etc/ldap_tacacs.conf use_first_pass auth required /lib/security/$ISA/pam_deny.so account [default=bad success=ok user_unknown=ignore] /lib/security/$ISA/pam_ldap.so account required /lib/security/$ISA/pam_permit.so ### /etc/ldap_tacacs.conf URI ldaps:// [ server name ] base OU=[ OU name ],dc=[ domain name ],dc=[ domain name suffix ] binddn [ binding DN ] bindpw [ binding password ] pam_login_attribute sAMAccountName ssl yes timelimit 120 bind_timelimit 120 idle_timelimit 3600 tls_cacert /etc/openldap/certs/[ cert file ] TLS_REQCERT never ### /etc/openldap/ldap.conf URI ldaps:// [ server name ] base OU=[ OU name ],dc=[ domain name ],dc=[ domain name suffix ] binddn [ binding DN ] bindpw [ binding password ] pam_login_attribute sAMAccountName ssl yes timelimit 120 bind_timelimit 120 idle_timelimit 3600 tls_cacert /etc/openldap/certs/[ cert file ] -----Original Message----- From: tac_plus-bounces at shrubbery.net [mailto:tac_plus-bounces at shrubbery.net] On Behalf Of Linda Slater Sent: Monday, March 17, 2014 12:59 PM To: tac_plus at shrubbery.net Subject: [tac_plus] tac_plus with pam-ldap to AD implementation Hi I have read and tried many of the information listed in the many postings but I am still having an issue. I am running on ubuntu 12.04lts. I want my users to log into the Cisco router devices using their AD credentials The server that TACplus is running on has been joined to the AD test domain. I have also confirmed that I can bind to the remote LDAP server. Note I have also tested this with krb5 _kerboros) and that also works. My tacacs.conf file for my tacplus user pointing to PAM login = PAM. When my test user tries to login to the Cisco router , the username and password that is accepted happens to be the username and password that is in the /etc/passwd file on the ubuntu server rather than the AD username and password? How do I get PAM to communicate with the remote LDAP server? Note I have configured my ldap files per the posting by Adam. I get the following error message pam_ldap: reconnecting to LDAP server... pam_ldap: reconnecting to LDAP server (sleeping 1 seconds)... note: AD and LDAP server are functioning and respond when I use the ldapsearch command. kerberos , kinit,klist ,etc. Regards Lin From daniel.schmidt at wyo.gov Mon Mar 17 20:45:15 2014 From: daniel.schmidt at wyo.gov (Daniel Schmidt) Date: Mon, 17 Mar 2014 14:45:15 -0600 Subject: [tac_plus] do_auth and aaa authorization not working with Foundry ServerIronXL load-balancers In-Reply-To: <1FD1A2FED7E41F4ABD1D2E2BDDEA519B1D75A4@mbx030-w1-co-6.exch030.domain.local> References: <1FD1A2FED7E41F4ABD1D2E2BDDEA519B1D2263@mbx030-w1-co-6.exch030.domain.local> <20140314223850.GG44053@shrubbery.net> <1FD1A2FED7E41F4ABD1D2E2BDDEA519B1D75A4@mbx030-w1-co-6.exch030.domain.local> Message-ID: -D switch is only for command line testing - mainly to test that your do_auth.ini is setup right. Never use it in tac_plus.conf. I wonder if the brocades don't like the return value? Kind of like Dell procurves. You could throw a: exit_val = 0 In the do_auth.ini and see if it makes it happier. I can't think of a reason it wouldn't return the tac_pairs - it's supposed to. This *looks* right though: service=shell cmd* priv-lvl=15 Thing:priv-lvl Thing:15 not len(the_command) > 0 Returning:priv-lvl=15 2014-03-14 17:27:36: User 'testuser' granted access to device '10.99.1.11' in group 'test-group' from '10.33.144.34' Exiting status 2 I can't remember what "thing" was - I think i was debugging to make sure we split correctly. Comment that part back out in the future. (Jathan rightly gave me a bad time for my variable names) Let me know what you find. I'm always happy to look into something that isn't a patch request. On Fri, Mar 14, 2014 at 5:45 PM, Aaron Wasserott < aaron.wasserott at viawest.com> wrote: > I enabled debugging and recompiled do_auth.py. However I found two lines > that generate an error. I couldn't figure out how to fix them so I left > them commented out. There were 14 other DEBUG lines I uncommented that > compiled successfully. > > ### Line 339: > > File "do_auth-debug.py", line 339 > log_file.write('Hello World!' + '\n') > ^ > IndentationError: unindent does not match any outer indentation level > > ### Line 375: > > File "do_auth-debug.py", line 375 > return_pairs = av_pairs[2:] > ^ > IndentationError: unindent does not match any outer indentation level > > > > Here is the log output from do_auth.log. Both of them are with 'aaa > authorization exec' enabled on the ServerIron: > > ### do_auth.log with -D switch off > > service=shell > cmd* > priv-lvl=15 > Thing:priv-lvl > Thing:15 > > not len(the_command) > 0 > Returning:priv-lvl=15 > 2014-03-14 17:27:36: User 'testuser' granted access to device '10.99.1.11' > in group 'test-group' from '10.33.144.34' > Exiting status 2 > > ### do_auth.log with -D switch on > > service=shell > cmd=show > cmd-arg=users > cmd-arg=wide > cmd-arg= > show users wide > 2014-03-14 17:39:59: User 'testuser' allowed command 'show users wide' to > device '10.99.1.11' in 'test-group'->'command_permit' > > > > -----Original Message----- > From: heasley [mailto:heas at shrubbery.net] > Sent: Friday, March 14, 2014 4:39 PM > To: Aaron Wasserott > Cc: tac_plus at shrubbery.net > Subject: Re: [tac_plus] do_auth and aaa authorization not working with > Foundry ServerIronXL load-balancers > > Fri, Mar 14, 2014 at 04:17:00PM +0000, Aaron Wasserott: > > I have many ancient Foundry ServerIronXL load-balancers. They work fine > with basic TACACS AAA but when I implement do_auth I cannot login. I > noticed some interesting behavior, that if I either turn off authorization > or enable do_auth debugging it will work. > > > > Below are tacacs debug outputs for the 3 scenarios with do_auth. 1) with > authorization and it fails. 2) without authorization and it passes. 3) > with authorization and with debugging and it passes. Doing a compare, > between scenario 1 and 3 it appears the root issue is that without > debugging, do_auth will send AUTHOR/PASS_REPL and with debugging it will > send AUTHOR/PASS_ADD. If you paste the entire debug output (with header) > below into a text editor, this in on line 115. Shortly after that on line > 138 there are other differences, and w/o debugging it either sends or > receives (I can't tell) data not sent/received with debugging. Also notice > that w/o debugging it never receives the username. Then w/o debugging it > gets a null packet when it expects a continue, pointing to the ServerIron > not liking something sent to it. > > > > I am hoping to find a way to modify how do_auth communicates with the > ServerIron's that leaves debugging off, and authorization on. > > i believe something is missing; the do-auth script is exiting with value 2 > but not writing the AVPs or the AVPs are empty. There are many debugging > messages in the script that are commented out. you should uncomment them > and try the script; there are only two places where it exits with code 2. > it may be that it should be exiting with code 1. > _______________________________________________ > tac_plus mailing list > tac_plus at shrubbery.net > http://www.shrubbery.net/mailman/listinfo/tac_plus > E-Mail to and from me, in connection with the transaction of public business, is subject to the Wyoming Public Records Act and may be disclosed to third parties. -------------- next part -------------- An HTML attachment was scrubbed... URL: From aaron.wasserott at viawest.com Tue Mar 18 03:10:23 2014 From: aaron.wasserott at viawest.com (Aaron Wasserott) Date: Tue, 18 Mar 2014 03:10:23 +0000 Subject: [tac_plus] do_auth and aaa authorization not working with Foundry ServerIronXL load-balancers In-Reply-To: References: <1FD1A2FED7E41F4ABD1D2E2BDDEA519B1D2263@mbx030-w1-co-6.exch030.domain.local> <20140314223850.GG44053@shrubbery.net> <1FD1A2FED7E41F4ABD1D2E2BDDEA519B1D75A4@mbx030-w1-co-6.exch030.domain.local> Message-ID: <1FD1A2FED7E41F4ABD1D2E2BDDEA519B1DAEAC@mbx030-w1-co-6.exch030.domain.local> That did the trick, thanks! Here is do_auth.log output now (still running the debug version of do_auth.pyc): service=shell cmd* priv-lvl=15 Thing:priv-lvl Thing:15 not len(the_command) > 0 Returning:priv-lvl=15 2014-03-17 21:04:05: User 'testuser' granted access to device '10.99.1.11' in group 'test-group' from '10.33.144.28' Exiting status 0 From: Daniel Schmidt [mailto:daniel.schmidt at wyo.gov] Sent: Monday, March 17, 2014 2:45 PM To: Aaron Wasserott Cc: tac_plus at shrubbery.net Subject: Re: [tac_plus] do_auth and aaa authorization not working with Foundry ServerIronXL load-balancers -D switch is only for command line testing - mainly to test that your do_auth.ini is setup right. Never use it in tac_plus.conf. I wonder if the brocades don't like the return value? Kind of like Dell procurves. You could throw a: exit_val = 0 In the do_auth.ini and see if it makes it happier. I can't think of a reason it wouldn't return the tac_pairs - it's supposed to. This *looks* right though: service=shell cmd* priv-lvl=15 Thing:priv-lvl Thing:15 not len(the_command) > 0 Returning:priv-lvl=15 2014-03-14 17:27:36: User 'testuser' granted access to device '10.99.1.11' in group 'test-group' from '10.33.144.34' Exiting status 2 I can't remember what "thing" was - I think i was debugging to make sure we split correctly. Comment that part back out in the future. (Jathan rightly gave me a bad time for my variable names) Let me know what you find. I'm always happy to look into something that isn't a patch request. On Fri, Mar 14, 2014 at 5:45 PM, Aaron Wasserott > wrote: I enabled debugging and recompiled do_auth.py. However I found two lines that generate an error. I couldn't figure out how to fix them so I left them commented out. There were 14 other DEBUG lines I uncommented that compiled successfully. ### Line 339: File "do_auth-debug.py", line 339 log_file.write('Hello World!' + '\n') ^ IndentationError: unindent does not match any outer indentation level ### Line 375: File "do_auth-debug.py", line 375 return_pairs = av_pairs[2:] ^ IndentationError: unindent does not match any outer indentation level Here is the log output from do_auth.log. Both of them are with 'aaa authorization exec' enabled on the ServerIron: ### do_auth.log with -D switch off service=shell cmd* priv-lvl=15 Thing:priv-lvl Thing:15 not len(the_command) > 0 Returning:priv-lvl=15 2014-03-14 17:27:36: User 'testuser' granted access to device '10.99.1.11' in group 'test-group' from '10.33.144.34' Exiting status 2 ### do_auth.log with -D switch on service=shell cmd=show cmd-arg=users cmd-arg=wide cmd-arg= show users wide 2014-03-14 17:39:59: User 'testuser' allowed command 'show users wide' to device '10.99.1.11' in 'test-group'->'command_permit' -----Original Message----- From: heasley [mailto:heas at shrubbery.net] Sent: Friday, March 14, 2014 4:39 PM To: Aaron Wasserott Cc: tac_plus at shrubbery.net Subject: Re: [tac_plus] do_auth and aaa authorization not working with Foundry ServerIronXL load-balancers Fri, Mar 14, 2014 at 04:17:00PM +0000, Aaron Wasserott: > I have many ancient Foundry ServerIronXL load-balancers. They work fine with basic TACACS AAA but when I implement do_auth I cannot login. I noticed some interesting behavior, that if I either turn off authorization or enable do_auth debugging it will work. > > Below are tacacs debug outputs for the 3 scenarios with do_auth. 1) with authorization and it fails. 2) without authorization and it passes. 3) with authorization and with debugging and it passes. Doing a compare, between scenario 1 and 3 it appears the root issue is that without debugging, do_auth will send AUTHOR/PASS_REPL and with debugging it will send AUTHOR/PASS_ADD. If you paste the entire debug output (with header) below into a text editor, this in on line 115. Shortly after that on line 138 there are other differences, and w/o debugging it either sends or receives (I can't tell) data not sent/received with debugging. Also notice that w/o debugging it never receives the username. Then w/o debugging it gets a null packet when it expects a continue, pointing to the ServerIron not liking something sent to it. > > I am hoping to find a way to modify how do_auth communicates with the ServerIron's that leaves debugging off, and authorization on. i believe something is missing; the do-auth script is exiting with value 2 but not writing the AVPs or the AVPs are empty. There are many debugging messages in the script that are commented out. you should uncomment them and try the script; there are only two places where it exits with code 2. it may be that it should be exiting with code 1. _______________________________________________ tac_plus mailing list tac_plus at shrubbery.net http://www.shrubbery.net/mailman/listinfo/tac_plus E-Mail to and from me, in connection with the transaction of public business, is subject to the Wyoming Public Records Act and may be disclosed to third parties. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mreddy at aristanetworks.com Mon Mar 17 22:49:49 2014 From: mreddy at aristanetworks.com (Mohan Reddy) Date: Mon, 17 Mar 2014 15:49:49 -0700 Subject: [tac_plus] Problem with creating Multiple groups for a single user. (creating composite groups) Message-ID: Hi, I am trying to create a composite group to assign it to an user but it's not working and tacacs service fails when restarted. Below is the link which I followed http://www.shrubbery.net/pipermail/tac_plus/2007-August/000125.html Below is the package details currently I have on my system Version: 4.0.4.19-11build1 Depends: libc6 (>= 2.14), libpam0g (>= 0.99.7.1), libtacacs+1, libwrap0 (>= 7.6-4~), adduser, python Conffiles: /etc/logrotate.d/tacacs+ cabd142065137950856da3a031d7121b /etc/default/tacacs+ d794c7a21bf0a2fb3e8276958d096474 /etc/init.d/tacacs_plus 56440b8721635d29ff42fea7d906c55d /etc/tacacs+/tac_plus.conf a2d54ccc38d35fb06e5f08b4be23f17a Description: TACACS+ authentication daemon TACACS+ is a protocol (not TACACS or XTACACS) for authentication, authorization and accounting (AAA) services for routers and network devices. Original-Maintainer: Henry-Nicolas Tourneur Homepage: http://www.shrubbery.net/tac_plus/ Below is sample of my configuration acl = 1 { permit = ^10\.190\.0\. } acl = 2 { permit = ^172\.22\. } #test group = readonly1 { default service = deny acl = 1 service = exec { priv-lvl = 2 } cmd = show { permit .* } cmd = conf { permit .* } cmd = bash { deny .* } } #readonly - account group = readonly2 { default service = deny acl = 2 service = exec { priv-lvl = 2 } cmd = show { permit .* } cmd = enable { permit .* } cmd = conf { deny .* } cmd = bash { permit .* } cmd = clear { deny .* } cmd = exit { permit .* } } #test group = test_all { member = readonly1 member = readonly2 } user = mohan { default service = deny member = test_all } Thanks, Mohan -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.mckinnon at gmail.com Tue Mar 18 09:00:40 2014 From: alan.mckinnon at gmail.com (Alan McKinnon) Date: Tue, 18 Mar 2014 11:00:40 +0200 Subject: [tac_plus] Problem with creating Multiple groups for a single user. (creating composite groups) In-Reply-To: References: Message-ID: <53280B38.8010809@gmail.com> On 18/03/2014 00:49, Mohan Reddy wrote: > Hi, > > I am trying to create a composite group to assign it to an user but it's > not working and tacacs service fails when restarted. Below is the link > which I followed > > > > http://www.shrubbery.net/pipermail/tac_plus/2007-August/000125.html [snip] > #test > > group = test_all { > > member = readonly1 > > member = readonly2 > > } tac_plus supports only one group per user, and that group can be a member of only one larger group, and so on recursively. So the syntax you are trying to use will not work Use Dan's python script do_auth.py, a copy is shipped in the tac_plus tarball -- Alan McKinnon alan.mckinnon at gmail.com From alan.mckinnon at gmail.com Tue Mar 18 09:02:41 2014 From: alan.mckinnon at gmail.com (Alan McKinnon) Date: Tue, 18 Mar 2014 11:02:41 +0200 Subject: [tac_plus] Problem with creating Multiple groups for a single user. (creating composite groups) In-Reply-To: References: Message-ID: <53280BB1.8040702@gmail.com> On 18/03/2014 00:49, Mohan Reddy wrote: > Hi, > > I am trying to create a composite group to assign it to an user but it's > not working and tacacs service fails when restarted. Below is the link > which I followed > > > > http://www.shrubbery.net/pipermail/tac_plus/2007-August/000125.html Addition to my other mail: That link you followed requires Kiss's patch to be applied before it will work. You need to find the patch code, apply it and recompile. > > > > > > Below is the package details currently I have on my system > > Version: 4.0.4.19-11build1 > > Depends: libc6 (>= 2.14), libpam0g (>= 0.99.7.1), libtacacs+1, libwrap0 (>= > 7.6-4~), adduser, python > > Conffiles: > > /etc/logrotate.d/tacacs+ cabd142065137950856da3a031d7121b > > /etc/default/tacacs+ d794c7a21bf0a2fb3e8276958d096474 > > /etc/init.d/tacacs_plus 56440b8721635d29ff42fea7d906c55d > > /etc/tacacs+/tac_plus.conf a2d54ccc38d35fb06e5f08b4be23f17a > > Description: TACACS+ authentication daemon > > TACACS+ is a protocol (not TACACS or XTACACS) for authentication, > > authorization and accounting (AAA) services for routers and network devices. > > Original-Maintainer: Henry-Nicolas Tourneur > > Homepage: http://www.shrubbery.net/tac_plus/ > > > > > > Below is sample of my configuration > > > > acl = 1 { > > permit = ^10\.190\.0\. > > } > > acl = 2 { > > permit = ^172\.22\. > > } > > > > > > #test > > group = readonly1 { > > default service = deny > > acl = 1 > > service = exec { > > priv-lvl = 2 > > } > > cmd = show { > > permit .* > > } > > cmd = conf { > > permit .* > > } > > cmd = bash { > > deny .* > > } > > } > > > > #readonly - account > > group = readonly2 { > > default service = deny > > acl = 2 > > service = exec { > > priv-lvl = 2 > > } > > cmd = show { > > permit .* > > } > > cmd = enable { > > permit .* > > } > > cmd = conf { > > deny .* > > } > > cmd = bash { > > permit .* > > } > > cmd = clear { > > deny .* > > } > > cmd = exit { > > permit .* > > } > > } > > > > #test > > group = test_all { > > member = readonly1 > > member = readonly2 > > } > > > > user = mohan { > > default service = deny > > member = test_all > > } > > > > Thanks, > > Mohan > -------------- 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 > > -- Alan McKinnon alan.mckinnon at gmail.com From lslater at yorku.ca Tue Mar 18 17:20:49 2014 From: lslater at yorku.ca (Linda Slater) Date: Tue, 18 Mar 2014 13:20:49 -0400 Subject: [tac_plus] tac_plus with pam-ldap to AD implementation In-Reply-To: <1FD1A2FED7E41F4ABD1D2E2BDDEA519B1DAC14@mbx030-w1-co-6.exch030.domain.local> References: <1FD1A2FED7E41F4ABD1D2E2BDDEA519B1DAC14@mbx030-w1-co-6.exch030.domain.local> Message-ID: Hi Aaron, I will give this a try. Question was any of the files in the pam.d directory such as Common-Auth modified from default? Linda Linda Slater | Senior Network Designer, Network Development | University Information Technology 010 Steacie Science and Engineering Library | York University | 4700 Keele St. , Toronto ON Canada M3J 1P3 T: +1.416.736.2100 ext 22733 | F: +1.416.736.5830 | lslater at yorku.ca | www.yorku.ca York UIT will NEVER send unsolicited requests for passwords or other personal information via email. Messages requesting such information are fraudulent and should be deleted. -------------- next part -------------- An HTML attachment was scrubbed... URL: From aaron.wasserott at viawest.com Tue Mar 18 17:24:48 2014 From: aaron.wasserott at viawest.com (Aaron Wasserott) Date: Tue, 18 Mar 2014 17:24:48 +0000 Subject: [tac_plus] tac_plus with pam-ldap to AD implementation In-Reply-To: References: <1FD1A2FED7E41F4ABD1D2E2BDDEA519B1DAC14@mbx030-w1-co-6.exch030.domain.local> Message-ID: <1FD1A2FED7E41F4ABD1D2E2BDDEA519B1DB2FD@mbx030-w1-co-6.exch030.domain.local> Yes, we run Centrify so some of those other files needed to be modified. Wish I could help you more, I mostly just handled the TACACS part of it. From: Linda Slater [mailto:lslater at yorku.ca] Sent: Tuesday, March 18, 2014 11:21 AM To: Aaron Wasserott Cc: tac_plus at shrubbery.net Subject: RE: [tac_plus] tac_plus with pam-ldap to AD implementation Hi Aaron, I will give this a try. Question was any of the files in the pam.d directory such as Common-Auth modified from default? Linda Linda Slater | Senior Network Designer, Network Development | University Information Technology 010 Steacie Science and Engineering Library | York University | 4700 Keele St. , Toronto ON Canada M3J 1P3 T: +1.416.736.2100 ext 22733 | F: +1.416.736.5830 | lslater at yorku.ca | www.yorku.ca York UIT will NEVER send unsolicited requests for passwords or other personal information via email. Messages requesting such information are fraudulent and should be deleted. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vadud3 at gmail.com Wed Mar 19 18:03:14 2014 From: vadud3 at gmail.com (Asif Iqbal) Date: Wed, 19 Mar 2014 14:03:14 -0400 Subject: [tac_plus] tac_plus with pam-ldap to AD implementation In-Reply-To: References: <1FD1A2FED7E41F4ABD1D2E2BDDEA519B1DAC14@mbx030-w1-co-6.exch030.domain.local> Message-ID: On Tue, Mar 18, 2014 at 1:20 PM, Linda Slater wrote: > Hi Aaron, > > I will give this a try. Question was any of the files in the pam.d > directory such as Common-Auth modified from default? > You don't have to Some details: http://shrubbery.net/tac_plus/PAM_guide.txt http://www.shrubbery.net/pipermail/tac_plus/2013-August/001319.html > > Linda > Linda Slater | Senior Network Designer, Network Development | University > Information Technology > 010 Steacie Science and Engineering Library | York University | 4700 Keele > St. , Toronto ON Canada M3J 1P3 > T: +1.416.736.2100 ext 22733 | F: +1.416.736.5830 | lslater at yorku.ca | > www.yorku.ca > > York UIT will NEVER send unsolicited requests for passwords or other > personal information via email. Messages requesting such information are > fraudulent and should be deleted. > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://www.shrubbery.net/pipermail/tac_plus/attachments/20140318/b3a99d97/attachment.html > > > _______________________________________________ > tac_plus mailing list > tac_plus at shrubbery.net > http://www.shrubbery.net/mailman/listinfo/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 mreddy at aristanetworks.com Wed Mar 26 21:25:37 2014 From: mreddy at aristanetworks.com (Mohan Reddy) Date: Wed, 26 Mar 2014 14:25:37 -0700 Subject: [tac_plus] FW: Your message to tac_plus awaits moderator approval In-Reply-To: References: Message-ID: <941e3162ecfd2fe736f890c9491d9d10@mail.gmail.com> Hello, I did not hear back anything regarding this issue. May I know if there is a solution for the problem. Thanks, Mohan -----Original Message----- From: tac_plus-bounces at shrubbery.net [mailto:tac_plus-bounces at shrubbery.net] Sent: Monday, March 17, 2014 10:55 PM To: mreddy at aristanetworks.com Subject: Your message to tac_plus awaits moderator approval Your mail to 'tac_plus' with the subject Problem with creating Multiple groups for a single user. (creating composite groups) Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: http://www.shrubbery.net/mailman/confirm/tac_plus/74a4b760976ad0b138d7ea4c 25a34c504226d9d8