[tac_plus] Re: Using LDAP groups in tac_plus authorization
adam
prozaconstilts at gmail.com
Sat May 16 02:30:22 UTC 2009
daniel Rahmeh wrote:
> Hi,
>
> I have a question please about the possibility to use ldap groups with
> tac_plus. I know that it's possible to authenticate users via ldap by
> never seen a solution that permits to get the user's group. Is there
> some kind of patch that can satisfy this need?
>
> Thank you a lot and sorry for bothering,
>
> Daniel RAHMEH
>
>
>
>
> _______________________________________________
> tac_plus mailing list
> tac_plus at shrubbery.net
> http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus
Hi,
I'd suggest this:
> Instructions for RHEL5:
>
> 1. install the pam-devel package from your repository
>
> 2. compile the source for tacacs+, making sure that -lpam was
discovered in
> the configure script
>
> 3. define users in the conf file as such:
>
> user = <username> {
> login = PAM
> }
>
> 4. Place a pam stack configuration in /etc/pam.d/tac_plus that has
whatever
> mechanisms you require for authentication (see below)
>
> 5. celebrate
The pam stack I use looks like this:
#cat /etc/pam.d/tac_plus:
#%PAM-1.0
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
It's not very obvious in that file, but I include system-auth, which
looks like this:
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
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_ldap.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_ldap.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_ldap.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 required pam_mkhomedir.so skel=/etc/skel/ umask=0077
session optional pam_ldap.so
So, in this manner, tacacs+, talking to PAM, and using pam_ldap, can
authenticate a user with ldap-based credentials.
While there is no way to directly reference an ldap group in the
tac_plus.conf file, you can kind of get authorization using a
pam_filter. Here is my ldap.conf:
URI ldaps://my.ldap.server.com
base ou=my_ou,dc=my,dc=ldap,dc=server,dc=com
binddn uid=read-only_account,ou=Accounts,dc=my,dc=ldap,dc=server,dc=com
bindpw ohsosecret
scope sub
ssl yes
TLS_CACERTDIR /etc/openldap/cacerts
TLS_REQCERT allow
nss_schema rfc2307bis
nss_base_passwd ou=Accounts,dc=my,dc=ldap,dc=server,dc=com?sub
nss_base_shadow ou=Accounts,dc=my,dc=ldap,dc=server,dc=com?sub
nss_base_group ou=Accounts,dc=my,dc=ldap,dc=server,dc=com?sub
referrals no # otherwise it goes freakishly slow
pam_login_attribute uid
pam_member_attribute uniquemember
pam_filter (tacacsenabled=true)
What's important there is the pam_filter (tacacsenabled=true)
It means that pam will only authenticate users who have an attribute
tacacsenabled set to true in ldap.
Or, even better, you can use this instead of the filter:
pam_groupdn cn=tacacs,ou=groups,dc=my,dc=ldap,dc=server,dc=com
meaning only members of that group get authenticated.
There are 2 caveats to this setup:
1. Since I include system-auth, this means that I've restricted who can
log in to my tacacs server to only those in my tacacs group. This is my
intention for my organization, because the only people using tacacs are
the people who administer that server. If this is not ideal for you, you
should use pam_ldap directly in the tac_plus pam configuration instead
of including system-auth.
2. I still have to include individual usernames in the tac_plus config.
While it'd be ideal to not have to do that, the daemon doesn't support
it. I've been trying my hand at patching that in, but the going is slow,
cause I'm learning as I go, and I've basically gotten nowhere. :(
Anyhoo, I hope that this can help you out.
Adam
More information about the tac_plus
mailing list