1idmap(1M)               System Administration Commands               idmap(1M)
2
3
4

NAME

6       idmap - configure and manage the Native Identity Mapping service
7

SYNOPSIS

9       idmap
10
11
12       idmap -f command-file
13
14
15       idmap add [-d] name1 name2
16
17
18       idmap dump [-n] [-v]
19
20
21       idmap export [-f file] format
22
23
24       idmap get-namemap name
25
26
27       idmap help
28
29
30       idmap import [-F] [-f file] format
31
32
33       idmap list
34
35
36       idmap remove [-t|-f] name
37
38
39       idmap remove -a
40
41
42       idmap remove [-d] name1 name2
43
44
45       idmap set-namemap [-a authenticationMethod] [-D bindDN]
46            [-j passwdfile] name1 name2
47
48
49       idmap show [-c] [-v] identity [target-type]
50
51
52       idmap unset-namemap [-a authenticationMethod] [-D bindDN]
53            [-j passwdfile] name [target-type]
54
55

DESCRIPTION

57       The  idmap  utility is used to configure and manage the Native Identity
58       Mapping service.
59
60
61       The Native Identity Mapping service supports  the  following  types  of
62       mappings  between Windows security identities (SIDs) and POSIX user IDs
63       and group IDs (UIDs and GIDs):
64
65           o      Name-based mapping. An administrator maps Windows  and  UNIX
66                  users and groups by name.
67
68           o      Ephemeral  ID mapping. A UID or GID is dynamically allocated
69                  for every SID that is not already mapped by name.
70
71           o      Local-SID mapping. A non-ephemeral UID or GID is  mapped  to
72                  an algorithmically generated local SID.
73
74
75       The  idmap utility can be used to create and manage the name-based map‐
76       pings and to monitor the mappings in effect.
77
78
79       If the idmap utility is invoked without  a  subcommand  or  option,  it
80       reads  the  subcommands  from  standard input. When standard input is a
81       TTY, the idmap command prints the usage message and exits.
82
83   Mapping Mechanisms
84       The idmapd(1M) daemon maps Windows user and group SIDs to UNIX UIDs and
85       GIDs as follows:
86
87           1.     SIDs are mapped by name.
88
89                  This  mapping uses the name-based mappings that are manually
90                  set up by the system administrator.
91
92           2.     If no name-based mapping is found, the SID is  mapped  to  a
93                  dynamically allocated ephemeral ID.
94
95                  This allocation uses the next available UID or GID from 2^31
96                  to 2^32 - 2.
97
98
99       Local SID mappings are used to map from UNIX to Windows.
100
101
102       To prevent aliasing problems, all file systems, archive and backup for‐
103       mats,  and  protocols  must  store SIDs or map all UIDs and GIDs in the
104       2^31 to 2^32 - 2 range to the nobody user and group.
105
106
107       It is possible to create also diagonal mappings. They are the  mappings
108       between Windows groups and Solaris users and between Solaris groups and
109       Windows users. They are needed when Windows uses a group identity as  a
110       file owner or vice versa.
111
112   Name-based Mappings
113       Name-based  mappings  establish  name equivalence between Windows users
114       and groups and their counterparts in the UNIX name service. These  map‐
115       pings  persist  across reboots. For example, the following command maps
116       Windows users to UNIX users with the same name:
117
118         # idmap add "winuser:*@mywindomain.com" "unixuser:*"
119
120
121
122
123       If configured to use a directory service, idmapd(1M) will first try  to
124       use  the mapping information that is stored in user or group objects in
125       the Active Directory (AD) and/or the native LDAP directory service. For
126       example,  an  AD  object  for a given Windows user or group can be aug‐
127       mented to include the corresponding  Solaris  user  or  group  name  or
128       numeric  id. Similarly, the native LDAP object for a given Solaris user
129       or group can be augmented to include the corresponding Windows user  or
130       group name.
131
132
133       idmapd(1M)  can  be  configured to use AD and/or native LDAP directory-
134       based name mappings  by  setting  the  appropriate  service  management
135       facility  (SMF)  properties  of the idmap service. See "Service Proper‐
136       ties," below, for more details.
137
138
139       If directory-based name mapping is not configured or if configured  but
140       not  found, then idmapd(1M) will process locally stored name-based map‐
141       ping rules.
142
143
144       idmap supports the mapping of Windows well-known names. A few of  these
145       are listed below:
146
147         Administrator
148         Guest
149         KRBTGT
150         Domain Admins
151         Domain Users
152         Domain Guest
153         Domain Computers
154         Domain Controllers
155
156
157
158
159       When  idmap rules are added, these well-known names will be expanded to
160       canonical form. That is, either the default domain name will  be  added
161       (for  names  that are not well-known) or an appropriate built-in domain
162       name will be added. Depending on the particular well-known  name,  this
163       domain name might be null, BUILTIN, or the local host name.
164
165
166       The  following  sequence  of idmap commands illustrate the treatment of
167       the non-well-known name fred and the well-known names administrator and
168       guest.
169
170         # idmap add winname:fred unixuser:fredf
171         add     winname:fred    unixuser:fredf
172
173         # idmap add winname:administrator unixuser:root
174         add     winname:administrator   unixuser:root
175
176         # idmap add winname:guest unixuser:nobody
177         add     winname:guest   unixuser:nobody
178
179         # idmap add wingroup:administrators sysadmin
180         add     wingroup:administrators unixgroup:sysadmin
181
182         # idmap list
183         add     winname:Administrator@examplehost  unixuser:root
184         add     winname:Guest@examplehost  unixuser:nobody
185         add     wingroup:Administrators@BUILTIN unixgroup:sysadmin
186         add     winname:fred@example.com       unixuser:fredf
187
188
189
190   Ephemeral Mappings
191       The  idmapd  daemon  attempts  to preserve ephemeral ID mappings across
192       daemon restarts. However, when IDs cannot be preserved, the daemon maps
193       each  previously  mapped  SID  to a new ephemeral UID or GID value. The
194       daemon will never re-use ephemeral UIDs or GIDs. If the  idmapd  daemon
195       runs  out  of ephemeral UIDs and GIDs, it returns an error as well as a
196       default UID or GID for SIDs that cannot be mapped by name.
197
198
199       The dynamic ID mappings are not retained across reboots. So,  any  SIDs
200       that are dynamically mapped to UNIX UIDs or GIDs are most likely mapped
201       to different IDs after rebooting the system.
202
203   Local SID Mappings
204       If no name-based mapping is found, a non-ephemeral UID or GID is mapped
205       to  an algorithmically generated local SID. The mapping is generated as
206       follows:
207
208         local SID for UID = <machine SID> - <1000 + UID>
209         local SID for GID = <machine SID> - <2^31 + GID>
210
211
212
213
214       <machine SID> is a unique SID generated by the idmap  service  for  the
215       host on which it runs.
216
217   Rule Lookup Order
218       When  mapping a Windows name to a UNIX name, lookup for name-based map‐
219       ping rules is performed in the following order:
220
221           1.     windows-name@domain to ""
222
223           2.     windows-name@domain to unix-name
224
225           3.     windows-name@* to ""
226
227           4.     windows-name@* to unix-name
228
229           5.     *@domain to *
230
231           6.     *@domain to ""
232
233           7.     *@domain to unix-name
234
235           8.     *@* to *
236
237           9.     *@* to ""
238
239           10.    *@* to unix-name
240
241
242       When mapping a UNIX name to a Windows name, lookup for name-based  map‐
243       ping rules is performed in the following order:
244
245           1.     unix-name to ""
246
247           2.     unix-name to windows-name@domain
248
249           3.     * to *@domain
250
251           4.     * to ""
252
253           5.     * to windows-name@domain
254
255   Service Properties
256       The service properties determine the behavior of the idmapd(1M) daemon.
257       These properties are stored in the SMF repository  (see  smf(5))  under
258       property  group  config.  They  can be accessed and modified using svc‐
259       cfg(1M), which requires solaris.smf.value.idmap authorization. The ser‐
260       vice properties for the idmap service are:
261
262       config/ad_unixuser_attr
263
264           Specify  the  name  of the AD attribute that contains the UNIX user
265           name. There is no default.
266
267
268       config/ad_unixgroup_attr
269
270           Specify the name of the AD attribute that contains the  UNIX  group
271           name. There is no default.
272
273
274       config/nldap_winname_attr
275
276           Specify  the  name  of  the Native LDAP attribute that contains the
277           Windows user/group name. There is no default.
278
279
280       config/directory_based_mapping
281
282           Controls support for identity mapping using data stored in a direc‐
283           tory service.
284
285           none disables directory-based mapping.
286
287           name  enables  name-based  mapping  using  the properties described
288           above.
289
290           idmu enables mapping using Microsoft's Identity Management for UNIX
291           (IDMU).  This Windows component allows the administrator to specify
292           a UNIX user ID for each Windows user, mapping the Windows  identity
293           to  the corresponding UNIX identity. Only IDMU data from the domain
294           the Solaris system is a member of is used.
295
296
297
298       Changes to service properties do not affect a  running  idmap  service.
299       The service must be refreshed (with svcadm(1M)) for the changes to take
300       effect.
301

