IBM Security Verify

 View Only
  • 1.  Some ways of setting a password result in unusable password

    Posted Thu May 12, 2022 12:40 PM
    Edited by Jens Petersen Fri May 13, 2022 12:02 PM
    Hy Community,
    I've opened a PMR long time go (63 Days!) and still no final response, while it is easily reproducible. Maybe anybody here has a clue:



    We found an issue with changing a user’s password in different ways leading to a different result while using the same input string. In the end we could trace it down to some German special characters. But also, other special characters seem to trigger that issue.

    To see what’s happening we’d set up a lab environment wit LDAP storing the PW in plain text. As input string we used the following password in ALL cases: pwAGPVBO%456ÄÖÜäöüß

    We have tried 4 different use cases:
    1. Using WPM from Appliance
    2. Using pdadmin from ssh terminal
    3. Using mapping rule with UserHelper
    4. Using our portal which results in a call to the pdadmin REST API

    Setting it with WPM results in the same string stored at the LDAP userPassword Attribute. So case 1 seems fine. See result at pwmitumlauten-pdadmin-wpm.png.

    Using pdadmin from ssh terminal ends up with a totally different String. That in fact would result in a not recoverable password and a user unable to log in. See pwmitumlauten-putty.png

    For the mapping Rule with UserLookupHelper we also got a very strange and again different result, as you can find at pwmitumlauten-userlookuphelper.png. At this point we noticed that forcing the browser using ISO-8859 encoding solves the problem. As we can’t force users to do so this isn’t a way solving the issue. The code is as follows:
    var user = helper.getUser(username);
    if (user && !stringUtils.isNullOrEmpty(newPassword)) {

    For the REST API it looks like the PW will be stored correctly. The code is as follows:
    commands = String.format("user modify %s account-valid yes", cn),
    String.format("user modify %s password \"%s\"", cn, newPassword),
    String.format("user modify %s password-valid no", cn);
    JSONArray commandsArray = new JSONArray();
    for (String command : commands) {
    return new JSONObject()
    .put("admin_id", adminId)
    .put("admin_pwd", adminPwd)
    .put("admin_domain", adminDomain)
    .put("commands", commandsArray)

    Jens Petersen

  • 2.  RE: Some ways of setting a password result in unusable password

    Posted Fri May 13, 2022 11:50 AM
    Edited by Jonathan Pechta Fri May 13, 2022 12:06 PM

    We've reached out to the Verify team to alert them to this forum post. There should be an update on your case now. If you continue to experience issues like this in the future, be aware that there is an escalate button for cases in the support portal. I do not work on the IBM Verify team direct, but do work in QRadar Support. If IBM is Working is the status of a case you can escalate to request an update at any time. This puts cases in an elevated response for the support team to contact you.

    Reference information: How to Escalate Support Cases

    I hope this helps. I contacted both the case owner and their manager to your forum post via internal IBM channels to raise your issue to the support personnel involved.

    Jonathan Pechta
    QRadar Support Content Lead
    Support forums:

  • 3.  RE: Some ways of setting a password result in unusable password

    Posted Fri May 13, 2022 11:57 AM
    Hi Jonathan,
    thanks for the hint, I used the escalate Button and got a response, at least. Seems now it's escalated to L2 ...


    Jens Petersen

  • 4.  RE: Some ways of setting a password result in unusable password

    Posted Mon May 16, 2022 05:00 AM
    Hi Jens,

    I don't think you'll get a universal solution for non-ASCII passwords, since there is no standard way for a server to ask for a client-sided encoding.

    José Pina Coelho
    IT Specialist at Kyndryl

  • 5.  RE: Some ways of setting a password result in unusable password

    Posted Mon May 16, 2022 11:12 AM

    Well, if doubtable about different applications you probably got a point (while I think there would be one or another option). In this case we are talking about different interfaces to the same application. In fact I think it's not even all different. I wonder e. g. whether the REST uses a new implemented module but the same as pdadmin as the REST call is about calling pdadmin. 


    Jens Petersen