Directory Integration and Synchronization

In 1996 Novell shipped GroupWise 5.0. It was the first release that had totally been developed under the Novell umbrella (what we know as GroupWise 4.1 had been in beta as WordPerfect Office 4.0b when Novell purchased WordPerfect Corporation). The changes were not terribly huge from a user or basic structure standpoint. However, suddenly you needed to have NDS (Novell Directory Services, now just known as NetIQ eDirectory) to manage GroupWise.

GroupWise was only “loosely” integrated with eDirectory, and this caused no small amount of confusion for the next 18 years. Until Novell added LDAP authentication with GroupWise 6.5, there were truly no operational dependencies on eDirectory at all. In other words, you could set up a GroupWise system on Windows, for example, disconnect the NetWare servers, and so long as you never needed to add a user to your system, GroupWise would hum along just fine. It seemed like a lot of “overhead” to have GroupWise connected to eDirectory in a very loose way, and yet depend so entirely on eDirectory for configuration and maintenance.

GroupWise 2014 will be a welcome change for some administrators, and a vexing step back for others. At it’s very core, GroupWise 2014 has the right idea: Remove the dependency of a Directory from the GroupWise system, and yet allow for synchronization of data back and forth between GroupWise and a directory service if desired. So let’s look at the benefits and the disadvantages of this new way of GroupWise life. These pros and cons are based on the shipping version of GroupWise, and we expect to see many of the disadvantages addressed in future service packs and releases. As of today, here’s where we stand:

Pros:

  • GroupWise is no longer tied to eDirectory, so sites that have moved or are moving to an Active Directory environment can use AD for the authentication and integration if they choose.
  • GroupWise can be used as a totally standalone system for very small companies that use NO directory service for their access (and before you say they don’t exist, let us assure you they do!).
  • GroupWise management is no longer tied to management tools not under the control of the GroupWise engineers. Both nwadmin and ConsoleOne were developed by other teams at Novell, and GroupWise had to somehow “fit in”. Edicts such as “all Novell products will be managed by iManager” were unrealistic for a product like GroupWise, which being only “loosely” tied to eDirectory could not be properly administered with web based tools that could not effect direct access to the GroupWise databases.
  • GroupWise 2014 has a separate Management Console that is uniquely and purposefully designed to be the best “GroupWise” Administration tool without dependencies and limitations of being a snapin or part of a larger administration tool.

Cons:

  • At the time GroupWise 2014 ships, there will be no IDM driver available. Sites reliant on IDM for their GroupWise/Directory integration will be required to manage their systems with two sets of tools.
  • The iManager and MMC plugins for GroupWise are in their infancy, and provide only limited functionality (adding users to post offices, for example), and sites will be required to have two separate management tools for their networks.
  • GroupWise 2014 has a separate Management Console that is uniquely and purposefully designed to be the best “GroupWise” Administration tool without dependencies and limitations of being a snapin or part of a larger administration tool. Hey – wasn’t this listed as an advantage above? It’s one of those double-edged swords. This also means that sites who were accustomed to one tool being able to handle everything will suddenly be faced with the need for multiple administrative tools pertaining to GroupWise.

The good news though is that GroupWise administration will be totally controlled by the GroupWise development team, and ultimately limited only by their choice of REST as the engine for their management, and their own imaginations. The buck stops there.

When we talk about LDAP and GroupWise, there are really two issues at hand:

  • Directory Integration & Synchronization
  • Directory Authentication

These topics are not necessarily as straight-forward as you might think, so let’s discuss.

What is Directory Integration and Synchronization?

Generally when we think of GroupWise and Directory Integration, we think of eDirectory, because frankly that is the only directory that GroupWise versions 5.0 through 2012 are capable of integrating with. In order to explain Directory Integration in a wider sense, we will use eDirectory as our model.

In GroupWise 2012 and earlier, GroupWise users were by their very nature associated directly with an eDirectory object, either an eDirectory user, or a special GroupWise object called an External Entity. Most administrators never actually knew that it was even possible for a GroupWise user to NOT have an eDirectory association, unless something odd happened in the system, and one day a perfectly normal GroupWise user suddenly appeared in the GroupWise view with a “white shirt”.

Our figure below shows two eDirectory users who have GroupWise accounts (Red Shirts), one External Entity (Green Shirt – a GroupWise user who has a special eDirectory object that allows for no access to network resources other than GroupWise access), and one totally unassociated GroupWise user who has no ties to eDirectory at all (White Shirt). Prior to GroupWise 2014, having unassociated users was typically a “mistake”, but it did happen occasionally. Interestingly enough, the GroupWise user still functioned okay, so one wonders in retrospect why the External Entity was so important!

linuxinstall110.tif

A variety of GroupWise User Objects

If a disturbance in the Force were to happen, and the eDirectory connection with the GroupWise object was damaged (but not entirely deleted – i.e., the icon did not turn white), the object would become unmanageable – literally! You would receive an error like “replication may be in progress” or other strange error messages, and you would be unable to deal with things like changing user passwords, moving users to new POs, etc. You would first need to fix the “association” before you could continue.

In prior releases of GroupWise, there were eDirectory Schema Extensions available that allowed GroupWise specific objects to be referenced in the tree (Domains, Post Offices, Resources, Distribution Lists, etc.). Without these extensions, many GroupWise functions could not be properly managed in ConsoleOne. GroupWise 2014 no longer needs any Directory extensions to function. In fact, the only information that GroupWise “writes” to the Directory is the email address for users, via LDAP.

GroupWise 2014 takes away the “direct” eDirectory link, and relies instead on LDAP for all Directory integration functions. In this first iteration of GroupWise 2014, the directory types are limited to eDirectory and Active Directory. One can envision a day when OpenLDAP would also be supported, allowing GroupWise to be integrated into just about any networking system available.

During a GroupWise upgrade, assuming certain criteria have been met, your system will be automatically integrated with eDirectory (see”Preparing Your LDAP System” on page 14).

So, in a nutshell, when we speak of Directory Integration (at least in this guide) we are referring to the association between a GroupWise user and a user in eDirectory or AD.

