Hi Adam,<br><br>Thank you very much for replying me so quick. This is really helpful. I will try it tomorrow and let you know what I will find out. Thanks a lot.<br><br>Appreciated.<br><br>Lou<br><br><div class="gmail_quote">
On Tue, Nov 17, 2009 at 9:16 PM, adam <span dir="ltr"><<a href="mailto:prozaconstilts@gmail.com">prozaconstilts@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hailu Meng wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div></div><div class="h5">
Hi all,<br>
<br>
I'm trying to set up tac_plus in CentOS 5.3. tac_plus has been compiled with<br>
pam and tcp_wrapper. I configured my switch as below:<br>
<br>
aaa new-model<br>
aaa authentication login default group tacacs+ local-case<br>
aaa authentication enable default group tacacs+ enable<br>
aaa authorization exec default tacacs+<br>
aaa accounting exec default start-stop tacacs+<br>
aaa accounting network start-stop tacacs+<br>
tacacs+ host 10.0.0.11<br>
tacacs+ key mykey<br>
<br>
I configured /etc/tac_plus.conf to use local setting firstly. It worked.<br>
Then I tried to use pam with ldap to authenticate against the microsoft<br>
active directory. I snifferred the traffic and saw there was an error when<br>
my tacacs server was doing query against Active Directory. The error<br>
is *problem<br>
2001* (*NO_OBJECT*).<br>
<br>
Do you guys have similar problem when you set up this kind of<br>
authentication? I listed the main configuration files below:<br>
**************************************************************<br>
/etc/pam.d/tac_plus<br>
<br>
#%PAM-1.0<br>
auth include system-auth<br>
account required pam_nologin.so<br>
account include system-auth<br>
password include system-auth<br>
session optional pam_keyinit.so force revoke<br>
session include system-auth<br>
session required pam_loginuid.so<br>
<br>
*********************************************<br>
/etc/pam.d/system-auth<br>
<br>
#%PAM-1.0<br>
# This file is auto-generated.<br>
# User changes will be destroyed the next time authconfig is run.<br>
auth required pam_env.so<br>
auth sufficient pam_unix.so nullok try_first_pass<br>
auth requisite pam_succeed_if.so uid >= 500 quiet<br>
auth sufficient pam_ldap.so use_first_pass<br>
auth required pam_deny.so<br>
<br>
account required pam_unix.so broken_shadow<br>
account sufficient pam_localuser.so<br>
account sufficient pam_succeed_if.so uid < 500 quiet<br>
account [default=bad success=ok user_unknown=ignore] pam_ldap.so<br>
account required pam_permit.so<br>
<br>
password requisite pam_cracklib.so try_first_pass retry=3<br>
password sufficient pam_unix.so md5 shadow nullok try_first_pass<br>
use_authtok<br>
password sufficient pam_ldap.so use_authtok<br>
password required pam_deny.so<br>
<br>
session optional pam_keyinit.so revoke<br>
session required pam_limits.so<br>
session [success=1 default=ignore] pam_succeed_if.so service in<br>
crond quiet use_uid<br>
session required pam_unix.so<br>
session required pam_mkhomedir.so skel=/etc/skel/ umask=0077<br>
session optional pam_ldap.so<br>
<br>
*******************************************************8<br>
/etc/ldap.conf<br>
<br>
<br>
host 10.0.0.100<br>
base ou=security groups,dc=hq,dc=corp,dc=myhouse,dc=com<br>
binddn cn=network services,ou=security groups,dc=hq,dc=corp,dc=myhouse,dc=com<br>
#bindpw ohsosecret # no secret set<br>
scope sub<br>
ssl no<br>
<br>
<br>
nss_schema rfc2307bis<br>
nss_base_passwd ou=security groups,dc=hq,dc=corp,dc=myhouse,dc=com?sub<br>
nss_base_shadow ou=security groups,dc=hq,dc=corp,dc=myhouse,dc=com?sub<br>
nss_base_group ou=security groups,dc=hq,dc=corp,dc=myhouse,dc=com?sub<br>
<br>
referrals no # otherwise it goes freakishly slow<br>
<br>
I linked /etc/openldap/ldap.conf to /etc/ldap.conf. I didn't enable ssl for<br>
ldap.<br>
<br>
I think the problem could be in the configuration of ldap.conf or it doesn't<br>
match the configuration in Active Directory. In my AD, I have "security<br>
groups" OU and in this OU I have "network services" group.<br>
Maybe the issue also stays in nss mapping? I searched some articles. It<br>
seems like nss mapping must be correct to authenticate through Linux box<br>
against Active Directory.<br>
<br>
Another question about active directory is: Do I need create a separate OU<br>
to hold the user accounts who will have rights to login Cisco devices? I saw<br>
someone said the user account in tacacs server must not be in other groups.<br>
If the separate OU is needed and the user must be only in this new OU, it<br>
will lose the flexibility to use the current Active Directory which is<br>
already configured.<br>
<br>
Please give me some help on this. Very appreciated.<br>
<br>
Thanks.<br>
<br>
Lou<br></div></div>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <a href="http://www.shrubbery.net/pipermail/tac_plus/attachments/20091117/03eedad2/attachment.html" target="_blank">http://www.shrubbery.net/pipermail/tac_plus/attachments/20091117/03eedad2/attachment.html</a> _______________________________________________<br>
tac_plus mailing list<br>
<a href="mailto:tac_plus@shrubbery.net" target="_blank">tac_plus@shrubbery.net</a><br>
<a href="http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus" target="_blank">http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus</a><br>
</blockquote>
<br>
I think you're missing a few key items from your ldap.conf:<br>
<br>
pam_filter objectclass=User<br>
pam_login_attribute sAMAccountName<br>
<br>
These directives will tell pam pretty much two things:<br>
<br>
1. pam_filter = an ldap filter that restricts who can actually authenticate. This is wonderfully handy as it lets you build an AD group that you can then look for when you auth a user, and not have to modify your AD structure e.g.<br>
<br>
pam_filter &(objectclass=User)(member=cn=my_group,ou=my_ou,dc=my_domain)<br>
<br>
This tells pam that you can only authenticate if you are a "User" (and not a service or other non-person account type), and that you are a member of the group specified. Assuming all your user accounts exist somewhere under the base OU you specified above, this lets you search them out, and use AD groups w/o messing w/ your AD structure.<br>
<br>
2. pam_login_attribute sAMAccountName<br>
<br>
By default, when using openldap, logging in as 'joe' causes pam_ldap to look in the LDAP store for a record like uid=joe,(+base). For you, this means pam_ldap will ask the AD for any object that has uid=joe anywhere under your base ou: ou=security groups,dc=hq,dc=corp,dc=myhouse,dc=com.<br>
<br>
But in Active Directory land, user accounts don't have a 'uid' field that gets populated with your login name, it uses a different field, called sAMAccountName. This directive tells pam to look for sAMAccountName=joe when talking to the active directory, which is what the AD is expecting.<br>
<br>
Also, you can subtract tac_plus from the mix and just try to make sure pam works. In your ldap.conf, you can put a line like<br>
<br>
debug 256<br>
<br>
to get lots of debug into on console and in log files, and then run su - <username>, subbing in your AD user account name. The higher the debug number, the more debug output you'll get.<br><font color="#888888">
<br>
Adam<br>
<br>
</font></blockquote></div><br>