test

Solaris CIFS Administration Guide

Chapter 1 Windows Interoperability (Overview)

This administration guide provides the information needed to integrate a SolarisTM Common Internet File System (CIFS) server into an existing Windows environment and also describes the Solaris CIFS client, which enables you to mount CIFS shares on Solaris systems.

Windows clients can access CIFS shares from the Solaris CIFS service as if they were made available from a Windows server. This guide focuses only on the information required to integrate the Solaris CIFS service and how to use the Solaris CIFS client. Windows topics are only covered when those topics affect the integration of the Solaris CIFS service into the Windows environment.

This chapter covers the following topics:

Note –

The Common Internet File System (CIFS) is an enhanced version of the Server Message Block (SMB) protocol, which allows CIFS clients to access files and resources on CIFS servers. The terms SMB and CIFS can be considered interchangeable.

Up-to-date troubleshooting information is available from the OpenSolaris CIFS Server project page.

For information about installing the Solaris CIFS service packages, see Getting Started With the Solaris CIFS Service wiki on the OpenSolaris CIFS Server project page.

The Solaris CIFS Service

The Solaris Operating System (Solaris OS) has reached a new level of Windows interoperability with the introduction of an integrated CIFS service. A Solaris server can now be an active participant in a Windows active directory domain and provide ubiquitous, cross-protocol file sharing through CIFS and NFS to clients in their native dialect.

The Solaris CIFS service allows a native Solaris system to serve files, by means of CIFS shares, to CIFS/SMB enabled clients, such as Windows and Mac OS systems. By virtue of the Solaris CIFS service, a Windows client (or other CIFS client) can interoperate with the Solaris CIFS service as it would with a Windows server.

The Solaris CIFS service can operate in either workgroup mode or in domain mode. In workgroup mode, the Solaris CIFS service is responsible for authenticating users locally when access is requested to shared resources. This authentication process is referred to as local login. In domain mode, the Solaris CIFS service uses pass-through authentication, in which user authentication is delegated to a domain controller.

When a user is successfully authenticated, the Solaris CIFS service generates an access token using the security identifiers (SIDs) that represent the user's identity and the groups of which the user is a member. When the user requests access to files or resources from the service, the access token is used to determine access to files by cross-checking the token with the access control list (ACL) or permissions on files and resources. Solaris OS credentials have been enhanced to fully support Windows-style SIDs. In addition, file systems, such as the ZFSTM file system, support Windows-style ACLs and access checking.

The Solaris OS is unique in that it can manage user identities simultaneously by using both traditional UIDs (and GIDs) and SIDs. When a user is authenticated through the CIFS service, the user's CIFS identity is mapped to the appropriate UNIX® or Network Information Service (NIS) identity by using the idmap identity mapping service. If an existing UNIX or NIS identity exists, that identity is used. Otherwise, a temporary identity is generated using ephemeral UIDs and GIDs, as required. Ephemeral IDs are valid only within each Solaris OS instance and only until the system is rebooted. These IDs are never stored on disk or transmitted over the network. When an ACL is stored on disk through the CIFS service, the SIDs are used to generate the access control entries. Solaris utilities, such as ls and chmod, support ACL management.

For more information about how the Solaris OS manages user identities, see Chapter 2, Identity Mapping Administration (Tasks).

The following diagram shows how a Solaris file server can operate simultaneously with both NIS and Windows domains. The Windows domain controller provides CIFS authentication and naming services for CIFS clients and servers, while the NIS servers provide naming services for NFS clients and servers.

Figure 1–1 Solaris CIFS Environment

Diagram showing the components and interactions in a Solaris CIFS environment.

The Solaris services described in this book include the following components:

Solaris CIFS Service

Note –

The Samba and CIFS services cannot be used simultaneously on a single Solaris system. The Samba service must be disabled in order to run the Solaris CIFS service. For more information, see How to Disable the Samba Service.

For a high-level overview of configuring the Solaris CIFS service, see Configuring the Solaris CIFS Service – Process Overview. For information about configuring the service, see Chapter 3, Solaris CIFS Service Administration (Tasks). For more information about the Solaris CIFS service, see the smbadm(1M), smbd(1M), smbstat(1M), smb(4), smbautohome(4), and pam_smb_passwd(5) man pages.

The CIFS features offered by the Solaris service depend on the file system being shared. To fully support the Solaris CIFS service, a file system should support the following features:

For information about the supported features of the UFS and ZFS file systems, see the ufs(7FS) man page and the Solaris ZFS Administration Guide, respectively.