If a user is properly integrated with a Directory (in GroupWise terminology we say the user is “associated” with a Directory), then the changes made in the Directory can synchronize to GroupWise through an LDAP connection.

Directory Rights Requirements

As you configure directory objects in this chapter, you will be asked for an LDAP user to use as the synchronization agent user. It is best practice to create a user specifically for this task.

eDirectory

In order to be able to Synchronize information from eDirectory to GroupWise, the account that you specify for the LDAP Sync must have Browse objects rights to users in the eDirectory Tree. There are also specific Attribute Rights that are required in order to Publish users’ e-mail addresses back to the directory. The LDAP account specified for syncing requires Read and Write to the eMailAddress and mail attributes.

Additionally if the System is upgraded from GroupWise 8 or 2012 the user will need read and write to these additional attributes.

  • nGWFileID
  • nGWGroupWiseID
  • nGWObjectID
  • nGWPostOffice
  • nGWVisibility
  • nGWAccountIDn
  • GWMailboxExpirationTime

Active Directory

In order to synchronize information to Active Directory, the LDAP account must have write rights to the mail and proxyAddress attributes in AD.

What Is Directory Authentication?

When Novell introduced LDAP authentication with GroupWise 6.5, it was seen as primarily a way to accomplish a couple of things:

  • Extend the functionality of GroupWise passwords to enforce password restrictions such as length and expiration policies.
  • Provide a single-signon solution for GroupWise users at all points of entry.

Administrators had long lamented that GroupWise passwords were too simple, and there was no way to force a user to change a password on a schedule. Additionally, while it was possible to allow users to avoid having to put in their password from their Windows workstation if the user was already logged into eDirectory, the GroupWise specific password was needed for WebAccess, IMAP and the like. Only the Windows client could benefit from a “single login” to authenticate to GroupWise. Additionally, because GroupWise passwords were separate from the eDirectory password, users frequently didn’t even know the GroupWise password if they were relying on the eDirectory authentication at the desktop.

Utilizing LDAP passwords for authentication solved both of these problems. Users only needed one password, the password length and duration could be defined by the administrator, and the GroupWise password itself became unimportant.

GroupWise 2014 still allows for either LDAP authentication or native GroupWise passwords for authentication.

You should not confuse the idea of LDAP authentication with Directory Integration and Synchronization. You can turn on LDAP authentication at the Post Office and not have any Directory Integration for the system. We’ve had many AD shops do just this in older versions of GroupWise. These sites used their AD LDAP server as their “Authentication” servers. It was not necessarily a simple setup. It required entering the LDAP login information in the LDAP Authentication field for each user. That said, it was possible even with older versions of GroupWise to use Active Directory as the authentication source, even though the users were actually “associated” with users in the eDirectory tree.

Launching the New Administration Console

First you must log into your Administration Console from your Web Browser. There was a link to the Administration Console at the end of your Primary Domain upgrade. You can also launch the Administration Console either by using the Icon on your Server Desktop (which is actually just a shortcut for your browser), or navigate directly to your Console by navigating to:

https://yourserver.com:9710

linuxinstall019.tif

The Administration Console Login Windows

Figure 5-3 shows the main GroupWise Administration Console screen. This is the default “Overview” or “Dashboard” view when you open the Administration Console.

linuxinstall095.tif

The GroupWise Administration Console Dashboard

We will discuss the Administration Console in more detail in the next chapter. For now we have some business to attend to with Directory Services.

The Initial Directory Integration

In “Preparing Your LDAP System” on page 14,we showed you how to configure your GroupWise system prior to upgrading to GroupWise 2014. During the upgrade of your Primary Domain, if your LDAP system is setup properly as described in the aforementioned sections, your new GroupWise 2014 system should be automatically integrated with eDirectory.

If after your upgrade you see a red box in the top right corner of the Administration Console, the likelihood is that your Directory Integration failed.

syncerror.tif

Initial Directory Configuration Error

We will look at how to correct this in “Correcting a Failed Directory Integration” below. First, let’s see how this looks if the initial Directory Integration is successful.

Let’s start by looking at our test system.

linuxinstall112.tif

GroupWise Test System

In this system, we have upgraded our GroupWise Primary domain to GroupWise 2014. This domain also has a GWIA and Post Office. We have a Secondary Domain that is still at GroupWise 8 version.

Click on Users, so that we can see what our users look like in our upgraded system.

linuxinstall119.tif

Users in our upgraded system

Compare this to another system below.

linuxinstall120.tif

Unassociated Users

If you look closely, you will see that there are two separate icons for GroupWise users. One indicates that a user is associated with a directory, and one indicates that the user is a “stand-alone” groupwise user.

linuxinstall121.tif

Unassociated vs. Associated Users

Since our system came from a prior version of GroupWise, which required eDirectory, you should only see the Unassociated icon if you had users in eDirectory that had lost their eDirectory Association (see the “White Shirt” in Figure 5-1 above).

NOTE: Even if your LDAP servers and eDirectory Synchronization was not properly configured before the upgrade, your GroupWise users will show an “Associated” icon. This can be misleading, and we will discuss that later in this chapter.

Associated Users

When we look at the General Details for an Associated User, we see the following:

linuxinstall128.tif

A user associated with eDirectory

Notice the LDAP information for the user

LDAP DN: cn=Mary,o=CNC

Directory: GODDESS

LDAP GUID: c8a7ee51-9f5c-4254-ac52-b16b56c64007

This information is read-only. The only information on this window that can be changed is the calendar publishing information. All other information, including phone numbers, physical address, department and the like are defined in the LDAP directory.

By contrast if we were to look at an Unassociated User, all information can be manipulated within the GroupWise Administration Console directly. Unassociated Users receive no information from any directory source. Thus, if you were to choose to dissociate your users from eDirectory and make them all Unassociated users, changes made in eDirectory (or Active Directory, if that is your Directory of choice) would not filter down to the GroupWise system. Very small systems with no need for either eDirectory or Active Directory would probably choose this method.

Unassociated Users

Below we see an Unassociated User.

linuxinstall122.tif

An Unassociated User has all information stored in the GroupWise System

Unassociated Users are managed entirely within the GroupWise Administration Console. All updates to user name, address, phone number, department and the like are entered directly into the GroupWise database through the Administration Console.

