Bug 506490 - Password change crashes FDS with "Failed to generate LM/NT hashes"
Summary: Password change crashes FDS with "Failed to generate LM/NT hashes"
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: freeIPA
Classification: Retired
Component: ipa-server
Version: 1.2
Hardware: All
OS: Linux
low
medium
Target Milestone: v2 release
Assignee: Rob Crittenden
QA Contact: Chandrasekar Kannan
URL:
Whiteboard:
Depends On:
Blocks: 431020
TreeView+ depends on / blocked
 
Reported: 2009-06-17 14:19 UTC by Loris Santamaria
Modified: 2015-01-04 23:39 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-09-16 13:39:16 UTC
Embargoed:


Attachments (Terms of Use)

Description Loris Santamaria 2009-06-17 14:19:09 UTC
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 14:29:08 UTC
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 20:24:22 UTC
Is this still a problem for you?

Comment 4 Loris Santamaria 2010-02-17 13:00:55 UTC
Sorry I haven't access to that particular setup anymore.

Comment 5 Rob Crittenden 2010-09-16 13:39:16 UTC
We have been unable to reproduce this.


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