This administration guide provides the information needed to integrate a Solaris 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:The Solaris CIFS Service Configuring the Solaris CIFS Service – Process Overview Utilities and Files Associated With the Solaris CIFS Server and Client Authentication, Directory, Naming, and Time Services CIFS Shares Local CIFS Groups 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. This is a beta release of the Solaris CIFS service for evaluation and OpenSolaris development. Do not use this service in production environments where service availability and data reliability are required. 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 ZFS, 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.

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 Solaris CIFS Client Identity Mapping Service 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 smbadm1M, smbd1M, smbstat1M, smb4, smbautohome4, and pam_smb_passwd5 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:If the file system supports the archive, hidden, read-only, and system attributes, these attributes are made available as the DOS attributes available on Windows systems. ZFS supports these attributes. If the file system supports Solaris extended attributes, they are made available as NTFS alternate data streams. The case-sensitivity capabilities of the file system are made available to CIFS clients. To support both Windows-style access and POSIX access, a file system should support mixed-mode, which is simultaneous support for case-sensitive and case-insensitive name operations.The Solaris OS supports both the NFS and CIFS protocols, which have different expectations regarding case behavior. For instance, Windows clients typically expect case-insensitive behavior while local applications and NFS clients typically expect case-sensitive behavior. The ZFS file system supports three case modes: case-sensitive, case-insensitive, and mixed. The ZFS file system can indicate case conflicts when in mixed mode. Mixed mode is recommended for maximum multi-protocol compatibility. To provide full Windows access control list (ACL) support, file systems should be able to store SIDs and they should at least support NFSv4 ACLs. For information about the supported features of the UFS and ZFS file systems, see the ufs7FS 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. 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 smbutil1, mount_smbfs1M, nsmbrc4, and pam_smbfs_login5 man pages. 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):Name-based mapping. Maps Windows and Solaris users and groups by name in the following ways:Directory-based mapping. Uses name mapping information that is stored in user or group objects in the Active Directory (AD) and/or the native LDAP directory service to map users and groups. Rule-based mapping. An administrator uses rules to map Windows and Solaris users and groups by name. Ephemeral ID mapping. A UID or GID is dynamically allocated as needed for every SID that is not already mapped by name. Ephemeral ID mapping is used by default. Local SID mapping. A non-ephemeral UID or GID is mapped to an algorithmically generated local SID. 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 idmap1M man page. 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 sharectl1M and smb4 man pages. For descriptions of the Solaris CIFS client properties, see the nsmbrc4 man page.The Solaris CIFS properties and their values are stored in the Service Management Facility (SMF). For more information about SMF, see Chapter 15, 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). This section describes the high-level process for configuring the Solaris CIFS service.Determine your identity mapping strategy.See Creating Your Identity Mapping Strategy. Configure the Solaris CIFS service as a client to the various services that are used in your environment.For WINS, see How to Configure WINS. 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.For DNS, see System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP). For Kerberos, see Configuring Kerberos Clients (Task Map) in System Administration Guide: Security Services. For LDAP, see Chapter 12, Setting Up LDAP Clients (Tasks), in System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP). For NIS, see Setting Up NIS Clients in System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP). For NTP, see How to Set Up an NTP Client in System Administration Guide: Network Services. Determine whether you want the Solaris CIFS service to join an existing Windows domain or a Windows workgroup.To join a domain, see How to Configure the Solaris CIFS Service in Domain Mode. To join a workgroup, see How to Configure the Solaris CIFS Service in Workgroup Mode. Define one or more CIFS shares.See Managing CIFS Shares (Task Map). This section describes the CIFS utilities and files that are used by the CIFS service and client.Solaris CIFS Utilities Solaris CIFS Service Daemon Solaris CIFS Files The Solaris CIFS service is only supported in the global zone. 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 sharectl Command sharemgr Command smbadm Command smbstat Command smbutil Command umount_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:How to Mount a Share on a Directory You Own How to Mount a Multiuser Share How to Add a Direct Automounter Entry for a CIFS Share Also, see the mount_smbfs1M man page. The sharectl utility is an administrative tool that enables you to configure and manage file-sharing protocols, such as CIFS and NFS. You can use this command to do the following:Set client and server operational properties Display property values for a specific protocol Obtain the status of a protocol For procedures that use the sharectl utility, see the following:How to Configure WINS How to Customize the Global Solaris CIFS Environment How to View the Global Solaris CIFS Environment Property Settings Also, see the sharectl1M man page. 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:Share. One or more files or directories in a share group. Share group. A container of one or more shared files or directories.Note the following:Options for sharemgr are set to a share group, not to a specific file or directory. All options apply to each file and directory in the group. A file or directory can only be assigned to one share group. However, you can move a file or directory from one group to another. A share group can be used by multiple file system types. For example, the share group my_group could be used by NFS and ZFS and be assigned one set of options for NFS and another set of options for ZFS.When a share is managed by ZFS, sharemgr identifies the share and lists it in a zfs share group. 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 sharesmb property to configure SMB sharing. For more information, see How to Create a CIFS Share (zfs) and the zfs1M and zpool1M man pages.For procedures that use the sharemgr utility, see the following:How to Create a CIFS Share (sharemgr) How to Modify CIFS Share Properties (sharemgr) How to Remove a CIFS Share (sharemgr) Also, see the sharemgr1M man page. 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:How to Configure the Solaris CIFS Service in Domain Mode How to Configure the Solaris CIFS Service in Workgroup Mode How to Create a CIFS Group How to Add a Member to a CIFS Group How to Remove a Member From a CIFS Group How to Modify CIFS Group Properties Also, see the smbadm1M man page. 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 smbstat1M 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 kstat1M man page. Use the smbutil command to perform the following CIFS client tasks:View the shares available for mounting from a particular CIFS server Generate a hash of a password for storing in a file such as $HOME/.nsmbrc Create or remove persistent passwords used to authenticate to CIFS servers Resolve a name to an IP address for a server that uses CIFS over NetBIOS, not TCP Resolve the specified server to the NetBIOS workgroup and system name For procedures that use the smbutil utility, see the following:How to Find Available Shares on a Known File Server How to Mount a Share on a Directory You Own How to Store a Persistent Password How to Configure the PAM Module to Store a Persistent Password How to Delete a Persistent Password How to Mount a Multiuser Share How to Delete All Persistent Passwords Also, see the smbutil1 man page. With this command, you can remove a named CIFS share from a mount point.For more information, see How to Unmount a Share From a Directory You Own, and the mount_smbfs1M man page. 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 idmap1M and idmapd1M man pages.smbd is part of the svc:/network/smb/server:default service.For more information, see the smbd1M man page. The following files support CIFS activities on any computer:/etc/auto_direct /etc/smbautohome $HOME/.nsmbrc 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 Persistent Password.For instructions and examples, see How to Add a Direct Automounter Entry for a CIFS Share. 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 smbautohome4 man page. 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:How to Customize Your Solaris CIFS Environment How to Customize the Global Solaris CIFS Environment How to View the Global Solaris CIFS Environment Property Settings Also, see the nsmbrc4 man page. 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:Active Directory Service (AD). AD is a Windows 2000 directory service that is integrated with the Domain Name System (DNS). AD runs only on domain controllers. In addition to storing and making data available, AD protects network objects from unauthorized access and replicates objects across a network so that data is not lost if one domain controller fails. Domain Name System (DNS). DNS resolves host names to Internet Protocol (IP) addresses for the system. This service enables you to identify a server by either its IP address or its name. Dynamic DNS (DDNS). DDNS is provided with AD and enables a client to dynamically update its entries in the DNS database. Lightweight Data Access Protocol (LDAP). LDAP is a standard, extensible directory access protocol that enables clients and servers that use LDAP naming services to communicate with each other. Network Information Service (NIS). NIS is a naming service that focuses on making network administration more manageable by providing centralized control over a variety of network information. NIS stores information about the network, machine names and addresses, users, and network services. Network Time Protocol (NTP). NTP is a protocol that enables a client to automatically synchronize its system clock with a time server. The clock is synchronized each time the client is booted and any time it contacts the time server. Windows Internet Naming Service (WINS). A WINS server resolves NetBIOS names to IP addresses, which allows computers on your network to locate other NetBIOS devices more quickly and efficiently. The WINS server runs on a Windows system. The WINS server performs a similar function for Windows environments as a DNS server does for UNIX environments. For more information, see How to Configure WINS. 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.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.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.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).All autohome shares are removed when the Solaris CIFS service is restarted. 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=usersThe 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.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:cn= represents the common name ou= represents the organizational unit dc= represents the domain component The attribute type that is used to describe an object's RDN is called a naming attribute.AD uses the naming attributes as follows:cn for the user object class ou for the OU (organizational unit) object class dc for the domainDns object class The autohome feature supports the following wildcard substitutions for the value of the key field:The ampersand character (&) is expanded to the value of the key field for the entry in which it occurs. In the following example, & expands to jane:jane /home/& The question mark character (?) is expanded to the value of the first character in the key field for the entry in which it occurs. In the following example, the path is expanded to /home/jj/jane:jane /home/??/& 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/&The wildcard rule is only applied if an appropriate rule is not matched by another map entry. 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.+nsswitchLike the “catch-all” entry, the nsswitch map is only searched if an appropriate rule is not matched by another map entry.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 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:Administrators. Members of this group can fully administer files and directories on the system. Backup Operators. Members of this group can bypass file security to back up and restore files. Power Users. Members of this group can be assigned ownership of files and directories on the system, and can back up and restore files. 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:An access right is explicitly granted or denied to a user or a group. Access rights are assigned as permissions in a discretionary access control list (DACL) on a per-object basis. A privilege is a system-wide role that implicitly grants members of a group the ability to perform predefined operations. Privileges override or bypass object-level access rights. 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:Back up files and directories. Perform backups without requiring read access permission on the target files and folders. Restore files and directories. Restore files without requiring write access permission on the target files and folders. Take ownership of files and folders. Take ownership of an object without requiring take-ownership access permission. Ownership can only be set to those values that the holder of the privilege may legitimately assign to an object. 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).