7023286: SSPR 5003 in Forgotten Password Module

This document (7023286) is provided subject to the disclaimer at the end of this document.

Environment

Self Service Password Reset

SSPR 4.2.0.3

eDir 9.0.4
IDM UserApp 4.6
OSP Integration
SSPR Forgotten password module configured to allow unlock of intruder-locked eDir account

Situation

Error 5003 returned after answering passphrase questions in SSPR “forgotten password” module

5003 ERROR_USERAUTHENTICATED, simply means the user is already authenticated to SSPR.
User had previously authenticated to User App

Resolution

This is working as designed. The user getting the 5003 error had previously authenticated to UserApp, and the message just means that the user is already authenticated.

When SSPR is integrated with User App, OSP automatically logs the user into SSPR with tokens. Since OSP uses tokens it can authenticate the user to SSPR even if the user’s password became locked after the User App login.
Workaround:

Change the text shown on the “change password” button,and the text that goes with the button description in SSPR ConfigurationEditor, under Display Text – Display. Change the valuesfor “Button_ChangePassword” and “Display_RecoverChoiceReset.”







Additional Information

Steps to duplicate:

1. Configure SSPR for OSP integration
2. Login to User App
3. Using an incorrect password, attempt to login to eDirectory with the Client for Open Enterprise Server enough times to trigger intruder detection
4. Launch SSPR from User App, select Forgotten Password
5. Answer passphrase questions
6. Error 5003, “user already authenticated” will be returned

Disclaimer

This Support Knowledgebase provides a valuable tool for NetIQ/Novell/SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented “AS IS” WITHOUT WARRANTY OF ANY KIND.

Related:

  • No Related Posts

7023286: SSPR 5003 in Forgottten Password Module

This document (7023286) is provided subject to the disclaimer at the end of this document.

Environment

Self Service Password Reset

SSPR 4.2.0.3

eDir 9.0.4
IDM UserApp 4.6
OSP Integration
SSPR Forgotten password module configured to allow unlock of intruder-locked eDir account

Situation

Error 5003 returned after answering passphrase questions in SSPR “forgotten password” module

5003 ERROR_USERAUTHENTICATED, simply means the user is already authenticated to SSPR.
User had previously authenticated to User App

Resolution

This is working as designed. The user getting the 5003 error had previously authenticated to UserApp, and the message just means that the user is already authenticated.

When SSPR is integrated with User App, OSP automatically logs the user into SSPR with tokens. Since OSP uses tokens it can authenticate the user to SSPR even if the user’s password became locked after the User App login.
Workaround:

Change the text shown on the “change password” button,and the text that goes with the button description in SSPR ConfigurationEditor, under Display Text – Display. Change the valuesfor “Button_ChangePassword” and “Display_RecoverChoiceReset.”







Additional Information

Steps to duplicate:

1. Configure SSPR for OSP integration
2. Login to User App
3. Using an incorrect password, attempt to login to eDirectory with the Client for Open Enterprise Server enough times to trigger intruder detection
4. Launch SSPR from User App, select Forgotten Password
5. Answer passphrase questions
6. Error 5003, “user already authenticated” will be returned

Disclaimer

This Support Knowledgebase provides a valuable tool for NetIQ/Novell/SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented “AS IS” WITHOUT WARRANTY OF ANY KIND.

Related:

  • No Related Posts

7012569: How to reset the Filr Admin user password.

Do one of the following:

1) Either create a local user with a new password or use a existing user that you know the password for, then copy its password in the database to the password of admin. In order to copy/reset the password in the database, login to mysql from the server by typing:

mysql -uroot -p

<root password>

use filr

select name,password from SS_Principals where name=’admin’; (keep a copy of this for backup, just in case)

select name,password from SS_Principals where name=’desireduser’; (this should be the user you know the password for, save this)

update SS_Principals set password=’xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx’ where name=’admin’; (keep the single quotes, replace the xxxx with the saved password from the user above)

Reboot Filr after that change.

Or

2) Reset the password for admin back to the default, which was admin, do the following:

mysql -uroot -p

[Enter database root Password]

Use filr;

UPDATE SS_Principals SET password=’bc8f3945a1466d220df9c91b655fb864b2664421′, pwdenc=’SHA’ WHERE name=’admin’ and type=’user’;

exit;

Restart Filr Service.
Login as admin with password admin.

Related:

Re: Avamar Default passwords 7.5.1

Hi,

I am on Avamar 7.5.1 and my security team found a default password on the dtlt and I thought they had all be changed by my predecessors as this system is 5 years old.

However, they found a default password for Root. I was confused as I know that the password for Root has been changed as I came across a document stating that the default password is changeme and that is not what I use. I have since learned that there is another root account on the system and I need to get it changed, but the Admin guide makes me more confused on how to make this change that it does clearing the issue up.

What are the 2 root accounts defined as and how do I change the one and not the other account password?

After changing the password in Avamar, where else does that password need to be changed and how do I do that? (such as in DataDomain or the Proxies?)

Thank you for helping me with this “inherited” system.

-Mike

Related:

How to Enforce Password Complexity on NetScaler

  • > set system parameter Strongpassword (enableall/enablelocal) Warning: Strong Password now enabled. Please ensure all the existing user passwords adhere to this restriction. Minimum Password Length is set to 4 as default.

    Note: Command Strongpassword can have values enableall, enablelocal or disabled. By default it is disabled. If you want to force strong passwords for local accounts then we can set the value as enablelocal.

    After enabling strong password (enableall / enablelocal – not included in exclude list), all the passwords / sensitive information must have – Atleast 1 Lower case character, Atleast 1 Upper case character, Atleast 1 numeric character, Atleast 1 special character ( ~, `, !, @, #, $, %, ^, &, *, -, _, =, +, {, }, [, ], |, , :, <, >, /, ., ,, ” “).

    After enabling strong passwords for the appliance, make sure that you update the passwords to match the strong password criteria. Otherwise, users with weak passwords cannot access the appliance. To locate the weak passwords, in the shell, go to the “/netscaler” directory and run the “nsconfigaudit -weakpasswd” utility.

  • Related:

    VNX: Automated Failover Manager (AFM) Discovery failure with exit code 255 (User correctable)

    Article Number: 516752 Article Version: 3 Article Type: Break Fix



    VNX/VNXe Family,Automated Failover Manager

    Failure occurs when attempting to execute NAS Active/Passive Discover on AFM and the interpreter exists with exit code 255 as stated in the following example output,

    10.12.2017 16:18:58 – CMD >d:progra~1emcafm/emcadm2binemcadm.exe -f ua_getlun_file -s vnxrh03 -d d:progra~1emcafmtmpnasvnxrh03.getlun< with Return: 255

    10.12.2017 16:18:58 – CMD >d:progra~1emcafm/emcadm2binemcadm.exe -f ua_getlun_file -s vnxult03 -d d:progra~1emcafmtmpnasvnxult03.getlun< with Return: 255

    10.12.2017 16:18:58 – CMD >naviseccli -h 172.xx.xxx.xxx storagegroup -list -gname ~filestorage< with Return: 4294967295

    10.12.2017 16:18:58 – CMDL(53): IF_OK GOTO 55

    10.12.2017 16:18:58 – CMDL(54): EXIT

    10.12.2017 16:18:58 – Exit Interpreter.

    10.12.2017 16:18:58 – ====FINISH DISCOVER with exit code 255====

    Status > Discover is used to gather information about components such as file systems, storage groups, and RecoverPoint groups on the VNX systems in a NAS environment. It is also used to update changes in the configuration.

    Status > Discover runs Naviseccli commands to gather the stated information about the VNX systems based on a pre-existing user Naviseccli secure file that contains the access privileges for access to the VNX systems.

    Hence, the Naviseccli commands are run without the explicit specification of the username, password or scope, such as in the following example,

    • naviseccli -h <IP address> storagegroup -list -gname ~filestorage

    The failure occurs in case the user/password was changed for any of the two VNX systems and not updated in the Naviseccli secure file, or the Naviseccli secure file is unavailable, corrupted, or deleted.

    A potential change could be the expiration of the user security files, which normally occurs following an array code upgrade.

    In order to resolve this issue, the following should be checked:

    1. If the VNX user/password was changed
    2. If the user Naviseccli secure file is available and updated with the correct VNX user/password

    Once you confirm the correct access credentials for the VNX systems, you can run the following command via CMD on the Windows host on which AFM runs, in order to update the user Naviseccli secure file with the correct access credentials for the VNX systems,

    • naviseccli -addusersecurity -user <USERNAME> -password <PASSWORD> -scope 0 -address <IP ADDRESS>

    The command should be applied for the Control Stations and Storage Processors of both VNX systems.

    Related:

    Re: Changing SYSADMIN password on DD 620 running 6.1.1.5

    The access to BASH (shell-escape) is changed/hardened in DDOS6 and now requires a daily encrypted password to access BASH.

    The locking period will expire and allow another login but again this is hardened to prevent brute force password attacks.

    Depending on number of failed attempts, this could of course be a very long timeout now.

    BASH was never a method supported for use outside support for the safety of the system and user data.

    If you lost your sysadmin password and have another admin account then you will need to request support to assist by accessing BASH and resetting the password or the pam_tally for sysadmin for you – (if you know the sysadmin password you’re attempting is correct).

    No other user user (admin or not) can reset sysadmin password from admin/SE shell/user – as you say.

    HTH, Jonathan

    Related:

    • No Related Posts

    Client Login Extension 4.3

    Abstract:

    This is a patch for the Client Login Extension. When this patch is installed, the CLE version will be at 4.3.   It is a full build of the product. 

     

    Document ID: 5376511
    Security Alert: No
    Distribution Type: Public
    Entitlement Required: Yes
    Files:

    • CLE_4.3_19.zip (52.2 MB)

    Products:

    • Identity Manager 4.5.5
    • Identity Manager 4.5.6
    • Identity Manager 4.6
    • SecureLogin 8.5
    • SecureLogin 8.5.1
    • SecureLogin 8.5.2
    • SecureLogin 8.5.3
    • SecureLogin 8.6
    • Self Service Password Reset 4
    • Self Service Password Reset 4.1
    • Self Service Password Reset 4.2
    • Self Service Password Reset 4.3

    Superceded Patches:

    Related: