Windows Server and NSS volumes

We're going through this just now. So far as I know there are no file-system drivers for NSS on any Windows platform. In the immediate term we're loading the CIFS stack on our NetWare servers which allows our Windows servers to talk to them without the Novell client crudding up the network stack. Then we're running a series of scripts to migrate trustees.

Loading "TRUSTEE.NLM" on the server will give you a very, very handy rights dump of the assigned trustees on the volume.

trustee /edt save DATA1: sys:/tmp/metadata.log

That'll dump both Trustee and directory-quota data into a log file that you can then perform Rites of Scripting upon. What those scripts are, are up to you. Somethings you'll need:

• A reliable way to translate Novell groups into AD groups. This can be a lookup table of some kind, or a predictable name
  • A possibility is to migrate all of your Novell groups into AD, and deal with converting your group names to something more standardized 'later'.
• The directory structure in place. ROBOCOPY has very good options for this. Don't copy files yet, do that last.
• The script reads the metadata.log file and applies NTFS permissions to the correct directories. Keeping in mind that NTFS and NSS permissions are not the same (see below for a rough guide).
• Pray you haven't made heavy use of inherited rights filters.
• Copy files in only after your rights structure is built. It's a LOT faster that way.
• ROBOCOPY has a sync option that'll keep file data synced while you wait for cut-over day. It WILL NOT copy trustee/acl data, so putting a rights change moratorium while you're in this state is a very good idea.

NSS rights to NTFS rights. Do note, Directory permissions are not the same as File permissions, even though they use the same ACL bits. The translations are icacls options. For instance...

icacls Directory /grant NW-IT-Guys:(rx)

Gives the 'NW-IT-Guys' group the Read/Execute right to that directory, with no inheritance.

icacls Directory /grant NW-IT-Guys:(oi)(ci)(rx)

Does the same, but they'll also be able to read files (oi) and directories (ci) created below that point as well.

• R - (Implies "F" below, Windows doesn't allow reading without file-scan) (rx)
• W - (wd) on files only. Putting it on a directory means C on NSS.
• E - (d) for files, (dc) on directories if you want users with that right to be able to delete files in the directory
• M - (ad) for files. When granted to directories, allows creating sub-directories.
• C - (wd) on directories only. Putting it on a file means W on NSS.
• F - (rd) on directories only. No equivalent for files. If you're using Access Based Enumeration, there is no way 'see files but not read them'.
• A - Not sure
• S - (F), but unlike NetWare this can be blocked.

This table is meant for those cases where you're not granting [rwemcf] (a.k.a. read/write) or [rf] rights (a.k.a. read) to a directory. For these simple cases, use the (rx) for read, and (m) shortcuts for read/write. For those users who need to be able to make changes to rights, (f) is the shortcut for that. For special directories, such as drop boxes or write-only directories, the above may help figure it out.

Some examples of assigning rights with icacls:

Create an undeletable/moveable directory with modify rights

icacls AcctReports /grant NW-Acct-Techs:(io)(oi)(ci)(m)
icacls AcctReports /grant NW-Acct-Techs:(rx)

(io) means 'inherit only', or only applies to child objects.

Create a standard NSS-style read/write directory

icacls AcctReports /grant NW-Acct-Techs:(oi)(ci)(m)

Create a standard read-only directory

icacls AcctReports /grant NW-Acct-Auditors:(oi)(ci)(rx)

Create a directory containing log-files appended to by end-users. Perhaps application install logs or the like

icacls AppLogs /grant Everyone:(rx)
icacls AppLogs\FirefoxInstall.Log /grant Everyone:(rx,ad)

If you're like almost every NetWare install I've seen, your volume roots have very few permissions on them and you grant permissions on your top level directories and below. This isn't terribly compatible with Windows, but there are ways to kludge it into working. I'm assuming you're using 'access based enumeration' because that's how NetWare has always done it, and you don't want to shock your users with how many directories there really are out there.

• 'Everyone' will need the (rx) right to "this folder only" for the top directory of your shares. Otherwise, mapping will fail.
• For cases where users will have to traverse multiple directories before they get to the one they have rights on, NTFS won't let you browse down. You can fake it by using the "(rx) to this-folder-only" trick for that access entity on each directory from the share-root to the directory. Yes, this sucks. But it works.
• Direct access will work. Mapping to "\\server\share\dir1\dir2\dir3\" will work, even if "\\server\share\dir1\" fails. It is up to you to figure out if educating your users on this is easier than the previous point.

And I'm not even on to ShadowCopies vs. Salvage yet.

As far as I know, only OES Linux and OES NetWare can mount NSS volumes.

If the issue is you have a disaster recovery problem and can't get NetWare running, you should try the OES Linux strategy first. If this is migration, the way we cut over was to copy the data to a new server and reassign permissions, and fix mistakes over time.