For information about how to access CIFS shares from your client, refer to the client documentation.

Solaris CIFS Client

The SMB protocol is the natural file-sharing protocol used by Windows and Mac OS systems. Samba implements the SMB protocol for UNIX and Linux systems. The Solaris CIFS client is a Solaris virtual file system that provides access to files and directories from the CIFS service.

By using the Solaris CIFS client, a user can mount remote CIFS shares (directories) on his Solaris system to get read-write access to previously inaccessible files. The Solaris CIFS client does not include the ability to print by means of CIFS or the ability to access CIFS resources other than files and directories. The Solaris CIFS client enables an unprivileged user to mount and unmount shares on directories he owns.

For more information about how to use the Solaris CIFS client to access shares, see Chapter 4, Solaris CIFS Client Administration (Tasks), and the smbutil(1), mount_smbfs(1M), nsmbrc(4), pam_smbfs_login(5), and smbfs(7FS) man pages.

Identity Mapping Service

The Solaris OS includes an identity mapping service that enables you to map identities between Solaris systems and Windows systems.

This identity mapping service supports the following types of mappings between Windows security identities (SIDs) and Solaris user IDs and group IDs (UIDs and GIDs):

The idmap utility can be used to create and manage the name-based mappings and to monitor the mappings in effect.

For more information about mapping user and group identities, see Mapping User and Group Identities. For information about how to determine your identity mapping strategy, see Creating Your Identity Mapping Strategy. For instructions on how to use the idmap command, see Managing Directory-Based Identity Mapping for Users and Groups (Task Map), Managing Rule-Based Identity Mapping for Users and Groups (Task Map), and the idmap(1M) man page.

Managing Solaris CIFS Configuration Properties

The Solaris CIFS service and the Solaris CIFS client use the sharectl command to manage configuration properties. For descriptions of the Solaris CIFS service properties, see the sharectl(1M) and smb(4) man pages. For descriptions of the Solaris CIFS client properties, see the nsmbrc(4) man page.

The Solaris CIFS properties and their values are stored in the Service Management Facility (SMF). For more information about SMF, see Chapter 16, Managing Services (Overview), in System Administration Guide: Basic Administration.

The sharectl command is used throughout the configuration process to set and view properties. This command and examples of its use are described in Chapter 3, Solaris CIFS Service Administration (Tasks). The sharectl command is also used by the Solaris CIFS client to configure the global environment. For more information, see Chapter 4, Solaris CIFS Client Administration (Tasks).

Configuring the Solaris CIFS Service – Process Overview

This section describes the high-level process for configuring the Solaris CIFS service.

  1. Determine your identity mapping strategy.

    See Creating Your Identity Mapping Strategy.

  2. Configure the Solaris CIFS service as a client to the various services that are used in your environment.

    Your Solaris system might need to be a client of other services that are available in your environment.

    The following list shows these other services and points to information about how to configure your Solaris system as a client of that service.

  3. Determine whether you want the Solaris CIFS service to join an existing Windows domain or a Windows workgroup.

  4. Define one or more CIFS shares.

    See Managing CIFS Shares (Task Map).

Utilities and Files Associated With the Solaris CIFS Server and Client

This section describes the CIFS utilities and files that are used by the CIFS service and client.

Note –

The Solaris CIFS service is only supported in the global zone.

Solaris CIFS Utilities

These utilities must be run as superuser or with specific privileges to be fully effective, but requests for information can be made by all users:

mount_smbfs Command

With this command, you can attach a named CIFS share to a specified mount point. The mount_smbfs command enables you to mount a CIFS share to a directory you own without having to become superuser.

For more information, see the following:

Also, see the mount_smbfs(1M) man page.

sharectl Command

The sharectl utility is an administrative tool that enables you to configure and manage file-sharing protocols, such as CIFS and NFS, and network protocols such as NetBIOS. You can use this command to do the following:

For procedures that use the sharectl utility, see the following:

Also, see the sharectl(1M) man page.

sharemgr Command

The sharemgr utility is an administrative tool that provides an enhanced method of sharing files and performing related tasks. The sharemgr utility introduces the following concepts:

Note –

The sharemgr utility provides a unique way of checking the validity of a desired configuration. The -n option allows you to test the validity of the options and properties you want to use with a specific subcommand. The test does not change your configuration. For example, if you use the -n option with the subcommand create, no share group is created.

