sipe NTLM implementation doesn't cope with certain passwords?

Help
2013-04-02
2013-04-10
  • This was a serious pain to debug and is probably one of the most bizarre bugs that I've encountered so far.
    The server connection failed upon the attempt to send NTLM authentication details with:

    ms-diagnostics: 1000;reason="Final handshake failed";source="OCS2007R2FE2.example.org";HRESULT="0xC3E93EC3(SIP_E_AUTH_UNAUTHORIZED)"

    I changed my password once by one char, as I suspected a 0 at the end could be the problem. Problem persisted. We had started debugging on the server side, when I changed the password again to a completely different password. It magically started working again.

    Is anything like that known already?

    The password in question was >=30 char long with lower/upper-case characters and numbers. But I've had other longer passwords that didn't pose any problems, my current password is actually longer and it works.

    The version currently installed is 1.11.2-1ubuntu1. I could try against 1.15.0 (I actually did, but seems that debug log is worthless as 1.15.0 fails to connect to our OCS if SSO is enabled and it never got to the NTLM part when I tried and logged back then)

     
    Last edit: Stefan Becker 2013-04-10
  • Stefan Becker
    Stefan Becker
    2013-04-10

    Is anything like that known already?

    NTLMv2 passwords have to be converted to UTF-16LE before they enter the hash calculation. IMHO the only way this can fail is that

    • your password contains non-ASCII characters, and
    • SIPE (on UNIX) and "NTLM password hash generator" (on Windows) use a different character set conversion. I.e. they arrive at a different UTF-16LE representation of the same input string.

    as 1.15.0 fails to connect to our OCS if SSO is enabled

    SIPE's internal NTLMv2 implementation never supported SSO. If you still have SSO enabled in your account settings after upgrading to 1.15.0 then I can only assume that you didn't read the update notice, the FAQ, ...