perl-ldap-dev

Re: SSL is slow

[<la...@sp...>]

Hi Gary,

>> Is there any way to speedup this initial login?
>
>Encryption is a CPU intensive process. Check your CPU
>utilization to see if your server processor is a=20
>bottleneck. If so, an obvious solution would be to=20
>upgrade the processor. On another platform, a hardware=20
>crypto board may be a solution but I=27m not sure if one=20
>is available for Novell.

Don=27t think so. However, utilization isn=27t the problem: LDAP is _very_
fast when using Novells own utilities (still using SSL), and the openssl
utilities are quite fast as well - that=27s why I=27m pretty sure it Perl
LDAP that=27s the problem.

I=27m playing around with it presently - trying to figure out how to
import/add/use the trusted CA certificate for the NDS/eDir system in
question as a first measure.

Regards,
Lars

Lars Skj=E6rlund, NeReceived: from Skjaerlund-MTA by porter.spinn.dk
twork Consultant, Spinn International ApS
Bukkeballevej 30, 2960 Rungsted Kyst, Denmark
Tel.: +45 70 25 88 10, Fax: +45 70 25 88 44
Mail: lars=40spinn.dk Web: http://www.spinn.dk
--

Re: SSL is slow

[<la...@sp...>]

Hi Chris,

>> Whilst this is not a problem, it=27s rather slow. After login,
everything
>> runs pretty fast, but it does take quite a while to login.

>About the first thing that happens on a TLS connection is a crypto
>=22handshake=22, and it sounds like this is what is being slow for you.
>
>Common reasons for that are that the client wants a different
strength
>symmetric key than the server has, so the server has to generate a new
one
>for you. (Something like that anyway, my memory is pretty hazy.) So
check
>what key lengths and algorithms you=27re asking for, and what the
server
>supports.
>
>You can run the openssl s_client program in verbose/debug mode to find
out
>what the server=27s advertising, which might help.

Tried that - but the only extra output I get from the =27-debug=27 option
is a hex dump thatReceived: from Skjaerlund-MTA by porter.spinn.dk
 I unfortunately don=27t know how to interpret ;-).

However, I=27ve come as far as this:

Running =27openssl s_client=27 against the LDAP server produces output
rather quickly - and has done it al the time. Just running the s_client
produces an error, though, that the server certificate isn=27t trusted. I
eventually figured out how to handle this, and I can now connect to the
server with a trusted CA and no errors.

I thought that maybe the error might delay Perl::LDAP - but no: My
newly generated CA certificate does work with Perl - I can require
verification and still connect - but the long delay hasn=27t gone.

So: How do one decipher the hex dump and find out about the key sizes?
I=27ve tried a lot of other s_client options, but none seems to disclose
this information.

Regards,
Lars

Lars Skj=E6rlund, Network Consultant, Spinn International ApS
Bukkeballevej 30, 2960 Rungsted Kyst, Denmark
Tel.: +45 70 25 88 10, Fax: +45 70 25 88 44
Mail: lars=40spinn.dk Web: http://www.spinn.dk
--

Re: SSL is slow

[Chris R. <chr...@me...>]

Lars Skj=E6rlund <la...@sp...> wrote:
> So: How do one decipher the hex dump and find out about the key sizes?
> I've tried a lot of other s_client options, but none seems to disclose
> this information.

I can't figure out the s_client (or s_server) options either, sorry. I
wonder how I got that info before?

Cheers,

Chris

Re: SSL is slow

[<la...@sp...>]

Hi Chris,

>> So: How do one decipher the hex dump and find out about the key
sizes?
>> I=27ve tried a lot of other s_client options, but none seems to
disclose
>> this information.
>
>I can=27t figure out the s_client (or s_server) options either, sorry.
I
>wonder how I got that info before?

I=27ve continued working on the project - and SSL is still slow.

Until I ported my app to Apache and mod_perl. It now screams (well,
almost) - so apparently the caching of the module loading did the
trick.

Said in other words: The SSL LDAP module is a very slow loader ;-).

Regards,
Lars

Lars Skj=E6rlund, Network Consultant, Spinn International ApS
Bukkeballevej 30, 2960 Rungsted Kyst, Denmark
Tel.: +45 70 25 88 10, Fax: +45 70 25 88 44
Mail: lars=40spinn.dk Web: http://www.spinn.dk
--

Re: SSL is slow

[Chris R. <chr...@me...>]

Lars Skj=E6rlund <la...@sp...> wrote:
> Hi Gary,
>=20
>>> Is there any way to speedup this initial login?
>>=20
>> Encryption is a CPU intensive process. Check your CPU
>> utilization to see if your server processor is a=20
>> bottleneck. If so, an obvious solution would be to=20
>> upgrade the processor. On another platform, a hardware=20
>> crypto board may be a solution but I'm not sure if one=20
>> is available for Novell.
>=20
> Don't think so. However, utilization isn't the problem: LDAP is _very_

I agree with Lars, since each end is using symmetric encryption to encrypt
the traffic, and since symmetric algorithms are supposed to be extremely
fast and use little CPU.

