12.6 Domain Services for Windows

Domain Services for Windows (DSfW) allows eDirectory users on Windows workstations to access storage on both OES servers and Windows servers through native Windows and Active Directory authentication and file service protocols.

DSfW enables companies with Active Directory and eDirectory deployments to achieve better coexistence between the two platforms.

  • Users 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 Client for Open Enterprise Server or even a matching local user account on the Windows workstation.

  • Network administrators can use Microsoft Management Console (MMC) to administer users and groups within the DSfW domain, including their access rights to Samba-enabled storage on OES servers.

This section discusses the following:

12.6.1 Graphical Overview of DSfW

User Management

Figure 12-2 DSfW User Management Overview

Table 12-1 DSfW User Management

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.

Storage Management

Figure 12-3 DSfW Storage Management Overview

Table 12-2 DSfW Storage Management

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 servers can be either NSS or traditional Linux volumes. Samba management standards apply to both volume types.

12.6.2 Planning Your DSfW Implementation

12.6.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 2023: Domain Services for Windows Administration Guide, especially the Troubleshooting DSfW section.

Implement Universal Password Before DSfW 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 Client for Open Enterprise Server 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.

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 Service Limitations

Only designated OES services can be installed on a DSfW server. For more information, see Unsupported Service Combinations in the OES 2023: Domain Services for Windows Administration Guide.

Install DSfW on a New OES Server When Possible

Because of the service limitations mentioned in OES Service Limitations, OES 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.