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

  • 1.  How can I get more verbose logging from the Unix/Linux adapter for Identity Manager?

    Posted 2 days ago
    Edited by Frank Tate 2 days ago

    I am having a problem connecting to some new AWS EC2 VMs with the Unix/Linux adapter, and I want to get more detailed logging. Using jd-gui, I can see that the SecureSession class (and others in ssh.jar) utilize java.util.logging to write some detailed messages that would help me determine the issue. I have configured the ibmdisrv shell script to include this Java property on the command line to point to a configuration file:

    -Djava.util.logging.config.file=/opt/IBM/TDI/V10/jvm/jre/conf/logging.properties

    In that file, I have set the default level to "ALL" and have also specified a custom logger at the end of the file with the line:

    com.ibm.net.ssh.level = ALL

    I can see that the logger named "com.ibm.net.ssh" is being created, and some additional output is written to ITIMAd_stdout.log. However, I don't see any of the really detailed logging that I can see that SecureSession is able to write out.

    I have also tried uncommenting this line in the logging.properties file:

    handlers= java.util.logging.FileHandler, java.util.logging.ConsoleHandler

    to have it write data to its own file (rather than ITIMAd_stdout.log), and it writes to the specified file, but again, not the detailed logging that I'm looking for. 

    Does anyone have any suggestions for this?

    Edit: Doing more testing, I found that log4j2.xml is used to configure logging. I was just looking in the wrong place for the output. I found it in ITIMAd_stdout.log. So the configuration above doesn't matter. That's why I struck through all of that.

    I have log4j2.xml configured to set the default logging level to ALL, and specifically set ALL as the level for com.ibm.net.ssh, and I'm not seeing the detailed messages that I was hoping to from SecureSession. I see a bunch of log messages, but I'm really hoping to see the data that is sent and received by the PosixConnector when I test the adapter.

    Edit 2: Both of the above methods can be used simultaneously to configure logging, with different results from each. So you can use log4j2.xml AND/OR logging.properties. Who knew? Anyway, even with both of those in place and logging cranked up absolutely as high as it will go (level is set to ALL for everything), I'm still not seeing the log messages that I believe I should be seeing. For example, this line is in the code:

    logger.find("Socket connected");

    And that's just when the TCP connection is made, before the ssh session is even established. So "Socket connected" should be in one of the log files (because I know for a fact that it is connecting to the server, by looking at the logs on the server).

    Anyone tried to debug this adapter?

    ------------------------------
    Frank Tate
    Gulfsoft Consulting
    https://www.gulfsoft.com
    AIOps Experts. Contact us for implementation help.
    ------------------------------



  • 2.  RE: How can I get more verbose logging from the Unix/Linux adapter for Identity Manager?

    Posted yesterday

    I am not very good at the logging for Java/Adapters - a case of course would probably get that question answered....

    That said - the IBM Java SSH has had several problems adjusting to the ever revolving strengthening of Java - so I believe the problem you are seeing is probably in negotiating the crypto protocols - so I would setup SSL tracing to see what SSL is negotiating...

    HTH



    ------------------------------
    Franz Wolfhagen
    WW IAM Solution Architect - Certified Consulting IT Specialist
    IBM Expert Labs
    ------------------------------

    Original Message


  • 3.  RE: How can I get more verbose logging from the Unix/Linux adapter for Identity Manager?

    Posted 11 hours ago
    Edited by Frank Tate 11 hours ago

    Thanks for the reply, Franz. I found that the problem was the crypto signature algorithm that was negotiated. I found that using the first set of instructions I included in my question - using the logging.properties file. Once that was configured, I could see that the algorithm negotiated was ssh-rsa, and then it failed. On a server that worked, the negotiated algorithm was rsa-sha2-512. To resolve this, we ran the following commands on the server:

    # echo "sign = +DSA-SHA1 +RSA-SHA1" > /etc/crypto-policies/policies/modules/SIGN.pmod 
    # update-crypto-policies --set DEFAULT:SIGN 
    # update-crypto-policies --show 
    DEFAULT:SIGN 
    #systemctl restart sshd 

    So the negotiated algorithm is still ssh-rsa, but it works now that these legacy signature algorithms have been enabled.

    I don't think this is the 100% correct way to resolve the issue since on a server that works, ssh-rsa isn't in the list of supported algorithms accepted by the server (sshd -T). So while this workaround works, I think it is less secure than the configuration that's in place on the one that works.

    Anyway, back to the logging:

    In the logging.properties file, you additionally need to update these two properties:

    java.util.logging.FileHandler.limit = 100000
    java.util.logging.FileHandler.count = 20

    If you don't update them from the default values in the supplied logging.properties file, the SSL negotiation messages will quickly roll out of the generated log file.

    Frank Tate
    MBA, PMP, CISSP




    Original Message


Related Content