From dan.schmidt at uplinkdata.com Mon May 4 16:57:28 2009 From: dan.schmidt at uplinkdata.com (Schmidt, Daniel) Date: Mon, 4 May 2009 10:57:28 -0600 Subject: [tac_plus] After Authorizaion Script Message-ID: <05CC562AFB5A9446A1BC3F66AD04A3BC70D407@che-exch-003.uplinkdata.com> I have finished my python implementation of the "after authorization script", thanks all for your help. It allows more granular control of logins. If anybody would be interested in testing it, I would be happy to send it out. The configuration is fairly simple; as an example, let's say I wanted to have user Homer have full access to 192.168.1.1 and 10.1.1.0/24, but only do show commands for everything else in 10.0.0.0/8. For the heck of it, let's say we only want them to connect from 192.168.1.0/24, but never 192.168.1.4 - he can only do the show commands. The config would be as follows: [users] homer = simpson_group television_group [simpson_group] host_deny = 192.168.1.4 host_allow = 192.168.1.* device_permit = 192.168.1.1 10.1.1.* command_permit = .* [television_group] host_allow = 192.168.1.* device_permit = 10.* command_permit = show.* From dan.schmidt at uplinkdata.com Mon May 4 17:24:40 2009 From: dan.schmidt at uplinkdata.com (Schmidt, Daniel) Date: Mon, 4 May 2009 11:24:40 -0600 Subject: [tac_plus] Re: After Authorizaion Script In-Reply-To: <20090504171341.GE6380@shrubbery.net> References: <05CC562AFB5A9446A1BC3F66AD04A3BC70D407@che-exch-003.uplinkdata.com> <20090504171341.GE6380@shrubbery.net> Message-ID: <05CC562AFB5A9446A1BC3F66AD04A3BC70D40B@che-exch-003.uplinkdata.com> Hum... don't even have a web page to post it on. 326 lines - a bit long for an email. Perhaps I should find a place to post it in case I wish to add/fix the code. Suggestions? -----Original Message----- From: john heasley [mailto:heas at shrubbery.net] Sent: Monday, May 04, 2009 11:14 AM To: Schmidt, Daniel Subject: Re: [tac_plus] After Authorizaion Script Mon, May 04, 2009 at 10:57:28AM -0600, Schmidt, Daniel: > I have finished my python implementation of the "after authorization > script", thanks all for your help. It allows more granular control of > logins. > > If anybody would be interested in testing it, I would be happy to send > it out. The configuration is fairly simple; as an example, let's say I please do, if nothing else I'll include it as an example. > wanted to have user Homer have full access to 192.168.1.1 and > 10.1.1.0/24, but only do show commands for everything else in > 10.0.0.0/8. For the heck of it, let's say we only want them to connect > from 192.168.1.0/24, but never 192.168.1.4 - he can only do the show > commands. The config would be as follows: > > [users] > homer = > simpson_group > television_group > [simpson_group] > host_deny = > 192.168.1.4 > host_allow = > 192.168.1.* > device_permit = > 192.168.1.1 > 10.1.1.* > command_permit = > .* > [television_group] > host_allow = > 192.168.1.* > device_permit = > 10.* > command_permit = > show.* > _______________________________________________ > tac_plus mailing list > tac_plus at shrubbery.net > http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus From dan.schmidt at uplinkdata.com Mon May 4 18:50:19 2009 From: dan.schmidt at uplinkdata.com (Schmidt, Daniel) Date: Mon, 4 May 2009 12:50:19 -0600 Subject: [tac_plus] Re: After Authorizaion Script In-Reply-To: <20090504173650.GL6380@shrubbery.net> References: <05CC562AFB5A9446A1BC3F66AD04A3BC70D407@che-exch-003.uplinkdata.com> <20090504171341.GE6380@shrubbery.net> <05CC562AFB5A9446A1BC3F66AD04A3BC70D40B@che-exch-003.uplinkdata.com> <20090504173650.GL6380@shrubbery.net> Message-ID: <05CC562AFB5A9446A1BC3F66AD04A3BC70D40D@che-exch-003.uplinkdata.com> Could sourceforge it, but it's not really good enough for sourceforge. Anyway, here it is in source & compiled. For instructions: do_auth.pyc | less It's also on pastie: http://pastie.org/467936 Obviously, some good programmers on this list, suggested appreciated - am not a programmer. Suggest compiling, as it will probably run faster. -----Original Message----- From: john heasley [mailto:heas at shrubbery.net] Sent: Monday, May 04, 2009 11:37 AM To: Schmidt, Daniel Subject: Re: [tac_plus] After Authorizaion Script Mon, May 04, 2009 at 11:24:40AM -0600, Schmidt, Daniel: > Hum... don't even have a web page to post it on. 326 lines - a bit long > for an email. Perhaps I should find a place to post it in case I wish > to add/fix the code. Suggestions? 326 lines is not a problem. i'm suggesting including it in the tarball. -------------- next part -------------- A non-text attachment was scrubbed... Name: do_auth.zip Type: application/x-zip-compressed Size: 7946 bytes Desc: do_auth.zip Url : http://www.shrubbery.net/pipermail/tac_plus/attachments/20090504/495c61ef/attachment.bin From john at sackheads.org Tue May 5 14:20:49 2009 From: john at sackheads.org (John Payne) Date: Tue, 5 May 2009 10:20:49 -0400 Subject: [tac_plus] Re: After Authorizaion Script In-Reply-To: <05CC562AFB5A9446A1BC3F66AD04A3BC70D40B@che-exch-003.uplinkdata.com> References: <05CC562AFB5A9446A1BC3F66AD04A3BC70D407@che-exch-003.uplinkdata.com> <20090504171341.GE6380@shrubbery.net> <05CC562AFB5A9446A1BC3F66AD04A3BC70D40B@che-exch-003.uplinkdata.com> Message-ID: On May 4, 2009, at 1:24 PM, Schmidt, Daniel wrote: > Hum... don't even have a web page to post it on. 326 lines - a bit > long > for an email. Perhaps I should find a place to post it in case I wish > to add/fix the code. Suggestions? tacacs.org would be happy to host it.... > > > -----Original Message----- > From: john heasley [mailto:heas at shrubbery.net] > Sent: Monday, May 04, 2009 11:14 AM > To: Schmidt, Daniel > Subject: Re: [tac_plus] After Authorizaion Script > > Mon, May 04, 2009 at 10:57:28AM -0600, Schmidt, Daniel: >> I have finished my python implementation of the "after authorization >> script", thanks all for your help. It allows more granular control >> of >> logins. >> >> If anybody would be interested in testing it, I would be happy to >> send >> it out. The configuration is fairly simple; as an example, let's say > I > > please do, if nothing else I'll include it as an example. > >> wanted to have user Homer have full access to 192.168.1.1 and >> 10.1.1.0/24, but only do show commands for everything else in >> 10.0.0.0/8. For the heck of it, let's say we only want them to > connect >> from 192.168.1.0/24, but never 192.168.1.4 - he can only do the show >> commands. The config would be as follows: >> >> [users] >> homer = >> simpson_group >> television_group >> [simpson_group] >> host_deny = >> 192.168.1.4 >> host_allow = >> 192.168.1.* >> device_permit = >> 192.168.1.1 >> 10.1.1.* >> command_permit = >> .* >> [television_group] >> host_allow = >> 192.168.1.* >> device_permit = >> 10.* >> command_permit = >> show.* >> _______________________________________________ >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.shrubbery.net/pipermail/tac_plus/attachments/20090505/73e69465/attachment.html From daniel.rahmeh at orange-ftgroup.com Fri May 15 13:51:52 2009 From: daniel.rahmeh at orange-ftgroup.com (daniel Rahmeh) Date: Fri, 15 May 2009 15:51:52 +0200 Subject: [tac_plus] Using LDAP groups in tac_plus authorization Message-ID: <4A0D7378.9010402@orange-ftgroup.com> Hi, I have a question please about the possibility to use ldap groups with tac_plus. I know that it's possible to authenticate users via ldap by never seen a solution that permits to get the user's group. Is there some kind of patch that can satisfy this need? Thank you a lot and sorry for bothering, Daniel RAHMEH From heas at shrubbery.net Fri May 15 17:30:57 2009 From: heas at shrubbery.net (john heasley) Date: Fri, 15 May 2009 10:30:57 -0700 Subject: [tac_plus] Re: Using LDAP groups in tac_plus authorization In-Reply-To: <4A0D7378.9010402@orange-ftgroup.com> References: <4A0D7378.9010402@orange-ftgroup.com> Message-ID: <20090515173057.GF24192@shrubbery.net> Fri, May 15, 2009 at 03:51:52PM +0200, daniel Rahmeh: > Hi, > > I have a question please about the possibility to use ldap groups with > tac_plus. I know that it's possible to authenticate users via ldap by > never seen a solution that permits to get the user's group. Is there > some kind of patch that can satisfy this need? Sorry, there is no such thing. I have very limited experience with LDAP. From prozaconstilts at gmail.com Sat May 16 02:30:22 2009 From: prozaconstilts at gmail.com (adam) Date: Fri, 15 May 2009 22:30:22 -0400 Subject: [tac_plus] Re: Using LDAP groups in tac_plus authorization In-Reply-To: <4A0D7378.9010402@orange-ftgroup.com> References: <4A0D7378.9010402@orange-ftgroup.com> Message-ID: <4A0E253E.4000302@gmail.com> daniel Rahmeh wrote: > Hi, > > I have a question please about the possibility to use ldap groups with > tac_plus. I know that it's possible to authenticate users via ldap by > never seen a solution that permits to get the user's group. Is there > some kind of patch that can satisfy this need? > > Thank you a lot and sorry for bothering, > > Daniel RAHMEH > > > > > _______________________________________________ > tac_plus mailing list > tac_plus at shrubbery.net > http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus Hi, I'd suggest this: > Instructions for RHEL5: > > 1. install the pam-devel package from your repository > > 2. compile the source for tacacs+, making sure that -lpam was discovered in > the configure script > > 3. define users in the conf file as such: > > user = { > login = PAM > } > > 4. Place a pam stack configuration in /etc/pam.d/tac_plus that has whatever > mechanisms you require for authentication (see below) > > 5. celebrate The pam stack I use looks like this: #cat /etc/pam.d/tac_plus: #%PAM-1.0 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 It's not very obvious in that file, but I include system-auth, which looks like this: #%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. 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 required pam_mkhomedir.so skel=/etc/skel/ umask=0077 session optional pam_ldap.so So, in this manner, tacacs+, talking to PAM, and using pam_ldap, can authenticate a user with ldap-based credentials. While there is no way to directly reference an ldap group in the tac_plus.conf file, you can kind of get authorization using a pam_filter. Here is my ldap.conf: URI ldaps://my.ldap.server.com base ou=my_ou,dc=my,dc=ldap,dc=server,dc=com binddn uid=read-only_account,ou=Accounts,dc=my,dc=ldap,dc=server,dc=com bindpw ohsosecret scope sub ssl yes TLS_CACERTDIR /etc/openldap/cacerts TLS_REQCERT allow nss_schema rfc2307bis nss_base_passwd ou=Accounts,dc=my,dc=ldap,dc=server,dc=com?sub nss_base_shadow ou=Accounts,dc=my,dc=ldap,dc=server,dc=com?sub nss_base_group ou=Accounts,dc=my,dc=ldap,dc=server,dc=com?sub referrals no # otherwise it goes freakishly slow pam_login_attribute uid pam_member_attribute uniquemember pam_filter (tacacsenabled=true) What's important there is the pam_filter (tacacsenabled=true) It means that pam will only authenticate users who have an attribute tacacsenabled set to true in ldap. Or, even better, you can use this instead of the filter: pam_groupdn cn=tacacs,ou=groups,dc=my,dc=ldap,dc=server,dc=com meaning only members of that group get authenticated. There are 2 caveats to this setup: 1. Since I include system-auth, this means that I've restricted who can log in to my tacacs server to only those in my tacacs group. This is my intention for my organization, because the only people using tacacs are the people who administer that server. If this is not ideal for you, you should use pam_ldap directly in the tac_plus pam configuration instead of including system-auth. 2. I still have to include individual usernames in the tac_plus config. While it'd be ideal to not have to do that, the daemon doesn't support it. I've been trying my hand at patching that in, but the going is slow, cause I'm learning as I go, and I've basically gotten nowhere. :( Anyhoo, I hope that this can help you out. Adam From david at hrcsb.org Wed May 20 20:50:46 2009 From: david at hrcsb.org (David Clymer) Date: Wed, 20 May 2009 16:50:46 -0400 Subject: [tac_plus] Default user config values Message-ID: <1242852646.31316.78.camel@shakazulu.mainst.hrcsb.org> I want to authenticate users via PAM & LDAP, but since tac_plus doesn't allow me to specify PAM as a default authentication method, I modified config.c to allow users which don't have specific configs, to use a the authentication method (an any other config values) from the DEFAULT user. I'm not completely sure this isn't stupid for one reason or another, but I need that functionality. In any case, here is the simple change I made: --- tacacs+-F4.0.4.18/config.c 2009-03-18 19:24:54.000000000 -0400 +++ tacacs+-F4.0.4.18-davidc/config.c 2009-05-20 12:35:34.000000000 -0400 @@ -1854,8 +1854,8 @@ if (!user) { if (debug & DEBUG_CONFIG_FLAG) - report(LOG_DEBUG, "cfg_get_value: no user/group named %s", name); - return(value); + report(LOG_DEBUG, "cfg_get_value: no user/group named %s, using DEFAULT values.", name); + user = (USER *) hash_lookup(isuser ? usertable : grouptable, DEFAULT_USERNAME); } /* found the entry. Lookup value from attr=value */ Enjoy, and thanks for writing tac_plus! -davidc -- Experience is that marvelous thing that enables you to recognize a mistake when you make it again." -Franklin P. Jones