osdir.com
mailing list archive F.A.Q. -since 2001!



Subject: RE: DIGEST-MD5 and Windows 2003 Active Directory -
msg#00007

List: lang.perl.modules.ldap

Mail Archive Navigation:
by Date: Prev Next Date Index by Thread: Prev Next Thread Index

I've done some more checking and I've found some problems with
Authen::SASL::Perl::Digest_MD5. The handling of qop from the challenge
to the response is too simplistic and needs to be amended. This will add
the requirement that values for crypt in the challenge will also need
processing. Also the value of qop in the response is being quoted and
shouldn't be. These problems will certainly cause the authentication to
AD 2003 to fail.

I don't have a patch yet for the above issues, as some further research
is required and I don't have much time to dedicate to this right now.

Even with playing around with values in the response that I thought were
correct, I never managed to authenticate to Windows 2003 Active
Directory. There are a number of user options on the AD side (using
reversible encryption for the users password for one) that might require
tweaking.

Regards,

Paul.

-----Original Message-----
From: Paul Connolly [mailto:Paul.Connolly@xxxxxxxxxxxxxxxx]
Sent: 08 September 2003 07:10
To: 'Johnson, Brian K'; perl-ldap@xxxxxxxx
Subject: RE: DIGEST-MD5 and Windows 2003 Active Directory

I haven't done any testing of Authen::SASL::PERL::DIGEST_MD5 against
Windows 2003, but try adding the serv callback to the constructor, e.g.

$sasl = Authen::SASL->new(
mechanism => 'DIGEST-MD5',
callback => {
user => $dn,
pass => $password,
serv => 'lm.local',
},
);

Regards,

Paul.

-----Original Message-----
From: Johnson, Brian K [mailto:brian.k.johnson@xxxxxxxx]
Sent: 05 September 2003 15:58
To: perl-ldap@xxxxxxxx
Subject: DIGEST-MD5 and Windows 2003 Active Directory

After installing Windows 2003 on my testbed machine I noticed that AD
under 2003 now accepts DIGEST-MD5 as a SASL mechanism (Hurrah!) as seen
from this snippet of the rootdse dump:

4> supportedSASLMechanisms: GSSAPI; GSS-SPNEGO; EXTERNAL;
DIGEST-MD5;

Anyway, I tried using sasl with digest-md5 and it is not working. Any
suggestions would be welcome. Below is my test code and some debug
output. Oh, the 'normal' plaintext authenticated bind which is commented
out works just fine.

> use net::LDAP;
> use Authen::SASL;
> $dn="CN=Administrator,CN=users,DC=lm,DC=local";
>
> $password="pass4YOU";
>
> $sasl = Authen::SASL->new(
> mechanism => 'DIGEST-MD5',
> callback => {
> user => $dn,
> pass => $password,
> },
> );
>
>
> $ldap = new Net::LDAP("bjtest23.lm.local",port => 389, debug => 3,
version =>3) or die "new failed";
> #$result=$ldap->ldapbind(dn =>$dn, password =>$password) || die "bind
failed";
> $result=$ldap->ldapbind(sasl=>$sasl) || die "bind failed";
>
> $err=$result->code;
> print "ERR: $err\n";
>
>
>
Net::LDAP=HASH(0x183f1f4) sending:

30 18 02 01 01 60 13 02 01 03 04 00 A3 0C 04 0A 0....`..........
44 49 47 45 53 54 2D 4D 44 35 __ __ __ __ __ __ DIGEST-MD5

Net::LDAP=HASH(0x183f1f4) received:

30 84 00 00 00 E0 02 01 01 61 84 00 00 00 D7 0A 0........a......
01 0E 04 00 04 00 87 82 00 CC 71 6F 70 3D 22 61 ..........qop="a
75 74 68 2C 61 75 74 68 2D 69 6E 74 2C 61 75 74 uth,auth-int,aut
68 2D 63 6F 6E 66 22 2C 63 69 70 68 65 72 3D 22 h-conf",cipher="
33 64 65 73 2C 64 65 73 2C 72 63 34 2D 34 30 2C 3des,des,rc4-40,
72 63 34 2C 72 63 34 2D 35 36 22 2C 61 6C 67 6F rc4,rc4-56",algo
72 69 74 68 6D 3D 6D 64 35 2D 73 65 73 73 2C 6E rithm=md5-sess,n
6F 6E 63 65 3D 22 35 30 37 39 66 62 34 38 62 39 once="5079fb48b9
37 33 63 33 30 31 32 64 66 37 38 63 34 36 65 33 73c3012df78c46e3
61 33 31 33 39 63 63 64 39 65 64 30 62 35 34 31 a3139ccd9ed0b541
66 34 38 39 39 36 31 61 65 62 30 31 65 36 34 64 f489961aeb01e64d
64 30 35 64 64 66 61 35 36 32 31 39 33 64 66 30 d05ddfa562193df0
30 33 35 33 34 63 22 2C 63 68 61 72 73 65 74 3D 03534c",charset=
75 74 66 2D 38 2C 72 65 61 6C 6D 3D 22 6C 6D 2E utf-8,realm="lm.
6C 6F 63 61 6C 22 __ __ __ __ __ __ __ __ __ __ local"

Net::LDAP=HASH(0x183f1f4) sending:

30 82 01 6D 02 01 02 60 82 01 66 02 01 03 04 00 0..m...`..f.....
A3 82 01 5D 04 0A 44 49 47 45 53 54 2D 4D 44 35 ...]..DIGEST-MD5
04 82 01 4D 63 68 61 72 73 65 74 3D 75 74 66 2D ...Mcharset=utf-
38 2C 63 6E 6F 6E 63 65 3D 22 37 65 35 64 36 33 8,cnonce="7e5d63
35 39 61 61 33 64 38 62 66 32 64 31 61 65 35 37 59aa3d8bf2d1ae57
37 37 61 37 66 63 32 37 31 63 22 2C 64 69 67 65 77a7fc271c",dige
73 74 2D 75 72 69 3D 22 6C 64 61 70 2F 62 6A 74 st-uri="ldap/bjt
65 73 74 32 33 2E 6C 6D 2E 6C 6F 63 61 6C 22 2C est23.lm.local",
6E 63 3D 30 30 30 30 30 30 30 31 2C 6E 6F 6E 63 nc=00000001,nonc
65 3D 22 35 30 37 39 66 62 34 38 62 39 37 33 63 e="5079fb48b973c
33 30 31 32 64 66 37 38 63 34 36 65 33 61 33 31 3012df78c46e3a31
33 39 63 63 64 39 65 64 30 62 35 34 31 66 34 38 39ccd9ed0b541f48
39 39 36 31 61 65 62 30 31 65 36 34 64 64 30 35 9961aeb01e64dd05
64 64 66 61 35 36 32 31 39 33 64 66 30 30 33 35 ddfa562193df0035
33 34 63 22 2C 71 6F 70 3D 22 61 75 74 68 2C 61 34c",qop="auth,a
75 74 68 2D 69 6E 74 2C 61 75 74 68 2D 63 6F 6E uth-int,auth-con
66 22 2C 72 65 61 6C 6D 3D 22 6C 6D 2E 6C 6F 63 f",realm="lm.loc
61 6C 22 2C 72 65 73 70 6F 6E 73 65 3D 32 63 33 al",response=2c3
65 33 65 63 31 31 34 38 36 39 31 64 30 66 36 39 e3ec1148691d0f69
36 37 39 32 65 66 61 38 39 38 61 39 61 2C 75 73 6792efa898a9a,us
65 72 6E 61 6D 65 3D 22 43 4E 3D 41 64 6D 69 6E ername="CN=Admin
69 73 74 72 61 74 6F 72 2C 43 4E 3D 75 73 65 72 istrator,CN=user
73 2C 44 43 3D 6C 6D 2C 44 43 3D 6C 6F 63 61 6C s,DC=lm,DC=local
22 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ "

Net::LDAP=HASH(0x183f1f4) received:

30 84 00 00 00 65 02 01 02 61 84 00 00 00 5C 0A 0....e...a....\.
01 31 04 00 04 55 38 30 30 39 30 33 30 41 3A 20 .1...U8009030A:
4C 64 61 70 45 72 72 3A 20 44 53 49 44 2D 30 43 LdapErr: DSID-0C
30 39 30 34 31 39 2C 20 63 6F 6D 6D 65 6E 74 3A 090419, comment:
20 41 63 63 65 70 74 53 65 63 75 72 69 74 79 43 AcceptSecurityC
6F 6E 74 65 78 74 20 65 72 72 6F 72 2C 20 64 61 ontext error, da
74 61 20 30 2C 20 76 65 63 65 00 __ __ __ __ __ ta 0, vece.


brian.k.johnson@xxxxxxxx






Thread at a glance:

Previous Message by Date:

Re: Net::LDAP and mod_perl

hi! maybe you should check the ResourcePool::Factory::Net::LDAP module. one of it's side effects is that it holds persistent connections. it does also clean up broken connections. things like failover and loadbalancing can be done with the ResourcePool::LoadBalancer. the only drawback is that it isn't transparent like Apache::DBI. -markus - - - - - - - - - - - - - Markus Winand e-mail: mws@xxxxxxxxxxxxx web: www.fatalmind.com On Mon, 8 Sep 2003, Marco Marongiu wrote: > Alexander.Farber@xxxxxxxxx wrote: > > I would like to change they script so that the opened LDAP- > > connection is being cached. Would using a global variable to > > hold the LDAP-object and just checking if it's defined suffice: > > AFAIK, Apache::DBI does exactly the same with DBI handles. Besides, it > is completely transparent to the scripts; for example, if you had a > script that wasn't designed to take advantage of cached connections, and > it explicitly closes the database handle, the script will continue to > work but, as you may guess, the dbh won't be closed at all and, maybe, > it will find it there the next time it will connect() > > Sorry if my english is not good as my italian :-) > > Ciao > --M > >

Next Message by Date:

Escaping parameters in search filters

Hi, Is there built-in support in Net::LDAP for escaping parameters in search filters? Something like DBI's placeholders or at least a method/subroutine in public API which can escape strings for me. Example: my $result = $ldap->search(base => $base, filter => "uid=$user"); I want to be able to ensure that string $user is properly escaped in search filter. I've checked Net::LDAP docs but I haven't found anything. It seems there is some code for escaping and de-escaping strings (subs _escape and _unescape) for LDAP search queires in Net::LDAP::Filter but it doesn't seem to be a part of public API so I don't think it is wise to rely on them. BTW it seems there is a bug in Net::LDAP::Filter docs: it is documented to have method asn() but there is no such method in Net::LDAP::Filter. P.S. Please Cc replies to me as I'm not subscribed to this mailing list. -- Ilya Martynov, ilya@xxxxxxxxxxx CTO IPonWEB (UK) Ltd Quality Perl Programming and Unix Support UK managed @ offshore prices - http://www.iponweb.net Personal website - http://martynov.org

Previous Message by Thread:

RE: DIGEST-MD5 and Windows 2003 Active Directory