OPERANDS

303       The idmap command uses the following operands:
304
305       format
306
307           Specifies the format in which user name mappings are described  for
308           the export and import subcommands. The Netapp usermap.cfg and Samba
309           smbusers external formats are supported. These external formats are
310           only for users, not groups.
311
312               o      The usermap.cfg rule-mapping format is as follows:
313
314                        windows-username [direction] unix-username
315
316
317                      windows-username  is  a  Windows user name in either the
318                      domain\username or username@domain format.
319
320                      unix-username is a UNIX user name.
321
322
323               direction is one of the following:
324
325                   o      == means  a  bidirectional  mapping,  which  is  the
326                          default.
327
328                   o      => or <= means a unidirectional mapping.
329               The IP qualifier is not supported.
330
331               o      The smbusers rule-mapping format is as follows:
332
333                        unixname = winname1 winname2 ...
334
335
336                      If winname includes whitespace, escape the whitespace by
337                      enclosing the value in double quotes. For  example,  the
338                      following  file  shows  how  to  specify whitespace in a
339                      valid format for the idmap command:
340
341                        $ cat myusermap
342                        terry="Terry Maddox"
343                        pat="Pat Flynn"
344                        cal=cbrown
345
346
347                      The mappings are  imported  as  unidirectional  mappings
348                      from Windows names to UNIX names.
349
350                      The  format  is based on the "username map" entry of the
351                      smb.conf man page, which is available on  the  samba.org
352                      web site. The use of an asterisk (*) for windows-name is
353                      supported. However, the @group directive and the  chain‐
354                      ing of mappings are not supported.
355
356                      By  default,  if  no mapping entries are in the smbusers
357                      file, Samba maps a windows-name to the equivalent  unix-
358                      name,  if any. If you want to set up the same mapping as
359                      Samba does, use the following idmap command:
360
361                        idmap add -d "winuser:*@*" "unixuser:*"
362
363
364
365
366       identity
367
368           Specifies a user name, user ID, group name, or group  ID.  identity
369           is specified as type:value. type is one of the following:
370
371           usid         Windows user SID in text format
372
373
374           gsid         Windows group SID in text format
375
376
377           sid          Windows  group  SID  in  text  format  that can belong
378                        either to a user or to a group
379
380
381           uid          Numeric POSIX UID
382
383
384           gid          Numeric POSIX GID
385
386
387           unixuser     UNIX user name
388
389
390           unixgroup    UNIX group name
391
392
393           winuser      Windows user name
394
395
396           wingroup     Windows group name
397
398
399           winname      Windows user or group name
400
401           value is a number or string that is appropriate  to  the  specified
402           type.  For instance, unixgroup:staff specifies the UNIX group name,
403           staff. The identity gid:10 represents GID 10, which corresponds  to
404           the UNIX group staff.
405
406
407       name
408
409           Specifies  a  UNIX  name  (unixuser,  unixgroup)  or a Windows name
410           (winuser, wingroup) that can be used for name-based mapping rules.
411
412
413           A Windows security entity name can be specified  in  one  of  these
414           ways:
415
416               o      domain\name
417
418               o      name@domain
419
420               o      name, which uses the default mapping domain
421           If name is the empty string (""), mapping is inhibited. Note that a
422           name of "" should not be used to preclude logins by  unmapped  Win‐
423           dows users.
424
425           If  name  uses  the wildcard (*), it matches all names that are not
426           matched by other mappings. Similarly, if name is the wildcard  Win‐
427           dows  name  (*@*), it matches all names in all domains that are not
428           matched by other mappings.
429
430           If name uses the wildcard on both sides of the  mapping  rule,  the
431           name  is  the same for both Windows and Solaris users. For example,
432           if the rule is "*@domain" == "*", the jp@domain Windows  user  name
433           matches this rule and maps to the jp Solaris user name.
434
435           Specifying  the type of name is optional if the type can be deduced
436           from other arguments or types specified on the command line.
437
438
439       target-type
440
441           Used with the show and unset-namemap subcommands. For show,  speci‐
442           fies the mapping type that should be shown. For example, if target-
443           type is sid, idmap show returns the  SID  mapped  to  the  identity
444           specified  on  the  command  line. For unset-namemap, identifies an
445           attribute within the object specified by the name operand.
446
447

