| Skip Navigation Links | |
| Exit Print View | |
|
Sun ZFS Storage 7000 System Administration Guide |
Adding a user to a local group
Authentication and Access Control
Local vs. Remote Configurations
Backing up with "dump" and "tar"
Section A: Kerberos issue (KB951191)
Section B: NTLMv2 issue (KB957441)
Identity Mapping Directory-based Mapping
Identity Mapping Name-based Mapping
RIP and RIPng Dynamic Routing Protocols
Receiver Configuration Examples
The identity mapping services manages Windows and Unix user identities simultaneously by using both traditional Unix UIDs (and GIDs) and Windows SIDs. The SMB service uses the identity mapping service to associate Windows and Unix identities. When the SMB service authenticates a user, it uses the identity mapping service to map the user's Windows identity to the appropriate Unix identity. If no Unix identity exists for a Windows user, the service generates a temporary identity using an ephemeral UID and GID. These mappings allow a share to be exported and accessed concurrently by SMB and NFS clients. By associating Windows and Unix identities, an NFS and SMB client can share the same identity, thereby allowing access to the same set of files.
In the Windows operating system, an access token contains the security information for a login session and identifies the user, the user's groups, and the user's privileges. Administrators define Windows users and groups in a Workgroup, or in a SAM database, which is managed on an Active Directory domain controller. Each user and group has a SID. An SID uniquely identifies a user or group both within a host and a local domain, and across all possible Windows domains.
Unix creates user credentials based on user authentication and file permissions. Administrators define Unix users and groups in local password and group files or in a name or directory service, such as NIS and LDAP. Each Unix user and group has a UID and a GID. Typically, the UID or GID uniquely identifies a user or group within a single Unix domain. However, these values are not unique across domains.
The identity mapping service creates and maintains a database of mappings between SIDs, UIDs, and GIDs. Three different mapping approaches are available, as described in the following table:
|
When IDMU mapping is enabled, that method takes precedence over all other mapping methods. If directory-based mapping is enabled, that mapping approach will take precedence over the other approaches. If directory-based mapping is not available, then the service will attempt to map an identity the name-based approach. If no name-based rule is available for a given identity, the service will fallback on creating an ephemeral mapping.
Microsoft offers a feature called "Identity Management for Unix", or IDMU. This software is available for Windows Server 2003, and is bundled with Windows Server 2003 R2 and later. This feature is part of what was called "Services For Unix" in its unbundled form.
The primary use of IDMU is to support Windows as a NIS/NFS server. IDMU adds a "UNIX Attributes" panel to the Active Directory Users and Computers user interface that lets the administrator specify a number of UNIX-related parameters: UID, GID, login shell, home directory, and similar for groups. These parameters are made available through AD through a schema similar to (but not the same as) RFC2307, and through the NIS service.
When the IDMU mapping mode is selected, the identity mapping service consumes these Unix attributes to establish mappings between Windows and Unix identities. This approach is very similar to directory-based mapping, only the identity mapping service queries the property schema established by the IDMU software instead of allowing a custom schema. When this approach is used, no other directory-based mapping may take place.
Directory-based mapping involves annotating an LDAP or Active Directory object with information about how the identity maps to an equivalent identity on the opposite platform. These extra attributes associated with the object must be configured in the following properties.
|
Changing services properties is documented in the BUI and CLI sections of services. The CLI property names are shorter versions of those listed above.
For information on augmenting the Active Directory or the LDAP schemas, see the section Directory-Based Identity Mapping for Users and Groups (Task Map) in the Solaris CIFS Administration Guide on www.docs.sun.com.
The name-based mapping approach involves creating various rules which map identities by name. These rules establish equivalences between Windows identities and Unix identities.
The following properties comprise a name-based rule.
|
Windows names are case-insensitive and Unix names are case-sensitive. The user names JSMITH, JSmith, and jsmith are equivalent names in Windows, but they are three distinct names in Unix. Case sensitivity affects name mappings differently depending on the direction of the mapping.
For a Windows-to-Unix mapping to produce a match, the case of the Windows username must match the case of the Unix user name. For example, only Windows user name "jsmith" matches Unix user name "jsmith". Windows user name "Jsmith" does not match.
An exception to the case matching requirement for Windows-to-Unix mappings occurs when the mapping uses the wildcard character, "*" to map multiple user names. If the identity mapping service encounters a mapping that maps Windows user *@some.domain to Unix user "*", it first searches for a Unix name that matches the Windows name as-is. If it does not find a match, the service converts the entire Windows name to lower case and searches again for a matching Unix name. For example, the windows user name "JSmith@some.domain" maps to Unix user name "jsmith". If, after lowering the case of the Windows user name, the service finds no match, the user does not obtain a mapping. You can create a rule to match strings that differ only in case. For example, you can create a user-specific mapping to map the Windows user "JSmith@sun.com" to Unix user "jSmith". Otherwise, the service assigns an ephemeral ID to the Windows user.
For a Unix-to-Windows mapping to produce a match, the case does not have to match. For example, Unix user name "jsmith" matches any Windows user name with the letters "JSMITH" regardless of case.
When the identity mapping service provides a name mapping, it stores the mapping for 10 minutes, at which point the mapping expires. Within its 10-minute life, a mapping is persistent across restarts of the identity mapping service. If the SMB server requests a mapping for the user after the mapping has expired, the service re-evaluates the mappings.
Changes to the mappings or to the name service directories do not affect existing connections within the 10-minute life of a mapping. The service evaluates mappings only when the client tries to connect to a share and there is no unexpired mapping.
A domain-wide mapping rule matches some or all of the names in a Windows domain to Unix names. The user names on both sides must match exactly (except for case sensitivity conflicts, which are subject to the rules discussed earlier). For example, you can create a bidirectional rule to match all Windows users in "myDomain.com" to Unix users with the same name, and vice-versa. For another example you can create a rule that maps all Windows users in "myDomain.com" in group "Engineering" to Unix users of the same name. You cannot create domain-wide mappings that conflict with other mappings.
Deny mapping rules prevent users from obtaining any mapping, including an ephemeral ID, from the identity mapping service. You can create domain-wide or user-specific deny mappings for Windows users and for Unix users. For example, you can create a mapping to deny access to SMB shares for all Unix users in the group "guest". You cannot create deny mappings that conflict with other mappings.
After creating a name-based mapping, the following symbols indicate the semantics of each rule.
|
If an icon is gray instead of black (
, 
, 
, 
,
), that rule matches a Unix identity which cannot be resolved.
If no name-based mapping rule applies for a particular user, that user will be given temporary credentials through an ephemeral mapping unless they are blocked by a deny mapping. When a Windows user with an ephemeral Unix name creates a file on the system, Windows clients accessing the file using SMB see that the file is owned by that Windows identity. However, NFS clients see that the file is owned by "nobody".
Configuring fine-grained identity mapping rules only applies when you want to have the same user access a common set of files as both an NFS and SMB client. If NFS and SMB clients are accessing disjoint filesystems, there's no need to configure any identity mapping rules.
Reconfiguring the identity mapping service has no effect on active SMB sessions. Connected users remain connected, and their previous name mapping is available for authorizing access to additional shares for up to 10 minutes. To prevent unauthorized access you must configure the mappings before you export shares.
The security that your identity mappings provide is only as good as their synchronization with your directory services. For example, if you create a name-based mapping that denies access to a particular user, and the user's name changes, the mapping no longer denies access to that user.
You can only have one bidirectional mapping for each Windows domain that maps all users in the Windows domain to all Unix identities. If you want to create multiple domain-wide rules, be sure to specify that those rules map only from Windows to Unix.
Use the IDMU mapping mode instead of directory-based mapping whenever possible.
The Mappings tab in the BUI shows how various identities are mapped given the current set of rules. By specifying a Windows entity or Unix entity, the entity will be mapped to its corresponding identity on the opposite platform. The resulting information in the User Properties and Group Properties sections displays information about the mapping identity, including the source of the mapping.
Here is a example of adding two name-based rules in the CLI. The first example creates a bi-directional name-based mapping between a Windows user and Unix user.
twofish:> configuration services idmap twofish:configuration services idmap> create twofish:configuration services idmap (uncommitted)> set windomain=eng.fishworks.com twofish:configuration services idmap (uncommitted)> set winname=Bill twofish:configuration services idmap (uncommitted)> set direction=bi twofish:configuration services idmap (uncommitted)> set unixname=wdp twofish:configuration services idmap (uncommitted)> set unixtype=user twofish:configuration services idmap (uncommitted)> commit twofish:configuration services idmap> list MAPPING WINDOWS ENTITY DIRECTION UNIX ENTITY idmap-000 Bill@eng.fishworks.com (U) == wdp (U)
The next example creates a deny mapping to prevent all Windows users in a domain from obtaining credentials.
twofish:configuration services idmap> create
twofish:configuration services idmap (uncommitted)> list
Properties:
windomain = (unset)
winname = (unset)
direction = (unset)
unixname = (unset)
unixtype = (unset)
twofish:configuration services idmap (uncommitted)> set
windomain=guest.fishworks.com
twofish:configuration services idmap (uncommitted)> set winname=*
twofish:configuration services idmap (uncommitted)> set direction=win2unix
twofish:configuration services idmap (uncommitted)> set unixname=
twofish:configuration services idmap (uncommitted)> set unixtype=user
twofish:configuration services idmap (uncommitted)> commit
twofish:configuration services idmap> list
MAPPING WINDOWS ENTITY DIRECTION UNIX ENTITY
idmap-000 Bill@eng.fishworks.com (U) == wdp (U)
idmap-001 *@guest.fishworks.com (U) => "" (U)
The following are example tasks. See the BUI and CLI sections for how these tasks apply to each interface method.
|