Bug 506490 - Password change crashes FDS with "Failed to generate LM/NT hashes"
Password change crashes FDS with "Failed to generate LM/NT hashes"
Status: CLOSED WORKSFORME
Product: freeIPA
Classification: Community
Component: ipa-server (Show other bugs)
1.2
All Linux
low Severity medium
: v2 release
: ---
Assigned To: Rob Crittenden
Chandrasekar Kannan
:
Depends On:
Blocks: 431020
  Show dependency treegraph
 
Reported: 2009-06-17 10:19 EDT by Loris Santamaria
Modified: 2015-01-04 18:39 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-09-16 09:39:16 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Loris Santamaria 2009-06-17 10:19:09 EDT
Description of problem:

This server has a winsync agreement with an Active Directory Domain. After upgrading FDS to 1.2 we got this frequent crashes where the last message recorded in the FDS error log is "Failed to generate LM/NT hashes". Downgrading to FDS 1.1.3 doesn't trigger the crash (but that version of FDS has stability problems of its own).

Version-Release number of selected component (if applicable):

freeIPA 1.2.1
Fedora Directory Server 1.2

How reproducible:

Some password changes triggers the bug, some others no. I haven't been able to find the exact ldap modify operation that triggers the bug.

However, I've been able to find the actual part of the code which contains the bug:

in function encode_ntlm_keys in ipa_pwd_extop.c this is the problem part:

      inc = newPasswd;
      outc = ucs2Passwd;
      cs = iconv(cd, &inc, &il, &outc, &ol);
      if (cs == -1) {
            ret = -1;
            free(ucs2Passwd);
            iconv_close(cd);
            goto done;
      }
Comment 1 Rob Crittenden 2009-06-17 10:29:08 EDT
It would be really handy to get a back trace of the server crash.

I think this will do the trick:

# debuginfo-install fedora-ds-base
# gdb -p <pid of ns-slapd>
[snip bunch of gdb output]
(gdb) c

Now gdb should be watching the running ns-slapd process. You might want to try a simple ldap search to be sure the server is still accepting connections (ldapsearch -x -b "dc=example,dc=com" uid=admin)

Now try a password change. The server should crash and you should be left at a (gdb) prompt.

(gdb) where

Include the output in the bug report.
Comment 2 Rob Crittenden 2010-02-15 15:24:22 EST
Is this still a problem for you?
Comment 4 Loris Santamaria 2010-02-17 08:00:55 EST
Sorry I haven't access to that particular setup anymore.
Comment 5 Rob Crittenden 2010-09-16 09:39:16 EDT
We have been unable to reproduce this.

Note You need to log in before you can comment on or make changes to this bug.