Wednesday, December 18, 2013

Application user ID is not valid. errorCode=107

Sometimes, debugging issues with Policy Agent can be a pain (somewhere :>). So, I spent 2 days helping a customer remotely with his Policy Agent issue.

He just installed a IIS 7 Policy Agent and upon IIS starts, he always get the following error in agent debug log:

2013-12-17 14:36:47.919    Error 3076:2252 AuthService: AuthService::processLoginStatus() Exception message=[Application user ID is not valid.] errorCode='107' templateName=login_failed_template.jsp. 

2013-12-17 14:36:47.919    Error 3076:2252 all: ProcessRequest(): Agent intialization failed.

Isn't this error clear? -- "Application user ID is not valid".

My initial response was straight-forward - "You have not create an agent of the same profile name in OpenAM Administration Console. Go do it and you'll be able to resolve."

In the end, I found out that the agent was already created. The password was also correct (I was able to manually log-in to OpenAM console using the agent name and password).

A telnet from the IIS server to the OpenAM server was also successful!

Hmmm… very strange… However, when I tail the agent debug log and the Authentication debug log on the OpenAM server, something was missing.

The Authentication debug log never moved, even when I set the debug level to Message.

How can it be?

I then set all:5 on the Policy Agent side and debugged further. This was real verbose, mind you. I need to spend time tracing carefully.

We know that there are XML content passing around whenever the Policy Agent talks to a OpenAM server. Initially, I still could not find anything wrong with the configuration, until a few more rounds of restarting/testing later.


How come the XML content has the FQDN of the development OpenAM server? We are trying to connect to UAT OpenAM server, no?

Finally, I found out that the customer has mistakingly keyed in the IP address of the development OpenAM server into the /etc/hosts of the IIS server.

Network 101 - A telnet to the FQDN of the OpenAM server is not good enough. Is the IP address of the OpenAM server correctly pointing to the appropriate server?


1 comment: