Novell Home

 

NOTE: Domain Services for Windows is coming soon! Watch for it in Novell Open Enterprise Server 2 Support Pack 1, scheduled for release in 2008.

Complexity seems to be a way of life for many in the IT world. Maybe that’s why Novell constantly seems to be looking for new ways to reduce complexity for its customers. This drive towards simplification is keenly evidenced by the new Novell Domain Services for Windows feature debuting in Novell Open Enterprise Server 2. Novell Domain Services for Windows provides seamless cross-authentication between Windows Active Directory environments and Linux eDirectory server environments for file and print services.

"In addition to eliminating the requirement for the Novell client, one of the biggest benefits that Domain Services for Windows provides end users is that it eliminates multiple logins if they need access to both Active Directory- and eDirectory-based services."

This new component in Novell Open Enterprise Server 2 had its genesis when some customers indicated that while they want to take advantage of Novell file and print services on the back end, they prefer to streamline the clients required on the front end. Novell Domain Services for Windows delivers this exact functionality, enabling Linux servers to appear as if they are Active Directory servers, such that users can log in and authenticate to a Linux server with their native Windows clients using their eDirectory usernames and passwords.

> Trust—Not Synchronization
You should know that Domain Services for Windows is not a directory synchronization solution. Rather, a cross-domain or cross-forest trust can be created between Active Directory and a Novell Domain Services for Windows domain. (See Figure 1.) This trust relationship enables each user to be represented by a single user account, whether that account resides in eDirectory or Active Directory.

Domain Services for Windows Architecture

Novell Domain Services for Windows requires eDirectory version 8.8 SP2, but a number of other key components have been modified to enable the solution to facilitate the coexistence of Active Directory and Novell eDirectory deployments. (See Figure 3.) These key components include:

  • LDAP Server: A NAD virtualization layer has been added to NLDAP that virtualizes the Active Directory information model within eDirectory so LDAP requests are handled appropriately. This enables LDAP under Domain Services for Windows to support the standard protocols used by the Microsoft Management Console.
  • NMAS: The NMAS secure authentication layer has been extended to support the Microsoft encryption mechanism so native Windows clients can securely authenticate to eDirectory, just as if they were authenticating to Active Directory. This includes NMAS extensions for Kerberos for GSSLSM and SAMSPM. GSSLSM supports GSS-API authentication mechanisms, and SAMSPM generates NTLM and Kerberos keys when a user’s universal password is changed.
  • Directory System Agent: An Active Directory Provisioning Handler (ADPH) has been added to the Directory System Agent to provide agent-side support for the Active Directory information model. It enforces Active Directory security and information models. It allocates Security IDs (SIDs) to users and groups. It validates entries and enables existing eDirectory users and groups to use Active Directory and RFC 2307 authorization.
  • Kerberos: A specialized Kerberos Key Distribution Center (KDC) based on MIT KDC 1.6 has been specifically developed for Domain Services for Windows to provide Active Directory-style authentication.
  • Domain Services Daemon: This daemon provides support for legacy Windows RPCs, including Local Security Authority, Security Accounts Manager and Net Logon.
  • CIFS: The CIFS file services provided by the SAMBA 3.x software that comes with SUSE Linux Enterprise Server 10 and Novell Open Enterprise Server 2 has been modified to allow it to join a local Domain Services for Windows domain.
  • DNS: The DNS server has been modified to support Generic Security Service-Transaction Signature (GSS-TSIG), a Kerberos secured dynamic updates authentication method used by Windows XP and Windows 2000.
  • NTP: The NTP server has been modified to support the signing of NTP responses with workstation shared secrets used by the Active Directory security model.

For example, when you install a Domain Services for Windows domain in your eDirectory tree, the AD Provisioning Handler (ADPH) automatically provisions all of the objects in that domain with the appropriate Active Directory attributes. (See Domain Services for Windows Architecture.) This means that your eDirectory users not only can authenticate to Novell file and print services using their native Windows clients, but its seamless cross-authentication capabilities enable those users to use their eDirectory usernames and passwords to authenticate to Active Directory services as well.

This also means that whether the user objects reside in eDirectory or Active Directory, users can access file services regardless of server platform or operating system. So, they can map drives or access Novell Storage Services volumes on Linux servers using SAMBA shares, or NTFS files on Windows servers using CIFS shares. In terms of print services, these users can leverage either Windows server printing handled by the Windows printing subsystem or Novell server printing handled by Novell iPrint. Print operations with iPrint don’t require the Novell client, except in the case of secure printing or authorized printing.

