|Applies To||RSA 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)
|Issue||How to make Administration API work for RSA ACE/Server|
Error: "Daemon/Library or Demon/TCL mismatch"
|Cause||Sometimes when RSA ACE/Server Administration API programs fails, it is due to the environment not being correct|
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:
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 ID||a3576|