Non-Associated Users

In our chapter on”Preparing Your GroupWise System”, it was mentioned that if LDAP and eDirectory Synchronization are not properly configured in your pre-upgraded GroupWise system, the automatic Integration with eDirectory will not occur. This results in a special situation where the users are not Associated with eDirectory, and yet they also are not considered Unassociated Users. For our purposes in describing these users, let’s call them “Non-Associated”. Notice in our figure below, Giuseppe has the “Associated User” icon, and the information for Giuseppe is read-only in the General tab. Yet there is no LDAP DN and GUID information present. In this state, Giuseppe is somewhat in limbo. Changes in the Directory will not propagate to Giuseppe’s object in GroupWise, but the Administrator is also unable to edit the information directly. Giuseppe is stuck in a state between Associated and Unassociated. This is very similar to situations in ConsoleOne where you might attempt to edit a user object only to be warned that “replication” was in progress, and the user was not accessible. Certainly you can still do some routine maintenance tasks on this Non-Associated user. You can change the password, run GWCheck, create Nicknames, etc. You simply cannot change the “address information” typically found in the General tab.

linuxinstall123.tif

A Non-Associated User

We’ll show you how to fix synchronization issues such as this below.

The Directory Object

When we look more closely at our LDAP Servers in the sections below, you will note that there are two types of objects: The Directory and the LDAP Server. We’ll discuss those now.

The Directory Object (in our case in named Goddess) will represent either eDirectory or Active Directory, and is what we will call a “Master LDAP Server”. Many of the settings in the Directory Object will flow down to any additional LDAP Servers that are subordinate to the Directory.

The Directory is used for two purposes:

  • The Directory provides the facility to synchronize LDAP users to their GroupWise counterparts.
  • The Directory serves as an LDAP Authentication source for users logging into GroupWise using LDAP credentials.

When you verify or create the Directory objects below, you will be providing both of these functions to your system.

The LDAP Server Object

Subordinate to the Directory Object can be one or more LDAP Server objects. In our upgraded system, our LDAP Server, defined as CNC and listed in “Preparing Your LDAP System” on page 14, provides only Authentication Services. It is not in charge of any synchronization.

Controller servers. This can provide redundancy for your users to ensure that if one LDAP server is down, users can continue to log into GroupWise. However, since the Directory object itself is also an Authentication source, you really only need to define LDAP servers if you have more than one LDAP server that can server as an authentication source.

linuxinstall114.tif

Our LDAP System

For the rest of this chapter, we will be focusing on the following scenarios:

The likelihood is that you only need deal with one of these scenarios. We have duplicated a lot of the content so that you can read the section that pertains to you, and avoid a lot of jumping around.

If you goal is to remove eDirectory altogether and immediately either integrate your entire system with Active Directory, or remove all Directory Associations, there is little need for you to go through the steps of verifying or correcting your current configuration. You can skip down to the section that pertains to your situation.

Verifying a Successful Directory Integration

If you received no Directory Integration errors (shown in Figure 5-4 and Figure 5-5 above), we can assume that your Directory integrated properly. That said, we will want to verify the installation, and generally just show you how it should look. Also, we have seen instances where systems were set up for eDirectory synchronization properly, but had one or more domains not actually synchronizing. We’ll want to look at the system to make sure it is in order.

Verifying the Directory

First, click on System in the Administration Console. This choose LDAP Servers.

linuxinstall114.tif

Our LDAP System

Here our imported LDAP Directory and Server is from eDirectory. The name of the Tree is Goddess. We had defined an LDAP server in ConsoleOne and named it CNC. This information came over during the upgrade with no prompt for intervention. In other words, if the system was correct before the upgrade, it should be correct here. If you had issues with the eDirectory Synchronization prior to the upgrade, you will continue to have those problems after the upgrade!

Let’s look at our Directory named Goddess. Simply click on the name of the Directory to open the details page.

linuxinstall144.tif

Our migrated eDirectory “Directory”

The General tab of the Directory shows the tree name, Directory type (in an upgrade this will always be eDirectory) and the location of the Directory. Verify all settings here, enter the LDAP user password, and click Test Connection to ensure that the Directory is properly configured.

NOTE: If you come back to this screen at a later time to test, and the LDAP password is greyed out as in the figure, you will be required to put the password in again in order to complete a successful test.

The Base DN is the “starting point” for your LDAP search. A migrated Directory will not have any value listed in the Base DN. For synchronization purposes, this is not an issue, as the Synchronization queries a specific LDAP GUID to compare property values. However, if you will be authenticating via LDAP you will want to set a Base DN. In our example above, we have a very small tree, and users are in the “O” container. Larger organizations generally have OUs based on type of object, or company organization, etc. You do not want your Base DN too high in your tree, as that would require the LDAP search to look through too many records. By the same token though, you want to make sure that all user objects you wish to manage in this directory are found below this Base DN designation.

Note the Sync Domain. As with prior versions of GroupWise, it is really only required that one MTA be configured to do synchronization for the entire system. Choose the Domain whose MTA should perform the sync for this Directory. The MTA must have a Scheduled Event for Directory Synchronization enabled for Directory Synchronization to actually occur automatically. We will go through the steps to verify the synchronization in “Testing Directory Synchronization” at the end of this chapter.

The Directory is also serves as the default LDAP authentication source. Here you define the LDAP settings for your LDAP authentication. Click on the LDAP Authentication tab to see the current, migrated settings.

linuxinstall116.tif

LDAP Authentication Settings

We can also look at the Email Publishing settings here. Now that GroupWise has been decoupled from eDirectory, the only changes GroupWise ever makes to the directory (whether eDirectory or Active Directory) are related to the email addresses of your users.

linuxinstall117.tif

The Email Publishing Settings

You can change these settings to meet the needs of your organization. These settings are defined in System|Internet Addressing. You can modify them there for the entire system, or you can changed them here by clicking on the “Override” box and choosing the options you desire.

linuxinstall118.tif

Modified email publishing settings

