Planning for Active Directory Partitioning
.gif) Note: |
|---|
|
We recommend that you maintain all virtual organizations in a single forest and domain.
|
Active Directory partitioning is implemented by creating separate OUs for each virtual organization or group. Each organizational unit will contain the segregated users, distribution lists, and security groups to restrict or grant access to Active Directory appropriately.
As with any Active Directory design, it is important to insure minimized risk of unauthorized data access. With this design, the risk increases with the use of Internet access and partitioning security. Some risk is due to the fact that Exchange uses the Internet as a primary connection point. If a segregated user is allowed to log on, it has additional methods for accessing the GAL (GAL). Security groups contained within the OUs provide the partitioning security context for the segregated users. These security groups contain only those users who require rights to that specific OU. For example, all users will be restricted to the company's OUs within Active Directory. Some of those users may also be granted additional rights to create new objects (users).
After Exchange is configured to allow access, a security risk is inherent in the creation of new objects. Documented processes must be followed, either manually or programmatically, to ensure that appropriate security is applied to each object. Objects without the correct security context may be able to access objects outside the segregated boundaries. For example, users from one segregated group could potentially have access to user information within another segregated group.
Option 1
Locate all segregated groups in a single forest within a single domain and use OUs to partition each group's users. The advantage of this architecture is that hardware requirements are reduced since all segregated groups are located on the same physical hardware. This option is easy to manage with a single administration process, and is scalable.
A disadvantage of this design is the risk of one segregated group's unintended access to another group's data should the documented permission processes not be followed.
An issue to consider is that Windows Server 2003 adds users and administrators to a default set of security groups, such as the Domain Users group. Disallow this to prevent users from having access to domain resources, such as printers. This will not prevent you from allowing users and administrators to access resources found only in Exchange.
Option 2
Locate all segregated groups in a single forest with multiple domains. Each segregated group stores user data in a separate domain, and the global catalog would provide information from the directory.
A disadvantage of this architecture is cost. Locating each segregated group in a separate domain requires at least two domain controllers per segregated group and you must still implement processes to prevent the issues detailed above with the single domain method. Because security settings and defaults apply to a domain, the impact of a user being added to a Windows Server 2003 security group, such as Domain Users, is limited to the segregated groups in that domain.
Option 3
Locate each segregated group in a separate forest partition where each group's users are located in a separate Active Directory schema. An advantage of this method is minimal risk of inadvertently giving one segregated group access to another group's data. Distributing services across hardware offers other advantages. In the event of a failure, you can continue to provide services to other companies while restoring services to the affected company.
A drawback of this design is cost. To locate each segregated group in a separate forest requires at least two domain controllers per group, separate administration processes, and disaster recovery equipment. You will also have to manage each and every forest as a completely separate entity. This approach is generally not practical because of the additional hardware and administrative cost.
Global Address List Configuration
Active Directory contains a database of all users. The practical implementation of this database, when accessed from an Outlook client, is referred to as the Exchange GAL. When segregating Exchange, if user searches this list, you want to limit the results to recipients in the same segregated group.
This partitioning of the GAL is provided by access control lists associated with global group memberships. For each organizational unit containing a segregated group, a global group must be created. The global group membership is the users of the segregated group located in the OU. Use this group, together with other permission changes, to provide a view of Active Directory specific to the segregated group located in the organizational unit.
When partitioning the GAL, you must remove the existing default rights to see all users and objects within Active Directory. To accomplish this task, you must remove from each organizational unit the permissions assigned to the Authenticated Users group and the Everyone group, if it exists.
The host company requires permissions to see all objects within Active Directory. Add rights for the security group for each segregated group's users, thus allowing the users to see other users in their own organizational unit. Go through each organizational unit and add a security group for that segregated group. For example, for the organizational unit representing Fabrikam.com, add the Fabrikam Users security group and assign Read rights.
There are some permissions that apply only to specific clients. Your service determines which clients get support. For example, Outlook Web Access does not incorporate user permission sets when doing searches. The permissions set on OUs do not prevent search results from including other segregated group's recipients. If you are using Outlook Web Access, you must set the attribute msExchQueryBaseDN on each address list or user object to restrict the search results to include only the members of the appropriate address list.
As with all security and permissions changes, verification and testing must be performed to ensure the expected result is obtained after the change has been implemented. In this example, the Outlook client and Outlook Web Access should be tested to guarantee that each segregated group can view only their group-specific data, and that all client features operate as intended.
msExchUserOAB Configuration
When you configure multiple offline address lists for a particular messaging database (MDB) in Exchange, Exchange associates the offline address book that a user is permitted to download with the MDB where that user's mailbox is located. This may be unacceptable if you locate many segregated groups on a single mailbox database. Modification of the user attribute msExchUseOAB will allow Exchange to determine the offline address book (that is generated from a particular address list, or lists), and is meant to be available to each user. When you must locate multiple segregated groups on a single database, and these groups have different offline address lists, you must restrict the offline address book by using the msExchUseOAB attribute.
msExchQueryBasedDN Configuration
Microsoft Outlook Web Access (OWA) users may use the Find names feature to view users, including those who are not located in the same organizational unit. To limit the scope of a directory service search available to Outlook Web Access users, you must set the msExchQueryBaseDN attribute on each user object. The value that is specified for the msExchQueryBaseDN attribute limits the searches and the ambiguous name resolution queries that a user can perform. This can be set to the distinguishedname (DN) of the OU or an address list containing the correct group of users.
dsHeuristics Configuration
Active Directory in earlier versions of Microsoft Windows-based domains accept anonymous requests. In these versions, a successful result depends on having correct user permissions in Active Directory.
With Windows Server 2003, only authenticated users may initiate an LDAP request against Windows Server 2003-based domain controllers. You can override this new default behavior by changing the third character of the dsHeuristics attribute. By default, this attribute is not set. If the attribute is not set, you must change the value to 001. If the attribute is already populated, change the third character to a 1 and leave the first two as they are. The DN path for the dsHeuristics attribute is listed below. It can be found in the root domain of the forest.
CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration
The dsHeuristics setting applies to all Windows Server 2003-based domain controllers in the same forest. The value is realized by domain controllers upon Active Directory replication without restarting Windows.
| Note: |
|---|
|
Microsoft Windows 2000 Server-based domain controllers do not support this setting and do not restrict anonymous operations if they are present in a Windows Server 2003-based forest.
|
| Important: |
|---|
|
In Active Directory, object visibility is normally controlled by List Contents permissions on the parent object, which is an object that will only be visible to a user if the user has been granted List Contents permissions on the parent object. When a user has List Contents permission on a parent node, he or she can see and browse all objects that are children of that node without any further selectivity. However, Active Directory can also be configured to control object visibility at a more granular level on a per-object basis. This is a special mode referred to as the "List Object" mode. In this special mode, an object will continue to be visible to a user if the user has been granted List Contents permission on the parent object. Alternatively, if the user has not explicitly been granted or explicitly been denied List Contents permission on the parent object, the object will still be visible to the user if the user is granted List Object permission on both the parent object and the object itself. When considering the use of this special "List Object" mode for Active Directory, it is important to keep in mind that controlling object visibility purely based on the List Object permission will significantly increase the number of access check calls made by the directory service to determine if an object is visible to a user. Therefore, it can have a negative effect on the performance of browsing or reading from Active Directory. The directory can be put in this special "List Object" mode by modifying the dsHeuristics attribute on the Directory Service object (cn=Directory Service,cn=Windows NT,cn=Services,cn=Configuration,dc=ForestRootDomain). This attribute is a single valued Unicode string and the third character position (from the left) which controls whether or not the directory service is in the special "List Object" mode. The default value for the third character is 0. Changing the third character value to 1 will put the directory service in the special "List Object" mode. By default, only Enterprise Administrators and Domain Administrators of the Root Domain have permissions to modify this attribute. Care should be taken when changing this dsHeuristics attribute value because other characters in this value control other directory service functionality. Accidentally modifying them might directly affect functionality.
|
User Principal Name Configuration
User principal names (UPNs) provide logon names in a format similar to e-mail names. By making UPN values independent from domain names, you can move user accounts between domains while leaving UPN values unchanged, making the move transparent to users and easing administration.
The primary benefit of using UPNs is to provide a unique namespace for each segregated organization. Through the use of UPN for logon and user identification, rob@contoso.com and rob@fabrikam.com can be supported in the same Active Directory domain without worrying about Rob’s user ID or e-mail name being unique. Each segregated group can be provided a unique namespace, which is equivalent to how most companies allocate user credentials. This also masks the Windows domain name from the segregated users who have this attribute configured. This provides the appearance to each segregated group that the entire environment is set up purely for them, even though several virtual organizations have been segregated within your environment.
The main advantage to using UPNs is for Outlook Web Access or IMAP logons. This enables users to log on to their mailboxes, using only their SMTP address and password, without specifying a Windows 2003 domain.
Return to top