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.
Note: There was an issue with the Prosoft client’s preferences files becoming corrupted; this can cause the client to repeatedly ask for a serial number, often rejecting valid serial numbers. In speaking with Prosoft support while preparing this article, it appears that this is a known issue and that the suggested procedure is to remove all preferences files and reinstall the client if needed. Kanaka The second third-party option is Kanaka by Condrey Corp. Kanaka achieves the desired results of computer log-in and easy access to remote resources differently than Prosoft’s client. Where Prosoft focuses on a Novell client that can run directly on a Mac, Kanaka is designed for both the client and the server. This broader approach allows Kanaka to provide computer log-in, as does Prosoft’s client, as well as additional features including workstation management based on network accounts stored in eDirectory, and options to ease the process of accessing resources. To do this, Kanaka installs on a server as an NLM and on Mac clients as a Directory Access plug-in. The NLM serves a number of different functions, but it relies on Novell’s Native File Access NLM to handle the actual authentication of users. While Kanaka doesn’t aim to be a complete Novell solution unto itself, as Prosoft’s client does, it does aim to provide as many network management features as possible. It does this by translating many of the schema attributes used by Open Directory to their appropriate eDirectory equivalents, most notably the home directory attribute. This provides a seamless user experience and allows users to mount their home directories, as well as other network storage to which they have access, with relative ease. Kanaka also goes beyond just handling authentication. During installation, it extends the eDirectory schema to support several Open Directory attributes, most notably those required to implement Mac OS X’s managed preferences architecture. When using managed preferences, administrators can elect to define a handful of preferences using Kanaka’s management console. Or, if Mac OS X Server is available, admins can set these options directly from Workgroup Manager, offering many of the options available in an Open Directory environment. This makes Kanaka a great option if you want to implement a managed environment as well as authenticate users against eDirectory for access to individual computers. It also allows Open Directory and eDirectory to integrate and provide a more robust environment for supporting Mac users. Kanaka also installs an application on Macs called Kanaka Dashboard that allows users to easily change their passwords and monitor the available space of their home directories. This simplifies the password management issues normally associated with using Novell’s Native File Access (NFA). Kanaka can generally be considered an ideal option for larger and more complex networks or those where additional management features are desired. Installation and use is somewhat more complex than Prosoft’s solution because it is a server-side technology, and it does increase server overhead by both its overall design and dependence on NFA to provide actual authentication and file services. As with the Prosoft solution, a demo version of Kanaka is available on the vendor’s site. The licensing model for Kanaka also varies from the Prosoft client in that it requires a yearly maintenance fee as opposed to Prosoft’s single purchase price. Overall considerations Supporting Macs in a Novell environment will probably never be as simple as supporting them in an Open Directory or Active Directory environment. Unless you simply opt to rely on the Native File Access and local user accounts, it will also probably continue to be costly, as both Prosoft’s client and Kanaka incur significant licensing fees. A single user license for Prosoft’s client comes at a price of $149, for example, with bulk and site license options for larger purchases. Kanaka’s commercial pricing begins at $150 for a single license with an additional annual fee of $37.50, with bulk and site licensing options available as well. Both companies also offer educational pricing, and Condrey extends Kanaka’s educational pricing to government agencies. Pricing aside, the choice between Prosoft and Kanaka truly comes down to the network in which they will be used and the goals of the administrator. Prosoft promises a simpler setup and makes Macs much more equal players from the Novell administrator’s perspective. However, the software doesn’t easily deploy as broadly and isn’t as transparent to users. Kanaka, by contrast, doesn’t attempt to be a Novell client but does provide a much more seamless user environment, complete with advanced management capabilities. It also deploys more readily into larger environments. Because of their differences, it isn’t easy to make direct comparisons and declare one a superior product. A better option is to assess your specific needs and goals and to keep them in mind while exploring the demo versions of both products. Ryan Faas is a freelance writer and technology consultant specializing in Mac and multiplatform network issues. In addition to writing for Computerworld, he is a frequent contributor to InformIT.com. Ryan was also the co-author of O’Reilly’s “Essential Mac OS X Panther Server Administration.” You can find more information about Ryan, his consulting services and recently published work at www.ryanfaas.com, and can e-mail him at ryan@ryanfaas.com.
