The ASU server enables you to share UNIX directories as disk shares, then make those shares available to domain user accounts and groups. For example, when a directory is shared, authorized Windows users can make connections from their workstations to the share and access its files.
The only way to make a file accessible over the network is to share one of its parent directories as disk share. When you share a directory, Windows users can gain access to that directory, the files in it, and all of the subdirectories and their contents. Every point on the directory tree below the shared directory is available to users. You use Windows NT permissions to manage user access to the share and Windows NT file system (NTFS) and Tru64 UNIX permissions to manage user access to files and directories in shares.
This chapter discusses the following topics:
See the ASU
Installation and Administration Guide
for information on creating disk shares.
4.1 Disk Share Permissions
Every file and directory has an owner. The owner controls how permissions are set on the file or directory and can grant permissions to others. When a file or directory is created, the person creating the file or directory automatically becomes its owner. By default, a user must pass the following levels of security before they can access a file or directory in a disk share:
Windows NT share level security
Windows NT File System (NTFS) security
Tru64 UNIX file and directory security
The following steps describe how permissions are checked when a user maps a drive to a disk share and requests access to a file in the disk share:
From a system running the Windows operating system software, a user connects to a disk share. By default, all users have permission to connect to a share.
The user's Windows system provides the ASU server with authentication information about the user, including the user's name, password, and security ID.
The ASU server checks the user's name and password in the directory database.
If the ASU server authenticates the user's information, a unique ID is assigned to the user's Windows system. The Windows system must present this ID when the user makes subsequent requests to shares.
The user attempts to open a file in the share.
The ASU
lmx.srv
process services the user's request.
Normally, the
lmx.srv
process runs as root, the highest Tru64 UNIX
privilege level.
The
lmx.srv
process determines if the user
has the correct Windows NT share permissions to access the share.
If the permissions are not correct, the
lmx.srv
returns
an access denied error to the Windows system.
The
lmx.srv
process determines if the user
has the correct NTFS permissions to access the file in the share.
If the permissions are not correct, the
lmx.srv
process
returns an access denied error to the Windows system.
The
lmx.srv
process determines Tru64 UNIX
access based on the mapping of the domain user account to a Tru64 UNIX
user account.
The
lmx.srv
process changes its effective
user ID from root to the ID of the corresponding Tru64 UNIX account and
tries to open the file.
The Tru64 UNIX operating system determines if the user has the correct Tru64 UNIX permissions.
If the permissions are correct, the file is opened.
If the permissions
are not correct, the
lmx.srv
process returns an access
denied error to the Windows system.
Table 4-1
describes the Windows NT permissions
that you can set for a disk share.
Table 4-1: Windows NT Permissions
Permission | Purpose |
No Access |
Prevents a user from accessing the disk share |
Read |
Allows:
|
Change |
Allows everything Read allows, plus:
|
Full Control |
Allows everything Read and Change allows, plus:
The default is to grant the Everyone group Full Control permission to new disk shares. |
Note
Permissions are cumulative except that the No Access permission overrides all other permissions. For example, if the Coworkers group has Write permission for a file while the Finance group has only Read permission and John is a member of both groups, John will be granted Read and Write permissions. However, if you change the Finance group's permission for the file to No Access, John will not be able to use the file even though he is a member of a group that has write access to the file.
See the ASU
Installation and Administration Guide
for information on setting Windows
NT permissions.
4.1.2 Windows NTFS Permissions
There is a standard set of NTFS permissions that you can set or you
can customize NTFS permissions to meet you needs.
Table 4-2
describes the standard Windows NTFS permissions that you can set.
Table 4-3
describes the custom Windows NTFS permissions that you can set.
Table 4-2: NTFS Standard Permissions
Permission | For File | For Directory |
Add | Cannot read the contents of current files, change them, or list the files | Can add files to the directory |
AddRead | Can read and execute files but cannot change files | Can read, write, and execute files in the directory |
Change | Can change the contents of current files | Can read and add files |
Full control | Can read and change files, add new ones, change permissions for files, and take ownership of file | Change permissions for the directory and take ownership of the directory |
NoAccess | Not applicable | Cannot access the directory in any way, even if the user is a member of a group that has been granted access to the directory |
List | Cannot access files | List the files and subdirectories in this directory and change to a subdirectory of this directory |
Read | Can read the contents of files and run applications | Allows viewing the names of files and subdirectories |
Table 4-3: NTFS Custom Permissions
Permission | For File | For Directory |
Change Permissions (p) | Allows changing the file's permissions | Allows changing the directory's permissions |
Delete (d) | Allows deleting the file | Allows deleting the directory |
Execute (x) | Allows running the file if it is a program | Allows changing to subdirectories |
Read (r) | Allows viewing the file's data | Allows viewing the names of files and subdirectories |
Take Ownership (o) | Allows taking ownership of the file | Allows taking ownership of the directory |
Write (w) | Allows changing the file's data | Allows adding files and subdirectories |
NTFS displays two sets of permissions: the permissions set on the directory and the permissions set on files in the directory. For example, the following output would display if you set AddRead permission on a share for a user name peter. The (RWX) means Read, Write, and Execute permissions on the directory, and (RX) means Read and Execute permission on its files.
Resource: c:\usr\net\servers\lanman\shares\share1 Owner: server1.dom\Administrators Name: Permissions: ------------------------------------------------------------------------------- *Administrators FullControl(All)(All) *Everyone Read(RX)(RX) peter AddRead(RWX)(RX)
The ASU server displays groups by preceding the group name with an asterisk ( * ).
NTFS Permissions on files in a directory can be set to NotSpecified. This means that no permissions will be set for that user or group on the files in the directory or that are created after setting this permission. A user or group cannot access files in the directory until permission is granted.
When you set permissions on a directory, you can use the Creator Owner special group to allow users to control only the subdirectories and files that they create within the directory. Permissions set on the Creator Owner group are transferred to the user who creates a directory or file within the directory. To change permissions on the directory, you must be the owner of the directory or have been granted permission to do so by the owner.
Note
By default, Windows NTFS permissions grant read and execute permission to the Everyone group, of which every domain user account is a member. You must grant Windows NTFS write permission to the domain user account or group that will write files to the disk share.
See the ASU
Installation and Administration Guide
for information on setting Windows
NTFS permissions.
4.1.3 Tru64 UNIX Permissions
By default, subdirectories created in a disk share have the following Tru64 UNIX permissions:
Owner has read and write permission
Group has read permission
Other has read permission
By default, files created in a disk share have the following Tru64 UNIX permissions:
Owner has read and write permission
Group has read permission
Other has read permission
See
System Administration
for information on setting Tru64 UNIX permissions.
4.1.4 Disk Share Permission Considerations
The user who creates a file or directory is the owner of that file or
directory; however, users who are members of the Administrators group always
can take ownership of a file or directory.
The owner can control access to
the file or directory by changing the permissions set on it.
When changing
the permissions on a directory, you choose whether to apply the changes to
all files and subdirectories in the directory.
Users cannot use a directory
or file unless they have been granted permission to do so or belong to a group
that has permission to do so.
Each permission that you set specifies the access
that a group or user can have to the directory or file.
For example, when
you set Read permission for the group called Coworkers on the file
MY_IDEAS.DOC
, the users in the Coworkers group can display the
file's data and attributes, but they cannot change the file or delete it.
The easiest way to administer security is by setting permissions for groups, not individual users. Typically, a user needs access to many files. If the user is a member of a group that has access to the files, you can terminate the user's access by removing the user from the group rather than changing the permissions on each of the files. Note that setting permission for an individual user does not override the access granted to the user through groups to which the user belongs.
When copying files or directories, the current security permissions,
ownership, and auditing information is discarded.
The copied files or directories
inherit a new set of permissions from the directory into which they are copied
and the person copying the file or directory is the owner.
4.2 Directory Replication
One of the helpful tasks that the ASU server performs is keeping shared
resources current, which can be accomplished by using the
Replicator
service.
If you have directories and files that you want to distribute
to many users, you can use the
Replicator
service to set
up and maintain identical directory trees on controllers and workstations
to balance the work among them.
The
Replicator
service requires that you configure
one computer as an export server, place the master copies of directories and
files on the export server, and configure other computers as import computers.
You only need to create one copy of a directory or file on the export server
and import computers automatically receive an identical copy of the directory
or file.
When you update a directory or file in the directory tree on an export
server, the updated directory or file is copied automatically to all the import
computers.
Every export server maintains a list of computers to which directories and files are exported, and each import computer maintains a list of computers from which directories and files are imported. Export servers can export to domain names and import computers can import from those domain names. This is a convenient way to set up directory replication for many computers; each export server and import computer needs to specify only a few domain names for export or import rather than a long list of computer names.
You can configure an ASU server as an export server and as an import
computer.
4.2.1 Directory Replication Overview
The
Replicator
service must be running on each export
server and import computer.
The
Replicator
service sends
updated directories and files on each export server to import computers that
participates in replication.
The
Replicator
service on
each computer logs on to the same user account, which you create for this
purpose.
A domain can have multiple export servers; however, to ensure the integrity
of replicated information, do not export duplicate subdirectories.
The
/usr/net/servers/lanman/shares/asu/repl/export
directory is the
default export path on the export server and should contain the directories
and files to be replicated.
When changes are saved to subdirectories and files
in this directory, the subdirectories and files automatically replace the
existing subdirectories and files on all of the import computers.
You also can specify whether the export server sends changes as they occur or wait until an export subdirectory has been stable for two minutes. This prevents exporting partially changed subdirectory trees. In addition, you can lock an export or import directory. Changes to a locked directory are not exported or imported until you unlock the directory.
On the export server, you specify the import computers that are to receive copies of the directories and files that the export server is exporting. An export server has only one list of import computers to which it replicates. All directories to be replicated are exported as subdirectories in the export path. Subdirectories created in the export path and files in those subdirectories are exported automatically. Export servers can replicate any number of subdirectories (limited only by available memory) with each exported subdirectory having up to 32 subdirectory levels in its tree.
Imported subdirectories and their files are automatically placed in
the
/usr/net/servers/lanman/shares/asu/repl/import
directory.
You do not need to create import subdirectories.
They are created automatically
when directory replication occurs.
4.2.2 Configuring Directory Replication
Follow these steps to configure directory replication on export servers and import computers:
Create a domain user account for the
Replicator
service to use to log on.
Be sure the user account has the Password Never
Expires option selected and all logon hours allowed.
See the ASU Installation and Administration Guide for information about creating domain user accounts.
For each computer that will be configured as an export server, use the Server Manager, select Properties from the Computer menu, then select Replication and configure:
The
Replicator
service to start automatically.
To log on using the domain user account that was created for
the
Replicator
service.
The names of the import computers and domains by adding them to the To List.
See Server Manager help for more information on configuring
the
Replicator
service.
On a computer that will be configured as an export server,
create the directories to be exported.
They must be subdirectories of the
replication export path,
/usr/net/servers/lanman/shares/asu/repl/export
.
For each computer that will be configured as an import computer, use the Server Manager, select Properties from the Computer menu, then select Replication and configure:
The
Replicator
service to start automatically.
To log on using the domain user account that was created for
the
Replicator
service.
The names of the of the export servers and domains by adding them to the From List.
See Server Manager Help for more information on configuring the
Replicator
service.
You can set up an export server to replicate a directory tree to itself (from its export directory to its import directory). This replication can provide a local backup of the files, or you can use the import version of these files as another source for users to access, while preserving the export version of the files as a source master.
4.2.3 Managing Export Subdirectories
Use the Server Manager to manage exported subdirectories by clicking on Manage under Export Directories in the Directory Replication dialog box. Aspects of directory replication that you can manage include the following:
Locking a subdirectory to prevent it from being exported to any import computers. For example, if you know that a directory will be receiving a series of changes that you do not want partially replicated, you can put one or more locks on the subdirectory in the export path. Until you remove the lock or locks, the subdirectory will not be replicated. The date and time the lock is placed is displayed so that you know how long a lock has been in effect.
Stabilizing a subdirectory, which causes the export server to wait two minutes after changes before exporting the subdirectory. The waiting period allows time for subsequent changes to take place so that all intended changes are recorded before being replicated.
Specifying to export all of the export subdirectories or only the first-level subdirectory in the export directory path.
4.2.4 Managing Import Subdirectories
You can use locks to prevent imports to subdirectories on an import computer. Locking a subdirectory on an import computer prevents the replication of subdirectories to that computer until the lock is removed. Locking a subdirectory on an import computer affects replication to only that computer, not to other import computers.
Use the Server Manager to manage locks on subdirectories and also view the status of each subdirectory by clicking on Manage under Import Directories in the Directory Replication dialog box.
The Status column can have one of the following four entries:
OK indicates that the subdirectory is receiving regular updates from an export server and that the imported data is identical to the data that is being exported.
No Master indicates that the subdirectory has received updates in the past but is not receiving updates currently. The export server might not be running or a lock may be in effect on the export server
No Sync indicates that although the subdirectory has received updates, the data is not up-to-date. This could be a result of a communications failure, open files on the import computer or export server, the import computer not having access permissions at the export server, an export server malfunction, or a large subdirectory replication in progress.
No entry (blank) indicates that replication never occurred for that subdirectory. Replication may not be configured correctly for this import computer, for the export server, or both.
The Last Update column shows the date and time of the latest change to the import subdirectory or to any of its subdirectories.
See To View a List of, or Manage Locks for, Import Subdirectories in
Server Manager Help for more information on managing locks.
4.2.5 Replicating Logon Scripts
Logon scripts are files that can be assigned to domain user accounts. Every time a user logs on, the assigned logon script runs. Logon scripts allow administrators to affect domain users' environments without managing every aspect of it. When a controller processes a logon request, the system locates the logon script that you specified for the user. See Section 3.1.2 for more information on assigning logon scripts.
If you use logon scripts in a domain that has a PDC and at least one BDC, you should replicate logon scripts among the domain controllers. Master copies of every logon script for a domain should be stored in the replication export directory on one server, which can be the PDC but does not need to be. Copies of the logon scripts should be replicated to every controller that participates in authenticating logons for the domain. If this is done, only one copy of each logon script will need to be maintained and every controller that participates in authenticating domain logons will have identical copies of every user logon script.
By default, the ASU server exports logon scripts from the
/usr/net/servers/lanman/shares/asu/repl/export/scripts
directory
to the
/usr/net/servers/lanman/shares/asu/repl/import/scripts
directory on import computers.
4.2.6 Using Directory Replication
Suppose you manage an environment in which you have a domain that contains two directory trees that you want to replicate: one for logon scripts and one for other data. The computers that need to import the two directory trees are different. Four domain controllers need the logon scripts; however, only two domain controllers and two Windows NT Servers need to import the other data.
The best solution is to set up two export servers: one for the scripts
directory tree and one for the data directory tree.
Remember that a single
export server has only one list of import computers to which it replicates.
If you set up a single export server for the two directories, it exports
both directory trees to all import computers even though not all import computers
use both directory trees.
4.2.7 Replication Troubleshooting Tips
Directory replication problems can have a variety of causes.
When the
Replicator
service generates an error, it is displayed in the Event
Viewer.
The Event Viewer contains information about the Status column in
the Manage Import Directories dialog box and information about messages that
appear while you are configuring directory replication.
See
Chapter 6
for more information about the Event
Viewer.
4.2.7.1 Access Denied
If the Event Viewer shows
access denied
errors for
the
Replicator
service, be sure that:
The
Replicator
service on the export server
and import computer is configured to log on using the same domain user account.
The domain user account used by the import computer's
Replicator
service has permission to read the files on the export
computer.
The default permissions for an export directory grant FullControl to the Replicator local group. If FullControl permission is removed from the directory, exported files are copied to the import computers but receive the wrong permissions, and an access denied error is written to the event log. If necessary, use the Server Manager, select properties for the share that is associated with the export directory, select Permissions, and grant FullControl permission to the Replicator local group
4.2.7.2 Exporting to Specific Computers
Be sure to specify export servers and import computers in the To List and From List in the Directory Replication dialog box. If you fail to do so, exporting will occur to all import computers in the local domain, and importing will occur from all export servers in the local domain.
An export server has only one list of import computers to which it replicates.
All import computers in that list receive all the exported directories and
files.
You cannot be selective about which import computer receives which
export file or directory.
For this level of control, you must use multiple
export servers and configure them accordingly.
4.2.7.3 Lost Permissions in Import Directory
Do not use the Explorer or File Manager to examine permissions in the
/usr/net/servers/lanman/shares/asu/repl/import
directory.
If you
do, special permissions initially set there might be lost.
These initial
permissions enable directory replication to work; you do not need to change
them.
4.2.7.4 Replication to a Domain Name Over a WAN Link
Directory replication to a domain name does not always succeed when
some or all import computers are located across a wide area network (WAN)
bridge from an export server.
When adding names to the export To List on
an export server, and when adding names to the import From List on an import
computer, specify the computer names (instead of or in addition to specifying
the domain name) for those computers separated by a WAN bridge.
4.3 Managing Disk Share Usage
Table 4-4
describes the disk share usage
information that you can display by using the Properties option in the Server
Manager or
net
commands.
Table 4-4: Disk Share Usage
Option | Description | net Command |
Sessions | The users who are remotely connected to the computer and the shares to which they are connected. | # net
session |
Open Files | The number of shared resources opened on the computer. | # net
file |
File Locks | The number of file locks on open resources of the computer. | # net
file |
Open Named Pipes | The number of named pipes open on the computer. In some cases, a print job is monitored as an open named pipe. | # net
file |
See the ASU
Installation and Administration Guide
and the
net help
command for more information on
net
commands.
4.3.1 Disconnecting Users From Shares
You can use the Server Manager or the
net
commands
to disconnect one or all users from a share.
To prevent data loss, always
warn users before disconnecting them.
See
Section 4.3.2
for more information on sending messages.
To use the
net
command to disconnect all users, enter
the following command:
#
net session /delete
Follow these steps to use the Server Manager disconnect one or all users from shares:
If you want to disconnect users who are connected to shares on a remote controller, choose Select Domain to and enter the domain for the controller. While you are administering another computer remotely, your user account is listed as a user connected to the IPC$ resource. It cannot be disconnected.
From the Computer menu, select Properties.
A Properties dialog box is displayed.
Select:
Users to disconnect a user or all users from all shares to which they are connected.
A Users Sessions dialog box is displayed. To disconnect a user, select the user in the list and select Disconnect. To disconnect all users, select Disconnect All.
Shares to disconnect a user or all users from a particular share to which they are connected.
A Shared Resource dialog box is displayed. Select the name of the share in the Sharename window. To disconnect a user, select the user in the Connected Users window and select Disconnect. To disconnect all users, select Disconnect All.
4.3.2 Sending a Message to Users
You can send a message to all users who are connected to shares by using
the Send Message command on the Computer menu in Server Manager.
For example,
you can do this before you disconnect one or more users or before you stop
the
Server
service on a controller.
For a message to be sent and received, the
Messenger
service must be running on the computer sending the message and on the computers
receiving the message.
See Sending a Message to Connected Users in Server Manager Help for more information about sending messages.