Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.
Jochen De Smet
Ran into an interesting issue last night. I finally managed to set up an OCS server (Lynx 2010 actually) for testing, and was having problems logging in from windows. Turns out that this is because by default the new server requires 128-bit authentication, and windows XP doesn't support that. Relaxing the requirements on the server fixed it.
However, there was no problem logging in from linux. Apparently the sip-sec-nltm code supports 128-bit just fine.
So I'm wondering, unless SSO is selected, would it make sense to just use the sip-sec-ntlm code on windows instead of the sip-sec-sspi one for NTLM authentication? That obviously would mean some code changes since right now sspi is selected just based on whether or not we're compiled with kerberos available or not.
IMHO we shouldn't change the code. Supporting dynamic SSPI selection (a windows-only feature) would affect also the UNIX code paths in sip-sec.c.
I agree though that enabling the calling of the SSPI code is flagged with HAVE_LIBKRB5 is confusing. Especially that the code is always compiled in, even when HAVE_LIBKRB5 is not set. pier11 should have introduced an own flag for that.
I think it is just one of those facts of life: if you want to support non-128-Bit-NTLM capable clients with your OCS, you have to lower the security requirements on the server.