Novell Home

Domain Services for Windows

Enabling greater interoperability and infrastructure simplicity in mixed-directory environments.

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 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 Novell 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 eDirectory and Active Directory from a Windows workstation without requiring multiple logins or having the Novell Client for Windows installed.

By creating a cross-forest trust between eDirectory and Active Directory, Domain Services for Windows also eliminates the need to synchronize and duplicate identity stores so you can reduce infrastructure complexity, simplify user management and lower investment costs in directory server hardware. This cross-forest trust can also lower training and support costs by allowing administrators to perform basic user administration for all users using either Novell 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 does Domain Services for Windows work?
Domain Services for Windows enables organizations to create a cross-forest trust between the identity stores in Novell 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, eDirectory users in a Domain Services for Windows forest can authenticate to Novell 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 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 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 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.

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 Novell has 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 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.

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 a Novell 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 eDirectory passwords. It enables eDirectory users to utilize common Windows desktop operations to access file services on Novell Storage Services™ (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*.

Novell CIFS is for organizations that want to provide their users with basic workgroup authentication and access to the Novell NSS file system on Linux from a Windows workstation without requiring the Novell 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 Novell Open Enterprise Server as their primary environment and simply want to be able to allow users to authenticate to network resources without relying on the Novell client. Other candidates include organizations that have been using CIFS on NetWare and are making the move to Linux. So, they simply want to continue using native Windows authentication that the Novell CIFS protocol provides.

© Micro Focus