#64 Add support for GSS-NTLMSSP

closed-fixed
Stefan Becker
None
Protocol/Other
5
2013-10-26
2013-07-03
David Woodhouse
No

I've logged in to my system using pam_winbind, and automatic NTLM authentication is working for Firefox, Evolution, everything that uses libsoup, etc.

It works by invoking /usr/bin/ntlm_auth to handle the NTLM challenge/responses for me.

However, it doesn't seem to work with pidgin-sipe. Pidgin demands to be given the password, without even trying /usr/bin/ntlm_auth.

There's a sample ntlm_auth implementation at http://david.woodhou.se/ntlm_auth_v2.c which you can build with -DTEST_HACK and drop into place for testing purposes, without actually having to have winbind set up (although winbind can be prodded with the right info with 'wbinfo -K $DOMAINUSERNAME' too, which is easier than actually configuring the local PAM stack to use it).

Discussion

  • Stefan Becker
    Stefan Becker
    2013-07-04

    Ticket moved from /p/sipe/bugs/205/

    Can't be converted:

    • _milestone: 1.16.x
     
  • Stefan Becker
    Stefan Becker
    2013-07-04

    SIPE has it's own NTLMv2 implementation for non-Windows systems.

    Supporting PAM/pam_winbind would be a new feature. I hope there is an API and documentation available that can be called from C code to detect its presence and to generate the NTLM messages. Running an external program is not acceptable for protocol plugin code.

    I don't see anything about PAM in the referenced C code, so I don't quite understand how it is supposed to help.

     
  • Stefan Becker
    Stefan Becker
    2013-07-04

    • summary: Automatic NTLM authentication not working --> Add support for pam_winbind
    • Category: Pidgin --> Protocol/Other
     
  • Stefan Becker
    Stefan Becker
    2013-07-04

    To be more precise: I see two options: PAM offers either

    1. an API to provide the NTLM authentication tokens for the "logged in" user, i.e.
      • domain
      • username
      • NTLMv2 hash
        (this should be enough to initialize the SIPE internal NTLMv2 implementation)
    2. or a GSSAPI-like interface, which is already used for Kerberos

    Those APIs must be support runtime detection, otherwise it will be impossible to support this feature in Linux distribution packages.

     
  • Stefan Becker
    Stefan Becker
    2013-07-04

    ntlm_auth(1) man page

    This tool is not usable for SIPE, because it only handles user authentication but not message authentication.

     
  • Stefan Becker
    Stefan Becker
    2013-07-04

    I start to wonder if this will work at all. If you use Samba, why don't you simply join the Windows Kerberos Domain and use Kerberos instead? That has GSSAPI and supports Single Sign-on.

    Based on the available information I propose to close this feature request as INVALID.

     
    • That's explained in feature request #65. Kerberos fails too often due to random DNS and other issues. Windows users don't notice because they just fall back to NTLM. so when I use Kerberos some features just stop working (like download contact images/icons).

       
  • Stefan Becker
    Stefan Becker
    2013-07-05

    After studying soup-auth-ntlm.c I have come to conclusion that the ntlm_auth approach only works for HTTP connections, because all you need there are the raw NTLM challenge/response messages.

    But M$ has extended the SIP protocol with a mandatory Message Integrity Code (see [MS-SIP] , section 3.1.4.2 for details). You can only generate and verify MIC's if you have the Exported Session Key, which is generated during the NTLM authentication message (see src/core/sip-sec-ntlm.c:sip_sec_ntlm_gen_authenticate(), e.g. client_sign_key).

    As far as I can tell Samba does not offer a GSSAPI to winbind, which would be required for SIPE to be able to use the cached credentials.

     
    Last edit: Stefan Becker 2013-07-05
  • Stefan Becker
    Stefan Becker
    2013-07-05

    If I understand Samba3 ntlm_auth code correctly, then even in the case of cached credentials you don't get access to the session key, i.e. winbind generates the NTLM messages for you.

    It looks like that Samba4 ntlm_auth code no longer implements cached credentials.

    Unless someone can point out what I'm missing I fear this feature can't be implemented.

     
  • Apologies for the duplicate request. I was "sure" I'd filed it once, but the URL (https://sourceforge.net/p/sipe/bugs/205/) just gave me a 404 and I couldn't find it anywhere when I searched. I don't seem to be getting email updates. So I assumed user error, and filed it again.

    I will file an RFE against Samba to ensure that this can be supported properly. Thank you for the coherent explanation of what's missing.

     
  • Stefan Becker
    Stefan Becker
    2013-07-10

    Please make sure that the RFE handles the following requirements:

    • solution must work in parallel to existing SIPE NTLMv2 (having to select it during compile time will prevent Samba support from being enabled in distribution packages)
    • API for "NTLM SSO available: YES/NO" must be on-the-fly and non-blocking
    • libgssapi_ntlm.so.2 [I guess, to be the same as heimdal API?] (I don't want to even know about ntlm_auth and its cryptic pipe protocol....)

    Some future goal: add sip-sec-gssapi.c based on libgssapi.so. I.e. use the same approach as SSPI on Windows also for UNIX. As far as I understand the Heimdal documentation it would already possible to do this with Heimdal.

     
  • ntlm_auth already supports GSSAPI exchanges (see --helper-protocol gss-spnego and --helper-protocol gss-spnego-client). It shouldn't be impossible to extend it to support message authentication too. You might give it the hash of the message you're sending, and it hands back the Message Integrity Code according to the NTLM session key.

    Request filed in Samba bugzilla at https://bugzilla.samba.org/show_bug.cgi?id=10007

     
  • (Apologies if this is another duplicate. I just hit 'post' and was told that the message was posted but it isn't here...)

    https://bugzilla.samba.org/show_bug.cgi?id=10007

     
  • Yay, multi-page views, not showing me what I just posted! Grr :)

    See https://git.samba.org/?p=idra/gss-ntlmssp.git for a start at a proper GSSAPI mechanism.

    Making the 'SSO available: yes/no' non-blocking is hard. It has to talk to something and see if there are credentials available. That 'something' is the local winbind server, and it's fast. But it's not entirely non-blocking.
    It's about as non-blocking as reading from a local file though, and we usually get away with that.

    And answering the question 'do my SSO credentials work?' is even harder. You actually have to talk to the server to establish that. The password might be changed on the server between the time you ask your question, and the time your authentication packets actually reaches the server.

    Fundamentally, there's usually something wrong if you need to know the answers to these questions in advance. We should be trying it, and falling back to a password if it doesn't work.

     
  • Stefan Becker
    Stefan Becker
    2013-07-10

    That would require rewriting/restructuring a lot of the code to be asynchronous. The security code is on a lower level and has absolutely no clue about the SIPE core, e.g. for triggering scheduling actions.

    There is something similar already in place for TLS-DSK when the necessary certificate is not available, i.e. initiate certificate retrieval and set the "can't proceed" flag. When the certificate code has acquired the certificate it retriggers the REGISTER attempt.

     
  • Stefan Becker
    Stefan Becker
    2013-07-10

    BTW: please remember one thing: SIPE core does not "own" the event loop. It doesn't and can't know anything about the event loop, because this information is backend specific.

    That means that executing and talking to "ntlm_auth" asynchronously would need to happen in the backend.

     
  • Stefan Becker
    Stefan Becker
    2013-10-20

    • summary: Add support for pam_winbind --> Add support for GSS-NTLMSSP
    • assigned_to: Stefan Becker
     
  • Stefan Becker
    Stefan Becker
    2013-10-20

    Update: implementation is progressing.

    GSS-NTLMSSP is a GSSAPI mechanism that implements NTLMSSP.

    Kerberos 1.11 added support for SPNEGO (AKA Negotiate).

    Adding support for this will mean you can compile SIPE on UNIX without internal NTLM & Negotiate. I.e. we will have the equivalent to SSPI on Windows.

     
  • Stefan Becker
    Stefan Becker
    2013-10-26

    • status: open --> closed-fixed
     
  • Stefan Becker
    Stefan Becker
    2013-10-26

    Basic GSS-NTLMSSP support has been implemented in git commit a2af707. Setting to CLOSED-FIXED.

    GSSAPI SPNEGO support is still work in progress. Code currently still uses the internal Negotiate module.

    Once GSS-NTLMSSP supports SSO via pam_winbind then the original feature request will be fulfilled. But that is outside the control of the SIPE project.