Public Service Anouncement :)
Ever needed to get back a clear text Windows/UNIX account's password from a login object because nobody wrote it down anywhere else, and resetting it will cause major hassle?
With a large corporation and 50+ users who all manage their own login objects, that (sadly) happens to us more often than I'd like to admit ;)
After finding nothing about this so far, I'll describe a method below.
Disclaimers:
1. ensure that you are in fact allowed to recover the password in question
2. while this may appear like a security breach, this method is a consequence of the way UC4 works and by design, and is in itself not a security issue since database credentials are required, which should only ever be available to legitimate administrators, and
3. you will need to make a (albeit very limited and self-explainatory) temporary update statement to the SQL database, which is officially not supported by Automic. So keep this method to the desperate cases and, to stay supported by Automic at all times, I recommend you load any production data needed for this approach into a development system, then perform the needed write to the database on that non-production copy.
How does it work then?
Until at least Automic V9, the Job Messenger (aka "Jobmelder") on the agent machine could be used to decode and display any password from login objects. That's because the agent needs the password in clear text, and can be made to print it after decoding it. Phillip Elmer of former "Automic Blog" had a write-up of this.
As of AE 10.0, there appears to be a blacklist for the built-in login types. Any attempt to decode the built-in login types results in error U0020679. This, however, only counts for built-in login types. One can freely define ones own login types by populating the system variable UC_LOGIN_TYPES in client 0. See the help file for more on how to do this.
These custom-defined login types can have their password decoded by the pre-V10-method by design. However, to recover a Windows or UNIX password, one can not simply change it's type, because the UI will clear the password from the login object once you change the login type, as a security precaution.
What you can do, however, is create a custom login type, find it's ID from the OH table, and temporarily update the single line holding the one login you need to recover in the OLC table:
select OH_IDNR from OH where OH_NAME='MY.LOGIN.OBJECT';
update OLC set OLC_TYPE='MY_CUSTOM_LOGIN_TYPE' where OLC_OH_IDNR='<that number from above>' and OLC_HOST='<value_of_the_logins_name_column>';
commit;
Then, go to Automic and, without changing, saving or otherwise touching that login object, run a UNIX job (probably works with Windows, too, with minor to no modifications) to decode the elusive password:
:SET &LI# = GET_LOGIN(MY_LOGIN_OBJECT,THE_NAME,MY_CUSTOM_LOGIN_TYPE,LOGIN_INFO)
:SET &PW# = GET_LOGIN(MY_LOGIN_OBJECT,THE_NAME,MY_CUSTOM_LOGIN_TYPE,PASSWORD)
:PRINT &LI#
:PRINT &PW#
&UC_JOBMD CMD="echo Username: &LI# Password &PW#"
Your plain text password will be in the job report. Proceed to display the result of your magic trick to your astonished users, pretenting to have recovered the password by mind reading (this step entirely optional :)
Don't forget to undo the SQL update and set the original type. You can possibly omit this if you performed this on a dump of your db on a development system, which again, I am highly advocating.