I looked at a crypto accelerator card recently (Rainbow, or whatever
they're called now :-) and it mostly just speeds up the SSL handshake which
uses RSA. It certainly makes HTTPS *very* quick, but of course it costs
quite a lot of money too.

Cheers,

Chris

Changing passwords in Active Directory

[Jim H. <ha...@us...>]

Does anyone have a code snippet of changing passwords in Active Directory
via Net::LDAP?  From what I can gather, you need 1) to have 128 bit SSL
connection 2) have either old and new password or be bound with Reset
Password rights and 3) put things out correctly for changing the
unicodePwd attribute.  I am unsure as to how to use an old password (is it
part of a modify or do we need to bind with it?) and how to format the new
password correctly for unicodePwd.
  --Jim Harle

Re: Changing passwords in Active Directory

[Christopher A B. <ca...@tc...>]

As Jim Harle once put it so eloquently:

> Does anyone have a code snippet of changing passwords in Active Directory
> via Net::LDAP?  From what I can gather, you need 1) to have 128 bit SSL
> connection 2) have either old and new password or be bound with Reset
> Password rights and 3) put things out correctly for changing the
> unicodePwd attribute.  I am unsure as to how to use an old password (is it
> part of a modify or do we need to bind with it?) and how to format the new
> password correctly for unicodePwd.

This is how you can do it if you are bound via LDAPS with sufficient
(administratorish?) rights.  I've never tried to do this as a user
changing their own password (our AD is slaved to our X.500 directory,
so all changes come from X.500 via the script from which this was
taken).  But this shows you how you can format unicodePwd so that AD
will take the change.

&change_changes is there because when you do a "replace" on an
attribute of an Entry object, it adds a "replace" action to the entry
rather than modifying an existing "replace" command, which would
result in AD trying to modify unicodePwd twice; once with the original 
(plaintext) value, and once with the "fixed" version.  The first
modify would cause an error that would cause the whole operation to be 
rejected.  So we have to dig a little in the actual Entry structure.
If you're not reusing an existing Entry object (i.e. you're building
one from scratch) or you're directly updating the entry, the
change_changes bit isn't necessary.

  # done; now, if there's still a unicodePwd, then UTF-16(?) it
  # and base64 encode it and make sure it gets sent that way.
  my $opw = $entry->get_value('unicodePwd');
  if (defined $opw) {
    my $upw = pack "v*", unpack "C*", qq("$opw");
    &change_changes($entry, 'replace', 'unicodePwd', $upw);
  }

sub change_changes {
  my ($entry, $op, $attr, @values) = @_;
  
  # add/delete entry operations don't have this problem
  # so just use the regular method to update them
  unless ($entry->changetype eq 'modify') {
    $entry->$op($attr, \@values);
    return;
  }

  # ok, this is a modify, do it the hard way
  $attr = lc $attr;
  my $changes = $entry->{changes};
  for (my $i = 0; $i < @$changes; $i += 2) {
    my ($oldop, $oldargs)   = @{$changes}[$i, $i+1];
    my ($oldattr, $oldvals) = @$oldargs;
    if ($oldattr eq $attr) {
      $changes->[$i] = $op;
      $oldargs->[1] = \@values;
      last;
    }
  }
}

%%  Christopher A. Bongaarts  %%  ca...@tc...       %%
%%  Internet Services         %%  http://umn.edu/~cab  %%
%%  University of Minnesota   %%  +1 (612) 625-1809    %%

Re: Changing passwords in Active Directory

[Norbert K. <nor...@da...>]

--On Mittwoch, 24. April 2002 10:28 -0400 Jim Harle <ha...@us...> wrote:

> Does anyone have a code snippet of changing passwords in Active Directory
> via Net::LDAP?  From what I can gather, you need 1) to have 128 bit SSL
> connection

Yes

> 2) have either old and new password or be bound with Reset
> Password rights


Yes

> 3) put things out correctly for changing the
> unicodePwd attribute. I am unsure as to how to use an old password (is it
> part of a modify or do we need to bind with it?)

IIRC if you don't have reset password rights on the account, you do (in=20
LDIF notation):

changetype: modify
delete: unicodePwd
unicodePwd: MakeUnicodePwd(OldPassword)
-
add: unicodePwd
unicodePwd: MakeUnicodePwd(NewPassword)

otherwise you do a simple_bind as someone who das reset password rights=20
(self) and do a replace.

> and how to format the new
> password correctly for unicodePwd.

use Unicode::String qw(latin1 utf16);
sub MakeUnicodePwd
{
    my $u =3D latin1("\"".$_[0]."\"");
    $u->byteswap();
    return $u->ucs2;
}


--=20
Norbert Klasen, Dipl.-Inform.
DAASI International GmbH                 phone: +49 7071 29 70336
Wilhelmstr. 106                          fax:   +49 7071 29 5114
72074 T=FCbingen                           email: nor...@da...
Germany                                  web:   http://www.daasi.de