Making Mac OS X play nicely with Novell

Novell's NetWare and eDirectory are still major presences in many organizations today, particularly in some education markets. But fully integrating Mac OS X with both NetWare and eDirectory poses a unique set of challenges to systems administrators. The solutions are not as simple or as "out of the box" as they can be for integrating Mac OS X into a Windows/Active Directory environment, for instance.

In fact, the process of linking NetWare and Apple often requires much greater planning and testing, and the use of third-party software.

Novell client vs. NetWare Loadable Modules

Novell uses two methods of communication with client computers in a network. The first is client-based software that manages the client's interaction with the Novell server(s). This client authenticates user access to both the computer and to network resources. It can use Novell's authentication and encryption techniques to securely transmit log-in information and to secure file access.

Windows users of a computer on which the Novell client is installed will see a Novell log-in dialog at startup instead of the traditional Windows log-in dialog. The Novell client's typical installation also includes a variety of tools for tasks such as browsing servers within the Novell network, using network printers and even messaging other users.

The alternative to relying on Novell's client is to install NetWare Loadable Modules (NLM) on the Novell server(s). NLMs extend the functionality of the server and are produced by both Novell and third parties. Novell includes NLMs for what it refers to as Native File Access. These NLMs essentially provide the framework for the server to authenticate users and deliver access to resources using protocols native to other platforms, such as Apple Filing Protocol (AFP) for Macs and SMB/CIFS (Server Message Block/Common Internet File Services) for Windows.

In a Windows-only environment, advantages to using client software are that this method doesn't require overhead on the server and it ensures Novell's authentication and encryption techniques are supported by the client. It also ensures access to directory services and allows authentication of user log-in.

The disadvantage is that it must be installed (and periodically updated) on every client.

In contrast to the Windows-only environment, Native File Access (NFA) for a Mac requires little if any modification on the client, but it produces some overhead -- usually minimal -- on the server. And it doesn't always provide the most secure communication methods.

However, Novell does not produce a Mac client version of its software. As a result, Novell admins needing to support Macs must rely on NFA or they must use third-party software.

Using NFA presents some major challenges. While NFA provides authentication and access to shared files and printers via AFP, it does not provide any way to authenticate user access to local computers. When users log in at a Mac, they must use a local account stored on that computer rather than a network account. This prevents the ability to fully secure access to workstations.

This also means that when users log into a Mac, they will have access to any files that other users -- or at least others using the same local account -- have created on the Mac's hard drive. It also means that if a user logs into different Macs, no information will follow them except for files that they have explicitly placed in a network storage location.

Both of those situations can be major issues for Mac users to deal with, and under normal circumstances, they are mitigated when Macs are used in either a Windows Active Directory environment or in a Mac OS X Server infrastructure. But it's not so simple in a Novell world.

Depending on your Novell configuration, password management can also be a challenge when using NFA. Because NFA doesn't use the Novell client, it cannot support the full range of authentication and encryption techniques available to Novell servers. A simple password is often set -- either by an administrator or by the server at a user's first NFA log-in -- for users who log in from a Mac. The simple password is not as secure as an eDirectory password and may even be sent in clear text in some cases, meaning it's readable by just about anyone.

It can also become out of sync with a user's eDirectory password when that user changes his password from either the Novell client on a PC or uses the "change password" option presented in the Mac's "connect to the server" dialog when connecting to shared resources on a Novell server.

In Novell NetWare 6.5, a universal password feature was introduced to manage simple passwords and ensure that they remain in sync with eDirectory passwords. Universal passwords are not, however, enabled by default and may require additional steps to implement throughout a network.

For administrators needing the least costly and sometimes simpler option of using local accounts and NFA, the dilemma is how to still preserve some manner of authentication to the computer and how to make network resources easily available.

One mechanism is to force users to mount a shared folder at log-in. This can be done either by setting the shared folder as a log-in item or by writing a custom script or simple application that is configured as a log-in item or log-in hook. Log-in hooks are run as root and cannot be bypassed by holding the shift key at log-in, as log-in items can be. However it's done, the idea is to authenticate the user and/or mount specific shared folders.

Users should also be encouraged to log out of Mac OS X when finished using the computer; this disconnects the client from all servers before the next user begins using the computer. (A custom application can automatically disconnect users.) Also, any local user accounts should be non-administrative accounts.

LDAP and eDirectory

Novell's native directory service is known as eDirectory. Like Active Directory and Apple's Open Directory, it is based on LDAP. In previous Mac OS X releases, Mac clients could authenticate against eDirectory via LDAP, much as can be done with Active Directory. This allowed network accounts to be used to log into Macs.

But making use of that mechanism requires both the extension of the eDirectory schema and the setup of custom LDAP attribute mappings for Mac clients. It is not for the faint of heart and shouldn't be attempted unless you are familiar with eDirectory, LDAP and Mac OS X's Open Directory.

Though cumbersome, an LDAP approach can be among the least costly ways of developing a more robust Mac solution. Details about developing an LDAP-based authentication solution, along with further resources, can be found in this white paper. For many administrators, however, the time needed for building an in-house solution, coupled with the desire for additional support, often leads to consideration and/or purchase of one of the third-party options below.

Also, it is worth noting that when Mac OS X Tiger (10.4) was released, changes in the Open Directory schema caused problems with LDAP-based packages that were designed to work with earlier Mac OS X releases. In fact, at that time, there was a general sense that working with a third-party solution was the best -- and in some cases, the only viable -- option.

Prosoft's Novell Client

Prosoft's Novell Client is the first of two third-party solutions for integrating Macs with Novell. The Prosoft client installs on each Mac in a network and provides access to Novell's authentication mechanisms and encryption. It can be used solely for access to file and printer sharing as well as for authenticating access to a computer using an account in eDirectory.

When used for file and printer access, a browser application allows users to log in based on their username and context within the Novell Directory Services (NDS) Tree. Once logged in, users can browse for network resources and mount shares without the need for the Native File Access NLM. Automounting and dynamic mounting of share points are supported and can be configured with relative ease to ensure users have access to shared folders.

The Prosoft client also installs a Directory Access plug-in. This plug-in, which requires no configuration, can be enabled in the Directory Access utility. Available NDS Trees can be added to a Mac's Open Directory search path, allowing for authentication at the Mac OS X log-in window. Contextless log-in is supported, provided that a list of contexts to search for user accounts is created and placed in an appropriate directory on the Mac. Otherwise, users need to type their context as part of their username at log-in. (Note: Contextless log-in is the ability to log in at any location in a Novell network without the need to specify the container where the user's account is stored, in addition to the username and password.)

The Prosoft client is generally a good option, particularly for smaller and less complex network environments. By default, it relies on the open standard called Service Locator Protocol (SLP) to find directory servers. SLP cannot typically locate servers on remote subnets. In these situations, both Novell and the Prosoft client rely on directory agents and service agents running on Novell servers to help find resources.

In some complex environments, however, the Prosoft client may have problems finding and interacting properly with these agents. If your environment is even moderately complex, you should download the free trial and test the client throughout your environment before purchasing it.

1 2 Page 1
Page 1 of 2
How to supercharge Slack with ‘action’ apps
  
Shop Tech Products at Amazon