You can choose to publish all allowed addresses, only certain types of addresses, even nicknames. The eDirectory email field is multi-valued and can accept more than one email address. If you are using the LDAP server to provide address lookup for a smart host (perhaps an anti-spam appliance in front of your GroupWise system), you would need to decide which addresses are allowed. In some cases, this is necessary in order to keep costs down. For example, if your anti-spam provider treats each email address as a “user”, danitaz, danita, danita.zanre, and zanre.danita could start to get expensive.

Verifying the LDAP Server

In Figure 5-14 under the Directory you also see our LDAP server (named CNC). When we click on the link for the LDAP server, we see the following window.

linuxinstall129.tif

LDAP Server Configuration

This is pretty straightforward. The contains the information for the LDAP server to which users will authenticate for access to GroupWise (if you have LDAP authentication enabled). You can create multiple LDAP servers here for failover and redundancy in case one server is down when a user attempts to log into GroupWise.

The Post Offices tabs lists each GroupWise Post Offices that will use this LDAP server as its primary authentication source. If this LDAP server is down, and other LDAP servers have been configured, the POA will step through the listed servers to find an available authentication source.

linuxinstall130.tif

Assigning Post Offices to LDAP servers for authentication.

These settings enable your LDAP server to be used as authentication for your users. However, to actually be in effect, you must activate it in the Post Office Security settings.

It is beyond the scope of this upgrade guide to discuss LDAP server layout and system design. Make certain that the servers you had defined in your former GroupWise system are correct and operational here.

Verifying User Associations

As we saw in Figure 5-10 above, when users are properly associated with the Directory, you will be able to tell readily by looking at the General tab for the user in question. It would, however, be tedious to look through every user in your system! We can do a quick check to see which users are integrated, and which (if any) are not.

First, click on Users in the list to the left. Now click into the search field (not Global Search) in the upper right.

Type in

directory=null

You will see a list of all unassociated users in your system.

linuxinstall132.tif

A listing of unassociated users

By the way, if you are curious, you can also type

directory=directoryname

Our Directory was named Goddess (imported from our eDirectory tree), so we could type

directory=goddess

and see the resultant user list.

linuxinstall133.tif

Listing of all users in our directory

In our case, upon further inspection, we found that in our eDirectory Synchronization in ConsoleOne, the CNC2 domain had not been configured for synchronization. Thus, those users have been brought into the upgrade GroupWise system in what we have termed “Non-Associated” states (this is not a Novell term, but we felt we needed a designation for these types of objects). It could be that you will have no users in this state. It could be that you will have many!

Depending on how many users you have who are unassociated, and where they reside in your system, you may choose to associate them en masse at the post office, domain or system level.

At the Domain or Post Office level, click on More and choose Directory Associations.

association.tif

Choosing Directory Associations

If you wish to do all of the users at once, go to System|Directory Associations.

Regardless of the method, you will next see the following screen.

linuxinstall140.tif

Accessing the Directory Associations

You may be asked for the LDAP password here.

Once you click Preview you will see the list of users that have been matched in eDirectory.

linuxinstall136.tif

Matched Users

If for some reason you did not want to associate a particular user, you could click on the “X’ to the far right of the name.

If you know or suspect that you have duplicate userids throughout your tree, double check that the proper GroupWise user is matched with the appropriate eDirectory user. If you see an incorrect association, click the X and make note of the user. You can associate this user manually after you finish the mass association.

Once you have verified all of the associations, click Associate.

At the Success window, click Close.

Earlier in Figure 5-12 we showed you our user Giuseppe Verde who was in what we’ve termed a Non-Associated state. If we look at Giuseppe’s details now, we see that he has an LDAP GUID and has been associated with our Goddess Directory.

linuxinstall138.tif

Our newly associated user.

Correcting a Failed Directory Integration

The very first time you logged into the Administration Console after upgrading your Primary Domain, you may have seen an error notification in the top right corner of the Administration Console. While this does not always mean that Directory Integration failed, that is the most likely scenario.

When you click on the red box, you will see any errors that are being reported by the Administration Console.

Initial Directory Configuration Error

This means that either you were unable to configure your eDirectory Sync on your prior system (for example, you are migrating from NetWare, or your Windows server is GroupWise 7 or earlier, or even your entire system is GroupWise 6 or earlier!). We will now go through the steps required to integrate your directory.

Verifying the Directory

In the Administration Console, go to System|LDAP Servers. Here our imported LDAP Directory and Server is from eDirectory. The name of the Tree is Goddess. We had defined an LDAP server in ConsoleOne and named it CNC. This information came over during the upgrade with no prompt for intervention. You will at a minimum see the eDirectory object after the upgrade, and if you had defined LDAP servers, they will be here as well.

  1. Our linuxinstall114.tifLDAP System

It’s possible that you will only see a Directory listed, as in the following figure.

  1. linuxinstall142.tifA Directory with no LDAP Servers

GroupWise systems that do not use LDAP Authentication, and were not set up properly for eDirectory Synchronization as per our instructions in “Preparing Your LDAP System” on page 14, will only have a Directory listed, representing the eDirectory tree where the GroupWise system resides. This of course includes all systems migrated from NetWare, as well as older systems that did not meet our minimum requirements in that section.

Let’s look at our Directory named Goddess. Simply click on the name of the Directory to open the details page.

  1. linuxinstall143.tifOur migrated eDirectory “Directory”

The General tab of the Directory shows the tree name, Directory type (in an upgrade this will always be eDirectory) and the location of the Directory. If your integration failed you may find that you need to fill out these details. Enter the IP address of your Directory, LDAP port and whether it is SSL. If SSL you will need to upload the SSL certificate for the LDAP server. See “Exporting Trusted Root Certificates” later in this chapter for information on exporting the trusted root certificate for this purpose.

The Base DN is the “starting point” for your LDAP search. A migrated Directory will not have any value listed in the Base DN. For synchronization purposes, this is not an issue, as the Synchronization queries a specific LDAP GUID to compare property values. However, if you will be authenticating via LDAP you will want to set a Base DN. In our example above, we have a very small tree, and users are in the “O” container. Larger organizations generally have OUs based on type of object, or company organization, etc. You do not want your Base DN too high in your tree, as that would require the LDAP search to look through too many records. By the same token though, you want to make sure that all user objects you wish to manage in this directory are found below this Base DN designation.

