Booches.nl

Outlook 2010 and Google Calendar Sync

I replaced my Outlook 2007 with Outlook 2010. Since I am using Google Calendar, I would like to sync my calendar with Outlook. With Outlook 2007 you can use the Google Calendar Sync application. After installing Outlook 2010 the synchronization of the calendar didn’t function anymore. While synchronizing you will receive the following error message.

Outlook 2010 is available for some time now, so I don’t understand why Google didn’t release a version of Google Calender Sync which support Outlook 2010. I searched the internet and found the following article on the Google Forum. The article describes how the replace the GoogleCalendarSync.exe with a modified executable. The modified executable can be found here.

Just close the GoogleCalendarSync application and create a backup of the current executable. Replace the current executable with the modified version and restart GoogleCalendarSync. Now you are able to synchronize your Google calendar with Outlook. As far as I have read the thread on the Google forum, this solution should work for 32-bit versions of Outlook 2010. The status for 64-bit versions is unknown.

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).

The 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.

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.

Since I had to renew a Server Authentication certificate, I choose the option Request a certificate.

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

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.

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.

I 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.

The 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.

VMware: upgrade VMware Tools and Virtual Hardware for Microsoft ISA array

Today I have been troubleshooting problems with a Microsoft ISA array. The array didn’t function anymore after moving the Configuration Storage Server and one array member from a VMware 3.5 environment to a VMware 4.0 environment. After moving the array member the VMware Tools were upgraded and also the Virtual Hardware was upgraded. After rebooting the moved array member the customer received multiple error messages, like duplicate IP addresses and users not able to access resource through the reverse proxy.

A Microsoft ISA array uses Network Load-Balancing and NLB was the cause of all problems. After upgrading the VMware Tools and the Virtual Hardware, NLB needs to be reconfigured. The complete configuration of NLB was lost. I reconfigured NLB (multicast with IGMP support) and the problem was resolved. The array members were functioning properly again.

Moving and upgrading the second array member resulted in the same problems with the same cause. Reconfiguring NLB on the second array member did the trick. So be careful when moving ISA array members with NLB configured from a VMware 3.5 to a VMware 4.0 environment, especially when upgrading VMware Tools and the Virtual Hardware.

Microsoft ISA publishing – it’s all in the “path”

I have installed multiple reverse proxy servers based on Microsoft ISA 2006. These reverse proxy servers are mainly deployed to publish services like Outlook WebAccess, PDA synchronization, SharePoint or regular websites. Services like Outlook WebAccess are published using secure session protected by SSL certificates. Microsoft ISA server uses “Listeners” to match and intercept traffic from public users.

I have seen multiple ISA publishing rules with only match traffic when the user enters the specific URL in the browser. Let’s take OWA as an example. When users would like to access OWA, they need to enter the following URL: https://webmail.booches.nl/owa. The base URL is webmail.booches.nl and users need to add /owa manually, because internally the Exchange server is configured with a virtual directory called owa. Sometimes I see Listeners configured for HTTP and HTTPS and all HTTP traffic is redirected to HTTPS.

Is this solution user-friendly? What happens when the users makes a typo and enters http://webmail.booches.nl/ower? I try to configure the publishing rules to be user-friendly and I always configure separate Listeners for HTTP and HTTPS traffic. When publishing OWA I configure 3 firewall policy rules.

1. 1. The first rule redirects all HTTP traffic (http://webmail.booches.nl/* to https://webmail.booches.nl/owa;
2. 2. The second rule intercepts all the OWA traffic (https://webmail.booches.nl/owa);
3. 3. The third rule redirects all HTTPS traffic (https://webmail.booches.nl/* to https://webmail.booches.nl/owa);

The first rule uses a Listener, which is configured for HTTP-only traffic and doesn’t use authentication. The firewall policy is intended for All Users and there is no authentication delegation.

	Action for HTTP and HTTPS redirect is to block the request and redirect the request to the correct URL for OWA
	The Listener for HTTP is configured without Authentication method and the rule is intended for All Users
	The public path contains /*

The second rule uses a Listener for HTTPS-only traffic and uses HTML Forms Authentication with LDAP, RADIUS or another authentication method. The associated firewall policy is intended for all Authenticated Users and uses authentication delegation based on Basic Authentication or Negotiate (NTLM / Kerberos) authentication.

	The Listener for HTTPs is configured with FBA as authentication method and the rule is intended for Authenticated Users. The authentication delegation is configured for Basic Authentication or Negotiate
	The public path configuration contains the appropriate Exchange virtual directories

The third firewall policy uses the same Listener as the second rule, but doesn’t use authentication delegation and is intended for all users. The configuration of the path, users and authentication delegation is the same as the first rule.

When you need to publish additional services, like ActiveSync or Outlook Anywhere, you have to add the specific publishing rules between the second and the third rule, so the redirection doesn’t mess up your publishing.

This setup is very user-friendly, at least that’s my opinion. The public user only needs to type the base URL (webmail.booches.nl) correct and he is always redirected to the OWA sign-in page. Service like ActiveSync or Outlook Anywhere are automatically configured to use the correct public path (/Microsoft-Server-ActiveSync or /rpc).