RSA Authentication Manager 7.1 upgrade issue

Following on from my article on the SQL files bug in RSA Authentication Manager 7.1 we were looking to carry out the upgrade to the client’s server in a maintenance window last weekend however the engineer carrying out the work was unable to login to the Operations Manager console to carry out certain parts of the upgrade task.

It turns out that since RSA was installed the Security Console Super Admin account had its password changed and in the updated documentation we lost the details of the password for the Operations Console as the two passwords are not linked. In order for us to get back into the Operations Console we had to run through the following:

  1. Create a new Super Admin from the Security Console in the Internal Database
  2. Run the RSA command line utility (C:Program FilesRSA SecurityRSA Authentication ManagerutilsRSAutil) to create a new Operations Console user account

Unfortunately it wasnt that easy to complete!

Initially when we ran RSAutil as one of the admin accounts we received an error stating that only one account could run it, the account that originally installed RSA! Luckily the account was still listed and we just needed to enable this and perform a swift “runas” to bring up a command prompt as that user.

Next we sent a good bit of time running through various commands to work out how we create a new Operations Console admin account. The final command that we needed to run was as follows:

rsautil manage-oc-administrators -a create -u UserCreatedEarlier -p PasswordForUserCreatedEarlier -g OperationsConsole-Administrators NewOperationsConsoleUsername NewOperationsConsolePassword

We were now able to login to the Operations Console using the account we created. Now to find another maintenance window to patch the RSA server

RSA Authentication Manager SQL bug

As part of a planned reboot of our client’s infrastructure last month we had an issue with the RSA server taking a *LONG* time to come back up (were talking hours not minutes). After logging a call with RSA they pointed out that Authentication Manager 7.1 has an issue with cleaning up the .sql files it creates as part of its standard operation and this has been resolved in SP4.

The .sql files that are generated are all saved in C:WindowsTemp and are in the format DbMgmtSqlScript*.sql with 1 or two generated per minute on the server. The content of the files is as follows

Whilst waiting for approval to install SP4 on the server I was looking for a fix as the RSA server has generated over 64,000 files this month and I stumbled across the following article (http://microsoftplatform.blogspot.com/2011/04/rsa-authentication-manager-71-bug.html) which describes a nice batch file that can be used to clear out the .sql files on a daily basis:

That should carry out a workaround for the short term. Long term I would recommend that you install SP4 and Patch 4 which can be downloaded from the RSA website.

CheckPoint Full Disk Encryption and RSA SecurID800

I have spent the past week looking at a peculiar issue with CheckPoint Full Disk Encryption for a client. As a bit of a background all laptops are encrypted with Full Disk Encryption and to provide two factor authentication we are using the RSA SecurID800 which acts as a Smart Card as well as a one time authenticator.

Whilst provisioning a laptop for a new starter we re-used an existing token, issued the Smart Card certificate from our internal Certification Authority and it was added to the token successfully. After updating Full Disk Encryption from the MI Console we rebooted and tested login. Everything worked fine.

The issues came when we removed the old certificates from the token and suddenly Full Disk Encryption was showing “Invalid Logon – No certificates were found on this token” yet when in Windows the RSA software shows the certificate is there and the fingerprint matches what was picked up from Active Directory by the MI Console. Rebooted the laptop and still the same no certificates error.

Speaking with CheckPoint on the issue didn’t turn up much so I decided to issue a new certificate and try again. Went through the same process and upon reboot it worked fine and I put the original error down to a glitch so went and removed the old token from the SID800. Rebooted and it was broken again with the same error message.

To fix the issue I removed *all* certificates from the token, revoked all the issued ones in the CA and then issued one more for the user. All works fine and the user can now work on the laptop without issue.

Moral of the story… Remove all certificates first and then only add the one that you need. Its easier in the long run