I haven't done any testing of Authen::SASL::PERL::DIGEST_MD5 against Windows 2003, but try adding the serv callback to the constructor, e.g. $sasl = Authen::SASL->new( mechanism => 'DIGEST-MD5', callback => { user => $dn, pass => $password, serv => 'lm.local', }, ); Regards, Paul. -----Original Message----- From: Johnson, Brian K [mailto:brian.k.johnson@xxxxxxxx] Sent: 05 September 2003 15:58 To: perl-ldap@xxxxxxxx Subject: DIGEST-MD5 and Windows 2003 Active Directory After installing Windows 2003 on my testbed machine I noticed that AD under 2003 now accepts DIGEST-MD5 as a SASL mechanism (Hurrah!) as seen from this snippet of the rootdse dump: 4> supportedSASLMechanisms: GSSAPI; GSS-SPNEGO; EXTERNAL; DIGEST-MD5; Anyway, I tried using sasl with digest-md5 and it is not working. Any suggestions would be welcome. Below is my test code and some debug output. Oh, the 'normal' plaintext authenticated bind which is commented out works just fine. > use net::LDAP; > use Authen::SASL; > $dn="CN=Administrator,CN=users,DC=lm,DC=local"; > > $password="pass4YOU"; > > $sasl = Authen::SASL->new( > mechanism => 'DIGEST-MD5', > callback => { > user => $dn, > pass => $password, > }, > ); > > > $ldap = new Net::LDAP("bjtest23.lm.local",port => 389, debug => 3, version =>3) or die "new failed"; > #$result=$ldap->ldapbind(dn =>$dn, password =>$password) || die "bind failed"; > $result=$ldap->ldapbind(sasl=>$sasl) || die "bind failed"; > > $err=$result->code; > print "ERR: $err\n"; > > > Net::LDAP=HASH(0x183f1f4) sending: 30 18 02 01 01 60 13 02 01 03 04 00 A3 0C 04 0A 0....`.......... 44 49 47 45 53 54 2D 4D 44 35 __ __ __ __ __ __ DIGEST-MD5 Net::LDAP=HASH(0x183f1f4) received: 30 84 00 00 00 E0 02 01 01 61 84 00 00 00 D7 0A 0........a...... 01 0E 04 00 04 00 87 82 00 CC 71 6F 70 3D 22 61 ..........qop="a 75 74 68 2C 61 75 74 68 2D 69 6E 74 2C 61 75 74 uth,auth-int,aut 68 2D 63 6F 6E 66 22 2C 63 69 70 68 65 72 3D 22 h-conf",cipher=" 33 64 65 73 2C 64 65 73 2C 72 63 34 2D 34 30 2C 3des,des,rc4-40, 72 63 34 2C 72 63 34 2D 35 36 22 2C 61 6C 67 6F rc4,rc4-56",algo 72 69 74 68 6D 3D 6D 64 35 2D 73 65 73 73 2C 6E rithm=md5-sess,n 6F 6E 63 65 3D 22 35 30 37 39 66 62 34 38 62 39 once="5079fb48b9 37 33 63 33 30 31 32 64 66 37 38 63 34 36 65 33 73c3012df78c46e3 61 33 31 33 39 63 63 64 39 65 64 30 62 35 34 31 a3139ccd9ed0b541 66 34 38 39 39 36 31 61 65 62 30 31 65 36 34 64 f489961aeb01e64d 64 30 35 64 64 66 61 35 36 32 31 39 33 64 66 30 d05ddfa562193df0 30 33 35 33 34 63 22 2C 63 68 61 72 73 65 74 3D 03534c",charset= 75 74 66 2D 38 2C 72 65 61 6C 6D 3D 22 6C 6D 2E utf-8,realm="lm. 6C 6F 63 61 6C 22 __ __ __ __ __ __ __ __ __ __ local" Net::LDAP=HASH(0x183f1f4) sending: 30 82 01 6D 02 01 02 60 82 01 66 02 01 03 04 00 0..m...`..f..... A3 82 01 5D 04 0A 44 49 47 45 53 54 2D 4D 44 35 ...]..DIGEST-MD5 04 82 01 4D 63 68 61 72 73 65 74 3D 75 74 66 2D ...Mcharset=utf- 38 2C 63 6E 6F 6E 63 65 3D 22 37 65 35 64 36 33 8,cnonce="7e5d63 35 39 61 61 33 64 38 62 66 32 64 31 61 65 35 37 59aa3d8bf2d1ae57 37 37 61 37 66 63 32 37 31 63 22 2C 64 69 67 65 77a7fc271c",dige 73 74 2D 75 72 69 3D 22 6C 64 61 70 2F 62 6A 74 st-uri="ldap/bjt 65 73 74 32 33 2E 6C 6D 2E 6C 6F 63 61 6C 22 2C est23.lm.local", 6E 63 3D 30 30 30 30 30 30 30 31 2C 6E 6F 6E 63 nc=00000001,nonc 65 3D 22 35 30 37 39 66 62 34 38 62 39 37 33 63 e="5079fb48b973c 33 30 31 32 64 66 37 38 63 34 36 65 33 61 33 31 3012df78c46e3a31 33 39 63 63 64 39 65 64 30 62 35 34 31 66 34 38 39ccd9ed0b541f48 39 39 36 31 61 65 62 30 31 65 36 34 64 64 30 35 9961aeb01e64dd05 64 64 66 61 35 36 32 31 39 33 64 66 30 30 33 35 ddfa562193df0035 33 34 63 22 2C 71 6F 70 3D 22 61 75 74 68 2C 61 34c",qop="auth,a 75 74 68 2D 69 6E 74 2C 61 75 74 68 2D 63 6F 6E uth-int,auth-con 66 22 2C 72 65 61 6C 6D 3D 22 6C 6D 2E 6C 6F 63 f",realm="lm.loc 61 6C 22 2C 72 65 73 70 6F 6E 73 65 3D 32 63 33 al",response=2c3 65 33 65 63 31 31 34 38 36 39 31 64 30 66 36 39 e3ec1148691d0f69 36 37 39 32 65 66 61 38 39 38 61 39 61 2C 75 73 6792efa898a9a,us 65 72 6E 61 6D 65 3D 22 43 4E 3D 41 64 6D 69 6E ername="CN=Admin 69 73 74 72 61 74 6F 72 2C 43 4E 3D 75 73 65 72 istrator,CN=user 73 2C 44 43 3D 6C 6D 2C 44 43 3D 6C 6F 63 61 6C s,DC=lm,DC=local 22 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ " Net::LDAP=HASH(0x183f1f4) received: 30 84 00 00 00 65 02 01 02 61 84 00 00 00 5C 0A 0....e...a....\. 01 31 04 00 04 55 38 30 30 39 30 33 30 41 3A 20 .1...U8009030A: 4C 64 61 70 45 72 72 3A 20 44 53 49 44 2D 30 43 LdapErr: DSID-0C 30 39 30 34 31 39 2C 20 63 6F 6D 6D 65 6E 74 3A 090419, comment: 20 41 63 63 65 70 74 53 65 63 75 72 69 74 79 43 AcceptSecurityC 6F 6E 74 65 78 74 20 65 72 72 6F 72 2C 20 64 61 ontext error, da 74 61 20 30 2C 20 76 65 63 65 00 __ __ __ __ __ ta 0, vece. brian.k.johnson@xxxxxxxx

Next Message by Thread:

Net::LDAP and mod_perl

Hi, I have a mod_perl handler which opens and closes an LDAP connection each time they script is being started: $ldap = Net::LDAP->new('xxx.xxx.nokia.com') or die "$@"; $ldap->bind(); ... $ldap->unbind(); I would like to change they script so that the opened LDAP- connection is being cached. Would using a global variable to hold the LDAP-object and just checking if it's defined suffice: my $LDAP; ... $LDAP ||= Net::LDAP->new('xxx.xxx.nokia.com')->bind() or die "$@"; I'm worried if that's the correct way and if the $LDAP object will reliably turn into undef on the timeouts. Thank you Regards Alex
blog comments powered by Disqus

Home | News | Sitemap | FAQ | advertise | OSDir is an Inevitable website. GBiz is too!