RSA Web Threat Detection (WTD) administrator is not able to create a new user in the administrative interface with the following error: value too long for type character varying(80)
Originally Published: 2016-04-28
Last Modified: 2023-10-06
Article Number
000064100
Applies To
RSA Product Set: Web Threat Detection
RSA Product/Service Type: Administration UI
RSA Version/Condition: 5.1.1.5
Platform: Linux
O/S Version: Red Hat Enterprise Linux 6.x
Product Description: Web Fraud Detection
Issue
The WTD administrator is not able to add a user in the administrative interface.  The following error shows in /var/log/messages: 
Apr  27 09:56:41 testWTD51 uiserver[13342]: [info] 0 [UpdateUser]: DB failure on UPDATE of users table : 
ERROR:  value too long for type character varying(80)
Cause
An added feature to 5.1.1.5 encrypts the user password in the Annotation Database. In order to do this, the variable characters for the password and prevpassword need to be increased from 80 characters to 120 characters. This is handled by the rpm-postinstall.sh script that will call the updatedb.sh to complete that task. This process doesn’t always complete as part of the upgrade. The reason for this is unknown at this point, but we believe it is due to permissions issues at the time of the upgrade.

When rpm-postinstall.sh runs, it will first change the pg_hba.conf to authentication method to “trust.”  This should allow for a user to run the updatedb.sh script to upgrade the database. The updatedb.sh script then will check for and implement the resize the column size in the users table for password and prevpassword from 80 to 120 characters. After the resize of those columns the script will do many other updates to the database if needed.

Resolution
Contact RSA support for information on how to manually change the column size in the PostgreSQL database.
Workaround
To fix this issue, we will need to have root SSH access to the server hosting AnnoDB. If we do not have root access then if we have the postres account credentials we may be able to make the change.
  1. Login via SSH to the AnnoDB server and su to postgres
  2. Login to psql with the command below:
# psql -p 7078 -d silvertail -U postgres

The password for the user is postgres and the default password is changeme.

  1. Start a transaction in the database and commit it if everything works:
BEGIN;

ALTER TABLE users
 ALTER COLUMN password TYPE varchar(120),
 ALTER COLUMN prevpasswd TYPE varchar(120);
  1. Check to see if the varchar has been updated to (120) for password and prevpasswd:
\d users
  1. If things look correct, as in the example below, then type the following command to finish the commands in step 3 to write the transaction block to the database:
COMMIT;
  1. If any error is given, or if the TYPE does not match what is shown in the example below, use this command to discard the changes:
ROLLBACK; 
  1. The code below is an example of the expected output:
silvertail=# BEGIN;
BEGIN
silvertail=#
silvertail=# ALTER TABLE users
silvertail-# ALTER COLUMN password TYPE varchar(120),
silvertail-# ALTER COLUMN prevpasswd TYPE varchar(120);
ALTER TABLE
silvertail=#
silvertail=# \d users
                 Table "public.users"
   Column    |            Type             | Modifiers
-------------+-----------------------------+-----------
 username    | character varying(80)       |
 password    | character varying(120)      |
 accesslevel | integer                     |
 created     | timestamp without time zone |
 lastlogin   | timestamp without time zone |
 prevpasswd  | character varying(120)      |
 expiredate  | timestamp without time zone |
 fails       | integer                     |
 locked      | boolean                     |
 tenantid    | character varying(200)      |
Indexes:
    "users_username_key" UNIQUE, btree (username, tenantid)
Referenced by:
    TABLE "user_preference" CONSTRAINT "user_preference_tenantid_fkey" FOREIGN KEY (tenantid, username) REFERENCES users(tenantid, username) ON DELETE CASCADE
    TABLE "user_role" CONSTRAINT "user_role_tenantid_fkey" FOREIGN KEY (tenantid, username) REFERENCES users(tenantid, username) ON DELETE CASCADE

Related Articles

Trending Articles

Don't see what you're looking for?