000018688 - How to make Administration API work for RSA ACE/Server

Document created by RSA Customer Support Employee on Jun 14, 2016Last modified by RSA Customer Support Employee on Apr 21, 2017
Version 2Show Document
  • View in full screen mode

Article Content

Article Number000018688
Applies ToRSA ACE/Server Administration API
RSA Authentication Manager
UNIX (AIX, HP-UX, Solaris)
Programs written using the Administration API available for RSA ACE/Server produce a variety of errors (where the actual messages are dependant on the application that has been written)
IssueHow to make Administration API work for RSA ACE/Server
Error: "Daemon/Library or Demon/TCL mismatch"
CauseSometimes  when RSA ACE/Server Administration API programs fails, it is due to the environment not being correct
Resolution

There are a few general areas where the environment for an Administration API program may fail:


 


1. The user running the program is not an ACE/Server administrator


 


This is straight forward - the requirement is for the UNIX username being used to be specified as an ACE/Server administrator. Running the command 'id'


 


will tell you what your UNIX username is, for example:


 


        # id


        uid=1001(adminuser) gid=100(ace)


        #


 


In this example a user should be configured in the ACE/Server with administrative privileges, where their default login name is set to 'adminuser'


 


NOTE: It may be that a SecurID protection has been set up for the admin program where 'SD_Logon' is being used. In the example program, the user is


 


prompted for their ID, but it should be noted that this is just an example. It may well be that your program will want to take your UNIX username and


 


prompt for a PASSCODE for this specific use. In the example program it is possible for you to run the program under a given UNIX username, but do a


 


SecurID authentication against a different name.


 


NOTE: The current documentation states that only the ACE/Server toolkit user is allowed to be the ACE owner - this is no longer true and future documentation will be corrected.


 


2. UNIX permissions stop part of the system working


 


There are two areas to watch out for with UNIX permissions. The first is the obvious one that the user needs to have standard permissions to be able to


 


run ACE/Server programs. This includes the ability to read the files with a '.r' suffix. The easiest way to manage this is to have a specific group


 


(such as 'ace') configured and change the group ownership of all the ACE/Server file. Then any person who will administer the ACE/Server (either via


 


'sdadmin' or the Administration API) can be added to this group.


 


Another useful tool is to run 'sdsetup -config'. This will traverse the directories of the ACE/Server and set all necessary permissions.


 


The second area relates to the need to write temporary files. A number of temporary files are generated when your API program runs. By default, the


 


system will attempt to write into your $VAR_ACE directory (see below); it may well be that you do not want everyone doing this (even if they are an


 


ACE/Server administrator). Under the section of the API manual entitled 'Directory requirements for Using the Toolkit' there are instructions on how an


 


alternative temporary directory can be specified.


 


3. One of a number of UNIX environment settings has not been initialized


 


A number of environment settings need to be configured (and exported). For more information, please see the solution entitled Setting up RSA Authentication Manager environment on UNIX for administration and Administration API programsSetting up an ACE environment on UNIX for administration and Admin API programs.


 


4. The ACE/Server brokers have not been started.


 


When an API program connects to an ACE/Server database it may do so in two ways,  firstly (and most commonly) it may use the Sd_ApiInit() function call to connect to a running ACE/Server and secondly it may connect to an ACE/Server database which is not running using the function call Sd_ApiInitSingle().  In both instances, the type of connection must match the environment of the ACE/Server.  If you wish to connect to a running (multi-user) ACE/Server then you must use Sd_ApiInit() and likewise if you wish to connect to a non-running ACE/Server you must use Sd_ApiInitSingle().

Legacy Article IDa3576

Attachments

    Outcomes