LDAP - Authen:SASL::Perl::DIGEST-MD5 Problem

Author

Authen:SASL::Perl::DIGEST-MD5 Problem

SteveC

2005-08-04, 9:07 am

Hi,

I have been trying to authenticate to an Active Directory LDAP server using Authen::SASL::Perl::DIGEST_MD5 and am failing. Using OpenLDAP's ldapsearch and the -Y DIGEST-MD5 command line option, I can authenticate with no problem -- so the credentials I a
m using are certainly correct. However, with the script below I get an error code 49 -- invalid credentials.

use Net::LDAP;
use Authen::SASL qw/Perl/;

my $host = "fqdn.of.domain.controller"; # one of our AD domain controllers

my $user = 'me@myDomain'; # my UserPrincipalName in AD
my $passwd = 'myPassword';

my $sasl = Authen::SASL->new(
mechanism => 'DIGEST-MD5',
callback => {
user => $user,
pass => $passwd,
}
);
my $ldap = Net::LDAP->new($host, debug=>12, version => 3);
my $msg = $ldap->bind("", sasl => $sasl);
if($msg->code) {
print $msg->error . "\n";
}
else {
print "IT WORKED!!!\n";
exit(0);
}

The only thing of note in the AD environment is that we have multiple domain controllers. This lead me to look at the 'serv' callback parameter, as that appears to be used when there is a replicated service. One thing I have noticed while investigating t
his, is that there appears to be a bug in the 'serv' parameter handling of the DIGEST_MD5 module. When this parameter is present, the module appends the value to digest_uri (note the underscore), it should do so to digest-md5. However, even when I chang
e the module and try to use this parameter I still get the same authentication problem. [In my testing with ther 'serv' parameter, the $host is the fqdn of a domain controller, and the serv value was the name of the domain I am trying to authenticate to.]

Any ideas what I am doing wrong?

Steve

Steve Clark

2005-08-04, 9:07 am

On 8/4/05, SteveC <steve37a@gmail.com> wrote:

>=20
> The only thing of note in the AD environment is that we have multiple dom=
ain
> controllers. This lead me to look at the 'serv' callback parameter, as t=
hat
> appears to be used when there is a replicated service. One thing I have
> noticed while investigating this, is that there appears to be a bug in th=
e
> 'serv' parameter handling of the DIGEST_MD5 module. When this parameter =
is
> present, the module appends the value to digest_uri (note the underscore)=
,
> it should do so to digest-md5. However, even when I change the module an=
d
^^^^^^^^^^
Oops! I mean digest-uri of course

> try to use this parameter I still get the same authentication problem. [I=
n
> my testing with ther 'serv' parameter, the $host is the fqdn of a domain
> controller, and the serv value was the name of the domain I am trying to
> authenticate to.]
>

SteveC

2005-08-04, 9:07 am

On 8/4/05, SteveC <steve37a@gmail.com <mailto:steve37a@gmail.com>> wrote:

>
> The only thing of note in the AD environment is that we have multiple
domain
> controllers. This lead me to look at the 'serv' callback parameter,
as that
> appears to be used when there is a replicated service. One thing I have
> noticed while investigating this, is that there appears to be a bug
in the
> 'serv' parameter handling of the DIGEST_MD5 module. When this
parameter is
> present, the module appends the value to digest_uri (note the
underscore),
> it should do so to digest-md5. However, even when I change the
module and
^^^^^^^^^^
Oops! I mean digest-uri of course

Steve

Peter Marschall

2005-08-06, 5:03 pm

Hi Steve,

On Thursday 04 August 2005 11:52, SteveC wrote:
> I have been trying to authenticate to an Active Directory LDAP server using
> Authen::SASL::Perl::DIGEST_MD5 and am failing. Using OpenLDAP's ldapsearch
> and the -Y DIGEST-MD5 command line option, I can authenticate with no
> problem -- so the credentials I am using are certainly correct. However,
> with the script below I get an error code 49 -- invalid credentials.
>
>
> use Net::LDAP;
> use Authen::SASL qw/Perl/;
>
> my $host = "fqdn.of.domain.controller"; # one of our AD domain
> controllers
>
> my $user = 'me@myDomain'; # my UserPrincipalName in AD
> my $passwd = 'myPassword';
>
> my $sasl = Authen::SASL->new(
> mechanism => 'DIGEST-MD5',
> callback => {
> user => $user,
> pass => $passwd,
> }
> );
> my $ldap = Net::LDAP->new($host, debug=>12, version => 3);
> my $msg = $ldap->bind("", sasl => $sasl);
> if($msg->code) {
> print $msg->error . "\n";
> }
> else {
> print "IT WORKED!!!\n";
> exit(0);
> }
>
>
> The only thing of note in the AD environment is that we have multiple
> domain controllers. This lead me to look at the 'serv' callback parameter,
> as that appears to be used when there is a replicated service. One thing I
> have noticed while investigating this, is that there appears to be a bug in
> the 'serv' parameter handling of the DIGEST_MD5 module. When this
> parameter is present, the module appends the value to digest_uri (note the
> underscore), it should do so to digest-uri. However, even when I change
> the module and try to use this parameter I still get the same
> authentication problem. [In my testing with ther 'serv' parameter, the
> $host is the fqdn of a domain controller, and the serv value was the name
> of the domain I am trying to authenticate to.]

I guess you are right with digest-uri vs. digest_uri

A few questions / requests:
- Did you replace both occurrences of 'digest_uri' with 'digest-uri' ?
- Did you try the script with Authen::SASL::Cyrus as Backend ?
- Did you check the communication for the different implementations
on the wire ?

If not, would you mind to do so ?

Thank you for your help
Peter

--
Peter Marschall
eMail: peter@adpm.de