Note the Sync Domain. As with prior versions of GroupWise, it is really only required that one MTA be configured to do synchronization for the entire system. Choose the Domain whose MTA should perform the sync for this Directory. The MTA must have a Scheduled Event for Directory Synchronization enabled for Directory Synchronization to actually occur automatically. We will go through the steps to verify the synchronization in “Testing Directory Synchronization” at the end of this chapter.

Once you have all settings entered, click Test Connection. If all is well, you will receive a green banner at the top of the screen indicating success!

NOTE: If you come back to this screen at a later time to test, and the LDAP password is greyed out as in the figure, you will be required to put the password in again in order to complete a successful test.

The Directory is also where you define the settings for LDAP authentication for this directory. Click on the LDAP Authentication tab to see the current, migrated settings. While an LDAP server configuration in GroupWise 2014 is only required if you wish to use LDAP Authentication, the pertinent settings for how LDAP Authentication will be configured are in the Directory Object.

  1. linuxinstall116.tifLDAP Authentication Settings

We can also look at the Email Publishing settings here. Now that GroupWise has been decoupled from eDirectory, the only changes GroupWise ever makes to the directory (whether eDirectory or Active Directory) are related to the email addresses of your users.

  1. linuxinstall117.tifThe Email Publishing Settings

You can change these settings to meet the needs of your organization. These settings are defined in System|Internet Addressing. You can modify them there for the entire system, or you can changed them here by clicking on the “Override” box and choosing the options you desire.

  1. linuxinstall118.tifModified email publishing settings

You can choose to publish all allowed addresses, only certain types of addresses, even nicknames. The eDirectory email field is multi-valued and can accept more than one email address. If you are using the LDAP server to provide address lookup for a smart host (perhaps an anti-spam appliance in front of your GroupWise system), you would need to decide which addresses are allowed. In some cases, this is necessary in order to keep costs down. For example, if your anti-spam provider treats each email address as a “user”, danitaz, danita, danita.zanre, and zanre.danita could start to get expensive.

Verifying User Associations

As we pointed out in Figure 5-10 above, when users are properly associated with the Directory, you will be able to tell readily by looking at the General tab for the user in question. It would, however, be tedious to look through every user in your system! While it may be that none of your users are Associated, we’ve seen some instances where merely fixing the Directory server causes an Integration to complete when you save the Directory settings (you may receive a popup question asking if you wish to update the information for all users in the system). If you would like to check the state of your user integrations before attempting the Directory Associations, follow the steps below.

  1. First, click on Users in the list to the left.
  2. Notice the search field in the upper-right of the user list. Click into that field.

Type in

directory=null

You will see a list of all unassociated users in your system.

  1. linuxinstall145.tifA listing of unassociated users

Depending on how many users you have who are unassociated, and where they reside in your system, you may choose to associate them en masse at the post office, domain or system level.

At the Domain or Post Office level, click on More and choose Directory Associations.

  1. association.tifChoosing Directory Associations

If you wish to do all of the users at once, go to System|Directory Associations.

Regardless of the method, you will next see the following screen.

  1. linuxinstall140.tifAccessing the Directory Associations

You may be asked for the LDAP password here.

Once you click Preview you will see the list of users that have been matched in eDirectory.

  1. linuxinstall146.tifMatched Users

If for some reason you did not want to associate a particular user, you could click on the “X’ to the far right of the name.

If you know or suspect that you have duplicate userids throughout your tree, double check that the proper GroupWise user is matched with the appropriate eDirectory user. If you see an incorrect association, click the X and make note of the user. You can associate this user manually after you finish the mass association.

Once you have verified all of the associations, click Associate.

  1. linuxinstall147.tifSuccessful Association

At the Success window, click Close.

Earlier in Figure 5-12 we showed you our user Giuseppe Verde who was in what we’ve termed a Non-Associated state. If we look at Giuseppe’s details now, we see that he has an LDAP GUID and has been associated with our Goddess Directory.

  1. linuxinstall138.tifOur newly associated user.

Verifying the LDAP Server

While the Directory object is required to synchronize your Directory to GroupWise, and acts as an authentication source, the purpose of the LDAP Server is to provide redundancy as an additional authentication source for the GroupWise Client. It is technically not required if you are not using LDAP Authentication. That said, even if you have never used LDAP Authentication before, it is not a wasted exercise to verify and/or create an LDAP server for your system. If you have more than one LDAP server available in your network, you may wish to configure additional LDAP servers here.

  1. To create an LDAP Server for authentication, first click on System|LDAP Servers.
  2. If you have an LDAP server listed under your Directory, click on it to open the properties. If you do not have an LDAP server for authentication, click New LDAP Server.
  3. Fill in the information for your LDAP server. You may wonder why there is no authentication information here, but remember that was defined for the entire Directory in the Directory object.
    1. linuxinstall157.tifCreating the LDAP Server
  4. Click on the Post Offices tab and move all post offices that should use this LDAP server as their primary authentication source from the right to the left. If this LDAP server is down, and other LDAP servers have been configured, the POA will step through the listed servers to find an available authentication source.
    1. linuxinstall158.tifPost Office associations for LDAP Server
  5. These steps enable your LDAP server to be used as authentication for your users. However, to actually be in effect, you must activate it in the Post Office Security settings.

Once you have successfully associated your users, you can jump to “Testing Directory Synchronization” below.

Integrating Active Directory into Your GroupWise System

One of the new features of GroupWise 2014 is the ability to Integrate directly with Active Directory in lieu of, or in conjunction with, eDirectory. Some of the reasons for this might be your organization has moved to an AD environment and currently only uses eDirectory for GroupWise. Or you might have some users in an AD environment, and others in eDirectory, all sharing a GroupWise system. Thus, you may have a need or desire to associate some or all of your users to AD.

If you are moving immediately to Active Directory, and will not need eDirectory at all after your upgrade to GroupWise 2014, there is really little reason to follow the steps above to check and verify your integrations with eDirectory. If you will be moving users slowly to AD, then you should first ensure that your current eDirectory system is also functional by following the steps in the sections above pertaining to verifying your Integrations.

The first thing that must be done when planning an integration with Active Directory is of course to create the Directory Object in the GroupWise Administration Console. Follow these steps:

  1. In the Administration Console, click on System and then on LDAP Servers.
  2. You should see your current eDirectory tree listed as in the figure below.
    1. linuxinstall142.tifThe eDirectory listing
  3. Click New Directory
  4. Fill in the Directory creation window with information about your Active Directory LDAP server.
  5. If your Domain Controller LDAP server is enabled for SSL, you will need to export the certificate for importing into this Directory setup. See “Exporting Trusted Root Certificates” later in this chapter for details on how to accomplish this.
  6. linuxinstall182.tifClick Test to ensure that you have everything entered correctly

NOTE: If you come back to this screen at a later time to test, and the LDAP password is greyed out as in the figure, you will be required to put the password in again in order to complete a successful test.

  1. The Base DN is the “starting point” for your LDAP search. All users who should be managed by this directory must reside under this Base DN. You do not want your Base DN too high in your tree, as that would require the LDAP search to look through too many records. By the same token though, you want to make sure that all user objects you wish to manage in this directory are found below this Base DN designation. In our testing, the Base DN for Active Directory must be above the OU for your users. The query does not appear to look directly in the level of the Base DN.
  2. Choose your Sync Domain. This is the Domain whose MTA will perform Directory Synchronization for this Directory. The MTA must have a Scheduled Event for Directory Synchronization enabled for Directory Synchronization to actually occur automatically. You will test this Synchronization in “Testing Directory Synchronization” below.

We can also look at the Email Publishing settings here. Now that GroupWise has been decoupled from eDirectory, the only changes GroupWise ever makes to the directory (whether eDirectory or Active Directory) are related to the email addresses of your users.

  1. linuxinstall117.tifThe Email Publishing Settings

You can change these settings to meet the needs of your organization. These settings are defined in System|Internet Addressing. You can modify them there for the entire system, or you can changed them here by clicking on the “Override” box and choosing the options you desire.

  1. linuxinstall118.tifModified email publishing settings

You can choose to publish all allowed addresses, only certain types of addresses, even nicknames. With AD, the preferred ID is written to the mail attribute and the others are written to the proxyAddresses attribute as follows:

  • primary email address is written to the mail attribute, and also to the proxyAddresses as SMTP:user@domain (SMTP uppercase)
  • other email addrs are written as smtp:user@domain (smtp lowercase)

This can be viewed by going into the AD Users and Computers, go to View and select Advanced Features. Then in the user properties there is an Attribute Editor tab that will show all the LDAP attributes/values. Look for the proxyAddress line to view all Email addresses

If you are using the LDAP server to provide address lookup for a smart host (perhaps an anti-spam appliance in front of your GroupWise system), you would need to decide which addresses are allowed. In some cases, this is necessary in order to keep costs down. For example, if your anti-spam provider treats each email address as a “user”, danitaz, danita, danita.zanre, and zanre.danita could start to get expensive.

Associating GroupWise Users with Active Directory

You can Associate your GroupWise users with Active Directory users individually, by Post Office, by Domain or entire system. If you plan on associating a large number of users at once, it’s best practice to do the association procedure during a slow time on the network, perhaps evening or weekend.

Depending on whether your users were properly associated with eDirectory or not, you may have some or all of your users as Associate Users, Unassociated Users, or even our “Non-Associated” designation.

Associating Individual Users

If you choose to associate individual users to Active Directory, you must actually dissociate the user first, and then associate to the new directory (of course, if the user is not associated to eDirectory at this point, you only need associate the user to the new Directory).

  1. In the Administration Console, find the user. You can click into the Global Search field and type the user’s name to quickly access the user.
  2. Open the user properties and under More, click Dissociate.
  3. If the More button says Associate, then the user is not associated with any Directory. After the user is Dissociated, click More again. This time choose Associate.
  4. You will see the below figure. Make sure your AD Directory is listed, and browse the tree for the user.
    1. linuxinstall181.tifAssociating Individual Users
  5. Click OK to Associate.
  6. Now if we look at the General Tab for Mary, we will see that she is associated with the Cattivo (Active Directory) Domain.
    1. linuxinstall155.tifUser Associated with Active Directory

Associating Users En Masse

You can also associate users to Active Directory en masse. In order to do so, your GroupWise object id must match the AD samAccountName. Otherwise, the matching cannot occur.. If you wish to associate your users to Active Directory by post office or by domain, open the object in question, and under More choose Associate.

  1. association.tifChoosing Directory Associations

If you wish to make the change for the entire system, click on System and then Directory Associations.

You can make the switch in one step, rather than having to attempt to dissociate users and then associate them with AD.

  1. linuxinstall183.tifAssociate users to Active Directory en masse

The important setting for associating your users without first needing to dissociate them is to check the box that says “Override existing association”. This will allow users in any state (associated, unassociated, or even our special “non-associated”) to change to the new Active Directory association in one step.

After you click Preview, review the users and when you are ready, click Associate.

If you know or suspect that you have duplicate userids in your Active Directory Domain, double check that the proper GroupWise user is matched with the appropriate AD user. If you see an incorrect association, click the X and make note of the user. You can associate this user manually after you finish the mass association.

Creating the LDAP Server

While the Directory object is required to synchronize your Directory to GroupWise and act as the default authentication source for LDAP authentication, the purpose of the LDAP Server is to provide additional authentication sources for the GroupWise Client. It is technically not required if you are not using LDAP Authentication. That said, even if you have never used LDAP Authentication before, it is not a wasted exercise to verify and/or create an LDAP server for your system. If you have more than one LDAP server available in your network, you may wish to create additional LDAP servers.

  1. To create an LDAP Server for authentication, first click on System|LDAP Servers
  2. If you have an LDAP server listed under your Directory, click on it to open the properties. If you do not have an LDAP server for authentication, click New LDAP Server.
  3. Fill in the information for your LDAP server. You may wonder why there is no authentication information here, but remember that was defined for the entire Directory in the Directory object.
    1. linuxinstall159.tifCreating the LDAP Server
  4. Click on the Post Offices tab and move all post offices that should use this LDAP server as the primary authentication source from the right to the left. If this LDAP server is down, and other LDAP servers have been configured, the POA will step through the listed servers to find an available authentication source.
    1. linuxinstall158.tifPost Office associations for LDAP Server
  5. These steps enable your LDAP server to be used as authentication for your users. However, to actually be in effect, you must activate it in the Post Office Security settings.

Removing eDirectory Associations to become Stand-Alone

If you are planning on removing integrations from your existing eDirectory tree and turning GroupWise into a “stand-alone” system, the steps are fairly simple.

  1. In the GroupWise Administration Console, click on System, and then LDAP Servers.
  2. Check the box next to your eDirectory tree.
    1. linuxinstall148.tifPreparing to delete your Directory
  3. Click on Delete at the top of the window.
  4. You will receive a warning that this action cannot be undone (although it would not be a huge undertaking in the relative scheme of the Universe to recreate the Directory!).
  5. Click Okay.
  6. Click Users in the left pane of the Administration Console
  7. Voila! All of your users are now Unassociated.

linuxinstall149.tif

Testing Directory Synchronization

Once you have confirmed your Directory settings (whether eDirectory, AD or both), you can test to ensure updates are happening.

  1. Use iManager or ConsoleOne without any GroupWise snapins, or MMC if this is AD to change something that needs to synchronize to GroupWise. For example, a phone number.
  2. Go back to System and click on LDAP Servers.
  3. Click on the name of your Directory to open the details
  4. At the bottom of the window, click Sync.
  5. Go look at your MTA log (in verbose mode) and you should see a synchronization event.

17:51:03 18B8 Synchronizing Directory Goddess

17:51:03 18B8 Connecting to LDAP server at 192.168.110.192 for Directory Goddess

17:51:03 18B8 Checking CNC.Caledonia.Mary

17:51:03 18B8 Checking CNC.Caledonia.Robert

17:51:03 18B8 Checking CNC.Caledonia.RobRoy

17:51:03 18B8 Checking CNC2.Italia.Giuseppe

17:51:03 18B8 Checking CNC2.Italia.Leonardo

17:51:04 18B8 Update Telephone Number:720-319-7530

17:51:04 18B8 Disconnecting from LDAP server for Directory Goddess

17:51:04 18B8 Synchronization complete for Directory Goddess

Once you have verified that Synchronization is occurring, check your Scheduled Event to ensure that synchronization occurs regularly.

  1. In the Administration Console, click on Message Transfer Agents in the left column, and then click on the MTA for the domain you defined in your Sync Domain in the Directory configuration.
  2. Click on Scheduled Events.
  3. Regardless of whether you had eDirectory Synchronization configured before, you will no doubt have one or more NDS and/or eDirectory Synchronization events. Various version of GroupWise changed the events, even creating a new “eDirectory” event when the name changed, but leaving the NDS event behind. You can have multiple events configured here if you desire to have an update more than once a day. Or you can choose to delete any extraneous events you find here, and have only one scheduled event for synchronization.
  4. Click on the Event you wish to edit. The default for this event is 1:00 a.m. local time. Set it to any time you choose.
  5. If you wish to have synchronization occur more than once a day, you will need to create multiple events and set them for different times.
  6. Click Okay, and make certain that the event is enabled (checked).

External Entities

External Entities are interesting objects going forward. They cannot be modified in ConsoleOne without GroupWise Snapins. External Entities may be edited in iManager, and thus are “associated users”. However, there is no way to create new External Entities in iManager. Going forward, eDirectory synchronized users must be full eDirectory users, or be managed as unassociated users in the GroupWise Administration Console.

If you want to dissociate your External Entities and treat them as unassociated users, you will need to manage the dissociations one at a time. There is no method to mass dissociate at this time. In order to dissociate an External Entity, do the following:

  1. In the Administration Console, click on Users.
  2. Find the user in your list. External Entities are not listed separately. They will look like any other user.
  3. Click on the External Entities to view the properties.
  4. Under More, click Dissociate.
    1. linuxinstall150.tifDissociating External Entities

Exporting Trusted Root Certificates

iManager

To export your Trusted Root Certificate for a Linux server with iManager, see

https://www.novell.com/support/kb/doc.php?id=7013142

Instructions for ConsoleOne can be found at

http://www.novell.com/coolsolutions/tip/19360.html

Windows

SSL is not enabled automatically for LDAP on Windows. It is beyond the scope of this guide to design and configure SSL for your LDAP environment. We point you to this Microsoft TechNet document for guidance.

http://social.technet.microsoft.com/wiki/contents/articles/2980.ldap-over-ssl-ldaps-certificate.aspx

Directory Plugins

There are Directory plugins for eDirectory via iManager and Active Directory through Microsoft Management Console (MMC). The first iterations of these plugins have some basic functionality for adding users to GroupWise as they are added to the Directory itself. We expect there will be additional functionality as GroupWise 2014 and this new Administration Model progress. For now, here is how to install and utilize these plugins.

Installing the iManager Plugin

iManager Plugins are npm files. The GroupWise Plugin will typically be named GroupWisePlugins-.npm.

Download the npm file from download.novell.com or your Novell Customer Care Portal. Then follow these instructions.

  1. Log into iManager (for example https://192.168.110.210/nps/servlet/webacc).
  2. Click Configure at the top of the window
    1. linuxinstall195.tifAccessing Role Configuration
  3. Click on Plugin Installation
  4. Click Available Plugin Modules
  5. Click Add
    1. imanager-plugin-copy.pngAdding a new plugin
  6. Browse for the npm file you downloaded
  7. Click OK
  8. You will be returned to the plugin list. Find the GroupWisePlugins listing, check it and click Install at the top.
    1. imanager-plugin-install.pngInstalling the new Plugin
  9. After the installation is completed, click Close.
  10. You are instructed to restart Tomcat on your eDirectory server running iManager

For Linux, run

/etc/init.d/novell-tomcat6 start (OES)

or

/etc/init.d/tomcat6 start (SLES)

On Windows, click Start > Administrative Tools > Services. Then right-click Tomcat 6, and click Restart.

The plugin has been installed.

  1. Log back into iManager, then click the Configure button again (Figure 5-54).
  2. Select Role-Based Services > RBS Configuration.
  3. Notice that we have uninstalled modules
    1. rbs-role-install-select.png
  4. Click on the number under uninstalled
  5. Click on GroupWise and choose Install
    1. rbs-role-install.pngAdd GroupWise Module

After the module is installed, return to Roles & Tasks.

After the module has been installed, it must first be configured before it can be used. To do so, do the following in iManager.

  1. Click Users and then Modify User
  2. Browse to any user (Admin, your own – we’re not making changes, just activating the plugin).
    1. linuxinstall198.tifThe new GroupWise Tab
  3. When you click on the GroupWise tab for the first time you will see the following:
    1. error-no-config.pngNotice that the GroupWise Plugin is not configured
  4. Click on GroupWise Configuration above the error notice.
  5. Next you must fill out your LDAP server information for your tree.
  1. gw-config-success.pngLDAP Server Configuration
  • Enter GroupWise Admin Service URL: IP address or Host name of service
  • Enter GroupWise Admin Service Port: 9710 by default
  • Enter LDAP server ID: Directory Name
  • Enter GroupWise Admin Username: gwadmin (per our installation)
  • Enter GroupWise Admin Password: admin service password

Using the iManager Plugin

Now that your plugin has been successfully configured, let’s see how it works. We will create a new user, add the user to GroupWise, and then modify an existing user.

  1. In iManager Roles, click on Users and then Create User
  2. Create the User in the same way you create all of your users, including using any user templates, setting home directories, etc.
    1. linuxinstall199.tifCreating a new User
  3. You will be at the following screen. Click Modify (not OK).
    1. linuxinstall200.tifClick Modify at the Successful User Creation
  4. Click on the GroupWise Tab. Since this is a new User who does not belong to a GroupWise Post Office, you will see the following informational notice, and a dropdown for choosing the Post Office for the user.
    1. linuxinstall202.tifNew User who does not belong to a post office
  5. Choose the post office for this user. We’ll put Connor MacLeod in the Caledonia Post Office.
  6. You will receive a success notification, and the user is now in the Caledonia Post Office.

We can check this status by going to the GroupWise Administration Console. Follow the instructions in “Launching the New Administration Console” earlier in this chapter.

  1. Click on Users
  2. Find your user, in our case Connor.
  3. On the General Tab for Connor, you will see that he has an LDAP GUID and has been added properly to the Post Office.
    1. Our user, added from iManagerlinuxinstall204.tif

In addition to modifying a new user in order to add to a post office directly after creation, the only other functionality of the iManager plugin is to modify existing users who do not already have a GroupWise account. Simply follow the instructions above, but rather than clicking Create User choose Modify User. Find the User to Modify, and click on the GroupWise tab.

You will either see the window in Figure 5-13 above, and you can proceed to adding the user to a post office, or you will see the following, indicating that the user is already a member of a GroupWise Post Office.

  1. linuxinstall203.tifUser already belongs to a post office.

There is currently no other functionality of the GroupWise iManager Plugin. For example, deleting a user in iManager will not delete the associated GroupWise User.

MMC Plugin

The GroupWise MMC Plugin installation is launched from <installationfiles>\setup.exe.

Follow the instructions below to install the plugin.

  1. After launching setup.exe, choose GroupWise MMC Plugin,
    1. linuxinstall205.tifLaunching the MMC Plugin Setup
  2. Some redistributable runtimes will install. This can take a few minutes.
  3. When prompted, select your language for installation.
  4. Click next at the welcome screen.
  5. Accept the license agreement
  6. At the next screen you will see the installation options for the MMC plugin, which really are only whether you will actually install it, and the directory location for the installation. Click Next.
    1. linuxinstall206.tifCustom Setup Screen
  7. At the next screen click Install.
  8. You will be at the completion screen. Keep the “Configure” box checked in the lower left, and click Finish.
  9. At the next screen (you will configure your LDAP connection from MMC to the GroupWise Administration Service.
  1. configure-mmc.png
  • Enter GroupWise Admin Service URL: IP address or Host name of service
  • Enter GroupWise Admin Service Port: 9710 by default
  • Enter LDAP server ID: Directory Name
  • Enter GroupWise Admin Username: gwadmin (per our installation)
  • Enter GroupWise Admin Password: admin service password
    1. mmc-configure-test-success.pngSuccessful Configuration

Using the MMC Plugin

In MMC, create your user as usual. Once you have passed the Password page you will be presented with the Select GroupWise Post Office Dialog below.

  1. mmc-add-user-po.pngAdding User to Post Office

Once the user is added, you will receive a confirmation window telling you that the addition was successful.

  1. mmc-add-user-summary-gw-po.pngNew Object Added

We can check this status by going to the GroupWise Administration Console. Follow the instructions in “Launching the New Administration Console” earlier in this chapter.

  1. Click on Users
  2. Find your user, in our case bswan.
  3. On the General Tab for bswan, you will see that she has an LDAP GUID and has been added properly to the Post Office.
    1. mmc-users-add-success-gw.pngUser Successfully Added to GroupWise Post Office

Cleaning up eDirectory

At some point in the future, far enough ahead that you know that you will no longer need ConsoleOne for anything GroupWise, you can do some cleanup. PLEASE do these steps in iManager or a copy of ConsoleOne with no snapins. (If we could make a PDF flash a warning, we would now). If you are attached to a GroupWise domain in ConsoleOne when deleting these objects, ConsoleOne will attempt to delete the object in the GroupWise system itself, and not merely from the eDirectory tree.

There are many GroupWise Only objects that can be removed from your eDirectory tree when you are confident that you will no longer need them. A few months from now, when you are in a tidying mood, you can delete any of the following:

  • GroupWise Domains
  • GroupWise Post Offices
  • GroupWise MTAs
  • GroupWise POAs
  • GroupWise WebAccess Objects (more detail is given in the WebAccess chapter)
  • GroupWise Distribution Lists
  • GroupWise Resources
  • GroupWise Libraries
  • GroupWise External Entities