Now that you understand what it means to have security in a mixed environment, how do you go about achieving it?

Mix It Up: Security in a NT/Unix Enterprise, Part 2

Now that you understand what it means to have security in a mixed environment, how do you go about achieving it?

An engineering friend gave me a credo by which all system administrators should live: “Roberta,” he said, “If you’re going to be an engineer, you must realize that there are no problems, only opportunities.”

Last month I helped you get into tune with mixed NT/Unix enterprises and to understand some of the differences. Now that you have all that, what opportunities present themselves?

To start, say you want to be able to access data, whether it resides on a Unix or NT box. NT, in general, offers Telnet and ftp clients and Windows NT Server offers an FTP server. Unix offers Telnet and ftp clients and servers. So we simply use FTP to get and put files from one to the other, right? Beeeeeeep! Does passwords in the clear ring any bells? File access, you say, not transfer, is what you want and need? No problem. Utilities abound—well, at least they exist for accessing that data. But the issues are twofold: First, both the file system structures and permission structures are different. To determine which way to go, you need to ask which file system a solution is oriented toward; then define how to conquer the limitations of file access, authentication, and auditing; and, finally, decide which one to use.

For file access, you have several options:

  • Using client software for the opposite system. For example, you could use an NFS client for the desktop that allows PCs to browse NFS shares and mount them, much as they currently map NT drives. Hummingbird Communications Ltd.’s Exceed allows NT or Windows 95 users to emulate X-Windows and cut and paste data from Unix into a Windows-based application. The Windows NT Services for Unix Add-On Pack provides NFS client software that allows Microsoft clients to access files and printers existing on Unix servers.
  • Implementing an NFS server on an NT box, thereby allowing Unix clients to gain access to files and printers running Windows NT. Windows NT Services for Unix Add-on Pack offers this.
  • Implementing NFS gateway machines on the NT server. The NT server uses NFS to mount file and print resources on the Unix server, then reshares these resources using the NT community SMB protocol. To Unix, the gateway appears to be another Unix system accessing files. The Microsoft client needs no additional software but sees the point of access as another NT share. The Unix administrator maintains file-level access permission. The NT administrator maintains connection-level security.
  • Implementing SMB on Unix servers and workstations to allow Unix system access to files on NT hosts. Samba, AS/U, AT&T’s Advanced Server for Unix, and Syntax, Inc.’s TotalNET Advanced Server work this way. The SMB protocol is implemented to support Microsoft clients. It’s managed and configured on the Unix server. To the Microsoft client, the server looks like another Microsoft server. The client needs no additional software. The Unix client may need additional software to access files on the server. Administration of file access varies from Unix file access bits, to default NT tools used by ASU, to a mixture of the two.

File access permissions come in three forms:

  • Translated from one OS to the other, such as the way Network Appliance handles it.
  • Managed by the integration host, the AT&T ASU approach.
  • Implemented by the native file system—NTFS permissions when using the NTFS file system or NIS permissions on an NFS file system.

The problem of password synchronization is usually solved in one of three ways as well:

  • You have two accounts and separate passwords—no synchronization.
  • One OS becomes the master (you change your password in NT and your Unix account is synchronized, or vice versa). Microsoft’s Windows NT Services for Unix Add-on Pack provides one-way password synchronization with Unix. Change your password in NT and it will be changed on the Unix platform. AT&T’s ASU allows a Unix system to become either a primary or backup domain controller in an NT environment. Logging onto NT allows access to distributed resources managed by the ASU on NT and Unix hosts. A password-management utility may be available on some implementations to coordinate password synchronization from the NT side.
  • When you log on with a Unix ID or an NT ID and change a password, the other OS is synchronized.
The Responsive Server
Why not have a server that can respond to both Unix and NT clients in the manner to which they’re accustomed—Unix users with Unix file permissions and NT users with NTFS? Network Appliance offers a product that can make this happen.

The NetApp Multiprotocol Filer is a dedicated server that speaks a combination of NFS, CIFS, and HTTP. It merges Unix and NTFS file-level security and accommodates Unix permissions and NT ACLs. Different areas of the file server handle each model. This appliance uses the method of a qtree as a basis for security configuration, lock configuration, backup management, and security style. Qtrees can be changed on the fly, converting from Unix to NTFS and back as storage needs change. NFS requests to Unix trees or CIFS requests to NTFS work as you’d expect. You can even establish file access by Unix permission or NTFS ACL on a file-by-file basis.

The problems occur when mapping CIFS requests to Unix trees and vice versa. Each CIFS user is mapped to a Unix user and validated against Unix permissions. The Unix UID and GID is used for access validation. Unix permissions are guaranteed to be more restrictive than the ACL to prevent users from circumventing ACL-based security by using NFS. Since Unix permissions aren’t as rich as ACLs, some files may not be accessible over NFS. Client requests to change the Unix file permissions to an NT ACL or to take ownership or to set file permissions is denied in Unix trees; in a mixed-tree setting it’s allowed only by the owner of the file. A request to take ownership is allowed only by the owner and converts the file to use an ACL. A CIFS request to create a file results in inherited permissions. (A Unix request would include the file permissions in the request.)

This type of access works well for the file owner and the permissions applied to the group Everyone. The group Everyone is mapped to the Unix “other” bit permission. This type of access doesn’t work well for other groups.

CIFS requests to CIFS trees are treated in the normal fashion.

When NTFS ACLs are created or changed, a corresponding set of Unix permissions is calculated, allowing for normal processing. The Unix user perm is set based on the access rights of the ACL to the CIFS session creating the file. The Unix other perm is set based on access rights from the NT Everyone group. ACL denies are subtracted from the other perm; if there are any denials, all others are excluded. The Unix group perm is set equal to the other perm. Since Unix can’t fully represent the NT granularity and richness, some files will be inaccessible from NFS. NFS requests to set permissions on NTFS files are rejected. In a mixed tree only the owner can set permission.

NT Administrator accounts can be mapped to the Unix “root” or to a non-privileged Unix account.

Learn more about Network Appliance’s products at www.networkappliance.com.

—Roberta Bragg

We Want it All and We Want it Now!

So what should you choose? How do you provide resource access in a mixed environment?

  • Determine which platform is primary; that platform dictates your direction. Are most users working under Microsoft Windows? Apply a Microsoft-oriented approach. Multiple products use Microsoft’s SMB or CIFS. Is Unix the primary platform and NT the newcomer? NFS is probably more familiar to your users, so choose utilities that maintain that interface. If your situation lies somewhere between and you’re in need of a compromise, you may need to implement access utilities from both fronts. But remember the mixed blessings inherent in such a choice.
  • Choose utilities that allow your users to comfortably access files on an unfamiliar OS, while retaining the levels of security your environment demands.
  • Implement the best possible security on both systems. There may be areas where you can use the inherent differences in the system authentication and file access permissions to further protect sensitive files. Remember, just because you need to provide shared file access between disparate systems doesn’t mean you need to expose critical information to unlimited penetration. There’s nothing wrong with insisting that this data be kept separate from shared data and that it be accessible only through native access rather than some translating utility.
  • Forego use of enterprise administrative commands if you don’t fully know or understand their use and potential abuse. Don’t judge these utilities by ease of use alone, but by firm understanding of their impact on both operating systems.
Additional Information

Featured