Adam,<br><br>I tried the su - "userid" in my tacacs+ server but I don't have that userid in CentOS. So the CentOS just don't want me log in. I think this will not ask tacacs server to authenticate against AD.<br>
<br>Is there any other way to test ldap authentication against AD with the userid in AD? I tried ldapsearch. It did find my user id without problem. But I haven't found any option to try with password and authenticate against AD.<br>
<br>Do you have ldap server setup or only the openldap library and openldap client? I don't understand why the log is not turned on. There must be some debugging info in the log which can help solve this issue.<br><br>
If the user can authenticate, does ethereal capture some packets about password verification? Right now I only see the packets when ldap search for my user id and gets results back from AD.<br><br>Maybe I need dig into ldap.conf more. If you have any idea, let me know.<br>
<br>Thank you very much.<br><br>Lou<br><br><div class="gmail_quote">On Thu, Nov 19, 2009 at 8:46 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">
Forgot to post to the mailing list.<br>
<br>
I'm feeling getting close to the end. After modifying the ldap.conf and bind a correct user in my group. Right now I can see the packets snifferred through ethereal shows LDAP found my userid. The packet shows out all the user information from Active Directory. This means LDAP did succeeded in finding my userid. But when I input the password. It just got denied. I'm sure the password is correct. So I doubt it could have some setup about password in ldap.conf is wrong. By the way, I added debug=256 and logdir=/var/log/ldap in ldap.conf, but no log is captured for ldap. Not sure why. Here is my current ldap.conf<br>
******************************<br>
<br>
********<br>
host 10.xx.x.15<br>
base ou=User Accounts,dc=home,dc=corp,dc=myhome,dc=org<br>
ldap_version 3<br>
scope sub<br>
binddn CN=test,OU=User Accounts,dc=home,dc=corp,dc=myhome,dc=org<br>
bindpw mypass<br>
rootbinddn dc=home,dc=corp,dc=myhome,dc=org<br>
# The port.<br>
# Optional: default is 389. SSL LDAP Port 636<br>
port 389<br>
# RFC2307bis naming contexts<br>
nss_base_passwd dc=home,dc=corp,dc=myhome,dc=org?sub<br>
nss_base_shadow dc=home,dc=corp,dc=myhome,dc=org?sub<br>
nss_base_group dc=home,dc=corp,dc=myhome,dc=org?sub<br>
# RFC 2307 (AD) mappings<br>
nss_map_objectclass posixAccount User<br>
nss_map_objectclass shadowAccount User<br>
nss_map_attribute uid sAMAccountName<br>
nss_map_attribute cn sAMAccountName<br>
nss_map_attribute gecos cn<br>
<br>
# PAM_LDAP options<br>
pam_login_attribute sAMAccountName<br>
pam_filter objectclass=User<br>
pam_password ad<br>
logdir /var/log/ldap<br>
debug 1024<br>
ssl no<br>
timelimit 30<br>
bind_timelimit 30<br>
<br>
I'm thinking pam_password is wrong? I didn't see any packet in<br>
ethereal related to password authentication. So I doubt the password<br>
hasn't been sent out to Active Directory. Please help me. Thank you<br>
very much!!!<br>
<br>
Lou <br>
<br>
<br></div></div><div class="im">
On Thu, Nov 19, 2009 at 3:42 PM, Hailu Meng <<a href="mailto:hailumeng@gmail.com" target="_blank">hailumeng@gmail.com</a> <mailto:<a href="mailto:hailumeng@gmail.com" target="_blank">hailumeng@gmail.com</a>>> wrote:<br>
<br>
Hi Adam,<br>
<br></div><div><div></div><div class="h5">
I'm feeling getting close to the end. After modifying the ldap.conf<br>
and bind a correct user in my group. Right now I can see the packets<br>
snifferred through ethereal shows LDAP found my userid. The packet<br>
shows out all the user information from Active Directory. This means<br>
LDAP did succeeded in finding my userid. But when I input the<br>
password. It just got denied. I'm sure the password is correct. So I<br>
doubt it could have some setup about password in ldap.conf is wrong.<br>
By the way, I added debug=256 and logdir=/var/log/ldap in ldap.conf,<br>
but no log is captured for ldap. Not sure why. Here is my current<br>
ldap.conf<br>
**************************************<br>
host 10.xx.x.15<br>
base ou=User Accounts,dc=home,dc=corp,dc=myhome,dc=org<br>
ldap_version 3<br>
scope sub<br>
binddn CN=test,OU=User Accounts,dc=home,dc=corp,dc=myhome,dc=org<br>
bindpw mypass<br>
rootbinddn dc=home,dc=corp,dc=myhome,dc=org<br>
# The port.<br>
# Optional: default is 389. SSL LDAP Port 636<br>
port 389<br>
# RFC2307bis naming contexts<br>
nss_base_passwd dc=home,dc=corp,dc=myhome,dc=org?sub<br>
nss_base_shadow dc=home,dc=corp,dc=myhome,dc=org?sub<br>
nss_base_group dc=home,dc=corp,dc=myhome,dc=org?sub<br>
# RFC 2307 (AD) mappings<br>
nss_map_objectclass posixAccount User<br>
nss_map_objectclass shadowAccount User<br>
nss_map_attribute uid sAMAccountName<br>
nss_map_attribute cn sAMAccountName<br>
nss_map_attribute gecos cn<br>
<br>
# PAM_LDAP options<br>
pam_login_attribute sAMAccountName<br>
pam_filter objectclass=User<br>
pam_password ad<br>
logdir /var/log/ldap<br>
debug 1024<br>
ssl no<br>
timelimit 30<br>
bind_timelimit 30<br>
<br>
I'm thinking pam_password is wrong? I didn't see any packet in<br>
ethereal related to password authentication. So I doubt the password<br>
hasn't been sent out to Active Directory. Please help me. Thank you<br>
very much!!!<br>
<br>
Lou<br>
<br>
On Wed, Nov 18, 2009 at 6:57 AM, adam <<a href="mailto:prozaconstilts@gmail.com" target="_blank">prozaconstilts@gmail.com</a><br></div></div><div class="im">
<mailto:<a href="mailto:prozaconstilts@gmail.com" target="_blank">prozaconstilts@gmail.com</a>>> wrote:<br>
<br>
Hailu Meng wrote:<br>
<br></div><div class="im">
Hi Adam,<br>
<br>
By the way, as you said. It appears I don't need create<br>
another new group for this authentication purpose. I already<br>
have one group setup and I want every one in this group can<br>
be authenticated. And also these users are the members for<br>
other groups. Does it matter for this case? I mean one user<br>
in multiple groups?<br>
<br>
And how about nss mapping? Do I need do some configuration<br>
for them? Like,<br>
<br>
nss_schema rfc2307bis<br>
nss_base_passwd ou=security<br>
groups,dc=hq,dc=corp,dc=myhouse,dc=com?sub<br>
nss_base_shadow ou=security<br>
groups,dc=hq,dc=corp,dc=myhouse,dc=com?sub<br>
<br>
nss_base_group ou=security<br>
groups,dc=hq,dc=corp,dc=myhouse,dc=com?sub<br>
<br>
Thanks.<br>
<br>
Lou<br>
On Tue, Nov 17, 2009 at 10:11 PM, Hailu Meng<br>
<<a href="mailto:hailumeng@gmail.com" target="_blank">hailumeng@gmail.com</a> <mailto:<a href="mailto:hailumeng@gmail.com" target="_blank">hailumeng@gmail.com</a>><br></div>
<mailto:<a href="mailto:hailumeng@gmail.com" target="_blank">hailumeng@gmail.com</a> <mailto:<a href="mailto:hailumeng@gmail.com" target="_blank">hailumeng@gmail.com</a>>>><div class="im"><br>
wrote:<br>
<br>
Hi Adam,<br>
<br>
Thank you very much for replying me so quick. This is really<br>
helpful. I will try it tomorrow and let you know what I<br>
will find<br>
out. Thanks a lot.<br>
<br>
Appreciated.<br>
<br>
Lou<br>
<br>
<br>
On Tue, Nov 17, 2009 at 9:16 PM, adam<br>
<<a href="mailto:prozaconstilts@gmail.com" target="_blank">prozaconstilts@gmail.com</a> <mailto:<a href="mailto:prozaconstilts@gmail.com" target="_blank">prozaconstilts@gmail.com</a>><br></div>
<mailto:<a href="mailto:prozaconstilts@gmail.com" target="_blank">prozaconstilts@gmail.com</a><div><div></div><div class="h5"><br>
<mailto:<a href="mailto:prozaconstilts@gmail.com" target="_blank">prozaconstilts@gmail.com</a>>>> wrote:<br>
<br>
Hailu Meng wrote:<br>
<br>
Hi all,<br>
<br>
I'm trying to set up tac_plus in CentOS 5.3.<br>
tac_plus has<br>
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+<br>
local-case<br>
aaa authentication enable default group tacacs+<br>
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<br>
firstly. It worked.<br>
Then I tried to use pam with ldap to authenticate<br>
against<br>
the microsoft<br>
active directory. I snifferred the traffic and<br>
saw there was<br>
an error when<br>
my tacacs server was doing query against Active<br>
Directory.<br>
The error<br>
is *problem<br>
2001* (*NO_OBJECT*).<br>
<br>
Do you guys have similar problem when you set up<br>
this kind of<br>
authentication? I listed the main configuration<br>
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<br>
authconfig is<br>
run.<br>
auth required pam_env.so<br>
auth sufficient pam_unix.so nullok<br>
try_first_pass<br>
auth requisite pam_succeed_if.so uid<br>
>= 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 <<br>
500 quiet<br>
account [default=bad success=ok<br>
user_unknown=ignore]<br>
pam_ldap.so<br>
account required pam_permit.so<br>
<br>
password requisite pam_cracklib.so<br>
try_first_pass retry=3<br>
password sufficient pam_unix.so md5 shadow<br>
nullok<br>
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]<br>
pam_succeed_if.so<br>
service in<br>
crond quiet use_uid<br>
session required pam_unix.so<br>
session required pam_mkhomedir.so<br>
skel=/etc/skel/<br>
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<br>
groups,dc=hq,dc=corp,dc=myhouse,dc=com<br>
binddn cn=network services,ou=security<br>
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<br>
groups,dc=hq,dc=corp,dc=myhouse,dc=com?sub<br>
nss_base_shadow ou=security<br>
groups,dc=hq,dc=corp,dc=myhouse,dc=com?sub<br>
nss_base_group ou=security<br>
groups,dc=hq,dc=corp,dc=myhouse,dc=com?sub<br>
<br>
referrals no # otherwise it goes<br>
freakishly slow<br>
<br>
I linked /etc/openldap/ldap.conf to<br>
/etc/ldap.conf. I didn't<br>
enable ssl for<br>
ldap.<br>
<br>
I think the problem could be in the configuration of<br>
ldap.conf or it doesn't<br>
match the configuration in Active Directory. In<br>
my AD, I<br>
have "security<br>
groups" OU and in this OU I have "network<br>
services" group.<br>
Maybe the issue also stays in nss mapping? I<br>
searched some<br>
articles. It<br>
seems like nss mapping must be correct to<br>
authenticate<br>
through Linux box<br>
against Active Directory.<br>
<br>
Another question about active directory is: Do I<br>
need create<br>
a separate OU<br>
to hold the user accounts who will have rights to<br>
login<br>
Cisco devices? I saw<br>
someone said the user account in tacacs server<br>
must not be<br>
in other groups.<br>
If the separate OU is needed and the user must be<br>
only in<br>
this new OU, it<br>
will lose the flexibility to use the current Active<br>
Directory which is<br>
already configured.<br>
<br>
Please give me some help on this. Very appreciated.<br>
<br>
Thanks.<br>
<br>
Lou<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL:<br>
<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>
_______________________________________________<br>
tac_plus mailing list<br>
<a href="mailto:tac_plus@shrubbery.net" target="_blank">tac_plus@shrubbery.net</a><br>
<mailto:<a href="mailto:tac_plus@shrubbery.net" target="_blank">tac_plus@shrubbery.net</a>><br></div></div>
<mailto:<a href="mailto:tac_plus@shrubbery.net" target="_blank">tac_plus@shrubbery.net</a> <mailto:<a href="mailto:tac_plus@shrubbery.net" target="_blank">tac_plus@shrubbery.net</a>>><div><div></div>
<div class="h5"><br>
<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>
<br>
<br>
I think you're missing a few key items from your<br>
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<br>
actually<br>
authenticate. This is wonderfully handy as it lets<br>
you build an<br>
AD group that you can then look for when you auth a<br>
user, and<br>
not have to modify your AD structure e.g.<br>
<br>
pam_filter<br>
&(objectclass=User)(member=cn=my_group,ou=my_ou,dc=my_domain)<br>
<br>
This tells pam that you can only authenticate if you<br>
are a<br>
"User" (and not a service or other non-person account<br>
type), and<br>
that you are a member of the group specified.<br>
Assuming all your<br>
user accounts exist somewhere under the base OU you<br>
specified<br>
above, this lets you search them out, and use AD<br>
groups w/o<br>
messing w/ your AD structure.<br>
<br>
2. pam_login_attribute sAMAccountName<br>
<br>
By default, when using openldap, logging in as 'joe'<br>
causes<br>
pam_ldap to look in the LDAP store for a record like<br>
uid=joe,(+base). For you, this means pam_ldap will<br>
ask the AD<br>
for any object that has uid=joe anywhere under your<br>
base ou:<br>
ou=security groups,dc=hq,dc=corp,dc=myhouse,dc=com.<br>
<br>
But in Active Directory land, user accounts don't<br>
have a 'uid'<br>
field that gets populated with your login name, it uses a<br>
different field, called sAMAccountName. This<br>
directive tells pam<br>
to look for sAMAccountName=joe when talking to the active<br>
directory, which is what the AD is expecting.<br>
<br>
Also, you can subtract tac_plus from the mix and just<br>
try to<br>
make sure pam works. In your ldap.conf, you can put a<br>
line like<br>
<br>
debug 256<br>
<br>
to get lots of debug into on console and in log<br>
files, and then<br>
run su - <username>, subbing in your AD user account<br>
name. The<br>
higher the debug number, the more debug output you'll<br>
get.<br>
<br>
Adam<br>
<br>
<br>
<br>
<br>
A user being a member of multiple groups shouldn't be a problem.<br>
Just be sure that the account you specify for your binddn has<br>
the ability to see the "memberof" information about your users.<br>
Also, you'll probably need to specify the password for the<br>
network services user in the bindpw for it to work...<br>
<br>
<br>
All the nss bits shouldn't be necessary for pam to work.<br>
<br>
<br>
<br>
</div></div></blockquote>
<br>
can you 'su - <user>' on the tacacs server and authenticate?<br>
<br>
Strange about the debug...I know I get gobs of output...<br>
</blockquote></div><br>