#65 Fall back from Kerberos to NTLM


In the Windows environment, Kerberos often breaks. Usually due to reverse DNS of a given host not matching the name of the principal it expects to see in a Kerberos ticket.

In this situation, Windows will silently fall back to using NTLM authentication (much like Firefox etc. will on Linux). So people rarely even notice when Kerberos is broken, and thus it doesn't get fixed.

For pidgin-sipe to be optimally useful in this kind of environment (and let's face it, where else would you be trying to use Lync?) we are going to need it to automatically fall back from Kerberos to NTLM authentication as required, rather than preconfiguring it to use one or the other.


  • Stefan Becker

    Stefan Becker - 2013-07-04

    Ticket moved from /p/sipe/bugs/208/

    Can't be converted:

    • _milestone: 1.16.x
  • Stefan Becker

    Stefan Becker - 2013-07-04
    • Category: Pidgin --> Protocol/Other
  • Stefan Becker

    Stefan Becker - 2013-07-04

    You don't seem to understand the difference between "bug" and "missing feature".

    Please provide your idea how an automatic fallback from Single Sign-On Kerberos to non-Single Sign-On NTLM is supposed to work. Please remember that if the user selects "Single Sign-On", then login name & password are ignored.

    IMHO this would only work if Single Sign-On NTLM (see feature request #64) can be implemented, which I currently highly doubt.

    The other thing that would be required would be dynamic authentication scheme selection for the SIP connection. Currently this is hard-coded to use the authentication scheme selected by the user.

  • David Woodhouse

    David Woodhouse - 2013-07-10

    Apologies; I'm not particularly used to bug trackers which distinguish between bugs and features in this way. Not to mention the fact that one person's "I cannot make this work without violating my company's security policy by storing passwords in the app config" bug is another person's "feature request" :)

    As for my idea on how it works... well, to be honest I've never quite understood the 'Single Sign-on' option at all. So it's hard to describe how I think things would integrate with that.

    But to be clear, I'd expect authentication to work like it does in the browser and other places:
    1. Try Kerberos. If that works, yay!
    2. Try NTLM automatically (there is work on a GSSAPI method for this, if ntlm_auth isn't good enough — although ntlm_auth supports a bunch of different "helper protocols" already and could perhaps be extended.)
    3. If all else fails, ask user for a password.

    The 'SSO' option in pidgin-sipe has always confused me, as I said. It seems meaningless to have authentication=krb5 and not SSO, or to have authentication=ntlm and to set the SSO option. My wild guess is that it's done that way to work around a bug in the generic pidgin code, which has weirdness about assuming that a password shall exist, or not, keyed on a 'SSO' option? And doesn't have support for falling back from SSO to non-SSO and requesting a password only when it's needed?

  • Stefan Becker

    Stefan Becker - 2013-07-10

    The old SSO implementation was confusing, but this has changed in 1.15.0: if you select SSO, then login and password will be ignored, no matter if you enter them or not. If an authentication scheme requires login and password, like NTLMv2 on non-Windows, then it will simply fail with SSO selected.

    Not everybody is using a full Kerberos setup, so krb5 and SSO off has its use cases. I use it myself with my company account.

    And you are completely ignoring Office 365 users, which today includes (almost) all new SIPE users.

    Anyway this requires quite a bit of restructure and implementation. First estimate:

    • backend: remove authentication scheme account setting
    • backend: remove pre-account-setup password handling
    • backend: switch to "always password-less" mode
    • backend: add password query API
    • sip-transport: allow multiple connect attempts, i.e. retry if there are still authentication schemes to choose from
    • sip-transport: switch from hard-coded authentication scheme to auto-detection based on 401 response authentication headers (probable priority list: TLS-DSK -> Kerberos (if compiled in) -> NTLM)
    • others in core: all places where authentication scheme value is checked need to be aware that it is auto-detected, i.e. the decision can only be made after successful SIP connect
    • security: "password required" decision: when, how?

    Not something you do in 5 minutes and I probably missed some blockers.

  • Stefan Becker

    Stefan Becker - 2014-05-04
    • assigned_to: Stefan Becker
  • Stefan Becker

    Stefan Becker - 2014-05-04

    git commit a1afe87 is the initial implementation for this feature. I'm not sure if your Kerberos error case is covered by this, because a GSSAPI failure will still abort the connection. Please test.

    After some pondering I decided that SSO stays as it is. The user has 3 choices to set up his account:

    1. SSO enabled: SIPE will never ask for the password before connecting, unless the authentication scheme requires one (e.g. TLS-DSK),
    2. SSO disabled: SIPE will always ask for a password before connecting, or
    3. SSO disabled, password saved: SIPE will never ask for the password before connecting.

    Querying for the password while we are connecting is not possible, because the server will disconnect due to an inactivity timeout. I.e. it would depend if the user has entered the password fast enough for the authentication to succeed or not.

  • Stefan Becker

    Stefan Becker - 2014-05-10

    git commit 1a4e35e extends the fallback for the cases where the automatically selected authentication scheme fails to initialize or can't continue. This should complete the implementation for this feature.

    @David: please test

  • Stefan Becker

    Stefan Becker - 2014-06-07
    • status: open --> closed-fixed
  • Stefan Becker

    Stefan Becker - 2014-06-07

    No feedback, assuming feature is working for reporter. CLOSING


Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks