A problem with rsautil & jython used to automate user admin in SecurID
Years ago a predecessor of mine used a jython script to automate user administration on one of my SecurID systems and it has worked fairly well until recently. In the last few days it appears that the script still runs but it does not enable, disable or add users to the system. While it appears to try and do that no actual database changes are made.
My system is fairly up to date 8.6 px and the script has been working for months since the last update. My only change has been a bit of house cleaning of users. It certainly seems that there is some sort of permissions issue involved as no database changes get made but when I look at the script it does not appear to run as anything but the normal "rsaadmin". Since I often use rsautils for other admin tasks I know that it has to be "feed" a user/password combo via an amba.ini file however in the case of the jython script I can't see any such authentication - the command line is literally "rsautil jython script_name".
Does anybody know if any auth is needed for a jython script run by rsautil other than those from being user = rsaadmin & group = rsaadmin? I just wondering if in my zeal to houseclean I blew something away that I need.
There should be some set of credentials defined somewhere for running the jython script using the credentials of an administrator from the Security Console that has the permissions necessary for whatever operations you are having the script perform against the Authentication Manager database. Does the jython script reference an administrator or a "jython.properties" file in which the credentials for the administrator are defined?
Thanks - what you suggest makes sense but I have 1 working deployment and another that isn't working and while comparing "Administrative Roles" I really see no difference between the two.
Re: your question: "Does the jython script reference an administrator or a "jython.properties" file in which the credentials for the administrator are defined?" Sadly no - I can't see any such reference in the file or in its directory. There is a file called rsaenv in /opt/rsa/am/utils that ends with setting CLU_USER="rsaadmin" and exports that variable and some file path variables into the environment.
If it is indeed a permissions or user issue I am surprised that isn't logged somewhere - every time the script tries to make a change to the database and fails that should get logged somewhere but so far I can't find that info.
I agree with Rob, I've done jython scripts and they do have to reference a credentials file somewhere unless they're hard coded in the script (!). Even if it fails, the attempt should be logged in authentication activity or admin activity. Within Administrative Roles, do you show any assigned accounts that are locked or disabled? If the two systems are otherwise identical, run the job on the working one and see what admin account session is triggered in the admin activity log, then look at that same account on the non-working one.