Steve Clark

2005-08-09, 9:06 am

Hi Peter,

"Peter Marschall" <peter@adpm.de> wrote in message
news:<200508061707.42213.peter@adpm.de>...
> Hi Steve,
>
> On Thursday 04 August 2005 11:52, SteveC wrote:
using[color=darkred]
ldapsearch[color=darkred]
However,[color=darkred]
....[color=darkred]
parameter,[color=darkred]
I[color=darkred]
in[color=darkred]
the[color=darkred]
name[color=darkred]
>
> I guess you are right with digest-uri vs. digest_uri
>
> A few questions / requests:
> - Did you replace both occurrences of 'digest_uri' with 'digest-uri' ?
> - Did you try the script with Authen::SASL::Cyrus as Backend ?
> - Did you check the communication for the different implementations
> on the wire ?
>
> If not, would you mind to do so ?
>
> Thank you for your help
> Peter
>
>
> --
> Peter Marschall
> eMail: peter@adpm.de

Wrt your points above:

- I only saw one instance of 'digest_uri' -- I have checked on the CPAN
site (in source DIGEST_MD5) and that is all that I can spot there as well.
All the other occurences are the correct 'digest-uri'.

- The reason I was trying the Perl version of the DIGEST-MD5 SASL
authentication was that I am having even more problems with the Cyrus
version! I have downloaded and installed the most recent version (the
0.13-server version) ---built against cyrus SASL2. But when I try to use it
(the same test script as my original post except removing the qw/Perl/) I
get a 'Local error' message -- there is no network activity -- hence my
'even more problems' comment!

- I don't have access to the test environment at the moment, but from what I
remember, when using ldapsearch the DIGEST authentication actually selects
'auth-conf', whereas the perl module selects 'auth'.

Steve

SteveC

2005-08-09, 5:08 pm

Steve Clark wrote:
> Hi Peter,
>
> "Peter Marschall" <peter@adpm.de> wrote in message
> news:<200508061707.42213.peter@adpm.de>...
>
> using
>
> ldapsearch
>
> However,
>
> ...
>
> parameter,
>
> I
>
> in
>
> the
>
> name
>
>
>
> Wrt your points above:
>
> - I only saw one instance of 'digest_uri' -- I have checked on the CPAN
> site (in source DIGEST_MD5) and that is all that I can spot there as well.
> All the other occurences are the correct 'digest-uri'.
>
> - The reason I was trying the Perl version of the DIGEST-MD5 SASL
> authentication was that I am having even more problems with the Cyrus
> version! I have downloaded and installed the most recent version (the
> 0.13-server version) ---built against cyrus SASL2. But when I try to use it
> (the same test script as my original post except removing the qw/Perl/) I
> get a 'Local error' message -- there is no network activity -- hence my
> 'even more problems' comment!
>
> - I don't have access to the test environment at the moment, but from what I
> remember, when using ldapsearch the DIGEST authentication actually selects
> 'auth-conf', whereas the perl module selects 'auth'.
>
> Steve
>

It looks like I have got into the habit of replying to myself -- sorry
for the noise I am generating.

I have looked into the third of the above bullets and I think that I
have found out what is going on. In summary:

- When using ldapsearch, although I thought that I was binding to AD
with my UPN (userid_1@myDomain), ldapsearch was acually using my UNIX
account name, userid_2 (which is unfortunaley different from the prefiz
of my UPN, but is the same as the AD attribute sAMAccountName). It was
using this to authenticate to AD with the DIGEST-MD5 SASL method --
selecting auth-conf as I noted above.

- In my perl script, when I now use the sAMAccountname value (my UNIX
id) I can successfully authenticate. AD then compplains that I am only
using auth -- the domain security policy required auth-int or better (or
to run under SSL/TLS).

This now leaves me with a puzzle:
- Why is AD refusing to authenticate me using my UPN? According to the
AD documentation (for W2k3) digest hashes are calculated for a number
variants of alternate names (UPN and derivations of sAMAccountName) --
so why does it fail to allow me to log on -- evenn though it has
obviously 'matched' my account as after several attempts my account is
locked out.
- Presumably I am now going to need to get Authen::SASL::Cyrus working
so that I can use auth-int or auth-conf and so comform to our Domain
security policy (I could also use SSL/TLS but at present we don't have
that configured on our domain controllers). Any ideas on why the Cyrus
SASL gives 'Local error' even before generating any network traffic? I
certainly have digestmd5 enabled, and SASL2.

Steve

Graham Barr

2005-08-09, 5:08 pm

On Tue, August 9, 2005 8:57 am, SteveC said:
> - Presumably I am now going to need to get Authen::SASL::Cyrus working
> so that I can use auth-int or auth-conf and so comform to our Domain
> security policy

Or modify DIGEST_MD5.pm to perform them :-)

> (I could also use SSL/TLS but at present we don't have
> that configured on our domain controllers). Any ideas on why the Cyrus
> SASL gives 'Local error' even before generating any network traffic? I
> certainly have digestmd5 enabled, and SASL2.

IIRC there are two Authen::SASL::Cyrus implmentations. Someone did thier
own becuase they had little luck with the one on CPAN.

Does anyone on the list remember this?

Graham.

Simon Wilkinson

2005-08-09, 5:08 pm

Graham Barr wrote:
> IIRC there are two Authen::SASL::Cyrus implmentations. Someone did thier
> own becuase they had little luck with the one on CPAN.
>
> Does anyone on the list remember this?

There are three different implementations.

I produced one in the dim and distant past, which was never upgraded to
the new Authen::SASL API.

Mark Adamson from CMU produced one, which is the 'official'
Authen::SASL:Cyrus on CPAN. I don't know of anyone who's had much luck
using this in production without significant patches.