OPTIONS

449       The idmap command supports one option and a  set  of  subcommands.  The
450       subcommands also have options.
451
452   Command-Line Option
453       -f command-file
454
455           Reads  and  executes idmap subcommands from command-file. The idmap
456           -f - command reads from standard input. This option is not used  by
457           any subcommands.
458
459
460   Subcommands
461       The following subcommands are supported:
462
463       add [-d] name1 name2
464
465           Adds  a  name-based  mapping  rule. By default, the name mapping is
466           bidirectional. If the -d option is used, a  unidirectional  mapping
467           is created from name1 to name2.
468
469           Either name1 or name2 must be a Windows name, and the other must be
470           a UNIX name. For the Windows name, the winname identity  type  must
471           not be used. Instead, specify one of the winuser or wingroup types.
472           See "Operands" for information about the name operand.
473
474           Note that two unidirectional mappings between the same two names in
475           two  opposite  directions  are equivalent to one bidirectional map‐
476           ping.
477
478           This subcommand requires the  solaris.admin.idmap.rules  authoriza‐
479           tion.
480
481
482       dump [-n] [-v]
483
484           Dumps  all  the  mappings cached since the last system boot. The -n
485           option shows the names, as well. By default, only sids,  uids,  and
486           gids  are  shown.  The -v option shows how the mappings were gener‐
487           ated.
488
489
490       export [-f file] format
491
492           Exports name-based mapping rules to standard output in  the  speci‐
493           fied  format.  The -f file option writes the rules to the specified
494           output file.
495
496
497       get-namemap name
498
499           Get the directory-based name mapping information  from  the  AD  or
500           native LDAP user or group object represented by the specified name.
501
502
503       help
504
505           Displays the usage message.
506
507
508       import [-F] [-f file] format
509
510           Imports  name-based  mapping rules from standard input by using the
511           specified format. The -f file option reads the rules from the spec‐
512           ified file. The -F option flushes existing name-based mapping rules
513           before adding new ones.
514
515           Regardless of the external format used, the imported rules are pro‐
516           cessed  by  using  the semantics and order described in the section
517           "Rule Lookup Order," above.
518
519           This subcommand requires the  solaris.admin.idmap.rules  authoriza‐
520           tion.
521
522
523       list
524
525           Lists  all name-based mapping rules. Each rule appears in its idmap
526           add form.
527
528
529       remove [-t|-f] name
530
531           Removes any name-based mapping rule  that  involves  the  specified
532           name. name can be either a UNIX or Windows user name or group name.
533
534           The  -f  option  removes  rules that use name as the source. The -t
535           option removes rules  that  use  name  as  the  destination.  These
536           options are mutually exclusive.
537
538           This  subcommand  requires the solaris.admin.idmap.rules authoriza‐
539           tion.
540
541
542       remove -a
543
544           Removes all name-based mapping rules.
545
546           This subcommand requires the  solaris.admin.idmap.rules  authoriza‐
547           tion.
548
549
550       remove [-d] name1 name2
551
552           Removes name-based mapping rules between name1 and name2. If the -d
553           option is specified, rules from name1 to name2 are removed.
554
555           Either name1 or name2 must be a Windows name, and the other must be
556           a UNIX name.
557
558           This  subcommand  requires the solaris.admin.idmap.rules authoriza‐
559           tion.
560
561
562       set-namemap [-a authenticationMethod] [-D bindDN] [-j passwdfile] name1
563       name2
564
565           Sets  name  mapping  information  in  the AD or native LDAP user or
566           group object. Either name1 or name2 must be a Windows name, and the
567           other must be a UNIX name.
568
569           If  name1  is  a Windows name, then the UNIX name name2 is added to
570           the AD object represented by name1. Similarly, if name1 is  a  UNIX
571           name  then the Windows name name2 is added to the native LDAP entry
572           represented by name1.
573
574           The following options are supported:
575
576           -a authenticationMethod
577
578               Specify authentication method when modifying native LDAP entry.
579               See ldapaddent(1M) for details. Default value is sasl/GSSAPI.
580
581
582           -D bindDN
583
584               Uses the distinguished name bindDN to bind to the directory.
585
586
587           -j passwdfile
588
589               Specify  a  file  containing the password for authentication to
590               the directory.
591
592
593
594       show [-c] [-v] name [target-type]
595
596           Shows the identity of type, target-type, that  the  specified  name
597           maps  to.  If the optional target-type is omitted, the non-diagonal
598           mapping is shown.
599
600           By default, this subcommand shows  only  mappings  that  have  been
601           established  already.  The -c option forces the evaluation of name-
602           based mapping configurations or the dynamic allocation of IDs.
603
604           The -v option shows how the mapping was generated and also  whether
605           the mapping was just generated or was retrieved from the cache.
606
607
608       unset-namemap [-a authenticationMethod] [-D bindDN] [-j passwdfile]
609       name [target-type]
610
611           Unsets directory-based name mapping  information  from  the  AD  or
612           native  LDAP user or group object represented by the specified name
613           and optional target type.
614
615           See the set-namemap subcommand for options.
616
617

