'nonce'}}),
charset => $sparams{'charset'},
== simple program
use Net::LDAP;
use Authen::SASL qw/Perl/;
my $host= 'users.mycompany.it';# one of our AD domain controllers
my $user= 'my_Userid'
So this is doable with existing modules? If so, i've just tried your
suggestion, and got the following:
Can't locate object method "callback" via package "ldap" (perhaps you
forgot to load "ldap"?)
If that's not what you meant, then should I wait for a future rev of SASL?
Graham Barr wrote:
I'm not sure if I understand, but I see where continuing to rely on
Net::LDAP to get it right might be a problem. I'd like to see a change
to Authen::SASL::Perl where I can override whatever value the host is
populated with. For my uses, something like a callback where I can stick
in a referen
On Mar 2, 2009, at 1:53 PM, Ismael wrote:
I'm not sure if I understand, but I see where continuing to rely on
Net::LDAP to get it right might be a problem. I'd like to see a
change to Authen::SASL::Perl where I can override whatever value the
host is populated with. For my uses, something
On Mar 1, 2009, at 7:58 AM, Ismael Lezcano wrote:
I just looked and I think that I was beaten to the punch. What I'm
complaining about is documented in bug 35263 on CPAN. This behavior
was introduced in the sasl round robin patch as part of 0.37. I
think it has something to do with how new_
I just looked and I think that I was beaten to the punch. What I'm
complaining about is documented in bug 35263 on CPAN. This behavior was
introduced in the sasl round robin patch as part of 0.37. I think it has
something to do with how new_client in the SASL modules is called. So if
the patch
er the bind attempt. Here's a snippet. The @ldaploginservers is an
> > array of LDAP URLs:
>
> > my $sasl = Authen::SASL->new(mechanism => 'DIGEST-MD5',
> > callback => {
> > user
ASL object I created via Dumper in a line
after the bind attempt. Here's a snippet. The @ldaploginservers is an
array of LDAP URLs:
my $sasl = Authen::SASL->new(mechanism => 'DIGEST-MD5',
callback => {
Dumper in a line
after the bind attempt. Here's a snippet. The @ldaploginservers is an
array of LDAP URLs:
my $sasl = Authen::SASL->new(mechanism => 'DIGEST-MD5',
callback => {
user => $aduser,
ease also create a testcase which fails and shows the problem on the
> version you have so we can verify that new code has fixed it.
Attached, derived from existing DIGEST-MD5; my test user doesn't have
authorization rights and it'd be too much hassle to set up such a
privileged acco
have worked against a real server. :^(
> Ack, another module caught by a change in Module::Install. I have
> checked in a fix
Okay, builds now, and I can see that revision 89 fixed DIGEST-MD5 in
February too.
Any chance of a release soon please?
Thanks,
-Phil
pgpvuw5D7t3YM.pgp
Description: PGP signature
checked in a fix
Please also create a testcase which fails and shows the problem on
the
version you have so we can verify that new code has fixed it.
Attached, derived from existing DIGEST-MD5; my test user doesn't have
authorization rights and it'd be too much hassle to set up such
On Mar 24, 2008, at 1:02 AM, Phil Pennock wrote:
Folks,
The Perl native DIGEST-MD5 implementation for Authen::SASL doesn't
actually implement the second stage verification. Instead, an attempt
to actually verify the server's second stage data results in:
Server did not provid
Folks,
The Perl native DIGEST-MD5 implementation for Authen::SASL doesn't
actually implement the second stage verification. Instead, an attempt
to actually verify the server's second stage data results in:
Server did not provide required field(s): algorithm nonce
That's a
On Monday 04 September 2006 00:52, Graham Barr wrote:
> Hm, I forget the exact details but I seem to remember they were both
> set because some servers were using user while others where using
> authzid. I guess we will find out later which servers needed authzid :-)
That means 2 kinds of broken
On Sep 3, 2006, at 4:48 PM, Achim Grolms wrote:
I was wrong, not Authen::SASL::Perl::DIGEST_MD5 is the problem,
Net::POP3 caused the problem.
The code in Net::POP3 is this
$sasl = Authen::SASL->new(mechanism=> $mechanisms,
callback => { user => $username,
On Sunday 03 September 2006 15:23, Achim Grolms wrote:
> On Friday 01 September 2006 16:47, Jürgen Herz wrote:
> > And client response (here decoded)
> > authzid="juergen",charset=utf-8,cnonce="7c1c927e756c9067dbf412c964a823c1"
> >, digest-uri="pop/pico",nc=0001,nonce="S5hbmt7qeaQYOS/OLKOsYg=="
On Friday 01 September 2006 16:47, Jürgen Herz wrote:
> And client response (here decoded)
> authzid="juergen",charset=utf-8,cnonce="7c1c927e756c9067dbf412c964a823c1",
> digest-uri="pop/pico",nc=0001,nonce="S5hbmt7qeaQYOS/OLKOsYg==",
> qop=auth,realm="",response=fed55b47609e097fdf7d145635e845f
xporter(5.58)
Net::POP3>>> IO::Socket::INET(1.29)
Net::POP3>>> IO::Socket(1.29)
Net::POP3>>> IO::Handle(1.25)
Net::POP3=GLOB(0x1019fff0)<<< +OK Dovecot ready.
Net::POP3=GLOB(0x1019fff0
hanges
> that made 2.28_2 are not the problem.).
As i can see from Authen::SASL:Perl::DIGEST_MD5
code the servicename is part of authentication, too:
'digest-uri' => $self->service . '/' . $self->host,
Can you please check if the change of servicename ('po
On Friday 01 September 2006 16:47, Jürgen Herz wrote:
> So, what to do to find out what's wrong?
Does the problem happen with Net::POP3 2.28
or with Net::POP3 2.28_2 ?
(I want to ensure that the changes
that made 2.28_2 are not the problem.).
You can use ->debug(1) method of a Net::POP3 objec
Hi,
I was testing Authen-SASL's DIGEST-MD5 mechanism in a script (Net::POP3)
but it failed. Server was Dovecot 0.99.14.
In order to find out which side is guilty, I used the SASL module in a
Net::SMTP script and tried with Postfix server: login succeeded with
DIGEST-MD5.
Though I was pretty
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 w
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/prodtechnol/windowsserver2003/library/Tech
>Ref/717b450c-f4a0-4cc9-86f4-cc0633aae5f9.mspx
>
> explains ho
uthen::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->{s
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 re
--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 sh
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
--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 c
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
--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 val
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 becua
ration 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 $sa
his 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
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 rem
--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
ccountName). 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 a
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
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
erl::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 o
SL::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 cr
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 wit
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
undersc
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 diges
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 am using are certainly co
The DIGEST-MD5 mechanism in Authen-SASL 2.06 seems slightly broken, using
either perl 5.8.0 or perl 5.8.1.
I am told by our SASL guru that DIGEST-MD5 is a multi-step procedure, and it
looks like the client_step code in DIGEST_MD5.pm isn't aware of this and
tries to use stuff in step 2 that
tweaking.
Regards,
Paul.
-Original Message-
From: Paul Connolly [mailto:[EMAIL PROTECTED]
Sent: 08 September 2003 07:10
To: 'Johnson, Brian K'; [EMAIL PROTECTED]
Subject: RE: DIGEST-MD5 and Windows 2003 Active Directory
I haven't done any testing of Authen::SASL::PERL::DIGEST_MD5 again
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 => $pass
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 w
49 matches
Mail list logo