Patrick Boettcher produced a fork of Mark Adamson's module which is
available from
http://www.wi-bw.tfh-wildau.de/~pbo...ex.php?site=asc
which we're using locally.

You may find, depending on the application you're using the module with,
that you require additional patches to Patrick's code - in particular it
doesn't report the current mechanism in use correctly. However, it works
fine with Net::LDAP.

Cheers,

Simon.

Chris Ridd

2005-08-09, 5:08 pm

On 9/8/05 2:57, SteveC <steve37a@gmail.com> wrote:

> It looks like I have got into the habit of replying to myself -- sorry
> for the noise I am generating.
>
> I have looked into the third of the above bullets and I think that I
> have found out what is going on. In summary:
>
> - When using ldapsearch, although I thought that I was binding to AD
> with my UPN (userid_1@myDomain), ldapsearch was acually using my UNIX
> account name, userid_2 (which is unfortunaley different from the prefiz
> of my UPN, but is the same as the AD attribute sAMAccountName). It was
> using this to authenticate to AD with the DIGEST-MD5 SASL method --
> selecting auth-conf as I noted above.
>
> - In my perl script, when I now use the sAMAccountname value (my UNIX
> id) I can successfully authenticate. AD then compplains that I am only
> using auth -- the domain security policy required auth-int or better (or
> to run under SSL/TLS).
>
> This now leaves me with a puzzle:
> - Why is AD refusing to authenticate me using my UPN? According to the
> AD documentation (for W2k3) digest hashes are calculated for a number
> variants of alternate names (UPN and derivations of sAMAccountName) --
> so why does it fail to allow me to log on -- evenn though it has
> obviously 'matched' my account as after several attempts my account is
> locked out.
> - Presumably I am now going to need to get Authen::SASL::Cyrus working
> so that I can use auth-int or auth-conf and so comform to our Domain
> security policy (I could also use SSL/TLS but at present we don't have
> that configured on our domain controllers). Any ideas on why the Cyrus
> SASL gives 'Local error' even before generating any network traffic? I
> certainly have digestmd5 enabled, and SASL2.

Steve,

I've got the author of the DIGEST-MD5 I-D next to me, and he might be able
to shed some likght on what's going wrong. Can you send a protocol trace
from the various clients?

Cheers,

Chris

Quanah Gibson-Mount

2005-08-09, 5:08 pm

--On Tuesday, August 09, 2005 4:54 PM +0100 Simon Wilkinson
<simon@sxw.org.uk> wrote:

> Graham Barr wrote:
>
> There are three different implementations.
>
> I produced one in the dim and distant past, which was never upgraded to
> the new Authen::SASL API.
>
> Mark Adamson from CMU produced one, which is the 'official'
> Authen::SASL:Cyrus on CPAN. I don't know of anyone who's had much luck
> using this in production without significant patches.
>
> Patrick Boettcher produced a fork of Mark Adamson's module which is
> available from
> http://www.wi-bw.tfh-wildau.de/~pbo...ex.php?site=asc
> which we're using locally.

Patrick's release (the only one I've ever had any luck with) is now part of
CPAN, as authen-cyrus-sasl-server.

<http://search.cpan.org/~pboettch/Au...us-0.13-server/>

will get you Patrick's.

--Quanah

--
Quanah Gibson-Mount
Principal Software Developer
ITSS/Shared Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

"These censorship operations against schools and libraries are stronger
than ever in the present religio-political climate. They often focus on
fantasy and sf books, which foster that deadly enemy to bigotry and blind
faith, the imagination." -- Ursula K. Le Guin

SteveC

2005-08-09, 5:08 pm

Quanah Gibson-Mount wrote:
>
>
> --On Tuesday, August 09, 2005 4:54 PM +0100 Simon Wilkinson
> <simon@sxw.org.uk> wrote:
>
>
>
>
> Patrick's release (the only one I've ever had any luck with) is now part
> of CPAN, as authen-cyrus-sasl-server.
>
>
> <http://search.cpan.org/~pboettch/Au...us-0.13-server/>
>
> will get you Patrick's.
>
> --Quanah
>
> --
> Quanah Gibson-Mount
> Principal Software Developer
> ITSS/Shared Services
> Stanford University
> GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
>
> "These censorship operations against schools and libraries are stronger
> than ever in the present religio-political climate. They often focus on
> fantasy and sf books, which foster that deadly enemy to bigotry and blind
> faith, the imagination." -- Ursula K. Le Guin
>
That is the one that I have downloaded and installed and get the 'Local
error' with.

Steve

SteveC

2005-08-09, 5:08 pm

Chris Ridd wrote:
> On 9/8/05 2:57, SteveC <steve37a@gmail.com> wrote:
>
>
>
>
> Steve,
>
> I've got the author of the DIGEST-MD5 I-D next to me, and he might be able
> to shed some likght on what's going wrong. Can you send a protocol trace
> from the various clients?
>
> Cheers,
>
> Chris
>
>
I think that I might have spotted what's causing my problem:

This Microsoft technet article

http://www.microsoft.com/technet/pr...0633aae5f9.mspx

explains how Microsoft pre-computes and saves certain MD5 hashes based
on combinations of account names (UPN and SamAccountName, DNS names,
fixed strings, and paswords -- in various combinations) [See Digest
Hashes section in the body]. These pre-computed hashes mean that AD
doesn't need to hold passwords in a reversible encryption format.[This
is a new feature in W2k3 -- W2k needs the reversible encryption
apparently if digest authentication is going to be used.]