EXAMPLES

619       Example 1 Using a Wildcard on Both Sides of a Name-Based Mapping Rule
620
621
622       The following command maps all Windows user names in the xyz.com domain
623       to  the  UNIX users with the same names provided that one exists and is
624       not otherwise mapped. If such a rule is matched but the UNIX user  name
625       does not exist, an ephemeral ID mapping is used.
626
627
628         # idmap add "winuser:*@xyz.com" "unixuser:*"
629
630
631
632       Example 2 Using a Wildcard on One Side of a Name-Based Mapping Rule
633
634
635       The  following  command  maps all unmapped Windows users in the xyz.com
636       domain to the guest UNIX user. The -d option specifies a unidirectional
637       mapping from *@xyz.com users to the guest user.
638
639
640         # idmap add -d "winuser:*@xyz.com" unixuser:guest
641
642
643
644       Example 3 Adding a Bidirectional Name-Based Mapping Rule
645
646
647       The  following  command  maps Windows user, foobar@example.com, to UNIX
648       user, foo, and conversely:
649
650
651         # idmap add winuser:foobar@example.com unixuser:foo
652
653
654
655
656       This command shows how to remove the mapping added by the previous com‐
657       mand:
658
659
660         # idmap remove winuser:foobar@example.com unixuser:foo
661
662
663
664       Example 4 Showing a UID-to-SID Mapping
665
666           o      The  following command shows the SID that the specified UID,
667                  uid:50000, maps to:
668
669                    # idmap show uid:50000 sid
670                    uid:50000 -> usid:S-1-5-21-3223191800-2000
671
672
673
674           o      The following command shows the  UNIX  user  name  that  the
675                  specified Windows user name, joe@example.com, maps to:
676
677                    # idmap show joe@example.com unixuser
678                    winuser:joe@example.com -> unixuser:joes
679
680
681
682       Example 5 Listing the Cached SID-to-UID Mappings
683
684
685       The  following command shows all of the SID-to-UID mappings that are in
686       the cache:
687
688
689         # idmap dump | grep "uid:"
690         usid:S-1-5-21-3223191800-2000    ==     uid:50000
691         usid:S-1-5-21-3223191800-2001    ==     uid:50001
692         usid:S-1-5-21-3223191800-2006    ==     uid:50010
693         usid:S-1-5-21-3223191900-3000    ==     uid:2147491840
694         usid:S-1-5-21-3223191700-4000    =>     uid:60001
695
696
697
698       Example 6 Batching idmap Requests
699
700
701       The following commands show how to batch idmap requests. This  particu‐
702       lar command sequence does the following:
703
704
705           o      Removes any previous rules for foobar@example.com.
706
707           o      Maps  Windows  user  foobar@example.com to UNIX user bar and
708                  vice-versa.
709
710           o      Maps Windows group members to UNIX  group  staff  and  vice-
711                  versa.
712
713         # idmap <<EOF
714                remove winuser:foobar@example.com
715                add winuser:foobar@example.com unixuser:bar
716                add wingroup:members unixgroup:staff
717         EOF
718
719
720
721       Example 7 Listing Name-Based Mapping Rules
722
723
724       The following command shows how to list the name-based mapping rules:
725
726
727         # idmap list
728         add winuser:foobar@example.com unixuser:bar
729         add wingroup:members unixgroup:staff
730
731
732
733       Example 8 Importing Name-Based Mapping Rules From the usermap.cfg File
734
735
736       The usermap.cfg file can be used to configure name-based mapping rules.
737       The following usermap.cfg file shows mapping  rules  that  map  Windows
738       user  foo@example.com to UNIX user foo, and that map foobar@example.com
739       to the UNIX user foo.
740
741
742         # cat usermap.cfg
743         foo@example.com == foo
744         foobar@example.com => foo
745
746
747
748
749       The following idmap command  imports  usermap.cfg  information  to  the
750       idmapd database:
751
752
753         # cat usermap.cfg | idmap import usermap.cfg
754
755
756
757
758       This command does the same as the previous command:
759
760
761         # idmap import -f usermap.cfg usermap.cfg
762
763
764
765
766       The following commands are equivalent to the previous idmap import com‐
767       mands:
768
769
770         # idmap <<EOF
771                add winuser:foo@example.com unixuser:foo
772                add -d winuser:foobar@example.com unixuser:foo
773         EOF
774
775
776
777       Example 9 Using Name-Based and Ephemeral ID Mapping With Identity Func‐
778       tion Mapping and Exceptions
779
780
781       The  following commands map all users in the example.com Windows domain
782       to UNIX user accounts of the same name. The command also specifies map‐
783       pings  for the following Windows users: joe@example.com, jane.doe@exam‐
784       ple.com, administrator@example.com. The administrator from all  domains
785       is  mapped  to  nobody.  Any  Windows  users without corresponding UNIX
786       accounts are mapped dynamically to available ephemeral UIDs.
787
788
789         # idmap import usermap.cfg <<EOF
790                joe@example.com == joes
791                jane.doe@example.com == janed
792                administrator@* => nobody
793                *@example.com == *
794                *@example.com => nobody
795         EOF
796
797
798
799       Example 10 Adding Directory-based Name Mapping to AD User Object
800
801
802       The following command maps Windows user joe@example.com  to  UNIX  user
803       joe by adding the UNIX name to AD object for joe@example.com.
804
805
806         # idmap set-namemap winuser:joe@example.com joes
807
808
809
810       Example  11  Adding  Directory-based  Name  Mapping to Native LDAP User
811       Object
812
813
814       The following command maps UNIX user foo to Windows  user  foobar@exam‐
815       ple.com by adding the Windows name to native LDAP object for foo.
816
817
818         # idmap set-namemap unixuser:foo foobar@example.com
819
820
821
822       Example 12 Removing Directory-based Name Mapping from AD User Object
823
824
825       The  following  command  removes the UNIX username unixuser from the AD
826       object representing joe@example.com.
827
828
829         # idmap unset-namemap winuser:joe@example.com unixuser
830
831
832

EXIT STATUS

834       0     Successful completion.
835
836
837       >0    An error occurred. A diagnostic message is  written  to  standard
838             error.
839
840

ATTRIBUTES

842       See attributes(5) for descriptions of the following attributes:
843
844
845
846
847       ┌─────────────────────────────┬─────────────────────────────┐
848       │      ATTRIBUTE TYPE         │      ATTRIBUTE VALUE        │
849       ├─────────────────────────────┼─────────────────────────────┤
850       │Availability                 │SUNWcsu                      │
851       ├─────────────────────────────┼─────────────────────────────┤
852       │Interface Stability          │Uncommitted                  │
853       └─────────────────────────────┴─────────────────────────────┘
854

SEE ALSO

856       svcs(1),    idmapd(1M),    ldapaddent(1M),    svcadm(1M),   svccfg(1M),
857       attributes(5), smf(5)
858

NOTES

860       The idmapd service is  managed  by  the  service  management  facility,
861       smf(5).  The  service  identifier  for  the idmapd service is svc:/sys‐
862       tem/idmap.
863
864
865       Use the svcadm command to perform administrative actions on  this  ser‐
866       vice,  such  as  enabling,  disabling, or restarting the service. These
867       actions require the  solaris.smf.manage.idmap  authorization.  Use  the
868       svcs command to query the service's status.
869
870
871       Windows  user  names  are  case-insensitive,  while UNIX user names are
872       case-sensitive. The case of Windows names as they appear in idmap name-
873       rules and idmap show command lines is irrelevant.
874
875
876       Because  common  practice  in UNIX environments is to use all-lowercase
877       user names, wildcard name-rules map Windows names  to  UNIX  user/group
878       names  as  follows:  first, the canonical Windows name (that is, in the
879       case as it appears in the directory) is used as a UNIX  user  or  group
880       name.  If there is no such UNIX entity, then the Windows name's case is
881       folded to lowercase and the result is used as the UNIX  user  or  group
882       name.
883
884
885       As a result of this differing treatment of case, user names that appear
886       to be alike might not be recognized as matches. You must  create  rules
887       to  handle such pairings of strings that differ only in case. For exam‐
888       ple, to map the Windows user sam@example to the Solaris user  Sam,  you
889       must create the following rules:
890
891         # idmap add "winuser:*@example" "unixuser:*"
892         # idmap add winuser:sam@example unixuser:Sam
893
894
895
896
897       For  guidance  on modifying an Active Directory schema, consult the Mi‐
898       crosoft document, Step-by-Step Guide to Using Active  Directory  Schema
899       and  Display  Specifiers, which you can find at their technet web site,
900       http://technet.microsoft.com/.
901
902
903
904SunOS 5.11                        3 Aug 2009                         idmap(1M)
Impressum