DSfW as you might be aware, enables emulation of many Active Directory use cases over eDirectory. Scenarios like clientless login, Group Policies applications, and authentication to products like VMware.
In OES11SP2, we are introducing new features in DSfW. These features, sites and subnets in particular, were requested by many customers.
These features are functionally similar to what is in Microsoft environment. However, the way they are configured is very different in DSfW, compared to Active Directory environment. Further, while overall functionality is almost similar, there are a few subtle differences which we will touch upon.
Even if you are unfamiliar with corresponding AD concepts, this blog should enable you to make a good headstart and start working productively very soon on new features of DSfW.
Also we give an overview of new client platforms we support, and a new procedure we have introduced to involve consulting services in complex environments from the very beginning of setting up DSfW forest.
3.1 Purpose: As I mentioned in the overview, in the “Sites and Subnets” feature we plan to offer a solution to the problem of geographically distributed users across slow WAN. While there are other technical possibilities like sub-domains[child domains like child1.dsfw.com, child2.dsfw.com], Active Directory recommendation is to have different sites in same domain. (Probably because it's easier to administer a single domain having multiple sites rather than separate sub-domain in each site).
Site, as you might be aware by now, is a geographically cohesive entity like a building that has workstations connected over fast LAN. And different sites are different locations ranging from different buildings to different countries, which are connected by relatively slower WAN links.
Prior to OES11SP2, for same domain, while it was still possible to have DSfW domain controllers in each site. But the domain controllers that were part of domain had no control over workstation requests. That is workstation in Bangalore could still authenticate to domain controller in Provo, even if Bangalore site had a domain controller for the domain.
For configuration, administrator has to map domain controller to the site it will belong to. And then map the range of workstations which can authenticate to this site, that is to this domain controller (or any other domain controller that belongs to this site). The range of workstations is specified using the subnet workstations belong to.
3.2 Configuration in Fresh Installations
There are two configuration options provided for every domain controller. One is to create a new site, and another is to integrate the domain controller to already created site.
The following subsections show how these configurations can be done if the new domain controller is being setup using OES11SP2 packages.
3.2.1 Configuring New Site:
Creating a new site involves creating an object in eDirectory that will refer to new location. Of course, in case of first domain controller new site always needs to be created.
The following image shows “Fresh Install” screen where new site is configured. During installation it gets created in the tree. Administrator needs to enter the name of new site in the “Site Name of Domain Controller” text box.
3.2.2 Configuring Existing Site
As it is possible to have more than one domain controller in a site, another option is to add domain controller to the existing site. In case the traffic of users in particular site is more, it makes sense to add more domain controllers in that site. In that case “Existing Site” option can be used.
The following image shows “Fresh Install” scenario. Here domain controller is being configured to get integrated into existing site. During installation, integration of domain controller to the existing site is done in the eDirectory tree.
Administrator needs to select the existing site in the “Site Name of Domain Controller” text box using “Browse” button.
3.3 Configuration of Sites in Upgrades
Further, administrator can also configure the domain controller that is installed prior to OES11SP2, to be “sites and subnets” enabled. Apart from upgrading to OES11SP2, the feature configuration wizard needs to be run. Other than upgraded servers, the feature configuration wizard is also used in migrated servers.
Creation of new sites or integration to existing site is done differently for upgraded server as compared to “freshly installed” server described before. The following checkbox selection will enable domain controller to be used for creation and integration of sites.
Similar to provisioning done after a fresh DSfW installation, the feature configuration wizard is provisioned for a particular feature, “Sites and Subnets” in this case.
It is here that the domain controller actually gets enabled to support “Sites and Subnets” feature.
The following image shows the Provisioning screen of Feature Configuration Wizard
Unlike “Fresh Install” case, where we configure domain controller to create / “integrate to” site in YaST configuration, in case of upgraded/migrated and feature provisioned server, the site is created using “sites and services” snap-in launched in any of the client workstations joined to the domain.
Domain controller is integrated into the site by moving the server object corresponding to the domain controller into particular site's container.
3.4 Integrating Site to Subnets
Whether “Freshly Installed” or “Upgraded/migrated and Feature Provisioned” server, in both cases the subnets are created using the “sites and services” snap-in. After creating subnets in this snapin, we can associate sites to relevant subnets.
Following image shows screen for movement of sites and creation / association of subnets.
Here server object SADC was originally associated to DELHI-FAD-SITE. After movement it gets associated with GERMANY site.
3.5 Sites Support and DNS:
Internally sites and subnets functionality uses site specific DNS SRV records.
Following set of SIX SRV records will be created for every domain controller in a DSfW domain.
3.6 Known Limitations
Internally site is stored as a non-leaf object in edirectory tree, so deletion of site is not supported.
Following error pops-up during the DC movement across sites. We can safely ignore this error.
“Windows cannot move object FRD820 because: There is no such object on the server”.
4.1 Purpose: As mentioned in overview, integration of WINS protocol to DSfW is the preemptive solution we came up for problem of duplicate workstations in a domain. Thus preventing system from going into hard to troubleshoot states.
By duplicate workstations I mean two workstations joined to domain having same “computer name”.
(The problem was especially severe in cultures like China, where the pool of names is limited.)
4.2 Configuration of domain controller as WINS server
Like “Sites and Subnet” feature, here too the configuration is different for freshly installed server and server that is upgraded to OES11SP2.
For freshly installed server, configuration option is selected during YaST configuration. For upgraded server it is selected using feature configuration wizard that we saw for sites and subnets feature.
This screenshot shows checkbox used for enabling WINS configuration in YaST configuration wizard (for fresh install). Once the server gets installed, the feature will be enabled.
This screenshot shows checkbox used for enabling WINS configuration in Feature configuration wizard. This method is applicable for server that is upgraded or migrated to OES11SP2. The feature will be enabled after the provisioning of this wizard.
4.3 Client Side Configuration
Apart from server options described here, each of the client workstation also needs to be configured to point to WINS server. The option is available in advanced configuration of IPV4 settings in network configuration of Windows.
Organizations where number of workstations are more, DHCP server can also be configured to push WINS settings to all workstations in the domain.
4.4 Detection of duplicate workstation using WINS
If another workstation having same computer name exists among the workstations joined to the domain, the popup will come prior to join of the new workstation having duplicate name.
4.5 Known Limitations
The current implementation only allows for 1 WINS server per domain. That is only one domain controller in a domain can be configured as WINS server. The UI options are disabled in case there is WINS server existing in the domain.
In enterprises that have two DSfW domains like netiq.attachmategroup.com and novell.attachmategroup.com, it is possible to have a single WINS server catering to both domains in the forest. However, for load balancing we recommend 2 WINS servers, that is one WINS server per domain.
5.1 Purpose: As mentioned before, while kerberos is the default and widely used authentication method in AD environment. There are some applications which require that ldap authentication be done using NTLMSSP. To make DSfW compatible with such applications we are introducing support for NTLMSSP authentication in OES11SP2.
5.2 Execution of ldap over NTLMSSP: In DSfW server when the SASL NTLMSSP bind happens in ldap, in OES11SP2 it is no longer an error scenario.
The functionality was achieved by extending one of the NMaS methods.
5.3 Limitation of Support: While DSfW server should now honor all applications authenticating using SASL NTLMSSP over ldap, the support is limited to one particular application, Polycom that is.
New client platforms will be supported from OES11SP2 onwards. Client platforms now supported are Mac10.8.X and above, Windows 8 and above, and also environments having Novell Client installed.
While many use cases involving these clients worked before also, but this was never a NTS supported scenario. Now NTS will claim support for these.
We are introducing a new procedure to involve Novell consulting in complex environments from the very beginning of setting up of DSfW forest.
In the first installation screen itself we give specific recommendations to the domain administrator. He is made aware of the fact that complex installations like those having 2000 users require help from consulting services.
(We have had situations in past where big customers ended up installing complex Domains without engaging with consulting. Troubleshooting these setups took lots of bandwidth of engineering, NTS and also customers. Hopefully such situation can be avoided with this initiative).
Also, we have written a Best Practices Guide in OES11SP2. This guide integrates the experiences of engineers, consultants and also NTS in a structured manner. Objective is to share the learnings from past experiences to help administrators build optimal domains. The text of the screen contains link to this new guide.
Administrator needs to confirm that he has thought about setup considerations and studied Best Practices Guide by selection of checkbox, as is shown in the following screenshot.
As always, the overall objective of these features is to make our customers more productive, and at the same time keep the domain secure. So if there is any feedback related to these features or any new features that you think will be useful, do share that feedback at appropriate forum.
The following links can be followed to understand DSfW and some of these features.
 DSfW Administration Guide for OES11SP2 - http://www.novell.com/documentation/oes11/acc_dsfw_lx/data/bookinfo.html#bookinfo
 Sites and Subnets Feature Documentation - http://www.novell.com/documentation/oes11/acc_dsfw_lx/data/b15y1rp8.html
 WINS integration to DSfW - http://www.novell.com/documentation/oes11/acc_dsfw_lx/data/b15y24oh.html
 Using Mac Client - http://www.novell.com/documentation/oes11/acc_dsfw_lx/data/srvc_fpn.html
 DSfW Best Practices Guide -https://www.novell.com/documentation/oes11/dsfw_bp_lx/data/bookinfo.html