Connecting Java and Teradata: The UserId, Password or Account is invalid

Question

I have been trying to connect to Teradata

Class.forName("com.teradata.jdbc.TeraDriver");
        String connectionString = "jdbc:teradata://xxx.xxxxxx.com/database=xxxxxx,  tmode=ANSI,  charset=UTF8";
        String user = "Rocket512";
        String password = "aui8mn5";
        Connection conn = DriverManager.getConnection(connectionString, user, password);

Got the following

  Exception in thread "main" com.teradata.jdbc.jdbc_4.util.JDBCException: [Teradata Database] 
[TeraJDBC 14.10.00.17] [Error 8017] [SQLState 28000] The UserId, Password or Account is invalid.
        at com.teradata.jdbc.jdbc_4.util.ErrorFactory.makeDatabaseSQLException(ErrorFactory.java:300)
        at com.teradata.jdbc.jdbc.GenericLogonController.run(GenericLogonController.java:666)
        at com.teradata.jdbc.jdbc_4.TDSession.<init>(TDSession.java:216)

I know that the host is specified correctly since i did not get UnknownHost Exception. Also I have double checked my userid and password are correct.

---

I ran query suggested by @beni23 (thank you)

select * 
from dbc.logonoff 
where logdate >= date '2013-10-31'

Here is the result that I got

What is Bad Password? I used SQL Assistant with this very password and it works great. Why cannot i connect with Java?

Answer 1

LDAP Authentication failures will not be captured in DBC.LogOnOff as a Bad Password event because the authentication doesn't take place on the database.

Typically the error message you are receiving, The UserId, Password or Account is invalid., is indicative of the user account being locked on the database.

SELECT U.UserName
     , U.ProfileName
     , U.DefaultAccount
     , COALESCE(P.MAXLOGONATTEMPTS, S.MAXLOGONATTEMPTS) AS MaxLogonAttempts_
     , U.LockedCount
     , U.LockedDate
  FROM dbc.UsersV U
  LEFT JOIN
       dbc.ProfileInfoV P
    ON P.ProfileName = U.ProfileName   
  CROSS JOIN
       dbc.SecurityDefaults S
 WHERE UserName = 'Rocket512';

If LockedCount is not 0 than a failed logon attempt has occurred since the last successful logon to the database.

If LockedDate is not NULL it represents the date which the account was last locked.

MaxLogonAttempts_ will tell you how many times you can attempt to logon using database authentication (TD2) before the account is locked.

A couple of things I would suggest:

1. Remove whitespace between the parameters of connectString
2. Put the User and Password parameters in the connectString
3. Using original code above modify the connectString to add: ,ACCOUNT=$AMRWRW&DrT&r which should match what is returned by the query in my response above (I have added DefaultAccount).

EDIT: 11/12/13 May I suggest you download Teradata Studio Express and attempt to make a connection to the same Teradata system using JDBC much like you are here in your code. This may help shed light on the parameters you need to specify in your connection string in order to make the connection successful. You should be able to setup your connection parameters in Teradata Studio Express the same as you have here in your code and see if it works.

Using LDAP as the logon mechanism for a user that has not been granted the explicit right to logon with a NULL password has resulted in the error message `The UserId, Password or Account is invalid.'. I received this the other day using a privileged account without changing my logon mechanism from LDAP to TD2.

What does the following SQL return?

SELECT *
  FROM DBC.LogonRulesV
 WHERE UserName = 'Rocket512';

It may not return anything, which is okay. This simply means you ability to logon with that userid from any host on the system has not been explicitly granted or revoked.

EDIT: 05/22/18 The “Bad Password” event for an externally authenticated user may will appear in the event log when the provided password and the what is stored on the directory server do not match. In certain scenarios you can verify this by using ldapsearch from the PDN to submit an inquiry directly to the LDAP directory. You can find more details about using this command in the Security Administration manual. I’ve discovered this trying to triage a problem with a subset of user accounts that fail to authenticate to the directory. I felt it would be appropriate to update this answer with more details as my lead in statement at the top is not 100% accurate.