Looking at all the code that has been suggested, it seems that everyone who
uses Net::LDAP is using simple authentication (setting password => xxx,
rather than using SASL). I have gotten this to work as well, and can query
AD in this way. Unfortunately, this method sends the user's password over
the network in plaintext, which is not secure enough for my needs.
I looked at getting the Net::LDAP::Cyrus module set up, and started to
realize that setting up Cyrus on a win2k/xp platform was going to be a bit
more involved than I expected. I am already new to LDAP, and the Cyrus
stuff seems to be a project all by itself. This seems to rule out using
GSSAPI.
There seems to be no way to take advantage of native windows authentication
(kerberos?) from Net::LDAP easily. Hopefully a future release?
I looked at the code on www.rallenhome.com and saw a snippet that intrigued
me. Does the following code use windows authentication, or is the password
sent out in plaintext?
# Setup the ADO connections
my $connObj = Win32::OLE->new('ADODB.Connection');
$connObj->{Provider} = "ADsDSOObject";
$connObj->Properties->{'User ID'} = $user;
$connObj->Properties->{'Password'} = $passwd;
$connObj->Open;
Thanks for all the replies.
-ben
>Message-ID:
<[EMAIL PROTECTED]>
>To: "'perl-ldap[at]perl.org'" <perl-ldap[at]perl.org>
>Subject: RE: [Fwd: howto perl-ldap AD authentication with SASL/GSSAPI mech
anism?]
>Date: Thu, 28 Aug 2003 09:07:30 -0400
>From: rallen[at]cisco.com (Robbie Allen)
>
>Querying AD with Net::LDAP is easy and straightforward. MS does a lot of
>proprietary things, but they do not do "very proprietary LDAP *type* things
>on 389". AD is very compliant to the LDAPv3 spec (as compliant as the
other
>vendors anyway). You can perform LDAP queries against port 389 on any AD
>domain controller and you can query port 3268 on any global catalog server.
>
>
>You can find a bunch of examples of using Net::LDAP against AD here:
>http://www.rallenhome.com/books/managingenterprisead/code.html
>
>Robbie Allen
>http://www.rallenhome.com/
>
>> -----Original Message-----
>> From: Tim Musson [mailto:[EMAIL PROTECTED]
>> Sent: Thursday, August 28, 2003 8:20 AM
>> To: Graham Barr
>> Subject: Re: [Fwd: howto perl-ldap AD authentication with
>> SASL/GSSAPI mechanism?]
>>
>>
>> Hey Graham, or Ben :-)
>>
>> My MUA believes you used Ximian Evolution 1.4.4
>> to write the following on Wednesday, August 27, 2003 at 3:06:04 PM.
>>
>> GB> I have spent a week trying to search Active Directory via
>> Net::LDAP.
>> GB> I finally found the xray mailing list (geo crawler does
>> not seem to
>> GB> have information for this year?) via your CPAN information. I have
>> GB> spent all day reading posts (many of them yours), which has led me
>> GB> to believe that I need to use Simon' s module
>> GB> (perl-cyrus-sasl-0.02.tar.gz) to use GSSAPI to bind to AD. I am
>> GB> going to start down this path, but I realize that many people are
>> GB> trying to do this. Unfortunately, I have yet to find a
>> decent howto
>> GB> on it. Perhaps you can point me in the right direction?
>>
>> GB> Also, I saw the post
>> GB>
>> (http://www.xray.mpe.mpg.de/mailing-lists/perl-ldap/2003-01/ms
>> g00116.html)
>> GB> that suggested putting Active Directory info in your
>> Net:LDAP book.
>> GB> I would buy it if it contained this information,
>> especially the hard
>> GB> to track down authentication piece. Several people at my company
>> GB> have been trying to do this (AD via perl).
>>
>> I also had to do this, and have written a script taking
>> things from the
>> Net::LDAP::Examples link on http://perl-ldap.sourceforge.net/.
>>
>> I broke most everything into subroutines because I needed to do 3
>> different queries to 3 different LDAP sources (syncing them...).
>>
>> The one thing I had the hardest time with is you don't use
>> port 389 for
>> LDAP access (I think AD does some very proprietary LDAP
>> *type* things on
>> 389). The MS web site has a document about it, and my AD
>> admins followed
>> it and set up port 3268 for LDAP queries. Another thing about
>> AD LDAP is
>> that by default there is no anonymous access at all. We decided it was
>> not needed, and set up an ID with rights...
>>
>> The last odd AD/LDAP thing I can think of off the top of my
>> head is they
>> use CN instead of UID...
>>
>> ,----- [ Here is my code (that works), I am *very* open to
>> suggestions :-) ]
>
