The following error appears in the ewaresystem.log when doing a mail merge:

2012-09-19T14:24:55 [Proxy] Error received from http://localhost:10009/crmj/$service/mailMerge?&originalHostCRMRedirector=localhost: The remote server returned an error: (401) Unauthorized.
2012-09-19T14:24:55 [Proxy] System.Net.HttpWebResponse


The customer had recently upgraded from an earlier version.

When you're doing anything in the CRM webapps that requires a user logon, you'll see a request going from the eWare DLL to the target webapp. It'll have the following header:

X-Sage-Authorization: Basic YWRtaW46VXJWZXJ5Tm9zeQ==

The hashed bit at the end is a base64-encoded username and password, something like admin:Password. When doing a mail merge, the current user's details are used. This isn't the case for the likes of the Exchange integration – for that, you enter a CRM user account that will be used for synchronising all accounts. But the principle's the same.

In this case, we were getting a 401 Unauthorized response from Tomcat, indicating that there was something wrong with the username/password. We could log into CRM using that user's details though, so at first look it didn't seem to be something wrong with the password as such.

The Tomcat webapps will only be able to decode the username/password if they're sent in one of two ways – either as plaintext (admin:Password), or if the password's encrypted using the current encryption scheme (admin: ^ILODMJEDLBGAJPPPLPMFBKKNGGGNAKAEKNPIDMJN). There's actually four different encryption schemes used for passwords in CRM, depending on what the passwords are to be used for.

1: ^ prefix. This is used for user passwords, like in the example above. If you save a user password in CRM, it will be stored like this in the database. This is the result of a one-way function, and cannot be decoded. When you log in, password that's been entered is hashed, and the result is compared to the hashed value stored in the database.
2: & prefix. This is an encrypted password, used in instances where you have to be able to return the plaintext password, and not just compare a hash. A good example of where this is used is in storing database connection details - we need to know the plaintext password so we can log in.
3: # prefix. Again, this is an encrypted password, but it is no longer used. It was used formerly for user passwords, but it's since been changed to the first scheme as it's more secure.
4: $ prefix. Encrypted password. No longer in use.

In this case, the customer hadn't changed their admin password in a very long time (presumably pre-6.1, the support team did not check back further), so it was using the third encryption method. This was fine for logging in, but this old method's not supported by the Tomcat webapps so an error appeared.


Changing the user's password resolved the issue.