Creating Fault Tolerance

Although LDAP authentication is a great authentication method, if you don't take measures to make it fault tolerant, your users can all be locked out of their GroupWise accounts. If the LDAP server you have configured for your user authentication goes down, the POA cannot authenticate users, and so users will not be able to access their mailboxes. The solution to this potential problem is called LDAP server pooling. The next section talks about how to enable LDAP server pooling.

LDAP Server Pooling

LDAP pooling allows you to define a second (or even a third) LDAP server for the POA to roll over to if the first one is not available for some reason. Here are the steps for doing this:

1.	Create a new LDAP server under Tools, GroupWise System Operations, LDAP Servers, just as you did earlier in this chapter. Take care to give the name of the LDAP server something slightly different from that of the first LDAP server you defined. For example, to be consistent with the naming standards at WorldWide Widgets, the second LDAP server is called LDAP2. The IP address (or DNS address) should be different from that of the first LDAP server, because, of course, you want this to be a totally different server just in case the server defined as the first LDAP server goes down or is not available to service LDAP requests. Be sure to add the CORPPO as one of the post offices that can use the LDAP2 server definition.
2.	Edit the post office object, and go to the Security property page. Click the Select Servers button and be sure to add the second LDAP server to the Selected Servers column, as shown in Figure 26.4. Figure 26.4. Selecting a second LDAP server Note From the Selected Servers column in the Select LDAP Servers dialog box, the order in which the POA will access the LDAP servers is based on the order in which the POA received the update of LDAP servers in its pool. The best way to view the LDAP pool state that the POA knows about is to access the POA's HTTP port. From there, you can click the Configuration tab, and then click the LDAP Authentication link. You will now see all the servers in the LDAP pool, as well as the state of the particular LDAP server. The LDAP server can be in a Starting, Good, or Bad state. Starting simply means that the POA has not really started to talk to this LDAP server. Good means that the POA has contacted this LDAP server, and Bad means that the LDAP server is currently down. If an LDAP server is in the Bad state, you will see a second counter that lets you know when the POA will refresh this LDAP server to see whether its LDAP services are available again.
3.	The LDAP Pool Server Reset Timeout value on the post office's Security property page governs how long an LDAP server is kept out of the LDAP server pool when the POA has determined it cannot obtain services from that LDAP server. You can adjust this setting to your liking; we prefer the default of five minutes.

Other LDAP Authentication Options

Let's take a deeper look at LDAP authentication in order to make an important point. The GroupWise POA identifies the user who is logging in based on the User ID the user fills in via the GroupWise client (be it the Windows, WebAccess, or wireless clients). In every user's record in the GroupWise directory (WPDOMAIN.DB and WPHOST.DB), there is a field called Network ID. There's another field that identifies the eDirectory tree the user is grafted into. These two values come from eDirectory based on the eDirectory object that the GroupWise account is associated with. The POA uses these values to indicate which eDirectory context to look into in order to authenticate the users.

Now that you understand the architecture, imagine that either your LDAP server is in another eDirectory tree, or your LDAP server isn't even a Novell eDirectory LDAP server. What do you do then? You have two options, as discussed next.

Option 1

Each user object has a field on the GroupWise Account page called LDAP Authentication. This field allows you to indicate a different context or fully distinguished name. For example, you could enter this:

CN=ECORNISH,OU=EMPLOYEES,O=FLATTREEORGANIZATION

The fact that you enter the location for the user in another tree means that the LDAP server defined to service this post office must also be in the other tree or LDAP directory.

Option 2

Leave the LDAP Authentication field blank, and make sure that the email address attribute in the LDAP directory matches the eDirectory's email attribute of the GroupWise user. You must then rename the LDAPX.NLM file found on the server where your POA is running and restart the POA. When you perform this step, the POA will not try to look up the eDirectory's distinguished name for the user, and because the LDAP Authentication field is blank, the POA will simply search against the LDAP server for the user's email address. If it finds an email address, it will then know the user's distinguished name, and will know how to authenticate to the other tree or LDAP directory as the correct user.

If you happen to have a workforce tree (an eDirectory tree created from another eDirectory tree via DirXML), and you want to use the workforce tree for LDAP authentication, refer to a Technical Information Document in Novell's Knowledgebase at http://support.novell.com. Search for the TID # 10067272 in the Knowledgebase search field.

This Technical Information Document talks about the details surrounding option 2. External eDirectory trees and DirXML are outside the scope of this book.

We have also used the LDAP Authentication field to associate the user's login credentials with a different eDirectory user object. For example, we wanted to have the user TKRATZER to authenticate with the user ADMIN's password. Here's what we did:

1. Edited the object TKRATZER.

2. Went to the GroupWise Account page for TKRATZER.

3. Entered the following in the LDAP Authentication field:

   CN=admin,O=americas

   
   

4. Now when tkratzer logs into GroupWise, he types TKRATZER as the user ID, and the password for the object ADMIN.AMERICAS in the password field.

So, why do this? We did it to prove it could be done. You'll have to think of under what conditions you might find this useful.