IBM Verify

IBM Verify

Join this online user group to communicate across Security product users and IBM experts by sharing advice and best practices with peers and staying up to date regarding product enhancements.

 View Only
Back to discussions
Expand all | Collapse all

NTLM workarounds

  • 1.  NTLM workarounds

    Posted Wed December 19, 2018 11:39 AM
    Edited by Michael Boey***** Wed December 19, 2018 11:40 AM
    ​Hello,

    Following my (successfully solved) question about Forms-based SSO, we have another legacy technology which we are phasing out, but still exists. Again, I'm fully aware that it might be a better idea to move to other protocols, but it is a reality that some applications still speak NTLM.

    So what we'd like to achieve is:
    User => Internet ======> ISAM Webseal ===NTLM===> back-end app

    We know that NTLM is not supported anymore in ISAM. Is there someone who has a valid alternative in case we cannot get the back-end application to move away from NTLM(v2)?


    ------------------------------
    Michael
    ------------------------------
    ​


  • 2.  RE: NTLM workarounds

    Posted Thu December 20, 2018 12:57 AM
    Hi Michael, since WebSEAL does not speak NTLM, I was thinking of a gateway between WebSEAL and the NTLM-capable back-end. There seems to be an Java-based httpclient from Apache that could be useful. See here: https://hc.apache.org/httpcomponents-client-4.5.x/ntlm.html. WebSEAL could then send just about anything to that gateway; anything that contains what NTLM needs: a username and password. It could f.i. be a BA junction using your newly developed GSO web service.
    All in all, this looks like an adventure.

    Cheers, Peter.

    ------------------------------
    Peter Volckaert
    Sales Engineer
    IBM Security
    ------------------------------

    Original Message


  • 3.  RE: NTLM workarounds

    Posted Thu December 20, 2018 03:38 AM
    ​Hi Peter,

    That might be a valid alternative indeed. The one downside is of course that we introduce a new component, which we'd have to set up HA and maintain. I'll investigate it a bit futher internally.

    Perhaps another alternative is a mapping rule which speaks NTLM? I see some people tried to implement NTLM in JS:
    • https://libraries.io/npm/@beyond-sharepoint%2Fntlm-remote-auth
    • https://github.com/beyond-sharepoint/ntlm-remote-auth/blob/master/lib/ntlm.js


    ------------------------------
    Michael
    ------------------------------

    Original Message


  • 4.  RE: NTLM workarounds

    Posted Thu December 20, 2018 08:40 AM
    Hi Michael,

    A mapping rule containing JavaScript that can implement NTLM is an interesting idea but I wonder how communication between the InfoMap and the backend service would work.  An InfoMap doesn't have any direct influence over what is sent over a junction.

    One idea might be to have the InfoMap talk directly to the backend server and perform an NTLM login.  Once complete, the backend server would (presumably) set a cookie to maintain logged-in state for the session.  If you could capture that cookie and get it set in the browser (or in the Reverse Proxy cookie-jar) with path=/ then it might be possible to have that session used for requests via the ntlm-server's junction.

    Quite a few "ifs" in the above but given the eventual success with the GSO issue I suggest it in case you want to investigate further.

    Cheers... Jon.

    ------------------------------
    Jon Harry
    Consulting IT Security Specialist
    IBM
    ------------------------------

    Original Message


  • 5.  RE: NTLM workarounds

    Posted Tue January 08, 2019 11:13 AM
    Hi,

    Thanks for the answers.
    We wish to investigate the JS option a bit further, just to be sure: is any Javascript supported on ISAM or are there restrictions?

    Btw, the previous examples were nodejs modules, this one seems to be plain JS: https://github.com/erlandranvinge/ntlm.js/tree/master

    ------------------------------
    Michael
    ------------------------------

    Original Message


  • 6.  RE: NTLM workarounds

    Posted Tue January 08, 2019 11:53 AM

    Hi Michael,

    Not just any Javascript is ok, it must conform to JavaScript 1.7.

    More specs and tips on this link: https://www.ibm.com/support/knowledgecenter/SSPREK_9.0.6/com.ibm.isam.doc/config/task/tsk_managingmappingrules.html

    Cheers, Peter.



    ------------------------------
    Peter Volckaert
    Sales Engineer
    IBM Security
    ------------------------------

    Original Message


  • 7.  RE: NTLM workarounds

    Posted Fri January 11, 2019 10:48 AM
    I tried it using a patched version of the NTLM JS library: https://github.com/hdeshev/nativescript-ntlm-demo/blob/master/app/ntlm.js . 
    Changes to get it running were minimal, but I did not succeed and my assumption is that it is because that library only seems to support NTLM 56 bit encryption, whereas most modern applications / servers demand the use of NTLM 128 bit encryption. Also, it seems there is something like signing of NTLM, which also does not seem to be supported by that library. 

    The nodeJS library (https://github.com/beyond-sharepoint/ntlm-remote-auth/blob/master/lib/ntlm.js) seems to include the missing features, but converting that to plain JS seems like a daunting task. Perhaps one day someone will try that :). 

    Fun experience, too bad I couldn't get it to work. 

    Kr,
    Michael

    ------------------------------
    Michael
    ------------------------------

    Original Message


  • 8.  RE: NTLM workarounds

    Posted Mon January 14, 2019 10:23 AM
    Edited by Michael Boey***** Mon January 14, 2019 12:56 PM
    ​Ok, I couldn't just leave it.
    I contacted someone via upwork.com and had the https://github.com/gautamsi/node-ntlm-client translated into plain JavaScript.

    In tests outside ISAM this works fine. It even runs in ISAM, but there is one very last error (at least, I hope it's the last one) that I'm afraid I won't be able to solve myself. I'm using HTTPClient to set up a connection from ISAM to the back-end NTLM server (https://www.stephen-swann.co.uk/javadoc/sam9.0/com.ibm.security.access.common/com/ibm/security/access/httpclient/HttpClient.html).

    I took a packet trace on ISAM to see what was going wrong, this is my first (out of 2) NTLM request:
    GET /***redacted***
Connection: close
Authorization: NTLM TlRM***redacted***==
Cache-Control: no-cache
Pragma: no-cache
User-Agent: Java/1.8.0_171
Host: ***redacted***
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2​
    The problem is the first header: Connection: close.
    If I send a connection: close in my test client outside ISAM, the complete NTLM exchange fails. This is normal: for NTLM there need to be at least two requests and one response. If the server thinks it can disconnect after the first request, then there is an issue.

    Is there anyway I can modify this header to 'Connection: keep-alive'?

    Michael

    update: more info about the necessity for keep-alives when using NTLM: http://www.benjaminathawes.com/2010/10/14/ntlms-dependency-on-http-keep-alives-another-cause-of-the-dreaded-401-1-error/ (not that this is about the server headers, but it also counts for client headers).
    update 2:

    ------------------------------
    Michael
    ------------------------------

    Original Message


  • 9.  RE: NTLM workarounds

    Posted Wed January 16, 2019 11:56 AM
    ​I could get past the connection: close problem by using Webseal, as suggested by Peter. Also, I had to configure some other options:
    • strip-www-authenticate-headers=no
    • max-cached-persistent-connections= <something larger than 0>

    And then make sure the junction can be called by anyone (since it will be called by the httpclient). Also, the junction must have BA authentication set to 'ignore', so it will pass through the NTLM headers to the httpclient.

    Then, using Wireshark I am able to create exactly the same NTLM exchange. The sad thing is that it still fails somewhere. Since a capture of a working flow and a failing flow looks almost exactly equal, I have no clue where it goes wrong. Still, interesting exercise. Perhaps some day someone will find the solution, or ISAM might just support NTLM out of the box :).

    ------------------------------
    Michael
    ------------------------------

    Original Message


  • 10.  RE: NTLM workarounds

    Posted Mon January 21, 2019 04:05 AM
    ​Update: we got the core to work!
    I'm now able to access a page secured with NTLM (a 200 OK is returned with HTML and cookies).

    Todos:
    • check the security impact of enabling persistent sessions
    • copy the back-end authentication cookie (sharepoint in our case) into the user's session
    • check the performance of the code

    In the end, we fell prey to an endianness problem in the MD4 library that we used: https://github.com/mozilla/rhino/issues/515
    When we switched to another one which does not use intarrays, the issue was solved.

    I'll document it a bit further in the coming days/weeks.

    ------------------------------
    Michael
    ------------------------------

    Original Message