Archive for the ‘Security’ Category

Restore RSA 7.1 primary database and RADIUS config

A few days ago I was troubleshooting a problem with an ISA array after upgrading the VMware environment as you can read in this article. I had a same kind of problem with a RSA environment. After upgrading the VMware Tools and the Virtual Hardware, the RSA database didn’t start anymore. RSA noticed to much changes on the guest host, so we had to revert back to the “old” virtual machine.

To upgrade the VMware Tools and the Virtual Hardware I had to install a new server and restore the RSA primary database on the new server. The process for restoring the primary database can also be found in the RSA Administrator’s Guide.

There are two methods to restore the primary database:

  1. 1. Restore the database directly to the primary instance;
  2. 2. Promote a replica instance to be the new primary instance and restore the database to this primary instance;

I decided to use the first method, since we didn’t use a replica instance, and started installing a new server. I installed the new server under VMware. After the pre-installation I moved the server to another VLAN (port-group). I changed the hostname and the IP address of the new server to exactly the same hostname and IP address of the “live” RSA server. Next I installed a RSA AM7.1 SP2 primary instance with its default settings.

On the “live” RSA server I opened the RSA Operation Console to create a backup of the primary database (Maintenance – Backups – Create Backup).

rsa_backupThe backup process creates 3 separate files. This files need to be copied to the newly installed server. The *.dmp file is the file which contains the actual database configuration and is the most important. To restore the database on the new server, I had to take the following steps:

  1. 1. Remove all replica instances: Operations Console – Deployment Configuration – Instances – Manage Existing;
  2. 2. Stop all Authentication Manager Services on the server;
  3. 3. Restart the internal database: RSA Authentication Manager Database Server and RSA Authentication Manager Database Listener;
  4. 4. Open a new command prompt and change directories to %RSA_install_root%\utils;
  5. 5. Remove the primary database: rsautil setup-replication –a remove-primary;
  6. 6. Import the files into the database: rsautil manage-backups –a import –D –f absolute path, where absolute path is the absolute path and filename of the backup file, like C:\RSA_Backup\DB_Backup.dmp;
  7. 7. Reset the primary metadata: rsautil setup-replication –a set-primary;
  8. 8. Start the Authentication Manager primary instance;

The above steps help you restore the RSA database, but you still need to restore the RADIUS configuration separately. To restore the RADIUS configuration you first need to backup the RADIUS configuration from the “live” server. Creating a backup of the RADIUS configuration is very straightforward. You just need to copy the directory %RSA_install_root%\radius. To restore the RADIUS configuration on the new server, I had to take the following steps;

  1. 1. Stop the RADIUS server and make sure the RSA Authentication Manager is running: RSA Radius Server 7.1;
  2. 2. Overwrite the existing RADIUS installation directory with the backup data;
  3. 3. On the new RADIUS server, open a new command prompt and change directories to %RSA_install_root%\config;
  4. 4. Restore the RADIUS configuration: configUtil.cmd configure radius finalize-radius-restore;

The RADIUS server service is restarted automatically after executing the command above. After restoring the primary database and the RADIUS configuration you can shutdown the “live” server and change the network configuration (port-group assignment within VMware). The new server should be working directly. At least, it did for me.

If your configuration consists for one or more replica instances, you should perform the following steps for each replica instance:

  1. 1. On the primary instance, in the Operations Console, generate a replica package for all replica instances: Deployment Configuration – Instances – Generate Replica Package;
  2. 2. On the replica instance, in the Operations Console, provide the location of the replica package generated in the previous step;
  3. 3. On the replica instance, in the Operation Console, attach the replica instance: when the replica instance is successfully attached, all services on the replica are restarted;

If you use the On-Demand feature and you publish the RSA Self-Service portal via the reverse proxy solution, like a Microsoft ISA server, you should pay extra attention to the certificate chain configuration. The new server uses a different self-signed root certificate to sign the SSL certificate of the RSA Self-Service webpage. You need to import the new root certificate on the reverse proxy server and you should be ready to go.

Once I tried to restore the primary database with the second method (promoting replica to primary). This method wasn’t easy in my opinion and resulted in multiple error messages and an unsuccessful migration. I like the first method, because it is very straightforward and there isn’t a lot of downtime.

Windows LDAPS expired

A lot of appliances and/or security solutions use LDAP to synchronize users from an Active Directory or an eDirectory environment. Active Directory is LDAP enabled by default. If you would like to harden your network,  you would like to use LDAPS.

LDAPS is a term to refer to LDAP communication over SSL. Intercepted LDAPS traffic cannot be read easily by hackers. In an Active Directory environment you need to have at least one Certificate Authority (CA) to enable LDAPS. Windows uses Server Authentication certificates for the LDAPS operations.

Last week I had a customer complaining that people weren’t able to access their webmail via a Microsoft ISA reverse proxy. The cause of the problem was an expired Server Certificate on the specific domain controller. The reverse proxy server uses LDAPS to authenticate the user against an Active Directory. The following event log was found on the reverse proxy server.

ldaps-error To resolve the problem I had to renew the Server Authentication certificate on the domain controller. I decided to use the “Windows method” by using the Windows CA to renew the certificate. From the domain controller with the expired certificate I opened IE and enter the URL:

