From Jamie.Reid at ed.act.edu.au Wed Apr 4 05:11:11 2012 From: Jamie.Reid at ed.act.edu.au (Reid, Jamie) Date: Wed, 4 Apr 2012 15:11:11 +1000 Subject: [tac_plus] Wireless-WCS HTTP with tac_plus Message-ID: <3AE6F4122CA9164389B80CBADED85E9C01489738F7DE@WOS-M-01.actedu.net.au> Hi Everyone, Has anyone had any luck (or knows the config I need to use) to get "Wireless-WCS HTTP" working with tac_plus? I can get ssh login working, but I cannot get the web interface to authenticate against tac_plus. Wed Mar 21 21:37:07 2012 [21336]: pap-login query for 'test_user' Wireless-WCS HTTP from 192.168.0.30 rejected I've tried a few different configurations in tac_plus.conf eg. user = test_user { login = cleartext password enable = cleartext password member = testgroup service = Wireless-WCS protocol = HTTP { role0 = "SuperUsers" } } But when I try to load the server it errors: [root at elvis tac_plus]# tac_plus -C ./tac_plus.conf -G Error: expecting '{' but found 'protocol' on line 32 If anyone has had any luck getting it to work, or has any suggestions, I'd love some help :) Thanks in advance, J -- This email remains the property of the ACT Education & Training Directorate. This transmission and any accompanying attachments may contain confidential or legally privileged information. If you are not the intended addressee, you are notified that any use or dissemination of this email is strictly forbidden. If you have received this communication in error please notify the sender immediately and delete all copies of this message. Opinions, conclusions, views and other information in this message that do not relate to the official business of ACT Education & Training Directorate are the views of the individual sender and shall be understood as neither given nor endorsed by ACT Education & Training Directorate. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jamie.Reid at ed.act.edu.au Wed Apr 4 06:12:50 2012 From: Jamie.Reid at ed.act.edu.au (Reid, Jamie) Date: Wed, 4 Apr 2012 16:12:50 +1000 Subject: [tac_plus] Wireless-WCS HTTP with tac_plus In-Reply-To: <3AE6F4122CA9164389B80CBADED85E9C01489738F7DE@WOS-M-01.actedu.net.au> References: <3AE6F4122CA9164389B80CBADED85E9C01489738F7DE@WOS-M-01.actedu.net.au> Message-ID: <3AE6F4122CA9164389B80CBADED85E9C01489738F806@WOS-M-01.actedu.net.au> Similarly, I'm having trouble with getting F5s to authenticate. All the info I can find on the internet suggests that I should be able to define a service like this: service = ppp protocol = ip { F5-LTM-User-Info-1 = adm } Unfortunately, whenever I add the 'protocol =' part of the config I get the following error: Error expecting '{' but found 'protocol' on line ## And not including that part of the line doesn't work either. Using version tac_plus server F4.0.4.23 Cheers, J > -----Original Message----- > From: tac_plus-bounces at shrubbery.net [mailto:tac_plus- > bounces at shrubbery.net] On Behalf Of Reid, Jamie > Sent: Wednesday, 4 April 2012 3:11 PM > To: tac_plus at shrubbery.net > Subject: [tac_plus] Wireless-WCS HTTP with tac_plus > > Hi Everyone, > > Has anyone had any luck (or knows the config I need to use) to get "Wireless- > WCS HTTP" working with tac_plus? > > I can get ssh login working, but I cannot get the web interface to authenticate > against tac_plus. > > Wed Mar 21 21:37:07 2012 [21336]: pap-login query for 'test_user' Wireless- > WCS HTTP from 192.168.0.30 rejected > > I've tried a few different configurations in tac_plus.conf eg. > > user = test_user { > login = cleartext password > enable = cleartext password > member = testgroup > service = Wireless-WCS protocol = HTTP { > role0 = "SuperUsers" > } > } > > But when I try to load the server it errors: > > [root at elvis tac_plus]# tac_plus -C ./tac_plus.conf -G > Error: expecting '{' but found 'protocol' on line 32 > > If anyone has had any luck getting it to work, or has any suggestions, I'd love > some help :) > > Thanks in advance, > J > > -- > This email remains the property of the ACT Education & Training Directorate. > This transmission and any accompanying attachments may contain > confidential or legally privileged information. If you are not the intended > addressee, you are notified that any use or dissemination of this email is > strictly forbidden. If you have received this communication in error please > notify the sender immediately and delete all copies of this message. > Opinions, conclusions, views and other information in this message that do > not relate to the official business of ACT Education & Training Directorate are > the views of the individual sender and shall be understood as neither given > nor endorsed by ACT Education & Training Directorate. > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > 09612/attachment.html> > _______________________________________________ > tac_plus mailing list > tac_plus at shrubbery.net > http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus -- This email remains the property of the ACT Education & Training Directorate. This transmission and any accompanying attachments may contain confidential or legally privileged information. If you are not the intended addressee, you are notified that any use or dissemination of this email is strictly forbidden. If you have received this communication in error please notify the sender immediately and delete all copies of this message. Opinions, conclusions, views and other information in this message that do not relate to the official business of ACT Education & Training Directorate are the views of the individual sender and shall be understood as neither given nor endorsed by ACT Education & Training Directorate. From heas at shrubbery.net Wed Apr 4 16:17:27 2012 From: heas at shrubbery.net (heasley) Date: Wed, 4 Apr 2012 16:17:27 +0000 Subject: [tac_plus] Wireless-WCS HTTP with tac_plus In-Reply-To: <3AE6F4122CA9164389B80CBADED85E9C01489738F806@WOS-M-01.actedu.net.au> References: <3AE6F4122CA9164389B80CBADED85E9C01489738F7DE@WOS-M-01.actedu.net.au> <3AE6F4122CA9164389B80CBADED85E9C01489738F806@WOS-M-01.actedu.net.au> Message-ID: <20120404161727.GG53195@shrubbery.net> Wed, Apr 04, 2012 at 04:12:50PM +1000, Reid, Jamie: > Similarly, I'm having trouble with getting F5s to authenticate. > > All the info I can find on the internet suggests that I should be able to define a service like this: > > service = ppp protocol = ip { > F5-LTM-User-Info-1 = adm > } that ought to work; it parses for me. perhaps the source of the error precedes this line? or perhaps you're using a version that is modified in some incompatible manner? > Unfortunately, whenever I add the 'protocol =' part of the config I get the following error: > > Error expecting '{' but found 'protocol' on line ## > > And not including that part of the line doesn't work either. > > Using version tac_plus server F4.0.4.23 > > Cheers, > J > > > > > > -----Original Message----- > > From: tac_plus-bounces at shrubbery.net [mailto:tac_plus- > > bounces at shrubbery.net] On Behalf Of Reid, Jamie > > Sent: Wednesday, 4 April 2012 3:11 PM > > To: tac_plus at shrubbery.net > > Subject: [tac_plus] Wireless-WCS HTTP with tac_plus > > > > Hi Everyone, > > > > Has anyone had any luck (or knows the config I need to use) to get "Wireless- > > WCS HTTP" working with tac_plus? > > > > I can get ssh login working, but I cannot get the web interface to authenticate > > against tac_plus. > > > > Wed Mar 21 21:37:07 2012 [21336]: pap-login query for 'test_user' Wireless- > > WCS HTTP from 192.168.0.30 rejected > > > > I've tried a few different configurations in tac_plus.conf eg. > > > > user = test_user { > > login = cleartext password > > enable = cleartext password > > member = testgroup > > service = Wireless-WCS protocol = HTTP { > > role0 = "SuperUsers" > > } > > } > > > > But when I try to load the server it errors: > > > > [root at elvis tac_plus]# tac_plus -C ./tac_plus.conf -G > > Error: expecting '{' but found 'protocol' on line 32 > > > > If anyone has had any luck getting it to work, or has any suggestions, I'd love > > some help :) > > > > Thanks in advance, > > J > > > > -- > > This email remains the property of the ACT Education & Training Directorate. > > This transmission and any accompanying attachments may contain > > confidential or legally privileged information. If you are not the intended > > addressee, you are notified that any use or dissemination of this email is > > strictly forbidden. If you have received this communication in error please > > notify the sender immediately and delete all copies of this message. > > Opinions, conclusions, views and other information in this message that do > > not relate to the official business of ACT Education & Training Directorate are > > the views of the individual sender and shall be understood as neither given > > nor endorsed by ACT Education & Training Directorate. > > -------------- next part -------------- > > An HTML attachment was scrubbed... > > URL: > > > 09612/attachment.html> > > _______________________________________________ > > tac_plus mailing list > > tac_plus at shrubbery.net > > http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus > > -- > This email remains the property of the ACT Education & Training Directorate. > This transmission and any accompanying attachments may contain confidential or > legally privileged information. If you are not the intended addressee, you > are notified that any use or dissemination of this email is strictly > forbidden. If you have received this communication in error please notify the > sender immediately and delete all copies of this message. Opinions, > conclusions, views and other information in this message that do not relate to > the official business of ACT Education & Training Directorate are the views of the > individual sender and shall be understood as neither given nor endorsed by ACT Education & Training Directorate. > _______________________________________________ > tac_plus mailing list > tac_plus at shrubbery.net > http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus From maddison at lightbound.net Wed Apr 4 17:37:51 2012 From: maddison at lightbound.net (Matt Addison) Date: Wed, 4 Apr 2012 17:37:51 +0000 Subject: [tac_plus] RSA SecurID / ACE Client Message-ID: A non-text attachment was scrubbed... Name: aceclnt.patch Type: application/octet-stream Size: 15807 bytes Desc: aceclnt.patch URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ATT00001.txt URL: From heas at shrubbery.net Thu Apr 5 20:15:21 2012 From: heas at shrubbery.net (heasley) Date: Thu, 5 Apr 2012 20:15:21 +0000 Subject: [tac_plus] RSA SecurID / ACE Client In-Reply-To: References: Message-ID: <20120405201521.GO93425@shrubbery.net> is there are a reason that you chose this direction as opposed to simply using the securid PAM module that they make available [and i presume that they still make it available]? From matt.addison at lists.evilgeni.us Fri Apr 6 00:10:49 2012 From: matt.addison at lists.evilgeni.us (Matt Addison) Date: Thu, 5 Apr 2012 20:10:49 -0400 Subject: [tac_plus] RSA SecurID / ACE Client In-Reply-To: References: <20120405201521.GO93425@shrubbery.net> Message-ID: On Thu, Apr 5, 2012 at 16:15, heasley wrote: > > is there are a reason that you chose this direction as opposed to simply > using the securid PAM module that they make available [and i presume that > they still make it available]? In our case we were already using the tac_plus PAM option for centralized authentication (LDAP/Kerberos) for user login passwords. This patch allows us to use centralized information for login via PAM and still use RSA for enable. There are also some potentially interesting opportunities with direct ACE client integration, such as using the NAS or client IP addresses as the authentication source to do additional access restriction and logging at the RSA authentication manager (especially if different groups are responsible for systems/network). I've POC'd this but have not investigated implementing configuration options for it. ~Matt From cosmin.neagu at omnilogic.ro Tue Apr 10 14:00:02 2012 From: cosmin.neagu at omnilogic.ro (Cosmin Neagu) Date: Tue, 10 Apr 2012 17:00:02 +0300 Subject: [tac_plus] Question about logging with tac_plus Message-ID: <4F843CE2.5000002@omnilogic.ro> Hi, I want to know if it is posible to make tac_plus log into the default log file ( tac_plus.log ) logs when users ask for access on network equipment: Something like: Tue Apr 10 09:41:36 2012 : Auth: Login OK: [cosmin/parola] (from client 172.31.1.211 port 1) where 172.31.1.211 is the network equipment who asket tacacs for access on behalf of the user. I searched on internet but except: accounting file = /var/log/tac_plus.acct I did not find anything regarding logging user attempts to connect. Thanks. -- Cosmin Neagu NOC Team Leader Str. I. G. Duca nr. 36 Otopeni, Judetul Ilfov, 075100 Romania www.omnilogic.ro From heas at shrubbery.net Tue Apr 10 22:39:21 2012 From: heas at shrubbery.net (heasley) Date: Tue, 10 Apr 2012 15:39:21 -0700 Subject: [tac_plus] Question about logging with tac_plus In-Reply-To: <4F843CE2.5000002@omnilogic.ro> References: <4F843CE2.5000002@omnilogic.ro> Message-ID: <20120410223921.GX65070@shrubbery.net> Tue, Apr 10, 2012 at 05:00:02PM +0300, Cosmin Neagu: > Hi, > I want to know if it is posible to make tac_plus log into the default > log file ( tac_plus.log ) logs when users ask for access on network > equipment: > Something like: > Tue Apr 10 09:41:36 2012 : Auth: Login OK: [cosmin/parola] (from client > 172.31.1.211 port 1) > > where 172.31.1.211 is the network equipment who asket tacacs for access > on behalf of the user. > > I searched on internet but except: > accounting file = /var/log/tac_plus.acct > I did not find anything regarding logging user attempts to connect. or accounting syslog accouting is generated by the device, not the daemon. the daemon just receives the records. other logging goes to syslog loggging = syslog_facility or specify a file with the -l option. login failures are logged, like Apr 10 22:38:34 guelah tac_plus[77645]: connect from 198.58.5.127 [198.58.5.127] Apr 10 22:38:38 guelah tac_plus[77645]: login failure: heas 198.58.5.127 (198.58.5.127) tty2 From cosmin.neagu at omnilogic.ro Wed Apr 11 06:58:32 2012 From: cosmin.neagu at omnilogic.ro (Cosmin Neagu) Date: Wed, 11 Apr 2012 09:58:32 +0300 Subject: [tac_plus] Question about logging with tac_plus In-Reply-To: <20120410223921.GX65070@shrubbery.net> References: <4F843CE2.5000002@omnilogic.ro> <20120410223921.GX65070@shrubbery.net> Message-ID: <4F852B98.6090403@omnilogic.ro> Yes, that is exactly what i want to achieve I found this in the man pages (nothing about a -l option) " logging Specifies the syslog(3) facility used. By default, logs are posted to the daemon facility. logging = " I tried to enter the following in tac_plus.conf: logging = syslog_facility //it gives: tac_plus[7181]: Error expecting syslog facility on line 7, got syslog_facility I read about sysylog facilities and it seems to be a number meaning something logging = 10 //it gives tac_plus[7393]: Error expecting syslog facility on line 7, got 10 logging = syslog //does not give anymore error when starting but no logs apear in /var/log/syslog or /var/log/tac_plus.log Can you help me this or point me to some documentation about how to do this logging? Cosmin Neagu NOC Team Leader Str. I. G. Duca nr. 36 Otopeni, Judetul Ilfov, 075100 Romania Tel: 021 303 3159 / 0732 669 193 www.omnilogic.ro On 04/11/2012 01:39 AM, heasley wrote: > Tue, Apr 10, 2012 at 05:00:02PM +0300, Cosmin Neagu: >> Hi, >> I want to know if it is posible to make tac_plus log into the default >> log file ( tac_plus.log ) logs when users ask for access on network >> equipment: >> Something like: >> Tue Apr 10 09:41:36 2012 : Auth: Login OK: [cosmin/parola] (from client >> 172.31.1.211 port 1) >> >> where 172.31.1.211 is the network equipment who asket tacacs for access >> on behalf of the user. >> >> I searched on internet but except: >> accounting file = /var/log/tac_plus.acct >> I did not find anything regarding logging user attempts to connect. > or accounting syslog > > accouting is generated by the device, not the daemon. the daemon just > receives the records. > > other logging goes to syslog > > loggging = syslog_facility > > or specify a file with the -l option. login failures are logged, like > > Apr 10 22:38:34 guelah tac_plus[77645]: connect from 198.58.5.127 [198.58.5.127] > Apr 10 22:38:38 guelah tac_plus[77645]: login failure: heas 198.58.5.127 (198.58.5.127) tty2 > From alan.mckinnon at gmail.com Wed Apr 11 15:18:18 2012 From: alan.mckinnon at gmail.com (Alan McKinnon) Date: Wed, 11 Apr 2012 17:18:18 +0200 Subject: [tac_plus] Question about logging with tac_plus In-Reply-To: <4F852B98.6090403@omnilogic.ro> References: <4F843CE2.5000002@omnilogic.ro> <20120410223921.GX65070@shrubbery.net> <4F852B98.6090403@omnilogic.ro> Message-ID: <20120411171818.76d5de34@khamul.example.com> On Wed, 11 Apr 2012 09:58:32 +0300 Cosmin Neagu wrote: > Yes, that is exactly what i want to achieve > > I found this in the man pages (nothing about a -l option) > > " logging > Specifies the syslog(3) facility used. By default, > logs are posted to the daemon facility. > > logging = " > > I tried to enter the following in tac_plus.conf: > > logging = syslog_facility //it gives: tac_plus[7181]: Error > expecting syslog facility on line 7, got syslog_facility A syslog facility is a very specific thing and you cannot customize them. They have names like KERN, DAEMON, SECURITY and LOCAL0 to LOCAL7 They are documented in man 3 syslog Most folks use facility DAEMON or AUTH, or perhaps one of LOCAL* (you get to figure out for yourself how you will arrange those). You then need to configure your syslogger to do the correct thing with the log entries when it receives them from tac_plus. > > I read about sysylog facilities and it seems to be a number meaning > something > logging = 10 //it gives tac_plus[7393]: Error > expecting syslog facility on line 7, got 10 > > logging = syslog //does not give anymore error when starting > but no logs apear in > /var/log/syslog or /var/log/tac_plus.log > > Can you help me this or point me to some documentation about how to > do this logging? > > > Cosmin Neagu > NOC Team Leader > Str. I. G. Duca nr. 36 > Otopeni, Judetul Ilfov, 075100 Romania > Tel: 021 303 3159 / 0732 669 193 > www.omnilogic.ro > > > On 04/11/2012 01:39 AM, heasley wrote: > > Tue, Apr 10, 2012 at 05:00:02PM +0300, Cosmin Neagu: > >> Hi, > >> I want to know if it is posible to make tac_plus log into the > >> default log file ( tac_plus.log ) logs when users ask for access > >> on network equipment: > >> Something like: > >> Tue Apr 10 09:41:36 2012 : Auth: Login OK: [cosmin/parola] (from > >> client 172.31.1.211 port 1) > >> > >> where 172.31.1.211 is the network equipment who asket tacacs for > >> access on behalf of the user. > >> > >> I searched on internet but except: > >> accounting file = /var/log/tac_plus.acct > >> I did not find anything regarding logging user attempts to connect. > > or accounting syslog > > > > accouting is generated by the device, not the daemon. the daemon > > just receives the records. > > > > other logging goes to syslog > > > > loggging = syslog_facility > > > > or specify a file with the -l option. login failures are logged, > > like > > > > Apr 10 22:38:34 guelah tac_plus[77645]: connect from 198.58.5.127 > > [198.58.5.127] Apr 10 22:38:38 guelah tac_plus[77645]: login > > failure: heas 198.58.5.127 (198.58.5.127) tty2 > > > _______________________________________________ > tac_plus mailing list > tac_plus at shrubbery.net > http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus -- Alan McKinnnon alan.mckinnon at gmail.com From ivanlk3 at gmail.com Thu Apr 12 12:24:38 2012 From: ivanlk3 at gmail.com (ivo) Date: Thu, 12 Apr 2012 14:24:38 +0200 Subject: [tac_plus] TACACS+ Error socket issue. In-Reply-To: <20120329222811.GL19110@shrubbery.net> References: <20120329175555.GX19110@shrubbery.net> <20120329222811.GL19110@shrubbery.net> Message-ID: Hi Guys, thanks for help and ideas really apreaciate it. Here is the solution which helped to avoid error message: Error get_socket: bind xxxx Address already in use when restarting tacacs process which is running on backround example: root 3543 /usr/local/bin/tac_plus -C /etc/tacacs+/SW4_tac_plus.conf -l /var/log/tacacs/SW4_tac_plus.log -d 16 -p 5024 Algorithm: 1.add process_name 2. export pid of the process_name 3. gracefull kill of pid 4. wait 2 seconds 5. check if pid of process_name exist 6. if process name doesnt exist start again the same process else if process name still exist force kill of the process again wait one second and start again the same process. bash code: ########### RESTART ############ tac_process="/usr/local/bin/tac_plus -C /etc/tacacs+/SW4_tac_plus.conf -l /var/log/tacacs/SW4_tac_plus.log -d 16 -p 5024 export tacpid_before=`ps aux | grep "$tac_process" | grep -v grep | awk '{print $2}'` `kill -15 $tacpid` sleep 2 export tacpid=`ps aux | grep "$tac_process" | grep -v grep | awk '{print $2}'` if [ "$tacpid" == "" ];then echo 'Tacacs for '$name' with port:'$tacacs_port' Pid:'$tacpid_before' stopped (first attempt)!' `$tac_process` export tacpid=`ps aux | grep "$tac_process" | grep -v grep | awk '{print $2}'` echo 'Tacacs for '$name' with port:'$tacacs_port' Pid:'$tacpid' started (first attempt)!' exit else `kill -9 $tacpid` sleep 1 echo 'Tacacs for '$name' with port:'$tacacs_port' Pid:'$tacpid_before' stopped (second attempt)!' `$tac_process` export tacpid=`ps aux | grep "$tac_process" | grep -v grep | awk '{print $2}'` echo 'Tacacs for '$name' with port:'$tacacs_port' Pid:'$tacpid' started (second attempt)!' exit fi ----------------------------------------------------------------------------------------------------------- D?a 30. marca 2012 0:28, heasley nap?sal/a: > Thu, Mar 29, 2012 at 04:27:09PM -0600, Daniel Schmidt: >> pgrep tac_plus will tell u if anything >> survived > > and/or lsof for the specific port Thu, Mar 29, 2012 at 07:37:34PM +0200, ivo: > kill -9 > /usr/local/bin/tac_plus -C /etc/tacacs+/R1_tac_plus.conf -l > /var/log/tacacs/R1_tac_plus.log -d 16 -p 5000 > > I recieve error into R1_tac_plus.log: > Version F4.0.4.19 Initialized 1 > tac_plus server F4.0.4.19 starting > Backgrounded > Error get_socket: bind 5000 Address already in use make sure that it has actually died. pkill tac_plus -----Original Message----- From: tac_plus-bounces at shrubbery.net [mailto:tac_plus-bounces at shrubbery.net] On Behalf Of ivo Sent: Thursday, March 29, 2012 11:38 AM To: tac_plus at shrubbery.net Cc: trubela at gmail.com Subject: [tac_plus] TACACS+ Error socket issue. Hi Guys, I need some help with starting and stoping tacacs. I have several tacacs+ processes running on the backround linux red hat enterprise server. Tacacs+ version which I use is F4.0.4.19. The command which I use to start the tacacs processes are: /usr/local/bin/tac_plus -C /etc/tacacs+/R1_tac_plus.conf -l /var/log/tacacs/R1_tac_plus.log -d 16 -p 5000 /usr/local/bin/tac_plus -C /etc/tacacs+/R2_tac_plus.conf -l /var/log/tacacs/R2_tac_plus.log -d 16 -p 5001 /usr/local/bin/tac_plus -C /etc/tacacs+/R3_tac_plus.conf -l /var/log/tacacs/R3_tac_plus.log -d 16 -p 5002 when I run the tacacs it works fine. But the problem is with stop of the tacacs. I am using to stop tacacs on backround kill -9 I am not familiar how start and stop of tacacs+ work. Could me please somebody write a hint how to regular restart (stop and start ) tacacs+ process from above backround processes ? When i "restart" tacacs+ process : kill -9 /usr/local/bin/tac_plus -C /etc/tacacs+/R1_tac_plus.conf -l /var/log/tacacs/R1_tac_plus.log -d 16 -p 5000 I recieve error into R1_tac_plus.log: Version F4.0.4.19 Initialized 1 tac_plus server F4.0.4.19 starting Backgrounded Error get_socket: bind 5000 Address already in use Do anybody know how to regular stop and start tacacs process? -- http://www.gmail.com From heas at shrubbery.net Mon Apr 16 22:03:55 2012 From: heas at shrubbery.net (heasley) Date: Mon, 16 Apr 2012 15:03:55 -0700 Subject: [tac_plus] RSA SecurID / ACE Client In-Reply-To: References: <20120405201521.GO93425@shrubbery.net> Message-ID: <20120416220355.GB892@shrubbery.net> Thu, Apr 05, 2012 at 08:10:49PM -0400, Matt Addison: > On Thu, Apr 5, 2012 at 16:15, heasley wrote: > > > > is there are a reason that you chose this direction as opposed to simply > > using the securid PAM module that they make available [and i presume that > > they still make it available]? > > In our case we were already using the tac_plus PAM option for > centralized authentication (LDAP/Kerberos) for user login passwords. > This patch allows us to use centralized information for login via PAM > and still use RSA for enable. > > There are also some potentially interesting opportunities with direct > ACE client integration, such as using the NAS or client IP addresses > as the authentication source to do additional access restriction and > logging at the RSA authentication manager (especially if different > groups are responsible for systems/network). I've POC'd this but have > not investigated implementing configuration options for it. > > ~Matt is this commented-out code intentional? static int aceclnt_verify(char *name, char *passwd, struct authen_data *data) { struct private_data *p = data->method_data; SDI_HANDLE SdiHandle = p->SdiHandle; int acmRet; data->status = TAC_PLUS_AUTHEN_STATUS_FAIL; /* if (aceclntverify(aceclntp, passwd) == 0) { *//* S/Key authentication succeeded *//* data->status = TAC_PLUS_AUTHEN_STATUS_PASS; if (aceclntp->n < 5) { data->server_msg = tac_strdup("Password will expire soon"); return(1); } } */ acmRet = SD_Check(SdiHandle, passwd, name); if (acmRet == ACM_OK) data->status = TAC_PLUS_AUTHEN_STATUS_PASS; return(0); } have you tested enabling with aceclnt? From heas at shrubbery.net Mon Apr 16 22:27:17 2012 From: heas at shrubbery.net (heasley) Date: Mon, 16 Apr 2012 15:27:17 -0700 Subject: [tac_plus] RSA SecurID / ACE Client In-Reply-To: <20120416220355.GB892@shrubbery.net> References: <20120405201521.GO93425@shrubbery.net> <20120416220355.GB892@shrubbery.net> Message-ID: <20120416222717.GD892@shrubbery.net> Mon, Apr 16, 2012 at 03:03:55PM -0700, heasley: > Thu, Apr 05, 2012 at 08:10:49PM -0400, Matt Addison: > > On Thu, Apr 5, 2012 at 16:15, heasley wrote: > > > > > > is there are a reason that you chose this direction as opposed to simply > > > using the securid PAM module that they make available [and i presume that > > > they still make it available]? > > > > In our case we were already using the tac_plus PAM option for > > centralized authentication (LDAP/Kerberos) for user login passwords. > > This patch allows us to use centralized information for login via PAM > > and still use RSA for enable. > > > > There are also some potentially interesting opportunities with direct > > ACE client integration, such as using the NAS or client IP addresses > > as the authentication source to do additional access restriction and > > logging at the RSA authentication manager (especially if different > > groups are responsible for systems/network). I've POC'd this but have > > not investigated implementing configuration options for it. > > > > ~Matt > > is this commented-out code intentional? > > static int > aceclnt_verify(char *name, char *passwd, struct authen_data *data) > { > struct private_data *p = data->method_data; > SDI_HANDLE SdiHandle = p->SdiHandle; > int acmRet; > > data->status = TAC_PLUS_AUTHEN_STATUS_FAIL; > > /* > if (aceclntverify(aceclntp, passwd) == 0) { > *//* S/Key authentication succeeded *//* > data->status = TAC_PLUS_AUTHEN_STATUS_PASS; > if (aceclntp->n < 5) { > data->server_msg = tac_strdup("Password will expire soon"); > return(1); > } > } */ > acmRet = SD_Check(SdiHandle, passwd, name); > if (acmRet == ACM_OK) > data->status = TAC_PLUS_AUTHEN_STATUS_PASS; > return(0); > } > > have you tested enabling with aceclnt? also, is there not a library to link with that you have missed in Makefile.am? From prozaconstilts at gmail.com Sun Apr 22 14:39:22 2012 From: prozaconstilts at gmail.com (Adam Allred) Date: Sun, 22 Apr 2012 10:39:22 -0400 Subject: [tac_plus] AD version of the pam guide Message-ID: Hi all, Over the years, I've gotten a few people asking about how to do AD authentication with tac_plus and PAM. I finally sat down and modified the original pam guide to be AD specific. It's not very much different; the changes are listed here, and the full document attached: 1. Install the pam-devel package and tcp_wrappers via yum: yum install pam-devel tcp_wrappers pam_krb5 ... ... 9. For AD, we'll use kerberos auth rather than a plain ol' LDAP bind, so instead of pam_ldap in our pam conf, we'll replace with pam_krb5: vi /etc/pam.d/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_krb5.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_krb5.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_krb5.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_krb5.so Note that this config also works well for system-auth. If you want all authentication for your server to use AD (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 /etc/krb5.conf. This is where you will specify where to find your AD server. First, define a realm: [realms] MY.REALMS.DOMAIN = { kdc = myadserver.my.realms.domain admin_server = myadserver.my.realms.domain } set that realm as the default realm: [libdefaults] default_realm = MY.REALMS.DOMAIN And that *should* be enough. There are many other options that can be set in krb5.conf depending on your AD setup. For example, our AD's domain is not configured to be the actual DNS domain in which it resides. Since kerberos makes use of DNS for certain SRV records, our krb5.conf has the [domain_realm] section which maps the DNS domain to kerberos realm. All in all, YMMV, and you may need to poke your krb5.conf some more. Luckily, we can easily test if kerberos auth is working, before we try to lay tac_plus or PAM over it. After configuring your krb5.conf, you can use kinit to test the auth. Simply type 'kinit ' into your terminal session. The default realm should be appended, and you should see a prompt: Password for @MY.REALMS.DOMAIN: Type in your password, press return, and if you get a prompt back, then it works. You can then klist to see your kerberos principal, and kdestroy to remove it. -------------- next part -------------- 1. Install the pam-devel package and tcp_wrappers via yum: yum install pam-devel tcp_wrappers pam_krb5 2. Obtain the latest tac_plus from ftp://ftp.shrubbery.net/pub/tac_plus/ 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. For AD, we'll use kerberos auth rather than a plain ol' LDAP bind, so instead of pam_ldap in our pam conf, we'll replace with pam_krb5: vi /etc/pam.d/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_krb5.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_krb5.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_krb5.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_krb5.so Note that this config also works well for system-auth. If you want all authentication for your server to use AD (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 /etc/krb5.conf. This is where you will specify where to find your AD server. First, define a realm: [realms] MY.REALMS.DOMAIN = { kdc = myadserver.my.realms.domain admin_server = myadserver.my.realms.domain } set that realm as the default realm: [libdefaults] default_realm = MY.REALMS.DOMAIN And that *should* be enough. There are many other options that can be set in krb5.conf depending on your AD setup. For example, our AD's domain is not configured to be the actual DNS domain in which it resides. Since kerberos makes use of DNS for certain SRV records, our krb5.conf has the [domain_realm] section which maps the DNS domain to kerberos realm. All in all, YMMV, and you may need to poke your krb5.conf some more. Luckily, we can easily test if kerberos auth is working, before we try to lay tac_plus or PAM over it. After configuring your krb5.conf, you can use kinit to test the auth. Simply type 'kinit ' into your terminal session. The default realm should be appended, and you should see a prompt: Password for @MY.REALMS.DOMAIN: Type in your password, press return, and if you get a prompt back, then it works. You can then klist to see your kerberos principal, and kdestroy to remove 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. From daniel.schmidt at wyo.gov Mon Apr 23 21:32:44 2012 From: daniel.schmidt at wyo.gov (Daniel Schmidt) Date: Mon, 23 Apr 2012 15:32:44 -0600 Subject: [tac_plus] AD version of the pam guide In-Reply-To: References: Message-ID: Thanks much! Strange, I get "Unknown user" at tac_plus debug, though kinit/klist appears to work just fine. Config is correct - there isn't much you can mess up. Any ideas appreciated. [root at dufus ~]# egrep 1877 tac_log.txt Mon Apr 23 14:48:43 2012 [1877]: connect from 1.1.1.1 [1.1.1.1] Mon Apr 23 14:48:43 2012 [1877]: pam_verify homer Mon Apr 23 14:48:43 2012 [1877]: pam_tacacs received 1 pam_messages Mon Apr 23 14:48:43 2012 [1877]: 1.1.1.1 tty1: PAM_PROMPT_ECHO_OFF Mon Apr 23 14:48:46 2012 [1877]: Unknown user Mon Apr 23 14:48:46 2012 [1877]: login query for 'homer' tty1 from 1.1.1.1 rejected Mon Apr 23 14:48:46 2012 [1877]: login failure: homer 1.1.1.1 (1.1.1.1) tty1 user = homer { member = same_group_as_everybody login = PAM pap = PAM } -----Original Message----- From: tac_plus-bounces at shrubbery.net [mailto:tac_plus-bounces at shrubbery.net] On Behalf Of Adam Allred Sent: Sunday, April 22, 2012 8:39 AM To: tac_plus at shrubbery.net Cc: renat at vtxinc.com Subject: [tac_plus] AD version of the pam guide Hi all, Over the years, I've gotten a few people asking about how to do AD authentication with tac_plus and PAM. I finally sat down and modified the original pam guide to be AD specific. It's not very much different; the changes are listed here, and the full document attached: 1. Install the pam-devel package and tcp_wrappers via yum: yum install pam-devel tcp_wrappers pam_krb5 ... ... 9. For AD, we'll use kerberos auth rather than a plain ol' LDAP bind, so instead of pam_ldap in our pam conf, we'll replace with pam_krb5: vi /etc/pam.d/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_krb5.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_krb5.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_krb5.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_krb5.so Note that this config also works well for system-auth. If you want all authentication for your server to use AD (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 /etc/krb5.conf. This is where you will specify where to find your AD server. First, define a realm: [realms] MY.REALMS.DOMAIN = { kdc = myadserver.my.realms.domain admin_server = myadserver.my.realms.domain } set that realm as the default realm: [libdefaults] default_realm = MY.REALMS.DOMAIN And that *should* be enough. There are many other options that can be set in krb5.conf depending on your AD setup. For example, our AD's domain is not configured to be the actual DNS domain in which it resides. Since kerberos makes use of DNS for certain SRV records, our krb5.conf has the [domain_realm] section which maps the DNS domain to kerberos realm. All in all, YMMV, and you may need to poke your krb5.conf some more. Luckily, we can easily test if kerberos auth is working, before we try to lay tac_plus or PAM over it. After configuring your krb5.conf, you can use kinit to test the auth. Simply type 'kinit ' into your terminal session. The default realm should be appended, and you should see a prompt: Password for @MY.REALMS.DOMAIN: Type in your password, press return, and if you get a prompt back, then it works. You can then klist to see your kerberos principal, and kdestroy to remove it. -------------- next part -------------- 1. Install the pam-devel package and tcp_wrappers via yum: yum install pam-devel tcp_wrappers pam_krb5 2. Obtain the latest tac_plus from ftp://ftp.shrubbery.net/pub/tac_plus/ 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. For AD, we'll use kerberos auth rather than a plain ol' LDAP bind, so instead of pam_ldap in our pam conf, we'll replace with pam_krb5: vi /etc/pam.d/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_krb5.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_krb5.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_krb5.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_krb5.so Note that this config also works well for system-auth. If you want all authentication for your server to use AD (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 /etc/krb5.conf. This is where you will specify where to find your AD server. First, define a realm: [realms] MY.REALMS.DOMAIN = { kdc = myadserver.my.realms.domain admin_server = myadserver.my.realms.domain } set that realm as the default realm: [libdefaults] default_realm = MY.REALMS.DOMAIN And that *should* be enough. There are many other options that can be set in krb5.conf depending on your AD setup. For example, our AD's domain is not configured to be the actual DNS domain in which it resides. Since kerberos makes use of DNS for certain SRV records, our krb5.conf has the [domain_realm] section which maps the DNS domain to kerberos realm. All in all, YMMV, and you may need to poke your krb5.conf some more. Luckily, we can easily test if kerberos auth is working, before we try to lay tac_plus or PAM over it. After configuring your krb5.conf, you can use kinit to test the auth. Simply type 'kinit ' into your terminal session. The default realm should be appended, and you should see a prompt: Password for @MY.REALMS.DOMAIN: Type in your password, press return, and if you get a prompt back, then it works. You can then klist to see your kerberos principal, and kdestroy to remove 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. _______________________________________________ tac_plus mailing list tac_plus at shrubbery.net http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus E-Mail to and from me, in connection with the transaction of public business, is subject to the Wyoming Public Records Act and may be disclosed to third parties. From prozaconstilts at gmail.com Tue Apr 24 20:47:49 2012 From: prozaconstilts at gmail.com (Adam Allred) Date: Tue, 24 Apr 2012 16:47:49 -0400 Subject: [tac_plus] AD version of the pam guide In-Reply-To: References: Message-ID: hmm...perhaps that's pam_unix saying that (though my pam conf has pam_unix first, and I don't get that line). Try placing pam_krb5 above pam_unix in the auth section of the pam conf file, and moving use_first_pass down to pam_unix. But be careful...if that makes your pam stack unhappy, you may be unable to login with local accounts...like root, etc. If your tac_plus pam conf is simply including system-auth, I recommend breaking that inheritance, and having a full pam stack defined in /etc/pam.d/tac_plus. Adam On Mon, Apr 23, 2012 at 5:32 PM, Daniel Schmidt wrote: > Thanks much! > > Strange, I get "Unknown user" at tac_plus debug, though kinit/klist > appears to work just fine. ?Config is correct - there isn't much you can > mess up. ?Any ideas appreciated. > > [root at dufus ~]# egrep 1877 tac_log.txt > Mon Apr 23 14:48:43 2012 [1877]: connect from 1.1.1.1 [1.1.1.1] > Mon Apr 23 14:48:43 2012 [1877]: pam_verify homer > Mon Apr 23 14:48:43 2012 [1877]: pam_tacacs received 1 pam_messages > Mon Apr 23 14:48:43 2012 [1877]: 1.1.1.1 tty1: PAM_PROMPT_ECHO_OFF > Mon Apr 23 14:48:46 2012 [1877]: Unknown user > Mon Apr 23 14:48:46 2012 [1877]: login query for 'homer' tty1 from 1.1.1.1 > rejected > Mon Apr 23 14:48:46 2012 [1877]: login failure: homer 1.1.1.1 (1.1.1.1) > tty1 > > user = homer ?{ > ? ? ? ?member = same_group_as_everybody > ? ? ? ?login = PAM > ? ? ? ?pap = PAM > } > > -----Original Message----- > From: tac_plus-bounces at shrubbery.net > [mailto:tac_plus-bounces at shrubbery.net] On Behalf Of Adam Allred > Sent: Sunday, April 22, 2012 8:39 AM > To: tac_plus at shrubbery.net > Cc: renat at vtxinc.com > Subject: [tac_plus] AD version of the pam guide > > Hi all, > > Over the years, I've gotten a few people asking about how to do AD > authentication with tac_plus and PAM. I finally sat down and modified the > original pam guide to be AD specific. It's not very much different; the > changes are listed here, and the full document > attached: > > 1. Install the pam-devel package and tcp_wrappers via yum: > > ? ? ?yum install pam-devel tcp_wrappers pam_krb5 > > ... > ... > > 9. For AD, we'll use kerberos auth rather than a plain ol' LDAP bind, so > instead of pam_ldap in our pam conf, we'll replace with pam_krb5: > > ? ? ?vi /etc/pam.d/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_krb5.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_krb5.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_krb5.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_krb5.so > > Note that this config also works well for system-auth. If you want all > authentication for your server to use AD (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 /etc/krb5.conf. This is where you will specify where to > find your AD server. First, define a realm: > > [realms] > ?MY.REALMS.DOMAIN = { > ?kdc = myadserver.my.realms.domain > ?admin_server = myadserver.my.realms.domain ?} > > set that realm as the default realm: > > [libdefaults] > ?default_realm = MY.REALMS.DOMAIN > > And that *should* be enough. There are many other options that can be set > in krb5.conf depending on your AD setup. For example, our AD's domain is > not configured to be the actual DNS domain in which it resides. Since > kerberos makes use of DNS for certain SRV records, our krb5.conf has the > [domain_realm] section which maps the DNS domain to kerberos realm. All in > all, YMMV, and you may need to poke your krb5.conf some more. > > Luckily, we can easily test if kerberos auth is working, before we try to > lay tac_plus or PAM over it. After configuring your krb5.conf, you can use > kinit to test the auth. Simply type 'kinit ' into your > terminal session. The default realm should be appended, and you should see > a prompt: > > Password for @MY.REALMS.DOMAIN: > > Type in your password, press return, and if you get a prompt back, then it > works. You can then klist to see your kerberos principal, and kdestroy to > remove it. > -------------- next part -------------- > 1. Install the pam-devel package and tcp_wrappers via yum: > > ? ? ?yum install pam-devel tcp_wrappers pam_krb5 > > 2. Obtain the latest tac_plus from ftp://ftp.shrubbery.net/pub/tac_plus/ > > 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. For AD, we'll use kerberos auth rather than a plain ol' LDAP bind, so > instead of pam_ldap in our pam conf, we'll replace with pam_krb5: > > ? ? ?vi /etc/pam.d/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_krb5.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_krb5.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_krb5.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_krb5.so > > Note that this config also works well for system-auth. If you want all > authentication for your server to use AD (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 /etc/krb5.conf. This is where you will specify where to > find your AD server. First, define a realm: > > [realms] > ?MY.REALMS.DOMAIN = { > ?kdc = myadserver.my.realms.domain > ?admin_server = myadserver.my.realms.domain ?} > > set that realm as the default realm: > > [libdefaults] > ?default_realm = MY.REALMS.DOMAIN > > And that *should* be enough. There are many other options that can be set > in krb5.conf depending on your AD setup. For example, our AD's domain is > not configured to be the actual DNS domain in which it resides. Since > kerberos makes use of DNS for certain SRV records, our krb5.conf has the > [domain_realm] section which maps the DNS domain to kerberos realm. All in > all, YMMV, and you may need to poke your krb5.conf some more. > > Luckily, we can easily test if kerberos auth is working, before we try to > lay tac_plus or PAM over it. After configuring your krb5.conf, you can use > kinit to test the auth. Simply type 'kinit ' into your > terminal session. The default realm should be appended, and you should see > a prompt: > > Password for @MY.REALMS.DOMAIN: > > Type in your password, press return, and if you get a prompt back, then it > works. You can then klist to see your kerberos principal, and kdestroy to > remove 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. > _______________________________________________ > tac_plus mailing list > tac_plus at shrubbery.net > http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus > E-Mail to and from me, in connection with the transaction > of public business, is subject to the Wyoming Public Records > Act and may be disclosed to third parties. > From daniel.schmidt at wyo.gov Tue Apr 24 23:11:28 2012 From: daniel.schmidt at wyo.gov (Daniel Schmidt) Date: Tue, 24 Apr 2012 17:11:28 -0600 Subject: [tac_plus] AD version of the pam guide In-Reply-To: References: Message-ID: <5a3309614b5c6a13a99427d13237c4d9@mail.gmail.com> Thanks much for the suggestions. I tried this, but it also did not appear to work. Apologies, I know very little about PAM. # cat /etc/pam.d/tac_plus auth required pam_env.so auth sufficient pam_krb5.so use_first_pass auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 500 quiet 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_krb5.so account required pam_permit.so password requisite pam_cracklib.so try_first_pass retry=3 password sufficient pam_krb5.so use_authtok password sufficient pam_unix.so md5 shadow nullok try_first_pass 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_krb5.so -----Original Message----- From: Adam Allred [mailto:prozaconstilts at gmail.com] Sent: Tuesday, April 24, 2012 2:48 PM To: Daniel Schmidt Cc: tac_plus at shrubbery.net Subject: Re: [tac_plus] AD version of the pam guide hmm...perhaps that's pam_unix saying that (though my pam conf has pam_unix first, and I don't get that line). Try placing pam_krb5 above pam_unix in the auth section of the pam conf file, and moving use_first_pass down to pam_unix. But be careful...if that makes your pam stack unhappy, you may be unable to login with local accounts...like root, etc. If your tac_plus pam conf is simply including system-auth, I recommend breaking that inheritance, and having a full pam stack defined in /etc/pam.d/tac_plus. Adam On Mon, Apr 23, 2012 at 5:32 PM, Daniel Schmidt wrote: > Thanks much! > > Strange, I get "Unknown user" at tac_plus debug, though kinit/klist > appears to work just fine. ?Config is correct - there isn't much you can > mess up. ?Any ideas appreciated. > > [root at dufus ~]# egrep 1877 tac_log.txt > Mon Apr 23 14:48:43 2012 [1877]: connect from 1.1.1.1 [1.1.1.1] > Mon Apr 23 14:48:43 2012 [1877]: pam_verify homer > Mon Apr 23 14:48:43 2012 [1877]: pam_tacacs received 1 pam_messages > Mon Apr 23 14:48:43 2012 [1877]: 1.1.1.1 tty1: PAM_PROMPT_ECHO_OFF > Mon Apr 23 14:48:46 2012 [1877]: Unknown user > Mon Apr 23 14:48:46 2012 [1877]: login query for 'homer' tty1 from 1.1.1.1 > rejected > Mon Apr 23 14:48:46 2012 [1877]: login failure: homer 1.1.1.1 (1.1.1.1) > tty1 > > user = homer ?{ > ? ? ? ?member = same_group_as_everybody > ? ? ? ?login = PAM > ? ? ? ?pap = PAM > } > > -----Original Message----- > From: tac_plus-bounces at shrubbery.net > [mailto:tac_plus-bounces at shrubbery.net] On Behalf Of Adam Allred > Sent: Sunday, April 22, 2012 8:39 AM > To: tac_plus at shrubbery.net > Cc: renat at vtxinc.com > Subject: [tac_plus] AD version of the pam guide > > Hi all, > > Over the years, I've gotten a few people asking about how to do AD > authentication with tac_plus and PAM. I finally sat down and modified the > original pam guide to be AD specific. It's not very much different; the > changes are listed here, and the full document > attached: > > 1. Install the pam-devel package and tcp_wrappers via yum: > > ? ? ?yum install pam-devel tcp_wrappers pam_krb5 > > ... > ... > > 9. For AD, we'll use kerberos auth rather than a plain ol' LDAP bind, so > instead of pam_ldap in our pam conf, we'll replace with pam_krb5: > > ? ? ?vi /etc/pam.d/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_krb5.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_krb5.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_krb5.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_krb5.so > > Note that this config also works well for system-auth. If you want all > authentication for your server to use AD (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 /etc/krb5.conf. This is where you will specify where to > find your AD server. First, define a realm: > > [realms] > ?MY.REALMS.DOMAIN = { > ?kdc = myadserver.my.realms.domain > ?admin_server = myadserver.my.realms.domain ?} > > set that realm as the default realm: > > [libdefaults] > ?default_realm = MY.REALMS.DOMAIN > > And that *should* be enough. There are many other options that can be set > in krb5.conf depending on your AD setup. For example, our AD's domain is > not configured to be the actual DNS domain in which it resides. Since > kerberos makes use of DNS for certain SRV records, our krb5.conf has the > [domain_realm] section which maps the DNS domain to kerberos realm. All in > all, YMMV, and you may need to poke your krb5.conf some more. > > Luckily, we can easily test if kerberos auth is working, before we try to > lay tac_plus or PAM over it. After configuring your krb5.conf, you can use > kinit to test the auth. Simply type 'kinit ' into your > terminal session. The default realm should be appended, and you should see > a prompt: > > Password for @MY.REALMS.DOMAIN: > > Type in your password, press return, and if you get a prompt back, then it > works. You can then klist to see your kerberos principal, and kdestroy to > remove it. > -------------- next part -------------- > 1. Install the pam-devel package and tcp_wrappers via yum: > > ? ? ?yum install pam-devel tcp_wrappers pam_krb5 > > 2. Obtain the latest tac_plus from ftp://ftp.shrubbery.net/pub/tac_plus/ > > 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. For AD, we'll use kerberos auth rather than a plain ol' LDAP bind, so > instead of pam_ldap in our pam conf, we'll replace with pam_krb5: > > ? ? ?vi /etc/pam.d/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_krb5.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_krb5.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_krb5.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_krb5.so > > Note that this config also works well for system-auth. If you want all > authentication for your server to use AD (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 /etc/krb5.conf. This is where you will specify where to > find your AD server. First, define a realm: > > [realms] > ?MY.REALMS.DOMAIN = { > ?kdc = myadserver.my.realms.domain > ?admin_server = myadserver.my.realms.domain ?} > > set that realm as the default realm: > > [libdefaults] > ?default_realm = MY.REALMS.DOMAIN > > And that *should* be enough. There are many other options that can be set > in krb5.conf depending on your AD setup. For example, our AD's domain is > not configured to be the actual DNS domain in which it resides. Since > kerberos makes use of DNS for certain SRV records, our krb5.conf has the > [domain_realm] section which maps the DNS domain to kerberos realm. All in > all, YMMV, and you may need to poke your krb5.conf some more. > > Luckily, we can easily test if kerberos auth is working, before we try to > lay tac_plus or PAM over it. After configuring your krb5.conf, you can use > kinit to test the auth. Simply type 'kinit ' into your > terminal session. The default realm should be appended, and you should see > a prompt: > > Password for @MY.REALMS.DOMAIN: > > Type in your password, press return, and if you get a prompt back, then it > works. You can then klist to see your kerberos principal, and kdestroy to > remove 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. > _______________________________________________ > tac_plus mailing list > tac_plus at shrubbery.net > http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus > E-Mail to and from me, in connection with the transaction > of public business, is subject to the Wyoming Public Records > Act and may be disclosed to third parties. > E-Mail to and from me, in connection with the transaction of public business, is subject to the Wyoming Public Records Act and may be disclosed to third parties. From prozaconstilts at gmail.com Wed Apr 25 12:59:39 2012 From: prozaconstilts at gmail.com (Adam Allred) Date: Wed, 25 Apr 2012 08:59:39 -0400 Subject: [tac_plus] AD version of the pam guide In-Reply-To: <5a3309614b5c6a13a99427d13237c4d9@mail.gmail.com> References: <5a3309614b5c6a13a99427d13237c4d9@mail.gmail.com> Message-ID: Hm, so PAM doesn't know about the user. Try removing all pam_krb5 lines from your pam stack except the auth line and try again. pam *shouldn't* need to get anything like a passwd entry for a pam_authenticate call; the users are defined in your tac_plus.conf and assuming they don't need to login to the tac server itself, then the only pam_krb5 line that should be needed is the 'auth' line. Adam On Tue, Apr 24, 2012 at 7:11 PM, Daniel Schmidt wrote: > Thanks much for the suggestions. ?I tried this, but it also did not appear > to work. ?Apologies, I know very little about PAM. > > # cat /etc/pam.d/tac_plus > auth ? ? ? ?required ? ? ?pam_env.so > auth ? ? ? ?sufficient ? ?pam_krb5.so use_first_pass > auth ? ? ? ?sufficient ? ?pam_unix.so nullok try_first_pass > auth ? ? ? ?requisite ? ? pam_succeed_if.so uid >= 500 quiet > 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_krb5.so > account ? ? required ? ? ?pam_permit.so > > password ? ?requisite ? ? pam_cracklib.so try_first_pass retry=3 > password ? ?sufficient ? ?pam_krb5.so use_authtok > password ? ?sufficient ? ?pam_unix.so md5 shadow nullok try_first_pass > 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_krb5.so > > -----Original Message----- > From: Adam Allred [mailto:prozaconstilts at gmail.com] > Sent: Tuesday, April 24, 2012 2:48 PM > To: Daniel Schmidt > Cc: tac_plus at shrubbery.net > Subject: Re: [tac_plus] AD version of the pam guide > > hmm...perhaps that's pam_unix saying that (though my pam conf has > pam_unix first, and I don't get that line). Try placing pam_krb5 above > pam_unix in the auth section of the pam conf file, and moving > use_first_pass down to pam_unix. But be careful...if that makes your > pam stack unhappy, you may be unable to login with local > accounts...like root, etc. If your tac_plus pam conf is simply > including system-auth, I recommend breaking that inheritance, and > having a full pam stack defined in /etc/pam.d/tac_plus. > > Adam > > On Mon, Apr 23, 2012 at 5:32 PM, Daniel Schmidt > wrote: >> Thanks much! >> >> Strange, I get "Unknown user" at tac_plus debug, though kinit/klist >> appears to work just fine. ?Config is correct - there isn't much you can >> mess up. ?Any ideas appreciated. >> >> [root at dufus ~]# egrep 1877 tac_log.txt >> Mon Apr 23 14:48:43 2012 [1877]: connect from 1.1.1.1 [1.1.1.1] >> Mon Apr 23 14:48:43 2012 [1877]: pam_verify homer >> Mon Apr 23 14:48:43 2012 [1877]: pam_tacacs received 1 pam_messages >> Mon Apr 23 14:48:43 2012 [1877]: 1.1.1.1 tty1: PAM_PROMPT_ECHO_OFF >> Mon Apr 23 14:48:46 2012 [1877]: Unknown user >> Mon Apr 23 14:48:46 2012 [1877]: login query for 'homer' tty1 from > 1.1.1.1 >> rejected >> Mon Apr 23 14:48:46 2012 [1877]: login failure: homer 1.1.1.1 (1.1.1.1) >> tty1 >> >> user = homer ?{ >> ? ? ? ?member = same_group_as_everybody >> ? ? ? ?login = PAM >> ? ? ? ?pap = PAM >> } >> >> -----Original Message----- >> From: tac_plus-bounces at shrubbery.net >> [mailto:tac_plus-bounces at shrubbery.net] On Behalf Of Adam Allred >> Sent: Sunday, April 22, 2012 8:39 AM >> To: tac_plus at shrubbery.net >> Cc: renat at vtxinc.com >> Subject: [tac_plus] AD version of the pam guide >> >> Hi all, >> >> Over the years, I've gotten a few people asking about how to do AD >> authentication with tac_plus and PAM. I finally sat down and modified > the >> original pam guide to be AD specific. It's not very much different; the >> changes are listed here, and the full document >> attached: >> >> 1. Install the pam-devel package and tcp_wrappers via yum: >> >> ? ? ?yum install pam-devel tcp_wrappers pam_krb5 >> >> ... >> ... >> >> 9. For AD, we'll use kerberos auth rather than a plain ol' LDAP bind, so >> instead of pam_ldap in our pam conf, we'll replace with pam_krb5: >> >> ? ? ?vi /etc/pam.d/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_krb5.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_krb5.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_krb5.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_krb5.so >> >> Note that this config also works well for system-auth. If you want all >> authentication for your server to use AD (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 /etc/krb5.conf. This is where you will specify where > to >> find your AD server. First, define a realm: >> >> [realms] >> ?MY.REALMS.DOMAIN = { >> ?kdc = myadserver.my.realms.domain >> ?admin_server = myadserver.my.realms.domain ?} >> >> set that realm as the default realm: >> >> [libdefaults] >> ?default_realm = MY.REALMS.DOMAIN >> >> And that *should* be enough. There are many other options that can be > set >> in krb5.conf depending on your AD setup. For example, our AD's domain is >> not configured to be the actual DNS domain in which it resides. Since >> kerberos makes use of DNS for certain SRV records, our krb5.conf has the >> [domain_realm] section which maps the DNS domain to kerberos realm. All > in >> all, YMMV, and you may need to poke your krb5.conf some more. >> >> Luckily, we can easily test if kerberos auth is working, before we try > to >> lay tac_plus or PAM over it. After configuring your krb5.conf, you can > use >> kinit to test the auth. Simply type 'kinit ' into your >> terminal session. The default realm should be appended, and you should > see >> a prompt: >> >> Password for @MY.REALMS.DOMAIN: >> >> Type in your password, press return, and if you get a prompt back, then > it >> works. You can then klist to see your kerberos principal, and kdestroy > to >> remove it. >> -------------- next part -------------- >> 1. Install the pam-devel package and tcp_wrappers via yum: >> >> ? ? ?yum install pam-devel tcp_wrappers pam_krb5 >> >> 2. Obtain the latest tac_plus from ftp://ftp.shrubbery.net/pub/tac_plus/ >> >> 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. For AD, we'll use kerberos auth rather than a plain ol' LDAP bind, so >> instead of pam_ldap in our pam conf, we'll replace with pam_krb5: >> >> ? ? ?vi /etc/pam.d/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_krb5.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_krb5.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_krb5.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_krb5.so >> >> Note that this config also works well for system-auth. If you want all >> authentication for your server to use AD (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 /etc/krb5.conf. This is where you will specify where > to >> find your AD server. First, define a realm: >> >> [realms] >> ?MY.REALMS.DOMAIN = { >> ?kdc = myadserver.my.realms.domain >> ?admin_server = myadserver.my.realms.domain ?} >> >> set that realm as the default realm: >> >> [libdefaults] >> ?default_realm = MY.REALMS.DOMAIN >> >> And that *should* be enough. There are many other options that can be > set >> in krb5.conf depending on your AD setup. For example, our AD's domain is >> not configured to be the actual DNS domain in which it resides. Since >> kerberos makes use of DNS for certain SRV records, our krb5.conf has the >> [domain_realm] section which maps the DNS domain to kerberos realm. All > in >> all, YMMV, and you may need to poke your krb5.conf some more. >> >> Luckily, we can easily test if kerberos auth is working, before we try > to >> lay tac_plus or PAM over it. After configuring your krb5.conf, you can > use >> kinit to test the auth. Simply type 'kinit ' into your >> terminal session. The default realm should be appended, and you should > see >> a prompt: >> >> Password for @MY.REALMS.DOMAIN: >> >> Type in your password, press return, and if you get a prompt back, then > it >> works. You can then klist to see your kerberos principal, and kdestroy > to >> remove 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. >> _______________________________________________ >> tac_plus mailing list >> tac_plus at shrubbery.net >> http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus >> E-Mail to and from me, in connection with the transaction >> of public business, is subject to the Wyoming Public Records >> Act and may be disclosed to third parties. >> > E-Mail to and from me, in connection with the transaction > of public business, is subject to the Wyoming Public Records > Act and may be disclosed to third parties. > From daniel.schmidt at wyo.gov Wed Apr 25 17:02:47 2012 From: daniel.schmidt at wyo.gov (Daniel Schmidt) Date: Wed, 25 Apr 2012 11:02:47 -0600 Subject: [tac_plus] Accounting time off Message-ID: <571b6de087627e70e79b548f8faa9595@mail.gmail.com> Were changes made to the accounting time code? Same box: Wrong time: F4.0.4.25 tail ?n1 log Apr 25 16:52:14 ?.. Right time: F4.0.4.19 tail ?n1 log Wed Apr 25 10:55:55 E-Mail to and from me, in connection with the transaction of public business, is subject to the Wyoming Public Records Act and may be disclosed to third parties. -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.schmidt at wyo.gov Wed Apr 25 17:03:44 2012 From: daniel.schmidt at wyo.gov (Daniel Schmidt) Date: Wed, 25 Apr 2012 11:03:44 -0600 Subject: [tac_plus] AD version of the pam guide In-Reply-To: References: <5a3309614b5c6a13a99427d13237c4d9@mail.gmail.com> Message-ID: <0c163896219b815212fbdbfec8fc7cb0@mail.gmail.com> Same thing - I don't get it. I compiled the latest version, -lpam yes, it's checking PAM - it seems like everything should be right. Pull my hair out - any ideas appreciated, thx for your help. $ klist Ticket cache: FILE:/tmp/krb5cc_500 Default principal: homer at SIMPSON.EDU Valid starting Expires Service principal krbtgt/ renew until Kerberos 4 ticket cache: /tmp/tkt500 klist: You have no tickets cached $ kestroy user = homer { default service = permit service = exec { priv-lvl = 1 # brocade-privlvl = 5 idletime = 10 } service = ciscowlc { role1 = MONITOR } after authorization "/usr/bin/python /root/do_auth.pyo -i $address -fix_crs_bug -u $user -d $name -l /root/log.txt -f /root/do_auth.ini" login = PAM pap = PAM } # egrep 4031 tac_log.txt Wed Apr 25 10:34:39 2012 [4031]: connect from 1.1.1.1 [1.1.1.1] Wed Apr 25 10:34:39 2012 [4031]: pam_verify homer Wed Apr 25 10:34:39 2012 [4031]: pam_tacacs received 1 pam_messages Wed Apr 25 10:34:39 2012 [4031]: 1.1.1.1 tty14: PAM_PROMPT_ECHO_OFF Wed Apr 25 10:34:42 2012 [4031]: Unknown user Wed Apr 25 10:34:42 2012 [4031]: login query for 'homer' tty14 from 1.1.1.1 rejected Wed Apr 25 10:34:42 2012 [4031]: login failure: homer 1.1.1.1 (1.1.1.1) tty14 $ cat /etc/pam.d/tac_plus auth required pam_env.so auth sufficient pam_krb5.so use_first_pass auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 500 quiet 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 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 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 -----Original Message----- From: Adam Allred [mailto:prozaconstilts at gmail.com] Sent: Wednesday, April 25, 2012 7:00 AM To: Daniel Schmidt Cc: tac_plus at shrubbery.net Subject: Re: [tac_plus] AD version of the pam guide Hm, so PAM doesn't know about the user. Try removing all pam_krb5 lines from your pam stack except the auth line and try again. pam *shouldn't* need to get anything like a passwd entry for a pam_authenticate call; the users are defined in your tac_plus.conf and assuming they don't need to login to the tac server itself, then the only pam_krb5 line that should be needed is the 'auth' line. Adam On Tue, Apr 24, 2012 at 7:11 PM, Daniel Schmidt wrote: > Thanks much for the suggestions. ?I tried this, but it also did not > appear to work. ?Apologies, I know very little about PAM. > > # cat /etc/pam.d/tac_plus > auth ? ? ? ?required ? ? ?pam_env.so > auth ? ? ? ?sufficient ? ?pam_krb5.so use_first_pass auth > sufficient ? ?pam_unix.so nullok try_first_pass auth ? ? ? ?requisite > pam_succeed_if.so uid >= 500 quiet 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_krb5.so account ? ? required > pam_permit.so > > password ? ?requisite ? ? pam_cracklib.so try_first_pass retry=3 > password ? ?sufficient ? ?pam_krb5.so use_authtok password > sufficient ? ?pam_unix.so md5 shadow nullok try_first_pass 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_krb5.so > > -----Original Message----- > From: Adam Allred [mailto:prozaconstilts at gmail.com] > Sent: Tuesday, April 24, 2012 2:48 PM > To: Daniel Schmidt > Cc: tac_plus at shrubbery.net > Subject: Re: [tac_plus] AD version of the pam guide > > hmm...perhaps that's pam_unix saying that (though my pam conf has > pam_unix first, and I don't get that line). Try placing pam_krb5 above > pam_unix in the auth section of the pam conf file, and moving > use_first_pass down to pam_unix. But be careful...if that makes your > pam stack unhappy, you may be unable to login with local > accounts...like root, etc. If your tac_plus pam conf is simply > including system-auth, I recommend breaking that inheritance, and > having a full pam stack defined in /etc/pam.d/tac_plus. > > Adam > > On Mon, Apr 23, 2012 at 5:32 PM, Daniel Schmidt > > wrote: >> Thanks much! >> >> Strange, I get "Unknown user" at tac_plus debug, though kinit/klist >> appears to work just fine. ?Config is correct - there isn't much you >> can mess up. ?Any ideas appreciated. >> >> [root at dufus ~]# egrep 1877 tac_log.txt Mon Apr 23 14:48:43 2012 >> [1877]: connect from 1.1.1.1 [1.1.1.1] Mon Apr 23 14:48:43 2012 >> [1877]: pam_verify homer Mon Apr 23 14:48:43 2012 [1877]: pam_tacacs >> received 1 pam_messages Mon Apr 23 14:48:43 2012 [1877]: 1.1.1.1 >> tty1: PAM_PROMPT_ECHO_OFF Mon Apr 23 14:48:46 2012 [1877]: Unknown >> user Mon Apr 23 14:48:46 2012 [1877]: login query for 'homer' tty1 >> from > 1.1.1.1 >> rejected >> Mon Apr 23 14:48:46 2012 [1877]: login failure: homer 1.1.1.1 >> (1.1.1.1) >> tty1 >> >> user = homer ?{ >> ? ? ? ?member = same_group_as_everybody >> ? ? ? ?login = PAM >> ? ? ? ?pap = PAM >> } >> >> -----Original Message----- >> From: tac_plus-bounces at shrubbery.net >> [mailto:tac_plus-bounces at shrubbery.net] On Behalf Of Adam Allred >> Sent: Sunday, April 22, 2012 8:39 AM >> To: tac_plus at shrubbery.net >> Cc: renat at vtxinc.com >> Subject: [tac_plus] AD version of the pam guide >> >> Hi all, >> >> Over the years, I've gotten a few people asking about how to do AD >> authentication with tac_plus and PAM. I finally sat down and modified > the >> original pam guide to be AD specific. It's not very much different; >> the changes are listed here, and the full document >> attached: >> >> 1. Install the pam-devel package and tcp_wrappers via yum: >> >> ? ? ?yum install pam-devel tcp_wrappers pam_krb5 >> >> ... >> ... >> >> 9. For AD, we'll use kerberos auth rather than a plain ol' LDAP bind, >> so instead of pam_ldap in our pam conf, we'll replace with pam_krb5: >> >> ? ? ?vi /etc/pam.d/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_krb5.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_krb5.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_krb5.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_krb5.so >> >> Note that this config also works well for system-auth. If you want >> all authentication for your server to use AD (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 /etc/krb5.conf. This is where you will specify >> where > to >> find your AD server. First, define a realm: >> >> [realms] >> ?MY.REALMS.DOMAIN = { >> ?kdc = myadserver.my.realms.domain >> ?admin_server = myadserver.my.realms.domain ?} >> >> set that realm as the default realm: >> >> [libdefaults] >> ?default_realm = MY.REALMS.DOMAIN >> >> And that *should* be enough. There are many other options that can be > set >> in krb5.conf depending on your AD setup. For example, our AD's domain >> is not configured to be the actual DNS domain in which it resides. >> Since kerberos makes use of DNS for certain SRV records, our >> krb5.conf has the [domain_realm] section which maps the DNS domain to >> kerberos realm. All > in >> all, YMMV, and you may need to poke your krb5.conf some more. >> >> Luckily, we can easily test if kerberos auth is working, before we >> try > to >> lay tac_plus or PAM over it. After configuring your krb5.conf, you >> can > use >> kinit to test the auth. Simply type 'kinit ' into >> your terminal session. The default realm should be appended, and you >> should > see >> a prompt: >> >> Password for @MY.REALMS.DOMAIN: >> >> Type in your password, press return, and if you get a prompt back, >> then > it >> works. You can then klist to see your kerberos principal, and >> kdestroy > to >> remove it. >> -------------- next part -------------- 1. Install the pam-devel >> package and tcp_wrappers via yum: >> >> ? ? ?yum install pam-devel tcp_wrappers pam_krb5 >> >> 2. Obtain the latest tac_plus from >> ftp://ftp.shrubbery.net/pub/tac_plus/ >> >> 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. For AD, we'll use kerberos auth rather than a plain ol' LDAP bind, >> so instead of pam_ldap in our pam conf, we'll replace with pam_krb5: >> >> ? ? ?vi /etc/pam.d/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_krb5.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_krb5.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_krb5.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_krb5.so >> >> Note that this config also works well for system-auth. If you want >> all authentication for your server to use AD (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 /etc/krb5.conf. This is where you will specify >> where > to >> find your AD server. First, define a realm: >> >> [realms] >> ?MY.REALMS.DOMAIN = { >> ?kdc = myadserver.my.realms.domain >> ?admin_server = myadserver.my.realms.domain ?} >> >> set that realm as the default realm: >> >> [libdefaults] >> ?default_realm = MY.REALMS.DOMAIN >> >> And that *should* be enough. There are many other options that can be > set >> in krb5.conf depending on your AD setup. For example, our AD's domain >> is not configured to be the actual DNS domain in which it resides. >> Since kerberos makes use of DNS for certain SRV records, our >> krb5.conf has the [domain_realm] section which maps the DNS domain to >> kerberos realm. All > in >> all, YMMV, and you may need to poke your krb5.conf some more. >> >> Luckily, we can easily test if kerberos auth is working, before we >> try > to >> lay tac_plus or PAM over it. After configuring your krb5.conf, you >> can > use >> kinit to test the auth. Simply type 'kinit ' into >> your terminal session. The default realm should be appended, and you >> should > see >> a prompt: >> >> Password for @MY.REALMS.DOMAIN: >> >> Type in your password, press return, and if you get a prompt back, >> then > it >> works. You can then klist to see your kerberos principal, and >> kdestroy > to >> remove 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. >> _______________________________________________ >> tac_plus mailing list >> tac_plus at shrubbery.net >> http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus >> E-Mail to and from me, in connection with the transaction of public >> business, is subject to the Wyoming Public Records Act and may be >> disclosed to third parties. >> > E-Mail to and from me, in connection with the transaction of public > business, is subject to the Wyoming Public Records Act and may be > disclosed to third parties. > E-Mail to and from me, in connection with the transaction of public business, is subject to the Wyoming Public Records Act and may be disclosed to third parties. From heas at shrubbery.net Wed Apr 25 17:22:15 2012 From: heas at shrubbery.net (heasley) Date: Wed, 25 Apr 2012 10:22:15 -0700 Subject: [tac_plus] Accounting time off In-Reply-To: <571b6de087627e70e79b548f8faa9595@mail.gmail.com> References: <571b6de087627e70e79b548f8faa9595@mail.gmail.com> Message-ID: <20120425172214.GF4900@shrubbery.net> Wed, Apr 25, 2012 at 11:02:47AM -0600, Daniel Schmidt: > Were changes made to the accounting time code? Same box: no changes have occured. that looks like it might be a TZ difference. > Wrong time: > > F4.0.4.25 > > tail ?n1 log > > Apr 25 16:52:14 ?.. > > > > Right time: > > F4.0.4.19 > > tail ?n1 log > > Wed Apr 25 10:55:55 From heas at shrubbery.net Wed Apr 25 17:29:32 2012 From: heas at shrubbery.net (heasley) Date: Wed, 25 Apr 2012 10:29:32 -0700 Subject: [tac_plus] AD version of the pam guide In-Reply-To: <0c163896219b815212fbdbfec8fc7cb0@mail.gmail.com> References: <5a3309614b5c6a13a99427d13237c4d9@mail.gmail.com> <0c163896219b815212fbdbfec8fc7cb0@mail.gmail.com> Message-ID: <20120425172932.GH4900@shrubbery.net> Wed, Apr 25, 2012 at 11:03:44AM -0600, Daniel Schmidt: > Same thing - I don't get it. I compiled the latest version, -lpam yes, > it's checking PAM - it seems like everything should be right. Pull my > hair out - any ideas appreciated, thx for your help. > > $ klist > Ticket cache: FILE:/tmp/krb5cc_500 > Default principal: homer at SIMPSON.EDU > > Valid starting Expires Service principal > krbtgt/ > renew until > > > Kerberos 4 ticket cache: /tmp/tkt500 > klist: You have no tickets cached > $ kestroy > > user = homer { > default service = permit > service = exec { > priv-lvl = 1 > # brocade-privlvl = 5 > idletime = 10 } > service = ciscowlc { > role1 = MONITOR > } > after authorization "/usr/bin/python /root/do_auth.pyo -i $address > -fix_crs_bug -u $user -d $name -l /root/log.txt -f /root/do_auth.ini" > login = PAM > pap = PAM > } > > # egrep 4031 tac_log.txt > Wed Apr 25 10:34:39 2012 [4031]: connect from 1.1.1.1 [1.1.1.1] > Wed Apr 25 10:34:39 2012 [4031]: pam_verify homer > Wed Apr 25 10:34:39 2012 [4031]: pam_tacacs received 1 pam_messages > Wed Apr 25 10:34:39 2012 [4031]: 1.1.1.1 tty14: PAM_PROMPT_ECHO_OFF > Wed Apr 25 10:34:42 2012 [4031]: Unknown user does homer have a unix account? is his uid less than 500? etc etc. all those options. reduce the complexity until you have something that works; do the absolute minimum in the lab. honestly, i added pam to get SecurID to work for an eval trial; I've long thought that the configuration of pam was a bit esoteric and manual pages are lacking. > Wed Apr 25 10:34:42 2012 [4031]: login query for 'homer' tty14 from > 1.1.1.1 rejected > Wed Apr 25 10:34:42 2012 [4031]: login failure: homer 1.1.1.1 (1.1.1.1) > tty14 > > $ cat /etc/pam.d/tac_plus > auth required pam_env.so > auth sufficient pam_krb5.so use_first_pass > auth sufficient pam_unix.so nullok try_first_pass > auth requisite pam_succeed_if.so uid >= 500 quiet > auth required pam_deny.so > > account required pam_unix.so broken_shadow and where is the krb5 account check? > account sufficient pam_localuser.so > account sufficient pam_succeed_if.so uid < 500 quiet > 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 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 > From daniel.schmidt at wyo.gov Wed Apr 25 17:30:52 2012 From: daniel.schmidt at wyo.gov (Daniel Schmidt) Date: Wed, 25 Apr 2012 11:30:52 -0600 Subject: [tac_plus] Accounting time off In-Reply-To: <20120425172214.GF4900@shrubbery.net> References: <571b6de087627e70e79b548f8faa9595@mail.gmail.com> <20120425172214.GF4900@shrubbery.net> Message-ID: <358fa0469d73aa36766dc976e54c0fc9@mail.gmail.com> Make no sense. Only difference between 1 and 2 is a sudo make install from .19 and .25 directory and restarting service. Find/replace only on user * ip's. Where would TZ be set in the code? # tail -n2 /var/log/tacacs Apr 25 17:27:18 1.1.1.1 homer tty2 2.2.2.2 stop task_id=101 timezone=MDT service=shell start_time=1335374838 priv-lvl=15 cmd=write Wed Apr 25 11:28:01 2012 1.1.1.1 homer tty2 2.2.2.2 stop task_id=102 timezone=MDT service=shell start_time=1335374881 priv-lvl=15 cmd=write -----Original Message----- From: heasley [mailto:heas at shrubbery.net] Sent: Wednesday, April 25, 2012 11:22 AM To: Daniel Schmidt Cc: tac_plus at shrubbery.net Subject: Re: [tac_plus] Accounting time off Wed, Apr 25, 2012 at 11:02:47AM -0600, Daniel Schmidt: > Were changes made to the accounting time code? Same box: no changes have occured. that looks like it might be a TZ difference. > Wrong time: > > F4.0.4.25 > > tail ?n1 log > > Apr 25 16:52:14 ?.. > > > > Right time: > > F4.0.4.19 > > tail ?n1 log > > Wed Apr 25 10:55:55 E-Mail to and from me, in connection with the transaction of public business, is subject to the Wyoming Public Records Act and may be disclosed to third parties. From daniel.schmidt at wyo.gov Wed Apr 25 17:59:08 2012 From: daniel.schmidt at wyo.gov (Daniel Schmidt) Date: Wed, 25 Apr 2012 11:59:08 -0600 Subject: [tac_plus] AD version of the pam guide In-Reply-To: <20120425172932.GH4900@shrubbery.net> References: <5a3309614b5c6a13a99427d13237c4d9@mail.gmail.com> <0c163896219b815212fbdbfec8fc7cb0@mail.gmail.com> <20120425172932.GH4900@shrubbery.net> Message-ID: <5da3e09a39897854c5998d0103eb7f2e@mail.gmail.com> So... you're saying.... homer would need to exist locally on the box first? :-\ Of course, that works much better. My sincerest apologies for wasting everybody's time on this, thanks Adam and 'Heas. When I get a chance, I'll add this to tacacs.org lest anybody waste your time with this again. (New version of do_auth also coming - support for juniper pairs) -----Original Message----- From: heasley [mailto:heas at shrubbery.net] Sent: Wednesday, April 25, 2012 11:30 AM To: Daniel Schmidt Cc: Adam Allred; tac_plus at shrubbery.net Subject: Re: [tac_plus] AD version of the pam guide Wed, Apr 25, 2012 at 11:03:44AM -0600, Daniel Schmidt: > Same thing - I don't get it. I compiled the latest version, -lpam > yes, it's checking PAM - it seems like everything should be right. > Pull my hair out - any ideas appreciated, thx for your help. > > $ klist > Ticket cache: FILE:/tmp/krb5cc_500 > Default principal: homer at SIMPSON.EDU > > Valid starting Expires Service principal > krbtgt/ > renew until > > > Kerberos 4 ticket cache: /tmp/tkt500 > klist: You have no tickets cached > $ kestroy > > user = homer { > default service = permit > service = exec { > priv-lvl = 1 > # brocade-privlvl = 5 > idletime = 10 } > service = ciscowlc { > role1 = MONITOR > } > after authorization "/usr/bin/python /root/do_auth.pyo -i > $address -fix_crs_bug -u $user -d $name -l /root/log.txt -f /root/do_auth.ini" > login = PAM > pap = PAM > } > > # egrep 4031 tac_log.txt > Wed Apr 25 10:34:39 2012 [4031]: connect from 1.1.1.1 [1.1.1.1] Wed > Apr 25 10:34:39 2012 [4031]: pam_verify homer Wed Apr 25 10:34:39 2012 > [4031]: pam_tacacs received 1 pam_messages Wed Apr 25 10:34:39 2012 > [4031]: 1.1.1.1 tty14: PAM_PROMPT_ECHO_OFF Wed Apr 25 10:34:42 2012 > [4031]: Unknown user does homer have a unix account? is his uid less than 500? etc etc. all those options. reduce the complexity until you have something that works; do the absolute minimum in the lab. honestly, i added pam to get SecurID to work for an eval trial; I've long thought that the configuration of pam was a bit esoteric and manual pages are lacking. > Wed Apr 25 10:34:42 2012 [4031]: login query for 'homer' tty14 from > 1.1.1.1 rejected > Wed Apr 25 10:34:42 2012 [4031]: login failure: homer 1.1.1.1 > (1.1.1.1) > tty14 > > $ cat /etc/pam.d/tac_plus > auth required pam_env.so > auth sufficient pam_krb5.so use_first_pass > auth sufficient pam_unix.so nullok try_first_pass > auth requisite pam_succeed_if.so uid >= 500 quiet > auth required pam_deny.so > > account required pam_unix.so broken_shadow and where is the krb5 account check? > account sufficient pam_localuser.so > account sufficient pam_succeed_if.so uid < 500 quiet > 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 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 > E-Mail to and from me, in connection with the transaction of public business, is subject to the Wyoming Public Records Act and may be disclosed to third parties. From heas at shrubbery.net Wed Apr 25 18:33:20 2012 From: heas at shrubbery.net (heasley) Date: Wed, 25 Apr 2012 11:33:20 -0700 Subject: [tac_plus] AD version of the pam guide In-Reply-To: <5da3e09a39897854c5998d0103eb7f2e@mail.gmail.com> References: <5a3309614b5c6a13a99427d13237c4d9@mail.gmail.com> <0c163896219b815212fbdbfec8fc7cb0@mail.gmail.com> <20120425172932.GH4900@shrubbery.net> <5da3e09a39897854c5998d0103eb7f2e@mail.gmail.com> Message-ID: <20120425183320.GA9592@shrubbery.net> Wed, Apr 25, 2012 at 11:59:08AM -0600, Daniel Schmidt: > So... you're saying.... homer would need to exist locally on the box > first? :-\ or, there would need to be a krb5 version of this that is "sufficient" or whatever the knob is to stop processing: > > account required pam_unix.so broken_shadow From heas at shrubbery.net Wed Apr 25 18:43:48 2012 From: heas at shrubbery.net (heasley) Date: Wed, 25 Apr 2012 11:43:48 -0700 Subject: [tac_plus] Accounting time off In-Reply-To: <358fa0469d73aa36766dc976e54c0fc9@mail.gmail.com> References: <571b6de087627e70e79b548f8faa9595@mail.gmail.com> <20120425172214.GF4900@shrubbery.net> <358fa0469d73aa36766dc976e54c0fc9@mail.gmail.com> Message-ID: <20120425184348.GB9592@shrubbery.net> Wed, Apr 25, 2012 at 11:30:52AM -0600, Daniel Schmidt: > Make no sense. Only difference between 1 and 2 is a sudo make install > from .19 and .25 directory and restarting service. Find/replace only on > user * ip's. Where would TZ be set in the code? its not; its inheritted from the process that starts it. > # tail -n2 /var/log/tacacs > Apr 25 17:27:18 1.1.1.1 homer tty2 2.2.2.2 stop > task_id=101 timezone=MDT service=shell start_time=1335374838 > priv-lvl=15 cmd=write > Wed Apr 25 11:28:01 2012 1.1.1.1 homer tty2 2.2.2.2 > stop task_id=102 timezone=MDT service=shell > start_time=1335374881 priv-lvl=15 cmd=write shit, this change was added in F4.0.4.20; sorry missed that in the logs. so, hrm, but in order for it to use the inheritted timezone, it'd have to use localtime instead of gmtime. r3374 | heas | 2011-01-20 00:16:17 +0000 (Thu, 20 Jan 2011) | 2 lines - change accounting log time format to match syslog Index: do_acct.c =================================================================== --- do_acct.c (revision 3199) +++ do_acct.c (revision 3375) @@ -20,6 +20,7 @@ */ #include "tac_plus.h" +#include #include #if defined(__DragonFly__) && !defined(O_SYNC) #define O_SYNC O_FSYNC @@ -69,9 +70,11 @@ { int i, errors; time_t t = time(NULL); - char *ct = ctime(&t); + char ct[LINE_MAX]; + struct tm *tm; - ct[24] = '\0'; + tm = gmtime(&t); + strftime(ct, LINE_MAX, "%h %e %T", tm); if (!acctfd) { acctfd = open(session.acctfile, O_CREAT | O_WRONLY | O_APPEND, 0644); From prozaconstilts at gmail.com Wed Apr 25 21:54:57 2012 From: prozaconstilts at gmail.com (Adam Allred) Date: Wed, 25 Apr 2012 17:54:57 -0400 Subject: [tac_plus] AD version of the pam guide In-Reply-To: <20120425183320.GA9592@shrubbery.net> References: <5a3309614b5c6a13a99427d13237c4d9@mail.gmail.com> <0c163896219b815212fbdbfec8fc7cb0@mail.gmail.com> <20120425172932.GH4900@shrubbery.net> <5da3e09a39897854c5998d0103eb7f2e@mail.gmail.com> <20120425183320.GA9592@shrubbery.net> Message-ID: no_user_check tells pam_krb5.so to not check if a user exists on the local system, to skip authorization checks using the user's .k5login file, and to create ccache files owned by the current process's UID. This is useful for situations where a non-privileged server process needs to use Kerberized services on behalf of remote users who may not have local access. Note that such a server should have an encrypted connection with its client in order to avoid allowing the user's password to be eavesdropped. So maybe that option to pam_krb5 (though I'm not sure to which service type you should pass that option) will get what you need without having to list a local user account. On Wed, Apr 25, 2012 at 2:33 PM, heasley wrote: > Wed, Apr 25, 2012 at 11:59:08AM -0600, Daniel Schmidt: >> So... you're saying.... homer would need to exist locally on the box >> first? ?:-\ > > or, there would need to be a krb5 version of this that is "sufficient" or > whatever the knob is to stop processing: > >> > account ? ? required ? ? ?pam_unix.so broken_shadow From daniel.schmidt at wyo.gov Wed Apr 25 21:53:47 2012 From: daniel.schmidt at wyo.gov (Daniel Schmidt) Date: Wed, 25 Apr 2012 15:53:47 -0600 Subject: [tac_plus] Accounting time off In-Reply-To: <20120425184348.GB9592@shrubbery.net> References: <571b6de087627e70e79b548f8faa9595@mail.gmail.com> <20120425172214.GF4900@shrubbery.net> <358fa0469d73aa36766dc976e54c0fc9@mail.gmail.com> <20120425184348.GB9592@shrubbery.net> Message-ID: <50c2c68c9f7a8fb5c84144bbfd9b6b10@mail.gmail.com> Much better. Thkx. -----Original Message----- From: heasley [mailto:heas at shrubbery.net] Sent: Wednesday, April 25, 2012 12:44 PM To: Daniel Schmidt Cc: heasley; tac_plus at shrubbery.net Subject: Re: [tac_plus] Accounting time off Wed, Apr 25, 2012 at 11:30:52AM -0600, Daniel Schmidt: > Make no sense. Only difference between 1 and 2 is a sudo make install > from .19 and .25 directory and restarting service. Find/replace only > on user * ip's. Where would TZ be set in the code? its not; its inheritted from the process that starts it. > # tail -n2 /var/log/tacacs > Apr 25 17:27:18 1.1.1.1 homer tty2 2.2.2.2 stop > task_id=101 timezone=MDT service=shell start_time=1335374838 > priv-lvl=15 cmd=write > Wed Apr 25 11:28:01 2012 1.1.1.1 homer tty2 2.2.2.2 > stop task_id=102 timezone=MDT service=shell > start_time=1335374881 priv-lvl=15 cmd=write shit, this change was added in F4.0.4.20; sorry missed that in the logs. so, hrm, but in order for it to use the inheritted timezone, it'd have to use localtime instead of gmtime. r3374 | heas | 2011-01-20 00:16:17 +0000 (Thu, 20 Jan 2011) | 2 lines - change accounting log time format to match syslog Index: do_acct.c =================================================================== --- do_acct.c (revision 3199) +++ do_acct.c (revision 3375) @@ -20,6 +20,7 @@ */ #include "tac_plus.h" +#include #include #if defined(__DragonFly__) && !defined(O_SYNC) #define O_SYNC O_FSYNC @@ -69,9 +70,11 @@ { int i, errors; time_t t = time(NULL); - char *ct = ctime(&t); + char ct[LINE_MAX]; + struct tm *tm; - ct[24] = '\0'; + tm = gmtime(&t); + strftime(ct, LINE_MAX, "%h %e %T", tm); if (!acctfd) { acctfd = open(session.acctfile, O_CREAT | O_WRONLY | O_APPEND, 0644); E-Mail to and from me, in connection with the transaction of public business, is subject to the Wyoming Public Records Act and may be disclosed to third parties. From nicotine at warningg.com Thu Apr 26 11:58:20 2012 From: nicotine at warningg.com (Brandon Ewing) Date: Thu, 26 Apr 2012 06:58:20 -0500 Subject: [tac_plus] AD version of the pam guide In-Reply-To: <5da3e09a39897854c5998d0103eb7f2e@mail.gmail.com> References: <5a3309614b5c6a13a99427d13237c4d9@mail.gmail.com> <0c163896219b815212fbdbfec8fc7cb0@mail.gmail.com> <20120425172932.GH4900@shrubbery.net> <5da3e09a39897854c5998d0103eb7f2e@mail.gmail.com> Message-ID: <20120426115820.GE3903@radiological.warningg.com> On Wed, Apr 25, 2012 at 11:59:08AM -0600, Daniel Schmidt wrote: > So... you're saying.... homer would need to exist locally on the box > first? :-\ > > Of course, that works much better. My sincerest apologies for wasting > everybody's time on this, thanks Adam and 'Heas. When I get a chance, > I'll add this to tacacs.org lest anybody waste your time with this again. > (New version of do_auth also coming - support for juniper pairs) > My installation uses nss_ldap to connect to our AD LDAP to centralize account information. This may be a path for you, either through setting up a service account to handle LDAP binds for nss_ldap, or using machine accounts via joining the machine to the domain with Samba. -- Brandon Ewing (nicotine at warningg.com) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From daniel.schmidt at wyo.gov Thu Apr 26 16:27:58 2012 From: daniel.schmidt at wyo.gov (Daniel Schmidt) Date: Thu, 26 Apr 2012 10:27:58 -0600 Subject: [tac_plus] AD version of the pam guide In-Reply-To: <20120426115820.GE3903@radiological.warningg.com> References: <5a3309614b5c6a13a99427d13237c4d9@mail.gmail.com> <0c163896219b815212fbdbfec8fc7cb0@mail.gmail.com> <20120425172932.GH4900@shrubbery.net> <5da3e09a39897854c5998d0103eb7f2e@mail.gmail.com> <20120426115820.GE3903@radiological.warningg.com> Message-ID: <10d189164ab7f58614e5179190a79666@mail.gmail.com> Thanks for the suggestion! If you'd be willing to write/modify a how-to, I'm sure people (me) would benefit from it. My only goal is to prevent being forced to move to Cisco ACS - Kerberos eliminated this week's risk. I'd like ldap - would be better - far too busy to figure it out. Got to fix Juniper support in do_auth - too many other mundane network tasks 2 do. -----Original Message----- From: tac_plus-bounces at shrubbery.net [mailto:tac_plus-bounces at shrubbery.net] On Behalf Of Brandon Ewing Sent: Thursday, April 26, 2012 5:58 AM To: tac_plus at shrubbery.net Subject: Re: [tac_plus] AD version of the pam guide On Wed, Apr 25, 2012 at 11:59:08AM -0600, Daniel Schmidt wrote: > So... you're saying.... homer would need to exist locally on the box > first? :-\ > > Of course, that works much better. My sincerest apologies for wasting > everybody's time on this, thanks Adam and 'Heas. When I get a chance, > I'll add this to tacacs.org lest anybody waste your time with this again. > (New version of do_auth also coming - support for juniper pairs) > My installation uses nss_ldap to connect to our AD LDAP to centralize account information. This may be a path for you, either through setting up a service account to handle LDAP binds for nss_ldap, or using machine accounts via joining the machine to the domain with Samba. -- Brandon Ewing (nicotine at warningg.com) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: _______________________________________________ tac_plus mailing list tac_plus at shrubbery.net http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus E-Mail to and from me, in connection with the transaction of public business, is subject to the Wyoming Public Records Act and may be disclosed to third parties.