You can also use the ZFS file system sharesmb property to configure SMB sharing. For more information, see How to Create a CIFS Share (zfs) and the zfs(1M) and zpool(1M) man pages.

For procedures that use the sharemgr utility, see the following:

Also, see the sharemgr(1M) man page.

smbadm Command

You can use the smbadm command to manage domain membership of the Solaris CIFS service. For instance, you can have the Solaris CIFS service use domain mode or workgroup mode. The smbadm command also enables you to configure CIFS local groups. CIFS local groups can be used when Windows accounts must be members of some local groups and when Windows-style privileges must be granted. Solaris local groups cannot provide these functionalities.

For procedures that use the smbadm utility, see the following:

Also, see the smbadm(1M) man page.

smbstat Command

You can use the smbstat command to show statistical information about the smbd server. By default, the smbstat command shows general information about the CIFS service as well as dispatched CIFS request counters. For more information, see the smbstat(1M) man page.

The kstat command can be used to report on kernel CIFS statistics on a periodic basis and also to specify information about individual CIFS statistics. For more information, see the kstat(1M) man page.

smbutil Command

Use the smbutil command to perform the following CIFS client tasks:

For procedures that use the smbutil utility, see the following:

Also, see the smbutil(1) man page.

umount_smbfs Command

With this command, you can remove a named CIFS share from a mount point.

For more information, see How to Unmount a CIFS Share From a Directory You Own, and the mount_smbfs(1M) man page.

Solaris CIFS Service Daemon

The smbd daemon supports CIFS activities on Solaris systems. The smbd daemon provides the gateway to the various user space components that support non-file I/O CIFS services. Similar to the NFS kernel service, the SMB kernel module provides SMB file I/O services directly between the network interface and the virtual file system (VFS) within the kernel. Whenever a non-file I/O request is received, such as a user authentication or an MS-RPC named pipe request, it is passed to smbd for processing in user space. Requests that require interaction with a domain controller are passed to the SMB Redirector, which provides a simple user space SMB client for IPC communication.

The smbd daemon depends on the idmapd daemon. For more information about the identity mapping service, see Chapter 2, Identity Mapping Administration (Tasks), and the idmap(1M) and idmapd(1M) man pages.

smbd is part of the svc:/network/smb/server:default service.

For more information, see the smbd(1M) man page.

Solaris CIFS Files

The following files support CIFS activities on any computer:

/etc/auto_direct File

Use the /etc/auto_direct file to automatically mount a CIFS share when a user accesses the mount point. To use the automount feature, you must store a persistent password for authentication to mount the share. See How to Store a CIFS Persistent Password.

For instructions and examples, see How to Add an Automounter Entry for a CIFS Share.

/etc/smbautohome File

The /etc/smbautohome file is used to define the automatic sharing rules to be applied when a user connects to the Solaris CIFS service. For more information, see Autohome Shares and the smbautohome(4) man page.

$HOME/.nsmbrc File

You can use the $HOME/.nsmbrc file to override global behavior of the Solaris CIFS client. Global values are set in the Service Management Facility (SMF). The .nsmbrc file is used to customize the behavior of the Solaris CIFS client on a per-user basis.

By default, settings in the $HOME/.nsmbrc file are used unless they have security implications, in which case the stronger security setting is used.

For procedures that refer to the $HOME/.nsmbrc file, see the following:

Also, see the nsmbrc(4) man page.

Authentication, Directory, Naming, and Time Services

This section describes the various services that the Solaris CIFS service interoperates with as a client.

The Solaris CIFS service interoperates with a variety of naming services that are used by Windows and Solaris system networks. These naming services include the following:

CIFS Shares

A shared resource, or share, is a local resource on a server that is accessible to CIFS clients on the network. For the Solaris CIFS service, a share is typically a directory. Each share is identified by a name on the network. A CIFS client sees the share as a complete entity on the CIFS server, and does not see the local directory path to the share on the server.

Note –

A share and a directory are independent entities. Removing a share does not affect the underlying directory.

Shares are commonly used to provide network access to home directories on a network file server. Each user is assigned a home directory. A share is persistent and remains defined regardless of whether users are connected to the server.

The Solaris CIFS service provides a special kind of share called an autohome CIFS share. An autohome share is a transient share of a user's home directory that is created when a user logs in and removed when the user logs out.

When a user browses the system, only statically defined shares and his autohome share will be listed.

Autohome Shares

