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

[Steve Clark]

Hi Peter,

"Peter Marschall" <[EMAIL PROTECTED]> wrote in message
news:<[EMAIL PROTECTED]>...
> 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.
...
> > 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: [EMAIL PROTECTED]

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

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

[SteveC]

Steve Clark wrote:

Hi Peter,

"Peter Marschall" <[EMAIL PROTECTED]> wrote in message
news:<[EMAIL PROTECTED]>...


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.



...


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: [EMAIL PROTECTED]



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 ([EMAIL PROTECTED]), 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

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

[Graham Barr]

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.

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

[Simon Wilkinson]

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/~pboettch/home/index.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.

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

[Chris Ridd]

On 9/8/05 2:57, SteveC <[EMAIL PROTECTED]> 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 ([EMAIL PROTECTED]), 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

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

[Quanah Gibson-Mount]

--On Tuesday, August 09, 2005 4:54 PM +0100 Simon Wilkinson 
<[EMAIL PROTECTED]> wrote:



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/~pboettch/home/index.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.





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

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

[SteveC]

Quanah Gibson-Mount wrote:



--On Tuesday, August 09, 2005 4:54 PM +0100 Simon Wilkinson 
<[EMAIL PROTECTED]> wrote:



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/~pboettch/home/index.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.





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

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

[SteveC]

Chris Ridd wrote:

On 9/8/05 2:57, SteveC <[EMAIL PROTECTED]> 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 ([EMAIL PROTECTED]), 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



I think that I might have spotted what's causing my problem:

This Microsoft technet article

http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/TechRef/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 [EMAIL PROTECTED]  (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 .ROOT.BASE
- the flat domain name is 

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 
.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

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

[Graham Barr]

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.

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

[Larry Lile]

On Tue, 9 Aug 2005, SteveC wrote:

> Quanah Gibson-Mount wrote:
> > 
> > 
> > --On Tuesday, August 09, 2005 4:54 PM +0100 Simon Wilkinson 
> > <[EMAIL PROTECTED]> wrote:
> > 
> >> 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/~pboettch/home/index.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.
> > 
> > 
> > 
> > 
> > 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.

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;
}


[EMAIL PROTECTED] led]$ klist
Ticket cache: FILE:/tmp/krb5cc_1625_JxCOkw
Default principal: [EMAIL PROTECTED]
 
Valid starting ExpiresService principal
08/09/05 11:39:31  08/10/05 12:39:31  
krbtgt/[EMAIL PROTECTED]
 
[EMAIL PROTECTED] 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 ..\._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 ."[EMAIL PROTECTED]>]..G.:
21 0F DF E1 56 D3 68 98 FD E3 F7 E4 0A 7A 43 00 !...V.h..zC.
31 E3 F7 A6

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

[Quanah Gibson-Mount]

--On Tuesday, August 09, 2005 11:47 AM -0700 Larry Lile 
<[EMAIL PROTECTED]> 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?




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

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

[Larry Lile]

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

> 
> 
> --On Tuesday, August 09, 2005 11:47 AM -0700 Larry Lile 
> <[EMAIL PROTECTED]> 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?
> 
> 
> 
> 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

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

[Quanah Gibson-Mount]

--On Tuesday, August 09, 2005 1:51 PM -0700 Larry Lile 
<[EMAIL PROTECTED]> 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 __ __ 0e


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: [EMAIL PROTECTED]
   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: [EMAIL PROTECTED]
  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: [EMAIL PROTECTED]
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

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

[Larry Lile]

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

> 
> 
> --On Tuesday, August 09, 2005 1:51 PM -0700 Larry Lile 
> <[EMAIL PROTECTED]> 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:

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

Why doesn't it?

[EMAIL PROTECTED] 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

[EMAIL PROTECTED] 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

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

-- 
Larry

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

[Quanah Gibson-Mount]

--On Tuesday, August 09, 2005 2:18 PM -0700 Larry Lile 
<[EMAIL PROTECTED]> wrote:



Good.  So we both agree Stanford::Directory or Net::LDAP +

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?

[EMAIL PROTECTED] 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

[EMAIL PROTECTED] 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-8Larry 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

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

[Chris Ridd]

On 9/8/05 10:18, Larry Lile <[EMAIL PROTECTED]> wrote:

> [EMAIL PROTECTED] 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