[tac_plus] AD version of the pam guide
Daniel Schmidt
daniel.schmidt at wyo.gov
Mon Apr 23 21:32:44 UTC 2012
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