[tac_plus] Re: Issue with Cisco switch authentication against Microsoft Active Directory

[Hailu Meng]

On Thu, Nov 19, 2009 at 9:26 PM, adam <prozaconstilts at gmail.com> wrote:

> Hailu Meng wrote:
>
>> Adam,
>>
>> 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.
>>
>
> You shouldn't need to have to define the user in CentOS, that's the point
> of using ldap for authentication. The user is defined in ldap, not in
> CentOS. Now that I think about it, su - <user> probably wouldn't work
> anyway, as AD doesn't by default have the data needed by a linux box to
> allow login...but see below for more options.
>
>
>
>> 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.
>>
>
> Try using -D:
>
> from `man ldapsearch`:
>
> -D binddn
>  Use the Distinguished Name binddn to bind to the LDAP directory.
>
> so -D cn=username,ou=my_ou,dc=my_dc should let you try to authenticate
> using whatever user you want to define. Just check and double check you get
> the right path in that dn.


Actually in my ldap.conf, I set bindcn to one testing user in AD. And bind
is successful with user password (bindpw). I set this because lots of
articles say I need a proxy user account to bind. Then the other user in the
same group can be searched and authenticated. Maybe I get wrong, but the
result is good. They find my user. So I guess this -D and -w does the same
thing as the configuration in ldap.conf. I mean bindcn and bindpw, right? I
can try some user's password tomorrow morning. To see what will happen. If
there is no problem in this part, can we say the PAM/LDAP is clear? The
issue then could be the interface between tacacs and pam?

>
>
>  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.
>>
>
> only the libs and client. You should not need the server. In the
> ldapsearch, you can use -d <integer> to get debugging info for that search.
> As before, higher number = more debug
>
>
>  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.
>>
>
> Ethereal should catch all data flowing between the client and server. If
> you can search out the user in your AD right now, then one of two things is
> happening:
>
> 1. You are performing anonymous searches. In this case, no username and pw
> is provided, and your AD is happy to hand over info to anyone who asks for
> it. If this is the case, you will _not_ see authentication information. The
> following MS KB article should probably help you determine on your AD if
> anonymous queries are allowed:
>
> http://support.microsoft.com/kb/320528
>
> It has exact instructions for how to get it going, but you can follow along
> with it to check your current settings without making any changes.
>
> I will check this out tomorrow morning.


> 2. Authentication is happening. It will be the _very_ first thing the
> client and server perform, after basic connection establishment. Look for it
> at the very beginning of a dump.

When I input Username in my cisco switch, I saw the LDAP packet sent from my
tacacs server to AD server. And AD sent back a "search result" which include
my user information including "sAMAountName" (Username), "description",
"group name" and "cn". It seems good start.

>
>
> Also, it's a bit overkill, but the following article is extremely
> informative about all the different ways you can plug linux into AD for
> authentication. It might offer some hints...


What article is following? Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.shrubbery.net/pipermail/tac_plus/attachments/20091119/31209db3/attachment.html