"The automatic provisioning of eDirectory objects along with other Domain Services for Windows components allows eDirectory objects to be viewed or administered by Microsoft Management Console such that they look like they are objects in an Active Directory domain."

> Single Object, Single Password
In addition to eliminating the requirement for the Novell client, one of the biggest benefits Domain Services for Windows provides end users is it eliminates multiple logins if they need access to both Active Directory- and eDirectory-based services. Now that their user objects, with their associated user rights and attributes, only have to reside in one directory—either eDirectory or Active Directory—the trust relationship enables them to employ a single password for the services provided by either directory. From an IT perspective, this also greatly simplifies user management since objects for those users only need to be maintained in one directory repository instead of two.

A typical scenario might be that your organization relies primarily on eDirectory-based file and print services, but you have a few key third-party applications that require Active Directory. In the past you would have had to maintain user objects in both eDirectory and Active Directory. Likewise, your users would have had a different login for their Active Directory-based applications than they did for their Novell services. Domain Services for Windows eliminates the need to have redundant user objects in both Active Directory and eDirectory by simply moving these objects into your Domain Services for Windows domain in eDirectory.

"Domain Services for Windows allows you to reduce your workstation image library by half since you can now have a single workstation image for both your Active Directory and eDirectory users."

As a result, your users will only need a single password for the different services, and you’ve simplified your IT administration by eliminating the need to manage the same users in two different directory repositories. Domain Services for Windows will also automatically provision user objects with universal passwords for applications and services (such as SAMBA) by implementing Active Directory password policies over universal password policies. This eliminates the need for you to create and maintain your own specialized infrastructure for provisioning universal passwords.

Know that Domain Services for Windows uses an almost identical authentication mechanism as that used by Active Directory. More advanced services such as Microsoft Exchange require authorization, something Domain Services for Windows does not currently provide.

> More IT Simplification
In addition to eliminating redundant user objects in eDirectory and Active Directory, Domain Services for Windows simplifies your IT efforts in other ways. One of these is that you don’t have to train or force your IT personnel to use administration tools they’re not familiar with. Domain Services for Windows allows administrators to do basic administration of users and groups with either iManager or Microsoft Management Console, regardless of whether the user or group object is stored in eDirectory or Active Directory. (See Figure 2.) So, if they’re more comfortable with iManager, they can use it to perform basic user administration in either eDirectory or Active Directory. Likewise, if they have more experience with Microsoft Management Console, they can use it for basic administration of users in either Active Directory or eDirectory.

Primer on Active Directory

For those not as familiar with Active Directory, here’s a brief primer on a few of its aspects.

  • Domain: In Active Directory, a domain is a security boundary and is similar to a partition in eDirectory. Each Active Directory domain that is configured to act as a Global Catalog has a Global Catalog that stores a full copy of all Active Directory objects in the host domain and a partial copy of all objects for all other domains in the forest.
  • Forest: A forest is a collection of Active Directory domains and is comparable to a tree in eDirectory.
  • Trust relationships: You can set up trust relationships to share authentication secrets between domains. Federation can be accomplished through establishing cross-domain and cross-forest trusts.
  • Domain Class: Active Directory uses domain class (DC) naming at the root of a partition, as opposed to the X.500 naming used in eDirectory. For example, in eDirectory a partition might be specified as ou=sales.o=company, while in Active Directory the partition would be specified as ou=sales,dc=company,dc=com.
  • AD security model: The Active Directory security model is based on shared secrets. The domain controller contains all users’ keys. The authentication mechanism is based on Kerberos.

The automatic provisioning of eDirectory objects along with other Domain Services for Windows components allows eDirectory objects to be viewed or administered by Microsoft Management Console such that they look like they are objects in an Active Directory domain. It also provisions your eDirectory objects such that you no longer need to Linux-enable your Windows users in order to give them access to SAMBA shares.

Be aware, however, that this cross-management capability is limited to basic operations such as creating users, deleting users or making basic modification. You wouldn’t be able to use iManager to modify granular attributes or policies for a user in Active Directory, nor could you use Microsoft Management Console to do similar low-level operations on eDirectory users.

Another way that Domain Services for Windows simplifies IT administration is in the area of maintaining your workstation image library. Perhaps in the past you’ve had to maintain one set of workstation images for your Active Directory users and another set for your eDirectory users. Domain Services for Windows allows you to reduce your workstation image library by half since you can now have a single workstation image for both your Active Directory and eDirectory users.

