Hi Adam,<br><br>By the way, as you said. It appears I don&#39;t need create another new group for this authentication purpose. I already have one group setup and I want every one in this group can be authenticated. And also these users are the members for other groups. Does it matter for this case? I mean one user in multiple groups?<br>
<br>And how about nss mapping? Do I need do some configuration for them? Like, <br><pre>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</pre>Thanks.<br><br>Lou<br><div class="gmail_quote">On Tue, Nov 17, 2009 at 10:11 PM, Hailu Meng <span dir="ltr">&lt;<a href="mailto:hailumeng@gmail.com">hailumeng@gmail.com</a>&gt;</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;">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<div><div></div><div class="h5"><br><br><div class="gmail_quote">
On Tue, Nov 17, 2009 at 9:16 PM, adam <span dir="ltr">&lt;<a href="mailto:prozaconstilts@gmail.com" target="_blank">prozaconstilts@gmail.com</a>&gt;</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>
Hi all,<br>
<br>
I&#39;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 &gt;= 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 &lt; 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&#39;t enable ssl for<br>
ldap.<br>
<br>
I think the problem could be in the configuration of ldap.conf or it doesn&#39;t<br>
match the configuration in Active Directory. In my AD, I have &quot;security<br>
groups&quot; OU and in this OU I have &quot;network services&quot; 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&#39;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 &amp;(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 &quot;User&quot; (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 &#39;joe&#39; 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&#39;t have a &#39;uid&#39; 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 - &lt;username&gt;, subbing in your AD user account name. The higher the debug number, the more debug output you&#39;ll get.<br><font color="#888888">
<br>
Adam<br>
<br>
</font></blockquote></div><br>
</div></div></blockquote></div><br>