Menu
▾
▴
#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.
Ticket moved from /p/sipe/bugs/208/
Can't be converted:
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.
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?
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:
Not something you do in 5 minutes and I probably missed some blockers.
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:
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.
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
No feedback, assuming feature is working for reporter. CLOSING