Domain Services for Windows
Domain Services for Windows streamlines user and group management and simplifies infrastructure complexity in mixed environments. This innovative technology allows Microsoft Windows users to access OES services using native Windows and Active Directory protocols.
By allowing Micro Focus® eDirectory™ servers running on Open Enterprise Server to behave as if they were Active Directory servers, this technology enables companies with both directory services deployments to achieve better coexistence between the two platforms. Users can work in a pure Windows desktop environment and still take advantage of some Open Enterprise Server back-end services and technology, without the need for a OES Windows Client™ on the desktop.
What does Domain Services for Windows do?
Domain Services for Windows streamlines the user experience by allowing them to log in and authenticate to both Micro Focus eDirectory and Active Directory from a Windows workstation without requiring multiple logins or having the OES Windows Client for Windows installed.
By creating a cross-forest trust between Micro Focus eDirectory and Active Directory, Domain Services for Windows also eliminates the need to synchronize and duplicate identity stores. This means you can reduce infrastructure complexity, simplify user management, and lower investment costs in directory server hardware.
Cross-forest trust can also lower training and support costs by allowing administrators to perform basic user administration for all users using either Micro Focus iManager or Microsoft Management Console.
Additionally, since a Domain Services for Windows domain looks and acts just like an Active Directory domain, it can provide authentication to many AD style applications so you don’t have to deploy an AD server just to add an application that requires AD authentication.
How do I know if Domain Services for Windows will provide authentication for a certain AD style application?
In many cases, Domain Services for Windows can eliminate the need to build an Active Directory infrastructure to simply run certain Active Directory style applications.
For many Active Directory style applications, a Domain Services for Windows domain looks and acts just like an Active Directory domain. As a result, after users authenticate to Domain Services for Windows, many of these applications will recognize the Domain Services for Windows credentials as authentic and automatically log them into the application without prompting them for their username and password. This can all happen without the existence of an Active Directory domain.
While we have verified this functionality on a variety of Active Directory style applications, including Citrix Presentation Server, it might not work on all such applications. Even though Domain Services for Windows uses an almost identical authentication mechanism as that used by Active Directory, applications such as Microsoft Exchange that utilize advance APIs and require certain extension schemas might not be able to take advantage of this functionality at this time.
In addition to allowing Micro Focus eDirectory users to authenticate to certain Active Directory style applications, the cross-forest trust relationship that Domain Services for Windows provides also allows Active Directory users to authenticate to Active Directory-style applications within a Domain Services for Windows domain.
How does Domain Services for Windows work?
Domain Services for Windows enables organizations to create a cross-forest trust between the identity stores in Micro Focus eDirectory and Active Directory that allows each user to be represented by a single user account, regardless of where that account resides.
As a result of this cross-forest trust, Micro Focus eDirectory users in a Domain Services for Windows forest can authenticate to file and print services using their native Windows clients, as well as take advantage of the solution’s seamless cross-authentication capabilities that enable users to use their Micro Focus eDirectory usernames and passwords to authenticate to Active Directory services as well, including file systems, printers, and some AD style applications.
Is Domain Services for Windows a synchronization solution?
Domain Services for Windows is not a directory synchronization solution. Rather, the cross-forest trust it creates enables organizations to establish a relationship between Active Directory and Micro Focus eDirectory that allows each user to be represented by a single user account, regardless of where that account resides.
In fact, this cross-forest trust reduces the need for synchronization and eliminates the need to duplicate identities in organizations that have both Micro Focus eDirectory and Active Directory infrastructures since the rights and attributes for a user now only need to be maintained in one directory repository instead of two.
Since Domain Services for Windows and CIFS both provide clientless solutions, when should I use one over the other?
Domain Services for Windows is designed for organizations that want to consistently present their users with a complete Active Directory-style environment, regardless of whether those users need to access Linux servers or Windows servers. It enables an Open Enterprise Server to appear as if it is an Active Directory domain controller, allowing users to log in and authenticate to it with a native Windows client using their user principal names and Micro Focus eDirectory passwords. It also enables Micro Focus eDirectory users to utilize common Windows desktop operations to access file services on NSS volumes on Linux servers by using Samba shares or NTFS files on Windows servers that use CIFS shares, as well as shares in trusted Active Directory forests.
Domain Services for Windows supports common authentication protocols used in the Windows environment, including Kerberos.
CIFS is for organizations that want to provide their users with basic workgroup authentication and access to the NSS file system on Linux from a Windows workstation without requiring the OES Windows Client, but without all the overhead of an Active Directory-style presentation. These organizations don’t need Kerberos authentication, the Microsoft Management Console, or Windows Group Policy support. Their users just want to be able to map and access their network drives natively.
Common candidates for CIFS are organizations that have Open Enterprise Server as their primary environment and simply want to be able to enable users to authenticate to network resources without relying on the OES Windows client. Other candidates include organizations that have been using CIFS on NetWare and are making the move to Linux. They simply want to continue using native Windows authentication that the CIFS protocol provides.