IBM Support

Agent Service Interface authentication fails

Technical Blog Post


Agent Service Interface authentication fails


Even if it is rarely considered by end-users, Agent Service Interface (ASI) can be useful if you want to have information about agent itself,
situations delivered to the node or to make requests using XML.


When you access ASI, it asks to provide username + password, that are validated by the underlying OS security interface.
If the authentication fails, you are returned no error messages, but simply it shows again the input fields to provide USERID and PASSWORD.

For a case I recently investigated, despite the user/password pair was correct, authentication was failing.
The agent log showed errors like:


"Failed Agent server authentication, status 2085388311"

that is anyway a generic error returned by ASI for authentication failures.

After having set traces like:


the log file also showed this status code for the authentication failure:


(5B962477.0020-10:kbbac1i.c,260,"ACF1_Login") /opt/IBM/ITM/tmaitm6/lx8263/bin/kbbacf1 status was 139,0,0.


The three possible status that are returned by the module are:

Success                : 0,1,0
Authorisation Failure  : 512,1,2
kbbacf1 abend (sig 11) : 139,0,0


So in our case the authentication was failing for an exception.
Actually, looking at the dmesg we then noticed lot of segmentation fault caused by kbbacf1, entries like:

[3365395.270577] kbbacf1[2194]: segfault at 0 ip 0000000055820c6f sp 00000000fff8e79c error 4 in[556d8000+1c4000]

And core files were also created by the kbbacf1.
Further analysis performed using strace revealed that the exception was occurring because kbbacf1 was not able to open file
/etc/shadow, that is the one where OS stores the encrypted users passwords.
Access to this file was returning "Permission Denied".
After this failure, the authentication layer tried to use "SSS" process (as defined in nsswitch.conf file for a Linux env) but this was not fully configured and it led kbbacf1 to crash.

So we focused on the permission denied received when accessing /etc/shadow file.
In order to access this file, the process must have root authority.

By default, kbbacf1 file is set to have root owner and suid bit set.
This is required because even if the kbbacf1 is invoked by a non-root user, it must be actually executed as root.
This way it can read /etc/shadow successfully.

The "permission denied" we observed in our case was related to wrong permission bits and owner associated to kbbacf1 file.
It was configured with a non-root owner and without suid bit.

This is an acceptable configuration if you want to reduce the risk of privilege escalation in your server, as per:

but in this case you cannot use ASI.

If you need to access ASI, the kbbacf1 must have the following permission bits and owner:

-rwsrwxr-x 1 root mqm   6566 Nov  5  2015 kbbacf1

So you may need to:

1) change the owner back to root for file kbbacf1
2) set the suid bit for file kbbacf1 (chmod u+s kbbacf1)
3) Restart the agent

Using this setting, kbbacf1 will be able to access /etc/shadow file to authenticate the user you provided, even if it launched
by an agent process having no root authority.

Hope it helps





Tutorials Point


Subscribe and follow us for all the latest information directly on your social feeds:











Check out all our other posts and updates:

Academy Blogs:
Academy Videos:
Academy Google+:
Academy Twitter :


[{"Business Unit":{"code":"BU004","label":"Hybrid Cloud"},"Product":{"code":"","label":""},"Component":"","Platform":[{"code":"","label":""}],"Version":"","Edition":""}]