Novell is now a part of Micro Focus

Leveraging Novell Open Enterprise Server and Novell eDirectory as a File Protocol Gateway and Central Identity Store

Novell Cool Solutions: Feature
By Carl Lloyd, Darcy Partridge, Randy Goddard

Digg This - Slashdot This

Posted: 23 Mar 2006

Randy Goddard – Worldwide Support Engineer – Novell Technical Services
Carl Lloyd – Advantage Support Engineer – Novell Technical Services
Darcy Partridge – Worldwide Support Engineer – Novell Technical Services

Table of Contents


In today's world of multi-platform and multi-OS networks, interoperability between systems is becoming increasingly important. As data storage needs increase, SANs, NAS devices and other large capacity storage systems are becoming a necessity even for mid-sized businesses. With the introduction of these devices come the difficulties, among others, of managing file system rights and ownerships. As the number of these systems increases in the network, the complexity of managing these rights can increase exponentially.

Novell eDirectory, the industry's premier identity management solution, is designed to help the network administrator centrally control file system rights in today's heterogeneous networks. By combining eDirectory with the ability to speak multiple file and identity protocols, including Samba, NFS, NCP, and LDAP, Open Enterprise Server on Linux allows network administrators to leverage new and existing storage platforms while maintaining centralized control of file access rights and ownership.

For example, a protocol gateway can allow SMB/CIFS and NCP clients to work with a file system that does not natively support either of those protocols. Such an implementation is the subject of this document.


Diagram 1

Diagram 1 shows the setup used for this scenario. There are four machines being used:

  1. FS-SOL - A Sun SparcStation blade server running Solaris v10. In theory, this could be any storage device with the capability of sharing it's file system through NFS, though exact configuration steps will vary.

  2. FS-OES - A server class machine running Novell Open Enterprise Server on Linux. Support Pack 2 for OES has been applied.

  3. WS-SMB - A workstation running Windows XP Support Pack 2.

  4. WS-NCP - A workstation running Windows XP Support Pack 2, which has the Novell Client for Windows version 4.9.1 Support Pack 2 installed and active as the default GINA.

The solid lines in the diagram represent the file exchange protocols being used between the various machines. All file exchange traffic is considered bidirectional, implying two-way communication for both file reads and writes. The dashed lines represent the protocols over which authentication and/or file ownership mapping takes place. The OES server's eDirectory is the central and only identity store used in this scenario.

Above the Solaris and OES servers are shown the absolute paths of the file systems being respectively exported and imported through the NFS v3 protocol. Also shown are the SMB and NCP share names being exported from the OES server. Note that the share names are case sensitive. That being said, the SMB and NCP shares actually represent the same portion of the OES file system being exported through both protocols. The absolute path of the exported portion is /gateway/sol, the same as the mount point of the NFS import from the Solaris server.

For the purposes of this scenario, four users have been created in eDirectory.

They are:


The SMBUSERx users were LUM enabled in eDirectory at the time they were created. They were then immediately Samba enabled. The NCPUSERx objects were also LUM enabled at creation, but they were not Samba enabled. Explanation on these enabling processes is outside the scope of this solution. Further information on them can be found in the Open Enterprise Server documentation.

The eDirectory tree used in this example, for purposes of simplicity, is flat in structure. It contains a single organization (O=novell) where the OES server and all user objects reside.

Please note that the network infrastructure used to connect the machines is not shown and should be irrelevant as long as all the involved protocols can pass freely between the machines. In this test scenario, all machines were physically on the same IP subnet and network switch and entries in each device's HOSTS file were made to allow for name resolution. The introduction of routers, firewalls, etc. into the network infrastructure may necessitate individual adaptation such as the use of DNS servers, WINS servers, and/or firewall ACL rules to allow this setup to function.

Conventions Used in This Document

%word_or_phrase - This syntax is used when the information required is variable. The percent sign (%) and the word or phrase that follow should be replaced with an actual value. The word or phrase shown will describe the value needed.

command – Command strings are italicized.


  1. Solaris is installed and functional.

  2. An NFS export is created on the Solaris server. Because the NCP service will need to perform some operations as root, root access must be granted to the Novell Open Enterprise Server. On Solaris, the /etc/dfs/dfstab should be modified, adding root=%oesname to the -o (options) section. In this example, root=fs-oes. The NFS service should then be restarted.

  3. Novell Open Enterprise Server is installed and configured as a functional NCP and SMB server.

  4. Novell Open Enterprise Server users are LUM-enabled and Samba-enabled as needed.

  5. Novell Open Enterprise Server group(s) exists and is/are LUM enabled.

  6. The Solaris NFS export is mounted on the Novell Open Enterprise Server.

Installation and Configuration Steps Used to Utilize Novell Open Enterprise Server as a Protocol Gateway

Note: There are optional concerns that may be very important to some environments. Please be sure to read the Operational Considerations section before implementation.