In my environment, I have (don't ask my to justify why all the following
non-standard settings!):
- My UPN is name_1@BASE (where BASE is some string, i.e. not a real fqdn)
- my SamAccountName is name_2
- the forest root domain is ROOT.BASE
- the AD domain I belong to is XXXX.ROOT.BASE
- the flat domain name is XXXX

So, given all the above, when the 'A1' hash is calculated the 'realm'
used by DIGEST_MD5 is the one supplied by the domain controller which is
XXXX.ROOT.BASE. If this is the case, then the only entry from the table
in the above technet article that can ever work is if I provide the
SamAccountname -- then row 2 of the table (SamAccountName +
DNSDomainaname + password) will match a pre-computed hash.

Does that make sense?

If that is the case, then if the SASL & DIGEST_MD5 modules provided a
callback to enable the realm to be overridden, a user could provide one
of the Microsoft 'standard' values (in the case of a perverse
configuration like mine!) and things would work with the 'preferred'
UPN. [It still doesn't solve my auth-int/auth-conf follow-on
requirements however!]

Steve

Graham Barr

2005-08-09, 5:08 pm

On Tue, August 9, 2005 1:08 pm, SteveC said:

>
> If that is the case, then if the SASL & DIGEST_MD5 modules provided a
> callback to enable the realm to be overridden, a user could provide one
> of the Microsoft 'standard' values (in the case of a perverse
> configuration like mine!) and things would work with the 'preferred'
> UPN. [It still doesn't solve my auth-int/auth-conf follow-on
> requirements however!]

Well there is a "backdoor" you could use to verify this would work.

If you pass a sub-reference as the user,

my $sasl = Authen::SASL->new(
mechanism => 'DIGEST-MD5',
callback => {
user => \&user,
pass => $passwd,
}
);

Then if you do not use the XS implementation, you can do

sub user {
my $obj = shift;
$obj->{server_params}{realm} = "blah";
return $user;
}

Graham.

Larry Lile

2005-08-09, 5:08 pm

On Tue, 9 Aug 2005, SteveC wrote:

> Quanah Gibson-Mount wrote:
> That is the one that I have downloaded and installed and get the 'Local
> error' with.

I'm still unable to get Net::LDAP and Authen::SASL::Cyrus to play
nice. I'm using perl-ldap 0.33 and Authen-SASL-Cyrus-0.12-server
with perl-5.8.6.

I get a slightly different result "Use of uninitialized value" but
I have elicited the "Local error" message before.

Using the test script:

#!/opt/perl-5.8.6/bin/perl -w
use Net::LDAP;
use Authen::SASL;

my $slavesasl = Authen::SASL->new(mechanism=>'GSSAPI',
'user' => " ", # empty callback, so Net::LDAP don't overrides it
);

my $ldap = Net::LDAP->new('ldap1', version=>3, async=>1, debug =>3) || die
"$@";

my $mesg = $ldap->bind("", sasl=>$slavesasl, async=>1);

$mesg->code && die $mesg->error;

$mesg =
$ldap->search(async=>1,filter=>"(uid=lile)",base=>"dc=anim,dc=dreamworks,dc=com");

@entries = $mesg->entries;

foreach $entry (@entries) {
$entry->dump;
}

[lile@familyties led]$ klist
Ticket cache: FILE:/tmp/krb5cc_1625_JxCOkw
Default principal: lile@ANIM.DREAMWORKS.COM

Valid starting Expires Service principal
08/09/05 11:39:31 08/10/05 12:39:31
krbtgt/ANIM.DREAMWORKS.COM@ANIM.DREAMWORKS.COM

[lile@familyties led]$ ./test-cyrus
Net::LDAP=HASH(0x940e974) sending:

