Accessing GroupWise User Accounts



As a GroupWise administrator, I often get asked to access a user's account by his or her supervisor, for a variety of reasons (granting proxy access, looking for certain emails, opening a records request, etc.) and many times without that user knowing. For some time, the only way to access someone's account was to change their password. Of course, this would create problems for the target user when they tried to access their account again with a password that was no longer valid.


Since switching to LDAP Authentication for all GroupWise Post Offices, I've found a much easier, less intrusive way to access a user's account, without having to change their password. If you're not using LDAP Authentication, then this will not work.

To proceed, follow these steps:

1. Create a temporary eDirectory user. The actual login name can be anything.

2. Put the first and last name of the target user (the user whose email you are wanting to access) into the temporary user's First and Last name fields.

3. Assign a password to the temporary account.

4. Switch to the GroupWise View in ConsoleOne and browse to the target user.

5. Right-click his/her account and select GroupWise Utilities – GW / eDir Association – Associate Objects.

6. With 'Select Existing Object' chosen, click the Browse icon.

7. Browse to your temporary eDirectory user created in step 1.

8. Highlight the user and click OK. You will be prompted that the existing object is already associated with another object - proceed anyway.

This will reassociate the target user's GroupWise account with your temporary eDirectory user. Depending on your system's internet email format, with the first and last names filled in appropriately, it should also maintain the email address of the account during this operation so as not to deny any external email.

9. After allowing a few minutes for the changes to propagate, log in to GroupWise as the target user. You will use the target user's GroupWise USERNAME, but you will use the temporary eDirectory user's PASSWORD. Now you're in.

Once you've finished any necessary operations (finding email, granting proxy access, etc.), you'll need to reverse this.

10. Repeat Step 2 exactly.

11. Repeat Step 3, except when browsing for the existing object, select the target user's regular eDirectory account.

I was quite surprised to find how simple this solution is, and I have used it on many occasions to access user accounts on a supervisor's behalf.


GroupWise 7 using LDAP Authentication


How To-Best Practice
Comment List
  • Anyone ever seen this?

    Critical OS 08/13/2008 00:07 08/13/2008 00:07 1 Abnormal Program Termination (Abend: CPU Hog Detected by TimerRunning Process: Server 00:146)
    Critical OS 08/13/2008 00:06 08/13/2008 00:06 1 Fatal Exception (Number 14, Cause Abend: Page FaultRunning Process: Server 00:146Code executing in module COMN.NSS v3.25 at offset +3BC5Ch)

    Then the server reboots itself, I am running NW6.5 SP6 with GW7.03

  • in which case, about the only way is to use the Trusted Application API.
  • Is anyone aware of how an admin can access a user's account to authenticate for migration purposes without changing the user's password? Our LDAP may not be working/configured properly as the above suggestions did not work. We are utilizing IMAP for authentication for user-controlled spam management, etc.

  • in reply to MigrationDeletedUser
    In response to the earlier question - YOU are logged in as the user - if YOU make changes like open unread email, delete messages, forward messages, send messages, or anything that affects the status or contents of the mailbox the user can detect it (assuming they are moderately competent).

    It should be obvious to anyone that if a message they haven't read yet is marked as read that something strange is happening to their mailbox.

    If this is the case you may want to perform 'Hit-the-road' to make an offline copy that you can then peruse as necessary.

    -Jonathan Cauthorn

  • If you're using LDAP-Authentication you can use a password of another user:

    1. Go to In ConsoleOne, right-click the user object then click Properties.

    2. Click GroupWise > Account to display the Account page.

    3. Fill out the field "LDAP-Authentication:", use an Account with a known password i.E. "cn=admin,o=company,c=de"

    4. Click Ok/Apply

    Now you can use the password from "cn=admin,o=company,c=de" to login as the user...
  • When using LDAP authentication in GroupWise there is an even easier way to get access to a mailbox.

    Open ConsoleOne (with GroupWise snapins). Open the user account who's mailbox is to be opened. Click on the GroupWise tab. There should be an entry "LDAP Authentication". Just type in the name and context (in ldap format cn=jdoe,ou=mib,o=nsa) of a user (could be your own account or a temporary one) with a known password and apply the changes.

    Now you can log in to the mailbox that is to be opened with the password of the account that you specified in the "LDAP Authentication" field.

    When finished examining the mailbox remove the entry from the "LDAP Authentication" field and everything is back to normal.

  • Thanks for the post! This seems like the easiest way to accomplish that task.

    There are always ways to access users' email without their knowledge, this is just a simple way to do it. You can also use backup and restore, and probably a few dozen other methods.

    Usually email is corporate owned data. Admins should have full control over their systems, and if you have misbehaving admins it will usually come to light anyway.

    The only question that remains: "Who watches the watchers?"

  • What does the real user see while you have hijacked their email account? Will the real user notice anything or does the real user have to be out of GroupWise? Obviously if the admin opens, deletes, or makes other changes then when you put the account back, the real user will see those changes. Or if the real user is still logged into GroupWise, then will they see these changes being made in real time?
  • Great tip but this presents a security and/or privacy problem that, before now, GroupWise didn't have compared to other email systems. i.e What is there to prevent an admin level user from sending, reading, or modifying email for the CEO, CIO, HR Manager, etc. You would need to have some auditing mechanism in place with someone to do the auditing other than your admin people.

    A possible reason for NOT using LDAP authentication in GroupWise if you perceive this as a problem.

    - Tom Stone