14.4 Domain Services for Windows
14.4.3 Implementing DSfW on Your Network
(en) 17 September 2009
14.4.1 Graphical Overview of DSfW
“File Access” on page 147
“User Management” on page 148
“Storage Management” on page 149
File Access
Figure 14-2 DSfW File Access Overview
Could be on a seperate OES 2 server
in or out of the domain
Could be on a separate Windows server eDirectory
DSfW server eDirectory
User
Windows Explorer or Internet Explorer
Access Methods Authentication File Storage Services
AD Windows server AD User Windows Explorer
or Internet Explorer
Cross-Forest Trust
(en) 17 September 2009
Table 14-1 DSfW File Access
User Management
Figure 14-3 DSfW User Management Overview
Access Methods Authentication File Storage Services
eDirectory and Active Directory users on Windows workstations can access files through Windows Explorer (CIFS) or Internet Explorer (WebDAV Web Folders). No Novell Client can be on the machine.
Unlike Windows workgroup or Novell Samba, the user doesn’t need to have a matching username and password on the local workstation.
Although not shown, Novell Client users can also access files through a normal NCPTM connection.
For eDirectory users, file service access is controlled by
authentication through the eDirectory server using common Windows authentication
protocols, including Kerberos*, NTLM, and SSL/TLS.
For AD users, file service access is controlled by authentication through the AD server.
On OES 2 servers, file storage services are provided by Samba to NSS or trandtional Linux file systems.
For eDirectory users, access to storage on Windows servers is available through a cross-forest trust. Access rights are granted by the AD administrator following the establishment of the
(en) 17 September 2009
Table 14-2 DSfW User Management
Storage Management
Figure 14-4 DSfW Storage Management Overview
Management Tools Users
iManager manages DSfW users like other eDirectory users.
MMC manages both AD users and DSfW users as though they were AD users.
DSfW users must have the Default Domain Password policy assigned and a valid Universal Password.
DSfW users are automatically enabled for Samba and LUM.
Network Administrators
Management Tools Storage
Windows servers OES 2 servers OES
Storage Management Tools
Windows Storage Management
Tools
(en) 17 September 2009
Table 14-3 DSfW Storage Management
14.4.2 Planning Your DSfW Implementation
For planning information, see the OES 2 SP2: Domain Services for Windows Administration Guide.
14.4.3 Implementing DSfW on Your Network
This section highlights some of the potential caveats to consider when installing DSfW. For complete information, see the OES 2 SP2: Domain Services for Windows Administration Guide, especially the “Troubleshooting DSfW” section.
“Universal Password in a Name-Mapped Scenario” on page 150
“DSfW Must Be Installed at the Root of an eDirectory Partition” on page 150
“Hierarchical Placement of Users in the eDirectory Tree” on page 151
“OES 2 Service Limitations” on page 151
“Domain and Container Names Must Match” on page 151
“Install DSfW on a New OES 2 Linux Server When Possible” on page 151
“DNS Configuration” on page 151
Universal Password in a Name-Mapped Scenario
If you install DSfW into an existing tree and your users don’t currently have a Universal Password policy assigned, they won’t be able to log in without the Novell Client until the Universal Password has been set.
Therefore, you should consider implementing Universal Password and giving users an opportunity to log into the network before installing DSfW. Logging in after a password policy is in place creates a Universal Password for users so that their transition to DSfW is seamless.
DSfW Must Be Installed at the Root of an eDirectory Partition
You must install DSfW in the root container or an eDirectory partition, either one that currently exists or one that you create for DSfW. In both cases, the first DSfW server installed in the partition becomes the master of the partition.
Management Tools Storage
Network administrators use native OES and Windows storage management tools to create and manage storage devices on OES and Windows servers, respectively.
Windows management tools can also manage share access rights and POSIX file system rights on DSfW storage devices after the shares are created.
They cannot create the shares or perform other device management tasks.
Storage devices on OES 2 servers can be either NSS or traditional Linux volumes. Samba management standards apply to both volume types.
(en) 17 September 2009 Hierarchical Placement of Users in the eDirectory Tree
DSfW users must reside in the same eDirectory partition where DSfW is installed, either in the same container or in a container below it in the hierarchy. Therefore, DSfW should be installed high enough in the eDirectory tree that it encompasses all of the users that you want to enable for DSfW access.
OES 2 Service Limitations
Only designated OES 2 services can be installed on a DSfW server. For more information, see
“Unsupported Service Combinations” in the OES 2 SP2: Domain Services for Windows Administration Guide.
Domain and Container Names Must Match
When you install DSfW, the Domain name you specify must match the name of the container you are installing into. For more information, see “Installing the First DSfW Server in a New eDirectory Tree” in the OES 2 SP2: Domain Services for Windows Administration Guide.
Install DSfW on a New OES 2 Linux Server When Possible
Because of the service limitations mentioned in OES 2 Service Limitations, Novell strongly recommends that you install DSfW on a new server.
DNS Configuration
As you set up DNS, observe the following guidelines:
First DSfW Server (FRD): This should point to itself as the primary DNS server, and to the network DNS server as the secondary DNS server (if applicable).
Subsequent DSfW Servers: These must point to the FRD as their primary DNS server and optionally to the network DNS server as their secondary DNS server.
DSfW Workstations: These must be able to resolve the FRD of the DSfW forest. For example, you might configure workstations to point to the FRD as their primary DNS server and to the network DNS server secondarily. Or if the network DNS server is configured to forward requests to the DSfW server, then workstations could point to it as their primary DNS server.
(en) 17 September 2009
15
(en) 17 September 2009
15
Users and Groups
Networks exist to serve users and groups of users. Open Enterprise Server 2 provides strong user and group management through eDirectoryTM and its associated technologies.
Section 15.1, “Creating Users and Groups,” on page 153