The autohome share feature eliminates the administrative task of defining and maintaining home directory shares for each user that accesses the system through the SMB protocol. The system creates autohome shares when a user logs in, and removes them when the user logs out. This process reduces the administrative effort needed to maintain user accounts, and increases the efficiency of service resources.

For example, if /home is a home directory that contains subdirectories for users bob and sally, you can manually define the shares as follows:

bob

/home/bob

sally

/home/sally

However, defining and maintaining directory shares in this way for each user is inconvenient. Instead, you can use the autohome feature.

Note –

The Solaris CIFS client does not support autohome shares.

To configure the autohome feature, you need to specify autohome share rules. For example, if a user's home directory is /fort/sally, the autohome path is /fort. The temporary share is named sally. Note that the user's home directory name must be the same as the user's login name. See How to Create a Specific Autohome Share Rule.

When a user logs in, the Solaris CIFS service looks for a subdirectory that matches the user's name based on any rules that have been specified. If the service finds a match and if that share does not already exist, the subdirectory is added as a transient share. When the user logs out, the service removes that transient share.

Some Windows clients log a user out after 15 minutes of inactivity, which results in the autohome share disappearing from the list of defined shares. This behavior is expected for CIFS autohome shares. Even after a CIFS autohome share is removed, the share reappears when the user attempts to access the system (for example, in an Explorer window).

Note –

All autohome shares are removed when the Solaris CIFS service is restarted.

Autohome Entries

The Solaris CIFS service can automatically share home directories when a CIFS client connects. The autohome map file, /etc/smbautohome, uses the search options and rules to determine whether to share a home directory when a CIFS client connects to the service.

For example, the following entries specify the autohome rules for a particular environment:


+nsswitch	    dn=ads,dn=sun,dn=com,ou=users
jane    /home/?/&    dn=ads,dn=sun,dn=com,ou=users

The nsswitch autohome entry uses the naming service to match users to home directories. The second autohome entry specifies that the home directory for user jane is /home/j/jane.

Autohome Map Entry Format

A map entry, also referred to as a mapping, uses the following format:


key location [ container ]

key is a user name, location is the fully qualified path for the user's home directory, and container is an optional AD container.

If you intend to publish the share in AD, you must specify an AD container name, which is specified as a comma-separated list of attribute name-value pairs. The attributes use the Lightweight Data Access Protocol (LDAP) distinguished name (DN) or relative distinguished name (RDN) format.

The DN or RDN must be specified in LDAP format by using the following attribute types:

Note –

The attribute type that is used to describe an object's RDN is called a naming attribute.

AD uses the naming attributes as follows:

Autohome Map Key Substitution

The autohome feature supports the following wildcard substitutions for the value of the key field:

Wildcard Rule

When supplied in the key field, the asterisk character (*) is recognized as the “catch-all” entry. Such an entry matches any key not previously matched.

For example, the following entry would map any user to a home directory in /home in which the home directory name was the same as the user name:

*    /home/&
Note –

The wildcard rule is only applied if an appropriate rule is not matched by another map entry.

nsswitch Map

The nsswitch map is used to request that the home directory be obtained from a password database, such as the local, NIS, or LDAP database. If an AD path is appended, it is used to publish shares.

+nsswitch

Like the “catch-all” entry, the nsswitch map is only searched if an appropriate rule is not matched by another map entry.

Note –

The wildcard and nsswitch rules are mutually exclusive. Do not include an nsswitch rule if a wildcard rule has already been defined.

Local CIFS Groups

Local CIFS groups can be created on the system that runs the Solaris CIFS service. These CIFS groups apply only to users that are connected through CIFS.

The Solaris CIFS service supports the following built-in CIFS groups:

Local groups use privileges to provide a secure mechanism for assigning task responsibility on a system-wide basis. Each privilege has a well-defined role assigned by the system administrator to a user or a group.

Unlike access rights (which are assigned as permissions on a per-object basis through security descriptors), privileges are independent of objects. Privileges bypass object-based access control lists to allow the holder of the privilege to perform the role assigned. For example, members of the Backup Operators group must be able to bypass normal security checks to back up and restore files they would normally not be able to access.

The following definitions show the difference between an access right and a privilege:

You can assign any of the privileges to any of the local groups. Because you can make any domain user a member of the local groups, you can assign these privileges to any domain user.

The following privileges are supported for local groups:

By default, members of the local Administrators group can take ownership of any file or folder, and members of the Backup Operators group can perform backup and restore operations. Members of the Power Users group do not have default privileges.

For information about managing CIFS groups, see Managing CIFS Groups (Task Map).