Organizations might require Active Directory-style authentication and authorization to support an enterprise application with no Active Directory integrated workstations in the domain. The enterprise application can be any third-party service that integrates with Active Directory, such as Cisco ISE, Polycom, Citrix XENApp, XenDesktop, or VMWare. In such scenarios, the DSfW domain is expected to serve only a Windows server as a member server and have no workstations that require Active Directory-style logins.
Follow the guidelines given below for this deployment scenario:
Create only one central domain representing the entire eDirectory tree.
For existing OES environments, place the DSfW Forest Root Domain at the top-most partition (O or OU) in the existing eDirectory Tree and replicate all eDirectory partitions to the headquarters.
Configure at least 2 domain controllers per domain for high availability and fault tolerance.
Add additional domain controllers to meet the domain member server’s third-party performance needs and for more scalability.
NOTE:For existing OES users, always use the existing eDirectory tree and select the partition that needs to be mapped to the domain. If you are unclear about the structure that needs to support the domain or if there are multiple Organization Containers to be covered, contact a Novell Service Partner or Novell Consulting for assistance.
For organizations that have a high bandwidth connection (at least 2 MBits) between their offices and use local Active Directory-style login, or that have workstation integration and Group Policies, follow the guidelines below:
Configure a single central domain and support it with a local domain controller at each office. Use the Sites and Subnets feature to limit the Windows logon traffic to a local domain controller and to improve overall performance.
Add an additional domain controller at the headquarters and one at the remote office for fault tolerance and scalability.
This deployment scenario includes organizations requiring a decentralized administration or having offices in remote locations that are connected using a low bandwidth connection and having workstations integrated to the Domain.
If there is a need to reduce replication or logon traffic over WAN due to a weak WAN link between offices, or to delegate domain administration tasks to remote offices, use the following recommendations:
Split the remote office container (by partitioning) and map it to a child domain.
Add additional domain controllers to the child domain for fault tolerance and scalability.
(Optional) Configure the DSfW service on a standalone OES server if full eDirectory integration for OES service is not required.
NOTE:The multiple-domain approach leads to administration overheads, such as creating and maintaining domain-specific GPO policies and login scripts. Review the benefits and limitations of the single domain (multiple site feature) and multiple domain approach before introducing a child domain.