improving kadmind change-password performance

Danny Thomas d.thomas at
Sun Nov 11 16:40:15 EST 2012

One of our systems is used by a large number of new users to set their
password. I've resolved issues with the front-end and performance is
now constrained by kadmind, something I've never been involved with.

kadmind hits 100% CPU when load-testing with <100 simulated clients.
We want to cater for at least 500 concurrent users and see the average
time scale linearly to around 30secs with this number of clients.

Is this the sort of performance we'd expect (currently 2006 Xeon) ?

I tend to think the CPU comes from crypto operations and there'd be a
big benefit from spreading the load across cores.

The Makefile uses pthread but htop shows it using only 1 CPU.

I saw a commit "Use blocking locks in krb5kdc and libkadm5srv"
mentioned on the mailing list. Would that help ?

Finally, kadmind is only accessible from a few of our servers so is
there any opportunity to use faster but weaker crypto methods for a
service not exposed to end-users ?

RedHat EL5, kerberos client and server both on locally built 1.10.3

FWIW we're using the Authen::Krb5::Admin perl module to do this
  sub  kadmin_cpw ($$)
      my ($uid, $password) = @_;
      # error-checking removed
      # my $kadm5 = Authen::Krb5::Admin->init_with_skey('...', '/etc/keytab');
      my $kadm5 = Authen::Krb5::Admin->init_with_password('...', '...');
      my $krb5_principal = Authen::Krb5::parse_name($uid);
      my $success = $kadm5->chpass_principal($krb5_principal, $password);

Danny Thomas

More information about the Kerberos mailing list