The first step in setting up Novell Open Enterprise Server as a Protocol Gateway is to configure the Solaris server to access the Novell Open Enterprise Server via Lightweight Directory Access Protocol (LDAP). The reason this is suggested is to allow file and directory ownership to flow from eDirectory user and group names.

Prior to setting up LDAP, it is suggested that the nsswitch.conf be backed up. In most cases, simply cp /etc/nsswitch.conf /etc/

Next, the LDAP client should be configured. A command line configuration is suggested for ease. In most cases, it would be something like the following. Note: this command string is too large for the standard c-shell, using the bash shell is suggested.

ldapclient manual -a credentialLevel=proxy -a authenticationMethod=simple -a proxyDN=cn=admin,o=%oname -a proxyPassword=%password -a defaultSearchBase=o=%oname -a domainName=%domain -a defaultServerList=%ipaddress:389 -a defaultSearchScope=sub -a "serviceSearchDescriptor=passwd:o=%oname?sub" -a "serviceSearchDescriptor=group:oname=%o?sub".

In this example:

ldapclient manual -a credentialLevel=proxy -a authenticationMethod=simple -a proxyDN=cn=admin,o=novell -a proxyPassword=password -a defaultSearchBase=o=novell -a -a defaultServerList= -a defaultSearchScope=sub -a "serviceSearchDescriptor=passwd:o=novell?sub" -a "serviceSearchDescriptor=group:o=novell?sub" was used.

For simplicity of this example we've set "Require TLS for Simple Binds with Password=no" on the Novell Open Enterprise Server by running: ldapconfig set "require tls for simple binds with password=no". In application, however, this may not be the desired choice for the obvious security implications. If TLS is required, the ldap client will need an exported security certificate and the proper security configuration.

When running this configuration command, the /etc/nsswitch.conf is modified and [NOTFOUND=return] added to many lines. It is suggested to remove these for simplicity. Adding dns to the hosts: service is also suggested.

Once the LDAP client configuration is complete, verification is always a good idea. One can use id %ediruserid. If this returns the correct UID and GID for this user, as configured in eDirectory, then the client is properly configured.

The Solaris NFS-exported directory should now be modified to allow for Novell Open Enterprise Server group ownership. chmod 0775 %nfsexportdirectory, then chown or chgrp %oesgroupname %nfsexportdirectory.

In this example, chmod 0775 /solexport, chown :linuxgrp /solexport.

The second step is to configure the Novell Open Enterprise Server. As stated in the assumptions, the Novell Open Enterprise Server should be operational, and have LUM- and Samba-enabled users and groups. The NFS export should be mounted and owned by the %oesgroupname.

The NCP share configuration is done through ncpcon. This can be accomplished either by running ncpcon, then issuing the create volume %ncp_volume_name %path command, or from the command-line as ncpcon create volume %ncp_volume_name %path. Again by example: ncpcon create volume solshare /gateway/sol.

Once created, eDirectory rights should be granted to the users that will require access. Again, this can be completed through ncpcon or at the command line as: ncpcon rights add %path %fdn %mask. By example: ncpcon rights add solshare: ncpuser1.novell WEFRCM.

There are many ways to create SMB/CIFS shares. For ease of use and demonstration, YaST is suggested. Using the Samba Server configuration tool in YaST | Network Services | Samba Server, click Add, give the share a meaningful name and description, then either specify or browse for the Share Path. Click OK to finish.

Operational Considerations

Although quite simple, the configuration of Novell Open Enterprise Server as a Protocol Gateway does include some operational considerations. If one can learn from another's experience and pain, please learn from ours.

If both SMB/CIFS and NCP clients will be accessing the same storage location AND file sharing between protocols is desired, there are some additional configuration parameters you should be aware of.

When creating the Samba share, the additional parameters of 'create mask' and 'directory mask' should be configured as 0775. The default Samba create and directory mask is 0644, which would not allow all users in the linuxgrp group to read and write files.

After creating the NCP share, the /etc/opt/novell/ncpserv.conf should be modified. CROSS_PROTOCOL_LOCKS 1 should be added to the options section, because cross-protocol locking is turned off by default and could cause some file collisions and possible file corruption. Furthermore, Inherit_POSIX_Permissions should be added to the shared volume parameters, because the default ownership of files and directories is %ncpuser:root and would not allow all users in the linuxgrp group to read and write files. The NCP service should be restarted after making this change. As it is part of ndsd, rcndsd restart is the suggested command.

Specific Examples


/usr/sbin/share	-F	nfs	-o	sec=sys,root=fs-oes -d
"NFS exported filesystem"	/export/home/solexport

NCP Server Configuration File (/etc/opt/novell/ncpserv.conf)

; The name of the ncp server on which this file exists.
; This parameter is informational only. 


VOLUME SOLSHARE /gateway/sol Inherit_POSIX_Permissions


   browseable = yes
   comment = Solaris share through SMB
   guest ok = no
   path = /gateway/sol/
   printable = no
   read only = no
   writeable = yes
   create mask = 0775
   directory mask = 0775

Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions.

© Copyright Micro Focus or one of its affiliates