If you ever find yourself attempting to troubleshoot GroupWise mailboxes using IMAP and Trusted Applications, you will soon find that it can be a cumbersome process. You will also find that it's very difficult to actually find information that tells you how do be successful in your Trusted App login.
Why would you need this? Well, in my case I was troubleshooting an issue with a customer that uses Baracuda Archiving for long term message storage. It was having issues accessing folders in certain mailboxes, and from the GroupWise client we could not see any problems. So we needed to be able to login to numerous accounts, via IMAP, to determine exactly what the Barracuda archive was dealing with. Furthermore, I wanted to duplicate the process identical to how the Barracuda did, so I needed to login to IMAP with a Trusted Application.
The Trusted Application allows you to login once as a Global Administrator, then access mailboxes without having to know the credentials for each mailbox. This is extremely useful because users do not have to potentially compromise their credentials, nor do you have to talk to, schedule with, or interact with any actual users in any way. What a time saver. If you found this while googling, you may have found references to this process on other sites that are not exactly accurate. Meaning, you can try what they say and it just doesn't seem to work. But you don't really know why. They make assumptions, you make assumptions, and critical information is missing from their process. In the end, when I thought I was doing it right, I would receive the following error: "no XGWTRUSTEDAPP (D074)" Once I resolved the issue, I wrote this blog to clarify the issue for anyone else that may be struggling with the same thing.
Step 1: Obtain the necessary Trusted Application info
I am not going to tell you how to created a Trusted Application in GroupWise. It is beyond the scope of this article. That said, when you create the Trusted App, you give it a name. Then, you're either given a file with a text string, or you are provided with a string that you can copy to the clipboard (Depends on the version). But you need to have two things when you are done:
1) Name of the Trusted App, for example: CustomKey
2) Text containing a string of characters like this: 0F5B60810A780000B95764B02D3579E90F5B50820A780000B0534A45FB976AA1
If you are missing either of these, follow the path of least resistance and just create a new Trusted Application.
Step 2: Understand the IMAP Login Syntax Requirements
The syntax for logging into IMAP with the trusted key is a bit different than you would expect. It has two elements:
First, initiate the sequence: A002 AUTHENTICATE XGWTRUSTEDAPP
Second, supply the credentials sequence: XGWTRUSTEDAPP <ENCODED KEY>
The problem is, you have no idea what it means by the "Encoded Key". Where does this come from? Does it mean the long string of characters from when you created the Trusted App? Why doesn't this work when I try it myself? In reality, this will never work. It will always result in the D074 error. So what do you need to do to make this work?
Step 3: Overview of the Base 64 Encoded Key
What you have to do is manipulate the information from the Trusted App and encode it as a base 64 string, ensuring to follow Novell's required syntax. Then you provide that encoded string during the login process through IMAP.
In A Nutshell, The following Syntax is Required
Convert from Raw Data: <trustedAppName><nullCharacter><trustedAppKey>
Convert to Base 64 Encoded String: <Encoded Key>
Your Actual Data:
What you actually have to start with: <trustedAppName> and the <trustedAppKey>
Example: CustomKey and 0F5B60810A780000B95764B02D3579E90F5B50820A780000B0534A45FB976AA1 (Note that I excluded the NULL Character, primarily because you don't have it to st