> Deploying It
You might implement Domain Services for Windows in a number of ways, but the most common way for customers that have an existing Novell infrastructure and want to run with mixed-client configurations would be to install a new Domain Services for Windows domain inside an existing eDirectory tree. This scenario allows existing eDirectory users that become part of the new domain to work without the Novell client while allowing other users to continue running it.

Another scenario would be if you have no existing Novell infrastructure, but want to experiment with ways to eliminate costly MS servers. In this case you could install a new Domain Services for Windows domain in a new eDirectory tree and have it emulate an Active Directory forest.

Maybe you’re familiar with the advantages that Novell Storage Services provides over other file systems. If so, you could implement Domain Services for Windows, deploying and managing your data using Novell Storage Services as your file system of choice. This would let you manage your data using native Novell Storage Services tools, while also making data accessible to your users via SAMBA without requiring the Novell client.

Or perhaps you don't need to take advantage of the Novell Storage Services file system, but still want to deploy SAMBA servers with the Active Directory support that Domain Services for Windows provides instead of the NT-style protocols that plain SAMBA 3 servers support. To address this situation, you could implement the solution to deploy and maintain your data using a POSIX file system rather than a Novell Storage Services file system. In this scenario, user objects would be stored in the Domain Services for Windows domain in eDirectory in the same way they are stored with Novell Storage Services, but all file system access control would be done with POSIX commands rather than with Novell Storage Services commands.

Since the first scenario of installing a new Domain Services for Windows domain inside of an existing eDirectory tree will be the most common implementation, we’ll discuss some of its aspects.

Before installing it, you’ll want to make sure you have a good idea of what your long-term use for the solution will be. Will it only be used by a small group of users, such as a satellite office or a specific department? If that’s the case, you might want to place the domain in a container that contains those specific groups. If you want the majority or all of your users to be able to take advantage of Domain Services for Windows, you’ll probably want to deploy the domain near the top of your eDirectory tree.

You can install the solution from within YaST during or after you install Novell Open Enterprise Server 2. When deploying it during your server install of SUSE Linux Enterprise Server 10 SP1 and Open Enterprise Server 2, do the following:

  1. Select the Novell Domain Services for Windows pattern from the OES Services category under Installation Settings | Software. YaST will then automatically select any other software packages required for Domain Services for Windows. Note: Novell SAMBA will not be selected, because even though the Domain Services for Windows pattern does include SAMBA, it configures it differently than a regular Open Enterprise Server installation.
  2. Complete the server installation as you would for a normal Open Enterprise Server 2 installation.
  3. When you reach the Open Enterprise Server configuration portion of the installation, configure Domain Services for Windows along with eDirectory. While you configure your Domain Services for Windows server in a new eDirectory tree, also create a new domain in a new forest, and your Domain Services for Windows server will be automatically configured as a domain controller. You have the option to make the server your primary DNS server, or you can use your existing DNS infrastructure as along as it is based on SUSE Linux Enterprise Server 10 SP1 or Windows 2003.
  4. On the screen titled eDirectory Configuration-New or Existing Tree, select Existing Tree, specify the tree name and mark Configure Domain Services for Windows.
  5. On the next screen for the domain type, select New Forest. Specify the DNS name and choose whether or not you want to configure this machine to be a primary DNS server.
  6. On the next screen, specify the NetBIOS name for the new Domain Services for Windows domain. By default, the domain NetBIOS name is the domain context name without the parent context. This is the name that will display in the Windows login dialog when users log in to the domain.
  7. The next screen allows you to enter your existing eDirectory server information. The LDAP port and Secure LDAP port should be set to 389 and 636, because these are the default ports that Microsoft Management Console uses for LDAP.
  8. On the next screen, specify the name of the container in the existing tree and select Convert this container to a container in the new domain.
  9. Finish the remainder of the configuration and installation as you would for a normal Linux installation of Open Enterprise Server 2.

Also, as you complete the installation, be sure to accept the defaults on the CA Management screen, specify a reliable Network Time Protocol provider and accept the default of Local for the User Authentication Method. If you have fewer than three servers on your network, you do not need to set up Service Location Protocol. Also, in the NMAS Methods selection screen, you don’t need to select SASL GSSAPI, because the GSSAPI authentication mechanism that Domain Services for Windows uses will be installed automatically.

> A Simple Answer

Simplifying means different things to different people. For some it might mean only having to manage one user account in one directory per employee. For others it could be finding a way to make it easier for users to access the services they need. Reducing the number of workstation images you have to maintain might be how you want to simplify. Or maybe it’s facilitating an administrator's ability to manage users in a multi-directory environment. Whatever the case, when it comes to simplifying your IT environment, Domain Services for Windows might just be the answer you need.


© 2014 Novell