Datastage 8.5 Authentication Issues

[ufl_developer]

I have searched the forums and could not find a particular answer for my issue, so here it goes. In addition to opening an SR with Oracle (who will have to probably open a PMR with IBM), I thought I would attempt to see if anyone has experienced this issue.


Host Info: Linux x86-64 Redhat 5.8
DataStage: 8.5 Server

I have installed DataStage per documentation on the box. In addition, after installation (and per documentation) I have switched the WebSphere portion to Local OS Authentication so the users/groups defined on the OS would be used. Last, I followed the steps to enable PAM authentication.

More background, we have service accounts on the box and we have Kerberos to authenticate our AD users, which is all done through PAM. So logging on directly to the linux box works great.

When logging into any portion of the DataStage (client or web), it cannot authenticate these users that are AD, but it does recognize the service accounts. The interesting part is we then adjusted the PAM to block all connections, and that doesn't affect the DataStage Authorization. This makes me believe it is not actually using PAM, even though the exact steps were taken to enable it.

From our SystemOut.log, which is located within the WebSphere directory for Datastage, we have noticed this message about authorization:

0000001f UnixRegistryI E SECJ0336E: Authentication failed for user ##### because of the following exception com.ibm.websphere.security.PasswordCheckFailedException: Authentication failed for user: #####

(where ##### is the actual username)


Any ideas or suggestions are appreciated, we have tinkered around with this for too long and it is starting to affect our deadlines. I have noticed a few comments on these forums that "you will discover some undocumented steps," with the authentication and I am interested if I am missing something.

Thanks!

[gsbrown]

We had a similar situation and it turned out that our distinguished names we set inside WAS security settings weren't the exact same upper/lower case as how it appeared in Active Directory. Once we fixed that, it worked! Review your settings again and be sure you're not also victim to case sensitivity.