Domino on Linux/Unix, Troubleshooting, Best Practices, Tips and more ...

    IBM Mail Support for Microsoft Outlook officially released

    Daniel Nashed  29 June 2016 15:49:35
    Finally IBM has released IMSMO 2.0. It has been around already under controlled distribution and is finally available for all customers and partners.

    It enables you to connect a Microsoft Outlook 2013 client to a Domino V9.0.1 Server.

    The software is an add-on to your Domino server similar to what a Traveler does (in fact they share some code base but they are not the same!).
    Also the gateway need to resist on the mail-server of the user. We asked to have a way to use a gateway server approach but IBM implemented it this way.

    If you are running in a production environment and you are running with more than a handful of users it is strongly recommended to use DB2 for the state database instead of the derby database.
    So for every server that has IMSMO enabled you need a connection to a DB2 server for the state database.
    Another way would be to have a local replica of the mailfile on the IMSMO server for all users running an Outlook Client.

    This solution is not intended for a whole, large organization. It's more one of the flexible options to support Outlook Clients in your environment for users who want or need the client for some special reason.

    For the Outlook Client you have to deploy an add-on which handles the connection.
    The first version with the project name "Hawthorn" was using the Active Sync protocol for sync and rest services with a plug-in for additional services like OOO and busytime lookup. T
    hat's why only Outlook 2013 and higher was supported because earlier releases did not support ActiveSync.

    The new version uses SyncML which gives IBM more control over the connection and functionality. The plugin does now handle the whole connection from client to server over SyncML.
    Older clients can still connect over ActiveSync but the new model makes more sense to only use the new plug-in.
    IBM also plans to support other Outlook Clients leveraging the plug-in approach.

    If you are entitled to download Domino V9.0.1, you can download IBM mail support for Microsoft Outlook at no charge from Passport Advantage®.

    ReadMe

    IBM Mail Support for Microsoft Outlook 2.0 Release Notes Multiplatform English (CNCZ9EN )

    Servers

    IBM mail Add-on 2.0.0 (for IMSMO) Windows 64 bit Multilingual (CNBK6ML )
    IBM mail Add-on 2.0.0 (for IMSMO) AIX 64 bit Multilingual (CNBK7ML )
    IBM mail Add-on 2.0.0 (for IMSMO) Linux 64 Multilingual (CNBK8ML )

    Client

    IBM mail Add-in 2.0.0 (for IMSMO) Windows 32/64 bit Multilingual (CND43ML )


    But you should wait to download and install the client component. There is an issue where I have an open PMR since yesterday afternoon.
    It looks like there is an issue with the client package. Development reported back that they are working on it with high priority.
    I will blog about it once I have more details.


    Here is a quick link to the admin guide:

    http://www.ibm.com/support/knowledgecenter/SSKTMJ_9.0.1/admin_imsmo/adm_toc.html


      Domino Catalog vs Domain Catalog

      Daniel Nashed  11 June 2016 16:50:33
      I while ago I ran into this and I did analyse how it works in detail. But I never posted this information.

      Today we ran into this again and I looked for my old documentation.

      -- Daniel

      Here is how it is intended to work and how most admins are currently using it.


      I was very surprised when I figured out how the catalog and domain catalog really work.

      My impression was always that the catalog.nsf is a replica that is replicated everywhere.


      But there are two different types of catalogs:


      Normal Catalog


      - Content resist only on one server and is not replicated. Local server will update the data.

      - Other servers have reader access and nobody beside the own server can update it.


      Domain Catalog


      - Contains database information for many or all servers

      - Other servers have editor access and database information is pulled from other replicats to the central database

      - If a server has no replica of the catalog.nsf the catalog on the Domain catalog server will spider the server and collect databases, else the catalog task will replicate the database!



      So in any case the catalog.nsf should be a replica on each server -- actually it is derived from the replica of the server's names.nsf (it's one of the special replicas).

      Each replica maintains it separate ACL and each server should only have manager access on his own replica.
      The catalog.nsf is designed to have different ACLs so that only the Domain catalog servers will contain all data.


      When the catalog task starts it will check if the config document document has the "domain catalog" enabled.

      In that case LocalDomainServers, LocalDomainCatalogServers will be editor access in catalog.nsf on the local server Else both groups are set to reader access instead!


      That would mean if you add an admin server or have a catalog.nsf created on a server in a way that other servers have manager access to the database the ACL it might replicate all data and the concept of the catalog distribution will not work in most cases!


      Normally an Administrator would expect that LocalDomainServers are manager on catalog.nsf and the HUB server is admin server of the database with manager access and the ACL should be the same on all servers.

      But the catalog.nsf is intended to have a different ACL on each server instead. That was complete news for me. I was often wondering what is happening with the LocalDomainServers and LocalDomainCatalogServers all the time in some cases.


      Because LocalDomainServers, LocalDomainCatalogServers ACL entries are always checked and updated when needed by the catalog servertask, you should not change those ACL entries!
      And in case you want your own group to control replication of catalog.nsf in your own way, you should not use those two ACL entries but create your own group.


      In case a server has manager rights in the remote database it would push his ACL to the other server or if the other server has manager access, receive the ACL changes -- depending also on the time-stamps in the ACL.

      So what could happen is that you end up with a permanently changing ACL and potentially all catalog entries on all servers in your Domino domain -- depending which server is domain catalog server.


      This is not the intended way the catalog should work! It is intended to have separate ACLs settings on each replica and every server manages it's own ACL settings.

      Also the mentioned two ACL entries should not be removed from the ACL because that causes the catalog task to fail updating the ACL and does stop the catalog task before updating the catalog content.


      What might happen in many cases is that you create a "normal" replica of your catalog.nsf. In that case you could already run into trouble because the ACL might contain an admin server entry that is copied.

      That means the server you replicated the catalog.nsf from will be able to update documents on that new server -- which is not the intended way it should work.


      The best way would be just to start the catalog servertask and have the server create an empty replica based on the derived replica id from the names.nsf.

      Catalog.nsf will than only be replicated to a Domain catalog replica instead to all servers.


      Again I was very surprised when I figured out the logic behind it in detail and how it is intended to work.

      If you ran into this situation the best way would be to start from scratch.

      You remove the catalog.nsf databases on all servers, verify the right settings for the "Domain catalog" in server document and plan your catalog.nsf distribution that way.

      Once you are done you can just run the catalog task on each catalog server to populate it.

      When that is done, you can start the catalog task again on all the domain catalog servers.


      Take care: If you start it before a server has a new replica the Domain catalog server would spider the server manually and you could end up with duplicate documents in the catalog once the catalog task has been started on the local server later on.

      As a trick you could set the "Limit domain cataloging to the following servers:" field next to the Domain Catalog field in the Servertasks / Domain Catalog tab. This field limits which servers should be queried.

      Also take care that an administrator with manager access should never replicate the catalog.nsf because that would also potentially break the ACL and the replication scheme.


        DE-Mail Mail-Template with Command Line DNS Lookup

        Daniel Nashed  8 June 2016 07:43:38
        We ran into a limitation with the DE-Mail Template that T-System implemented in their Notes Mail Template.

        It turned out that they are invoking a cmd.exe because this is the only way to return data directly from nslookup to the application with a redirect on Windows.
        The function is used to check if the recipient's domain is a DE-Mail domain and queries SRV records defined in RFC RFC 2782 (check https://en.wikipedia.org/wiki/SRV_record for details).

        SRV Records can not be queried with  simple DNS lookup but need a more complex syntax as shown in the example below.

        Here is the actual code in the DE-Mail Template:

        'Call executeAndWait("CMD.EXE /C nslookup -type=SRV _ldaps._tcp."+domain+ipPart+" 2> "+tmpFilePath)

        Example nslookup:

        nslookup -type=SRV _ldaps._tcp.web.de-mail.de

        Non-authoritative answer:
        _lDAPS._tCP.wEb.de-mAIl.de      SRV service location:
                  priority       = 0
                  weight         = 5
                  port           = 636
                  svr hostname   = oevd.sec.de-mail.de


        We have asked T-Systems to enhance the code a quite while ago because usually cmd.exe is not allowed in Citrix environments and it will also not work on Linux and Mac.
        It does not look like we are going to get a solution soon., so we implemented your own work-around.


        Luckily there is a Java class that implements functionality to query SRV records. Here is the first version of the code I wrote.
        I have added a Java agent and a function to invoke the Java agent to replace the current implementation of the lookup.
        The agent is invoked with the document in context from Lotus Script without the need to save the document first.

        Feel free to use this code, modify/enhance it and send feedback.

        -- Daniel



        -- Script Lib "DeMailFunctions" --

        - New Function CheckRecipient


        Function CheckRecipient (Doc As Notesdocument, Domain As String) As Integer

               
               Dim theAgent As NotesAgent

               Dim AgentString As String

               Dim NoteID As String

               Dim ret As Integer

               Dim demail_recipient As Integer

               Dim db As NotesDatabase

               '1 = no DE-Mail recipient

               '0 = valid DE-Mail domain

               demail_recipient = 1

               
               On Error Goto end_function

               
               Set db = doc.ParentDatabase

               
               doc.nslookup_domain = domain

               Set theAgent = db.GetAgent("nslookup_srv")

               If Not(theAgent Is Nothing) Then

                       ret = theAgent.RunWithDocumentContext(doc, "")

                       
                       If (ret = 0) Then

                               If (doc.nslookup_result(0) <> "") Then

                                       ' Print "nslookup.srv result -> " + doc.nslookup_result(0)

                                       demail_recipient = 0

                               End If

                       End If

               Else

               End If

               
        end_function:

               Call doc.RemoveItem ("nslookup_domain")

                Call doc.RemoveItem ("nslookup_result")
                CheckRecipient = demail_recipient        
               Exit Function

               
        End Function



        -- Change Function "checkRecipients" --


        Comment out the following two red lines and add the green line


        'Call executeAndWait("CMD.EXE /C nslookup -type=SRV _ldaps._tcp."+domain+ipPart+" 2> "+tmpFilePath)

        'If Not checkLookUpResult(tmpFilePath) Then                

               

        If (CheckRecipient (doc, domain)) Then        



        -- New Agent "(nslookup_srv)" --

        Add the following Java Agent code


        ' Written by Daniel Nashed (nsh@nashcom.de)
        import lotus.domino.*;
        import
        java.util.Hashtable;
        import
        java.util.ArrayList;  
        import
        java.util.List;
        import
        javax.naming.*;
        import
        javax.naming.directory.*;

        public
        class JavaAgent extends AgentBase {

           
        public void NotesMain() {

             
        try {
                 Session session = getSession();

                 AgentContext agentContext = session.getAgentContext();

                 Document doc = agentContext.getDocumentContext();
                 
                 
        if (doc != null)
                 {

                         doc.replaceItemValue(
        "nslookup_result", "");
                         String nslookup_domain = doc.getItemValueString(
        "nslookup_domain");
                         String nslookup_dnsserver = doc.getItemValueString(
        "ServerIP");
                         System.
        out.println("nslookup_domain -->" + nslookup_domain + "< ServerIP --> " + nslookup_dnsserver + "<");
                 
                         Hashtable env =
        new Hashtable();
                         env.put(
        "java.naming.factory.initial", "com.sun.jndi.dns.DnsContextFactory");
                         
                         
        if (nslookup_dnsserver == "")
                                 env.put(
        "java.naming.provider.url", "dns:");
                         
        else
                                 env.put(
        "java.naming.provider.url", "dns://" + nslookup_dnsserver);
                                 
                         DirContext ctx =
        new InitialDirContext(env);
                         
                         
        try {
                                 Attributes attrs = ctx.getAttributes(
        "_ldaps._tcp." + nslookup_domain, new String[] { "SRV" });
                                 
        if(attrs != null && attrs.size() > 0)
                                 {

                                         
        // System.out.println ("---found something---");
                                 
                                         NamingEnumeration e = attrs.getAll();  
                                         String lookup_result e.next().toString();
                                         doc.replaceItemValue(
        "nslookup_result", lookup_result);
                                 }
                                 
        else
                                 {
                                         
        // System.out.println ("nothing returned");
                                 }

                             }
        catch (NamingException e) {
                                     System.
        out.println ("--- Namelookup Result Catch ---");
                                     e.printStackTrace();

                             }


                         doc.recycle();

                 }

             }
        catch(Exception e) {
                 System.
        out.println ("--- Namelookup - General Catch ---");
                 e.printStackTrace();

              }

           }

        }

        ...

        43. DNUG 1. + 2. June in Hamburg

        Daniel Nashed  26 May 2016 09:58:42
        Image:43. DNUG 1. + 2. June in Hamburg




        Hi and good morning!

        This will be my first blog entry in Germany and it's about German about our German "Notes" User Group "DNUG"...


        Bei der DNUG hat sich einiges getan in den letzten Monaten! Seitdem die DNUG einen neuen Vorstand hat, werden einige Dinge anders angegangen und auch die Art und Weise, wie die DNUG Konferenz geplant wird, hat sich geändert.

        Die Geschäfts-Stelle ist jetzt virtuell und auch die Server der DNUG sind entsprechend virtualisiert. Aber auch an anderen Stellen sieht man, daß sich einiges verändert.

        Für die Organisation der Konferenz-Tracks sind die verschiedenen Fachgruppen verantwortlich.

        Zur Anmeldung für die Konferenz und für den Schedule werden Tools verwendet, die es günstig aus der Cloud auf dem Markt gibt. Die eigene EULUC Connections Platform der DNUG wandert in die IBM Cloud.


        Als Mitglied in der Fachgruppe Verse/Notes/Domino zusammen mit Anett Hammerschmidt und Manfred Lenz als Ansprechpartner und Mitglied in unserer Fachgruppe, haben wir uns um unseren "Track" gekümmert.

        Und ich denke sowohl in unserem als auch in allen anderen Tracks findet Ihr spannende Vorträge.

        Besonders ans Herz legen möchte ich Euch die Session zum Thema Verse on Premise
        (http://sched.co/72CJ) und die Session zum Thema Microsoft und IBM (Link http://sched.co/6zNW).
        Aber auch die Lizenz-Session
        (http://sched.co/6zJt), die wir in ähnlicher Form schon auf dem Domino Day hatten, wird bestimmt wieder interessant und wichtig mit vielen Diskussionen (im Bereich Lizenzierung, gibt es viele Details, die oft nicht bei Kunden und auch Business Partnern bekannt sind).

        Relativ neu ist auch bei der DNUG, daß IBM alle Fachgruppen mit einem Ansprechpartner unterstützt. Und für unseren Track und auch für andere Tracks stehen die Sprecher die übrige Zeit auf der Konferenz für Fragen zur Verfügung.

        Nutzt diese Gelegenheit um die Kollegen von IBM mit Fragen zu löchern und Feedback zu geben über das Produkt, Support und andere Dinge, die Ihr auf dem Herzen habt.


        Und auch preislich hat sich bei der DNUG in Bezug auf die Konferenz einiges getan. Die DNUG Konferenz ist für Mitglieder ein ganzes Stück günstiger geworden und auch die Referenten erhalten als Dank für ihren inhaltlichen Beitrag wieder eine kostenlose Konferenzteilnahme.

        Ich kann leider selbst dieses Jahr nicht mit auf der Konferenz dabei sein. Mein Urlaub war nicht mehr anders zu planen (das ist eine längere Geschichte).
        Aber ich wünsche allen eine tolle und erfolgreiche DNUG Konferenz in neuer Gestalt!!
        Ich wäre sehr gerne in Hamburg dabei. Dafür werde ich aber auf jeden Fall beim nächsten Domino Day der Fachgruppe Verse/Notes/Domino im Herbst wieder mit dabei sein.


        Für Themen und Vortragsideen und andere Dinge, um die wir uns als Fachgruppe beschäftigen sollen/wollen sind wir immer an Feedback und Mitarbeit interessiert.

        Und wer noch nicht auf der DNUG Konferenz angemeldet ist hier nochmal der Link zur Konferenz-Seite
        http://dnug.de/43-dnug-konferenz/

        Ciao und bis bald!

        Daniel

        Domino 9.0.1 FP6

        Daniel Nashed  22 May 2016 21:55:43
        Domino 9.0.1 FP6 has been released a while ago. I have installed it and I got positive feedback from customers already.

        FP6 contains all the fixes from previous IFs and also the updated JVM Java60SR16FP20 which addresses a couple of security fixes.
        Also the server controller interoperability issue is fixed. But for a client based connection you also need to update your admin client!

        All the TLS fixes are also included and there is an additional fix for an issue in a TLS handshake.

        SPR# MKINA3SPYN - Fixes an intermittent Domino Server crash in crypto code when VerifyMAC() is passed a bogus length.


        There are many other potential crash issues and security issues that have been also fixed.
        So it makes a lot of sense to install it on Server side.


        In additional there are fixes that need notes.ini parameters.

        The first fix is to bring back the pre Domino 9 behaviour for removing documents from the trash folder after the threshold expiered.
        In Domino 8.5.x was checked on database open. With Domino 9 it is only checked with updall.

        There is a new notes.ini parameter CHECK_EXPIRED_SOFT_DELETES_ON_DBOPEN=1 which brings back the previous behaviour.

        SPR# HYYH9DF5GR - Fixes situation where emails in trash are not  removed even if "Permanently delete documents after X hours" is set. This fix introduced a new Notes.ini CHECK_EXPIRED_SOFT_DELETES_ON_DBOPEN=1. This is off be default.


        There is also an ID-Vault fix which needs a notes.ini parameter. The notes.ini parameter is missing in the SPR description.

        The fix introduced needs the this notes.ini parameter IDV_RefreshCerts=1
        By default the parameter is disabled for performance reasons. You should only enable it when you are in a key-rollover project.

        SPR# KLYH9ZDQNC -- IDVault Key Rollover State Can Be Incorrect Due to Timing Issue

        http://www.ibm.com/support/docview.wss?uid=swg21976659&myns=swglotus&mynp=OCSSKTMJ&mync=E&cm_sp=swglotus-_-OCSSKTMJ-_-E




        Domino Federarted Web Login / SAML with F5 and ADFS 3.0

        Daniel Nashed  25 April 2016 17:14:43

        In the last couple of weeks I spent a lot of time with customer Web Federated Login workshops and implementations.
        Not sure what happened but suddenly everyone is interested in SAML. It looks like more and more customers are looking into that because they have already implemented SSO for other applications like O365.

        In one case a customer had an existing F5 configuration. In one other case we had a customer with Windows 2012 R2 and ADFS 3.0.

        Both configurations are not officially supported yet but we got it to work! Specially the F5 configuration was tricky. But in general both are just another SAML 2.0 implementation.
        We officially asked if those two configurations can be officially supported. It looks like it is more testing and documentation effort than any code change that is needed.
        But it is not yet an officially supported configuration. Implementing ADFS 3.0 is quite similar than ADFS 2.0.

        Win2012 R2 ADFS 3.0

        ADFS 3.0 in fact is a nicer implementation and does not need any IIS components. Also the SSO portal application is now implemented in a way that the UI can be completely customized. You can add you logo, change the CSS or could even build your complete own page.

        Also the installation is easier. ADFS 3.0 comes with Win2012 R2 and just needs to be enabled as a separate role. In contrast earlier versions shipped with SAML 1.1 support and you and to separately download and install SAML 2.0.

        The configuration is very similar but you cannot use the cookbooks 1:1. Some configuration details are now set via PowerShell commands.
        For example if you need to disable the extended protection when working with Chrome.

        Domino SAML Implementation

        In two customer situations we ran into an odd issue. When initiating the SAML login from the SSO portal like ADFS (with ADFS 3.0 the portal looks prettier and more customers might directly use the portal) redirecting to the Domino HTTP server caused a strange behavior.
        The URL invoked should have been the default server URL but there have been som random chars at the end of the URL. Tracing turned out that this was a day one issue with Domino Web Federated Login (WFL) and it was never thought of that the first request is the login request with a redirect from the Identity provider (IdP) in our case ADFS 3.0 or the F5 applicance.

        Even Domino uses a IdP Initiated model the first request was always initiated by Domino.

        Here is the flow that Domino uses.

        - Browser hits the Domino Server for a resource that needs authentication

        - User ist redirected to the IdP for authentication --> the URL contains ?loginToRp to tell the ADFS server where to return to after authentication. This is a ADFS specific parameter which is for example not understood by F5.
          Example: https://nsh-win-ad.ad.nashcom.loc/adfs/ls/IdpInitiatedSignOn.aspx?loginToRp=https://domino.nashcom.loc/names.nsf
          At the same time the server sets an undocumented cookie "DOMRELAYSTATE" which contains some data in binary format (base64 encoded) which contains the location to redirect to after login.

        - User is authenticated at the IdP. Either via AD name and password or with a Kerberos ticket (Integrated Windows Authentication -- IWA) if configured and the user and workstation are in the current AD.


        - Browser redirects back to Domino with the SAML post request
         Example:
        https://domino.nashcom.loc/names.nsf?SAMLLogin

        - After verifying the SAML data, the user is authenticated and a LTPA cookie is generated


        - At the same time the server reads the "DOMRELAYSTATE" cookie, removes it and redirects the user to his original location


        Redirection Issue

        In our problem case the user had no "DOMRELAYSTATE" cookie which caused the server to add some garbage to the URL.
        We got a hotfix for the issue which will hopefully make it into one of the next IFs. The SPR for this defect is SPR # MKINA8XN74.

        Summary

        So in general if you want to implement SAML right now I would use ADFS 3.0 and Windows 2012 R2 if you have the choice - even it is not yet supported by Domino.
        But ADFS 3.0 is the much better product which is better supported by Microsoft. And it is a much cleaner implementation. No dependency on IIS as well!




        Server Controller Issue when applying 9.0.1 FP5 IF2

        Daniel Nashed  31 March 2016 14:27:11
        After applying 9.0.1 FP5 IF2 you cannot connect to the server controller -- again!
        That's another issue that cannot be fixed allowing MD5 in the java security files.

        What you need is an updated version of the JVM patch. The new patch has a release data of 25.3.2016 an can be downloaded from Fixcentral.

        Here is the relevant information from the updated technote referenced in the SPR.

        SPR RSSNA6UU79 is fixed in version 9.0.1FP5 Interim Fix 2 (IF2) via a server code fix and an updated JVM patch (SR16FP20). IMPORTANT NOTE: It is required to install both 9.0.1FP5IF2 and the new JVM patch to address the issue. Download links are available in the following technote: http://www.ibm.com/support/docview.wss?uid=swg21657963

        If you already installed the JVM patch before you will run into an error:

        Patching tree diff from ".\jvm" to ".\jvm_dst" using diff file ".\patch.diff"...
            You are attempting to patch:
              pwi3260sr16fp2ifix-20141203_01(SR16 FP2+IV66900))
            With a patch that is valid for:
              src1 pwi3260sr16fp15-20151106_01(SR16 FP15))
            Tree diff file patch failed.


        My work-around was to re-install FP5 which includes the previous JVM patch.

        From there I was able to run the new JVM patch installer and also upgrade to 9.0.1 FP5 IF2.

        If that does not work in your case you have to go all the way back to 9.0.1 because that is the last release that contains a full JVM (9.0.1 -> FP5 -> New JVM Patch -> 9.0.1 FP5 IF2).

        In my case reapplying FP5 was sufficient.

        After the installation the java.security again has MD5 disabled and the console works. So apparently they build in a fix into IF2 and also did changes in the JVM patch.

        There is also a fix included in the Notes Client fix 9.0.1 FP5 IF3 and you also have to update your local JVM with the new patch available.
        I have so far just tested if the local server console on the Domino server works again.

        But since the SPR is also fixed on client side, I assume it works as well.

        -- Udpated JVM Patch Information --

        Mar 25, 2016

         interim fix: JVMPatch_SR16FP20_RSSNA6UU79_W32_901.5_ClientServer (40.53 MB)
        JVMPatch_SR16FP20_RSSNA6UU79_W32_901.5_ClientServer

        interim fix: JVMPatch_SR16FP20_RSSNA6UU79_W64_901.5_Server (76.78 MB)
        JVMPatch_SR16FP20_RSSNA6UU79_W64_901.5_Server



        Security Issue - IBM Domino AES GCM weak nonce generation vulnerability

        Daniel Nashed  29 March 2016 12:02:24
        There is a new vulnerability affecting AES GCM ciphers which have been introduced in 9.01. FP3 (enabled by default).
        For very large data sets, IBM Domino Web servers using TLS and AES GCM generate a weak nonce which could be potentially used for a man-in-the-middle-attack.


        All Domino 9 versions supporting those ciphers are affected and there is  new IF (9.0.1 FP5 IF2) which addresses this issue.


        The IBM Domino AES GCM weak nonce generation vulnerability is tracked as SPR #KLYHA6ZP4F.

        If you cannot update your server you should change your cipher spec to exclude those ciphers.


        The following cipher spec would only allow the CBC ciphers and leave out the 6 GCM ciphers currently supported.


        notes.ini SSLCipherSpecÀ28006BC0140039C0270067C013003D0035003C002F000A


        The better option would be to install IF2.


        Also the new Interims Fix includes a couple of other fixes. Including a fix for the Domino Console introduced by disabling MD5 in the last JVM patch as posted before.
        There is no detail how SPR #RSSNA6UU79 addressed the console issue. I had no time to test it in detail yet.

        Update 31.3.2016: There is a new issue with the Server Controller if you have applied the JVM fix as well.
        The solution is to re-install the latest JVM patch which has apparently a fix as well.
        See this new blog post for details -->
        http://blog.nashcom.de/nashcomblog.nsf/dx/server-controller-issue-when-applying-9.0.1-fp5-if2.htm

        SPR Description
        KLYHA6ZP4F Security Bulletin: Vulnerability in IBM Domino Web Server TLS AES GCM Nonce Generation (technote 1979604) Image:Security Issue - IBM Domino AES GCM weak nonce generation vulnerability
        EDOE9HZLXH Using the colon character in the Domino server title break the Java console. Image:Security Issue - IBM Domino AES GCM weak nonce generation vulnerability
        MKINA86V2A The Java console applet needs to be updated for Oracle JVMs Image:Security Issue - IBM Domino AES GCM weak nonce generation vulnerability
        MKINA85TJB The java console applet needs the same fix as SODY9FFEYE (technote 1662233) Image:Security Issue - IBM Domino AES GCM weak nonce generation vulnerability
        MKINA85TEQ The java console applet needs the same fix as SODY9DDBD5 (technote 1662233) Image:Security Issue - IBM Domino AES GCM weak nonce generation vulnerability
        PMGYA4CHDZ Fixes intermittent Domino Server and Notes Client crash when organization is doing a key rollover. Crash occurs on both client and server side when trying to connect. Image:Security Issue - IBM Domino AES GCM weak nonce generation vulnerability
        RSSNA6UU79 Domino Console won't connect even when scontroller is running (technote 1977125)






        Details and references:


        http://www.ibm.com/support/docview.wss?uid=swg21979604

        CVEID: CVE-2016-0270 / DESCRIPTION: IBM Domino contains an unspecified vulnerability that could lead to session snooping using man-in-the-middle techniques.

        Critical: glibc security and bug fix update

        Daniel Nashed  17 February 2016 14:02:45

        There is a critical issue with the glibc lib that Linux and other systems are using.

        The best short description I found is the following:

        "A stack-based buffer overflow was found in the way the libresolv library
        performed dual A/AAAA DNS queries. A remote attacker could create a
        specially crafted DNS response which could cause libresolv to crash or,
        potentially, execute code with the permissions of the user running the
        library. Note: this issue is only exposed when libresolv is called from the
        nss_dns NSS service module. (CVE-2015-7547)"

        Redhat already released patches:

        https://rhn.redhat.com/errata/RHSA-2016-0175.html
        https://sourceware.org/bugzilla/show_bug.cgi?id=18665

        And there is also a patch from SuSE

        https://www.suse.com/support/update/announcement/2016/suse-su-20160470-1.html

        I have already updated my CentOS 6 Linux machines (via yum update).

        Another interesting link is from Heise with some details in German:

        http://www.heise.de/newsticker/meldung/glibc-Dramatische-Sicherheitsluecke-in-Linux-Netzwerkfunktionen-3107621.html

        Thanks to my friend Harvey Pope pointing me to this bug and sending me the Heise link!

        Daniel

        Domino Server Controller does not connect after upgrade to Java6SR16FP20

        Daniel Nashed  16 February 2016 18:33:18
        The IBM Java Team disabled MD5 in there latest patch to tighten security. But the Server Console currently can only use MD5 right now.
        So by this intentionally change by the IBM Java Team the Domino Console cannot connect any more.


        For now to have the Server Controller local and remotely working again you have to re-enable MD5.

        This is a similar issue than what we had when the IBM Java team disabled SSLV3 some time ago.


        There are two lines that you have to change in the ..jvm/lib/security/java.security file.


        You have to remove MD5 from the disabled algorithms for now:


        jdk.certpath.disabledAlgorithms=MD2,
        MD5, RSA keySize < 1024
        jdk.tls.disabledAlgorithms=SSLv3, RC4,
        MD5withRSA, DH keySize < 768


        There is currently no other work-around for Windows. On Linux you could use the "monitor" command when using my start script and disable the server controller.


        -- Daniel


        • [IBM Lotus Domino]
        • [Domino on Linux]
        • [Nash!Com]
        • [Daniel Nashed]