From mreddy at aristanetworks.com Wed Apr 2 18:23:21 2014 From: mreddy at aristanetworks.com (Mohan Reddy) Date: Wed, 2 Apr 2014 11:23:21 -0700 Subject: [tac_plus] Problem with creating Multiple groups for a single user. (creating composite groups) Message-ID: <9cd85e5468f9856d451ded274725c365@mail.gmail.com> Alan, As mentioned by you I used Dan's python script but I did receive a parsing error . Below is the error details and config details, 2014-04-02 10:44:04,978 [CRITICAL]: Can't open/parse config file: '/usr/bin/do_auth.ini' 2014-04-02 10:54:53,545 [CRITICAL]: Can't open/parse config file: '/usr/bin/do_auth.ini' 2014-04-02 10:59:28,184 [CRITICAL]: Can't open/parse config file: '/usr/bin/do_auth.ini' -------------------------------------------------------------------------- ------------------------- Configuration in Tacacs_conf file -------------------------------------------------------------------------- ----------------------------- user = test1 { member = doauthaccess } group = doauthaccess { default service = permit service = exec { priv-lvl = 15 } after authorization "/usr/bin/python /usr/bin/do_auth.py -i $address -u $user -d $name -l /usr/bin/log.txt -f /usr/bin/do_auth.ini" } -------------------------------------------------------------------------- ------------------------- Configuration in do_auth.ini file -------------------------------------------------------------------------- ----------------------------- [users] default = noprivs jathan = vdxgroup dans = vdxgroup test1 = readonly1 [readonly1] host_allow = .* device_permit = .* command_permit = .* -------------------------------------------------------------- May I know what might be the issue. Thanks, Mohan From alan.mckinnon at gmail.com Thu Apr 3 06:10:24 2014 From: alan.mckinnon at gmail.com (Alan McKinnon) Date: Thu, 03 Apr 2014 08:10:24 +0200 Subject: [tac_plus] Problem with creating Multiple groups for a single user. (creating composite groups) In-Reply-To: <9cd85e5468f9856d451ded274725c365@mail.gmail.com> References: <9cd85e5468f9856d451ded274725c365@mail.gmail.com> Message-ID: <533CFB50.2020305@gmail.com> On 02/04/2014 20:23, Mohan Reddy wrote: > Alan, > As mentioned by you I used Dan's python script but I did receive a parsing > error . Below is the error details and config details, > > 2014-04-02 10:44:04,978 [CRITICAL]: Can't open/parse config file: > '/usr/bin/do_auth.ini' Does /usr/bin/do_auth.ini really exist? What are the ownerships and permissions of that file? As which user does tac_plus run? > 2014-04-02 10:54:53,545 [CRITICAL]: Can't open/parse config file: > '/usr/bin/do_auth.ini' > 2014-04-02 10:59:28,184 [CRITICAL]: Can't open/parse config file: > '/usr/bin/do_auth.ini' > > > -------------------------------------------------------------------------- > ------------------------- > Configuration in Tacacs_conf file > -------------------------------------------------------------------------- > ----------------------------- > user = test1 { > member = doauthaccess > } > > group = doauthaccess { > default service = permit > > service = exec { > priv-lvl = 15 > } > > after authorization "/usr/bin/python /usr/bin/do_auth.py -i $address > -u $user -d $name -l /usr/bin/log.txt -f /usr/bin/do_auth.ini" > } > > -------------------------------------------------------------------------- > ------------------------- > Configuration in do_auth.ini file > -------------------------------------------------------------------------- > ----------------------------- > > [users] > default = > noprivs > jathan = > vdxgroup > dans = > vdxgroup > test1 = > readonly1 > > [readonly1] > host_allow = > .* > device_permit = > .* > command_permit = > .* > > -------------------------------------------------------------- > > May I know what might be the issue. > > Thanks, > Mohan > _______________________________________________ > 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 mreddy at aristanetworks.com Thu Apr 3 17:14:19 2014 From: mreddy at aristanetworks.com (Mohan Reddy) Date: Thu, 3 Apr 2014 10:14:19 -0700 Subject: [tac_plus] Problem with creating Multiple groups for a single user. (creating composite groups) In-Reply-To: <533CFB50.2020305@gmail.com> References: <9cd85e5468f9856d451ded274725c365@mail.gmail.com> <533CFB50.2020305@gmail.com> Message-ID: <519c9fcc64d5decabab332f24a8d1a40@mail.gmail.com> Alan, It worked, Sorry it was indentation in do_auth.ini script which has been resolved now. Now my problem with multiple groups has been resolved. Thanks, Mohan -----Original Message----- From: tac_plus-bounces at shrubbery.net [mailto:tac_plus-bounces at shrubbery.net] On Behalf Of Alan McKinnon Sent: Wednesday, April 02, 2014 11:10 PM To: tac_plus at shrubbery.net Subject: Re: [tac_plus] Problem with creating Multiple groups for a single user. (creating composite groups) On 02/04/2014 20:23, Mohan Reddy wrote: > Alan, > As mentioned by you I used Dan's python script but I did receive a > parsing error . Below is the error details and config details, > > 2014-04-02 10:44:04,978 [CRITICAL]: Can't open/parse config file: > '/usr/bin/do_auth.ini' Does /usr/bin/do_auth.ini really exist? What are the ownerships and permissions of that file? As which user does tac_plus run? > 2014-04-02 10:54:53,545 [CRITICAL]: Can't open/parse config file: > '/usr/bin/do_auth.ini' > 2014-04-02 10:59:28,184 [CRITICAL]: Can't open/parse config file: > '/usr/bin/do_auth.ini' > > > ---------------------------------------------------------------------- > ---- > ------------------------- > Configuration in Tacacs_conf file > ---------------------------------------------------------------------- > ---- > ----------------------------- > user = test1 { > member = doauthaccess > } > > group = doauthaccess { > default service = permit > > service = exec { > priv-lvl = 15 > } > > after authorization "/usr/bin/python /usr/bin/do_auth.py -i > $address -u $user -d $name -l /usr/bin/log.txt -f /usr/bin/do_auth.ini" > } > > ---------------------------------------------------------------------- > ---- > ------------------------- > Configuration in do_auth.ini file > ---------------------------------------------------------------------- > ---- > ----------------------------- > > [users] > default = > noprivs > jathan = > vdxgroup > dans = > vdxgroup > test1 = > readonly1 > > [readonly1] > host_allow = > .* > device_permit = > .* > command_permit = > .* > > -------------------------------------------------------------- > > May I know what might be the issue. > > Thanks, > Mohan > _______________________________________________ > tac_plus mailing list > tac_plus at shrubbery.net > http://www.shrubbery.net/mailman/listinfo/tac_plus > > -- Alan McKinnon alan.mckinnon at gmail.com _______________________________________________ tac_plus mailing list tac_plus at shrubbery.net http://www.shrubbery.net/mailman/listinfo/tac_plus From alan.mckinnon at gmail.com Thu Apr 3 17:48:43 2014 From: alan.mckinnon at gmail.com (Alan McKinnon) Date: Thu, 03 Apr 2014 19:48:43 +0200 Subject: [tac_plus] Problem with creating Multiple groups for a single user. (creating composite groups) In-Reply-To: <519c9fcc64d5decabab332f24a8d1a40@mail.gmail.com> References: <9cd85e5468f9856d451ded274725c365@mail.gmail.com> <533CFB50.2020305@gmail.com> <519c9fcc64d5decabab332f24a8d1a40@mail.gmail.com> Message-ID: <533D9EFB.8030604@gmail.com> Python indentation rules, yes I know that problem well :-) Good to hear you got it fixed. On 03/04/2014 19:14, Mohan Reddy wrote: > Alan, > It worked, Sorry it was indentation in do_auth.ini script which has been > resolved now. Now my problem with multiple groups has been resolved. > > Thanks, > Mohan > > -----Original Message----- > From: tac_plus-bounces at shrubbery.net > [mailto:tac_plus-bounces at shrubbery.net] On Behalf Of Alan McKinnon > Sent: Wednesday, April 02, 2014 11:10 PM > To: tac_plus at shrubbery.net > Subject: Re: [tac_plus] Problem with creating Multiple groups for a single > user. (creating composite groups) > > On 02/04/2014 20:23, Mohan Reddy wrote: >> Alan, >> As mentioned by you I used Dan's python script but I did receive a >> parsing error . Below is the error details and config details, >> >> 2014-04-02 10:44:04,978 [CRITICAL]: Can't open/parse config file: >> '/usr/bin/do_auth.ini' > > > Does /usr/bin/do_auth.ini really exist? > What are the ownerships and permissions of that file? > As which user does tac_plus run? > > > > >> 2014-04-02 10:54:53,545 [CRITICAL]: Can't open/parse config file: >> '/usr/bin/do_auth.ini' >> 2014-04-02 10:59:28,184 [CRITICAL]: Can't open/parse config file: >> '/usr/bin/do_auth.ini' >> >> >> ---------------------------------------------------------------------- >> ---- >> ------------------------- >> Configuration in Tacacs_conf file >> ---------------------------------------------------------------------- >> ---- >> ----------------------------- >> user = test1 { >> member = doauthaccess >> } >> >> group = doauthaccess { >> default service = permit >> >> service = exec { >> priv-lvl = 15 >> } >> >> after authorization "/usr/bin/python /usr/bin/do_auth.py -i >> $address -u $user -d $name -l /usr/bin/log.txt -f /usr/bin/do_auth.ini" >> } >> >> ---------------------------------------------------------------------- >> ---- >> ------------------------- >> Configuration in do_auth.ini file >> ---------------------------------------------------------------------- >> ---- >> ----------------------------- >> >> [users] >> default = >> noprivs >> jathan = >> vdxgroup >> dans = >> vdxgroup >> test1 = >> readonly1 >> >> [readonly1] >> host_allow = >> .* >> device_permit = >> .* >> command_permit = >> .* >> >> -------------------------------------------------------------- >> >> May I know what might be the issue. >> >> Thanks, >> Mohan >> _______________________________________________ >> tac_plus mailing list >> tac_plus at shrubbery.net >> http://www.shrubbery.net/mailman/listinfo/tac_plus >> >> > > > -- > Alan McKinnon > alan.mckinnon at gmail.com > > _______________________________________________ > 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 daniel.schmidt at wyo.gov Sun Apr 6 18:53:15 2014 From: daniel.schmidt at wyo.gov (Daniel Schmidt) Date: Sun, 6 Apr 2014 12:53:15 -0600 Subject: [tac_plus] Problem with creating Multiple groups for a single user. (creating composite groups) In-Reply-To: <533D9EFB.8030604@gmail.com> References: <9cd85e5468f9856d451ded274725c365@mail.gmail.com> <533CFB50.2020305@gmail.com> <519c9fcc64d5decabab332f24a8d1a40@mail.gmail.com> <533D9EFB.8030604@gmail.com> Message-ID: It probably works best when the library is also called to WRITE the ini, which I don't do. (Library doesn't have much idiot checking in it) For most, I think tacacs is something you setup and mainly leave alone which is why I haven't done more. Perhaps I should get with Jathan and work on detecting errors in the parsing, as this seems to be the biggest mistake people make, especially as some people don't care about multiple groups at all, they only want their tac_plus to work correctly with Nexus. Maybe including a default ini file with the download could help. On a side note, while thanking Alan for his assisting while I was out, I have to also smile at a bit of irony in that the one person who was wary and wouldn't touch do_auth is now helping people with it. :-P Thanks Alan! On Thu, Apr 3, 2014 at 11:48 AM, Alan McKinnon wrote: > Python indentation rules, yes I know that problem well :-) > > Good to hear you got it fixed. > > > > On 03/04/2014 19:14, Mohan Reddy wrote: > > Alan, > > It worked, Sorry it was indentation in do_auth.ini script which has been > > resolved now. Now my problem with multiple groups has been resolved. > > > > Thanks, > > Mohan > > > > -----Original Message----- > > From: tac_plus-bounces at shrubbery.net > > [mailto:tac_plus-bounces at shrubbery.net] On Behalf Of Alan McKinnon > > Sent: Wednesday, April 02, 2014 11:10 PM > > To: tac_plus at shrubbery.net > > Subject: Re: [tac_plus] Problem with creating Multiple groups for a > single > > user. (creating composite groups) > > > > On 02/04/2014 20:23, Mohan Reddy wrote: > >> Alan, > >> As mentioned by you I used Dan's python script but I did receive a > >> parsing error . Below is the error details and config details, > >> > >> 2014-04-02 10:44:04,978 [CRITICAL]: Can't open/parse config file: > >> '/usr/bin/do_auth.ini' > > > > > > Does /usr/bin/do_auth.ini really exist? > > What are the ownerships and permissions of that file? > > As which user does tac_plus run? > > > > > > > > > >> 2014-04-02 10:54:53,545 [CRITICAL]: Can't open/parse config file: > >> '/usr/bin/do_auth.ini' > >> 2014-04-02 10:59:28,184 [CRITICAL]: Can't open/parse config file: > >> '/usr/bin/do_auth.ini' > >> > >> > >> ---------------------------------------------------------------------- > >> ---- > >> ------------------------- > >> Configuration in Tacacs_conf file > >> ---------------------------------------------------------------------- > >> ---- > >> ----------------------------- > >> user = test1 { > >> member = doauthaccess > >> } > >> > >> group = doauthaccess { > >> default service = permit > >> > >> service = exec { > >> priv-lvl = 15 > >> } > >> > >> after authorization "/usr/bin/python /usr/bin/do_auth.py -i > >> $address -u $user -d $name -l /usr/bin/log.txt -f /usr/bin/do_auth.ini" > >> } > >> > >> ---------------------------------------------------------------------- > >> ---- > >> ------------------------- > >> Configuration in do_auth.ini file > >> ---------------------------------------------------------------------- > >> ---- > >> ----------------------------- > >> > >> [users] > >> default = > >> noprivs > >> jathan = > >> vdxgroup > >> dans = > >> vdxgroup > >> test1 = > >> readonly1 > >> > >> [readonly1] > >> host_allow = > >> .* > >> device_permit = > >> .* > >> command_permit = > >> .* > >> > >> -------------------------------------------------------------- > >> > >> May I know what might be the issue. > >> > >> Thanks, > >> Mohan > >> _______________________________________________ > >> tac_plus mailing list > >> tac_plus at shrubbery.net > >> http://www.shrubbery.net/mailman/listinfo/tac_plus > >> > >> > > > > > > -- > > Alan McKinnon > > alan.mckinnon at gmail.com > > > > _______________________________________________ > > tac_plus mailing list > > tac_plus at shrubbery.net > > http://www.shrubbery.net/mailman/listinfo/tac_plus > > > > > -- > Alan McKinnon > alan.mckinnon at gmail.com > > _______________________________________________ > 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 vadud3 at gmail.com Sun Apr 6 19:16:37 2014 From: vadud3 at gmail.com (Asif Iqbal) Date: Sun, 6 Apr 2014 15:16:37 -0400 Subject: [tac_plus] Problem with creating Multiple groups for a single user. (creating composite groups) In-Reply-To: References: <9cd85e5468f9856d451ded274725c365@mail.gmail.com> <533CFB50.2020305@gmail.com> <519c9fcc64d5decabab332f24a8d1a40@mail.gmail.com> <533D9EFB.8030604@gmail.com> Message-ID: On Sun, Apr 6, 2014 at 2:53 PM, Daniel Schmidt wrote: > > On a side note, while thanking Alan for his assisting while I was out, I > have to also smile at a bit of irony in that the one person who was wary > and wouldn't touch do_auth is now helping people with it. :-P Thanks > Alan! > Another offtopic comment, but we manage about 8 different tac_plus instances on different IP/PORT combination. And command authorizations are different, at least between cisco and juniper. We also have arista, alcatel and others. I should give the do_auth a try, not sure how different command authorization syntax can be consolidated? Sorry about injecting offtopic conversation here. -- 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 Sun Apr 6 21:54:00 2014 From: mreddy at aristanetworks.com (Mohan Reddy) Date: Sun, 6 Apr 2014 14:54:00 -0700 Subject: [tac_plus] Problem with creating Multiple groups for a single user. (creating composite groups) In-Reply-To: References: <9cd85e5468f9856d451ded274725c365@mail.gmail.com> <533CFB50.2020305@gmail.com> <519c9fcc64d5decabab332f24a8d1a40@mail.gmail.com> <533D9EFB.8030604@gmail.com> Message-ID: Daniel, The parsing error got resolved. I was receiving the parsing error due to the indentation in do_auth.ini file. Now the script is working fine. Thanks, Mohan On Sun, Apr 6, 2014 at 11:53 AM, Daniel Schmidt wrote: > It probably works best when the library is also called to WRITE the ini, > which I don't do. (Library doesn't have much idiot checking in it) For > most, I think tacacs is something you setup and mainly leave alone which is > why I haven't done more. > > Perhaps I should get with Jathan and work on detecting errors in the > parsing, as this seems to be the biggest mistake people make, especially as > some people don't care about multiple groups at all, they only want their > tac_plus to work correctly with Nexus. Maybe including a default ini file > with the download could help. > > On a side note, while thanking Alan for his assisting while I was out, I > have to also smile at a bit of irony in that the one person who was wary > and wouldn't touch do_auth is now helping people with it. :-P Thanks > Alan! > > > On Thu, Apr 3, 2014 at 11:48 AM, Alan McKinnon >wrote: > > > Python indentation rules, yes I know that problem well :-) > > > > Good to hear you got it fixed. > > > > > > > > On 03/04/2014 19:14, Mohan Reddy wrote: > > > Alan, > > > It worked, Sorry it was indentation in do_auth.ini script which has > been > > > resolved now. Now my problem with multiple groups has been resolved. > > > > > > Thanks, > > > Mohan > > > > > > -----Original Message----- > > > From: tac_plus-bounces at shrubbery.net > > > [mailto:tac_plus-bounces at shrubbery.net] On Behalf Of Alan McKinnon > > > Sent: Wednesday, April 02, 2014 11:10 PM > > > To: tac_plus at shrubbery.net > > > Subject: Re: [tac_plus] Problem with creating Multiple groups for a > > single > > > user. (creating composite groups) > > > > > > On 02/04/2014 20:23, Mohan Reddy wrote: > > >> Alan, > > >> As mentioned by you I used Dan's python script but I did receive a > > >> parsing error . Below is the error details and config details, > > >> > > >> 2014-04-02 10:44:04,978 [CRITICAL]: Can't open/parse config file: > > >> '/usr/bin/do_auth.ini' > > > > > > > > > Does /usr/bin/do_auth.ini really exist? > > > What are the ownerships and permissions of that file? > > > As which user does tac_plus run? > > > > > > > > > > > > > > >> 2014-04-02 10:54:53,545 [CRITICAL]: Can't open/parse config file: > > >> '/usr/bin/do_auth.ini' > > >> 2014-04-02 10:59:28,184 [CRITICAL]: Can't open/parse config file: > > >> '/usr/bin/do_auth.ini' > > >> > > >> > > >> ---------------------------------------------------------------------- > > >> ---- > > >> ------------------------- > > >> Configuration in Tacacs_conf file > > >> ---------------------------------------------------------------------- > > >> ---- > > >> ----------------------------- > > >> user = test1 { > > >> member = doauthaccess > > >> } > > >> > > >> group = doauthaccess { > > >> default service = permit > > >> > > >> service = exec { > > >> priv-lvl = 15 > > >> } > > >> > > >> after authorization "/usr/bin/python /usr/bin/do_auth.py -i > > >> $address -u $user -d $name -l /usr/bin/log.txt -f > /usr/bin/do_auth.ini" > > >> } > > >> > > >> ---------------------------------------------------------------------- > > >> ---- > > >> ------------------------- > > >> Configuration in do_auth.ini file > > >> ---------------------------------------------------------------------- > > >> ---- > > >> ----------------------------- > > >> > > >> [users] > > >> default = > > >> noprivs > > >> jathan = > > >> vdxgroup > > >> dans = > > >> vdxgroup > > >> test1 = > > >> readonly1 > > >> > > >> [readonly1] > > >> host_allow = > > >> .* > > >> device_permit = > > >> .* > > >> command_permit = > > >> .* > > >> > > >> -------------------------------------------------------------- > > >> > > >> May I know what might be the issue. > > >> > > >> Thanks, > > >> Mohan > > >> _______________________________________________ > > >> tac_plus mailing list > > >> tac_plus at shrubbery.net > > >> http://www.shrubbery.net/mailman/listinfo/tac_plus > > >> > > >> > > > > > > > > > -- > > > Alan McKinnon > > > alan.mckinnon at gmail.com > > > > > > _______________________________________________ > > > tac_plus mailing list > > > tac_plus at shrubbery.net > > > http://www.shrubbery.net/mailman/listinfo/tac_plus > > > > > > > > > -- > > Alan McKinnon > > alan.mckinnon at gmail.com > > > > _______________________________________________ > > 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: < > http://www.shrubbery.net/pipermail/tac_plus/attachments/20140406/448c1085/attachment.html > > > _______________________________________________ > tac_plus mailing list > tac_plus at shrubbery.net > http://www.shrubbery.net/mailman/listinfo/tac_plus > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aaron.wasserott at viawest.com Mon Apr 7 14:53:18 2014 From: aaron.wasserott at viawest.com (Aaron Wasserott) Date: Mon, 7 Apr 2014 14:53:18 +0000 Subject: [tac_plus] Problem with creating Multiple groups for a single user. (creating composite groups) In-Reply-To: References: <9cd85e5468f9856d451ded274725c365@mail.gmail.com> <533CFB50.2020305@gmail.com> <519c9fcc64d5decabab332f24a8d1a40@mail.gmail.com> <533D9EFB.8030604@gmail.com> Message-ID: <1FD1A2FED7E41F4ABD1D2E2BDDEA519B05A60BC2@mbx030-w1-co-6.exch030.domain.local> I would definitely give do_auth a try, you should be able to consolidate down to one tacacs daemon. How complex it needs to be depends really on your support user base. I use the tac_plus.conf file to point the different tiers of support users to different do_auth files. From there, I create separate groups in do_auth.ini that use device_permit to specify what commands they can run on the different devices, and pass the proper privilege level if necessary. You can use the DEFAULT user in the do_auth.ini file to assign everyone to the same groups in your do_auth.ini file, if you have already assigned users to a given do_auth.ini file in tac_plus.conf. -----Original Message----- From: tac_plus-bounces at shrubbery.net [mailto:tac_plus-bounces at shrubbery.net] On Behalf Of Asif Iqbal Sent: Sunday, April 06, 2014 1:17 PM To: Daniel Schmidt Cc: tac_plus at shrubbery.net Subject: Re: [tac_plus] Problem with creating Multiple groups for a single user. (creating composite groups) On Sun, Apr 6, 2014 at 2:53 PM, Daniel Schmidt wrote: > > On a side note, while thanking Alan for his assisting while I was out, > I have to also smile at a bit of irony in that the one person who was > wary and wouldn't touch do_auth is now helping people with it. :-P > Thanks Alan! > Another offtopic comment, but we manage about 8 different tac_plus instances on different IP/PORT combination. And command authorizations are different, at least between cisco and juniper. We also have arista, alcatel and others. I should give the do_auth a try, not sure how different command authorization syntax can be consolidated? Sorry about injecting offtopic conversation here. -- 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: _______________________________________________ tac_plus mailing list tac_plus at shrubbery.net http://www.shrubbery.net/mailman/listinfo/tac_plus From daniel.schmidt at wyo.gov Mon Apr 7 18:24:23 2014 From: daniel.schmidt at wyo.gov (Daniel Schmidt) Date: Mon, 7 Apr 2014 12:24:23 -0600 Subject: [tac_plus] Problem with creating Multiple groups for a single user. (creating composite groups) In-Reply-To: References: <9cd85e5468f9856d451ded274725c365@mail.gmail.com> <533CFB50.2020305@gmail.com> <519c9fcc64d5decabab332f24a8d1a40@mail.gmail.com> <533D9EFB.8030604@gmail.com> Message-ID: I see no reason why you couldn't do it with one instance with the help of do_auth. Just need to know what pairs to send to who. On Sun, Apr 6, 2014 at 1:16 PM, Asif Iqbal wrote: > > > > On Sun, Apr 6, 2014 at 2:53 PM, Daniel Schmidt wrote: > >> >> On a side note, while thanking Alan for his assisting while I was out, I >> have to also smile at a bit of irony in that the one person who was wary >> and wouldn't touch do_auth is now helping people with it. :-P Thanks >> Alan! >> > > Another offtopic comment, but we manage about 8 different tac_plus > instances > on different IP/PORT combination. And command authorizations are different, > at least between cisco and juniper. We also have arista, alcatel and > others. > > I should give the do_auth a try, not sure how different command > authorization > syntax can be consolidated? > > Sorry about injecting offtopic conversation here. > > > -- > 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? > > 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 vadud3 at gmail.com Tue Apr 8 00:41:26 2014 From: vadud3 at gmail.com (Asif Iqbal) Date: Mon, 7 Apr 2014 20:41:26 -0400 Subject: [tac_plus] Problem with creating Multiple groups for a single user. (creating composite groups) In-Reply-To: References: <9cd85e5468f9856d451ded274725c365@mail.gmail.com> <533CFB50.2020305@gmail.com> <519c9fcc64d5decabab332f24a8d1a40@mail.gmail.com> <533D9EFB.8030604@gmail.com> Message-ID: On Mon, Apr 7, 2014 at 2:24 PM, Daniel Schmidt wrote: > I see no reason why you couldn't do it with one instance with the help of > do_auth. Just need to know what pairs to send to who. > Please let me know if I should start a new discussion thread, but I have 13 different tac_plus instances with 267 groups and 11969 user = foo {..} entries. So any user could be on any of those groups as long as no one user in multiple groups on any of the 13 instances. I would love to see if I can consolidate all two one instance. It will probably also help adding a user using a script to multiple groups. Currently doing tons of awk magics to keep the {} pairs in track while adding new users on multiple instances into multiple groups. > > On Sun, Apr 6, 2014 at 1:16 PM, Asif Iqbal wrote: > >> >> >> >> On Sun, Apr 6, 2014 at 2:53 PM, Daniel Schmidt wrote: >> >>> >>> On a side note, while thanking Alan for his assisting while I was out, I >>> have to also smile at a bit of irony in that the one person who was wary >>> and wouldn't touch do_auth is now helping people with it. :-P Thanks >>> Alan! >>> >> >> Another offtopic comment, but we manage about 8 different tac_plus >> instances >> on different IP/PORT combination. And command authorizations are >> different, >> at least between cisco and juniper. We also have arista, alcatel and >> others. >> >> I should give the do_auth a try, not sure how different command >> authorization >> syntax can be consolidated? >> >> Sorry about injecting offtopic conversation here. >> >> >> -- >> 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? >> >> > 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. > > > -- 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 daniel.schmidt at wyo.gov Tue Apr 8 19:03:31 2014 From: daniel.schmidt at wyo.gov (Daniel Schmidt) Date: Tue, 8 Apr 2014 13:03:31 -0600 Subject: [tac_plus] Problem with creating Multiple groups for a single user. (creating composite groups) In-Reply-To: References: <9cd85e5468f9856d451ded274725c365@mail.gmail.com> <533CFB50.2020305@gmail.com> <519c9fcc64d5decabab332f24a8d1a40@mail.gmail.com> <533D9EFB.8030604@gmail.com> Message-ID: Holy #*@&. I'm starting to wish I had programmed inheritance on the groups. However, when I first started it, I had NO CLUE that it would ever be necessary (due to strange different tacacs implementations, NOT a failure of tac_plus). It wasn't till later that I even added the ability to change the tac_pairs. As it is right now, you'll be in group #^!!: homer = brocade_tier1 juniper_tier1 dell_tier1 no_name_piece_of_junk_ tier1 Now, kudos to Aaron for thinking of an entirely different approach. Expect to see his name on tacacs.org, (At least, I think he'd the first person - can't remember, anybody else do this?) Create a teir1.ini and define all your groups there as ONE access level. Assign them all to the default group and do all your assignments in tac_plus.conf like so: default = brocade_tier1 juniper_tier1 dell_tier1 no_name_piece_of_junk_ tier1 Then, in the tac_plus.conf file do all your user assignments, changing only the "ini" file you use in the after authentication. # example group with a bunch of seemingly random #*@& you have to do to get nexus and wlc working group = tier1_access { default service = permit service = exec { priv-lvl = 15 shell:roles="network-operator" idletime = 20 } # The wlc will not take a return value of 2. English: those roles must exist in tac_plus.conf service = ciscowlc { role1 = MONITOR } after authorization "/usr/bin/python /root/do_auth.pyo -i $address -fix_crs_bug -u $user -d $name -l /root/log.txt -f /root/tier1.ini" } user = homer { member = tier1_access service = ciscowlc { role1 = ALL } # optional enable password, if they insist enable = file /etc/passwd } That there might be your better bet. On Mon, Apr 7, 2014 at 6:41 PM, Asif Iqbal wrote: > > On Mon, Apr 7, 2014 at 2:24 PM, Daniel Schmidt wrote: > >> I see no reason why you couldn't do it with one instance with the help of >> do_auth. Just need to know what pairs to send to who. >> > > Please let me know if I should start a new discussion thread, but I have > 13 different tac_plus > instances with 267 groups and 11969 user = foo {..} entries. > > So any user could be on any of those groups as long as no one user in > multiple groups on any > of the 13 instances. > > I would love to see if I can consolidate all two one instance. > > It will probably also help adding a user using a script to multiple > groups. Currently doing > tons of awk magics to keep the {} pairs in track while adding new users on > multiple instances > into multiple groups. > > > > >> >> On Sun, Apr 6, 2014 at 1:16 PM, Asif Iqbal wrote: >> >>> >>> >>> >>> On Sun, Apr 6, 2014 at 2:53 PM, Daniel Schmidt wrote: >>> >>>> >>>> On a side note, while thanking Alan for his assisting while I was out, I >>>> have to also smile at a bit of irony in that the one person who was wary >>>> and wouldn't touch do_auth is now helping people with it. :-P Thanks >>>> Alan! >>>> >>> >>> Another offtopic comment, but we manage about 8 different tac_plus >>> instances >>> on different IP/PORT combination. And command authorizations are >>> different, >>> at least between cisco and juniper. We also have arista, alcatel and >>> others. >>> >>> I should give the do_auth a try, not sure how different command >>> authorization >>> syntax can be consolidated? >>> >>> Sorry about injecting offtopic conversation here. >>> >>> >>> -- >>> 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? >>> >>> >> 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. >> >> >> > > > -- > 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? > > 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 mus3 at Lehigh.EDU Fri Apr 11 14:57:32 2014 From: mus3 at Lehigh.EDU (Munroe Sollog) Date: Fri, 11 Apr 2014 10:57:32 -0400 Subject: [tac_plus] using a passwd file Message-ID: <534802DC.90100@lehigh.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm working on getting tacacs+ configured to use a passwd file. I've created a temporary one with a dummy password for testing: luser:$1$96948aad$3z1Q25KrTmwzEJvEaAEfw.:15322:0:99999:7::: However, when I try to log in using the file I get the following debug lines: connect from 192.168.4.12 [192.168.4.12] tac_passwd_lookup: open /usr/local/etc/tac_passwd_file 6 tac_passwd_lookup: close /usr/local/etc/tac_passwd_file 6 verify barfoo $1$96948aad$3z1Q25KrTmwzEJvEaAEfw. barfoo encrypts to $1$96948aad$3z1Q25KrTmwzEJvEaAEfw. Password is correct Password has expired :: login query for 'luser' port tty1 from 192.168.4.12 rejected login failure: luser 192.168.4.12 (192.168.4.12) tty1 My understanding of the shadow file notation is that '99999' should be 'days until password expires' I checked the date on both the device and the server they are synced correctly. Here is the stanza for that user in my conf user = luser{ default service = permit # login = cleartext barfoo login = file /usr/local/etc/tac_passwd_file service = exec { priv-lvl = 15 } } -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQEcBAEBAgAGBQJTSALbAAoJEPbbZiWCKDVCs8sH/jxXqW5v2Vps0gh7v2yZvDtn 0lP4DQnDNKnxankOX/gQevS3ClZoxIDQh+s98qv8LuxqOMX3Ki6uW/sAEu8tfg9r N5HnZWVLlQI4T+6oNQaGRqH/KGxAH9u6DtM7DM9Gau3VvugsUNEZGp7FTh1vw7B/ 8F4T+f+8Z/AFKmjOUp/9wlY8dSoBQHUAY7k5Ybi/6BTraBuxVgZe03O3Ulc6adRN d0TmN2GwQ7xvu42FiXsstjIW7bPXoUKdiCmHFYzVXaXzu9hnGRwRFTgr2yFKqh6V YOSybq+hV+gE93BI0oGFwhFIYub6jLX4vXlACFYj9fJTuxu11xwhvGbwAb7Xj8E= =qULd -----END PGP SIGNATURE----- From mus3 at Lehigh.EDU Fri Apr 11 18:10:47 2014 From: mus3 at Lehigh.EDU (Munroe Sollog) Date: Fri, 11 Apr 2014 14:10:47 -0400 Subject: [tac_plus] using a passwd file In-Reply-To: <534802DC.90100@lehigh.edu> References: <534802DC.90100@lehigh.edu> Message-ID: <53483027.3060109@lehigh.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I found a few other posts talking about this problem and it looks like if I use the /etc/passwd format *not* the /etc/shadow format and replace the 'x' with the actual hash, the authentication seems to work correctly. On 04/11/2014 10:57 AM, Munroe Sollog wrote: > I'm working on getting tacacs+ configured to use a passwd file. I've created a temporary one > with a dummy password for testing: > > luser:$1$96948aad$3z1Q25KrTmwzEJvEaAEfw.:15322:0:99999:7::: > > > However, when I try to log in using the file I get the following debug lines: > > connect from 192.168.4.12 [192.168.4.12] tac_passwd_lookup: open /usr/local/etc/tac_passwd_file > 6 tac_passwd_lookup: close /usr/local/etc/tac_passwd_file 6 verify barfoo > $1$96948aad$3z1Q25KrTmwzEJvEaAEfw. barfoo encrypts to $1$96948aad$3z1Q25KrTmwzEJvEaAEfw. > Password is correct Password has expired :: login query for 'luser' port tty1 from 192.168.4.12 > rejected login failure: luser 192.168.4.12 (192.168.4.12) tty1 > > > My understanding of the shadow file notation is that '99999' should be 'days until password > expires' > > I checked the date on both the device and the server they are synced correctly. > > Here is the stanza for that user in my conf > > user = luser{ default service = permit # login = cleartext barfoo login = file > /usr/local/etc/tac_passwd_file service = exec { priv-lvl = 15 } } > _______________________________________________ tac_plus mailing list tac_plus at shrubbery.net > http://www.shrubbery.net/mailman/listinfo/tac_plus > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQEcBAEBAgAGBQJTSDAlAAoJEPbbZiWCKDVCTD4H/1CCgBiIyTx4i046/YG16PWu QzSrd9f5sDJrnUo/mOzHK4NjfbF9iGeP9szGLOA0OnEuaQzARCn7P259qKeznz7r 2g4TWP0T1K0judt5GgCY1zHgrYPgC0UDJsDbz7YDz/hVt4QqUF/apfQvg5NvKQ90 ffTrlHcf5deYBuKQ7ujWJBAzlnf0iWmIeUKzc9AUIpFbPuEuGytwsDmO3PmIUzeA dFmPoAA5rpv4pOHkUJEf7SHxafzC2nPcv4bDpvigXAR6oLatrbPk5GVzozRd20oO cTi5eEGF5zcPqvd0FVaBg33oNl685/PhvEKXsbEz3AXI4th3a6hrwjauMV3pj5Y= =0BNo -----END PGP SIGNATURE----- From mus3 at Lehigh.EDU Mon Apr 14 12:55:21 2014 From: mus3 at Lehigh.EDU (Munroe Sollog) Date: Mon, 14 Apr 2014 08:55:21 -0400 Subject: [tac_plus] logging all commands run Message-ID: <534BDAB9.8040803@lehigh.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 So the next tribulation in my quest for a fully auditing network environment is to have tacacs+ log _every_ command. group = techs { service = exec { priv-lvl=2 } cmd = show { permit .* } cmd = exit { permit .* } cmd = enable { permit .* } } When a member of this group issues the command 'show interface status' nothing is logged. My best guess as to why nothing is logged is because a 'normal' priv-lvl 1 user has access to that command and thus there is no reason to do the authorization step, and thus it doesn't get logged. Is there a way to force logging for everything entered? I'm willing to entertain some creative solutions. Thanks. - - Munroe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQEcBAEBAgAGBQJTS9q5AAoJEPbbZiWCKDVC6NgIAO34qKtC8G+qTNuCJ5a2L4NZ 8Rem5fr+u0FBr8y2SlvYd2AJKXP7ey626qD6exBTOUsjDxiCTP0G5istBnNcuxPZ JeGd/4SgUKNYQURSC62F8vUeRXZdiyLFiy/vcops/yf22UF4u4GzvxHizdxo73+y S36zf60B5mgwQ0C8aoHGX/O15H/dinCLwiZ1PV8l7mpqfcaB0Hpl3MskU53nzUm1 Kcbf/OjilSdvebnjoB7ujB5j70D0QuS9ugE8Q9RkZIGfx6tAAkdvlzoeVRiNzeY+ E3ayHA0nhlagi/Fy75Um20ERW3y3/65YETJLGsn+T2gOm2LCj7OcjNmzKMBH37o= =HVK+ -----END PGP SIGNATURE----- From alan.mckinnon at gmail.com Mon Apr 14 14:27:32 2014 From: alan.mckinnon at gmail.com (Alan McKinnon) Date: Mon, 14 Apr 2014 16:27:32 +0200 Subject: [tac_plus] logging all commands run In-Reply-To: <534BDAB9.8040803@lehigh.edu> References: <534BDAB9.8040803@lehigh.edu> Message-ID: <534BF054.1080201@gmail.com> On 14/04/2014 14:55, Munroe Sollog wrote: > So the next tribulation in my quest for a fully auditing network environment is to have tacacs+ > log _every_ command. > > group = techs { > service = exec { > priv-lvl=2 > } > cmd = show { > permit .* > } > cmd = exit { > permit .* > } > cmd = enable { > permit .* > } > } > > > When a member of this group issues the command 'show interface status' nothing is logged. My best > guess as to why nothing is logged is because a 'normal' priv-lvl 1 user has access to that command > and thus there is no reason to do the authorization step, and thus it doesn't get logged. Is > there a way to force logging for everything entered? I'm willing to entertain some creative > solutions. > > Thanks. > - Munroe Do you want to log every command entered, or every command run? For the former, use tacacs accounting. For the latter, use the -d 8 option to tac_plus (this makes your logs very verbose) A useful thing to keep in mind is what tac_plus does when it logs. It's not a tacacs log, it's a Unix daemon log and it's recording the state of the daemon. Any information about the tacacs exchange is a lucky side-effect. Accounting does give you all commands run, but obviously not those that failed authorization. Accounting is to record events that happened, not things that were denied. A further option that requires some work on your part is to use the pre- and post-authorization hooks provided in tac_plus. It's described rather well in the manual file shipped in the tarball - tac_plus will call a custom script that you write and all info you could find useful are available as parameters (username, source address, port, device address, port and more). Getting the command run is quirky - it's not a parameter; tac_plus writes it to STDOUT as a sequence of key-value pairs which you have to read and assemble. The command is tokenized into words, the first is the "command" all others are "arguments". Like this: cmd=show cmd_arg=ip cmd_arg=interface cmd_arg=brief Tacacs AV pairs requested by the router are sent similarly. Use the pre-auth hook and your script should write a log entry and exit with exit code 0. tac_plus will then continue doing it's usual authorization. You won't need accounting logs for this purpose if you follow this route. -- Alan McKinnon alan.mckinnon at gmail.com From mus3 at Lehigh.EDU Mon Apr 14 14:38:35 2014 From: mus3 at Lehigh.EDU (Munroe Sollog) Date: Mon, 14 Apr 2014 10:38:35 -0400 Subject: [tac_plus] logging all commands run In-Reply-To: <534BF054.1080201@gmail.com> References: <534BDAB9.8040803@lehigh.edu> <534BF054.1080201@gmail.com> Message-ID: <534BF2EB.8020608@lehigh.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I am using accounting. The behavior though is a bit confusing to me. For example, the user 'luser' has the following stanza in the tac_plus.conf: user = luser { default service = permit login = file /usr/local/etc/tac_passwd_file service = exec { priv-lvl = 2 } cmd = show { permit .* } } The following is an excerpt from the accounting log as well as the actual switch session. As you can see the first time I try 'conf t' nothing is logged, when I am still priv-lvl 2 and run 'show interface status' nothing is logged. However, after I 'enable' (typoed the password the first time) and then run a 'do show interface status' then it is logged. I'm wondering why isn't my 'show interface status' logged the first time. ====tacacs accounting log==== Apr 14 10:30:46 192.168.1.126 luser tty2 192.168.1.76 start task_id=334 timezone=UTC service=shell start_time=1397485846 Apr 14 10:31:01 192.168.1.126 luser tty2 192.168.1.76 stop task_id=334 timezone=UTC service=shell start_time=1397485861 priv-lvl=0 cmd=enable Apr 14 10:31:07 192.168.1.126 luser tty2 192.168.1.76 stop task_id=335 timezone=UTC service=shell start_time=1397485867 priv-lvl=0 cmd=enable Apr 14 10:31:12 192.168.1.126 luser tty2 192.168.1.76 stop task_id=336 timezone=UTC service=shell start_time=1397485872 priv-lvl=15 cmd=configure terminal Apr 14 10:31:16 192.168.1.126 luser tty2 192.168.1.76 stop task_id=337 timezone=UTC service=shell start_time=1397485876 priv-lvl=15 cmd=do sho interface status =======switch session===== $ ssh luser at 192.168.1.126 Password: Switch#show interface status Port Name Status Vlan Duplex Speed Type Gi0/1 this is int 1 connected 1 a-full a-1000 10/100/1000BaseTX Gi0/2 notconnect 1 auto auto 10/100/1000BaseTX Gi0/3 notconnect 1 auto auto 10/100/1000BaseTX Gi0/4 notconnect 1 auto auto 10/100/1000BaseTX Gi0/5 notconnect 1 auto auto 10/100/1000BaseTX Gi0/6 notconnect 1 auto auto 10/100/1000BaseTX Gi0/7 notconnect 1 auto auto 10/100/1000BaseTX Gi0/8 connected 1 a-full a-1000 10/100/1000BaseTX Switch#conf t ^ % Invalid input detected at '^' marker. Switch#enable Password: % Error in authentication. Switch#enable Password: Switch#conf t Enter configuration commands, one per line. End with CNTL/Z. Switch(config)#do sho interface status Port Name Status Vlan Duplex Speed Type Gi0/1 this is int 1 connected 1 a-full a-1000 10/100/1000BaseTX Gi0/2 notconnect 1 auto auto 10/100/1000BaseTX Gi0/3 notconnect 1 auto auto 10/100/1000BaseTX Gi0/4 notconnect 1 auto auto 10/100/1000BaseTX Gi0/5 notconnect 1 auto auto 10/100/1000BaseTX Gi0/6 notconnect 1 auto auto 10/100/1000BaseTX Gi0/7 notconnect 1 auto auto 10/100/1000BaseTX Gi0/8 connected 1 a-full a-1000 10/100/1000BaseTX Switch(config)# -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQEcBAEBAgAGBQJTS/LqAAoJEPbbZiWCKDVC9FsH/RJg+iSM1ahnLD2lTfxyJbsR p1Dwklt66Hzjck3LDSDy7cRkcpcSk9g9cS8tkZrvjmP3fC/z5qKcKuFNtJD7rvp8 uVNO/CUAp14T3zyEgXebPtDRkHH/5sUO5g9m+wK2tqQVTj9PCwkVKgonFMQbpbim Lt2FxrCVM68G7cvf9F23/rvMnPn5fQjTtWYqbgfGA8fsNh2DtH07LHmFQQUgnMj3 FIWPExMommrmV98EcKUYghyRK9kOmwbMEWXTQABRebfqrshgnmah1WmrPSMiN8th 2l7VFvzqZmFgdB7gc7BZwrDWCRs61+Ec2iJ5d05MtWlLU04NHWQAy3Urc24Ba6g= =D5BM -----END PGP SIGNATURE----- From alan.mckinnon at gmail.com Mon Apr 14 14:55:16 2014 From: alan.mckinnon at gmail.com (Alan McKinnon) Date: Mon, 14 Apr 2014 16:55:16 +0200 Subject: [tac_plus] logging all commands run In-Reply-To: <534BF2EB.8020608@lehigh.edu> References: <534BDAB9.8040803@lehigh.edu> <534BF054.1080201@gmail.com> <534BF2EB.8020608@lehigh.edu> Message-ID: <534BF6D4.6050103@gmail.com> On 14/04/2014 16:38, Munroe Sollog wrote: > I am using accounting. The behavior though is a bit confusing to me. For example, the user > 'luser' has the following stanza in the tac_plus.conf: > > user = luser { > default service = permit > login = file /usr/local/etc/tac_passwd_file > service = exec { > priv-lvl = 2 > } > cmd = show { > permit .* > } > } > > The following is an excerpt from the accounting log as well as the actual switch session. As you > can see the first time I try 'conf t' nothing is logged, when I am still priv-lvl 2 and run 'show > interface status' nothing is logged. However, after I 'enable' (typoed the password the first > time) and then run a 'do show interface status' then it is logged. I'm wondering why isn't my > 'show interface status' logged the first time. > > > ====tacacs accounting log==== > > Apr 14 10:30:46 192.168.1.126 luser tty2 192.168.1.76 start task_id=334 timezone=UTC > service=shell start_time=1397485846 > Apr 14 10:31:01 192.168.1.126 luser tty2 192.168.1.76 stop task_id=334 timezone=UTC > service=shell start_time=1397485861 priv-lvl=0 cmd=enable > Apr 14 10:31:07 192.168.1.126 luser tty2 192.168.1.76 stop task_id=335 timezone=UTC > service=shell start_time=1397485867 priv-lvl=0 cmd=enable > Apr 14 10:31:12 192.168.1.126 luser tty2 192.168.1.76 stop task_id=336 timezone=UTC > service=shell start_time=1397485872 priv-lvl=15 cmd=configure terminal > Apr 14 10:31:16 192.168.1.126 luser tty2 192.168.1.76 stop task_id=337 timezone=UTC > service=shell start_time=1397485876 priv-lvl=15 cmd=do sho interface status > > > > > =======switch session===== > $ ssh luser at 192.168.1.126 > Password: > > Switch#show interface status > > Port Name Status Vlan Duplex Speed Type > Gi0/1 this is int 1 connected 1 a-full a-1000 10/100/1000BaseTX > Gi0/2 notconnect 1 auto auto 10/100/1000BaseTX > Gi0/3 notconnect 1 auto auto 10/100/1000BaseTX > Gi0/4 notconnect 1 auto auto 10/100/1000BaseTX > Gi0/5 notconnect 1 auto auto 10/100/1000BaseTX > Gi0/6 notconnect 1 auto auto 10/100/1000BaseTX > Gi0/7 notconnect 1 auto auto 10/100/1000BaseTX > Gi0/8 connected 1 a-full a-1000 10/100/1000BaseTX > Switch#conf t > ^ > % Invalid input detected at '^' marker. > > Switch#enable > Password: > % Error in authentication. > > Switch#enable > Password: > Switch#conf t > Enter configuration commands, one per line. End with CNTL/Z. > Switch(config)#do sho interface status > > Port Name Status Vlan Duplex Speed Type > Gi0/1 this is int 1 connected 1 a-full a-1000 10/100/1000BaseTX > Gi0/2 notconnect 1 auto auto 10/100/1000BaseTX > Gi0/3 notconnect 1 auto auto 10/100/1000BaseTX > Gi0/4 notconnect 1 auto auto 10/100/1000BaseTX > Gi0/5 notconnect 1 auto auto 10/100/1000BaseTX > Gi0/6 notconnect 1 auto auto 10/100/1000BaseTX > Gi0/7 notconnect 1 auto auto 10/100/1000BaseTX > Gi0/8 connected 1 a-full a-1000 10/100/1000BaseTX > Switch(config)# If a command isn't being logged in the accounting logs it's because the router never sent it to the tacacs server to be logged; if the router does send it then tac_plus will log it. You can verify this by enabling accounting debugging, check the tac_plus man page for the -d option Examine closely your AAA settings on the router to see how accounting is set up there. -- Alan McKinnon alan.mckinnon at gmail.com From daniel.schmidt at wyo.gov Mon Apr 14 17:16:24 2014 From: daniel.schmidt at wyo.gov (Daniel Schmidt) Date: Mon, 14 Apr 2014 11:16:24 -0600 Subject: [tac_plus] logging all commands run In-Reply-To: <534BF6D4.6050103@gmail.com> References: <534BDAB9.8040803@lehigh.edu> <534BF054.1080201@gmail.com> <534BF2EB.8020608@lehigh.edu> <534BF6D4.6050103@gmail.com> Message-ID: Hint: aaa accounting commands .... Not sure why you are using cutom priv levels rather than authorization On Mon, Apr 14, 2014 at 8:55 AM, Alan McKinnon wrote: > On 14/04/2014 16:38, Munroe Sollog wrote: > > I am using accounting. The behavior though is a bit confusing to me. > For example, the user > > 'luser' has the following stanza in the tac_plus.conf: > > > > user = luser { > > default service = permit > > login = file /usr/local/etc/tac_passwd_file > > service = exec { > > priv-lvl = 2 > > } > > cmd = show { > > permit .* > > } > > } > > > > The following is an excerpt from the accounting log as well as the > actual switch session. As you > > can see the first time I try 'conf t' nothing is logged, when I am still > priv-lvl 2 and run 'show > > interface status' nothing is logged. However, after I 'enable' (typoed > the password the first > > time) and then run a 'do show interface status' then it is logged. I'm > wondering why isn't my > > 'show interface status' logged the first time. > > > > > > ====tacacs accounting log==== > > > > Apr 14 10:30:46 192.168.1.126 luser tty2 192.168.1.76 > start task_id=334 timezone=UTC > > service=shell start_time=1397485846 > > Apr 14 10:31:01 192.168.1.126 luser tty2 192.168.1.76 > stop task_id=334 timezone=UTC > > service=shell start_time=1397485861 priv-lvl=0 cmd=enable > > Apr 14 10:31:07 192.168.1.126 luser tty2 192.168.1.76 > stop task_id=335 timezone=UTC > > service=shell start_time=1397485867 priv-lvl=0 cmd=enable > > Apr 14 10:31:12 192.168.1.126 luser tty2 192.168.1.76 > stop task_id=336 timezone=UTC > > service=shell start_time=1397485872 priv-lvl=15 cmd=configure > terminal > > Apr 14 10:31:16 192.168.1.126 luser tty2 192.168.1.76 > stop task_id=337 timezone=UTC > > service=shell start_time=1397485876 priv-lvl=15 cmd=do sho > interface status > > > > > > > > > > =======switch session===== > > $ ssh luser at 192.168.1.126 > > Password: > > > > Switch#show interface status > > > > Port Name Status Vlan Duplex Speed Type > > Gi0/1 this is int 1 connected 1 a-full a-1000 > 10/100/1000BaseTX > > Gi0/2 notconnect 1 auto auto > 10/100/1000BaseTX > > Gi0/3 notconnect 1 auto auto > 10/100/1000BaseTX > > Gi0/4 notconnect 1 auto auto > 10/100/1000BaseTX > > Gi0/5 notconnect 1 auto auto > 10/100/1000BaseTX > > Gi0/6 notconnect 1 auto auto > 10/100/1000BaseTX > > Gi0/7 notconnect 1 auto auto > 10/100/1000BaseTX > > Gi0/8 connected 1 a-full a-1000 > 10/100/1000BaseTX > > Switch#conf t > > ^ > > % Invalid input detected at '^' marker. > > > > Switch#enable > > Password: > > % Error in authentication. > > > > Switch#enable > > Password: > > Switch#conf t > > Enter configuration commands, one per line. End with CNTL/Z. > > Switch(config)#do sho interface status > > > > Port Name Status Vlan Duplex Speed Type > > Gi0/1 this is int 1 connected 1 a-full a-1000 > 10/100/1000BaseTX > > Gi0/2 notconnect 1 auto auto > 10/100/1000BaseTX > > Gi0/3 notconnect 1 auto auto > 10/100/1000BaseTX > > Gi0/4 notconnect 1 auto auto > 10/100/1000BaseTX > > Gi0/5 notconnect 1 auto auto > 10/100/1000BaseTX > > Gi0/6 notconnect 1 auto auto > 10/100/1000BaseTX > > Gi0/7 notconnect 1 auto auto > 10/100/1000BaseTX > > Gi0/8 connected 1 a-full a-1000 > 10/100/1000BaseTX > > Switch(config)# > > > If a command isn't being logged in the accounting logs it's because the > router never sent it to the tacacs server to be logged; if the router > does send it then tac_plus will log it. You can verify this by enabling > accounting debugging, check the tac_plus man page for the -d option > > Examine closely your AAA settings on the router to see how accounting is > set up there. > > -- > Alan McKinnon > alan.mckinnon at gmail.com > > _______________________________________________ > 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 mus3 at Lehigh.EDU Mon Apr 14 17:27:08 2014 From: mus3 at Lehigh.EDU (Munroe Sollog) Date: Mon, 14 Apr 2014 13:27:08 -0400 Subject: [tac_plus] logging all commands run In-Reply-To: References: <534BDAB9.8040803@lehigh.edu> <534BF054.1080201@gmail.com> <534BF2EB.8020608@lehigh.edu> <534BF6D4.6050103@gmail.com> Message-ID: <534C1A6C.8080701@lehigh.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I think I figured it out. I had: aaa accounting commands 2 default start-stop group tacacs+ aaa accounting commands 15 default start-stop group tacacs+ but when I added: aaa accounting commands 1 default start-stop group tacacs+ all of the commands I noticed weren't being logged started showing up. With regard to your concern about custom priv levels, it was something I went back and forth on. My current rationale is, I want the tac_config simple without having to enumerate dozens of commands and their variants. For example, I wanted my lowest level techs to be able to run 'show logging' which by default is a priv-15 command. When logged in at priv-1, even if I explicitly allowed that command the switch wouldn't recognize it. That being the case, I would have to give everyone priv-lvl 15 access and be extra careful to explicitly allow only the commands I want them to run. That seems like a lot more work than moving 'show logging' down to a lower privilege level and keeping the techs away from priv-lvl 15. But that is just my current rationale, if there is a better idea, I'm not married to it. - - Munroe On 04/14/2014 01:16 PM, Daniel Schmidt wrote: > Hint: aaa accounting commands .... > > Not sure why you are using cutom priv levels rather than authorization > > > On Mon, Apr 14, 2014 at 8:55 AM, Alan McKinnon wrote: > >> On 14/04/2014 16:38, Munroe Sollog wrote: >>> I am using accounting. The behavior though is a bit confusing to me. >> For example, the user >>> 'luser' has the following stanza in the tac_plus.conf: >>> >>> user = luser { default service = permit login = file /usr/local/etc/tac_passwd_file service >>> = exec { priv-lvl = 2 } cmd = show { permit .* } } >>> >>> The following is an excerpt from the accounting log as well as the >> actual switch session. As you >>> can see the first time I try 'conf t' nothing is logged, when I am still >> priv-lvl 2 and run 'show >>> interface status' nothing is logged. However, after I 'enable' (typoed >> the password the first >>> time) and then run a 'do show interface status' then it is logged. I'm >> wondering why isn't my >>> 'show interface status' logged the first time. >>> >>> >>> ====tacacs accounting log==== >>> >>> Apr 14 10:30:46 192.168.1.126 luser tty2 192.168.1.76 >> start task_id=334 timezone=UTC >>> service=shell start_time=1397485846 Apr 14 10:31:01 192.168.1.126 luser tty2 >>> 192.168.1.76 >> stop task_id=334 timezone=UTC >>> service=shell start_time=1397485861 priv-lvl=0 cmd=enable Apr 14 10:31:07 >>> 192.168.1.126 luser tty2 192.168.1.76 >> stop task_id=335 timezone=UTC >>> service=shell start_time=1397485867 priv-lvl=0 cmd=enable Apr 14 10:31:12 >>> 192.168.1.126 luser tty2 192.168.1.76 >> stop task_id=336 timezone=UTC >>> service=shell start_time=1397485872 priv-lvl=15 cmd=configure >> terminal >>> Apr 14 10:31:16 192.168.1.126 luser tty2 192.168.1.76 >> stop task_id=337 timezone=UTC >>> service=shell start_time=1397485876 priv-lvl=15 cmd=do sho >> interface status >>> >>> >>> >>> >>> =======switch session===== $ ssh luser at 192.168.1.126 Password: >>> >>> Switch#show interface status >>> >>> Port Name Status Vlan Duplex Speed Type Gi0/1 this is >>> int 1 connected 1 a-full a-1000 >> 10/100/1000BaseTX >>> Gi0/2 notconnect 1 auto auto >> 10/100/1000BaseTX >>> Gi0/3 notconnect 1 auto auto >> 10/100/1000BaseTX >>> Gi0/4 notconnect 1 auto auto >> 10/100/1000BaseTX >>> Gi0/5 notconnect 1 auto auto >> 10/100/1000BaseTX >>> Gi0/6 notconnect 1 auto auto >> 10/100/1000BaseTX >>> Gi0/7 notconnect 1 auto auto >> 10/100/1000BaseTX >>> Gi0/8 connected 1 a-full a-1000 >> 10/100/1000BaseTX >>> Switch#conf t ^ % Invalid input detected at '^' marker. >>> >>> Switch#enable Password: % Error in authentication. >>> >>> Switch#enable Password: Switch#conf t Enter configuration commands, one per line. End with >>> CNTL/Z. Switch(config)#do sho interface status >>> >>> Port Name Status Vlan Duplex Speed Type Gi0/1 this is >>> int 1 connected 1 a-full a-1000 >> 10/100/1000BaseTX >>> Gi0/2 notconnect 1 auto auto >> 10/100/1000BaseTX >>> Gi0/3 notconnect 1 auto auto >> 10/100/1000BaseTX >>> Gi0/4 notconnect 1 auto auto >> 10/100/1000BaseTX >>> Gi0/5 notconnect 1 auto auto >> 10/100/1000BaseTX >>> Gi0/6 notconnect 1 auto auto >> 10/100/1000BaseTX >>> Gi0/7 notconnect 1 auto auto >> 10/100/1000BaseTX >>> Gi0/8 connected 1 a-full a-1000 >> 10/100/1000BaseTX >>> Switch(config)# >> >> >> If a command isn't being logged in the accounting logs it's because the router never sent it >> to the tacacs server to be logged; if the router does send it then tac_plus will log it. You >> can verify this by enabling accounting debugging, check the tac_plus man page for the -d >> option >> >> Examine closely your AAA settings on the router to see how accounting is set up there. >> >> -- Alan McKinnon alan.mckinnon at gmail.com >> >> _______________________________________________ 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: > > _______________________________________________ tac_plus mailing list tac_plus at shrubbery.net > http://www.shrubbery.net/mailman/listinfo/tac_plus > - -- Munroe Sollog LTS - Network Analyst x85002 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQEcBAEBAgAGBQJTTBpsAAoJEPbbZiWCKDVC7FsH+wZe+HujqupQrMhh1elrkjYN p44PRY1flIUw1Hi9htlD3zlgP+okSWCD3ixVzi3maTWaHo80Wvck6syJYmszLgv0 XJc3lRNgphgUMz4Ifaq1HCqTqzsmaAsIORl56SVkngFn83isxYrb2mfNilEW1k+n G0rYjBPSKidRjcsJzqS3I2/r6P1aHwjsApgDPLl1pfpSgFtjX/xmnNIkx6b7FCam 4haRLE4IHrLvoNtx5rOs3piuHSvBENTeUotsucePcsyhxxJS55jX1aUbD/r6rGz9 5JyW77GIrC2qJbOmVfV7Msh+f9hWF9/t/ui6dC6MvSRkJZY++fHffUw3mGnN/hs= =JjSo -----END PGP SIGNATURE----- From alan.mckinnon at gmail.com Mon Apr 14 19:29:12 2014 From: alan.mckinnon at gmail.com (Alan McKinnon) Date: Mon, 14 Apr 2014 21:29:12 +0200 Subject: [tac_plus] logging all commands run In-Reply-To: <534C1A6C.8080701@lehigh.edu> References: <534BDAB9.8040803@lehigh.edu> <534BF054.1080201@gmail.com> <534BF2EB.8020608@lehigh.edu> <534BF6D4.6050103@gmail.com> <534C1A6C.8080701@lehigh.edu> Message-ID: <534C3708.6010408@gmail.com> The problem with the priv-lvl approach is that it doesn't scale very well. For 1 or 2 or 3 network devices it's fine, especially when you consider that tac_plus command auth involves regular expressions; you avoid that using priv-lvls on the router. However, it quickly becomes cumbersome. You have to work out exactly what you want each level to have, and make sure all of them have the identical config. Without some kind of automated config-push system this quickly gets out of hand. Double so if each user gets a local account on the router. With tacacs auth, you do that heavy lifting once in one place. Yes, you do have think it through more carefully as you must apply regexes to strings to do your allow/deny (tac_plus being clueless as to what commands mean). Using a default-deny/explicit permit model you can keep yourself safe and your techs away from danger. Which method you use depends in my mind on how big and complex your network is, that's something only you can really decide. On 14/04/2014 19:27, Munroe Sollog wrote: > I think I figured it out. I had: > > aaa accounting commands 2 default start-stop group tacacs+ > aaa accounting commands 15 default start-stop group tacacs+ > > but when I added: > aaa accounting commands 1 default start-stop group tacacs+ > > all of the commands I noticed weren't being logged started showing up. > > With regard to your concern about custom priv levels, it was something I went back and forth on. > My current rationale is, I want the tac_config simple without having to enumerate dozens of > commands and their variants. For example, I wanted my lowest level techs to be able to run 'show > logging' which by default is a priv-15 command. When logged in at priv-1, even if I explicitly > allowed that command the switch wouldn't recognize it. That being the case, I would have to give > everyone priv-lvl 15 access and be extra careful to explicitly allow only the commands I want them > to run. That seems like a lot more work than moving 'show logging' down to a lower privilege > level and keeping the techs away from priv-lvl 15. > > But that is just my current rationale, if there is a better idea, I'm not married to it. > > - Munroe > > On 04/14/2014 01:16 PM, Daniel Schmidt wrote: >> Hint: aaa accounting commands .... > >> Not sure why you are using cutom priv levels rather than authorization > > >> On Mon, Apr 14, 2014 at 8:55 AM, Alan McKinnon wrote: > >>> On 14/04/2014 16:38, Munroe Sollog wrote: >>>> I am using accounting. The behavior though is a bit confusing to me. >>> For example, the user >>>> 'luser' has the following stanza in the tac_plus.conf: >>>> >>>> user = luser { default service = permit login = file /usr/local/etc/tac_passwd_file service >>>> = exec { priv-lvl = 2 } cmd = show { permit .* } } >>>> >>>> The following is an excerpt from the accounting log as well as the >>> actual switch session. As you >>>> can see the first time I try 'conf t' nothing is logged, when I am still >>> priv-lvl 2 and run 'show >>>> interface status' nothing is logged. However, after I 'enable' (typoed >>> the password the first >>>> time) and then run a 'do show interface status' then it is logged. I'm >>> wondering why isn't my >>>> 'show interface status' logged the first time. >>>> >>>> >>>> ====tacacs accounting log==== >>>> >>>> Apr 14 10:30:46 192.168.1.126 luser tty2 192.168.1.76 >>> start task_id=334 timezone=UTC >>>> service=shell start_time=1397485846 Apr 14 10:31:01 192.168.1.126 luser tty2 >>>> 192.168.1.76 >>> stop task_id=334 timezone=UTC >>>> service=shell start_time=1397485861 priv-lvl=0 cmd=enable Apr 14 10:31:07 >>>> 192.168.1.126 luser tty2 192.168.1.76 >>> stop task_id=335 timezone=UTC >>>> service=shell start_time=1397485867 priv-lvl=0 cmd=enable Apr 14 10:31:12 >>>> 192.168.1.126 luser tty2 192.168.1.76 >>> stop task_id=336 timezone=UTC >>>> service=shell start_time=1397485872 priv-lvl=15 cmd=configure >>> terminal >>>> Apr 14 10:31:16 192.168.1.126 luser tty2 192.168.1.76 >>> stop task_id=337 timezone=UTC >>>> service=shell start_time=1397485876 priv-lvl=15 cmd=do sho >>> interface status >>>> >>>> >>>> >>>> >>>> =======switch session===== $ ssh luser at 192.168.1.126 Password: >>>> >>>> Switch#show interface status >>>> >>>> Port Name Status Vlan Duplex Speed Type Gi0/1 this is >>>> int 1 connected 1 a-full a-1000 >>> 10/100/1000BaseTX >>>> Gi0/2 notconnect 1 auto auto >>> 10/100/1000BaseTX >>>> Gi0/3 notconnect 1 auto auto >>> 10/100/1000BaseTX >>>> Gi0/4 notconnect 1 auto auto >>> 10/100/1000BaseTX >>>> Gi0/5 notconnect 1 auto auto >>> 10/100/1000BaseTX >>>> Gi0/6 notconnect 1 auto auto >>> 10/100/1000BaseTX >>>> Gi0/7 notconnect 1 auto auto >>> 10/100/1000BaseTX >>>> Gi0/8 connected 1 a-full a-1000 >>> 10/100/1000BaseTX >>>> Switch#conf t ^ % Invalid input detected at '^' marker. >>>> >>>> Switch#enable Password: % Error in authentication. >>>> >>>> Switch#enable Password: Switch#conf t Enter configuration commands, one per line. End with >>>> CNTL/Z. Switch(config)#do sho interface status >>>> >>>> Port Name Status Vlan Duplex Speed Type Gi0/1 this is >>>> int 1 connected 1 a-full a-1000 >>> 10/100/1000BaseTX >>>> Gi0/2 notconnect 1 auto auto >>> 10/100/1000BaseTX >>>> Gi0/3 notconnect 1 auto auto >>> 10/100/1000BaseTX >>>> Gi0/4 notconnect 1 auto auto >>> 10/100/1000BaseTX >>>> Gi0/5 notconnect 1 auto auto >>> 10/100/1000BaseTX >>>> Gi0/6 notconnect 1 auto auto >>> 10/100/1000BaseTX >>>> Gi0/7 notconnect 1 auto auto >>> 10/100/1000BaseTX >>>> Gi0/8 connected 1 a-full a-1000 >>> 10/100/1000BaseTX >>>> Switch(config)# >>> >>> >>> If a command isn't being logged in the accounting logs it's because the router never sent it >>> to the tacacs server to be logged; if the router does send it then tac_plus will log it. You >>> can verify this by enabling accounting debugging, check the tac_plus man page for the -d >>> option >>> >>> Examine closely your AAA settings on the router to see how accounting is set up there. >>> >>> -- Alan McKinnon alan.mckinnon at gmail.com >>> >>> _______________________________________________ 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: >> >> _______________________________________________ tac_plus mailing list tac_plus at shrubbery.net >> http://www.shrubbery.net/mailman/listinfo/tac_plus > > > _______________________________________________ > 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 Wed Apr 16 14:47:06 2014 From: lslater at yorku.ca (Linda Slater) Date: Wed, 16 Apr 2014 10:47:06 -0400 Subject: [tac_plus] TACPLUS AD Authentication Message-ID: Couple questions: I am using PAM_LDAP to authenticate our users via AD. The additional requirements are now: 1. No usernames in the Tac+ config file, I will define only groups and use AD groupings to decide if that user can be allowed to access a network device. Does anyone have any examples using this method? Currently, I have the user name ...... login = PAM, listed in the tac...config file. 2. Each user that logins into the Network device, must use their AD password to gain enable access to the network device. Is anyone using this method to allow users enable access, given that the Tac+ enable password cannot be pointed to PAM? Each user will have using their own AD login credentials. Regards, 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 daniel.schmidt at wyo.gov Wed Apr 16 14:54:39 2014 From: daniel.schmidt at wyo.gov (Daniel Schmidt) Date: Wed, 16 Apr 2014 08:54:39 -0600 Subject: [tac_plus] TACPLUS AD Authentication In-Reply-To: References: Message-ID: I guess that would work if you wanted EVERY ad user to have access. Full access, at that. If you priv_15 everybody, they shouldn't need an enable password. Doesn't seem 2 work 4 the ASA though. Give everybody one generic enable password maybe. On Wed, Apr 16, 2014 at 8:47 AM, Linda Slater wrote: > Couple questions: > > I am using PAM_LDAP to authenticate our users via AD. The additional > requirements are now: > > > > 1. No usernames in the Tac+ config file, I will define only groups and use > AD groupings to decide if that user can be allowed to access a network > device. Does anyone have any examples using this method? Currently, I > have the user name ...... login = PAM, listed in the tac...config file. > > 2. Each user that logins into the Network device, must use their AD > password to gain enable access to the network device. Is anyone using > this method to allow users enable access, given that the Tac+ enable > password cannot be pointed to PAM? Each user will have using their own > AD login credentials. > > > Regards, > 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/20140416/89ba12d8/attachment.html > > > _______________________________________________ > 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 lslater at yorku.ca Wed Apr 16 17:08:40 2014 From: lslater at yorku.ca (Linda Slater) Date: Wed, 16 Apr 2014 13:08:40 -0400 Subject: [tac_plus] TACPLUS AD Authentication In-Reply-To: References: Message-ID: The idea is the user will still need to enable up but instead of using a generic password , they will use their AD password. I am not sure if , I need to script that information in LDAP.conf /AD or somehow utilise the PAM module. Still learning the capabilities of LDAP and PAM. Linda From: Daniel Schmidt To: Linda Slater , Cc: "tac_plus at shrubbery.net" Date: 2014/04/16 10:54 AM Subject: Re: [tac_plus] TACPLUS AD Authentication I guess that would work if you wanted EVERY ad user to have access. Full access, at that. If you priv_15 everybody, they shouldn't need an enable password. Doesn't seem 2 work 4 the ASA though. Give everybody one generic enable password maybe. On Wed, Apr 16, 2014 at 8:47 AM, Linda Slater wrote: Couple questions: I am using PAM_LDAP to authenticate our users via AD. The additional requirements are now: 1. No usernames in the Tac+ config file, I will define only groups and use AD groupings to decide if that user can be allowed to access a network device. Does anyone have any examples using this method? Currently, I have the user name ...... login = PAM, listed in the tac...config file. 2. Each user that logins into the Network device, must use their AD password to gain enable access to the network device. Is anyone using this method to allow users enable access, given that the Tac+ enable password cannot be pointed to PAM? Each user will have using their own AD login credentials. -------------- next part -------------- An HTML attachment was scrubbed... URL: < http://www.shrubbery.net/pipermail/tac_plus/attachments/20140416/89ba12d8/attachment.html > _______________________________________________ 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 vadud3 at gmail.com Fri Apr 18 17:52:26 2014 From: vadud3 at gmail.com (Asif Iqbal) Date: Fri, 18 Apr 2014 13:52:26 -0400 Subject: [tac_plus] tacacs+-F5.0.0a1 make fails Message-ID: Hi All, I am failing to compile tacacs+-F5.0.0a1. ~/src/tacacs+-F5.0.0a1$ make /usr/bin/make all-am make[1]: Entering directory `/home/iqbala/src/tacacs+-F5.0.0a1' gcc -DHAVE_CONFIG_H -I. -I/usr/local/include -g -O2 -pthread -MT maxsessint.o -MD -MP -MF .deps/maxsessint.Tpo -c -o maxsessint.o maxsessint.c maxsessint.c: In function ?maxsess_check_count?: maxsessint.c:60:51: error: ?S_maxsess? undeclared (first use in this function) maxsess = cfg_get_intvalue(user, TAC_IS_USER, S_maxsess, TAC_PLUS_RECURSE); ^ maxsessint.c:60:51: note: each undeclared identifier is reported only once for each function it appears in make[1]: *** [maxsessint.o] Error 1 make[1]: Leaving directory `/home/iqbala/src/tacacs+-F5.0.0a1' make: *** [all] Error 2 There is no issue with compiling tacacs+-F4.0.4.27a. Is there a workaround? I am using ubuntu 14.04 64bit LTS Thanks -- 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 alan.mckinnon at gmail.com Sat Apr 19 00:14:00 2014 From: alan.mckinnon at gmail.com (Alan McKinnon) Date: Sat, 19 Apr 2014 02:14:00 +0200 Subject: [tac_plus] tacacs+-F5.0.0a1 make fails In-Reply-To: References: Message-ID: <5351BFC8.9040009@gmail.com> On 18/04/2014 19:52, Asif Iqbal wrote: > Hi All, > > I am failing to compile tacacs+-F5.0.0a1. > > ~/src/tacacs+-F5.0.0a1$ make > /usr/bin/make all-am > make[1]: Entering directory `/home/iqbala/src/tacacs+-F5.0.0a1' > gcc -DHAVE_CONFIG_H -I. -I/usr/local/include -g -O2 -pthread -MT > maxsessint.o -MD -MP -MF .deps/maxsessint.Tpo -c -o maxsessint.o > maxsessint.c > maxsessint.c: In function ?maxsess_check_count?: > maxsessint.c:60:51: error: ?S_maxsess? undeclared (first use in this > function) > maxsess = cfg_get_intvalue(user, TAC_IS_USER, S_maxsess, > TAC_PLUS_RECURSE); > ^ > maxsessint.c:60:51: note: each undeclared identifier is reported only once > for each function it appears in > make[1]: *** [maxsessint.o] Error 1 > make[1]: Leaving directory `/home/iqbala/src/tacacs+-F5.0.0a1' > make: *** [all] Error 2 > > > There is no issue with compiling tacacs+-F4.0.4.27a. > > Is there a workaround? > > I am using ubuntu 14.04 64bit LTS > > Thanks > 5.0.0a1 is very alpha and not fit for use at all. There are no guarantees it will build or do anything useful, as you have discovered. You must use the 4.0.4.x series; that one works reading between the lines in this list over the years, that branch is something john was fooling around with once long ago. I'm not entirely sure why it made it to a bundled tarball, it's at that point in it's life cycle where it should still be in a code repo only. -- Alan McKinnon alan.mckinnon at gmail.com From matt.addison at lists.evilgeni.us Fri Apr 25 18:06:00 2014 From: matt.addison at lists.evilgeni.us (Matt Addison) Date: Fri, 25 Apr 2014 14:06:00 -0400 Subject: [tac_plus] TACPLUS AD Authentication In-Reply-To: References: Message-ID: On Wed, Apr 16, 2014 at 10:47 AM, Linda Slater wrote: > Couple questions: > > I am using PAM_LDAP to authenticate our users via AD. The additional > requirements are now: > > > > 1. No usernames in the Tac+ config file, I will define only groups and use > AD groupings to decide if that user can be allowed to access a network > device. Does anyone have any examples using this method? Currently, I > have the user name ...... login = PAM, listed in the tac...config file. > > 2. Each user that logins into the Network device, must use their AD > password to gain enable access to the network device. Is anyone using > this method to allow users enable access, given that the Tac+ enable > password cannot be pointed to PAM? Each user will have using their own > AD login credentials. > There's a patch for that. https://gist.github.com/ragzilla/11297928 Allows for enable to be pointed to PAM, and also for DEFAULT user attributes to be used (such as login/enable) if there's no specific user. Planning to use this in my environment with do_auth (and a patch for that, to allow for pulling in NSS groups) so that the tac_plus.conf only has to have a default user and service accounts. Ideally you'd have 2 separate auth mechanisms for login/enable though (in our case we're using aceclnt for login, and PAM for enable). ~Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: