NIMS and Hosting Multiple Domains on the Same Physical Box
Novell Cool Solutions: Feature
By Lynn Madsen
Digg This -
Posted: 11 Aug 2000
OK, here's the scoop on multiple domains, unique naming and other related topics with NIMS.
Q: Can NIMS support multiple domains on the same physical box?
A: Absolutely! See Heath's response below.
Q: Must user IDs be unique within a domain?
A: Yes (Duh!). You can't have two identical user IDs in the same domain. That results in duplicate e-mail addresses. I know this sounds basic, but, believe it or not we get asked this question far too often.
Q: Must user IDs be unique accross domains? In other words, If NIMS is hosting abc.com and xyz.com, can I have a user "john" in each domain.
A: Yes! Now, here's where it gets confusing so follow along closely. It's example time.
Let's start with an example of what many want to do which *will not* work because of NIMS design issues. It all comes down to performance. First the example, then, the answer to the question "why does NIMS not work that way?"
NIMS does not support the idea of "Context" domains. In other words, you cannot specify a context or contexts as equivalent to an e-mail domain and place all of the users that belong to that domain in the approriate context(s) as per the following example:
Context A (abc.com) | - john - joe - jack - fred Context B (abc.com) | - mary - michelle - melanie - martha Context C (xyz.com) | - john - joe - jack - barry - bob - ben - mary
Although it does appear that supporting such a structure, as logical as many of you think this might be (it looks logical to us as well), would be the preferred answer to the issue of non-unique user names across domains, it is problematic in two ways; performance and login procedure. From a performance standpoint, this approch would force all NIMS agents to "remember" the domain associated with the user and then figure out which context(s) are associates with that domain. Currently, since we assume the user name is unique, that is all we have to remember and there are very fast and very efficient NDS calls for locating a user ID.
This is not so with users and contexts. Performance would be severly impacted if we were to implement the model outlined above. We have considered doing this, we almost did it for NIMS 2.1. Neverthless, we came to the conclusion that we cannot reconcile the "convenience" of doing things this way with the complete redeign of NIMS agents and the resultant performance degradation. It's a tradeoff we are not willing to make.
The second issue is login procedure. Even if users logged in with the context, we would still have to "remember" the domain for that user in all NIMS agents. Today, NIMS has contextless login. We don't need to know the context since the user ID is unique. What Internet e-mail users understand the "context" issues of NDS? Do we really want to force users in a hosted services scenario to login as .contexta.john or .contextb.john? What happens if they are moved to a different context? There are just too many sticky issues in such a situation and it is harder to manage the contexts in such a scenario.
OK, so what does work and how? It is possible to host multiuple domains and have the same e-mail name in or more different domains.
NIMS 2.1 and above (all upcoming releases supports NDS user object names in "Internet e-mail address" format (See Figure #1 below). By allowing domains to be included in the user object name, NIMS can provide mail services to users in different internet domains who have the same user ID. For example, "bob", "email@example.com", and "firstname.lastname@example.org" can now exist in the same container or in different containers.
This allows you to organize users in contexts alphabetically, geographically, etc. without respect to the domain name. This usually results in fewer NDS contexts and ,thus, better overall performance.
[Root] | |- Context A |- email@example.com |- firstname.lastname@example.org |- email@example.com |- firstname.lastname@example.org | |- Context B |- email@example.com |- firstname.lastname@example.org |- email@example.com |- firstname.lastname@example.org | |- Context J |- email@example.com |- firstname.lastname@example.org |- email@example.com |- firstname.lastname@example.org |- email@example.com |- firstname.lastname@example.org |- email@example.com
Configuration Users whose object names include an '@' must provide their full e-mail address when prompted for a login name. Also, domains included in these object names must be added to the SMTP Agent Object's "Hosting Domain(s)" list. User objects that do not include domains in their names can still be addressed at any of the domains listed in the SMTP object's traditional "Domains" list. All domains and hostnames that resolve to the IP address of an SMTP Agent should be added to one of these two lists. NO domain or hostname should be added to both lists.
Periods must be "escaped" when creating such user objects in NWAdmin or Webadmin. The user firstname.lastname@example.org will be entered and displayed in NWAdmin as bob@xyz\.com.
- This feature should not be used on NetWare 4.x. Users with periods in their names will not be able to log in.
- Netscape Communicator's POP clients cannot be used with these users because they currently strip '@'s and trailing characters from user login names. Netscape Communicator (Messenger) will work with these users in IMAP mode only. However, the users names must be manually added in Preferences because the User Profile wizard strips the '@' sign as well.
- If NIMS is used with Novell Border Manager Authentication Services (BMAS), alias objects must be created for user objects with an '@' due to current limitations in BMAS.
- Because finger clients strip off the domain, only users that do not have an '@' in their names can be fingered. All other mail services are available to these users.
Of course there is always the Aliasing Agent method as well whereby each user has a unique NDS ID (john, johnj, johnc, etc.) and the e-mail addresses email@example.com, firstname.lastname@example.org and email@example.com are "aliased" to the corresponding NDS ID.
I hope this clears up some confusion that may exist with the handling of multiple domains and unique IDs with NIMS.
Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com