[tac_plus] AD version of the pam guide

Adam Allred prozaconstilts at gmail.com
Tue Apr 24 20:47:49 UTC 2012


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.
>


More information about the tac_plus mailing list