From kissg at ssg.ki.iif.hu Thu Jul 1 09:24:24 2010 From: kissg at ssg.ki.iif.hu (Kiss Gabor (Bitman)) Date: Thu, 1 Jul 2010 11:24:24 +0200 (CEST) Subject: [tac_plus] Re: Different privs for different devices? In-Reply-To: <201006302345.54152.alan.mckinnon@gmail.com> References: <237975.48368.qm@web34302.mail.mud.yahoo.com> <201006302345.54152.alan.mckinnon@gmail.com> Message-ID: > > New to the list and tac_plus. I'm trying to figure out if there's a way to > > grant a set of users one privilege level on one set of devices and a > > different privilege level on another set of devices. My best guess at a > > config to do this was something like this: > Or, Gabor might drop by with a suggestion, he has some very useful patches in > his collection but I haven't tried them enough to comment. The above situation is a bit more complex than I imagined when developed "multiple group membership" feature. I concentrated on login access only but command authorization and other atteributes. At first sight I don't know if I can configure different privilege levels for myself on different devices. I will do some tests. Gabor -- E-mail = m-mail * c-mail ^ 2 From kissg at ssg.ki.iif.hu Thu Jul 1 09:49:58 2010 From: kissg at ssg.ki.iif.hu (Kiss Gabor (Bitman)) Date: Thu, 1 Jul 2010 11:49:58 +0200 (CEST) Subject: [tac_plus] Redesign? (Was: Different privs for different devices?) In-Reply-To: <20100630220437.GG12025@shrubbery.net> References: <237975.48368.qm@web34302.mail.mud.yahoo.com> <201006302345.54152.alan.mckinnon@gmail.com> <20100630220437.GG12025@shrubbery.net> Message-ID: > indeed he does. I hope to import them (possibly w/ some adjustment - sorry) > once i get a better config parser completed. What about lex and yacc? How portable would it be? By the way. IMHO using a relational database would be the most elegant solution to store user attributes. In this case arbitrary complex conditionals might be composed. E.g. "user 'bill' will get level 15 privileges in worktime logging in on the console port of certain 3 NAS-es but level 1 in other cases". The actual syntax of configuration file is established by Lol Grant (Cisco Systems) in the mid 90s. Its open source (and very simple) server side implementation of the TACACS+ protocol is the base of all current open source tac_plus daemons. This config file is not suitable to express such a relations. Maybe the whole concept could be redesigned. SQL database would separate the process of configuration and protocol implementation. Daemon could be smaller and simpler as well as peoples would develop simpler or spectacular configuration frontends including brutal GUIs, CGIs and other (even platform dependent!) utilities. This is like iptables rules could be composed by various firewall manegement programs independently of the way the kernel actually executes them. What is your opinion, guys? Gabor From shadrack at rocketmail.com Mon Jul 5 21:49:24 2010 From: shadrack at rocketmail.com (Paul Floyd) Date: Mon, 5 Jul 2010 14:49:24 -0700 (PDT) Subject: [tac_plus] Re: Redesign? (Was: Different privs for different devices?) In-Reply-To: References: <237975.48368.qm@web34302.mail.mud.yahoo.com> <201006302345.54152.alan.mckinnon@gmail.com> <20100630220437.GG12025@shrubbery.net> Message-ID: <996390.36627.qm@web34301.mail.mud.yahoo.com> > IMHO using a relational database would be the most elegant > solution to store user attributes. > In this case arbitrary complex conditionals might be composed. > E.g. "user 'bill' will get level 15 privileges in worktime > logging in on the console port of certain 3 NAS-es but > level 1 in other cases". I'm probably missing something obvious, but is there a reason you couldn't accomplish the same thing by allowing a user to be a member of two independent groups? Obviously tac_plus would have to be modified to allow that, but that sounds to me like it would be a lot easier than rewriting the whole backend to use an RDB. From kissg at ssg.ki.iif.hu Tue Jul 6 04:56:27 2010 From: kissg at ssg.ki.iif.hu (Kiss Gabor (Bitman)) Date: Tue, 6 Jul 2010 06:56:27 +0200 (CEST) Subject: [tac_plus] Re: Redesign? (Was: Different privs for different devices?) In-Reply-To: <996390.36627.qm@web34301.mail.mud.yahoo.com> References: <237975.48368.qm@web34302.mail.mud.yahoo.com> <201006302345.54152.alan.mckinnon@gmail.com> <20100630220437.GG12025@shrubbery.net> <996390.36627.qm@web34301.mail.mud.yahoo.com> Message-ID: > > solution to store user attributes. > > In this case arbitrary complex conditionals might be composed. > > E.g. "user 'bill' will get level 15 privileges in worktime > > logging in on the console port of certain 3 NAS-es but > > level 1 in other cases". > > I'm probably missing something obvious, but is there a reason you couldn't > accomplish the same thing by allowing a user to be a member of two independent > groups? Obviously tac_plus would have to be modified to allow that, but that > sounds to me like it would be a lot easier than rewriting the whole backend to > use an RDB. I think there is no way to painlessly(*) add further tests and their arbitrary combination to the current syntax. I mean: host originating telnet session, NAS tty, actual weekday and daytime, number of already live sessions of the user etc. Authorization clauses are also uneasy. *Including backward compatibility. Gabor From shadrack at rocketmail.com Tue Jul 6 15:30:56 2010 From: shadrack at rocketmail.com (Paul Floyd) Date: Tue, 6 Jul 2010 08:30:56 -0700 (PDT) Subject: [tac_plus] Re: Redesign? (Was: Different privs for different devices?) In-Reply-To: References: <237975.48368.qm@web34302.mail.mud.yahoo.com> <201006302345.54152.alan.mckinnon@gmail.com> <20100630220437.GG12025@shrubbery.net> <996390.36627.qm@web34301.mail.mud.yahoo.com> Message-ID: <434731.49213.qm@web34302.mail.mud.yahoo.com> > I think there is no way to painlessly(*) add further tests and their > arbitrary combination to the current syntax. > I mean: host originating telnet session, NAS tty, actual weekday and > daytime, number of already live sessions of the user etc. > > Authorization clauses are also uneasy. > > *Including backward compatibility. OK, but WHY? Maybe I'm an idiot, but I'm not seeing how the config syntax makes this particularly difficult. Is this something I just need to read the code to understand? From shadrack at rocketmail.com Tue Jul 6 17:08:05 2010 From: shadrack at rocketmail.com (Paul Floyd) Date: Tue, 6 Jul 2010 10:08:05 -0700 (PDT) Subject: [tac_plus] Re: Redesign? (Was: Different privs for different devices?) In-Reply-To: References: <237975.48368.qm@web34302.mail.mud.yahoo.com> <201006302345.54152.alan.mckinnon@gmail.com> <20100630220437.GG12025@shrubbery.net> <996390.36627.qm@web34301.mail.mud.yahoo.com> <434731.49213.qm@web34302.mail.mud.yahoo.com> Message-ID: <532834.20044.qm@web34301.mail.mud.yahoo.com> Thanks. Probably worth posting to the list... ----- Original Message ---- > From: Alan McKinnon > To: Paul Floyd > Sent: Tue, July 6, 2010 9:36:34 AM > Subject: Re: [tac_plus] Re: Redesign? (Was: Different privs for different >devices?) > > Inasmuch as it affects my setup, the major problem is that to perform > multiple group membership there is something you MUST be able to do in > the config, which tac_plus.conf does NOT do: > > conflict resolution > > It isn't 1991 anymore and things have moved on. It is trivially easy > to come up with a multiple-group config that both allows and disallows > an action. Or a config that tries to set two defaults in two different > places. > > Which one wins? > > The stupid (and hopelessly wrong) approach is "first one wins" much > like iptables on Linux. This instantly gets complicated - define > first. Is it the order in which groups are defined? Or the order they > are assigned in the user/group clause? What if you have a hierarchy of > groups with a permit in the top level group, and ambiguous permit * > somewhere in the middle and an explicit deny for the user? There's > only one way to resolve that - John must flip a coin and hard code it > in the source. Which will satisfy exactly 50% of the users...... > > We're talking AAA here, anything less than a provably correct > algorithm that resolves all conflicts just won't cut it. > > You will notice that nothing in the tac_plus config syntax permits any > such resolution, or even an assignment of priority to a rule. And that > any attempt to do so will probably break existing installations. > > So even though Gabor is proposing the long way round, I agree with his > ideas in principle. I would give my eyeteeth to disconnect the rule > database from the bulk of the code. > > > > On Tue, Jul 6, 2010 at 5:30 PM, Paul Floyd wrote: > >> I think there is no way to painlessly(*) add further tests and their > > > >> arbitrary combination to the current syntax. > >> I mean: host originating telnet session, NAS tty, actual weekday and > >> daytime, number of already live sessions of the user etc. > >> > >> Authorization clauses are also uneasy. > >> > >> *Including backward compatibility. > > > > OK, but WHY? Maybe I'm an idiot, but I'm not seeing how the config syntax >makes > > this particularly difficult. Is this something I just need to read the code >to > > understand? > > > > > > > > _______________________________________________ > > tac_plus mailing list > > tac_plus at shrubbery.net > > http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus > > > > > > -- > Alan McKinnon > alan dot mckinnon at gmail dot com > From kissg at ssg.ki.iif.hu Wed Jul 7 05:27:53 2010 From: kissg at ssg.ki.iif.hu (Kiss Gabor (Bitman)) Date: Wed, 7 Jul 2010 07:27:53 +0200 (CEST) Subject: [tac_plus] Re: Redesign? (Was: Different privs for different devices?) In-Reply-To: <434731.49213.qm@web34302.mail.mud.yahoo.com> References: <237975.48368.qm@web34302.mail.mud.yahoo.com> <201006302345.54152.alan.mckinnon@gmail.com> <20100630220437.GG12025@shrubbery.net> <996390.36627.qm@web34301.mail.mud.yahoo.com> <434731.49213.qm@web34302.mail.mud.yahoo.com> Message-ID: > > I think there is no way to painlessly(*) add further tests and their > > > arbitrary combination to the current syntax. > > I mean: host originating telnet session, NAS tty, actual weekday and > > daytime, number of already live sessions of the user etc. > OK, but WHY? Maybe I'm an idiot, but I'm not seeing how the config syntax makes > this particularly difficult. Is this something I just need to read the code to > understand? Why don't you show us some example configs? :-) Gabor From alan.mckinnon at gmail.com Wed Jul 7 09:51:41 2010 From: alan.mckinnon at gmail.com (Alan McKinnon) Date: Wed, 7 Jul 2010 11:51:41 +0200 Subject: [tac_plus] Re: Redesign? (Was: Different privs for different devices?) In-Reply-To: <434731.49213.qm@web34302.mail.mud.yahoo.com> References: <237975.48368.qm@web34302.mail.mud.yahoo.com> <434731.49213.qm@web34302.mail.mud.yahoo.com> Message-ID: <201007071151.41327.alan.mckinnon@gmail.com> On Tuesday 06 July 2010 17:30:56 Paul Floyd wrote: > > I think there is no way to painlessly(*) add further tests and their > > > > arbitrary combination to the current syntax. > > I mean: host originating telnet session, NAS tty, actual weekday and > > daytime, number of already live sessions of the user etc. > > > > Authorization clauses are also uneasy. > > > > *Including backward compatibility. > > OK, but WHY? Maybe I'm an idiot, but I'm not seeing how the config syntax > makes this particularly difficult. Is this something I just need to read > the code to understand? Inasmuch as it affects my setup, the major problem is that to perform multiple group membership there is something you MUST be able to do in the config, which tac_plus.conf does NOT do: conflict resolution It isn't 1991 anymore and things have moved on. It is trivially easy to come up with a multiple-group config that both allows and disallows an action. Or a config that tries to set two defaults in two different places. Which one wins? The stupid (and hopelessly wrong) approach is "first one wins" much like iptables on Linux. This instantly gets complicated - define first. Is it the order in which groups are defined? Or the order they are assigned in the user/group clause? What if you have a hierarchy of groups with a permit in the top level group, and ambiguous permit * somewhere in the middle and an explicit deny for the user? There's only one way to resolve that - John must flip a coin and hard code it in the source. Which will satisfy exactly 50% of the users...... We're talking AAA here, anything less than a provably correct algorithm that resolves all conflicts just won't cut it. You will notice that nothing in the tac_plus config syntax permits any such resolution, or even an assignment of priority to a rule. And that any attempt to do so will probably break existing installations. So even though Gabor is proposing the long way round, I agree with his ideas in principle. I would give my eyeteeth to disconnect the rule database from the bulk of the code. -- alan dot mckinnon at gmail dot com From shadrack at rocketmail.com Wed Jul 7 19:44:09 2010 From: shadrack at rocketmail.com (Paul Floyd) Date: Wed, 7 Jul 2010 12:44:09 -0700 (PDT) Subject: [tac_plus] Re: Redesign? (Was: Different privs for different devices?) In-Reply-To: References: <237975.48368.qm@web34302.mail.mud.yahoo.com> <201006302345.54152.alan.mckinnon@gmail.com> <20100630220437.GG12025@shrubbery.net> <996390.36627.qm@web34301.mail.mud.yahoo.com> <434731.49213.qm@web34302.mail.mud.yahoo.com> Message-ID: <911508.27751.qm@web34308.mail.mud.yahoo.com> ----- Original Message ---- > From: Kiss Gabor (Bitman) > Cc: tac_plus at shrubbery.net > Sent: Tue, July 6, 2010 10:27:53 PM > Subject: [tac_plus] Re: Redesign? (Was: Different privs for different devices?) > > > > I think there is no way to painlessly(*) add further tests and their > > > > > arbitrary combination to the current syntax. > > > I mean: host originating telnet session, NAS tty, actual weekday and > > > daytime, number of already live sessions of the user etc. > > > OK, but WHY? Maybe I'm an idiot, but I'm not seeing how the config syntax >makes > > > this particularly difficult. Is this something I just need to read the code >to > > > understand? > > Why don't you show us some example configs? :-) group = my_group { acl = my_acl tty = vty[0-4] time_of_day = Mon-Fri,8a-9p max_sessions = 2 } user = fred { member = my_group } From kissg at ssg.ki.iif.hu Thu Jul 8 04:56:20 2010 From: kissg at ssg.ki.iif.hu (Kiss Gabor (Bitman)) Date: Thu, 8 Jul 2010 06:56:20 +0200 (CEST) Subject: [tac_plus] Re: Redesign? In-Reply-To: <911508.27751.qm@web34308.mail.mud.yahoo.com> References: <237975.48368.qm@web34302.mail.mud.yahoo.com> <201006302345.54152.alan.mckinnon@gmail.com> <20100630220437.GG12025@shrubbery.net> <996390.36627.qm@web34301.mail.mud.yahoo.com> <434731.49213.qm@web34302.mail.mud.yahoo.com> <911508.27751.qm@web34308.mail.mud.yahoo.com> Message-ID: > > Why don't you show us some example configs? :-) > > group = my_group { > acl = my_acl > tty = vty[0-4] > time_of_day = Mon-Fri,8a-9p > max_sessions = 2 > } > > user = fred { > member = my_group > } Fine. :-) Let's see a bit more complex case. If Fred logs in terminal_server_A (192.168.0.1) { If logs in on the console or aux port { Execute autocommand "show ip bgp" } If logs in on the first three modem (tty0-2) { Execute autocommand "ppp" and set ip access-group 42 for incoming packets } If logs in on any other modem (tty*) { Execute autocommand "slip" } If logs in on vty* { Give him an exec prompt Set privilege level 2 Discard commands containing "ipv6" } } If Fred logs in any NAS on network_B (192.168.0.0/25) [including the above!] { On the weekends { Executing "configure" command is not allowed } After 4pm and before 8am { Executing "show interface" command is not allowed unless he connect the NAS from 10.3.3.3 } } If Fred logs in any NAS [including the above] { If he comes from 10.4.4.4 { Set privilege level 15 } } Regards Gabor -- No smoke, no drugs, no vindoze. From rselvidge at ffn.com Thu Jul 8 19:49:24 2010 From: rselvidge at ffn.com (Robert Selvidge) Date: Thu, 8 Jul 2010 12:49:24 -0700 Subject: [tac_plus] tac_plus configuration using AD/LDAP Message-ID: <21A67E2153E64D48ACBD190732CB859108377F8B@site1-mailbox1.pmgi.local> Hi, I'm trying to implement a solution using tac_plus with AD/LDAP authentication. I cannot find much information on this using Shurbbery's tac_plus with this setup. Can someone point me in the right direction on how to set this up or even supply a sample configuration if someone has implemented this? -Rob ________________________________ This message contains confidential information and is intended only for the individual named. If you are not the named addressee, you are notified that reviewing, disseminating, disclosing, copying or distributing this e-mail is strictly prohibited. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any loss or damage caused by viruses or errors or omissions in the contents of this message, which arise as a result of e-mail transmission. [FriendFinder Networks, Inc., 220 Humbolt court, Sunnyvale, CA 94089, USA, FriendFinder.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.shrubbery.net/pipermail/tac_plus/attachments/20100708/7e366052/attachment.html From prozaconstilts at gmail.com Fri Jul 9 12:15:27 2010 From: prozaconstilts at gmail.com (Adam) Date: Fri, 09 Jul 2010 08:15:27 -0400 Subject: [tac_plus] Re: tac_plus configuration using AD/LDAP In-Reply-To: <21A67E2153E64D48ACBD190732CB859108377F8B@site1-mailbox1.pmgi.local> References: <21A67E2153E64D48ACBD190732CB859108377F8B@site1-mailbox1.pmgi.local> Message-ID: <4C3712DF.40102@gmail.com> Hi, This is possible, to a certain extent.You may use pam to authenticate a user, (and thus pam_ldap or pam_krb5), but you still must define users in your tac_plus.conf, and you must still define groups in tac_plus.conf. A set of steps follows, and was written specifically for RHEL and an openldap server, so file locations and naming may vary: 1. Install the pam-devel package and tcp_wrappers via yum: yum install pam-devel tcp_wrappers 2. Obtain the latest tac_plus from ftp://ftp.shrubbery.net/pub/tac_plus/ I used version F4.0.4.15 3. unpack tac_plus: tar xfz tacacs+- 4. Run configure: ./configure --bindir=/usr/local/bin --sbindir=/usr/local/sbin --localstatedir=/var/local/tacacs --sysconfdir=/etc --with-logfile=/var/log/tacacs/tacacs --with-pidfile=/var/run/tacacs.pid --with-acctfile=/var/log/tacacs/acctfile Note that the above configure choices were my own, you can choose whatever values you want. 5. Make sure the pam libraries were found. Look at the output of configure for a line that looks like this: checking for pam_start in -lpam... yes If that says yes, then the daemon will compile with pam support. If it says no, then configure is unable to find your pam libraries. Make sure you performed Step 1. 6. compile tac_plus: make 7. install tac_plus make install 8. Configure tac_plus. While there are many more configurations to be done to make tac_plus work as a whole, the pam specific configuration is as follows: Edit the tac_plus conf file, and define your users as such: user = { login = PAM } Currently, tac_plus only allows authentication using pam (since pam is only used for authentication anyway). Authorizations are still configured within the conf file, no ldap groups allowed :( 9. Define a pam stack for tac_plus. cd /etc/pam.d vi tac_plus My pam stack config is as follows: auth required pam_env.so auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 500 quiet auth sufficient pam_ldap.so use_first_pass auth required pam_deny.so account required pam_unix.so broken_shadow account sufficient pam_localuser.so account sufficient pam_succeed_if.so uid < 500 quiet account [default=bad success=ok user_unknown=ignore] pam_ldap.so account required pam_permit.so password requisite pam_cracklib.so try_first_pass retry=3 password sufficient pam_unix.so md5 shadow nullok try_first_pass use_authtok password sufficient pam_ldap.so use_authtok password required pam_deny.so session optional pam_keyinit.so revoke session required pam_limits.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session optional pam_ldap.so Note that this config also works well for system-auth. If you want all authentication for your server to use ldap (graphical login, ssh, etc.), you can place the above into system-auth, and the define tac_plus as follows: auth include system-auth account required pam_nologin.so account include system-auth password include system-auth session optional pam_keyinit.so force revoke session include system-auth session required pam_loginuid.so 10. Configure your ldap.conf. This is where you define your ldap server, binddn, attribute maps, etc. Note that on RHEL5, there are two ldap.conf files. One is in /etc/openldap and the other is just in /etc. PAM will stat both files upon invocation, and the second one it stats will override the first. I usually modify /etc/openldap/ldap.conf, and then symlink /etc/ldap.conf to it. That's it. At this point, assuming you have everything setup right, you should be able to use your LDAP server for authentication. To troubleshoot, I normally run the tacacs daemon in the foreground with debugging on: tac_plus -C /path/to/tac_plus.conf -L -p 49 -d16 -g and then try to authenticate. So far, I have found a couple caveats that will make life very sad. First, if you decide to run tac_plus from xinetd in linux (which I suggest you do, to utilize tcp wrappers properly), then you should set up your /etc/xinetd.d/tacacs conf file as follows: service tacacs { socket_type = stream protocol = tcp wait = no disable = no user = root server = /path/to/tac_plus server_args = -C /path/to/tac_plus.conf -L -p 49 -i -d 16 cps = 50 10 flags = IPv4 } The server must be run as root. Because you are talking to PAM, then you must have root privileges, or else it will not work. Secondly, if you are using xinetd, in your ldap.conf file, turn off debugging. When run from xinetd with ldap debugging on, the ldap libs will output debug code to stderr. Since you are running the daemon from within xinetd, there is no stderr to output to, and the tac_plus daemon upon discovering this broken pipe will fail and exit. Whether this is a tac_plus or xinetd problem I'm not sure, but it's there all the same. You can use the -g option to run in the foreground to test your ldap conf if you wish, but once you start to use xinetd, make sure that the debug directive in your ldap.conf is off. On 07/08/2010 03:49 PM, Robert Selvidge wrote: > Hi, > > I'm trying to implement a solution using tac_plus with AD/LDAP authentication. I cannot find much information on this using Shurbbery's tac_plus with this setup. Can someone point me in the right direction on how to set this up or even supply a sample configuration if someone has implemented this? > > -Rob > > ________________________________ > This message contains confidential information and is intended only for the individual named. If you are not the named addressee, you are notified that reviewing, disseminating, disclosing, copying or distributing this e-mail is strictly prohibited. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any loss or damage caused by viruses or errors or omissions in the contents of this message, which arise as a result of e-mail transmission. [FriendFinder Networks, Inc., 220 Humbolt court, Sunnyvale, CA 94089, USA, FriendFinder.com > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: http://www.shrubbery.net/pipermail/tac_plus/attachments/20100708/7e366052/attachment.html > _______________________________________________ > tac_plus mailing list > tac_plus at shrubbery.net > http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus From shadrack at rocketmail.com Sat Jul 10 10:39:52 2010 From: shadrack at rocketmail.com (Paul Floyd) Date: Sat, 10 Jul 2010 03:39:52 -0700 (PDT) Subject: [tac_plus] Re: Redesign? In-Reply-To: References: <237975.48368.qm@web34302.mail.mud.yahoo.com> <201006302345.54152.alan.mckinnon@gmail.com> <20100630220437.GG12025@shrubbery.net> <996390.36627.qm@web34301.mail.mud.yahoo.com> <434731.49213.qm@web34302.mail.mud.yahoo.com> <911508.27751.qm@web34308.mail.mud.yahoo.com> Message-ID: <226980.41541.qm@web34305.mail.mud.yahoo.com> ----- Original Message ---- > From: Kiss Gabor (Bitman) > To: Paul Floyd > Cc: tac_plus at shrubbery.net > Sent: Wed, July 7, 2010 9:56:20 PM > Subject: Re: [tac_plus] Redesign? > > > > Why don't you show us some example configs? :-) > > > > group = my_group { > > acl = my_acl > > tty = vty[0-4] > > time_of_day = Mon-Fri,8a-9p > > max_sessions = 2 > > } > > > > user = fred { > > member = my_group > > } > > Fine. :-) > Let's see a bit more complex case. > > If Fred logs in terminal_server_A (192.168.0.1) { > If logs in on the console or aux port { > Execute autocommand "show ip bgp" > } > If logs in on the first three modem (tty0-2) { > Execute autocommand "ppp" > and set ip access-group 42 for incoming packets > } > If logs in on any other modem (tty*) { > Execute autocommand "slip" > } > If logs in on vty* { > Give him an exec prompt > Set privilege level 2 > Discard commands containing "ipv6" > } > } > If Fred logs in any NAS on network_B (192.168.0.0/25) [including the above!] { > On the weekends { > Executing "configure" command is not allowed > } > After 4pm and before 8am { > Executing "show interface" command is not allowed unless > he connect the NAS from 10.3.3.3 > } > } > If Fred logs in any NAS [including the above] { > If he comes from 10.4.4.4 { > Set privilege level 15 > } > } > > Regards > > Gabor OK I see how this works. I meet your challenge and you just move the goalpoasts! :-) Right, well, this is pretty rough (I'm sure I'm using half the commands wrong), but it should illustrate the basic idea which is that all groups in a hierarchy are processed (basically from the bottom up), but only the ones where all the conditions are matched have their parameters applied to the user session. Where two parameters conflict (for example autocmd) the last one applied takes precedence. There are probably a few places here where you'd have to UNSET parameters applied in an earlier group, but that is left as an exercise for the reader :-) acl = network_b { deny ^192\.168\.0\.12[89]$ permit ^192\.168\.0\.[0-9][0-9]?$ permit ^192\.168\.0\.1[0-2][0-9]$ } acl = term_serv_a { permit ^192\.168\.0\.1$ } group uber_manager { address = 10.4.4.4 service = exec { priv-lvl = 15 } } group tsa_conaux { acl = term_serv_a tty = console|aux autocmd="show ip bgp" member = uber_manager } group tsa_vty { acl = term_serv_a tty = vty* service = exec { priv-lvl = 2 } cmd { deny .*ipv6.* permit .* } member = tsa_conaux } group tsa_firstmodem { acl = term_serv_a tty = tty* autocmd="slip" inacl=none member = tsa_vty } group tsa_othermodem { acl = term_serv_a tty = tty[0-2] autocmd="ppp" inacl=42 member = tsa_firstmodem } group weekend { acl = network_b time_of_day = Su,Sa cmd = configure { deny .* } member = tsa_othermodem } group overnight { acl = network_b time_of_day = 0-8;16-24 address != 10.3.3.3 cmd = show { deny interface permit .* } member = weekend } user = fred { member = overnight } The example above is kinda bending over backwards in an effort not to depart from the existing syntax only to show that I think it could *technically* be done. That being said, it's horribly convoluted. A better solution might be to add a basic if/then/else conditional construct with a little boolean logic sprinkled in for good measure. Something sorta like this: group example_group { if(acl=network_b) { if(time_of_day = 0-8;16-24 && address != 10.3.3.3) { cmd = show { deny interface permit .* } } if(time_of_day = Su,Sa) { cmd = configure { deny .* } } if(acl=term_serv_a) { if(tty = console|aux) { autocmd="show ip bgp" } elseif (tty = tty[0-2]) { autocmd="ppp" inacl=42 } elseif (tty = tty.*) { autocmd="slip" } elseif (tty = vty.*) { service = exec { priv-lvl = 2 } cmd { deny .*ipv6.* permit .* } } } } if(address=10.4.4.4) { service = exec { priv-lvl = 15 } } user = fred { member = example_group } I kind of ignored inheritance here, but if you wanted to allow a "member = " clause in a group definition, you could treat it essentially as a substitution -- somewhat like an #include statement in C. I realize the whole idea is a big change, but it still seems more straightforward than converting the whole backend to SQL. I suspect it would perform better than SQL too, but then again, I haven't looked at the code, so maybe I'm way off base here... - Paul From kissg at ssg.ki.iif.hu Sat Jul 10 12:39:48 2010 From: kissg at ssg.ki.iif.hu (Kiss Gabor (Bitman)) Date: Sat, 10 Jul 2010 14:39:48 +0200 (CEST) Subject: [tac_plus] Re: Redesign? In-Reply-To: <226980.41541.qm@web34305.mail.mud.yahoo.com> References: <237975.48368.qm@web34302.mail.mud.yahoo.com> <201006302345.54152.alan.mckinnon@gmail.com> <20100630220437.GG12025@shrubbery.net> <996390.36627.qm@web34301.mail.mud.yahoo.com> <434731.49213.qm@web34302.mail.mud.yahoo.com> <911508.27751.qm@web34308.mail.mud.yahoo.com> <226980.41541.qm@web34305.mail.mud.yahoo.com> Message-ID: > group uber_manager { :-D > The example above is kinda bending over backwards in an effort not to depart > from the existing syntax only to show that I think it could *technically* be > done. That being said, it's horribly convoluted. A better solution might be to > add a basic if/then/else conditional construct with a little boolean logic > sprinkled in for good measure. Something sorta like this: > I kind of ignored inheritance here, but if you wanted to allow a "member = " > clause in a group definition, you could treat it essentially as a substitution > -- somewhat like an #include statement in C. I realize the whole idea is a big Summary: The current syntax is ineligible so a new procedural language should be designed from the scratch. Instead of calling external scripts we need a "TACACS+ parser" and interpreter. Syntax is not flexible enough or the interface between frontends and backend is not well defined. > change, but it still seems more straightforward than converting the whole > backend to SQL. I suspect it would perform better than SQL too, but then again, > I haven't looked at the code, so maybe I'm way off base here... John already has problems the current parser. I don't think he agrees with design of a new language too. Splitting frontends and backend has several advantage. But it works only if the interface is clean. Gabor From shadrack at rocketmail.com Sat Jul 10 21:22:29 2010 From: shadrack at rocketmail.com (Paul Floyd) Date: Sat, 10 Jul 2010 14:22:29 -0700 (PDT) Subject: [tac_plus] Re: Redesign? In-Reply-To: References: <237975.48368.qm@web34302.mail.mud.yahoo.com> <201006302345.54152.alan.mckinnon@gmail.com> <20100630220437.GG12025@shrubbery.net> <996390.36627.qm@web34301.mail.mud.yahoo.com> <434731.49213.qm@web34302.mail.mud.yahoo.com> <911508.27751.qm@web34308.mail.mud.yahoo.com> <226980.41541.qm@web34305.mail.mud.yahoo.com> Message-ID: <791336.20726.qm@web34301.mail.mud.yahoo.com> > Summary: > The current syntax is ineligible so a new procedural > language should be designed from the scratch. No, the current syntax cannot produce a straightforward config for YOUR EXAMPLE. But let's face it, your example scenario is far more convoluted than what is facing probably 99% of the potential user population. If one has complex requirements, maybe one should expect complex solutions. Although the second solution is closer to ideal, the first one is probably sufficient for the vast majority of real-world situations. - Paul From shadrack at rocketmail.com Sat Jul 10 21:47:59 2010 From: shadrack at rocketmail.com (Paul Floyd) Date: Sat, 10 Jul 2010 14:47:59 -0700 (PDT) Subject: [tac_plus] Re: Redesign? In-Reply-To: <791336.20726.qm@web34301.mail.mud.yahoo.com> References: <237975.48368.qm@web34302.mail.mud.yahoo.com> <201006302345.54152.alan.mckinnon@gmail.com> <20100630220437.GG12025@shrubbery.net> <996390.36627.qm@web34301.mail.mud.yahoo.com> <434731.49213.qm@web34302.mail.mud.yahoo.com> <911508.27751.qm@web34308.mail.mud.yahoo.com> <226980.41541.qm@web34305.mail.mud.yahoo.com> <791336.20726.qm@web34301.mail.mud.yahoo.com> Message-ID: <675670.26802.qm@web34306.mail.mud.yahoo.com> > Although the second solution is closer to ideal, the first one is probably > sufficient for the vast majority of real-world situations. Actually, I guess it's not fair for me to just assume that. Anybody out there care to send me a complex TACACS+ requirement they're facing (or have faced) in the REAL WORLD? I'm interested to know if there are a lot of scenarios that would be impossible or impractical for the first solution I proposed. Real-word situations only, please -- no "what if" scenarios. Please describe in sufficient detail to write a config. I'd also be interested to know how you're solving (or working around) the problem now. Thanks, - Paul From bruce.carleton at jasperwireless.com Wed Jul 14 19:17:56 2010 From: bruce.carleton at jasperwireless.com (Bruce Carleton) Date: Wed, 14 Jul 2010 12:17:56 -0700 Subject: [tac_plus] Re: tac_plus configuration using AD/LDAP In-Reply-To: <21A67E2153E64D48ACBD190732CB859108377F8B@site1-mailbox1.pmgi.local> References: <21A67E2153E64D48ACBD190732CB859108377F8B@site1-mailbox1.pmgi.local> Message-ID: I used winbind on RHEL 5. It's part of samba-common. If you have 2008 A/D controllers, you will probably need to use samba3x. There some other details that come to mind. You have to use pam in the tac_plus.conf entries for users: user = some.ad.user { login = PAM } If you use hosts.allow, you will need something like: tac_plus: 10. 192.168. You will also need a pam configuration for tac_plus. This is what mine looks like: $ cat /etc/pam.d/tac_plus auth include system-auth account required pam_nologin.so account include system-auth password include system-auth session optional pam_keyinit.so force revoke session include system-auth session required pam_loginuid.so After I had worked out my /etc/krb5.conf, /etc/samba/smb.conf and /etc/resolv.conf I used the following RHEL 5 command to get winbind working: $ authconfig --enablewinbindauth --enablewinbind --enablemkhomedir --update Those are the highlights. Best, --Bruce -----Original Message----- From: tac_plus-bounces at shrubbery.net [mailto:tac_plus-bounces at shrubbery.net] On Behalf Of Robert Selvidge Sent: Thursday, July 08, 2010 12:49 PM To: tac_plus at shrubbery.net Subject: [tac_plus] tac_plus configuration using AD/LDAP Hi, I'm trying to implement a solution using tac_plus with AD/LDAP authentication. I cannot find much information on this using Shurbbery's tac_plus with this setup. Can someone point me in the right direction on how to set this up or even supply a sample configuration if someone has implemented this? -Rob ________________________________ This message contains confidential information and is intended only for the individual named. If you are not the named addressee, you are notified that reviewing, disseminating, disclosing, copying or distributing this e-mail is strictly prohibited. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any loss or damage caused by viruses or errors or omissions in the contents of this message, which arise as a result of e-mail transmission. [FriendFinder Networks, Inc., 220 Humbolt court, Sunnyvale, CA 94089, USA, FriendFinder.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.shrubbery.net/pipermail/tac_plus/attachments/20100708/7e36605 2/attachment.html _______________________________________________ tac_plus mailing list tac_plus at shrubbery.net http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus From shadrack at rocketmail.com Wed Jul 14 23:16:19 2010 From: shadrack at rocketmail.com (Paul Floyd) Date: Wed, 14 Jul 2010 16:16:19 -0700 (PDT) Subject: [tac_plus] Re: Redesign? In-Reply-To: <675670.26802.qm@web34306.mail.mud.yahoo.com> References: <237975.48368.qm@web34302.mail.mud.yahoo.com> <201006302345.54152.alan.mckinnon@gmail.com> <20100630220437.GG12025@shrubbery.net> <996390.36627.qm@web34301.mail.mud.yahoo.com> <434731.49213.qm@web34302.mail.mud.yahoo.com> <911508.27751.qm@web34308.mail.mud.yahoo.com> <226980.41541.qm@web34305.mail.mud.yahoo.com> <791336.20726.qm@web34301.mail.mud.yahoo.com> <675670.26802.qm@web34306.mail.mud.yahoo.com> Message-ID: <908764.29160.qm@web34305.mail.mud.yahoo.com> > Actually, I guess it's not fair for me to just assume that. Anybody out there > > care to send me a complex TACACS+ requirement they're facing (or have faced) >in > > the REAL WORLD? I'm interested to know if there are a lot of scenarios that > would be impossible or impractical for the first solution I proposed. >Real-word > > situations only, please -- no "what if" scenarios. > > Please describe in sufficient detail to write a config. I'd also be >interested > > to know how you're solving (or working around) the problem now. > Anyone? Anyone?