Directory action

Directory action

Microsoft has decided to support NDS on its Windows NT networks. But, has Novell taken too long to convince Microsoft of the merits of NDS considering Microsoft's own Active Directory is looming on the horizon? Ian Yates examines the issue . . .

Novell promised to do it and it did. Novell Directory Services (NDS) is now available as a native Windows NT application. For small companies with one domain and no NetWare servers, the reaction to this news may be "so what?" But for companies with existing NetWare servers and a smattering of new NT servers, being able to manage the whole thing with one admin toolset rates up there with winning the lottery. And if the company is so big it needed to use multiple NT domains, NDS works better than a bucket of aspirin. But is it too late?

Active Directory, Microsoft's counter to NDS, ships with Windows NT version 5 and is due sometime this year. Will users make the move to NDS or just put up with the headaches of domains until NT 5 ships?

At best Novell may have a six-month window, during which it is the only directory in town. After that, Active Directory will be boasting it can take over from NDS and manage your NetWare servers as well as your NT servers. The rise of NT shows no signs of abating. It may well be this momentum that nails Novell to the network coffin along with OS/2 server.

At first Microsoft refused to play, took its directory bat and ball and went home. However, the level of noise generated by the media and end users was instrumental in causing an about face. Microsoft calls this "clarifying its position". We call it capitulating, but it was the right decision. You can't win the software wars by being a bully any more. And no doubt some genius at Redmond figured that if you're buying NDS for NT it means you probably have NetWare already, and they shouldn't make it harder for you to move some NT servers into that red computer room. So for now, Microsoft says NDS is OK if you must use it, but still advises you to wait for NT 5 and the "better" option of Active Directory.

Just so you'll know where each side stands, here are the official statements from the two adversaries. Maybe you can then figure out where you and your customers stand. Can you spell Unix?

Microsoft says:

Recently, there have been a lot of questions regarding Microsoft's support for Microsoft Windows NT Server customers who deploy NDS for NT from Novell. Any customer who uses NDS for NT can expect full support for Windows NT Server code from Microsoft. However, NDS for NT replaces an internal piece of the Windows NT Server operating system related to the directory and security portion of the system. Customers who need support for NDS on NT should contact Novell if their problems concern security and directory.

Customers should be aware that deploying NDS for NT could lead to significant implications, including:

Support and reliability

Novell is replacing an internal system DLL (samsrv.dll). This DLL is critical in that it implements a key part of the directory and security infrastructure in Windows NT Server. Microsoft has been enhancing the functionality of this module in virtually all Service Packs. For example, Service Pack 3 for Windows NT 4.0 contains changes that are not reflected in Novell's replacement of this DLL. The next Service Pack also updates this file.

Upgrading to future releases of Windows NT ServerBecause NDS for NT replaces an internal part of the operating system, servers with NDS for NT installed will not upgrade to Windows NT Server 5.0 correctly (for example, if any new local users have been created). The automatic upgrade to Windows NT Server 5.0 uses internal database information to do the upgrade which is not available once NDS for NT is installed.

While Microsoft understands Novell is trying to solve a very difficult problem -- easing directory management -- NDS for NT is not an interoperability solution because it doesn't maintain the state of both directory systems NDS for NT forces customers to replace a critical internal piece of security code on every Windows NT Server operating as a domain controller. It is an NDS-only solution.

Was there another approach for directory management that could have been used?

If Novell wanted to deliver an interoperability solution that works with what customers already have deployed, it could have built a directory synchronisation tool using the published Active Directory Service Interfaces (ADSI).

ADSI, the industry standard for accessing directory services from any vendor, allows third-party developers such as Novell to integrate their solutions into the Windows NT Directory Service. This, too, would have allowed Novell to synchronise the two directory services without replacing Windows NT Server code and manage both directories from NDS.

This solution would have been better for customers because it would allow both systems to coexist without forcing customers to replace what they already have. In fact, Microsoft's strategy with Windows NT Server 5.0 and Active Directory is to deliver an NDS directory synchronisation tool through native support for NDS protocols. This is a solution that will allow customers to manage their mixed environments from Active Directory. Customers can be assured this solution will not require them to replace any code on their NetWare servers. And, it will allow them to continue to leverage their investment in NDS.

Novell says:

We have been overwhelmed with the positive customer response from Novell and Microsoft customers. The vast majority want the two companies to work together to support our mutual customers.

We are also glad to see that Microsoft reversed its position and will support its customers who are running NDS for NT. It may be a welcoming thought that even while Microsoft made its previous "no-support" statements, both companies' support organisations were working out details on how to support customers who are integrating their domains into NDS for NT.

In addition, both organisations have agreed to cooperate to resolve issues on behalf of our mutual customers wherever the customer's problem lies. We have been informed that Microsoft will be advising its "premier" customers that Microsoft will treat NDS for NT as just another third-party application.

If you consider Microsoft's comments about supporting customers running NDS for NT, you don't have to read very far before you realise it simply does not want customers to buy NDS for NT. Whether Microsoft feels threatened or not shouldn't be the issue; for the customer the issue is that NDS for NT helps them integrate NT's strengths into the enterprise while reducing its cost and complexities.


Novell will provide NDS for NT updates which will parallel Microsoft's service packs.

So, how common is it for a third-party NT application to replace a DLL? In fact it is quite common. Citrix Winframe, a product Microsoft fully endorses, does extensive modifications to the OS.

We understand Microsoft must provide frequent service packs to correct stability and security related problems in NT Server. But Microsoft is unlikely to make any changes that adversely affect all BackOffice applications, which would be the case if they did something to intentionally disable NDS for NTNovell will quickly make available NDS for NT updates that reflect Microsoft's Service Pack changes. As a Microsoft developer, we get early notification of service pack releases.

Novell has also taken steps to ensure the application of service packs that replace SAMSRV.DLL will not impact system performance. If a service pack overwrites Novell's SAMSRV.DLL, NDS for NT will restore Novell's SAMSRV.DLL, ensuring the NT Server operates normally. Novell has tested and verified that NDS for NT will function after a service pack update that replaces SAMSRV.DLL.


Novell doesn't impact Microsoft's security; instead we add NDS' security to domain information and protect NT networks from hackers.

Novell adds NDS security to protect domain information and does not touch NT's security model. NDS for NT does not impact any of the client to server or application security services. It modifies a single DLL responsible for storing and fetching domain account information out of the registry. All NT authentication and security functions are handled by other systems within NT, and are not affected by NDS for NT.

NDS for NT incorporates Intruder Detection Lockout, which locks out anyone who doesn't correctly enter their password in a certain number of attempts. The potential "hacker" is then locked out for a certain amount of time from all domains, which isn't the case with standard NT domains where someone can "hack" in with accounts in each domain. NDS' architecture protects your entire network, whereas NT domains only secure each domain separately.

NDS for NT does not impact NT's security model, but does wrap our RSA public/private key security around the domain information stored in NDS.

Customers who implement NDS for NT are protected from many of the dangerous NT security threats that exploit the registry-based account information, such as the popular L0phtcrack utility, which determines a user's password by examining the contents of the registry. NDS for NT further encrypts NT password information and stores this information in NDS. Novell has tested and verified that NDS for NT completely negates the popular L0phtcrack utility, thereby improving NT Server security.

Microsoft NT Server is not C2-certifiable in a network with or without NDS for NT. It is only C2-certifiable as long as it does not have a network interface card and is not connected to a network. In fact, by adding any software including Microsoft's own NT Server service packs, you break the Trusted Computing Base (TCB) and guarantee NT Server to not be C2-certifiable.


Novell provides a way for you to migrate domain information back to domains and Microsoft is promising a way to migrate from NDS.

In fact, NDS for NT gives customers no-risk flexibility if they choose to migrate to Active Directory. NDS for NT is no-risk because we will tightly integrate with the future NT 5.0 and simple migration if you so choose.

First, NT 5.0 will support both the NT domains and Active Directory. Therefore, there will not be a pressing need at the release of NT 5.0 to move immediately to Active Directory. Many BackOffice applications will not be Active Directory-enabled until well after NT 5.0's release. In fact, with the interoperability Microsoft is planning you may not need to move your information to Active Directory at all. So consider waiting until Active Directory technology is a little more mature before considering your migration.

Secondly, customers can "reverse migrate" NDS information back into the registry-based SAM database before upgrading to NT Server 5.0. The customer has the choice of either migrating back to the initial NT domains or migrating back with all the domain changes made while in NDS. During a reverse migrate, all NT domain information including users, group memberships, trust relationships and local machine accounts will be created within the registry-based SAM database on the NT Server and will eliminate all NDS for NT software and configuration information. In effect, the simple reverse migrate process allows customers to back out of their NDS for NT configuration at any time without any loss of NT account information or NT Server functionality. The upgrade to NT Server 5.0 will then proceed as if NDS for NT was never installed. This process has been successfully tested by Novell using Microsoft's Beta 1 of NT Server 5.0.

Third of all, Microsoft has announced tools for migrating NDS information directly to Active Directory. If a customer decides to migrate from NDS to Active Directory, Microsoft has committed to providing the necessary migration tools.


Our customers implored us to use our advanced directory technology to manage their network from one directory so they do not have to design and manage costly NT domains and domain trusts separately.

Novell has also subjected NDS for NT to tests against the BackOffice Suite to ensure interoperability, and will seek BackOffice certification. However, there is only one roadblock Novell may face; Microsoft has the final word on who becomes BackOffice certified.

In a primarily NT network, NDS for NT does not require the NDS client or changes to any existing workstation connecting to an NT Server. This is further proof we do not impact system security infrastructure.

Customers like the single login and single point of administration that NDS for NT gives them and we do it without replacing any client code or affecting the client/server communication -- the synchronisation product that Microsoft says we should have created (and we did over a year ago with the release of Novell Administrator for Windows NT).

Any domain directory synchronisation solution still requires design, implementation and management of domains and trust relationships, and doesn't allow for flexible, network-wide reporting. That's why customers are more excited about NDS for NT -- because none of that is necessary.

Is there a better way?

We are helping to champion LDAP as the industry standard for accessing and interoperating with directories; however, he standard isn't mature enough to provide customers with the solution they want.

Microsoft is correct in saying we should integrate with their future directory through ADSI. So if we had used ADSI, we wouldn't have been able to ship our solution until NT 5.0 ships. ADSI is Microsoft's proprietary method for accessing Active Directory and a lowest common denominator for other vendor's directories. They have marketed ADSI as a set of open APIs for accessing their future directory information. We will integrate with NT 5.0 and will have full support for ADSI. Not only will we support ADSI, but server and client side ActiveX controls as well, and we have already shipped an OBDC interface for Visual Basic developers.

Reduction or elimination of trust relationshipsWhile NDS for NT fully supports trust relationships, they are no longer necessary, even in multiple domain deployments. Customers may reduce or eliminate trust relationships with NDS for NT, thereby reducing complexity and associated management costs.

Controlling users and groups

NT Server's current domain structure does not allow delegation of administrative rights among users. With NT Server, you'll either have all management rights over users and groups in the domain, or no management rights at all. NDS for NT brings more granular administrative capabilities, allowing delegation of administrative rights over a subset of the users and groups within the domain. With NDS, you can manage by setting up automatic policies and letting NDS' rights inheritance provide the proper rights at all levels of network administration, instead of setting up and administrating excessive groups.

When NT Server is not available

If you can't reach the primary domain controller in a standard NT domain, you can't manage your network. With NDS for NT, customers may manage NT users and groups even if the NT Server is not available. There is no need to "promote" a backup domain controller-NDS as NT eliminates the hassle.

Moving NT users between domains

Without NDS for NT, moving an NT Server user between domains requires deleting and recreating the user's account -- a painful task for both the administrator and the user. With NDS for NT, moving a user between NT domains is as simple as a single mouse click.

Making NT deployments more flexible

By eliminating trust relationships and providing delegation of administrative rights, NDS for NT customers gain greater flexibility when deploying NT Servers. Limitations in the NT Server domain structure dictate how NT will be deployed by force-fitting every customer into a rigid domain deployment model. NT Server customers cannot deploy NT Server as they wish; rather, they must change their businesses to fit one of NT Server's domain deployment structures.

If you've taken the time to explore NDS on your NetWare servers, you'll know that it is truly a "good thing".

A lot of people have just clicked on the "bindery emulation" switch and ignored the NDS completely. That is a mistake because it really is a better way to manage users and network resources.

That means it would be a good thing on NT as well, and far better than what is currently offered by Microsoft.

Will it be better than Active Directory? Well, who knows? When NT 5.0 ships you'll get a better chance to compare. However, you won't be able to run the entire back office suite from Active Directory on day one, unless there is some very feverish activity in the Microsoft bunkers between now and then. That means you'll be running the old domain system regardless.

NDS is available now and also lets you revert to the domain system should you need to.

If you have clients who need multiple domains and trusted domains to make their network operate, you should have a good look at NDS. It really is easier once you spend an hour or two to get familiar with the concepts. And now it's supported by Microsoft.

Follow Us

Join the newsletter!


Sign up to gain exclusive access to email subscriptions, event invitations, competitions, giveaways, and much more.

Membership is free, and your security and privacy remain protected. View our privacy policy before signing up.

Error: Please check your email address.

Brand Post

Show Comments