OES 2 SP2: Domain Services for Windows Administration Guide
Legal Notices
Novell, Inc. makes no representations or warranties with respect to the contents or use of this documentation, and
specifically disclaims any express or implied warranties of merchantability or fitness for any particular purpose.
Further, Novell, Inc. reserves the right to revise this publication and to make changes to its content, at any time,
without obligation to notify any person or entity of such revisions or changes.
Further, Novell, Inc. makes no representations or warranties with respect to any software, and specifically disclaims
any express or implied warranties of merchantability or fitness for any particular purpose. Further, Novell, Inc.
reserves the right to make changes to any and all parts of Novell software, at any time, without any obligation to
notify any person or entity of such changes.
Any products or technical information provided under this Agreement may be subject to U.S. export controls and the
trade laws of other countries. You agree to comply with all export control regulations and to obtain any required
licenses or classification to export, re-export or import deliverables. You agree not to export or re-export to entities on
the current U.S. export exclusion lists or to any embargoed or terrorist countries as specified in the U.S. export laws.
You agree to not use deliverables for prohibited nuclear, missile, or chemical biological weaponry end uses. Please
refer to www.novell.com/info/exports/ for more information on exporting Novell software. Novell assumes no
responsibility for your failure to obtain any necessary export approvals.
Novell, Inc. has intellectual property rights relating to technology embodied in the product that is described in this
document. In particular, and without limitation, these intellectual property rights may include one or more of the U.S.
patents listed at http://www.novell.com/company/legal/patents/ and one or more additional patents or pending patent
applications in the U.S. and in other countries.
Novell, Inc.
404 Wyman Street, Suite 500
Waltham, MA 02451
U.S.A.
www.novell.com
Online Documentation: To access the online documentation for this and other Novell products, and to get
updates, see www.novell.com/documentation.
Novell Trademarks
For a list of Novell trademarks, see the Novell Trademark and Service Mark list (http://www.novell.com/company/
legal/trademarks/tmlist.html).
Third-Party Materials
All third-party trademarks are the property of their respective owners.
novdocx (en) 7 January 2010
novdocx (en) 7 January 2010
4OES 2 SP2: Domain Services for Windows Administration Guide
10OES 2 SP2: Domain Services for Windows Administration Guide
About This Guide
This documentation describes how to install, configure, and use Novell® Domain Services for
Windows on a Novell Open Enterprise Server (OES) 2 server.
This guide is divided into the following sections:
Chapter 1, “Overview,” on page 13
Chapter 2, “What’s New,” on page 19
Chapter 3, “Use-Cases,” on page 21
Chapter 4, “Deployment Scenarios,” on page 25
Chapter 5, “Planning for DSfW,” on page 29
Chapter 6, “Installing Domain Services for Windows,” on page 41
Chapter 7, “Provisioning Domain Services for Windows,” on page 103
Chapter 9, “Upgrading DSfW,” on page 127
Chapter 10, “Running Domain Services for Windows in a Virtualized Environment,” on
page 129
novdocx (en) 7 January 2010
Chapter 11, “Logging In from a Windows Workstation,” on page 131
Chapter 12, “Creating Users,” on page 137
Chapter 13, “Understanding DNS in Relation to DSfW,” on page 141
Chapter 14, “Managing Group Policy Settings,” on page 147
Chapter 15, “Managing Trust Relationships in Domain Services for Windows,” on page 155
Chapter 16, “Providing Access to Server Data,” on page 189
Chapter 17, “Printing in the Domain Services for Windows Environment,” on page 199
Chapter 18, “Flexible Single Master Operation (FSMO) Roles,” on page 201
Chapter 19, “Troubleshooting,” on page 205
Audience
This guide is intended for network installers and administrators.
Feedback
We want to hear your comments and suggestions about this manual and the other documentation
included with this product. Please use the User Comment feature at the bottom of each page of the
online documentation, or go to www.novell.com/documentation/feedback.html and enter your
comments there.
Documentation Updates
For the most recent version of the OES 2:Domain Services for Windows Administration Guide, see
the latest Novell Open Enterprise Server 2 documentation (http://www.novell.com/documentation/
oes2/index.html).
About This Guide11
Additional Documentation
For information about security issues and recommendations for Novell®Domain Services for
Windows see OES 2: Novell Domain Services for Windows Security Guide
Documentation Conventions
In Novell documentation, a greater-than symbol (>) is used to separate actions within a step and
items in a cross-reference path.
®
A trademark symbol (
, TM, etc.) denotes a Novell trademark. An asterisk (*) denotes a third-party
trademark.
When a single pathname can be written with a backslash for some platforms or a forward slash for
other platforms, the pathname is presented with a backslash. Users of platforms that require a
forward slash, such as Linux* or UNIX*, should use forward slashes as required by your software.
novdocx (en) 7 January 2010
12OES 2 SP2: Domain Services for Windows Administration Guide
1
Overview
Domain Services for Windows (DSfW) is a suite of technologies in Open Enterprise Server (OES) 2
SP1 and later versions that allows Microsoft* Windows users to access OES services through native
Windows and Active Directory* protocols. By allowing OES Linux servers to behave as if they
were Active Directory servers, this technology enables companies with Active Directory and
®
Novell
can work in a pure Windows desktop environment and still take advantage of some OES back-end
services and technology, without the need for a Novell Client
Administrators can use either Novell iManager or Microsoft Management Console (MMC) to
administer users and groups. Network administrators manage file systems using the native tools of
each server, and they can also centrally administer Samba shares on OES Linux/ DSfW servers by
using iManager.
Administrators can use MMC to create inter-domain trusts between DSfW domains and Active
Directory domains.
eDirectoryTM deployments to achieve better coexistence between the two platforms. Users
TM
on the desktop.
novdocx (en) 7 January 2010
1
TM
Users can access Novell Storage Services
or NTFS files on Windows servers that use CIFS shares. eDirectory users can also access shares in
trusted Active Directory forests.
Domain Services for Windows is not a meta-directory or a synchronization connector between
eDirectory and Active Directory. It does not do desktop emulation. Domain Services for Windows
can only run on SUSE Linux Enterprise deployments of Open Enterprise Server 2 SP1 and later.
Section 1.1, “Features and Benefits,” on page 13
Section 1.2, “Architectural Overview,” on page 14
Section 1.3, “Basic Directory Services Concepts,” on page 16
Section 1.4, “Key Differences Between the DSfW LDAP Server and the eDirectory Server,” on
page 17
(NSS) volumes on Linux servers by using Samba shares
1.1 Features and Benefits
DSfW is designed to simplify the network infrastructure in mixed Windows/OES 2 SP2 Linux
environments, thereby reducing costs and streamlining IT operations. Minimal changes are required
to the default authentication, authorization, and replication mechanisms in existing eDirectory and
Active Directory environments. DSfW enforces the Active Directory security model in eDirectory
and applies it to all users and groups within the DSfW domain, regardless of the tool used to create
the users and groups. Both Microsoft
in either the Active Directory or eDirectory environment remain securely accessible by eDirectory
users.
*
and Novell applications can be used unmodified. Resources
Specific benefits of DSfW include the following:
Clientless login and cross-platform file access for Windows users: From a standard
Windows workstation, users can authenticate to an OES 2 SP2 Linux server running eDirectory
without the need for the Novell Client software or multiple logins. After the Windows
Overview
13
workstations have joined the DSfW domain, authorized users can log in and access the file and
print services they are authorized to use, whether the services are provided by OES 2 SP2
Linux servers in the DSfW domain or Windows servers in a trusted Active Directory domain.
Unified repository of user account information: DSfW is not a directory synchronization
solution. Each user is represented by a single user account, and that account can reside in either
eDirectory or Active Directory. A single password is used to authenticate each user to resources
in either environment.
Support for cross-domain and cross-forest trust relationships: DSfW allows administrators
to create cross-domain and cross-forest trusts between a Windows 2003 Active Directory
domain/forest and a DSfW domain/forest. This allows authenticated and authorized DSfW
users to access data on servers in an Active Directory domain/forest.
Support for existing management tools: Administrators can use familiar tools for their
environment, such as iManager for OES 2 SP2 and Microsoft Management Console (MMC)
for Windows, thus eliminating the need for re-training.
Network administrators can manage file systems using the native tools of each server, as well
as centrally administer Samba shares on OES Linux/DSfW servers using iManager.
Administrators can use MMC to create one-way cross-forest trusts between DSfW domains
and Active Directory domains. For example, Windows server/workstation policy settings in the
domain Group Policies can be changed by using MMC.
Support for common authentication protocols and open standards: DSfW supports
common authentication protocols used in the Windows environment, including Kerberos*,
NTLM, and SSL/TLS.
Single Password to Login: One of the biggest benefits Domain Services for Windows
provides end users is it eliminates multiple logins if they need access to both Active Directoryand eDirectory-based services. The trust relationship between eDirectory and Active Directory
enables them to employ a single password for the services provided by either directory. From
an IT perspective, this also greatly simplifies user management as objects for those users only
need to be maintained in one directory repository instead of two.
novdocx (en) 7 January 2010
1.2 Architectural Overview
Figure 1-1 illustrates the components included in DSfW and how they interact.
14OES 2 SP2: Domain Services for Windows Administration Guide
Figure 1-1 DSfW Components
DSfW is made up of the following technologies:
novdocx (en) 7 January 2010
eDirectory: eDirectory 8.8 SP2 and above supports DSfW.
Kerberos Key Distribution Center (KDC): Provides Active Directory-style authentication.
NOTE: This is a KDC specifically developed for DSfW. It is different from the Novell
NMAS Extensions: Provide support for GSS-API authentication mechanisms, and for
SAMSPM, to generate Active Directory-style credentials when a user’s Universal Password is
changed.
Active Directory Provisioning Handler (ADPH /Directory System Agent): Provides agent-
side support for the Active Directory information model, regardless of access protocol. It
enforces Active Directory security and information models, allocates Security Identifier (SIDs)
to users and groups, validates entries, and enables existing eDirectory users and groups to use
Active Directory and RFC 2307 authorization.
Domain Services Daemon: Provides support for Windows RPCs, including Local Security
Authority, Security Accounts Manager, and Net Logon.
NAD Virtualization Layer: Virtualizes the Active Directory information model within
eDirectory so that LDAP requests are handled appropriately.
CIFS: Provides file services and transport for DCE RPC over SMB. The services are provided
by the Samba 3.x software included with SUSE
DNS: The DNS server has been modified to support GSS-TSIG (Kerberos secured dynamic
®
Linux Enterprise Server 10 and OES 2.
updates).
NTP: The NTP server has been modified to support the secure signing of NTP responses.
Overview15
1.3 Basic Directory Services Concepts
To effectively set up and work with DSfW, a basic understanding of both eDirectory and Active
Directory is required. This section briefly outlines helpful concepts and terminology.
Section 1.3.1, “Domains, Trees, and Forests,” on page 16
Section 1.3.2, “Naming,” on page 16
Section 1.3.3, “Security Model,” on page 16
Section 1.3.4, “Groups,” on page 17
1.3.1 Domains, Trees, and Forests
Domain: In Active Directory, a domain is a security boundary. A domain is analogous to a partition
in eDirectory.
Forest: A forest is a collection of Active Directory domains. A forest is analogous to a tree in
eDirectory. You can set up trust relationships to share authentication secrets between domains.
Each Active Directory server has a domain, a configuration, and a schema partition.
novdocx (en) 7 January 2010
Global Catalog: Global catalogs are special Active Directory domain controllers that store a
complete copy of all the Active Directory objects belonging to the host domain and a partial copy of
all other objects in the forest.
Federation can be accomplished through establishing cross-domain and cross-forest trusts.
1.3.2 Naming
Active Directory uses DC (domain class) naming at the root of a partition, while eDirectory supports
other naming attributes like Organization (O) and Organizational Unit (OU). For example, in
eDirectory a partition might be specified as:
ou=sales.o=company
In Active Directory, the partition is specified as:
dc=sales,dc=company
Every Active Directory domain maps to a DNS domain. The DNS domain name can be derived
from the Active Directory domain name. DSfW also follows this rule and supports mapping of
eDirectory partitions to DSfW domains.
For example, the
dc=sales,dc=company,dc=com
ou=sales.o=company
.
partition can be mapped to the DSfW domain
1.3.3 Security Model
The Active Directory security model is based on shared secrets. The authentication mechanism is
based on Kerberos. The domain controller contains all users’ Kerberos keys. The KDC, Remote
Procedure Call (RPC) server, and Directory System Agent (DSA) operate inside a “trusted
computing base” and have full access to all user information.
16OES 2 SP2: Domain Services for Windows Administration Guide
Active Directory users and groups are identified by unique Security Identifiers. The SID consists of
domain-specific prefix, followed by an integer suffix or “relative ID” that is unique within the
domain.
For more information about Active Directory, see the Microsoft Active Directory Technical Library
Active Directory supports universal, global, and local groups. DSfW supports the semantics of these
groups with different scopes when the group management is performed through MMC. However,
there are exceptions. For example, validation of group type transitions is not supported.
Groups can also contain other groups, which is known as Nesting. Other limitations largely result
from the way eDirectory supports nested groups. You cannot add a group from other domains as a
member of a group.
In addition eDirectory supports dynamic groups, because Active Directory does not support them,
dynamic groups are not supported in DSfW. All groups created by using iManager or MMC can be
used as security principals in an Access Control List in eDirectory. Token groups can only have
groups that are enabled as security groups through MMC.
novdocx (en) 7 January 2010
1.4 Key Differences Between the DSfW LDAP
Server and the eDirectory Server
Table 1-1 Comparison of DSfW LDAP server and eDirectory server
FunctionDSfW LDAP ServereDirectory Server
LDAP Operations like Search and
Modify
PortsWhen DSfW server is configured
Semantic ControlsLDAP requests along with LDAP
Uses Domain Name format. For
example: dc=eng, dc= novell.
LDAP requests, such as Search
and Modify, to a DSfW server on
port 389 or 636 uses domain
name format instead of
eDirectory X.500 format. LDAP
ports 1389 and 1636 are enabled
to support LDAP requests using
the traditional X.500 format and
to behave as eDirectory ports.
semantic controls
(2.16.840.1.113719.1.513.4.5)
allow LDAP requests to select
X.500 or the domain format.
Uses X.500 format. For example:
ou=eng, o=novell.
eDirectory uses ports 389 and
636 for communication purposes.
The format used is X.500.
No support for semantic controls
Overview17
FunctionDSfW LDAP ServereDirectory Server
Schema AdditionAttribute and class mappings are
changed for some object classes.
For example, User and Group
object classes are mapped to
user and group; server is mapped
to ndsServer User and Group
object classes are extended to
hold additional Active Directory
attributes. For more information,
Attribute Mappings and Class
Mappings.
novdocx (en) 7 January 2010
SearchSearch and Modify, to a DSfW
server on port 389 or 636 return
only those objects that exist in the
partition and do not search
beyond the partition boundary. An
LDAP referral is returned, but if
the calling LDAP application does
not support referrals, it fails to
search beyond the partition
boundary. A search request on
global catalog ports (3268, 3269)
spans partition boundaries and
searches the entire forest. The
result set contains only the
attributes marked as Partial
Attribute Set (PAS).
Multiple InstancesNot supported.Supported.
Support for NT ACLsNo support for NT ACLs.Directory objects are protected by
Domain PartitionEvery DSfW server has a unique
domain partition (required by the
Active Directory security model).
The search spans across
partitions.
proven eDirectory ACLs.
No concept of domain partition.
For both DSfW server and LDAP server, login authorization and auditing is performed by using
TM
NMAS
. Data on the wire is encrypted as mandated by the workstations. All keys, including
Kerberos and NTLM, are encrypted by using a per attribute NICI key.
18OES 2 SP2: Domain Services for Windows Administration Guide
2
What’s New
This section describes additions to the Novell® Domain Services for Windows (DSfW) service for
the Novell Open Enterprise Server 2 SP2 Linux platform over the previous release:
DSfW Installation and configuration are now handled in a two-step process:
1. The YaST install prepares the server and the tree for domain users. This part of the process
features restructured installation screens.
2. A Provisioning Wizard, which is a separate utility that configures the DSfW server and
supporting services, and completes the installation process.
The SYSVOL is now located on every domain controller of each domain. This resolves the
limitation resulting from having the SYSVOL only on the first domain controller of the
domain.
Support for Upgrade to OES 2 SP2.
Support to join Windows 2003 server as a member server to the domain.
novdocx (en) 7 January 2010
2
What’s New
19
novdocx (en) 7 January 2010
20OES 2 SP2: Domain Services for Windows Administration Guide
3
Domain Services
for Windows
Users
Cross–forest
trust
Active
Directory
Applications
Use-Cases
This section describes some common usage patterns that will help you in understanding the
possibilities and functionalities of DSfW.
Section 3.1, “Authenticating to Applications That Require Active Directory-Style
Authentication,” on page 21
Section 3.2, “Working With Windows Systems Without Novell Client,” on page 22
Section 3.3, “Leveraging an Existing eDirectory Setup,” on page 23
Section 3.4, “Interoperability Between Active Directory and eDirectory,” on page 23
3.1 Authenticating to Applications That Require
Active Directory-Style Authentication
This use-case can be described using the following scenarios:
novdocx (en) 7 January 2010
3
Section 3.1.1, “Users Located in the DSfW Forest and Accessing Applications Hosted in the
Active Directory Tree,” on page 21
Section 3.1.2, “Users and Applications Hosted in the DSfW Forest,” on page 22
3.1.1 Users Located in the DSfW Forest and Accessing
Applications Hosted in the Active Directory Tree
In this case DSfW is deployed as an interoperable solution for organizations that have both
eDirectory and Active Directory as part of their infrastructure. Most organizations use Active
Directory-enabled applications which means that the application vendor has tested and certified his
application against Active Directory for authentication and management.
By keeping the users in the DSfW forest and the applications in the Active Directory tree,
organizations have the following advantages:
Manageability is easier as the users reside on a single directory service and are not spread out.
The company need not invest in network resources that may be required if the users were
spread out.
Applications can continue to be certified by the vendors for Active Directory as they are hosted
on an Active Directory infrastructure. With the users residing on DSfW, there is no need to
certify applications.
Figure 3-1 DSfW users Accessing Resources on Active Directory
Use-Cases
21
3.1.2 Users and Applications Hosted in the DSfW Forest
W
Users
Applications
Domain Services
for Windows
eDirectory
The applications in this use case are hosted in the DSfW infrastructure along with the users. This
kind of deployment helps organizations to consolidate their Directory infrastructure.
While most of the application vendors specifically request Active Directory-support, as many
applications are LDAP-enabled, the applications work seamlessly on DSfW.
However, some of the applications that have Active Directory-specific schemas may need additional
effort in terms of schema extensions to work with DSfW.
Figure 3-2 Users and Applications in DSfW Forest
novdocx (en) 7 January 2010
3.2 Working With Windows Systems Without
Novell Client
DSfW allows Microsoft Windows users to work in a pure Windows desktop environment and still
take advantage of some OES back-end services and technology, without the need for a Novell Client
on the desktop.
Administrators can either use Novell iManager or Microsoft Management Console (MMC) to
administer users and groups. Network administrators manage file systems using the native tools of
each server, as well as centrally administer Samba shares on OES Linux/DSfW servers using
iManager. Administrators can use MMC to create cross-forest trusts between DSfW domains and
Active Directory domains.
When deployed in an environment that also supports NetWare Core Protocol (NCP), DSfW supports
cross-protocol locking. Whether customers decide to use only Windows clients, NCP clients, or a
combination of both, access rights for files is enforced by the Novell Storage Services (NSS) file
system.
Novell Client does not need to be installed and managed as an extra software on the desktop. This
helps in streamlining user experiences in terms of login to the directory and single login facility to
both Active Directory applications and eDirectory services.
22OES 2 SP2: Domain Services for Windows Administration Guide
Figure 3-3 Accessing applications without Novell Client
w
Server
Novell
Client
Before
Desktop
iManager
MMC
Server
w
Server
After
Desktop
iManager
MMC
Server
IMPORTANT: Do not install the Novell ClientTM for Windows on a workstation for which you plan
to provide native Windows access to DSfW servers. Novell Client access and native Windows
access to DSfW servers do not work well together on the same workstation. But if you already have
Novell Client installed on your workstation, we recommend that you follow the instructions in
Joining a Workstation that Has Novell Client Installed
novdocx (en) 7 January 2010
3.3 Leveraging an Existing eDirectory Setup
If you already have an eDirectory setup but want to install DSfW in your environment, it is
recommended you utilise the existing eDirectory setup and install DSfW in a container in the
existing eDirectory tree. This way you can utilise all the user information in the eDirectory
container. This kind of setup is known as a name-mapped setup.
For more details on name-mapped setup, see Section 5.4.2, “Installation Prerequisites for a Name-
Mapped Setup,” on page 35 and Section 4.2, “Deploying DSfW in a Name-Mapped Setup,” on
page 27
3.4 Interoperability Between Active Directory
and eDirectory
Trust relationships are a key to managing Domain Services for Windows (DSfW). To facilitate
communication between Windows and Linux environments you can create a trust to access
resources from another domain. When a domain is installed, a trust is automatically established with
its parent domain.
To assist you in doing this, DSfW supports installing into a new eDirectory tree, an existing
eDirectory tree, or an existing forest, creating multiple DSfW domains, and setting up multiple
DSfW domain controllers within the same domain.
Figure 3-4 illustrates a typical deployment scenario in a mixed Novell/Microsoft environment.
Use-Cases23
Figure 3-4 Cross-Forest Trust between Active Directory and DSfW
MMC
iManager
iManager
eDirectory
Replica Ring
Cross Forest Trust
Domain Services
for Windows
Master
Domain Services
for Windows
Server
eDirectory
8.8 SPx
eDirectory
8.8 SP2
MS WorkstationMS Workstation
User
Add/Modify
User
Add/Modify
User B
Authenticates
User A
Authenticates
User
Add/Modify
Msforest.abc.com
User
Add/Modify
Organization
[ROOT]
Organiational
unit
novdocx (en) 7 January 2010
The diagram shows an Active Directory forest and a DSfW forest. Within the DSfW forest are two
DSfW servers, an eDirectory 8.8 SP2 server, and an eDirectory 8.8 SPx server, configured in the
same replica ring. Novell administrators can manage the domain by using iManager connected to
any of these servers, and a Microsoft administrator can use MMC connected to one of the DSfW
servers. The same set of users can access resources from the Active Directory forest through the
establishment of a cross-forest trust, which is a two-way, Kerberos-based, transitive trust between
the two forests.
Within the authentication/authorization boundary (realm) established by DSfW, eDirectory
replication can be used to expand the scope of users and groups that can access resources in a crossdomain and cross-forest scenario. In the example scenario shown above, users created in eDirectory
8.8 SP2 and above are replicated into the DSfW domain and can therefore access servers in the
Active Directory forest.
24OES 2 SP2: Domain Services for Windows Administration Guide
4
dc=example, dc=com
Domain
Controllers
server 1server 2server 3server 4server 5
domain
Deployment Scenarios
This section describes deployment scenarios for name-mapped and non-name mapped scenarios:
Section 4.1, “Deploying DSfW in a Non-Name-Mapped Setup,” on page 25
Section 4.2, “Deploying DSfW in a Name-Mapped Setup,” on page 27
4.1 Deploying DSfW in a Non-Name-Mapped
Setup
In case of installing DSfW in a non-name-mapped setup, you are setting up a new tree in a DSfW
forest. Here the tree structure overlaps with the DNS namespace. Before you start the process of
installation, ensure you have read and understood the details in Installation Prerequisites For a Non-
Name-Mapped Setup.
The scenarios explained here are only indicative of the various ways in which you can deploy DSfW
server in your environment.
novdocx (en) 7 January 2010
4
Section 4.1.1, “Deploying as a Single Domain,” on page 25
Section 4.1.2, “Deploying as Multiple Domains in a Forest,” on page 25
4.1.1 Deploying as a Single Domain
In this scenario, you have a single domain in the forest and have multiple DSfW servers acting as
domain controllers in the domain.
Figure 4-1 Deploying DSfW as a Single Domain
In Figure 4-1 the example.com domain is served by 5 domain controllers.
In this scenario, the DSfW forest is spread out in an horizontal manner. You can have each branch
office of the company configured as a domain.
As represented in the figure, example.com is the first domain in the forest. It represents the head
office of the company and the branch offices are represented by domains, America, India, Korea,
China and Mexico.
Figure 4-2 Deploying DSfW in a Horizontally Spread Tree
novdocx (en) 7 January 2010
Depth
In this form of structuring, the tree is vertically structured and you can create domains corresponding
to each engineering and support function in the organization.
Figure 4-3 Deploying DSfW in a Vertically Structured Tree
26OES 2 SP2: Domain Services for Windows Administration Guide
Depth and Width
dc=example,dc=com
Geographic
(Regional)
Geographic
(Location)
Operational
dc=amercdc=pacrimdc=europe
dc=tkyodc=hnkg
dc=chidc=prv
dc=hrdc=sales
With this combination you get benefits of a tree that is spread both horizontally and vertically spread
out. This is best suited for organizations that have offices locally as well as globally and there is a
high requirement for load processing.
Figure 4-4 Deploying DSfW in a Combination Structure
novdocx (en) 7 January 2010
4.2 Deploying DSfW in a Name-Mapped Setup
If you already have an eDirectory setup but want to install DSfW in your environment, it is
recommended you utilise the existing eDirectory setup and install DSfW in a container in the
existing eDirectory tree. This way you can utilise all the user information in the eDirectory
container. This kind of setup is known as a name-mapped setup. Before you start the process of
installation, ensure you have read and understood the details in Installation Prerequisites for a
Name-Mapped Setup.
In Figure 4-5 DSfW is installed in eDirectory container Asia. The container Asia becomes part of
the DSfW domain. If you have name-mapped an existing partition to a domain, you cannot namemap the sibling partitions to create a domain. Using the example in Figure 4-5, if you have already
name-mapped the O=Asia partition, you cannot name-map the O=America or O=Europe partitions.
However, it is possible to map the partitions underneath O=Asia to a domain. So you can map the
OU=India partition to create a DSfW domain. But if you have already mapped O=Asia partition and
now want to map the OU=Delhi partition, it cannot be done without mapping the OU=India
partition. The boundaries of a domain are valid till it encounters another partition.
Installing DSfW in a tree root partition is not supported.
Deployment Scenarios27
Figure 4-5 Deploying DSfW in an Existing eDirectory Tree
T=Global
T
ououou
ooo
AmericaAsia
China
Europe
IndiaJapan
DelhiBangalore
SalesFinanceSalesFinance
ou
ou
dc
dc=com
dc=asia
dc
novdocx (en) 7 January 2010
28OES 2 SP2: Domain Services for Windows Administration Guide
5
Planning for DSfW
This section describes requirements and guidelines for using the Novell® Domain Services for
Windows on a Novell Open Enterprise Server (OES) 2 server.
Section 5.1, “Server Requirements for Installing DSfW,” on page 29
Section 5.2, “Scalability Guidelines,” on page 29
Section 5.3, “Deciding Between Name-Mapped or Non-Name-Mapped Installation,” on
page 30
Section 5.4, “Meeting the Installation Requirements,” on page 32
Section 5.5, “Supported Installation Scenarios,” on page 39
Section 5.6, “Unsupported Service Combinations,” on page 39
Section 5.7, “Administrative Tools,” on page 40
Section 5.8, “Utilities Not Supported in DSfW,” on page 40
Section 5.9, “Limitation with NETBIOS Names,” on page 40
novdocx (en) 7 January 2010
5
5.1 Server Requirements for Installing DSfW
To install DSfW, you need a server that meets the system requirements for SUSE® Linux Enterprise
Server (SLES) 10 SP3 and Open Enterprise Server 2 SP2. For more information, see “Installing
OES 2 SP2” in the OES 2 SP2: Installation Guide
You should have access to the installation media for SLES 10 SP3 and OES2 SP2, either on physical
CD/DVD media or on a networked installation source server. For more information about installing
OES 2 SP2 from an installation source, see “Setting Up an Installation Source” in the OES 2 SP2:
Installation Guide
NOTE: Ensure that only root account is created during the SLES installation because administrator
or other Active Directory account names can conflict with the DSfW users.
5.2 Scalability Guidelines
The details presented below show the performance of a DSfW server during tests in a lab
environment. However, you can use these details to plan your production environment for DSfW.
Table 5-1 Scalability Guidelines
Forest ComponentScale upto
Number of domains in a forest10
Number of users per domain5000
Number of client workstations per domain1000
Number of simultaneous logins per domain500
Planning for DSfW
29
Forest ComponentScale upto
Number of domain controller per domain5
novdocx (en) 7 January 2010
Number of simultaneous logins per domain
controller
Number of child domains at the same level (width)5
Number of child domains(depth)6
200
5.3 Deciding Between Name-Mapped or NonName-Mapped Installation
Name-Mapped Installation: Installing DSfW in a name-mapped setup means you are installing
DSfW in an existing eDirectory tree inside a specific container.
Before you install DSfW in an existing container, the container must be partitioned.In Figure 5-1 the
existing container Asia is mapped to create a DSfW forest. After the mapping, all of the containers
below the O= Asia container become part of the DSfW forest.
If you have mapped an existing container to a domain, you cannot map the sibling containers to
create a domain. Using the example in Figure 5-1, if you have already partitioned the O=Asia
container, you cannot partition the O=America or O=Europe containers.
However, it is possible to map the containers underneath O=Asia to a domain.
It is not possible to partition the root container and map it to create a DSfW forest.
30OES 2 SP2: Domain Services for Windows Administration Guide
Loading...
+ 212 hidden pages
You need points to download manuals.
1 point = 1 manual.
You can buy points or you can get point for every manual you upload.