|
3/9/2006
Eric Low
NFAP lets you map NSS volumes and authenticate using an OS' native
protocol(s). This means NFS for Linux, CIFS for Windows, and AFP
on Macintosh.
I did not care about NFAP for Macintosh, so I did not add the Macintosh
Name Space to the volumes. I also am not running BorderManager, so do
not need to worry about creating a Login Policy Object (LPO). In fact,
all I really care about is NFAP for Linux (nope, I don't even care about
CIFS! We really have no Windows accounts out there, aside from Exchange
accounts).
|
If NFAP is not yet installed, here is the documentation
to refer to.
From a Windows 2000 workstation, logged into the NW server with
the admin account, insert the NW65 SP5 OS Overlay CD and run NWDEPLOY.EXE
(the Netware Deployment Manager) from the CD's root dir (or of
course it may run automatically). This brings up a page in IE
from which I clicked Post-Install Tasks -> Install Netware
6.5 Products (from the left-hand menu). After clicking on Remote
Product Install, you would enter the name of the target server
(in our case, S3), then the admin password when prompted. You
would then check "Native File Access Protocols."
|
When NFAP for Unix is installed, the following accounts will exist:
|
NFSAdmin Container Object is installed
under the eDirectory tree root, and gives you access to the exported
file structures available to NFS users.
NFAUUser User Object provides a link between
Netware and the root user on a local Linux machine (used internally
to convert data between the two systems). This
user is given Security Equivalence to the Admin account by default!
What this account does is, if a volume is exported with the "Root
Access" Global Permission checked, and a user mounts to that
path while logged in with the root account on the local
Linux client, they will be able to access everything that the
admin account could.
NFAUWorld Group Object provides Linux rights
when they access an exported NFS path (this account's effective
rights are converted into Linux RWX rights). To restrict NFS users
from having too much access to the Netware File System, you must
restrict the rights of this account.
NISSERV_SERVERNAME Server Object is used
when NIS is set up. It is not actually used for NFS file system
access.
|
In order to administer these properly (or even see the NFSAdmin
container), you must run ConsoleOne from the server on which NFAU is
installed. It will not work from a client, and I cannot find a plugin.
Before trying to access the NFSAdmin Container, you must also
load the NFSADMIN.NLM.
I did not want to use the NIS server at this time, so I shut it off
by going to the NFSAdmin container in ConsoleOne, clicking "Login
To NFSAdmin," right clicking on the server name and selecting
"NFSAdmin Properties." Under the Directory Access
tab, I unchecked "Enable NIS Client."
To allow volumes or directories to be mounted, they must first be exported.
To do this, log into iManager and click File Protocols -> NFS from
the left-hand menu. Select the server, then click the Export
button next to the "Exported Paths" box.
Unfortunately, you cannot choose to export all of our volumes
at once, by simply typing a slash. So, you must export volumes individually.
To do this, you would type /sys to export the SYS:/ volume, etc.
Under Access Control, I was sure to choose "Netware"
so that file system rights would be controlled by normal Netware
file system rights (rather than file access controlled simply by who
the owner is). I also selected "Read Write Access."
*** If you were to check "Root Access" under global permissions,
then anyone logged in with the local Linux client's root account would
get full access to the exported directory!
|
In all practicality, I could not really find a way to provide
adequate security using NFS. I spent a while trying to figure
out how to even specify a user to authenticate with when mounting
from Linux, and never could find it! When you mount with NFS to
an actual Linux NFS server, it of course authenticates
with whatever user you or logged on as, or anonymously if that
is allowed. When mounted a directory exported by the Netware
NFS server, however, it always seems to connect anonymously! All
access is then controlled by the NFAUWorld account (or
NFAUUSER, if root access is enabled), which means that
anyone who connects, with or without a password, gets the exact
same rights. Sure, you can control this by host, but that simply
is not good enough.
From what I have read, if you set up the NIS server as well,
things may be integrated enough where security there is a mapping
between eDirectory accounts and the virtual Linux account that
authenticated. However, I do not want an NIS server, and
therefore am not delving into this. But it may be a possibility.
So, from my observations, the Netware NFAU provides little to
no security. Therefore, I cannot use it and have decided to leave
it disabled. Good luck.
|
Configuration is stored in EXPORTS, NFS.CFG (these settings
are common to NFS and NIS?), NIS.CFG, and NFSSERV.CFG,
located in SYS:\ETC.
The NFS server is started and stopped by typing NFSSTART and NFSSTOP,
respectively. NFSSTART.NCF is located in the SYS:\SYSTEM directory and
contains the following lines:
load nisserv
load xnfs
hidescreen pkernel |
On a similar not, CIFSSTRT would load CIFS.NLM, CIFSPROX.NLM,
and NFAP4NRM.NLM. AFPSTRT would load AFPTCP.NLM
as well as NFAP4NRM.NLM if not already loaded.
*** I commented out CIFSSTRT.NCF and AFPSTRT.NCF in the autoexec.ncf
because I did not wish to use these methods of access.
*** Are rights always those of NFAUWorld no matter what user authenticates??
Gave RF rights to SYS:/ and then anyone who logged in could see all
files.
Setup
NFAU
|