Cool Solutions

Domain Services for Windows – Design Goals


July 16, 2007 12:47 pm





We looked at the overall use case of Domain Services for Windows in my last post.  Let’s have a look at the design goals of this product to get a clear understanding of the use cases.  The design goals listed below were carefully chosen.   

Design Goals

  • One of our main design goals was to provide seamless integration between windows and SuSE Linux Enterprise Server10 SP1 (SLES10-SP1). Windows administrators should be able to use Microsoft Management Console ( MMC ) for creating and managing users.  The same time, Novell administrators will be able to use Novell tools such as iManager to create or manage objects.  
  • Another design goal was to re-use existing open source components as much as possible.  However, there are some enhancements implemented in some components to get to get the complete functionality. For eg. MIT Kerberos with enhancements to support authorization data field used to contain user validation information or PAC, NTP with netlogon extensions etc.
  • Customers having windows and Novell network should be able to leverage the features of this product without re-creating their user identities.  So, it was essential to support existing eDirectory deployments  and have the same users log-on to both windows and SLES environments.

As you have noted already, seamless integration with Windows world, use of open source components and integration with existing Novell resources keeping eDirectory as the identity vault were the key design goals.

0 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 5 (0 votes, average: 0.00 out of 5)
You need to be a registered member to rate this post.

Categories: Uncategorized


Disclaimer: This content is not supported by Micro Focus. It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test it thoroughly before using it in a production environment.

1 Comment

  1. By:lpavic

    Hi Jose,

    Unfortunately, Novell did not deliver on these design goals. The very notion of limiting the XAD functionality to the partition boundary makes this technology only usable for small sites. Instead of using the partition boundary, it should have been allowed to specify the lower limit in the configuration of XAD (i.e. config file or a configuration object in eDirectory). I have a customer that has 200000+ objects in one eDirectory served by three dedicated authentication servers that have replicas of all partitions, and if DSfW were designed properly, they would not need to look at AD. However, with all the limitations imposed by DSfW, it is easier to replace eDirectory with AD DS (Win2008), and enjoy the additional benefits such as Recycle Bin.

    Is Novell looking at the enhancements of DSfW at all, and how can partners/customers discuss the real life needs with designers of DSfW? My current experience with Australia/New Zealand is not positive as people are really not doing much with DSfW. How can someone like me get an opportunity to discuss the design limitations of DSfWF with Novell?


    Ljubisa Pavic
    NETSYS Limited
    Auckland, New Zealand