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 start with. I show you how to insert this below.)
Following Novell’s Syntax:
What they require: <trustedAppName><NULL><trustedAppKey>
Example: CustomKey<NULL>0F5B60810A780000B95764B02D3579E90F5B50820A780000B0534A45FB976AA1 (This is the string that will be converted to Base 64 Encoding)
Your End Result
What you need to end up with: <Base 64 Encoded Key>
Example: Q3VzdG9tS2V5ADBGNUI2MDgxMEE3ODAwMDBCOTU3NjRCMDJEMzU3OUU5MEY1QjUwO DIwQTc4MDAwMEIwNTM0QTQ1RkI5NzZBQTE=
(This example is based on the same Trusted App “CustomKey” and text string used above)
STEP 4: Perform the Conversion to Base64
The needed conversion to Base 64 Encoding does not happen automatically, nor can you do it with normal editing tools. I downloaded a utility called “Notepad++”. This was all I needed to perform the rest of the tasks. Notepad++ can be downloaded here: http://notepad-plus-plus.org/ You basically need a utility that can do the following:
* Properly insert a NULL character
* Properly Convert to Base64
How to perform the conversion using Notepad++
1) Start a new document in Notepad++
2) Enter the name of your trusted key. In my case, CustomKey.
3) Insert a NULL Character. To do this, enter two number Zero’s. Highlight both of the Zero’s.
5) This shows the result of the NUL Character insertion. Though it is difficult to read with the contrast, you can see the letters NUL with a black background:
6) Now paste the original Trusted App key into the document after the NUL character: (Click to zoom in)
NOTE: At this point you now have the string in the syntax form of <trustedAppName><nullCharacter><trustedAppKey>. You just need to perform a conversion of the entire string to base 64 encoding.
STEP 5: Login to IMAP using Base64 Encoded String
Once you have completed the conversion, you should save the file or copy it to your clipboard for use with Telnet. The following sequence would then be used to login with the trusted key:
**NOTE** The Encoded key that I use in the ACTUAL Screen shot below is different than what I used in the example used above. Trust me, I feel HORRIBLE about this, it’s one of my biggest complaints about step by step guides just like this. And here I am doing it to you. I apologize for this and despite the difference in the actual key, I hope that you can take this information and interpret it accordingly. Everything else is the same.
The sequence is as follows:
TELNET xx.xx.xx.xx 143 (Use the IP Address where IMAP is configured for GroupWise) A10 AUTHENTICATE XGWTRUSTEDAPP + XGWTRUSTEDAPP Q3VzdG9tS2V5ADYzNTZBNDAwMERFRTAwMDA5QTEzMUUwNUMwQzBCRDE0NjM1NkE0MDEwREVFMDAwMDhDNkUxQkZFQTUzOTAyNEQ=
On Success, you receive a response “OK XGWTRUSTEDAPP Authentication Successful”
(Click to Zoom)
Example of Incorrect Login Sequence
Below is an example of what happens when you don’t have the encoding or syntax correct when you try to login with the Trusted App.
TELNET xx.xx.xx.xx 143 (Use the IP Address where IMAP is configured for GroupWise) A10 AUTHENTICATE XGWTRUSTEDAPP + XGWTRUSTEDAPP 6356A4000DEE00009A131E05C0C0BD146356A4010DEE00008C6E1BFEA539024D A10 NO XGWTRUSTEDAPP (D708)
On Failure, you receive a response “NO XGWTRUSTEDAPP (D708)” In all of my testing throughout this process I have found that the D708 failure means the encoded string is incorrect and does not match the Base64 Encoding requirements as outlined above. Once I understood properly how to get the Base64 Encoded string, my issues were resolved and I could login successfully.