[tac_plus] AD version of the pam guide
Daniel Schmidt
daniel.schmidt at wyo.gov
Wed Apr 25 17:03:44 UTC 2012
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
<date> <snip> krbtgt/<snip>
renew until <snip>
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 <daniel.schmidt at wyo.gov>
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
> <daniel.schmidt at wyo.gov>
> 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 <AD account name>' into
>> your terminal session. The default realm should be appended, and you
>> should
> see
>> a prompt:
>>
>> Password for <AD account>@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+-<your version here>
>>
>> 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 = <ldap user id> {
>> login = PAM
>> <other options>
>> }
>>
>> 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 <AD account name>' into
>> your terminal session. The default realm should be appended, and you
>> should
> see
>> a prompt:
>>
>> Password for <AD account>@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.
More information about the tac_plus
mailing list