Unable to locate administrator user in the corporate directory
search cancel

Unable to locate administrator user in the corporate directory

book

Article ID: 44068

calendar_today

Updated On:

Products

CA Identity Manager CA Identity Governance CA Identity Portal

Issue/Introduction

You may be receiving the following error in Identity Manager's log when logging in via a Site Minder protected web server. If your front web server is Apache and specifically if it is SPS then keep reading:

 

2016-04-15 15:22:28,606 ERROR [ims.ui] (default task-43) com.netegrity.llsdk6.imsapi.exception.ImsRuntimeException: [facility=4 severity=3 reason=0 status=6 message=Unrecognized command] Unable to locate administrator user in the corporate directory 

at com.netegrity.llsdk6.imsimpl.securityengine.PolicyEngine.getAdministratorsTasks(PolicyEngine.java:1232) [imsapi6.jar:] 

 

Environment

Identity Manager 14.x

Cause

When Site Minder is fronting Identity Manager then Identity Manager relies on Site Minder to provide header variables that allows it to know who the user that's logged on is. This will allow Identity Manager to look up this user in its IME (Identity Manager's Environment) directory by the %USER_ID% so that it can then establish its admin roles and know why privileges it has in the application. These http header variables are: SM_USER and SM_USERDN.

 

There are a few things to check, first check that the Identity Manager's side seems okay, perhaps disable the Site Minder integration and confirm that by logging in directly to Identity Manager you get things to work. Then you can check the smps and SM trace log files to confirm the IsProtected, IsAuthenticated, IsAuthorized are returning 'SmYes'. If all that works then look in the smps for the evidence that these header variables are being sent:

 

[04/19/2016][12:29:46.060][12:29:46][6596][2100][Sm_Az_Message.cpp:825][CSm_Az_Message::FormatAttribute][s826/r172][xxx-xxxxxxxxxxx][][svc_idmadmin][][SAAS_IME_ims_realm][SAAS IMEDomain][][][][][][][][][][][][][SM_USER=svc_idmadmin][Send response attribute 224, data size is 20] 

[04/19/2016][12:29:46.060][12:29:46][6596][2100][Sm_Az_Message.cpp:825][CSm_Az_Message::FormatAttribute][s826/r172][xxx-xxxxxxxxx][][svc_idmadmin][][SAAS_IME_ims_realm][SAAS IMEDomain][][][][][][][][][][][][][SM_USERDN=uid=svc_idmadmin,ou=service_accounts,ou=unified,dc=DCExample,dc=ey][Send response attribute 224, data size is 75]  

 

This basically shows that the variables that Idenity Manager is expecting are being created accurately.

 

So then, why still not working?

 

The last piece is the mod_jk or jk_connector. This is a forwarding element that is installed into your web server and is running after the protection and work of the web agent finished and the path is clear. The purpose of this element is to forward the http call to the Identity Manager's jboss server. It is in this forward action that things can still go wrong. Especially we learned that if the proxy rule are set to 'redirect' and not to 'forward' you may have the problem explained above. You shall need to change the proxy rule to 'forward' - see instructions below.

Resolution

In your SPS or Apache:

  • Modify our Proxy Rule: 

    From: 
    <nete:case value="/iam/im/saas/"><nete: redirect >http://FQDN:8080$0</nete:redirect></nete:case> 

    To: 
    <nete:case value="/iam/"><nete:forward>http://FQDN:8080$0</nete:forward></nete:case> 

 

  • You also changed SPS from 'redirect' to 'forward' to unblock the problem with the header variables which seem to have been blocked on the redirect.  
Powered by Wolken Software