How long can a password be in IBM TRIRIGA?
There is no maximum password length imposed by the out-of-the-box TRIRIGA system. The encrypted password length is 500 characters. However, that encrypted length translates to about 125 characters.
[Admin: To see other related posts, use the Password tag.]
We are considering the disabling of the default System account for security reasons. We are currently protecting the account with a long strong password. Does anyone have any experience with this? Is this System account used in internal system processes where disabling it will not work or will wreck havoc on the system?
I don’t think you can “disable” the System account. Typically, what you have done already is as far as most people go. I’ve heard of one company having an executive type in the password and keeping the password secret until it’s needed for some justifiable reason.
Through the application or database, you could populate a random number which then no one would know. But I’d highly recommend taking a copy of your database before you start testing, changing the password, or anything else down that path. You could corrupt the database by trying to disable the System account.
[Admin: To see other related posts, use the Admin Group tag or Password tag.]
We are running TRIRIGA 188.8.131.52 platform and TRIRIGA 10.5 application. We have a requirement from our customer, for Sarbanes-Oxley (SOX) compliance reasons, that we need to change the “System” user password in TRIRIGA. We have done this in the past. However, the old option now appears to have become read-only, so we can’t do it the same way. Any ideas how we can update this password now?
Here are some things that might be preventing you from updating the password:
- 1. The logged-in user does not have security access to update the password, or a workflow has triggered on the record that has modified the metadata, and made the password fields or its section non-editable.
- 2. The record is in a state that only supports read-only actions. This makes the record non-editable.
- If you are logged in as Admin and cannot modify the password, I’d confirm that the System user is still part of the Admin group.
- If you are trying to change the System password as another user that is not an Admin, I would put that user in the Admin group temporarily to see if this gets past your issue.
- If you can confirm that a user in the Admin group cannot modify the record, I would look at workflows that are changing the metadata and the record state.
- If you cannot access the account as the System user, you can temporarily clear the System password to blank (null), so that you can login as Admin and reset the password. For example, via an update SQL script:
- update user_credentials set password = null where user_account = ‘system’.
[Admin: This post is related to the 04.18.16 post about resetting a user’s password as an administrator. To see other related posts, use the Password tag.]
IV95219: Section 508 compliance for TRIRIGA login page
Visually impaired users dependent on Section 508 compliance to use TRIRIGA may run into a problem in the login page. They might have difficulty in navigating to enter the ID and Password.
IV95289: Section 508 compliance in Projects page
Keyboard access, style sheet dependence, language, page titles, and images for Section 508 compliance fail test on Projects tab.
IV95290: Section 508 compliance in My Reports page
Keyboard access, web forms have invalid HTML, web links, and user controls. Images have no description in plain text.
[Admin: This post is related to the 10.17.16 post about multiple APARs on Section 508 compliance.]
We are encountering an odd issue with TRIRIGA SSO and Active Directory with Personal Identity Verification (PIV) cards for authentication. The issue occurs after a session timeout, when a Windows Authentication dialog box would prompt a user to enter either their pin code or their Active Directory login, in which the Windows security does not accept their credentials, even though the right pin code or username/password is used…
Upon clicking on the Cancel option in the Windows Authentication dialog box, a second window with a “401 – Unauthorized Access” error is displayed to the user with a link that allows the user to regain access to the REMS application. We do not see any significant errors regarding authentication on the TRIRIGA side. At this point, I am not sure if this is a IIS, Active Directory, or a TRIRIGA configuration issue, but any suggestions would be great…
The issue is that the user’s old session on the app server is invalid, and the app is passing a 401 header back through IIS, and onto the browser. The solution is to tell the app server not to send the 401 header. In TRIRIGAWEB.properties, set:
This change in functionality was an enhancement made in TRIRIGA 3.5.2.x The change is not in 184.108.40.206… So, the options for you right now are to test out 3.5.2. In 3.5.1 and below, enable the session expiration warning setting and extend the session timeout in the web server to something like 8 hours (normal working day):
After a successful login to TRIRIGA, Oracle reports “invalid username/password” messages to the server.log. The TRIRIGA application authenticates and lets the users in, but while using the application, they will get a MID error on-screen that correlates to an Oracle message in the logs indicating “the account is locked” (ORA-28000). This can be tracked back to another Oracle message indicating an “invalid username/password” (ORA-01017).
The repeated “invalid username/password” messages caused Oracle to lock the account. This can be resolved by utilizing the following links:
[Admin: This post is related to the 05.13.16 post about the “Invalid Username or Password” with WebSphere.]