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?
- By Roberta Bragg
- 06/01/1999
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.