30 82 02 26 02 01 01 60 82 02 1F 02 01 03 04 00 0..&...`........
A3 82 02 16 04 06 47 53 53 41 50 49 04 82 02 0A ......GSSAPI....
60 82 02 06 06 09 2A 86 48 86 F7 12 01 02 02 01 `.....*.H.......
00 6E 82 01 F5 30 82 01 F1 A0 03 02 01 05 A1 03 .n...0..........
02 01 0E A2 07 03 05 00 20 00 00 00 A3 82 01 31 ........ ......1
61 82 01 2D 30 82 01 29 A0 03 02 01 05 A1 15 1B a..-0..)........
13 41 4E 49 4D 2E 44 52 45 41 4D 57 4F 52 4B 53 .ANIM.DREAMWORKS
2E 43 4F 4D A2 2D 30 2B A0 03 02 01 03 A1 24 30 .COM.-0+......$0
22 1B 04 6C 64 61 70 1B 1A 6D 6F 6F 6E 65 79 2E "..ldap..mooney.
61 6E 69 6D 2E 64 72 65 61 6D 77 6F 72 6B 73 2E anim.dreamworks.
63 6F 6D A3 81 DB 30 81 D8 A0 03 02 01 01 A1 03 com...0.........
02 01 05 A2 81 CB 04 81 C8 9B 61 EF 10 C6 31 3D ..........a...1=
BB 1C 71 B1 3F DF FB 04 A2 A9 5D 3A 5F BC 62 13 ..q.?.....]:_.b.
39 E1 41 60 00 B0 C8 0C DE 47 17 9F 56 E3 F0 69 9.A`.....G..V..i
92 F3 18 59 E0 B8 1A 1A 02 61 1D 1F A4 7B 36 E5 ...Y.....a...{6.
7A 4A CB 51 4E 22 37 D2 C4 51 34 DF 2E BF EC 8D zJ.QN"7..Q4.....
9B 0A 6D 3F 2A E2 33 73 9A 73 48 77 BD 6F 11 03 ..m?*.3s.sHw.o..
EB E1 5C 83 BA 83 80 90 3C 6C C4 1B 6C 60 F9 1C ..\.....<l..l`..
53 4B 96 C6 36 0A F4 F5 AE 46 11 E1 74 71 0A 61 SK..6....F..tq.a
C6 46 7D FB 38 87 A5 0C BB FC CF 8E C4 7F 13 1B .F}.8...........
3E 97 0E 94 0B 5F 65 98 8C 2D 8B 4C 00 68 F5 D6 >...._e..-.L.h..
EF 4A A0 66 A9 DC E0 A1 C6 91 5D 3C 88 04 2E 5C .J.f......]<...\
9B 88 FC EB 12 1A F0 33 E4 1D 0A 9A DB F7 63 D3 .......3......c.
4C A5 FE B1 3C 1F AF E7 E0 C7 95 2D AE E1 FA 62 L...<......-...b
7C A4 81 A6 30 81 A3 A0 03 02 01 01 A2 81 9B 04 |...0...........
81 98 D0 AE A7 E2 BA 9F 51 E7 3A 3D FA F9 7B 39 ........Q.:=..{9
CC 3E 2F 8C 17 AF C4 E1 26 4F 9A 7C 4E 4A B5 A1 .>/.....&O.|NJ..
F6 C8 C2 69 3C A1 CF 2F 1A 5A F2 FC 86 DF 3B B0 ...i<../.Z....;.
8C 88 F5 6B 83 59 0D A4 7B 99 DB 2C C2 6F D0 0F ...k.Y..{..,.o..
05 82 C2 6C 5E 73 E6 2D 98 EF 06 AB 62 A5 4F 88 ...l^s.-....b.O.
04 66 E2 FB 8E 60 42 26 BD 6F F8 D5 DF 23 9F 0E .f...`B&.o...#..
10 87 59 F3 D6 F8 56 50 E8 CC AD 11 03 33 62 AE ..Y...VP.....3b.
05 22 E7 DE 40 55 D8 BD 4B 3E 5D FA F2 47 16 3A ."..@U..K>]..G.:
21 0F DF E1 56 D3 68 98 FD E3 F7 E4 0A 7A 43 00 !...V.h......zC.
31 E3 F7 A6 04 E2 55 1F 34 6A __ __ __ __ __ __ 1.....U.4j

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

30 78 02 01 01 61 73 0A 01 0E 04 00 04 00 87 6A 0x...as........j
60 68 06 09 2A 86 48 86 F7 12 01 02 02 02 00 6F `h..*.H........o
59 30 57 A0 03 02 01 05 A1 03 02 01 0F A2 4B 30 Y0W...........K0
49 A0 03 02 01 01 A2 42 04 40 6C C3 B4 0A 17 96 I......B.@l.....
0B 6A CD 1F 99 45 0F 99 26 0B 6E 5B 7F 4C B4 FF .j...E..&.n[.L..
76 4E 57 2E FF 49 B7 F8 DB 2E CE C5 6E 27 CE 49 vNW..I......n'.I
DF 29 43 22 39 3E B1 E2 75 5E 4D 3A FE 50 A7 D3 .)C"9>..u^M:.P..
DE A2 2B 71 2C 67 3A F7 78 A3 __ __ __ __ __ __ ..+q,g:.x.

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

30 14 02 01 02 60 0F 02 01 03 04 00 A3 08 04 06 0....`..........
47 53 53 41 50 49 __ __ __ __ __ __ __ __ __ __ GSSAPI

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

30 43 02 01 02 61 3E 0A 01 0E 04 00 04 00 87 35 0C...a>........5
60 33 06 09 2A 86 48 86 F7 12 01 02 02 02 01 00 `3..*.H.........
00 FF FF FF FF 41 C2 BD 59 E5 D2 C9 BA 22 E9 61 .....A..Y....".a
68 F4 36 B9 47 36 9D 05 F3 74 E4 FA 9C 01 00 00 h.6.G6...t......
04 04 04 04 04 __ __ __ __ __ __ __ __ __ __ __ .....

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

30 4B 02 01 03 60 46 02 01 03 04 00 A3 3F 04 06 0K...`F......?..
47 53 53 41 50 49 04 35 60 33 06 09 2A 86 48 86 GSSAPI.5`3..*.H.
F7 12 01 02 02 02 01 00 00 FF FF FF FF 57 9D A9 .............W..
89 42 C0 CE A3 72 1C FB FB CD 0D 99 35 BB 30 C6 .B...r......5.0.
25 77 AD 2E B2 01 00 FF FF 04 04 04 04 __ __ __ %w...........

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

30 0C 02 01 03 61 07 0A 01 00 04 00 04 00 __ __ 0....a........

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

30 41 02 01 04 63 3C 04 1C 64 63 3D 61 6E 69 6D 0A...c<..dc=anim
2C 64 63 3D 64 72 65 61 6D 77 6F 72 6B 73 2C 64 ,dc=dreamworks,d
63 3D 63 6F 6D 0A 01 02 0A 01 02 02 01 00 02 01 c=com...........
00 01 01 00 A3 0B 04 03 75 69 64 04 04 6C 69 6C ........uid..lil
65 30 00 __ __ __ __ __ __ __ __ __ __ __ __ __ e0.

Use of uninitialized value in print at
/opt/perl-5.8.6/lib/site_perl/5.8.6/i686-linux/Authen/SASL/Cyrus/Security.pm
line 81, <DATA> line 225.

Which sometimes exits, sometimes hangs and sometimes it manages to
get a ticket.

[lile@familyties led]$ klist
Ticket cache: FILE:/tmp/krb5cc_1625_JxCOkw
Default principal: lile@ANIM.DREAMWORKS.COM

Valid starting Expires Service principal
08/09/05 11:39:31 08/10/05 12:39:31
krbtgt/ANIM.DREAMWORKS.COM@ANIM.DREAMWORKS.COM
08/09/05 11:40:43 08/10/05 12:39:31
ldap/mooney.anim.dreamworks.com@ANIM.DREAMWORKS.COM

Any wisdom on whats wrong?

--
Larry

Quanah Gibson-Mount

2005-08-09, 5:08 pm

--On Tuesday, August 09, 2005 11:47 AM -0700 Larry Lile
<lile@anim.dreamworks.com> wrote:

> I'm still unable to get Net::LDAP and Authen::SASL::Cyrus to play
> nice. I'm using perl-ldap 0.33 and Authen-SASL-Cyrus-0.12-server
> with perl-5.8.6.
>
> I get a slightly different result "Use of uninitialized value" but
> I have elicited the "Local error" message before.
>
> Using the test script:
>
># !/opt/perl-5.8.6/bin/perl -w
> use Net::LDAP;
> use Authen::SASL;
>
> my $slavesasl = Authen::SASL->new(mechanism=>'GSSAPI',
> 'user' => " ", # empty callback, so Net::LDAP don't overrides it
> );
>
> my $ldap = Net::LDAP->new('ldap1', version=>3, async=>1, debug =>3) ||
> die "$@";
>
> my $mesg = $ldap->bind("", sasl=>$slavesasl, async=>1);
>
> $mesg->code && die $mesg->error;
>
> $mesg =
> $ldap->search(async=>1,filter=>"(uid=lile)",base=>"dc=anim,dc=dreamworks,
> dc=com");
> @entries = $mesg->entries;
>
> foreach $entry (@entries) {
> $entry->dump;
> }

Just out of curiosity, have you looked at or tried my abstracted perl
module that goes on top of Net::LDAP and Authen::SASL?

<http://www.stanford.edu/services/di...ients/perl.html>

I use it to make SASL/GSSAPI connections to our OpenLDAP servers all the
time...

--Quanah

--
Quanah Gibson-Mount
Principal Software Developer
ITSS/Shared Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

"These censorship operations against schools and libraries are stronger
than ever in the present religio-political climate. They often focus on
fantasy and sf books, which foster that deadly enemy to bigotry and blind
faith, the imagination." -- Ursula K. Le Guin

Larry Lile

2005-08-09, 5:08 pm

On Tue, 9 Aug 2005, Quanah Gibson-Mount wrote:

>
>
> --On Tuesday, August 09, 2005 11:47 AM -0700 Larry Lile
> <lile@anim.dreamworks.com> wrote:
>
>
> Just out of curiosity, have you looked at or tried my abstracted perl
> module that goes on top of Net::LDAP and Authen::SASL?
>
> <http://www.stanford.edu/services/di...ients/perl.html>
>
> I use it to make SASL/GSSAPI connections to our OpenLDAP servers all the
> time...

I don't see how it would help, you are using Net::LDAP to create
a connection to the server, I already have a TGT so we'll skip
that part, then you create an Authen::SASL::GSSAPI object the
bind the Net::LDAP connection with the SASL cred.

Not using async and not setting user=" " still give the same result
so I can't see a difference. Using Stanford::Directory is just going
to give me more layers to debug and I can't believe it's going to change
the result.

From Stanford-Directory-3.0.7/Directory.pm:

# Connect to the server
my $serverName = gethostbyaddr(inet_aton($self->ldap_server()),
AF_INET);

$ld = Net::LDAP->new($serverName,version=>$self->version());
if ($ld == -1) {
$self->error_type("System");
$self->error("Could not connect to directory server (" .
$self->ldap_server .")");
return ();
}

[...]

# Bind to the directory
my $status;
my $sasl;

if ($self->mechanism) {
$sasl = Authen::SASL->new($self->mechanism());
$status = $ld->bind("", sasl=>$sasl);
}
else {
$status = $ld->bind("");
}

if ($status->code && $status->error) {
$self->error_type("System");
$self->error("Bind failed - " . $status->error . " (STATUS: " .
$status->code . ")");
return ();
}
$self->{connection_handle}=$ld;

--
Larry

Quanah Gibson-Mount

2005-08-09, 5:08 pm

--On Tuesday, August 09, 2005 1:51 PM -0700 Larry Lile
<lile@anim.dreamworks.com> wrote:

> I don't see how it would help, you are using Net::LDAP to create
> a connection to the server, I already have a TGT so we'll skip
> that part, then you create an Authen::SASL::GSSAPI object the
> bind the Net::LDAP connection with the SASL cred.

Well, to me the difference is this is something that I know pulls together
all the pieces, and works, with examples supplied in the tar ball that
should be trivial to modify for your environment. Obviously it'll use your
TGT if you already have one (as several of the examples do).

> Not using async and not setting user=" " still give the same result
> so I can't see a difference. Using Stanford::Directory is just going
> to give me more layers to debug and I can't believe it's going to change
> the result.

The difference is, I know my code works. I don't see anything obviously
wrong with your code, but one never knows. If you get the same error with
my code, there's something more fundamentally at issue than just the code.

Regardless, I can say for sure, there is something else fundamentally wrong
with your setup, because if I modify your script for my environment, it
works perfectly:

#!/usr/local/bin/perl -w
use Net::LDAP;
use Authen::SASL;

my $slavesasl = Authen::SASL->new(mechanism=>'GSSAPI',
'user' => " ", # empty callback, so Net::LDAP don't overrides it
);

my $ldap = Net::LDAP->new('ldap6.stanford.edu', version=>3, async=>1, debug
=>3) || die
"$@";

my $mesg = $ldap->bind("", sasl=>$slavesasl, async=>1);

$mesg->code && die $mesg->error;

$mesg =
$ldap->search(async=>1,filter=>"(uid=quanah)",base=>"dc=stanford,dc=edu");

@entries = $mesg->entries;

foreach $entry (@entries) {
$entry->dump;
}

[snip lots of output, then]

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

30 0C 02 01 04 65 07 0A 01 00 04 00 04 00 __ __ 0....e........

------------------------------------------------------------------------
dn:uid=quanah,cn=Accounts,dc=Stanford,dc
=edu

cn: Quanah Gibson-Mount
gecos: Quanah Gibson-Mount
gidNumber: 37
homeDirectory: /afs/ir/users/q/u/quanah
krb5PrincipalName: quanah@stanford.edu
loginShell: /bin/tcsh
suAccountStatus: active
suAfsHomeDirectory: /afs/ir/users/q/u/quanah
suAfsStatus: active
suCreateAgent: AccountSlog
suDialinStatus: active
suEmailAccountType: personal
suEmailAdmin: quanah
suEmailStatus: active
suEntryStatus: active
suKerberosStatus: active
suLelandStatus: active
suName: Quanah Gibson-Mount
suNameLF: Gibson-Mount, Quanah
suPtsStatus: active
suPtsUid: 54046
suSeasStatus: active
suSeasSunetID: qgibsonmount
quanah
quanahgibsonmount
suSeasUriRouteTo: /~quanah
uid: quanah
uidNumber: 54046
suCreateAPI: JNDI
suKrb4Name: quanah@IR.STANFORD.EDU
description: Information Technology Systems and Services, Principal
Sys Admin, QA, Programmer, Webmaster
suDescription: Information Technology Systems and Services, Principal
Sys Admin, QA, Programmer, Webmaster
suMailDrop: quanah@quanah.pobox.stanford.edu
suService: dialin
afs
leland
email
seas
pts
kerberos
objectClass: posixAccount
suPtsService
suAccount
suOperational
suLelandService
suAfsService
suEmailService
suDialinService
suKerberosService
suSeasService
owner:
suRegID=85e49978f61311d2ae662436000baa77
,cn=People,dc=Stanford,dc=edu
seeAlso:
suRegID=85e49978f61311d2ae662436000baa77
,cn=People,dc=Stanford,dc=edu
suIdentifies:
suRegID=85e49978f61311d2ae662436000baa77
,cn=People,dc=Stanford,dc=edu
suEmailQuota: 100

--
Quanah Gibson-Mount
Principal Software Developer
ITSS/Shared Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

"These censorship operations against schools and libraries are stronger
than ever in the present religio-political climate. They often focus on
fantasy and sf books, which foster that deadly enemy to bigotry and blind
faith, the imagination." -- Ursula K. Le Guin

Larry Lile

2005-08-09, 5:08 pm

On Tue, 9 Aug 2005, Quanah Gibson-Mount wrote:

>
>
> --On Tuesday, August 09, 2005 1:51 PM -0700 Larry Lile
> <lile@anim.dreamworks.com> wrote:
>
>
> Well, to me the difference is this is something that I know pulls together
> all the pieces, and works, with examples supplied in the tar ball that
> should be trivial to modify for your environment. Obviously it'll use your
> TGT if you already have one (as several of the examples do).
>
>
> The difference is, I know my code works. I don't see anything obviously
> wrong with your code, but one never knows. If you get the same error with
> my code, there's something more fundamentally at issue than just the code.
>
>
> Regardless, I can say for sure, there is something else fundamentally wrong
> with your setup, because if I modify your script for my environment, it
> works perfectly:

Good. So we both agree Stanford::Directory or Net::LDAP +
Authen::SASL::Cyrus is irrelevant, the test script _should_ work.

Why doesn't it?

[lile@familyties SOURCES]$ ls -1 perl-5.8.6.tar.gz perl-ldap-0.33.tar.gz
Authen-SASL-*
Authen-SASL-2.09.tar.gz
Authen-SASL-Cyrus-0.12-server.tar.gz
perl-5.8.6.tar.gz
perl-ldap-0.33.tar.gz

[lile@familyties SOURCES]$ rpm -qa | grep -i sasl
cyrus-sasl-2.1.15-10
cyrus-sasl-gssapi-2.1.15-10
cyrus-sasl-md5-2.1.15-10
cyrus-sasl-plain-2.1.15-10
cyrus-sasl-devel-2.1.15-10

[lile@familyties SOURCES]$ cat /etc/redhat-release
Red Hat Enterprise Linux WS release 3 (Taroon Update 4)

--
Larry

Quanah Gibson-Mount

2005-08-10, 4:04 am

--On Tuesday, August 09, 2005 2:18 PM -0700 Larry Lile
<lile@anim.dreamworks.com> wrote:

> Authen::SASL::Cyrus is irrelevant, the test script _should_ work.

Well, I'll caveat that by saying, it *does* work for me. Which is better
than should. ;)

> Why doesn't it?
>
> [lile@familyties SOURCES]$ ls -1 perl-5.8.6.tar.gz perl-ldap-0.33.tar.gz
> Authen-SASL-*
> Authen-SASL-2.09.tar.gz
> Authen-SASL-Cyrus-0.12-server.tar.gz
> perl-5.8.6.tar.gz
> perl-ldap-0.33.tar.gz
>
> [lile@familyties SOURCES]$ rpm -qa | grep -i sasl
> cyrus-sasl-2.1.15-10
> cyrus-sasl-gssapi-2.1.15-10
> cyrus-sasl-md5-2.1.15-10
> cyrus-sasl-plain-2.1.15-10
> cyrus-sasl-devel-2.1.15-10

Your version of cyrus-sasl may be an issue. I vaguely recall that I had to
have something like 2.1.17 or later for everything to work correctly.

I'm currently set up on debian as:

hostreg:~/work/directory> dpkg -l
ii libauthen-sasl 0.12-server-1 Perl extension for Cyrus SASL library
ii libauthen-sasl 2.08-2 Authen::SASL - SASL Authentication
framework
ii libsasl2 2.1.19-1.5 Authentication abstraction library
ii libsasl2-gssap 2.1.19-1.1 GSSAPI module for SASL using MIT Kerberos
ii libnet-ldap-pe 0.3202-3 A Client interface to LDAP servers
ii perl 5.8.4-8 Larry Wall's Practical Extraction and
Report

--Quanah

--
Quanah Gibson-Mount
Principal Software Developer
ITSS/Shared Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

"These censorship operations against schools and libraries are stronger
than ever in the present religio-political climate. They often focus on
fantasy and sf books, which foster that deadly enemy to bigotry and blind
faith, the imagination." -- Ursula K. Le Guin

Chris Ridd

2005-08-10, 4:04 am

On 9/8/05 10:18, Larry Lile <lile@anim.dreamworks.com> wrote:

> [lile@familyties SOURCES]$ cat /etc/redhat-release
> Red Hat Enterprise Linux WS release 3 (Taroon Update 4)

IIRC RedHat Enterprise Linux 3 ships with OpenLDAP tools that cannot perform
correct DIGEST-MD5 auth. I can't remember if the fix is to upgrade the
openldap tools, or sasl, or both :-( I'm pretty sure no RedHat update fixed
it.

Cheers,

Chris

SteveC

2005-08-10, 9:08 am

Graham Barr wrote:
> On Tue, August 9, 2005 1:08 pm, SteveC said:
>
>
>
>
> Well there is a "backdoor" you could use to verify this would work.
>
> If you pass a sub-reference as the user,
>
> my $sasl = Authen::SASL->new(
> mechanism => 'DIGEST-MD5',
> callback => {
> user => \&user,
> pass => $passwd,
> }
> );
>
> Then if you do not use the XS implementation, you can do
>
> sub user {
> my $obj = shift;
> $obj->{server_params}{realm} = "blah";
> return $user;
> }
>
> Graham.
>
>
Graham,

I tried you suggestion and via this route I can authenticate using all
the forms of pre-computed digest that AD on W2k3 supports.

If you are interested, here is a patch for changing DIGEST_MD5 to allow
for a 'realm' callback.This also includes the correction to the 'serv'
handling for digest-uri.

Steve

Peter Marschall

2005-08-10, 9:08 am

Hi Steve,

On Tuesday 09 August 2005 20:08, SteveC wrote:
> I think that I might have spotted what's causing my problem:
>
> This Microsoft technet article
>
> http://www.microsoft.com/technet/pr...03/library/Tech
>Ref/717b450c-f4a0-4cc9-86f4-cc0633aae5f9.mspx
>
> explains how Microsoft pre-computes and saves certain MD5 hashes based
> on combinations of account names (UPN and SamAccountName, DNS names,
> fixed strings, and paswords -- in various combinations) [See Digest
> Hashes section in the body]. These pre-computed hashes mean that AD
> doesn't need to hold passwords in a reversible encryption format.[This
> is a new feature in W2k3 -- W2k needs the reversible encryption
> apparently if digest authentication is going to be used.]
>
> In my environment, I have (don't ask my to justify why all the following
> non-standard settings!):
> - My UPN is name_1@BASE (where BASE is some string, i.e. not a real fqdn)
> - my SamAccountName is name_2
> - the forest root domain is ROOT.BASE
> - the AD domain I belong to is XXXX.ROOT.BASE
> - the flat domain name is XXXX
>
> So, given all the above, when the 'A1' hash is calculated the 'realm'
> used by DIGEST_MD5 is the one supplied by the domain controller which is
> XXXX.ROOT.BASE. If this is the case, then the only entry from the table
> in the above technet article that can ever work is if I provide the
> SamAccountname -- then row 2 of the table (SamAccountName +
> DNSDomainaname + password) will match a pre-computed hash.
>
> Does that make sense?

I don't know if it makes sense, but it seems to match the results of my
tests ;-)
As long als the server provided realm is used the samAccountname is to be used
as the value of the user callback.

> If that is the case, then if the SASL & DIGEST_MD5 modules provided a
> callback to enable the realm to be overridden, a user could provide one
> of the Microsoft 'standard' values (in the case of a perverse
> configuration like mine!) and things would work with the 'preferred'
> UPN. [It still doesn't solve my auth-int/auth-conf follow-on
> requirements however!]

I have extended the patch to Authen::SASL 2.09. It now
- corrects the un-escaping behaviour when reading the challenge
- checks for required fields (according to the RFC)
- allows for qop not to be sent froj the server (according to the RFC)
- corrects the digest-uri bug
- adds a callback for the realm

Graham,
please add this patch to the Authen-SASL SVN
(alternatively you may give my pmarschall account write access to the
Authen-SASL SVN in addition to the perl-ldap SVN so that I can do it
myself)

Peter

--
Peter Marschall
eMail: peter@adpm.de

Graham Barr

2005-08-10, 5:10 pm

On Wed, August 10, 2005 5:32 am, Peter Marschall said:
> Graham,
> please add this patch to the Authen-SASL SVN
> (alternatively you may give my pmarschall account write access to the
> Authen-SASL SVN in addition to the perl-ldap SVN so that I can do it
> myself)

Peter,

You should already have write access, did you try it?

You will see I have already made the s/digest_uri/digest-uri/
change.

I looked at you patch and saw you realm addition. And I agree
there is more todo here. I will try to put together my thoughts
on it tonight. But feel free to check in what you have.

Graham.

Sponsored Links