Integration Broker Authentication: Invalid Authentication type (AUTHOPTN) for node PSFT_LM. (158,452)

by Apurva T. on July 16, 2013

in PeopleSoft Integration Broker

This issue “Integration Broker Authentication: Invalid Authentication type (AUTHOPTN) for node PSFT_LM. (158,452)” has been documented in Oracle Support as well with ID 1127403.1.

The reason for this error is that the two nodes are not able to talk to each other because of different authentication type (hint is in the error – Invalid Authentication type (AUTHOPTN)).

In my case, I was trying to setup messaging between HRMS and ELM. As the error suggested, the first check I did was to ensure that the authentication type is set to the same in both the instances. Here is the SQL I used.

select AUTHOPTN from PSMSGNODEDEFN where msgnodename IN (‘PSFT_LM’,’PSFT_HR’,’PSFT_FMS’)

I ran this SQL in both the instances and the output was slightly different. When I ran it in HRMS, all the values were ‘P’ whereas when I ran this SQL in ELM, the output was N,P,P.

You might be interested in knowing what these values are. N stands for “No Authentication”; P stands for “Password Authentication” and C stands for “Certificate Authentication”.

So, this error obviously is because PSFT_LM is set to Password Authentication in one instance and No Authentication in another instance. So, I needed to change the authentication type.

I went to Main Menu -> PeopleTools -> Integration Broker -> Integration Setup -> Nodes -> PSFT_LM and under the “Node Definitions” tab, I changed the authentication type to Password and also provided the Node password and the default userid as shown below.

Invalid Authentication type

I hit Save and went to the Connectors tab to test – Ping Node failed with the same result. Oops!

Also Read:  Duplicate Routing Error - Routing xxx already exists. Please select a unique name. (158, 2075)

The next query I ran was to check if the password is the same or not. I ran the below query in both the instances:

select ibpassword from psmsgnodedefn where msgnodename in (‘PSFT_HR’ , ‘PSFT_LM’)
In one instance, the result was
KsSF4tIfkTy0XwkTmwqu7rRfCRObCq7utF8JE5sKru60XwkTmwqu7rRfCRObCq7utF8JE5sKru60XwkTmwqu7g==
KsSF4tIfkTy0XwkTmwqu7rRfCRObCq7utF8JE5sKru60XwkTmwqu7rRfCRObCq7utF8JE5sKru60XwkTmwqu7g==
while in the other, the result was
KsSF4tIfkTy0XwkTmwqu7rRfCRObCq7utF8JE5sKru60XwkTmwqu7rRfCRObCq7utF8JE5sKru60XwkTmwqu7g==
bALBrDg0IzW0XwkTmwqu7rRfCRObCq7utF8JE5sKru60XwkTmwqu7rRfCRObCq7utF8JE5sKru60XwkTmwqu7g==
So, obviously, I messed up the password while setting it up. I set the password again to an unencrypted value of KsSF4tIfkTy0XwkTmwqu7rRfCRObCq7utF8JE5sKru60XwkTmwqu7rRfCRObCq7utF8JE5sKru60XwkTmwqu7g== and testing it again. The error got resolved!

{ 0 comments… add one now }

Leave a Comment

Previous post:

Next post: