From morty+tac_plus at frakir.org Thu Jun 2 08:05:59 2011 From: morty+tac_plus at frakir.org (Morty) Date: Thu, 2 Jun 2011 04:05:59 -0400 Subject: [tac_plus] password expiration with PAM? In-Reply-To: <20110527171811.GI15202@radiological.warningg.com> References: <20110526051134.GD15573@red-sonja> <20110527171811.GI15202@radiological.warningg.com> Message-ID: <20110602080559.GG13962@red-sonja> On Fri, May 27, 2011 at 12:18:11PM -0500, Brandon Ewing wrote: > On Thu, May 26, 2011 at 01:11:34AM -0400, Morty wrote: > > I'm testing tacacs+-F4.0.4.19 under Solaris. > > > > I've got users with LOGIN=PAM. I set the password to be expired > > (i.e. I faked out the age in /etc/shadow to be 1000 days, with a max > > age of 60 days). Other subsystems using PAM, i.e. openssh and > > radiusd, do not allow the user to login; openssh provides a useful > > prompt, while radiusd just fails to allow the login for devices that > > utilize radiusd. But when the user logs in to a device using the > > tac_plus server, the login succeeds. > > > > This seems like a bug. > > > > - Morty > > What's in your PAM config for tac_plus? If your config doesn't have a > "password" section, I don't believe it will respect password expiration. Here is the pam.conf from my test box: login auth required /usr/lib/security/pam_unix.so.1 login auth required /usr/lib/security/pam_dial_auth.so.1 # rlogin auth sufficient /usr/lib/security/pam_rhosts_auth.so.1 rlogin auth required /usr/lib/security/pam_unix.so.1 # dtlogin auth required /usr/lib/security/pam_unix.so.1 # rsh auth required /usr/lib/security/pam_rhosts_auth.so.1 other auth required /usr/lib/security/pam_unix.so.1 # # Account management # login account required /usr/lib/security/pam_unix.so.1 dtlogin account required /usr/lib/security/pam_unix.so.1 # other account required /usr/lib/security/pam_unix.so.1 # # Session management # other session required /usr/lib/security/pam_unix.so.1 # # Password management # other password required /usr/lib/security/pam_unix.so.1 tac_plus, openssh, and radiusd are all handled via "other". openssh and radiusd are doing password expiration correctly. tac_plus isn't. As you can see, "other" has password defined. - Morty From johannwallace at msn.com Fri Jun 3 21:13:04 2011 From: johannwallace at msn.com (Johann Wallace) Date: Fri, 3 Jun 2011 14:13:04 -0700 Subject: [tac_plus] TAC Plus Encryption Types Message-ID: What type of encryption does TAC Plus offer when storing the user passwords within the config file? I see the reference of DES, but I want to determine if this truly is the depreciated version of DES or the "updated" 3DES, and if this is the only option for password storage other than clear text. Is there a plan or method to implement an alternate encryption method for passwords, such as AES 256, that the TAC Plus developed daemon can support? Please advise, thank you. Johann R. Wallace -------------- next part -------------- An HTML attachment was scrubbed... URL: From kissg at ssg.ki.iif.hu Sat Jun 4 05:03:28 2011 From: kissg at ssg.ki.iif.hu (Kiss Gabor (Bitman)) Date: Sat, 4 Jun 2011 07:03:28 +0200 (CEST) Subject: [tac_plus] TAC Plus Encryption Types In-Reply-To: References: Message-ID: > What type of encryption does TAC Plus offer when storing the user passwords > within the config file? I see the reference of DES, but I want to determine It depends on your libcrypt. Tac_plus itself does not contain encryption code. Gabor -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? From john at sackheads.org Mon Jun 6 20:30:36 2011 From: john at sackheads.org (John Payne) Date: Mon, 6 Jun 2011 16:30:36 -0400 Subject: [tac_plus] Command authorization for IPv6 Message-ID: <9A2A2E47-0333-41B7-BBC6-98B8AABF6F06@sackheads.org> Trying to authorize users to only configure neighbors and not peer-groups (as an example). This is highly simplified just to demonstrate the problem: cmd = neighbor { permit [0-9]+\.[0-9]+\.[0-9]+\.[0-9]+.* permit ":.*" deny .* } (config-router)#nei 1:2:3:4:5:6:7:9 remote-as 1 Command authorization failed. Mon Jun 6 20:12:57 2011 [31045]: authorize_cmd: user=XXXX, cmd=neighbor Mon Jun 6 20:12:57 2011 [31045]: line 284 compare neighbor permit '[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+.*' & 'remote-as 1 ' no match Mon Jun 6 20:12:57 2011 [31045]: line 285 compare neighbor permit ':.*' & 'remote-as 1 ' no match Mon Jun 6 20:12:57 2011 [31045]: line 286 compare neighbor deny '.*' & 'remote-as 1 ' match Mon Jun 6 20:12:57 2011 [31045]: neighbor remote-as 1 denied by line 286 Mon Jun 6 20:12:57 2011 [31045]: authorization query for 'XXXX' tty1 from yyy.yyy.yyy.yyy rejected Vs: (config-router)#nei 1.2.3.4 remote-as 1 Mon Jun 6 20:13:50 2011 [31116]: authorize_cmd: user=XXXX, cmd=neighbor Mon Jun 6 20:13:50 2011 [31116]: line 284 compare neighbor permit '[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+.*' & '1.2.3.4 remote-as 1 ' match Mon Jun 6 20:13:50 2011 [31116]: neighbor 1.2.3.4 remote-as 1 permitted by line 284 Mon Jun 6 20:13:50 2011 [31116]: authorization query for 'XXXX' tty1 from yyy.yyy.yyy.yyy accepted So it seems as though IPv6 addresses are not being passed through the authorization command. I have yet to determine as to whether or not this is between the router and tac_plus or internally to tac_plus. Before I go too deep, has anyone else run into this? Thanks John From heas at shrubbery.net Tue Jun 7 23:58:11 2011 From: heas at shrubbery.net (john heasley) Date: Tue, 7 Jun 2011 18:58:11 -0500 Subject: [tac_plus] Command authorization for IPv6 In-Reply-To: <9A2A2E47-0333-41B7-BBC6-98B8AABF6F06@sackheads.org> References: <9A2A2E47-0333-41B7-BBC6-98B8AABF6F06@sackheads.org> Message-ID: <20110607235811.GC13646@shrubbery.net> Mon, Jun 06, 2011 at 04:30:36PM -0400, John Payne: > Trying to authorize users to only configure neighbors and not peer-groups (as an example). This is highly simplified just to demonstrate the problem: > > cmd = neighbor { > permit [0-9]+\.[0-9]+\.[0-9]+\.[0-9]+.* > permit ":.*" > deny .* > } > > > (config-router)#nei 1:2:3:4:5:6:7:9 remote-as 1 > Command authorization failed. > > > Mon Jun 6 20:12:57 2011 [31045]: authorize_cmd: user=XXXX, cmd=neighbor > Mon Jun 6 20:12:57 2011 [31045]: line 284 compare neighbor permit '[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+.*' & 'remote-as 1 ' no match > Mon Jun 6 20:12:57 2011 [31045]: line 285 compare neighbor permit ':.*' & 'remote-as 1 ' no match looks like the device is not sending the address. i havent reviewed the code, but as i recall, it comes direct from (and is expanded to its canonical form by) the device. From daniel.schmidt at wyo.gov Wed Jun 8 14:16:47 2011 From: daniel.schmidt at wyo.gov (Daniel Schmidt) Date: Wed, 8 Jun 2011 08:16:47 -0600 Subject: [tac_plus] Command authorization for IPv6 In-Reply-To: <20110607235811.GC13646@shrubbery.net> References: <9A2A2E47-0333-41B7-BBC6-98B8AABF6F06@sackheads.org> <20110607235811.GC13646@shrubbery.net> Message-ID: <81352d85013c3ebc89de4338718de512@mail.gmail.com> You may try do_auth.py - the log tells you the exact commands sent as it's sent to the after authorization script. Then, you can use Pyreb or something to come up with the perfect regular expressions to put in your tac_plus.conf. (or just put them in do_auth.py if you find that easier) -----Original Message----- From: tac_plus-bounces at shrubbery.net [mailto:tac_plus-bounces at shrubbery.net] On Behalf Of john heasley Sent: Tuesday, June 07, 2011 5:58 PM To: John Payne Cc: tac_plus at shrubbery.net Subject: Re: [tac_plus] Command authorization for IPv6 Mon, Jun 06, 2011 at 04:30:36PM -0400, John Payne: > Trying to authorize users to only configure neighbors and not peer-groups (as an example). This is highly simplified just to demonstrate the problem: > > cmd = neighbor { > permit [0-9]+\.[0-9]+\.[0-9]+\.[0-9]+.* > permit ":.*" > deny .* > } > > > (config-router)#nei 1:2:3:4:5:6:7:9 remote-as 1 > Command authorization failed. > > > Mon Jun 6 20:12:57 2011 [31045]: authorize_cmd: user=XXXX, cmd=neighbor > Mon Jun 6 20:12:57 2011 [31045]: line 284 compare neighbor permit '[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+.*' & 'remote-as 1 ' no match > Mon Jun 6 20:12:57 2011 [31045]: line 285 compare neighbor permit ':.*' & 'remote-as 1 ' no match looks like the device is not sending the address. i havent reviewed the code, but as i recall, it comes direct from (and is expanded to its canonical form by) the device. _______________________________________________ tac_plus mailing list tac_plus at shrubbery.net http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus From john at sackheads.org Thu Jun 9 17:02:29 2011 From: john at sackheads.org (John Payne) Date: Thu, 9 Jun 2011 13:02:29 -0400 Subject: [tac_plus] Command authorization for IPv6 In-Reply-To: <81352d85013c3ebc89de4338718de512@mail.gmail.com> References: <9A2A2E47-0333-41B7-BBC6-98B8AABF6F06@sackheads.org> <20110607235811.GC13646@shrubbery.net> <81352d85013c3ebc89de4338718de512@mail.gmail.com> Message-ID: <47CF0265-1D21-4D53-A27A-5A0FBEEAF383@sackheads.org> On Jun 8, 2011, at 10:16 AM, Daniel Schmidt wrote: > You may try do_auth.py - the log tells you the exact commands sent as it's > sent to the after authorization script. Then, you can use Pyreb or > something to come up with the perfect regular expressions to put in your > tac_plus.conf. (or just put them in do_auth.py if you find that easier) Thanks Daniel, but if the IP isn't being sent by the router, its not going to make it into do_auth.py either :( > > -----Original Message----- > From: tac_plus-bounces at shrubbery.net > [mailto:tac_plus-bounces at shrubbery.net] On Behalf Of john heasley > Sent: Tuesday, June 07, 2011 5:58 PM > To: John Payne > Cc: tac_plus at shrubbery.net > Subject: Re: [tac_plus] Command authorization for IPv6 > > Mon, Jun 06, 2011 at 04:30:36PM -0400, John Payne: >> Trying to authorize users to only configure neighbors and not > peer-groups (as an example). This is highly simplified just to > demonstrate the problem: >> >> cmd = neighbor { >> permit [0-9]+\.[0-9]+\.[0-9]+\.[0-9]+.* >> permit ":.*" >> deny .* >> } >> >> >> (config-router)#nei 1:2:3:4:5:6:7:9 remote-as 1 >> Command authorization failed. >> >> >> Mon Jun 6 20:12:57 2011 [31045]: authorize_cmd: user=XXXX, cmd=neighbor >> Mon Jun 6 20:12:57 2011 [31045]: line 284 compare neighbor permit > '[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+.*' & 'remote-as 1 ' no match >> Mon Jun 6 20:12:57 2011 [31045]: line 285 compare neighbor permit ':.*' > & 'remote-as 1 ' no match > > looks like the device is not sending the address. i havent reviewed the > code, > but as i recall, it comes direct from (and is expanded to its canonical > form > by) the device. > _______________________________________________ > tac_plus mailing list > tac_plus at shrubbery.net > http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus > From john at sackheads.org Thu Jun 9 17:02:56 2011 From: john at sackheads.org (John Payne) Date: Thu, 9 Jun 2011 13:02:56 -0400 Subject: [tac_plus] Command authorization for IPv6 In-Reply-To: <20110607235811.GC13646@shrubbery.net> References: <9A2A2E47-0333-41B7-BBC6-98B8AABF6F06@sackheads.org> <20110607235811.GC13646@shrubbery.net> Message-ID: <1F947E7D-EC64-402A-B93A-A7A599BBD501@sackheads.org> On Jun 7, 2011, at 7:58 PM, john heasley wrote: > Mon, Jun 06, 2011 at 04:30:36PM -0400, John Payne: >> Trying to authorize users to only configure neighbors and not peer-groups (as an example). This is highly simplified just to demonstrate the problem: >> >> cmd = neighbor { >> permit [0-9]+\.[0-9]+\.[0-9]+\.[0-9]+.* >> permit ":.*" >> deny .* >> } >> >> >> (config-router)#nei 1:2:3:4:5:6:7:9 remote-as 1 >> Command authorization failed. >> >> >> Mon Jun 6 20:12:57 2011 [31045]: authorize_cmd: user=XXXX, cmd=neighbor >> Mon Jun 6 20:12:57 2011 [31045]: line 284 compare neighbor permit '[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+.*' & 'remote-as 1 ' no match >> Mon Jun 6 20:12:57 2011 [31045]: line 285 compare neighbor permit ':.*' & 'remote-as 1 ' no match > > looks like the device is not sending the address. i havent reviewed the code, > but as i recall, it comes direct from (and is expanded to its canonical form > by) the device. Thats what I thought :( Yay, more IPv6 related bugs.... From daniel.schmidt at wyo.gov Thu Jun 9 17:16:50 2011 From: daniel.schmidt at wyo.gov (Daniel Schmidt) Date: Thu, 9 Jun 2011 11:16:50 -0600 Subject: [tac_plus] Command authorization for IPv6 In-Reply-To: <47CF0265-1D21-4D53-A27A-5A0FBEEAF383@sackheads.org> References: <9A2A2E47-0333-41B7-BBC6-98B8AABF6F06@sackheads.org> <20110607235811.GC13646@shrubbery.net> <81352d85013c3ebc89de4338718de512@mail.gmail.com> <47CF0265-1D21-4D53-A27A-5A0FBEEAF383@sackheads.org> Message-ID: <0ed7126a9bf91dc1e963dcaeb0eeaf15@mail.gmail.com> True that. Just sayin' the log might make it easier to see that it isn't sent. What vendor, Cisco? Good luck getting them to fix it, I don't think they ever fixed tacacs single-connection. -----Original Message----- From: John Payne [mailto:john at sackheads.org] Sent: Thursday, June 09, 2011 11:02 AM To: Daniel Schmidt Cc: tac_plus at shrubbery.net Subject: Re: [tac_plus] Command authorization for IPv6 On Jun 8, 2011, at 10:16 AM, Daniel Schmidt wrote: > You may try do_auth.py - the log tells you the exact commands sent as it's > sent to the after authorization script. Then, you can use Pyreb or > something to come up with the perfect regular expressions to put in your > tac_plus.conf. (or just put them in do_auth.py if you find that easier) Thanks Daniel, but if the IP isn't being sent by the router, its not going to make it into do_auth.py either :( > > -----Original Message----- > From: tac_plus-bounces at shrubbery.net > [mailto:tac_plus-bounces at shrubbery.net] On Behalf Of john heasley > Sent: Tuesday, June 07, 2011 5:58 PM > To: John Payne > Cc: tac_plus at shrubbery.net > Subject: Re: [tac_plus] Command authorization for IPv6 > > Mon, Jun 06, 2011 at 04:30:36PM -0400, John Payne: >> Trying to authorize users to only configure neighbors and not > peer-groups (as an example). This is highly simplified just to > demonstrate the problem: >> >> cmd = neighbor { >> permit [0-9]+\.[0-9]+\.[0-9]+\.[0-9]+.* >> permit ":.*" >> deny .* >> } >> >> >> (config-router)#nei 1:2:3:4:5:6:7:9 remote-as 1 >> Command authorization failed. >> >> >> Mon Jun 6 20:12:57 2011 [31045]: authorize_cmd: user=XXXX, cmd=neighbor >> Mon Jun 6 20:12:57 2011 [31045]: line 284 compare neighbor permit > '[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+.*' & 'remote-as 1 ' no match >> Mon Jun 6 20:12:57 2011 [31045]: line 285 compare neighbor permit ':.*' > & 'remote-as 1 ' no match > > looks like the device is not sending the address. i havent reviewed the > code, > but as i recall, it comes direct from (and is expanded to its canonical > form > by) the device. > _______________________________________________ > tac_plus mailing list > tac_plus at shrubbery.net > http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus > From heas at shrubbery.net Thu Jun 9 17:50:12 2011 From: heas at shrubbery.net (john heasley) Date: Thu, 9 Jun 2011 12:50:12 -0500 Subject: [tac_plus] Command authorization for IPv6 In-Reply-To: <0ed7126a9bf91dc1e963dcaeb0eeaf15@mail.gmail.com> References: <9A2A2E47-0333-41B7-BBC6-98B8AABF6F06@sackheads.org> <20110607235811.GC13646@shrubbery.net> <81352d85013c3ebc89de4338718de512@mail.gmail.com> <47CF0265-1D21-4D53-A27A-5A0FBEEAF383@sackheads.org> <0ed7126a9bf91dc1e963dcaeb0eeaf15@mail.gmail.com> Message-ID: <20110609175012.GH20080@shrubbery.net> Thu, Jun 09, 2011 at 11:16:50AM -0600, Daniel Schmidt: > Good luck getting them to fix it, I don't > think they ever fixed tacacs single-connection. no, they haven't. works on XR though (or did). From Raymond.Lee at qwest.com Thu Jun 9 21:48:29 2011 From: Raymond.Lee at qwest.com (Lee, Raymond) Date: Thu, 9 Jun 2011 16:48:29 -0500 Subject: [tac_plus] pam_ldap accepting blank passwords Message-ID: <41EE66689DFD3647AAE8E8CB28C2668B86924661B2@qtomaexmbm21.AD.QINTRA.COM> Hi, Anyone out there running tac_plus on Ubuntu with pam_ldap? I installed libnss-ldapd, libpam-ldapd, nscd, and nslcd. Things seem to be working OK for the most part: - I can authenticate against our LDAP server when I give a valid LDAP username and password. - I get denied access as expected if I give a valid LDAP username but a bad password. - I get denied access as expected if I give an invalid LDAP username. However, if I give a valid LDAP username and a blank password, it lets me in -- not good! Seems like the LDAP server is accepting this as an anonymous bind. My /etc/pam.d/tac_plus looks like this: auth required pam_ldap.so account required pam_ldap.so My /etc/nslcd.conf looks like this: # /etc/nslcd.conf # nslcd configuration file. See nslcd.conf(5) # for details. # The user and group nslcd should run as. uid nslcd gid nslcd # The location at which the LDAP server(s) should be reachable. uri ldaps://10.1.2.3:1636 ldaps://10.2.3.4:1636 # The search base that will be used for all queries. base ou=People,dc=mnet,dc=qintra,dc=com filter passwd (objectclass=mnetperson) # The LDAP protocol version to use. #ldap_version 3 # The DN to bind with for normal lookups. binddn uid=proxyuser,ou=people,dc=mnet,dc=qintra,dc=com bindpw *********** # SSL options #ssl off tls_reqcert never # The search scope. #scope sub When I run 'nslcd -d' for debugging and try to authenticate with a blank password, I see this: nslcd: [e87ccd] DEBUG: connection from pid=18477 uid=0 gid=0 nslcd: [e87ccd] DEBUG: nslcd_pam_authc("leeraym","","tac_plus","") nslcd: [e87ccd] DEBUG: myldap_search(base="ou=People,dc=mnet,dc=qintra,dc=com", filter="(&(objectclass=mnetperson)(uid=leeraym))") nslcd: [e87ccd] ldap_result() failed: Can't contact LDAP server nslcd: [e87ccd] DEBUG: ldap_abandon() nslcd: [e87ccd] DEBUG: ldap_unbind() nslcd: [e87ccd] DEBUG: myldap_get_entry(): retry search nslcd: [e87ccd] DEBUG: ldap_initialize(ldaps://10.1.2.3:1636) nslcd: [e87ccd] DEBUG: ldap_set_rebind_proc() nslcd: [e87ccd] DEBUG: ldap_set_option(LDAP_OPT_PROTOCOL_VERSION,3) nslcd: [e87ccd] DEBUG: ldap_set_option(LDAP_OPT_DEREF,0) nslcd: [e87ccd] DEBUG: ldap_set_option(LDAP_OPT_TIMELIMIT,0) nslcd: [e87ccd] DEBUG: ldap_set_option(LDAP_OPT_TIMEOUT,0) nslcd: [e87ccd] DEBUG: ldap_set_option(LDAP_OPT_NETWORK_TIMEOUT,0) nslcd: [e87ccd] DEBUG: ldap_set_option(LDAP_OPT_REFERRALS,LDAP_OPT_ON) nslcd: [e87ccd] DEBUG: ldap_set_option(LDAP_OPT_RESTART,LDAP_OPT_ON) nslcd: [e87ccd] DEBUG: ldap_set_option(LDAP_OPT_X_TLS,LDAP_OPT_X_TLS_HARD) nslcd: [e87ccd] DEBUG: ldap_simple_bind_s("uid=proxyuser,ou=people,dc=mnet,dc=qintra,dc=com","*****") (uri="ldaps://10.1.2.3:1636") nslcd: [e87ccd] connected to LDAP server ldaps://10.1.2.3:1636 nslcd: [e87ccd] DEBUG: ldap_initialize(ldaps://10.1.2.3:1636) nslcd: [e87ccd] DEBUG: ldap_set_rebind_proc() nslcd: [e87ccd] DEBUG: ldap_set_option(LDAP_OPT_PROTOCOL_VERSION,3) nslcd: [e87ccd] DEBUG: ldap_set_option(LDAP_OPT_DEREF,0) nslcd: [e87ccd] DEBUG: ldap_set_option(LDAP_OPT_TIMELIMIT,0) nslcd: [e87ccd] DEBUG: ldap_set_option(LDAP_OPT_TIMEOUT,0) nslcd: [e87ccd] DEBUG: ldap_set_option(LDAP_OPT_NETWORK_TIMEOUT,0) nslcd: [e87ccd] DEBUG: ldap_set_option(LDAP_OPT_REFERRALS,LDAP_OPT_ON) nslcd: [e87ccd] DEBUG: ldap_set_option(LDAP_OPT_RESTART,LDAP_OPT_ON) nslcd: [e87ccd] DEBUG: ldap_set_option(LDAP_OPT_X_TLS,LDAP_OPT_X_TLS_HARD) nslcd: [e87ccd] DEBUG: ldap_simple_bind_s("uid=leeraym,ou=People,dc=mnet,dc=qintra,dc=com",empty) (uri="ldaps://10.1.2.3:1636") nslcd: [e87ccd] connected to LDAP server ldaps://10.1.5.7:1636 nslcd: [e87ccd] DEBUG: myldap_search(base="uid=leeraym,ou=People,dc=mnet,dc=qintra,dc=com", filter="(objectclass=mnetperson)") nslcd: [e87ccd] DEBUG: ldap_result(): end of results nslcd: [e87ccd] DEBUG: ldap_unbind() nslcd: [1b58ba] DEBUG: connection from pid=18477 uid=0 gid=0 nslcd: [1b58ba] DEBUG: nslcd_pam_authz("leeraym","uid=leeraym,ou=People,dc=mnet,dc=qintra,dc=com","tac_plus","","","") The last few lines of the debug look slightly different when I login using a valid username and password: nslcd: [7ed7ab] DEBUG: ldap_simple_bind_s("uid=leeraym,ou=People,dc=mnet,dc=qintra,dc=com","*****") (uri="ldaps://10.1.2.3:1636") nslcd: [7ed7ab] connected to LDAP server ldaps://10.1.2.3:1636 nslcd: [7ed7ab] DEBUG: myldap_search(base="uid=leeraym,ou=People,dc=mnet,dc=qintra,dc=com", filter="(objectclass=mnetperson)") nslcd: [7ed7ab] DEBUG: ldap_unbind() nslcd: [b141f2] DEBUG: connection from pid=18484 uid=0 gid=0 nslcd: [b141f2] DEBUG: nslcd_pam_authz("leeraym","uid=leeraym,ou=People,dc=mnet,dc=qintra,dc=com","tac_plus","","","") Has anyone run into this behavior before? Maybe I could resolve this if I had something above pam_ldap in my PAM stack that would check to make sure the password isn't blank? Thanks, Ray This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From vadud3 at gmail.com Thu Jun 9 23:28:16 2011 From: vadud3 at gmail.com (Asif Iqbal) Date: Thu, 9 Jun 2011 19:28:16 -0400 Subject: [tac_plus] IP block with net mask instead of regex in acl Message-ID: Is there a way to define a ip block with netmasks instead of regex in tacacs+ config? I looked through the tac_plus mailing list www.shrubbery.net/pipermail/tac_plus with avail So instead of doing it like this acl = foo_acl { deny = 192.168.0.([12][0-9]|[3][01])$ <== not sure if it is correct permit = .* } I wonder if there is way to add the above snippet like below acl = foo_acl { deny = 192.168.0.0/27 # or 192.168.0.0 mask 255.255.255.224 permit = .* } So much easier to manage network list with subnet masking option than regex. Thanks -- Asif Iqbal PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? From alan.mckinnon at gmail.com Fri Jun 10 08:14:48 2011 From: alan.mckinnon at gmail.com (Alan McKinnon) Date: Fri, 10 Jun 2011 10:14:48 +0200 Subject: [tac_plus] IP block with net mask instead of regex in acl In-Reply-To: References: Message-ID: <201106101014.48875.alan.mckinnon@gmail.com> Apparently, though unproven, at 01:28 on Friday 10 June 2011, Asif Iqbal did opine thusly: > Is there a way to define a ip block with netmasks instead of regex in > tacacs+ config? Unfortunately not. The parser understands only regexes. However, I'm sure John will gratefully review high-quality patches. > > I looked through the tac_plus mailing list > www.shrubbery.net/pipermail/tac_plus with avail > > So instead of doing it like this > > acl = foo_acl { > deny = 192.168.0.([12][0-9]|[3][01])$ <== not sure if it is > correct permit = .* > } > > I wonder if there is way to add the above snippet like below > > acl = foo_acl { > deny = 192.168.0.0/27 # or 192.168.0.0 mask 255.255.255.224 > permit = .* > } > > So much easier to manage network list with subnet masking option than > regex. > > Thanks -- alan dot mckinnon at gmail dot com From Raymond.Lee at qwest.com Fri Jun 10 18:00:30 2011 From: Raymond.Lee at qwest.com (Lee, Raymond) Date: Fri, 10 Jun 2011 13:00:30 -0500 Subject: [tac_plus] pam_ldap accepting blank passwords In-Reply-To: <41EE66689DFD3647AAE8E8CB28C2668B86924661B2@qtomaexmbm21.AD.QINTRA.COM> References: <41EE66689DFD3647AAE8E8CB28C2668B86924661B2@qtomaexmbm21.AD.QINTRA.COM> Message-ID: <41EE66689DFD3647AAE8E8CB28C2668B86924661BA@qtomaexmbm21.AD.QINTRA.COM> Many thanks to Greg Newton for this solution: Hi Raymond, I had this very problem on Maverick. The version of nslcd in the repos has a bug that allows this behaviour. Later versions (I think the problem got sorted in 0.7.8ish) sort out the problem. I now pull nslcd from launchpad (currently v0.7.13): https://launchpad.net/ubuntu/+source/nss-pam-ldapd/ I've done this in our small lab and had no issues whatsoever. Cheers, Greg > -----Original Message----- > From: tac_plus-bounces at shrubbery.net [mailto:tac_plus- > bounces at shrubbery.net] On Behalf Of Lee, Raymond > Sent: Thursday, June 09, 2011 5:48 PM > To: tac_plus at shrubbery.net > Subject: [tac_plus] pam_ldap accepting blank passwords > > Hi, > > Anyone out there running tac_plus on Ubuntu with pam_ldap? I installed > libnss-ldapd, libpam-ldapd, nscd, and nslcd. > > Things seem to be working OK for the most part: > - I can authenticate against our LDAP server when I give a valid LDAP > username and password. > - I get denied access as expected if I give a valid LDAP username but a > bad password. > - I get denied access as expected if I give an invalid LDAP username. > > However, if I give a valid LDAP username and a blank password, it lets > me in -- not good! Seems like the LDAP server is accepting this as an > anonymous bind. > > > My /etc/pam.d/tac_plus looks like this: > > auth required pam_ldap.so > account required pam_ldap.so > > > > My /etc/nslcd.conf looks like this: > > # /etc/nslcd.conf > # nslcd configuration file. See nslcd.conf(5) > # for details. > > # The user and group nslcd should run as. > uid nslcd > gid nslcd > > # The location at which the LDAP server(s) should be reachable. > uri ldaps://10.1.2.3:1636 ldaps://10.2.3.4:1636 > > # The search base that will be used for all queries. > base ou=People,dc=mnet,dc=qintra,dc=com > > filter passwd (objectclass=mnetperson) > > # The LDAP protocol version to use. > #ldap_version 3 > > # The DN to bind with for normal lookups. > binddn uid=proxyuser,ou=people,dc=mnet,dc=qintra,dc=com > bindpw *********** > > # SSL options > #ssl off > tls_reqcert never > > # The search scope. > #scope sub > > > > When I run 'nslcd -d' for debugging and try to authenticate with a > blank password, I see this: > > > nslcd: [e87ccd] DEBUG: connection from pid=18477 uid=0 gid=0 > nslcd: [e87ccd] DEBUG: nslcd_pam_authc("leeraym","","tac_plus","") > nslcd: [e87ccd] DEBUG: > myldap_search(base="ou=People,dc=mnet,dc=qintra,dc=com", > filter="(&(objectclass=mnetperson)(uid=leeraym))") > nslcd: [e87ccd] ldap_result() failed: Can't contact LDAP server > nslcd: [e87ccd] DEBUG: ldap_abandon() > nslcd: [e87ccd] DEBUG: ldap_unbind() > nslcd: [e87ccd] DEBUG: myldap_get_entry(): retry search > nslcd: [e87ccd] DEBUG: ldap_initialize(ldaps://10.1.2.3:1636) > nslcd: [e87ccd] DEBUG: ldap_set_rebind_proc() > nslcd: [e87ccd] DEBUG: ldap_set_option(LDAP_OPT_PROTOCOL_VERSION,3) > nslcd: [e87ccd] DEBUG: ldap_set_option(LDAP_OPT_DEREF,0) > nslcd: [e87ccd] DEBUG: ldap_set_option(LDAP_OPT_TIMELIMIT,0) > nslcd: [e87ccd] DEBUG: ldap_set_option(LDAP_OPT_TIMEOUT,0) > nslcd: [e87ccd] DEBUG: ldap_set_option(LDAP_OPT_NETWORK_TIMEOUT,0) > nslcd: [e87ccd] DEBUG: ldap_set_option(LDAP_OPT_REFERRALS,LDAP_OPT_ON) > nslcd: [e87ccd] DEBUG: ldap_set_option(LDAP_OPT_RESTART,LDAP_OPT_ON) > nslcd: [e87ccd] DEBUG: > ldap_set_option(LDAP_OPT_X_TLS,LDAP_OPT_X_TLS_HARD) > nslcd: [e87ccd] DEBUG: > ldap_simple_bind_s("uid=proxyuser,ou=people,dc=mnet,dc=qintra,dc=com"," > *****") (uri="ldaps://10.1.2.3:1636") > nslcd: [e87ccd] connected to LDAP server ldaps://10.1.2.3:1636 > nslcd: [e87ccd] DEBUG: ldap_initialize(ldaps://10.1.2.3:1636) > nslcd: [e87ccd] DEBUG: ldap_set_rebind_proc() > nslcd: [e87ccd] DEBUG: ldap_set_option(LDAP_OPT_PROTOCOL_VERSION,3) > nslcd: [e87ccd] DEBUG: ldap_set_option(LDAP_OPT_DEREF,0) > nslcd: [e87ccd] DEBUG: ldap_set_option(LDAP_OPT_TIMELIMIT,0) > nslcd: [e87ccd] DEBUG: ldap_set_option(LDAP_OPT_TIMEOUT,0) > nslcd: [e87ccd] DEBUG: ldap_set_option(LDAP_OPT_NETWORK_TIMEOUT,0) > nslcd: [e87ccd] DEBUG: ldap_set_option(LDAP_OPT_REFERRALS,LDAP_OPT_ON) > nslcd: [e87ccd] DEBUG: ldap_set_option(LDAP_OPT_RESTART,LDAP_OPT_ON) > nslcd: [e87ccd] DEBUG: > ldap_set_option(LDAP_OPT_X_TLS,LDAP_OPT_X_TLS_HARD) > nslcd: [e87ccd] DEBUG: > ldap_simple_bind_s("uid=leeraym,ou=People,dc=mnet,dc=qintra,dc=com",emp > ty) (uri="ldaps://10.1.2.3:1636") > nslcd: [e87ccd] connected to LDAP server ldaps://10.1.5.7:1636 > nslcd: [e87ccd] DEBUG: > myldap_search(base="uid=leeraym,ou=People,dc=mnet,dc=qintra,dc=com", > filter="(objectclass=mnetperson)") > nslcd: [e87ccd] DEBUG: ldap_result(): end of results > nslcd: [e87ccd] DEBUG: ldap_unbind() > nslcd: [1b58ba] DEBUG: connection from pid=18477 uid=0 gid=0 > nslcd: [1b58ba] DEBUG: > nslcd_pam_authz("leeraym","uid=leeraym,ou=People,dc=mnet,dc=qintra,dc=c > om","tac_plus","","","") > > > > The last few lines of the debug look slightly different when I login > using a valid username and password: > > > nslcd: [7ed7ab] DEBUG: > ldap_simple_bind_s("uid=leeraym,ou=People,dc=mnet,dc=qintra,dc=com","** > ***") (uri="ldaps://10.1.2.3:1636") > nslcd: [7ed7ab] connected to LDAP server ldaps://10.1.2.3:1636 > nslcd: [7ed7ab] DEBUG: > myldap_search(base="uid=leeraym,ou=People,dc=mnet,dc=qintra,dc=com", > filter="(objectclass=mnetperson)") > nslcd: [7ed7ab] DEBUG: ldap_unbind() > nslcd: [b141f2] DEBUG: connection from pid=18484 uid=0 gid=0 > nslcd: [b141f2] DEBUG: > nslcd_pam_authz("leeraym","uid=leeraym,ou=People,dc=mnet,dc=qintra,dc=c > om","tac_plus","","","") > > > > Has anyone run into this behavior before? Maybe I could resolve this > if I had something above pam_ldap in my PAM stack that would check to > make sure the password isn't blank? > > Thanks, > Ray > > This communication is the property of Qwest and may contain > confidential or > privileged information. Unauthorized use of this communication is > strictly > prohibited and may be unlawful. If you have received this > communication > in error, please immediately notify the sender by reply e-mail and > destroy > all copies of the communication and any attachments. > _______________________________________________ > tac_plus mailing list > tac_plus at shrubbery.net > http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From Raymond.Lee at qwest.com Fri Jun 10 20:44:56 2011 From: Raymond.Lee at qwest.com (Lee, Raymond) Date: Fri, 10 Jun 2011 15:44:56 -0500 Subject: [tac_plus] account lockout PAM module for LDAP Message-ID: <41EE66689DFD3647AAE8E8CB28C2668B86924661C1@qtomaexmbm21.AD.QINTRA.COM> Hi, I'm using nss-pam-ldapd for tac_plus authorization on an Ubuntu 10.04 box and would like to implement an account lockout policy if there are too many failed login attempts. I've looked at pam_tally, but that only works for local users on the tac_plus server. My tac_plus server talks to a remote LDAP server for authorization. Does anyone know of a module similar to pam_tally that will work with LDAP? Thanks, Ray ________________________________ This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Christofer.Algotsson at malmo.se Tue Jun 14 11:01:12 2011 From: Christofer.Algotsson at malmo.se (Christofer Algotsson) Date: Tue, 14 Jun 2011 11:01:12 +0000 Subject: [tac_plus] parsingbug in tac-plus 4.0.4.19 Message-ID: Hi, Just to let you know Debian GNU/Linux uses : as delimiter in /etc/passwd for expiery records. Tac_plus needs to know this in order to validate the row and value correctly. Thanks Christofer Algotsson Malm? Stad, ITS -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: tac_pluspatch.txt URL: From heas at shrubbery.net Tue Jun 14 17:20:07 2011 From: heas at shrubbery.net (john heasley) Date: Tue, 14 Jun 2011 17:20:07 +0000 Subject: [tac_plus] parsingbug in tac-plus 4.0.4.19 In-Reply-To: References: Message-ID: <20110614172006.GF7606@shrubbery.net> Tue, Jun 14, 2011 at 11:01:12AM +0000, Christofer Algotsson: > Hi, > > Just to let you know Debian GNU/Linux uses : as delimiter in /etc/passwd for expiery records. Tac_plus needs to know this in order to validate the row and value correctly. > I dont think this is correct. Can you provide an example of the field value? Your patch implies that a value that begins with a ':' is an empty or no expiration indicator. I think that a change must be made to the code below this. > Thanks > Christofer Algotsson > Malm? Stad, ITS > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > -------------- next part -------------- > An embedded and charset-unspecified text was scrubbed... > Name: tac_pluspatch.txt > URL: > _______________________________________________ > tac_plus mailing list > tac_plus at shrubbery.net > http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus From Christofer.Algotsson at malmo.se Wed Jun 15 09:50:09 2011 From: Christofer.Algotsson at malmo.se (Christofer Algotsson) Date: Wed, 15 Jun 2011 09:50:09 +0000 Subject: [tac_plus] parsingbug in tac-plus 4.0.4.19 In-Reply-To: <20110614172006.GF7606@shrubbery.net> References: <20110614172006.GF7606@shrubbery.net> Message-ID: Hi, Sorry quoting your email the outlook way. I meant the /etc/shadow file, not /etc/passwd - my bad. User1 doesn't have a expiry date set, User2 does. User1::13867:0:99999:7::: User2::13913:0:99999:7::14061: No matter if the expiry is configured or not the Tacacs daemon rejects all users credentials. After some investigation I found that the expiry variable got populated with a colon (:) which makes the daemon to reject the user. However it's not rejecting the user as 'accound expired' - it just silently tells you that the credentials are invalid. So I configured a valid expiry date for my test user, no difference.. got rejected. So I configured a expired expiry date and still got rejected (no expiry reason). My patch tells tac_plus not to treat colon as a valid expiry entry. Now everything works (expiry, non-expiry-accnts and so forth.) I could provide you with a debug if you'd like one. Could take some time to get one (production system). Thanks Chris -----Original Message----- From: john heasley [mailto:heas at shrubbery.net] Sent: Tuesday, June 14, 2011 7:20 PM To: Christofer Algotsson Cc: tac_plus at shrubbery.net Subject: Re: [tac_plus] parsingbug in tac-plus 4.0.4.19 Tue, Jun 14, 2011 at 11:01:12AM +0000, Christofer Algotsson: > Hi, > > Just to let you know Debian GNU/Linux uses : as delimiter in /etc/passwd for expiery records. Tac_plus needs to know this in order to validate the row and value correctly. > I dont think this is correct. Can you provide an example of the field value? Your patch implies that a value that begins with a ':' is an empty or no expiration indicator. I think that a change must be made to the code below this. From morty+tac_plus at frakir.org Fri Jun 17 06:35:28 2011 From: morty+tac_plus at frakir.org (Morty) Date: Fri, 17 Jun 2011 02:35:28 -0400 Subject: [tac_plus] PAM and PAP Message-ID: <20110617063528.GE27512@red-sonja> I'm running tacacs+-F4.0.4.19 under Solaris. I've got users with LOGIN=PAM. This works fine for IOS and the Perl Authen::TacacsPlus module. It does not appear to work for some other devices. With debug enabled, the logs show: Mon Jun 13 21:41:07 2011 [17455]: session.peerip is $IP Mon Jun 13 21:41:07 2011 [29501]: connect from $hostname [$IP] Mon Jun 13 21:41:07 2011 [29501]: pap-login query for '$user' 0 from $hostname rejected Mon Jun 13 21:41:07 2011 [29501]: login failure: $user $hostname ($IP) 0 Google finds a patch for this, but it comes with big caveats: http://peterton.org/?p=17 Is there a solution for this? Thanks. - Morty From jnathan at salesforce.com Fri Jun 17 16:07:34 2011 From: jnathan at salesforce.com (Jon Nathan) Date: Fri, 17 Jun 2011 09:07:34 -0700 Subject: [tac_plus] PAM and PAP In-Reply-To: <20110617063528.GE27512@red-sonja> Message-ID: We're using this patch to do PAP via PAM and it's working nicely for us. http://www.shrubbery.net/pipermail/tac_plus/2011-May/000882.html -Jon On 6/17/11 2:35 AM, "Morty" wrote: > I'm running tacacs+-F4.0.4.19 under Solaris. > > I've got users with LOGIN=PAM. This works fine for IOS and the Perl > Authen::TacacsPlus module. It does not appear to work for some other > devices. With debug enabled, the logs show: > > Mon Jun 13 21:41:07 2011 [17455]: session.peerip is $IP > Mon Jun 13 21:41:07 2011 [29501]: connect from $hostname [$IP] > Mon Jun 13 21:41:07 2011 [29501]: pap-login query for '$user' 0 from $hostname > rejected > Mon Jun 13 21:41:07 2011 [29501]: login failure: $user $hostname ($IP) 0 > > Google finds a patch for this, but it comes with big caveats: > > http://peterton.org/?p=17 > > Is there a solution for this? > > Thanks. > > - Morty > _______________________________________________ > tac_plus mailing list > tac_plus at shrubbery.net > http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus From morty+tac_plus at frakir.org Fri Jun 17 19:35:10 2011 From: morty+tac_plus at frakir.org (Morty) Date: Fri, 17 Jun 2011 15:35:10 -0400 Subject: [tac_plus] PAM and PAP In-Reply-To: References: <20110617063528.GE27512@red-sonja> Message-ID: <20110617193510.GJ3790@red-sonja> On Fri, Jun 17, 2011 at 09:07:34AM -0700, Jon Nathan wrote: > We're using this patch to do PAP via PAM and it's working nicely for us. > > http://www.shrubbery.net/pipermail/tac_plus/2011-May/000882.html Thanks! That message was actually one of the first ones that came up in my google search. :) Are there any plans to incorporate this patch into the official release? I know open source doesn't make guarantees, but the fact that the patch hasn't been incorporated into the main distribution, plus the comments about "double free" issues on peterton.org has me a little spooked. "double free" issues are often exploitable. - Morty From tacplus at rhemasound.org Mon Jun 20 19:56:20 2011 From: tacplus at rhemasound.org (tacplus at rhemasound.org) Date: Mon, 20 Jun 2011 19:56:20 +0000 Subject: [tac_plus] Default authentication other than passwd file Message-ID: <20110620195620.GA17807@Oslo> Is it possible to use PAM instead of /etc/passwd file for default authentication. I am trying to deploy an LDAP based system for tacacs authentication. --- Brian Raaen ZCorum braaen at zcorum.com From Raymond.Lee at qwest.com Mon Jun 20 20:04:47 2011 From: Raymond.Lee at qwest.com (Lee, Raymond) Date: Mon, 20 Jun 2011 15:04:47 -0500 Subject: [tac_plus] Default authentication other than passwd file In-Reply-To: <20110620195620.GA17807@Oslo> References: <20110620195620.GA17807@Oslo> Message-ID: <41EE66689DFD3647AAE8E8CB28C2668B8697E47C28@qtomaexmbm21.AD.QINTRA.COM> Hi Brian, I was able to accomplish this on Ubuntu using a combination of info from the following: http://www.shrubbery.net/pipermail/tac_plus/2009-January/000332.html http://arthurdejong.org/nss-pam-ldapd/ Hope this helps. Ray > -----Original Message----- > From: tac_plus-bounces at shrubbery.net [mailto:tac_plus- > bounces at shrubbery.net] On Behalf Of tacplus at rhemasound.org > Sent: Monday, June 20, 2011 3:56 PM > To: tac_plus at shrubbery.net > Subject: [tac_plus] Default authentication other than passwd file > > Is it possible to use PAM instead of /etc/passwd file for default > authentication. I am trying to deploy an LDAP based system for tacacs > authentication. > > --- > Brian Raaen > ZCorum > braaen at zcorum.com > _______________________________________________ > tac_plus mailing list > tac_plus at shrubbery.net > http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From prozaconstilts at gmail.com Mon Jun 20 23:11:09 2011 From: prozaconstilts at gmail.com (Adam) Date: Mon, 20 Jun 2011 19:11:09 -0400 Subject: [tac_plus] Default authentication other than passwd file In-Reply-To: <20110620195620.GA17807@Oslo> References: <20110620195620.GA17807@Oslo> Message-ID: <4DFFD38D.2010809@gmail.com> On 6/20/2011 3:56 PM, tacplus at rhemasound.org wrote: > Is it possible to use PAM instead of /etc/passwd file for default authentication. I am trying to deploy an LDAP based system for tacacs authentication. > > --- > Brian Raaen > ZCorum > braaen at zcorum.com > _______________________________________________ > tac_plus mailing list > tac_plus at shrubbery.net > http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus To my knowledge, you cannot set the default login to pam, nor can you set the login for a group to pam. You must define users one by one and set 'login = pam' per user. But I haven't built tacacs since Jan 2009, so it might have changed since then... Adam From heas at shrubbery.net Tue Jun 21 00:03:21 2011 From: heas at shrubbery.net (john heasley) Date: Mon, 20 Jun 2011 19:03:21 -0500 Subject: [tac_plus] Default authentication other than passwd file In-Reply-To: <4DFFD38D.2010809@gmail.com> References: <20110620195620.GA17807@Oslo> <4DFFD38D.2010809@gmail.com> Message-ID: <20110621000321.GP29519@shrubbery.net> Mon, Jun 20, 2011 at 07:11:09PM -0400, Adam: > On 6/20/2011 3:56 PM, tacplus at rhemasound.org wrote: > >Is it possible to use PAM instead of /etc/passwd file for default authentication. I am trying to deploy an LDAP based system for tacacs authentication. > > > >--- > >Brian Raaen > >ZCorum > >braaen at zcorum.com > >_______________________________________________ > >tac_plus mailing list > >tac_plus at shrubbery.net > >http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus > To my knowledge, you cannot set the default login to pam, nor can > you set the login for a group to pam. You must define users one by > one and set 'login = pam' per user. But I haven't built tacacs since > Jan 2009, so it might have changed since then... i believe it will work DEFAULT = { login = PAM }