http://<IP address CA>/certsrv

This opens the Microsoft Certificate Services webpage of the CA. The following screenshots show the request and installation procedure for the certificate renewal.

01_request-certSince I had to renew a Server Authentication certificate, I choose the option Request a certificate.

02_advanced To request a Server Authentication certificate I choose the option advanced certificate request.

03_create-and-submit Normally I use OpenSSL to generate the certificate signing request, which is submitted to the CA. In that scenario I had to choose option 2. This time I decide to generate the csr via the webpage and choose the first option: Create and submit a request to this CA.

04_webserver The csr is generated with the information from the screenshot above. Because I had to renew a Server Authentication certificate, I choose the Web Server certificate template. The Name field is very important and should match the FQDN of the LDAPS server. It is also important to select the Store certificate in local computer certificate store option. This ensures that the certificate isn’t installed in the user’s certificate store, because the certificate cannot be exported with private key.

When you submit the certificate request, you have to wait until the request is approved. The approval has to be done by someone who manages the CA environment. If you open the CA MMC snap-in you will see one or more pending request. The pending request needs to be approved. After the request was approved, I browsed to the Microsoft Certificate Services webpage, like shown below.

05_status_pendingI choose the option View the status of a pending certificate request. Remember that I did the whole procedure on the LDAPS server to be sure that the certificate is stored in the servers local computer certificate store. The last step involves installing the certificate in the local computers certificate store. After the installation I always check the store to see if the private key is present for the certificate.

06_install_certThe renewal of the certificate is almost done. The LDAPS services depends on the process LSASS.exe. To “associate” the SSL certificate with the LDAPS server I needed to reboot the server. During the reboot the first valid Server Authentication SSL certificate within the local computer certificate store is used by the LDAPS server.

The reverse proxy server was able to use LDAPS again after the reboot of the specific domain controller.

RSA AM 7.1SP3 Token Delivery

Using two-factor authentication is common when publishing remote services to the internet with components like Citrix NetScaler or Juniper SA appliances. RSA is a well-known provider of two-factor authentication mechanism.

Beginning with RSA Authentication Manager 7.1 people have the ability to use the On-Demand feature. This feature enables the delivery of token codes via SMS or e-mail. When using this feature you had to publish the RSA Self-Service website to the internet, so users can request a token code. The RSA Self-Service website is displayed below.

rsa_self_service

The procedure for opening a extra website to request an On-Demand token is difficult to understand for many people and increases the risk of problems and errors during the authentication process.

This behavior is changed in RSA AM 7.1SP3. With SP3 the Authentication Agent has possibility to generate the On-Demand token request on behalf of the user. The procedure to login to the Authenticaton Agent is:

  1. 1. Browse to the portal website
  2. 2. Enter your user credentials (username + password)
  3. 3. Enter only the token PIN code
  4. 4. The Authentication Agent generates the On-Demand token request and redirects the user to a website to enter the On-Demand token code
  5. 5. The user waits for the delivery of the token via SMS or e-mail
  6. 6. The user enters the On-Demand token code on the Authentication Agents website
  7. 7. The Authentication Agent validates the token code and displays the web portal

This way the delivery of token codes is less prone to problems and errors during the authentication process. I personally like this new feature.

User expiration with RSA AM 7.1

I noticed some differences in the user expiration between RSA Authentication Manager 7.1 and RSA Authentication Manager 7.1 SP2. When assigning a token to an user in RSA AM7.1, the user automatically gets an expiration date set on its user account. The default expiration date is one year. I cannot reproduce this same symptom with RSA AM7.1SP2. When I assign a token to an user, the user doesn’t get an expiration date set. I prefer this behavior above setting an expiration date on the user. Setting an expiration date means extra administrative burden for system engineers.

RSA_expiration

When an user account expires, the user doesn’t have the opportunity to log in on an Authentication Agent. When using the Real-time Activity Monitor, you will see an error message for the specific user with the reason “Principal account expired”.

I configured the reporting functionality to generate reports on monthly basis to filter all user account which expired within the next X days. You can use the built-in template “Expired User Accounts” to generate the report. Next I created a scheduled report to run every last day of the month. This way system engineers can proactively monitor which user account will expire in the near future. One drawback from the scheduled report functionality is lacking the ability to send the report to an mail account. You have to log in to the RSA Security Console to view the reports.

RSA_report_expiration

Problem running ISA en IAS on the same server

Today I had some problems running ISA 2004 en IAS on the same server. At the beginning the customer was running ISA 2000 and IAS on the same server without any problems. By incident, the customer was forced to upgrade his ISA. They had a 2004 license, so ISA 2004 it was.

I noticed that ISA 2004 puts a “Default ISA policy” with the highest priority in the remote access policies. The rule blocks all RADIUS requests, so I had to manually remove the access policy. After the removal everything was working fine again.

I had to change the configuration in the ISA server again and the “Default ISA policy” came back in IAS. So I had to delete the rule again. I also tried to change the priority of the rule, but the “Default ISA policy” gets the highest priority again after applying a change in ISA.

I cannot find anything specific about this problem on the internet, so maybe someone experienced this before and can provide me with an answer to disable this behavior.

ISA Default Policy