[tac_plus] AD version of the pam guide
Adam Allred
prozaconstilts at gmail.com
Wed Apr 25 12:59:39 UTC 2012
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.
>
More information about the tac_plus
mailing list