From daniel.schmidt at wyo.gov Mon Oct 3 15:34:45 2011 From: daniel.schmidt at wyo.gov (Daniel Schmidt) Date: Mon, 3 Oct 2011 09:34:45 -0600 Subject: [tac_plus] Configuring a/v pair expected by Brocade VDX switch In-Reply-To: <20110930234326.278f529d@rohan.example.com> References: <20110930205948.GV9227@shrubbery.net> <20110930234326.278f529d@rohan.example.com> Message-ID: I've never had this trouble you speak of with Brocade, but then again I have only used the CER, CES & FCX. The config I posed on tacacs.org seemed to work fine. Also, users CAN be members of multiple groups, you just have to write an authorization script. Or, just use my do_auth.py script from tacacs.org - several people have told me it works well. Tac_plus, I would argue, is more flexible than Cisco's solution. I'm working on key replacement with do_auth - what is your issue with Nexus? As for brcd-role, if you are willing to do try do_auth and turn on the debug, I should easily be able to add something for a certain IP range that strips the pairs you don't want and appends the pairs you do. -----Original Message----- From: tac_plus-bounces at shrubbery.net [mailto:tac_plus-bounces at shrubbery.net] On Behalf Of Alan McKinnon Sent: Friday, September 30, 2011 3:43 PM To: tac_plus at shrubbery.net Subject: Re: [tac_plus] Configuring a/v pair expected by Brocade VDX switch On Fri, 30 Sep 2011 14:14:03 -0700 Jathan McCollum wrote: > Hey John, thanks for the reply. That's a good suggestion that I'll > tuck away for future reference. > > I actually tracked down access to the Brocade support knowledge base > and found a document someone had posted using Cisco ASA. > > And it is: > > brcd-role = > > So my group config would be: > > group = admin { > default service = permit > service = exec { > priv-lvl = 15 > brcd-role = admin > } > } > > However, sharing that with Cisco devices causes them to be unhappy > and fail authorization. I tried prepending the "optional" keyword > e.g. "optional brcd-role = admin", which makes Cisco devices happy > again, but breaks it on the Brocade. > > So... almost there, but still missing something. Hi Jathan, I had a very similar issue getting my Cisco and Nexus kit to work together. Short answer is I couldn't get them to work together. The solution I opted for was to run two instances of tac_plus, the original on port 49 for Cisco and the second on port 50 for Nexus, and keep the configs entirely separate. This works for me and is probably more intuitive than trying to express the same thing in a single config file. One of the shortcomings of tac_plus in it's current form is how inflexible it can be. Users can be a member of only one group, which is a member of only one group etc. Freeradius has a concept of "vhosts" which would be insanely useful on tac_plus, but there is no comparable feature. You seem to have run into this. I'm not complaining (for the asking price of free tac_plus is a great product) and until I start submitting patches I have very little street-cred. In the meantime I accept that sometimes we have to do things in unusual ways (like run two daemons) to get what we want. > > On Fri, Sep 30, 2011 at 1:59 PM, john heasley > wrote: > > > Fri, Sep 30, 2011 at 01:39:32PM -0700, Jathan McCollum: > > > The documentation indicates the device is expecting the server to > > > send an a/v pair that specifies the authenticated user's role. I > > > assume the value would be "admin" in this case. The problem is > > > that nowhere in the documentation so far have I seen what > > > attribute the device is expecting. There may also be a unique > > > service type (again similar to JUNOS' "junos-exec") that is being > > > expected. > > > > > > So... After all that background, anyone had experience with this > > > platform and gotten it working successfully w/ tac_plus? > > > > none, but some devices send the av pairs they have when they perform > > authen and/or author. if you enable the appropriate debugging > > knobs, it might reveal it to you. > > > > or, take the image that you load on the box, uncompress it, unzip > > it or whatever their packaging method is, then run strings(1) on it > > and look for strings that might be related to authorization. then > > send a bomb to brocade offices. > > > > > -- Alan McKinnnon alan.mckinnon at gmail.com _______________________________________________ tac_plus mailing list tac_plus at shrubbery.net http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus From jathan at gmail.com Mon Oct 3 16:03:34 2011 From: jathan at gmail.com (Jathan McCollum) Date: Mon, 3 Oct 2011 09:03:34 -0700 Subject: [tac_plus] Configuring a/v pair expected by Brocade VDX switch In-Reply-To: References: <20110930205948.GV9227@shrubbery.net> <20110930234326.278f529d@rohan.example.com> Message-ID: Thanks Dan, I will give do_auth a shot in the lab and report back sometime between that time and eterinity. :) On Mon, Oct 3, 2011 at 8:34 AM, Daniel Schmidt wrote: > I've never had this trouble you speak of with Brocade, but then again I > have only used the CER, CES & FCX. The config I posed on tacacs.org > seemed to work fine. > > Also, users CAN be members of multiple groups, you just have to write an > authorization script. Or, just use my do_auth.py script from tacacs.org - > several people have told me it works well. Tac_plus, I would argue, is > more flexible than Cisco's solution. > > I'm working on key replacement with do_auth - what is your issue with > Nexus? As for brcd-role, if you are willing to do try do_auth and turn on > the debug, I should easily be able to add something for a certain IP range > that strips the pairs you don't want and appends the pairs you do. > > -----Original Message----- > From: tac_plus-bounces at shrubbery.net > [mailto:tac_plus-bounces at shrubbery.net] On Behalf Of Alan McKinnon > Sent: Friday, September 30, 2011 3:43 PM > To: tac_plus at shrubbery.net > Subject: Re: [tac_plus] Configuring a/v pair expected by Brocade VDX > switch > > On Fri, 30 Sep 2011 14:14:03 -0700 > Jathan McCollum wrote: > > > Hey John, thanks for the reply. That's a good suggestion that I'll > > tuck away for future reference. > > > > I actually tracked down access to the Brocade support knowledge base > > and found a document someone had posted using Cisco ASA. > > > > And it is: > > > > brcd-role = > > > > So my group config would be: > > > > group = admin { > > default service = permit > > service = exec { > > priv-lvl = 15 > > brcd-role = admin > > } > > } > > > > However, sharing that with Cisco devices causes them to be unhappy > > and fail authorization. I tried prepending the "optional" keyword > > e.g. "optional brcd-role = admin", which makes Cisco devices happy > > again, but breaks it on the Brocade. > > > > So... almost there, but still missing something. > > > Hi Jathan, > > I had a very similar issue getting my Cisco and Nexus kit to work > together. Short answer is I couldn't get them to work together. > > The solution I opted for was to run two instances of tac_plus, the > original on port 49 for Cisco and the second on port 50 for Nexus, and > keep the configs entirely separate. This works for me and is probably > more intuitive than trying to express the same thing in a single config > file. > > One of the shortcomings of tac_plus in it's current form is how > inflexible it can be. Users can be a member of only one group, which is > a member of only one group etc. Freeradius has a concept of "vhosts" > which would be insanely useful on tac_plus, but there is no comparable > feature. You seem to have run into this. > > I'm not complaining (for the asking price of free tac_plus is a great > product) and until I start submitting patches I have very little > street-cred. In the meantime I accept that sometimes we have to do > things in unusual ways (like run two daemons) to get what we want. > > > > > > > On Fri, Sep 30, 2011 at 1:59 PM, john heasley > > wrote: > > > > > Fri, Sep 30, 2011 at 01:39:32PM -0700, Jathan McCollum: > > > > The documentation indicates the device is expecting the server to > > > > send an a/v pair that specifies the authenticated user's role. I > > > > assume the value would be "admin" in this case. The problem is > > > > that nowhere in the documentation so far have I seen what > > > > attribute the device is expecting. There may also be a unique > > > > service type (again similar to JUNOS' "junos-exec") that is being > > > > expected. > > > > > > > > So... After all that background, anyone had experience with this > > > > platform and gotten it working successfully w/ tac_plus? > > > > > > none, but some devices send the av pairs they have when they perform > > > authen and/or author. if you enable the appropriate debugging > > > knobs, it might reveal it to you. > > > > > > or, take the image that you load on the box, uncompress it, unzip > > > it or whatever their packaging method is, then run strings(1) on it > > > and look for strings that might be related to authorization. then > > > send a bomb to brocade offices. > > > > > > > > > > > > > -- > Alan McKinnnon > alan.mckinnon at gmail.com > _______________________________________________ > tac_plus mailing list > tac_plus at shrubbery.net > http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus > _______________________________________________ > tac_plus mailing list > tac_plus at shrubbery.net > http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus > -- Jathan. -- -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.schmidt at wyo.gov Mon Oct 3 16:46:48 2011 From: daniel.schmidt at wyo.gov (Daniel Schmidt) Date: Mon, 3 Oct 2011 10:46:48 -0600 Subject: [tac_plus] Configuring a/v pair expected by Brocade VDX switch In-Reply-To: References: <20110930205948.GV9227@shrubbery.net> <20110930234326.278f529d@rohan.example.com> Message-ID: <7c8167e91e92471e33d4f53ff3d68bcd@mail.gmail.com> U don?t even need a lab, just add a new user and a new group to your tac_plus.conf. Leave your existing users alone and it?s completely safe. Anybody else having issues with Nexus & tac_plus? *From:* Jathan McCollum [mailto:jathan at gmail.com] *Sent:* Monday, October 03, 2011 10:04 AM *To:* Daniel Schmidt *Cc:* Alan McKinnon; tac_plus at shrubbery.net *Subject:* Re: [tac_plus] Configuring a/v pair expected by Brocade VDX switch Thanks Dan, I will give do_auth a shot in the lab and report back sometime between that time and eterinity. :) On Mon, Oct 3, 2011 at 8:34 AM, Daniel Schmidt wrote: I've never had this trouble you speak of with Brocade, but then again I have only used the CER, CES & FCX. The config I posed on tacacs.org seemed to work fine. Also, users CAN be members of multiple groups, you just have to write an authorization script. Or, just use my do_auth.py script from tacacs.org - several people have told me it works well. Tac_plus, I would argue, is more flexible than Cisco's solution. I'm working on key replacement with do_auth - what is your issue with Nexus? As for brcd-role, if you are willing to do try do_auth and turn on the debug, I should easily be able to add something for a certain IP range that strips the pairs you don't want and appends the pairs you do. -----Original Message----- From: tac_plus-bounces at shrubbery.net [mailto:tac_plus-bounces at shrubbery.net] On Behalf Of Alan McKinnon Sent: Friday, September 30, 2011 3:43 PM To: tac_plus at shrubbery.net Subject: Re: [tac_plus] Configuring a/v pair expected by Brocade VDX switch On Fri, 30 Sep 2011 14:14:03 -0700 Jathan McCollum wrote: > Hey John, thanks for the reply. That's a good suggestion that I'll > tuck away for future reference. > > I actually tracked down access to the Brocade support knowledge base > and found a document someone had posted using Cisco ASA. > > And it is: > > brcd-role = > > So my group config would be: > > group = admin { > default service = permit > service = exec { > priv-lvl = 15 > brcd-role = admin > } > } > > However, sharing that with Cisco devices causes them to be unhappy > and fail authorization. I tried prepending the "optional" keyword > e.g. "optional brcd-role = admin", which makes Cisco devices happy > again, but breaks it on the Brocade. > > So... almost there, but still missing something. Hi Jathan, I had a very similar issue getting my Cisco and Nexus kit to work together. Short answer is I couldn't get them to work together. The solution I opted for was to run two instances of tac_plus, the original on port 49 for Cisco and the second on port 50 for Nexus, and keep the configs entirely separate. This works for me and is probably more intuitive than trying to express the same thing in a single config file. One of the shortcomings of tac_plus in it's current form is how inflexible it can be. Users can be a member of only one group, which is a member of only one group etc. Freeradius has a concept of "vhosts" which would be insanely useful on tac_plus, but there is no comparable feature. You seem to have run into this. I'm not complaining (for the asking price of free tac_plus is a great product) and until I start submitting patches I have very little street-cred. In the meantime I accept that sometimes we have to do things in unusual ways (like run two daemons) to get what we want. > > On Fri, Sep 30, 2011 at 1:59 PM, john heasley > wrote: > > > Fri, Sep 30, 2011 at 01:39:32PM -0700, Jathan McCollum: > > > The documentation indicates the device is expecting the server to > > > send an a/v pair that specifies the authenticated user's role. I > > > assume the value would be "admin" in this case. The problem is > > > that nowhere in the documentation so far have I seen what > > > attribute the device is expecting. There may also be a unique > > > service type (again similar to JUNOS' "junos-exec") that is being > > > expected. > > > > > > So... After all that background, anyone had experience with this > > > platform and gotten it working successfully w/ tac_plus? > > > > none, but some devices send the av pairs they have when they perform > > authen and/or author. if you enable the appropriate debugging > > knobs, it might reveal it to you. > > > > or, take the image that you load on the box, uncompress it, unzip > > it or whatever their packaging method is, then run strings(1) on it > > and look for strings that might be related to authorization. then > > send a bomb to brocade offices. > > > > > -- Alan McKinnnon alan.mckinnon at gmail.com _______________________________________________ tac_plus mailing list tac_plus at shrubbery.net http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus _______________________________________________ tac_plus mailing list tac_plus at shrubbery.net http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus -- Jathan. -- -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.mckinnon at gmail.com Mon Oct 3 18:12:25 2011 From: alan.mckinnon at gmail.com (Alan McKinnon) Date: Mon, 3 Oct 2011 20:12:25 +0200 Subject: [tac_plus] Configuring a/v pair expected by Brocade VDX switch In-Reply-To: References: <20110930205948.GV9227@shrubbery.net> <20110930234326.278f529d@rohan.example.com> Message-ID: <20111003201225.2d80eeb0@rohan.example.com> On Mon, 3 Oct 2011 09:34:45 -0600 Daniel Schmidt wrote: > I've never had this trouble you speak of with Brocade, but then again > I have only used the CER, CES & FCX. The config I posed on tacacs.org > seemed to work fine. > > Also, users CAN be members of multiple groups, you just have to write > an authorization script. Or, just use my do_auth.py script from > tacacs.org - several people have told me it works well. Tac_plus, I > would argue, is more flexible than Cisco's solution. Hi Daniel, Yes, I'm aware of your script but I'm not willing to risk deploying it. Nothing to do with code quality you understand, I'm getting 1.5 million connections a day on a slow day and the only place I can test that for real is in production. My Change Manager would murder me if anything went wrong and I can't begin to calculate if I can cope with 50-75 python scripts spawned a second when things get busy. And that's just the PE devices. There's a completely separate system for CE devices (the current bane of my life...) > I'm working on key replacement with do_auth - what is your issue with > Nexus? As for brcd-role, if you are willing to do try do_auth and > turn on the debug, I should easily be able to add something for a > certain IP range that strips the pairs you don't want and appends the > pairs you do. The main issue with Nexus is that Tacacs support is not mature on those devices (5k & 7k), there are just too many edge cases and too many open support cases with Cisco from our NetOps guys about them. As a device, the 5k's work great, we just couldn't get them to co-exist on the same tac_plus daemon with our wildly wonderful RealWorld(tm) Cisco network. Some days I feel we have at least one of every piece of hardware and software version Cisco ever shipped live on the network needing to be supported. IIRC correctly, the thing that truly made NetOps give up was "conf t" - our Support guys must have it to get work done on Cisco and must not be able to use it on Nexus otherwise things break badly. We settled for local roles on the nexus devices and doing authentication and accounting on tacacs. This works well for us and the config can be reasonably easily understood by both teams (Services and NetOps). I see little scope to use your script in my setup due to size and complexity, but please don't stop developing on it. I'm sure the vast majority of readers here would find it very useful indeed. > > -----Original Message----- > From: tac_plus-bounces at shrubbery.net > [mailto:tac_plus-bounces at shrubbery.net] On Behalf Of Alan McKinnon > Sent: Friday, September 30, 2011 3:43 PM > To: tac_plus at shrubbery.net > Subject: Re: [tac_plus] Configuring a/v pair expected by Brocade VDX > switch > > On Fri, 30 Sep 2011 14:14:03 -0700 > Jathan McCollum wrote: > > > Hey John, thanks for the reply. That's a good suggestion that I'll > > tuck away for future reference. > > > > I actually tracked down access to the Brocade support knowledge base > > and found a document someone had posted using Cisco ASA. > > > > And it is: > > > > brcd-role = > > > > So my group config would be: > > > > group = admin { > > default service = permit > > service = exec { > > priv-lvl = 15 > > brcd-role = admin > > } > > } > > > > However, sharing that with Cisco devices causes them to be unhappy > > and fail authorization. I tried prepending the "optional" keyword > > e.g. "optional brcd-role = admin", which makes Cisco devices happy > > again, but breaks it on the Brocade. > > > > So... almost there, but still missing something. > > > Hi Jathan, > > I had a very similar issue getting my Cisco and Nexus kit to work > together. Short answer is I couldn't get them to work together. > > The solution I opted for was to run two instances of tac_plus, the > original on port 49 for Cisco and the second on port 50 for Nexus, and > keep the configs entirely separate. This works for me and is probably > more intuitive than trying to express the same thing in a single > config file. > > One of the shortcomings of tac_plus in it's current form is how > inflexible it can be. Users can be a member of only one group, which > is a member of only one group etc. Freeradius has a concept of > "vhosts" which would be insanely useful on tac_plus, but there is no > comparable feature. You seem to have run into this. > > I'm not complaining (for the asking price of free tac_plus is a great > product) and until I start submitting patches I have very little > street-cred. In the meantime I accept that sometimes we have to do > things in unusual ways (like run two daemons) to get what we want. > > > > > > > On Fri, Sep 30, 2011 at 1:59 PM, john heasley > > wrote: > > > > > Fri, Sep 30, 2011 at 01:39:32PM -0700, Jathan McCollum: > > > > The documentation indicates the device is expecting the server > > > > to send an a/v pair that specifies the authenticated user's > > > > role. I assume the value would be "admin" in this case. The > > > > problem is that nowhere in the documentation so far have I seen > > > > what attribute the device is expecting. There may also be a > > > > unique service type (again similar to JUNOS' "junos-exec") that > > > > is being expected. > > > > > > > > So... After all that background, anyone had experience with this > > > > platform and gotten it working successfully w/ tac_plus? > > > > > > none, but some devices send the av pairs they have when they > > > perform authen and/or author. if you enable the appropriate > > > debugging knobs, it might reveal it to you. > > > > > > or, take the image that you load on the box, uncompress it, unzip > > > it or whatever their packaging method is, then run strings(1) on > > > it and look for strings that might be related to authorization. > > > then send a bomb to brocade offices. > > > > > > > > > > > > -- Alan McKinnnon alan.mckinnon at gmail.com From daniel.schmidt at wyo.gov Mon Oct 3 20:45:39 2011 From: daniel.schmidt at wyo.gov (Daniel Schmidt) Date: Mon, 3 Oct 2011 14:45:39 -0600 Subject: [tac_plus] Configuring a/v pair expected by Brocade VDX switch In-Reply-To: <20111003201225.2d80eeb0@rohan.example.com> References: <20110930205948.GV9227@shrubbery.net> <20110930234326.278f529d@rohan.example.com> <20111003201225.2d80eeb0@rohan.example.com> Message-ID: <1787a48a889e73c3b544f21cd05459d7@mail.gmail.com> A test user & new group would not interfere with any current operation and the compiled python code runs quite fast. I would imagine it could be exactly what you need. However, I suppose we all understand the "It works, don't touch it!" mentality. I suppose I will have to get some 5000's up & running to test with. -----Original Message----- From: tac_plus-bounces at shrubbery.net [mailto:tac_plus-bounces at shrubbery.net] On Behalf Of Alan McKinnon Sent: Monday, October 03, 2011 12:12 PM Cc: tac_plus at shrubbery.net Subject: Re: [tac_plus] Configuring a/v pair expected by Brocade VDX switch On Mon, 3 Oct 2011 09:34:45 -0600 Daniel Schmidt wrote: > I've never had this trouble you speak of with Brocade, but then again > I have only used the CER, CES & FCX. The config I posed on tacacs.org > seemed to work fine. > > Also, users CAN be members of multiple groups, you just have to write > an authorization script. Or, just use my do_auth.py script from > tacacs.org - several people have told me it works well. Tac_plus, I > would argue, is more flexible than Cisco's solution. Hi Daniel, Yes, I'm aware of your script but I'm not willing to risk deploying it. Nothing to do with code quality you understand, I'm getting 1.5 million connections a day on a slow day and the only place I can test that for real is in production. My Change Manager would murder me if anything went wrong and I can't begin to calculate if I can cope with 50-75 python scripts spawned a second when things get busy. And that's just the PE devices. There's a completely separate system for CE devices (the current bane of my life...) > I'm working on key replacement with do_auth - what is your issue with > Nexus? As for brcd-role, if you are willing to do try do_auth and > turn on the debug, I should easily be able to add something for a > certain IP range that strips the pairs you don't want and appends the > pairs you do. The main issue with Nexus is that Tacacs support is not mature on those devices (5k & 7k), there are just too many edge cases and too many open support cases with Cisco from our NetOps guys about them. As a device, the 5k's work great, we just couldn't get them to co-exist on the same tac_plus daemon with our wildly wonderful RealWorld(tm) Cisco network. Some days I feel we have at least one of every piece of hardware and software version Cisco ever shipped live on the network needing to be supported. IIRC correctly, the thing that truly made NetOps give up was "conf t" - our Support guys must have it to get work done on Cisco and must not be able to use it on Nexus otherwise things break badly. We settled for local roles on the nexus devices and doing authentication and accounting on tacacs. This works well for us and the config can be reasonably easily understood by both teams (Services and NetOps). I see little scope to use your script in my setup due to size and complexity, but please don't stop developing on it. I'm sure the vast majority of readers here would find it very useful indeed. > > -----Original Message----- > From: tac_plus-bounces at shrubbery.net > [mailto:tac_plus-bounces at shrubbery.net] On Behalf Of Alan McKinnon > Sent: Friday, September 30, 2011 3:43 PM > To: tac_plus at shrubbery.net > Subject: Re: [tac_plus] Configuring a/v pair expected by Brocade VDX > switch > > On Fri, 30 Sep 2011 14:14:03 -0700 > Jathan McCollum wrote: > > > Hey John, thanks for the reply. That's a good suggestion that I'll > > tuck away for future reference. > > > > I actually tracked down access to the Brocade support knowledge base > > and found a document someone had posted using Cisco ASA. > > > > And it is: > > > > brcd-role = > > > > So my group config would be: > > > > group = admin { > > default service = permit > > service = exec { > > priv-lvl = 15 > > brcd-role = admin > > } > > } > > > > However, sharing that with Cisco devices causes them to be unhappy > > and fail authorization. I tried prepending the "optional" keyword > > e.g. "optional brcd-role = admin", which makes Cisco devices happy > > again, but breaks it on the Brocade. > > > > So... almost there, but still missing something. > > > Hi Jathan, > > I had a very similar issue getting my Cisco and Nexus kit to work > together. Short answer is I couldn't get them to work together. > > The solution I opted for was to run two instances of tac_plus, the > original on port 49 for Cisco and the second on port 50 for Nexus, and > keep the configs entirely separate. This works for me and is probably > more intuitive than trying to express the same thing in a single > config file. > > One of the shortcomings of tac_plus in it's current form is how > inflexible it can be. Users can be a member of only one group, which > is a member of only one group etc. Freeradius has a concept of > "vhosts" which would be insanely useful on tac_plus, but there is no > comparable feature. You seem to have run into this. > > I'm not complaining (for the asking price of free tac_plus is a great > product) and until I start submitting patches I have very little > street-cred. In the meantime I accept that sometimes we have to do > things in unusual ways (like run two daemons) to get what we want. > > > > > > > On Fri, Sep 30, 2011 at 1:59 PM, john heasley > > wrote: > > > > > Fri, Sep 30, 2011 at 01:39:32PM -0700, Jathan McCollum: > > > > The documentation indicates the device is expecting the server > > > > to send an a/v pair that specifies the authenticated user's > > > > role. I assume the value would be "admin" in this case. The > > > > problem is that nowhere in the documentation so far have I seen > > > > what attribute the device is expecting. There may also be a > > > > unique service type (again similar to JUNOS' "junos-exec") that > > > > is being expected. > > > > > > > > So... After all that background, anyone had experience with this > > > > platform and gotten it working successfully w/ tac_plus? > > > > > > none, but some devices send the av pairs they have when they > > > perform authen and/or author. if you enable the appropriate > > > debugging knobs, it might reveal it to you. > > > > > > or, take the image that you load on the box, uncompress it, unzip > > > it or whatever their packaging method is, then run strings(1) on > > > it and look for strings that might be related to authorization. > > > then send a bomb to brocade offices. > > > > > > > > > > > > -- Alan McKinnnon alan.mckinnon at gmail.com _______________________________________________ tac_plus mailing list tac_plus at shrubbery.net http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus From jathan at gmail.com Tue Oct 4 13:59:09 2011 From: jathan at gmail.com (Jathan McCollum) Date: Tue, 4 Oct 2011 06:59:09 -0700 Subject: [tac_plus] Configuring a/v pair expected by Brocade VDX switch In-Reply-To: <1787a48a889e73c3b544f21cd05459d7@mail.gmail.com> References: <20110930205948.GV9227@shrubbery.net> <20110930234326.278f529d@rohan.example.com> <20111003201225.2d80eeb0@rohan.example.com> <1787a48a889e73c3b544f21cd05459d7@mail.gmail.com> Message-ID: My environment sounds eerily similar to Alan's. My only real means of testing are in the lab just for the mere sake of deployment. The lab requires no deployment and if it goes down or breaks for any reason, only the lab gremlins notice. Especially as I'm also a big nut for Python, I definitely want to try it out. Sooner than later. On Mon, Oct 3, 2011 at 1:45 PM, Daniel Schmidt wrote: > A test user & new group would not interfere with any current operation and > the compiled python code runs quite fast. I would imagine it could be > exactly what you need. However, I suppose we all understand the "It > works, don't touch it!" mentality. I suppose I will have to get some > 5000's up & running to test with. > > -----Original Message----- > From: tac_plus-bounces at shrubbery.net > [mailto:tac_plus-bounces at shrubbery.net] On Behalf Of Alan McKinnon > Sent: Monday, October 03, 2011 12:12 PM > Cc: tac_plus at shrubbery.net > Subject: Re: [tac_plus] Configuring a/v pair expected by Brocade VDX > switch > > On Mon, 3 Oct 2011 09:34:45 -0600 > Daniel Schmidt wrote: > > > I've never had this trouble you speak of with Brocade, but then again > > I have only used the CER, CES & FCX. The config I posed on tacacs.org > > seemed to work fine. > > > > Also, users CAN be members of multiple groups, you just have to write > > an authorization script. Or, just use my do_auth.py script from > > tacacs.org - several people have told me it works well. Tac_plus, I > > would argue, is more flexible than Cisco's solution. > > Hi Daniel, > > Yes, I'm aware of your script but I'm not willing to risk deploying it. > Nothing to do with code quality you understand, I'm getting 1.5 million > connections a day on a slow day and the only place I can test that for > real is in production. My Change Manager would murder me if anything > went wrong and I can't begin to calculate if I can cope with 50-75 > python scripts spawned a second when things get busy. > > And that's just the PE devices. There's a completely separate system > for CE devices (the current bane of my life...) > > > I'm working on key replacement with do_auth - what is your issue with > > Nexus? As for brcd-role, if you are willing to do try do_auth and > > turn on the debug, I should easily be able to add something for a > > certain IP range that strips the pairs you don't want and appends the > > pairs you do. > > The main issue with Nexus is that Tacacs support is not mature on those > devices (5k & 7k), there are just too many edge cases and too many open > support cases with Cisco from our NetOps guys about them. > > As a device, the 5k's work great, we just couldn't get them to co-exist > on the same tac_plus daemon with our wildly wonderful RealWorld(tm) > Cisco network. Some days I feel we have at least one of every piece of > hardware and software version Cisco ever shipped live on the network > needing to be supported. > > IIRC correctly, the thing that truly made NetOps give up was "conf t" - > our Support guys must have it to get work done on Cisco and must not be > able to use it on Nexus otherwise things break badly. > > We settled for local roles on the nexus devices and doing > authentication and accounting on tacacs. This works well for us and the > config can be reasonably easily understood by both teams (Services and > NetOps). > > I see little scope to use your script in my setup due to size and > complexity, but please don't stop developing on it. I'm sure the vast > majority of readers here would find it very useful indeed. > > > > > > > > -----Original Message----- > > From: tac_plus-bounces at shrubbery.net > > [mailto:tac_plus-bounces at shrubbery.net] On Behalf Of Alan McKinnon > > Sent: Friday, September 30, 2011 3:43 PM > > To: tac_plus at shrubbery.net > > Subject: Re: [tac_plus] Configuring a/v pair expected by Brocade VDX > > switch > > > > On Fri, 30 Sep 2011 14:14:03 -0700 > > Jathan McCollum wrote: > > > > > Hey John, thanks for the reply. That's a good suggestion that I'll > > > tuck away for future reference. > > > > > > I actually tracked down access to the Brocade support knowledge base > > > and found a document someone had posted using Cisco ASA. > > > > > > And it is: > > > > > > brcd-role = > > > > > > So my group config would be: > > > > > > group = admin { > > > default service = permit > > > service = exec { > > > priv-lvl = 15 > > > brcd-role = admin > > > } > > > } > > > > > > However, sharing that with Cisco devices causes them to be unhappy > > > and fail authorization. I tried prepending the "optional" keyword > > > e.g. "optional brcd-role = admin", which makes Cisco devices happy > > > again, but breaks it on the Brocade. > > > > > > So... almost there, but still missing something. > > > > > > Hi Jathan, > > > > I had a very similar issue getting my Cisco and Nexus kit to work > > together. Short answer is I couldn't get them to work together. > > > > The solution I opted for was to run two instances of tac_plus, the > > original on port 49 for Cisco and the second on port 50 for Nexus, and > > keep the configs entirely separate. This works for me and is probably > > more intuitive than trying to express the same thing in a single > > config file. > > > > One of the shortcomings of tac_plus in it's current form is how > > inflexible it can be. Users can be a member of only one group, which > > is a member of only one group etc. Freeradius has a concept of > > "vhosts" which would be insanely useful on tac_plus, but there is no > > comparable feature. You seem to have run into this. > > > > I'm not complaining (for the asking price of free tac_plus is a great > > product) and until I start submitting patches I have very little > > street-cred. In the meantime I accept that sometimes we have to do > > things in unusual ways (like run two daemons) to get what we want. > > > > > > > > > > > > On Fri, Sep 30, 2011 at 1:59 PM, john heasley > > > wrote: > > > > > > > Fri, Sep 30, 2011 at 01:39:32PM -0700, Jathan McCollum: > > > > > The documentation indicates the device is expecting the server > > > > > to send an a/v pair that specifies the authenticated user's > > > > > role. I assume the value would be "admin" in this case. The > > > > > problem is that nowhere in the documentation so far have I seen > > > > > what attribute the device is expecting. There may also be a > > > > > unique service type (again similar to JUNOS' "junos-exec") that > > > > > is being expected. > > > > > > > > > > So... After all that background, anyone had experience with this > > > > > platform and gotten it working successfully w/ tac_plus? > > > > > > > > none, but some devices send the av pairs they have when they > > > > perform authen and/or author. if you enable the appropriate > > > > debugging knobs, it might reveal it to you. > > > > > > > > or, take the image that you load on the box, uncompress it, unzip > > > > it or whatever their packaging method is, then run strings(1) on > > > > it and look for strings that might be related to authorization. > > > > then send a bomb to brocade offices. > > > > > > > > > > > > > > > > > > > > > > > -- > Alan McKinnnon > alan.mckinnon at gmail.com > _______________________________________________ > tac_plus mailing list > tac_plus at shrubbery.net > http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus > _______________________________________________ > tac_plus mailing list > tac_plus at shrubbery.net > http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus > -- Jathan. -- -------------- next part -------------- An HTML attachment was scrubbed... URL: From Anne_Wei at symantec.com Fri Oct 14 19:00:28 2011 From: Anne_Wei at symantec.com (Anne Wei) Date: Fri, 14 Oct 2011 12:00:28 -0700 Subject: [tac_plus] New service Message-ID: <402AE8E1D2FBB84ABE4AB494310DC4A96235FB0683@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> Greeting, I need help for a new request in our environment. We want to use tac_plus as authentication for a GUI client application - silverpeak. We currently have group SSONET defined in tac_plus.cfg as following: group = SSONET { default service = permit service = shell { priv_lvl=15 } service = exec { priv-lvl=15 optional shell:Admin = "Admin default-domain" } service = junos-exec { local-user-name = remote-ro } after authorization "/bin/sh /app/tacacs/etc/do_auth.sh $name /app/tacacs/etc/allow.sso /app/tacacs/etc/allow.sso_storage" } The GUI client requires silverpeak is defined on TACACS+ server, and use any of the following as customer attribute for the service: role=admin, role=manager,role=monitor. I checked only, and don't see the role concept in tac_plus.cfg. And since there is default service = permit at top, can I assume if no service silverpeak defined, the default authorization is permit? Please give me some advice and guide, Thank you, Anne -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5428 bytes Desc: not available URL: From daniel.schmidt at wyo.gov Mon Oct 17 14:31:42 2011 From: daniel.schmidt at wyo.gov (Daniel Schmidt) Date: Mon, 17 Oct 2011 08:31:42 -0600 Subject: [tac_plus] New service In-Reply-To: <402AE8E1D2FBB84ABE4AB494310DC4A96235FB0683@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> References: <402AE8E1D2FBB84ABE4AB494310DC4A96235FB0683@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> Message-ID: <59b7822a9885261fb705c74047b7d8bd@mail.gmail.com> Sounds similar to the wlc, try role as a tac_pair. http://tacacs.org/2008/11/04/cisco-wireless-control-system/ -----Original Message----- From: tac_plus-bounces at shrubbery.net [mailto:tac_plus-bounces at shrubbery.net] On Behalf Of Anne Wei Sent: Friday, October 14, 2011 1:00 PM To: tac_plus at shrubbery.net Subject: [tac_plus] New service Greeting, I need help for a new request in our environment. We want to use tac_plus as authentication for a GUI client application - silverpeak. We currently have group SSONET defined in tac_plus.cfg as following: group = SSONET { default service = permit service = shell { priv_lvl=15 } service = exec { priv-lvl=15 optional shell:Admin = "Admin default-domain" } service = junos-exec { local-user-name = remote-ro } after authorization "/bin/sh /app/tacacs/etc/do_auth.sh $name /app/tacacs/etc/allow.sso /app/tacacs/etc/allow.sso_storage" } The GUI client requires silverpeak is defined on TACACS+ server, and use any of the following as customer attribute for the service: role=admin, role=manager,role=monitor. I checked only, and don't see the role concept in tac_plus.cfg. And since there is default service = permit at top, can I assume if no service silverpeak defined, the default authorization is permit? Please give me some advice and guide, Thank you, Anne -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5428 bytes Desc: not available URL: _______________________________________________ tac_plus mailing list tac_plus at shrubbery.net http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus From Jetmir.Sulmina at albtelecom.al Mon Oct 24 13:24:36 2011 From: Jetmir.Sulmina at albtelecom.al (Jetmir Sulmina) Date: Mon, 24 Oct 2011 15:24:36 +0200 Subject: [tac_plus] Tac_plus Service Message-ID: <7EBCAE1251E75D42BFF74579E4EEEA8802652F01F65A@HVALB-WA-EMB.albtelecom.al> Hi, I have used until now another version of Tacacs, but it didn't support 'acl' so I am trying to configure your latest release in ubuntu. I installed it correctle, configured the tac_plus.conf file , and afte "tac_plus -C /etc/tac_plus.conf -d 120" I can see the process running with "ps -A" but can't find its service name to restart, check its status etc. Commands like "service tac_plus status" or "service tacacs restart" don't work. Is this normal and how can I fix this? Thank you in advance ________________________________ The information in this e-mail is confidential and may be legally privileged. Access to this e-mail by anyone other than the intended address is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be takening reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Andrew.KENDALL at everythingeverywhere.com Tue Oct 25 08:23:50 2011 From: Andrew.KENDALL at everythingeverywhere.com (Kendall, Andrew) Date: Tue, 25 Oct 2011 09:23:50 +0100 Subject: [tac_plus] Tac_plus Service In-Reply-To: <7EBCAE1251E75D42BFF74579E4EEEA8802652F01F65A@HVALB-WA-EMB.albtelecom.al> References: <7EBCAE1251E75D42BFF74579E4EEEA8802652F01F65A@HVALB-WA-EMB.albtelecom.al> Message-ID: Hi The service name is tac_plus [root at datanetnms3 /]$ ps -ef | grep tac root 11100 11094 0 09:19:41 pts/1 0:00 grep tac root 19746 1 0 Sep 29 ? 0:50 /usr/local/bin/tac_plus -C /etc/tac_plus/tac_plus.conf -L -d 8 to restart I do: svcadm restart tac_plus but I'm running Unix. Hope this helps, Andy. -----Original Message----- From: tac_plus-bounces at shrubbery.net [mailto:tac_plus-bounces at shrubbery.net] On Behalf Of Jetmir Sulmina Sent: 24 October 2011 14:25 To: tac_plus at shrubbery.net Subject: [tac_plus] Tac_plus Service Hi, I have used until now another version of Tacacs, but it didn't support 'acl' so I am trying to configure your latest release in ubuntu. I installed it correctle, configured the tac_plus.conf file , and afte "tac_plus -C /etc/tac_plus.conf -d 120" I can see the process running with "ps -A" but can't find its service name to restart, check its status etc. Commands like "service tac_plus status" or "service tacacs restart" don't work. Is this normal and how can I fix this? Thank you in advance ________________________________ The information in this e-mail is confidential and may be legally privileged. Access to this e-mail by anyone other than the intended address is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be takening reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system. -------------- next part -------------- An HTML attachment was scrubbed... URL: _______________________________________________ tac_plus mailing list tac_plus at shrubbery.net http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus NOTICE AND DISCLAIMER This e-mail (including any attachments) is intended for the above-named person(s). If you are not the intended recipient, notify the sender immediately, delete this email from your system and do not disclose or use for any purpose. We may monitor all incoming and outgoing emails in line with current legislation. We have taken steps to ensure that this email and attachments are free from any virus, but it remains your responsibility to ensure that viruses do not adversely affect you. Everything Everywhere Limited Registered in England and Wales Company Registered Number: 02382161 Registered Office Address: Hatfield Business Park, Hatfield, Hertfordshire, AL10 9BW From daniel.schmidt at wyo.gov Tue Oct 25 13:17:23 2011 From: daniel.schmidt at wyo.gov (Daniel Schmidt) Date: Tue, 25 Oct 2011 07:17:23 -0600 Subject: [tac_plus] Configuring a/v pair expected by Brocade VDX switch In-Reply-To: <20111003201225.2d80eeb0@rohan.example.com> References: <20110930205948.GV9227@shrubbery.net> <20110930234326.278f529d@rohan.example.com> <20111003201225.2d80eeb0@rohan.example.com> Message-ID: <0b1a12093b6918c1116bc62417e35439@mail.gmail.com> Has anybody had any success passing a role as a tac_key? So far, all I see is that the nexus sends the same pairs, every time. Any config exampled would be appreciated. -----Original Message----- From: tac_plus-bounces at shrubbery.net [mailto:tac_plus-bounces at shrubbery.net] On Behalf Of Alan McKinnon Sent: Monday, October 03, 2011 12:12 PM Cc: tac_plus at shrubbery.net Subject: Re: [tac_plus] Configuring a/v pair expected by Brocade VDX switch On Mon, 3 Oct 2011 09:34:45 -0600 Daniel Schmidt wrote: > I've never had this trouble you speak of with Brocade, but then again > I have only used the CER, CES & FCX. The config I posed on tacacs.org > seemed to work fine. > > Also, users CAN be members of multiple groups, you just have to write > an authorization script. Or, just use my do_auth.py script from > tacacs.org - several people have told me it works well. Tac_plus, I > would argue, is more flexible than Cisco's solution. Hi Daniel, Yes, I'm aware of your script but I'm not willing to risk deploying it. Nothing to do with code quality you understand, I'm getting 1.5 million connections a day on a slow day and the only place I can test that for real is in production. My Change Manager would murder me if anything went wrong and I can't begin to calculate if I can cope with 50-75 python scripts spawned a second when things get busy. And that's just the PE devices. There's a completely separate system for CE devices (the current bane of my life...) > I'm working on key replacement with do_auth - what is your issue with > Nexus? As for brcd-role, if you are willing to do try do_auth and > turn on the debug, I should easily be able to add something for a > certain IP range that strips the pairs you don't want and appends the > pairs you do. The main issue with Nexus is that Tacacs support is not mature on those devices (5k & 7k), there are just too many edge cases and too many open support cases with Cisco from our NetOps guys about them. As a device, the 5k's work great, we just couldn't get them to co-exist on the same tac_plus daemon with our wildly wonderful RealWorld(tm) Cisco network. Some days I feel we have at least one of every piece of hardware and software version Cisco ever shipped live on the network needing to be supported. IIRC correctly, the thing that truly made NetOps give up was "conf t" - our Support guys must have it to get work done on Cisco and must not be able to use it on Nexus otherwise things break badly. We settled for local roles on the nexus devices and doing authentication and accounting on tacacs. This works well for us and the config can be reasonably easily understood by both teams (Services and NetOps). I see little scope to use your script in my setup due to size and complexity, but please don't stop developing on it. I'm sure the vast majority of readers here would find it very useful indeed. > > -----Original Message----- > From: tac_plus-bounces at shrubbery.net > [mailto:tac_plus-bounces at shrubbery.net] On Behalf Of Alan McKinnon > Sent: Friday, September 30, 2011 3:43 PM > To: tac_plus at shrubbery.net > Subject: Re: [tac_plus] Configuring a/v pair expected by Brocade VDX > switch > > On Fri, 30 Sep 2011 14:14:03 -0700 > Jathan McCollum wrote: > > > Hey John, thanks for the reply. That's a good suggestion that I'll > > tuck away for future reference. > > > > I actually tracked down access to the Brocade support knowledge base > > and found a document someone had posted using Cisco ASA. > > > > And it is: > > > > brcd-role = > > > > So my group config would be: > > > > group = admin { > > default service = permit > > service = exec { > > priv-lvl = 15 > > brcd-role = admin > > } > > } > > > > However, sharing that with Cisco devices causes them to be unhappy > > and fail authorization. I tried prepending the "optional" keyword > > e.g. "optional brcd-role = admin", which makes Cisco devices happy > > again, but breaks it on the Brocade. > > > > So... almost there, but still missing something. > > > Hi Jathan, > > I had a very similar issue getting my Cisco and Nexus kit to work > together. Short answer is I couldn't get them to work together. > > The solution I opted for was to run two instances of tac_plus, the > original on port 49 for Cisco and the second on port 50 for Nexus, and > keep the configs entirely separate. This works for me and is probably > more intuitive than trying to express the same thing in a single > config file. > > One of the shortcomings of tac_plus in it's current form is how > inflexible it can be. Users can be a member of only one group, which > is a member of only one group etc. Freeradius has a concept of > "vhosts" which would be insanely useful on tac_plus, but there is no > comparable feature. You seem to have run into this. > > I'm not complaining (for the asking price of free tac_plus is a great > product) and until I start submitting patches I have very little > street-cred. In the meantime I accept that sometimes we have to do > things in unusual ways (like run two daemons) to get what we want. > > > > > > > On Fri, Sep 30, 2011 at 1:59 PM, john heasley > > wrote: > > > > > Fri, Sep 30, 2011 at 01:39:32PM -0700, Jathan McCollum: > > > > The documentation indicates the device is expecting the server > > > > to send an a/v pair that specifies the authenticated user's > > > > role. I assume the value would be "admin" in this case. The > > > > problem is that nowhere in the documentation so far have I seen > > > > what attribute the device is expecting. There may also be a > > > > unique service type (again similar to JUNOS' "junos-exec") that > > > > is being expected. > > > > > > > > So... After all that background, anyone had experience with this > > > > platform and gotten it working successfully w/ tac_plus? > > > > > > none, but some devices send the av pairs they have when they > > > perform authen and/or author. if you enable the appropriate > > > debugging knobs, it might reveal it to you. > > > > > > or, take the image that you load on the box, uncompress it, unzip > > > it or whatever their packaging method is, then run strings(1) on > > > it and look for strings that might be related to authorization. > > > then send a bomb to brocade offices. > > > > > > > > > > > > -- Alan McKinnnon alan.mckinnon at gmail.com _______________________________________________ tac_plus mailing list tac_plus at shrubbery.net http://www.shrubbery.net/mailman/listinfo.cgi/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.