As the deployment of Windows NT servers becomes more
widespread, there is an increasing realisation that maintenance and administration of
Windows NT domains is expensive, and consumes valuable time on the part of skilled IT
staff. In a climate of acute awareness of the total cost of ownership of IT
infrastructures, these costs are receiving increasing attention, and it’s this that
Novell is hoping to exploit with the launch of NDS (Novell Directory Services) for NT
version 2.0.
Microsoft Exchange
The tremendous administrative benefits of enterprise-wide directory services, and the
importance in them being secure and reliable, are becoming appreciated by vendors and IT
staff alike. This is particularly brought home when trying to implement Microsoft
Exchange, already a costly exercise. A significant part of a recent consultancy contract
awarded to Unisys by the Department for Education and Employment was to reorganise the
Windows NT domains to provide a suitable foundation for the implementation of Microsoft
Exchange.
In a time of skills shortages, organisations would generally prefer that their IT staff
are contributing business value, rather than performing mundane administrative tasks such
as maintaining Windows NT domain trust relationships. "An IT department that’s
just doing factory work is liable to end up being replaced by facilities management,"
warns Dave Stewart, Technical Director for ICL’s Applications and Technical
Consultancy. Novell’s intention with NDS for NT is to substantially reduce the cost
of administering Windows NT servers and applications. There are very obvious benefits for
those sites with both NetWare and Windows NT, but Novell feels that the advantages of
adding NDS to pure NT sites are also worth a look. "If people are happy to accept
bringing a Windows NT server into a NetWare environment, then why not the other way
round?" asks Derek Venter, Regional Product Marketing Manager for NetWare and NDS.
NDS for NT Version 1.0
With version 1.0 of NDS for NT, Novell produced a product with the
primary objective of facilitating administration in a mixed Windows NT and NetWare
environment. By so doing, Novell actually made it much easier for NetWare sites to
consider introducing Windows NT without adding a major administrative burden. In mixed
environments, NDS for NT achieves both a single login for users and a single point of
administration for network support staff. With the same username and password, users are
authenticated to the NetWare servers – for access to resources such as BorderManager,
GroupWise, file and print – as well as to the Windows NT domain(s), for access to any
Windows NT resources. Maintenance tasks become much easier, because user and domain
objects in NDS start to benefit from NDS features like rights inheritance, the ability to
move objects, and an easy-to-use drag-and-drop interface.
NDS for NT has been designed to be very easy to install; in particular, nothing needs to
be changed on any of the client PCs, or Windows NT server applications. There would be
little business benefit to be gained from NDS for NT if it reduced on-going administration
but required a massive investment in terms of re-configuring desktop machines and
upgrading enterprise packages. By intercepting calls for authentication to the Windows NT
SAM (Security Accounts Manager) database and then redirecting them to the NDS directory,
NDS for NT ensures that all existing applications and even Windows NT administration tools
will work unmodified. On this occasion at least, Microsoft has disciplined itself to only
access the SAM database via the official interface, and hence all authentication and
administration requests can be successfully redirected by Novell’s software.
Domain simplification
Designing Windows NT domain implementations inevitably involves compromise between
flexibility, granularity of control, administrative burden and hardware cost. Recognising
the limitations of domains, Microsoft now suggests the master domain model, where all user
accounts are held in one single domain, with separate resource domains for servers,
workstations and printers. Even if this was desirable, it requires the painful step of
setting up and maintaining administrative accounts on every single server. Unfortunately,
most organisations deploying Windows NT have domain models that have grown organically
over time, and changing to the master domain model is an expensive and difficult option.
Novell’s claim is that NDS for NT reduces domain design and implementation costs.
With NDS for NT, a domain becomes an object within the NDS directory like any other. Now,
instead of having to visit multiple domain controllers to set up accounts for a new user,
a network manager can, through a single point of administration, readily give a user
rights to as many domain objects as necessary. Thus, you only need a single user account
instead of multiple ones, and there is no need to maintain domain trust relationships. The
resultant administrative savings, even in a pure Windows NT environment, can be quite high
although this will depend on the domain model. Gartner Group estimates that NDS for NT can
cut administrative costs by up to 40% in a Windows NT enterprise.
Implementation
Where NetWare and NDS already exist within an organisation, implementation of NDS for NT
simply requires the installation of the NDS for NT software to each domain controller.
Thereafter, all administration of both Windows NT accounts and NetWare accounts is carried
out using Novell’s NWAdmin tool, against the NDS directory. You can also continue to
use standard Windows NT tools, such as the User Manager for Domains, if you wish.
Although it is clearly advantageous that the Novell software is completely transparent to
any NT software or administrative tools, there is a drawback. Existing domain controllers,
and their backup controllers, must stay in place – workstations will continue to
carry out authentication against these systems, even though the authentication is
subsequently redirected to NDS. Thus, for existing NT domain configurations, there’s
no potential hardware saving – you can’t get rid of the domain controllers, and
if you want any resilience, you can’t even get rid of the backup domain controllers.
At least in a mixed NetWare and NT environment, there will be no additional hardware
requirement. On a pure NT site, the administrative savings would normally be sufficiently
attractive to warrant the expenditure on the additional hardware needed to host NetWare,
but the situation is very different if you have branch offices with NT domain controllers.
In this environment, to use NDS for NT would either require using the WAN link for every
authentication (which may be slow, and/or entail bringing up an ISDN line) or install a
NetWare server at every branch.
At installation time, the process of moving user, computer and domain objects into the NDS
directory is simplified with a Domain Object Wizard. Administration of Microsoft Exchange
is made easier with the Mailbox Manager for Exchange, which forwards all changes made
using NWAdmin to the appropriate Exchange server.
NDS for NT Version 2.0
NDS for NT version 2.0, launched earlier this year, was designed specifically to solve
this problem. With version 2.0, it’s now possible to host a replica of an NDS
directory on a Windows NT domain controller. User administration may be carried out
directly against this replica, using the standard Novell tool NWAdmin.
This replica is not intended to become a stand-alone NDS directory. Although normal
day-to-day remote administration of the replica hosted on NT is possible, not all of the
more advanced administration and repair tools are available for NT. Hence, there must
always be a master copy of the NDS directory somewhere hosted by NetWare. But what this
does mean is that branch offices that only have Windows NT domain controllers and no
NetWare servers can now hold a local replica of the enterprise NDS directory. Logins
taking place at the branch will take place directly against this replica, with no need to
generate WAN traffic.
Other improvements in version 2.0 include enhanced password synchronisation, so that if a
user is forced to change one password because of expiry then all other passwords are
automatically changed too, preserving the single sign-on metaphor. If you change the
domain password using the Microsoft utilities, NDS for NT detects this and changes the NDS
password. The other way round only works in a mixed environment, where you have the Novell
client software running on the actual workstations. In addition, Windows NT Shares can now
be included as objects within the enterprise directory. Thus, instead of having to set
access rights to shares on an individual server basis, you can set them from one central
administrative point, using NWAdmin.
Next version of NDS for NT
With the next version of NDS for NT, version 2.1, Novell will remove the need to use IPX
at all. Currently, there must be an IPX stack on the Microsoft domain controller that is
running the NDS for NT software, although this is not exactly difficult to install.
However, you will still need a NetWare server somewhere (in practice, more than one for
reliability) to host the main NDS directory. A future version of NDS for NT will add full
support for an NDS tree entirely hosted by Windows NT, removing the need for a NetWare
server entirely. This will make the product far more attractive to NT-only sites. A
version that includes support for Microsoft Active Directory is already being tried by
some Novell customers under an early access programme. Even in its current guise, NDS for
NT offers clear benefits for Windows NT administration. And anything that cuts down time
spent on mundane tasks like user account maintenance and frees up IT staff to respond to
the heavy demands for real business benefit from IT that users are making today, is to be
welcomed.
