1 | <?xml version="1.0" encoding="iso-8859-1"?>
|
---|
2 | <!DOCTYPE chapter PUBLIC "-//Samba-Team//DTD DocBook V4.2-Based Variant V1.0//EN" "http://www.samba.org/samba/DTD/samba-doc">
|
---|
3 | <chapter id="groupmapping">
|
---|
4 | <chapterinfo>
|
---|
5 | &author.jht;
|
---|
6 | <author>
|
---|
7 | <firstname>Jean François</firstname><surname>Micouleau</surname>
|
---|
8 | </author>
|
---|
9 | &author.jerry;
|
---|
10 | </chapterinfo>
|
---|
11 | <title>Group Mapping: MS Windows and UNIX</title>
|
---|
12 |
|
---|
13 |
|
---|
14 | <para>
|
---|
15 | <indexterm significance="preferred"><primary>groups</primary><secondary>mapping</secondary></indexterm>
|
---|
16 | <indexterm><primary>SID</primary></indexterm>
|
---|
17 | <indexterm><primary>associations</primary></indexterm>
|
---|
18 | <indexterm><primary>UNIX groups</primary></indexterm>
|
---|
19 | <indexterm><primary>groupmap</primary></indexterm>
|
---|
20 | <indexterm><primary>net</primary></indexterm>
|
---|
21 | Starting with Samba-3, new group mapping functionality is available to create associations
|
---|
22 | between Windows group SIDs and UNIX group GIDs. The <command>groupmap</command> subcommand
|
---|
23 | included with the &net; tool can be used to manage these associations.
|
---|
24 | </para>
|
---|
25 |
|
---|
26 | <para>
|
---|
27 | <indexterm><primary>group mapping</primary></indexterm>
|
---|
28 | <indexterm><primary>domain groups</primary></indexterm>
|
---|
29 | The new facility for mapping NT groups to UNIX system groups allows the administrator to decide
|
---|
30 | which NT domain groups are to be exposed to MS Windows clients. Only those NT groups that map
|
---|
31 | to a UNIX group that has a value other than the default (<constant>-1</constant>) will be exposed
|
---|
32 | in group selection lists in tools that access domain users and groups.
|
---|
33 | </para>
|
---|
34 |
|
---|
35 | <warning>
|
---|
36 | <para>
|
---|
37 | <indexterm><primary>domain admin group</primary></indexterm>
|
---|
38 | <indexterm><primary>Windows group</primary></indexterm>
|
---|
39 | The <parameter>domain admin group</parameter> parameter has been removed in Samba-3 and should no longer
|
---|
40 | be specified in &smb.conf;. In Samba-2.2.x, this parameter was used to give the listed users membership in the
|
---|
41 | <constant>Domain Admins</constant> Windows group, which gave local admin rights on their workstations
|
---|
42 | (in default configurations).
|
---|
43 | </para>
|
---|
44 | </warning>
|
---|
45 |
|
---|
46 | <sect1>
|
---|
47 | <title>Features and Benefits</title>
|
---|
48 |
|
---|
49 | <para>
|
---|
50 | Samba allows the administrator to create MS Windows NT4/200x group accounts and to
|
---|
51 | arbitrarily associate them with UNIX/Linux group accounts.
|
---|
52 | </para>
|
---|
53 |
|
---|
54 | <para>
|
---|
55 | <indexterm><primary>UID</primary></indexterm>
|
---|
56 | <indexterm><primary>GID</primary></indexterm>
|
---|
57 | <indexterm><primary>idmap uid</primary></indexterm>
|
---|
58 | <indexterm><primary>MMC</primary></indexterm>
|
---|
59 | <indexterm><primary>winbindd</primary></indexterm>
|
---|
60 | <indexterm><primary>ID range</primary></indexterm>
|
---|
61 | <indexterm><primary>group accounts</primary></indexterm>
|
---|
62 | Group accounts can be managed using the MS Windows NT4 or MS Windows 200x/XP Professional MMC tools.
|
---|
63 | Appropriate interface scripts should be provided in &smb.conf; if it is desired that UNIX/Linux system
|
---|
64 | accounts should be automatically created when these tools are used. In the absence of these scripts, and
|
---|
65 | so long as <command>winbindd</command> is running, Samba group accounts that are created using these
|
---|
66 | tools will be allocated UNIX UIDs and GIDs from the ID range specified by the
|
---|
67 | <smbconfoption name="idmap uid"/>/<smbconfoption name="idmap gid"/>
|
---|
68 | parameters in the &smb.conf; file.
|
---|
69 | </para>
|
---|
70 |
|
---|
71 | <figure id="idmap-sid2gid">
|
---|
72 | <title>IDMAP: Group SID-to-GID Resolution.</title>
|
---|
73 | <imagefile scale="50">idmap-sid2gid</imagefile>
|
---|
74 | </figure>
|
---|
75 |
|
---|
76 | <figure id="idmap-gid2sid">
|
---|
77 | <title>IDMAP: GID Resolution to Matching SID.</title>
|
---|
78 | <imagefile scale="50">idmap-gid2sid</imagefile>
|
---|
79 | </figure>
|
---|
80 |
|
---|
81 | <para>
|
---|
82 | <indexterm><primary>IDMAP</primary></indexterm>
|
---|
83 | <indexterm><primary>SID-to-GID</primary></indexterm>
|
---|
84 | <indexterm><primary>net</primary><secondary>groupmap</secondary></indexterm>
|
---|
85 | <indexterm><primary>group mappings</primary></indexterm>
|
---|
86 | In both cases, when winbindd is not running, only locally resolvable groups can be recognized. Please refer to
|
---|
87 | <link linkend="idmap-sid2gid">IDMAP: Group SID-to-GID Resolution</link> and <link
|
---|
88 | linkend="idmap-gid2sid">IDMAP: GID Resolution to Matching SID</link>. The <command>net groupmap</command> is
|
---|
89 | used to establish UNIX group to NT SID mappings as shown in <link linkend="idmap-store-gid2sid">IDMAP: storing
|
---|
90 | group mappings</link>.
|
---|
91 | </para>
|
---|
92 |
|
---|
93 | <figure id="idmap-store-gid2sid">
|
---|
94 | <title>IDMAP Storing Group Mappings.</title>
|
---|
95 | <imagefile scale="50">idmap-store-gid2sid</imagefile>
|
---|
96 | </figure>
|
---|
97 |
|
---|
98 | <para>
|
---|
99 | <indexterm><primary>groupadd</primary></indexterm>
|
---|
100 | <indexterm><primary>groupdel</primary></indexterm>
|
---|
101 | <indexterm><primary>shadow utilities</primary></indexterm>
|
---|
102 | <indexterm><primary>groupmod</primary></indexterm>
|
---|
103 | Administrators should be aware that where &smb.conf; group interface scripts make
|
---|
104 | direct calls to the UNIX/Linux system tools (the shadow utilities, <command>groupadd</command>,
|
---|
105 | <command>groupdel</command>, and <command>groupmod</command>), the resulting UNIX/Linux group names will be subject
|
---|
106 | to any limits imposed by these tools. If the tool does not allow uppercase characters
|
---|
107 | or space characters, then the creation of an MS Windows NT4/200x-style group of
|
---|
108 | <literal>Engineering Managers</literal> will attempt to create an identically named
|
---|
109 | UNIX/Linux group, an attempt that will of course fail.
|
---|
110 | </para>
|
---|
111 |
|
---|
112 | <para>
|
---|
113 | <indexterm><primary>GID</primary></indexterm>
|
---|
114 | <indexterm><primary>SID</primary></indexterm>
|
---|
115 | There are several possible workarounds for the operating system tools limitation. One
|
---|
116 | method is to use a script that generates a name for the UNIX/Linux system group that
|
---|
117 | fits the operating system limits and that then just passes the UNIX/Linux group ID (GID)
|
---|
118 | back to the calling Samba interface. This will provide a dynamic workaround solution.
|
---|
119 | </para>
|
---|
120 |
|
---|
121 | <para>
|
---|
122 | <indexterm><primary>net</primary><secondary>groupmap</secondary></indexterm>
|
---|
123 | Another workaround is to manually create a UNIX/Linux group, then manually create the
|
---|
124 | MS Windows NT4/200x group on the Samba server, and then use the <command>net groupmap</command>
|
---|
125 | tool to connect the two to each other.
|
---|
126 | </para>
|
---|
127 |
|
---|
128 | </sect1>
|
---|
129 |
|
---|
130 | <sect1>
|
---|
131 | <title>Discussion</title>
|
---|
132 |
|
---|
133 | <para>
|
---|
134 | <indexterm><primary>Windows NT4/200x</primary></indexterm>
|
---|
135 | <indexterm><primary>group privileges</primary></indexterm>
|
---|
136 | When you install <application>MS Windows NT4/200x</application> on a computer, the installation
|
---|
137 | program creates default users and groups, notably the <constant>Administrators</constant> group,
|
---|
138 | and gives that group privileges necessary to perform essential system tasks,
|
---|
139 | such as the ability to change the date and time or to kill (or close) any process running on the
|
---|
140 | local machine.
|
---|
141 | </para>
|
---|
142 |
|
---|
143 | <para>
|
---|
144 | <indexterm><primary>Administrator</primary></indexterm>
|
---|
145 | The <constant>Administrator</constant> user is a member of the <constant>Administrators</constant> group, and thus inherits
|
---|
146 | <constant>Administrators</constant> group privileges. If a <constant>joe</constant> user is created to be a member of the
|
---|
147 | <constant>Administrators</constant> group, <constant>joe</constant> has exactly the same rights as the user
|
---|
148 | <constant>Administrator</constant>.
|
---|
149 | </para>
|
---|
150 |
|
---|
151 | <para>
|
---|
152 | <indexterm><primary>domain member</primary></indexterm>
|
---|
153 | <indexterm><primary>Domain Admins</primary></indexterm>
|
---|
154 | <indexterm><primary>inherits rights</primary></indexterm>
|
---|
155 | <indexterm><primary>PDC</primary></indexterm>
|
---|
156 | When an MS Windows NT4/200x/XP machine is made a domain member, the <quote>Domain Admins</quote> group of the
|
---|
157 | PDC is added to the local <constant>Administrators</constant> group of the workstation. Every member of the
|
---|
158 | <constant>Domain Admins</constant> group inherits the rights of the local <constant>Administrators</constant> group when
|
---|
159 | logging on the workstation.
|
---|
160 | </para>
|
---|
161 |
|
---|
162 | <para>
|
---|
163 | <indexterm><primary>Domain Admins</primary></indexterm>
|
---|
164 | <indexterm><primary>PDC</primary></indexterm>
|
---|
165 | The following steps describe how to make Samba PDC users members of the <constant>Domain Admins</constant> group.
|
---|
166 | </para>
|
---|
167 |
|
---|
168 | <orderedlist>
|
---|
169 | <listitem><para>
|
---|
170 | Create a UNIX group (usually in <filename>/etc/group</filename>); let's call it <constant>domadm</constant>.
|
---|
171 | </para></listitem>
|
---|
172 |
|
---|
173 | <listitem><para>
|
---|
174 | <indexterm><primary>/etc/group</primary></indexterm>
|
---|
175 | Add to this group the users that must be <quote>Administrators</quote>. For example,
|
---|
176 | if you want <constant>joe, john</constant>, and <constant>mary</constant> to be administrators,
|
---|
177 | your entry in <filename>/etc/group</filename> will look like this:
|
---|
178 | </para>
|
---|
179 |
|
---|
180 | <para><programlisting>
|
---|
181 | domadm:x:502:joe,john,mary
|
---|
182 | </programlisting>
|
---|
183 | </para></listitem>
|
---|
184 |
|
---|
185 | <listitem><para>
|
---|
186 | Map this domadm group to the <quote>Domain Admins</quote> group by executing the command:
|
---|
187 | </para>
|
---|
188 |
|
---|
189 | <para>
|
---|
190 | <screen>
|
---|
191 | &rootprompt;<userinput>net groupmap add ntgroup="Domain Admins" unixgroup=domadm rid=512 type=d</userinput>
|
---|
192 | </screen>
|
---|
193 | </para>
|
---|
194 |
|
---|
195 | <para>
|
---|
196 | <indexterm><primary>Domain Admins group</primary></indexterm>
|
---|
197 | The quotes around <quote>Domain Admins</quote> are necessary due to the space in the group name.
|
---|
198 | Also make sure to leave no white space surrounding the equal character (=).
|
---|
199 | </para></listitem>
|
---|
200 | </orderedlist>
|
---|
201 |
|
---|
202 | <para>
|
---|
203 | Now <constant>joe, john</constant>, and <constant>mary</constant> are domain administrators.
|
---|
204 | </para>
|
---|
205 |
|
---|
206 | <para>
|
---|
207 | <indexterm><primary>groups</primary><secondary>domain</secondary></indexterm>
|
---|
208 | It is possible to map any arbitrary UNIX group to any Windows NT4/200x group as well as
|
---|
209 | to make any UNIX group a Windows domain group. For example, if you wanted to include a
|
---|
210 | UNIX group (e.g., acct) in an ACL on a local file or printer on a Domain Member machine,
|
---|
211 | you would flag that group as a domain group by running the following on the Samba PDC:
|
---|
212 | </para>
|
---|
213 |
|
---|
214 | <para>
|
---|
215 | <screen>
|
---|
216 | &rootprompt;<userinput>net groupmap add rid=1000 ntgroup="Accounting" unixgroup=acct type=d</userinput>
|
---|
217 | </screen>
|
---|
218 | The <literal>ntgroup</literal> value must be in quotes if it contains space characters to prevent
|
---|
219 | the space from being interpreted as a command delimiter.
|
---|
220 | </para>
|
---|
221 |
|
---|
222 | <para>
|
---|
223 | <indexterm><primary>RID</primary></indexterm>
|
---|
224 | <indexterm><primary>assigned RID</primary></indexterm>
|
---|
225 | Be aware that the RID parameter is an unsigned 32-bit integer that should
|
---|
226 | normally start at 1000. However, this RID must not overlap with any RID assigned
|
---|
227 | to a user. Verification for this is done differently depending on the passdb backend
|
---|
228 | you are using. Future versions of the tools may perform the verification automatically,
|
---|
229 | but for now the burden is on you.
|
---|
230 | </para>
|
---|
231 |
|
---|
232 | <sect2>
|
---|
233 | <title>Warning: User Private Group Problems</title>
|
---|
234 |
|
---|
235 | <para>
|
---|
236 | <indexterm><primary>group accounts</primary></indexterm>
|
---|
237 | <indexterm><primary>Red Hat Linux</primary></indexterm>
|
---|
238 | <indexterm><primary>private groups</primary></indexterm>
|
---|
239 | Windows does not permit user and group accounts to have the same name.
|
---|
240 | This has serious implications for all sites that use private group accounts.
|
---|
241 | A private group account is an administrative practice whereby users are each
|
---|
242 | given their own group account. Red Hat Linux, as well as several free distributions
|
---|
243 | of Linux, by default create private groups.
|
---|
244 | </para>
|
---|
245 |
|
---|
246 | <para>
|
---|
247 | <indexterm><primary>UNIX/Linux group</primary></indexterm>
|
---|
248 | <indexterm><primary>Windows group</primary></indexterm>
|
---|
249 | When mapping a UNIX/Linux group to a Windows group account, all conflict can
|
---|
250 | be avoided by assuring that the Windows domain group name does not overlap
|
---|
251 | with any user account name.
|
---|
252 | </para>
|
---|
253 |
|
---|
254 | </sect2>
|
---|
255 |
|
---|
256 | <sect2>
|
---|
257 | <title>Nested Groups: Adding Windows Domain Groups to Windows Local Groups</title>
|
---|
258 |
|
---|
259 | <indexterm><primary>groups</primary><secondary>nested</secondary></indexterm>
|
---|
260 |
|
---|
261 | <para>
|
---|
262 | <indexterm><primary>nested groups</primary></indexterm>
|
---|
263 | This functionality is known as <constant>nested groups</constant> and was first added to
|
---|
264 | Samba-3.0.3.
|
---|
265 | </para>
|
---|
266 |
|
---|
267 | <para>
|
---|
268 | <indexterm><primary>nested groups</primary></indexterm>
|
---|
269 | All MS Windows products since the release of Windows NT 3.10 support the use of nested groups.
|
---|
270 | Many Windows network administrators depend on this capability because it greatly simplifies security
|
---|
271 | administration.
|
---|
272 | </para>
|
---|
273 |
|
---|
274 | <para>
|
---|
275 | <indexterm><primary>nested group</primary></indexterm>
|
---|
276 | <indexterm><primary>group membership</primary></indexterm>
|
---|
277 | <indexterm><primary>domain security</primary></indexterm>
|
---|
278 | <indexterm><primary>domain member server</primary></indexterm>
|
---|
279 | <indexterm><primary>local groups</primary></indexterm>
|
---|
280 | <indexterm><primary>domain global groups</primary></indexterm>
|
---|
281 | <indexterm><primary>domain global users</primary></indexterm>
|
---|
282 | The nested group architecture was designed with the premise that day-to-day user and group membership
|
---|
283 | management should be performed on the domain security database. The application of group security
|
---|
284 | should be implemented on domain member servers using only local groups. On the domain member server,
|
---|
285 | all file system security controls are then limited to use of the local groups, which will contain
|
---|
286 | domain global groups and domain global users.
|
---|
287 | </para>
|
---|
288 |
|
---|
289 | <para>
|
---|
290 | <indexterm><primary>individual domain user</primary></indexterm>
|
---|
291 | <indexterm><primary>domain group settings</primary></indexterm>
|
---|
292 | <indexterm><primary>Account Unknown</primary></indexterm>
|
---|
293 | You may ask, What are the benefits of this arrangement? The answer is obvious to those who have plumbed
|
---|
294 | the dark depths of Windows networking architecture. Consider for a moment a server on which are stored
|
---|
295 | 200,000 files, each with individual domain user and domain group settings. The company that owns the
|
---|
296 | file server is bought by another company, resulting in the server being moved to another location, and then
|
---|
297 | it is made a member of a different domain. Who would you think now owns all the files and directories?
|
---|
298 | Answer: Account Unknown.
|
---|
299 | </para>
|
---|
300 |
|
---|
301 | <para>
|
---|
302 | <indexterm><primary>directory access control</primary></indexterm>
|
---|
303 | <indexterm><primary>local groups</primary></indexterm>
|
---|
304 | <indexterm><primary>ACL</primary></indexterm>
|
---|
305 | <indexterm><primary>Account Unknown</primary></indexterm>
|
---|
306 | Unraveling the file ownership mess is an unenviable administrative task that can be avoided simply
|
---|
307 | by using local groups to control all file and directory access control. In this case, only the members
|
---|
308 | of the local groups will have been lost. The files and directories in the storage subsystem will still
|
---|
309 | be owned by the local groups. The same goes for all ACLs on them. It is administratively much simpler
|
---|
310 | to delete the <constant>Account Unknown</constant> membership entries inside local groups with appropriate
|
---|
311 | entries for domain global groups in the new domain that the server has been made a member of.
|
---|
312 | </para>
|
---|
313 |
|
---|
314 | <para>
|
---|
315 | <indexterm><primary>nested groups</primary></indexterm>
|
---|
316 | <indexterm><primary>administrative privileges</primary></indexterm>
|
---|
317 | <indexterm><primary>domain member workstations</primary></indexterm>
|
---|
318 | <indexterm><primary>domain member servers</primary></indexterm>
|
---|
319 | <indexterm><primary>member machine</primary></indexterm>
|
---|
320 | <indexterm><primary>full rights</primary></indexterm>
|
---|
321 | <indexterm><primary>Domain Admins</primary></indexterm>
|
---|
322 | <indexterm><primary>local administrative privileges</primary></indexterm>
|
---|
323 | Another prominent example of the use of nested groups involves implementation of administrative privileges
|
---|
324 | on domain member workstations and servers. Administrative privileges are given to all members of the
|
---|
325 | built-in local group <constant>Administrators</constant> on each domain member machine. To ensure that all domain
|
---|
326 | administrators have full rights on the member server or workstation, on joining the domain, the
|
---|
327 | <constant>Domain Admins</constant> group is added to the local Administrators group. Thus everyone who is
|
---|
328 | logged into the domain as a member of the Domain Admins group is also granted local administrative
|
---|
329 | privileges on each domain member.
|
---|
330 | </para>
|
---|
331 |
|
---|
332 | <para>
|
---|
333 | <indexterm><primary>nested groups</primary></indexterm>
|
---|
334 | <indexterm><primary>auxiliary members</primary></indexterm>
|
---|
335 | <indexterm><primary>/etc/group</primary></indexterm>
|
---|
336 | <indexterm><primary>winbind</primary></indexterm>
|
---|
337 | UNIX/Linux has no concept of support for nested groups, and thus Samba has for a long time not supported
|
---|
338 | them either. The problem is that you would have to enter UNIX groups as auxiliary members of a group in
|
---|
339 | <filename>/etc/group</filename>. This does not work because it was not a design requirement at the time
|
---|
340 | the UNIX file system security model was implemented. Since Samba-2.2, the winbind daemon can provide
|
---|
341 | <filename>/etc/group</filename> entries on demand by obtaining user and group information from the domain
|
---|
342 | controller that the Samba server is a member of.
|
---|
343 | </para>
|
---|
344 |
|
---|
345 | <para>
|
---|
346 | <indexterm><primary>/etc/group</primary></indexterm>
|
---|
347 | <indexterm><primary>libnss_winbind</primary></indexterm>
|
---|
348 | <indexterm><primary>local groups</primary></indexterm>
|
---|
349 | <indexterm><primary>Domain Users</primary></indexterm>
|
---|
350 | <indexterm><primary>alias group</primary></indexterm>
|
---|
351 | In effect, Samba supplements the <filename>/etc/group</filename> data via the dynamic
|
---|
352 | <command>libnss_winbind</command> mechanism. Beginning with Samba-3.0.3, this facility is used to provide
|
---|
353 | local groups in the same manner as Windows. It works by expanding the local groups on the
|
---|
354 | fly as they are accessed. For example, the <constant>Domain Users</constant> group of the domain is made
|
---|
355 | a member of the local group <constant>demo</constant>. Whenever Samba needs to resolve membership of the
|
---|
356 | <constant>demo</constant> local (alias) group, winbind asks the domain controller for demo members of the Domain Users
|
---|
357 | group. By definition, it can only contain user objects, which can then be faked to be member of the
|
---|
358 | UNIX/Linux group <constant>demo</constant>.
|
---|
359 | </para>
|
---|
360 |
|
---|
361 | <para>
|
---|
362 | <indexterm><primary>nested groups</primary></indexterm>
|
---|
363 | <indexterm><primary>winbindd</primary></indexterm>
|
---|
364 | <indexterm><primary>NSS</primary></indexterm>
|
---|
365 | <indexterm><primary>winbind</primary></indexterm>
|
---|
366 | <indexterm><primary>local groups</primary></indexterm>
|
---|
367 | <indexterm><primary>Domain User Manager</primary></indexterm>
|
---|
368 | <indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>group</tertiary></indexterm>
|
---|
369 | To enable the use of nested groups, <command>winbindd</command> must be used with NSS winbind.
|
---|
370 | Creation and administration of the local groups is done best via the Windows Domain User Manager or its
|
---|
371 | Samba equivalent, the utility <command>net rpc group</command>. Creating the local group
|
---|
372 | <constant>demo</constant> is achieved by executing:
|
---|
373 | <screen>
|
---|
374 | &rootprompt; net rpc group add demo -L -Uroot%not24get
|
---|
375 | </screen>
|
---|
376 | <indexterm><primary>addmem</primary></indexterm>
|
---|
377 | <indexterm><primary>delmem</primary></indexterm>
|
---|
378 | Here the -L switch means that you want to create a local group. It may be necessary to add -S and -U
|
---|
379 | switches for accessing the correct host with appropriate user or root privileges. Adding and removing
|
---|
380 | group members can be done via the <constant>addmem</constant> and <constant>delmem</constant> subcommands of
|
---|
381 | <command>net rpc group</command> command. For example, addition of <quote>DOM\Domain Users</quote> to the
|
---|
382 | local group <constant>demo</constant> is done by executing:
|
---|
383 | <screen>
|
---|
384 | net rpc group addmem demo "DOM\Domain Users"
|
---|
385 | </screen>
|
---|
386 | <indexterm><primary>getent group demo</primary></indexterm>
|
---|
387 | <indexterm><primary>trusted domain</primary></indexterm>
|
---|
388 | <indexterm><primary>foreign domain</primary></indexterm>
|
---|
389 | <indexterm><primary>local access permissions</primary></indexterm>
|
---|
390 | Having completed these two steps, the execution of <command>getent group demo</command> will show demo
|
---|
391 | members of the global <constant>Domain Users</constant> group as members of the group
|
---|
392 | <constant>demo</constant>. This also works with any local or domain user. In case the domain DOM trusts
|
---|
393 | another domain, it is also possible to add global users and groups of the trusted domain as members of
|
---|
394 | <constant>demo</constant>. The users from the foreign domain who are members of the group that has been
|
---|
395 | added to the <constant>demo</constant> group now have the same local access permissions as local domain
|
---|
396 | users have.
|
---|
397 | </para>
|
---|
398 |
|
---|
399 | </sect2>
|
---|
400 |
|
---|
401 | <sect2>
|
---|
402 | <title>Important Administrative Information</title>
|
---|
403 |
|
---|
404 | <para>
|
---|
405 | Administrative rights are necessary in two specific forms:
|
---|
406 | </para>
|
---|
407 |
|
---|
408 | <orderedlist>
|
---|
409 | <listitem><para>For Samba-3 domain controllers and domain member servers/clients.</para></listitem>
|
---|
410 | <listitem><para>To manage domain member Windows workstations.</para></listitem>
|
---|
411 | </orderedlist>
|
---|
412 |
|
---|
413 | <para>
|
---|
414 | <indexterm><primary>rights and privileges</primary></indexterm>
|
---|
415 | <indexterm><primary>domain member client</primary></indexterm>
|
---|
416 | <indexterm><primary>group account</primary></indexterm>
|
---|
417 | Versions of Samba up to and including 3.0.10 do not provide a means for assigning rights and privileges
|
---|
418 | that are necessary for system administration tasks from a Windows domain member client machine, so
|
---|
419 | domain administration tasks such as adding, deleting, and changing user and group account information, and
|
---|
420 | managing workstation domain membership accounts, can be handled by any account other than root.
|
---|
421 | </para>
|
---|
422 |
|
---|
423 | <para>
|
---|
424 | <indexterm><primary>privilege management</primary></indexterm>
|
---|
425 | <indexterm><primary>delegated</primary></indexterm>
|
---|
426 | <indexterm><primary>Administrator</primary></indexterm>
|
---|
427 | Samba-3.0.11 introduced a new privilege management interface (see <link linkend="rights">User Rights and Privileges</link>)
|
---|
428 | that permits these tasks to be delegated to non-root (i.e., accounts other than the equivalent of the
|
---|
429 | MS Windows Administrator) accounts.
|
---|
430 | </para>
|
---|
431 |
|
---|
432 | <para>
|
---|
433 | <indexterm><primary>mapped</primary></indexterm>
|
---|
434 | <indexterm><primary>Domain Admins</primary></indexterm>
|
---|
435 | Administrative tasks on a Windows domain member workstation can be done by anyone who is a member of the
|
---|
436 | <constant>Domain Admins</constant> group. This group can be mapped to any convenient UNIX group.
|
---|
437 | </para>
|
---|
438 |
|
---|
439 | <sect3>
|
---|
440 | <title>Applicable Only to Versions Earlier than 3.0.11</title>
|
---|
441 |
|
---|
442 | <para>
|
---|
443 | <indexterm><primary>privilege</primary></indexterm>
|
---|
444 | Administrative tasks on UNIX/Linux systems, such as adding users or groups, requires
|
---|
445 | <constant>root</constant>-level privilege. The addition of a Windows client to a Samba domain involves the
|
---|
446 | addition of a user account for the Windows client.
|
---|
447 | </para>
|
---|
448 |
|
---|
449 | <para>
|
---|
450 | <indexterm><primary>system security</primary></indexterm>
|
---|
451 | <indexterm><primary>privileges</primary></indexterm>
|
---|
452 | Many UNIX administrators continue to request that the Samba Team make it possible to add Windows workstations, or
|
---|
453 | the ability to add, delete, or modify user accounts, without requiring <constant>root</constant> privileges.
|
---|
454 | Such a request violates every understanding of basic UNIX system security.
|
---|
455 | </para>
|
---|
456 |
|
---|
457 | <para>
|
---|
458 | <indexterm><primary>privileges</primary></indexterm>
|
---|
459 | <indexterm><primary>/etc/passwd</primary></indexterm>
|
---|
460 | <indexterm><primary>Domain Server Manager</primary></indexterm>
|
---|
461 | <indexterm><primary>Domain User Manager</primary></indexterm>
|
---|
462 | <indexterm><primary>manage share-level ACL</primary></indexterm>
|
---|
463 | <indexterm><primary>share-level ACLs</primary></indexterm>
|
---|
464 | There is no safe way to provide access on a UNIX/Linux system without providing
|
---|
465 | <constant>root</constant>-level privileges. Provision of <constant>root</constant> privileges can be done
|
---|
466 | either by logging on to the Domain as the user <constant>root</constant> or by permitting particular users to
|
---|
467 | use a UNIX account that has a UID=0 in the <filename>/etc/passwd</filename> database. Users of such accounts
|
---|
468 | can use tools like the NT4 Domain User Manager and the NT4 Domain Server Manager to manage user and group
|
---|
469 | accounts as well as domain member server and client accounts. This level of privilege is also needed to manage
|
---|
470 | share-level ACLs.
|
---|
471 | </para>
|
---|
472 |
|
---|
473 | </sect3>
|
---|
474 |
|
---|
475 | </sect2>
|
---|
476 |
|
---|
477 | <sect2>
|
---|
478 | <title>Default Users, Groups, and Relative Identifiers</title>
|
---|
479 |
|
---|
480 | <para>
|
---|
481 | <indexterm><primary>Relative Identifier</primary><see>RID</see></indexterm>
|
---|
482 | <indexterm><primary>RID</primary></indexterm>
|
---|
483 | <indexterm><primary>Windows NT4/200x/XP</primary></indexterm>
|
---|
484 | <indexterm><primary>well-known RID</primary></indexterm>
|
---|
485 | <indexterm><primary>domain groups</primary></indexterm>
|
---|
486 | <indexterm><primary>tdbsam</primary></indexterm>
|
---|
487 | <indexterm><primary>LDAP</primary></indexterm>
|
---|
488 | <indexterm><primary>NT groups</primary></indexterm>
|
---|
489 | When first installed, Windows NT4/200x/XP are preconfigured with certain user, group, and
|
---|
490 | alias entities. Each has a well-known RID. These must be preserved for continued
|
---|
491 | integrity of operation. Samba must be provisioned with certain essential domain groups that require
|
---|
492 | the appropriate RID value. When Samba-3 is configured to use <constant>tdbsam</constant>, the essential
|
---|
493 | domain groups are automatically created. It is the LDAP administrator's responsibility to create
|
---|
494 | (provision) the default NT groups.
|
---|
495 | </para>
|
---|
496 |
|
---|
497 | <para>
|
---|
498 | <indexterm><primary>default users</primary></indexterm>
|
---|
499 | <indexterm><primary>default groups</primary></indexterm>
|
---|
500 | <indexterm><primary>default aliases</primary></indexterm>
|
---|
501 | <indexterm><primary>RID</primary></indexterm>
|
---|
502 | Each essential domain group must be assigned its respective well-known RID. The default users, groups,
|
---|
503 | aliases, and RIDs are shown in <link linkend="WKURIDS">Well-Known User Default RIDs</link>.
|
---|
504 | </para>
|
---|
505 |
|
---|
506 | <note><para>
|
---|
507 | <indexterm><primary>passdb backend</primary></indexterm>
|
---|
508 | <indexterm><primary>LDAP</primary></indexterm>
|
---|
509 | <indexterm><primary>ldapsam</primary></indexterm>
|
---|
510 | <indexterm><primary>domain groups</primary></indexterm>
|
---|
511 | <indexterm><primary>RID</primary></indexterm>
|
---|
512 | It is the administrator's responsibility to create the essential domain groups and to assign each
|
---|
513 | its default RID.
|
---|
514 | </para></note>
|
---|
515 |
|
---|
516 | <para>
|
---|
517 | <indexterm><primary>domain groups</primary></indexterm>
|
---|
518 | <indexterm><primary>RID</primary></indexterm>
|
---|
519 | It is permissible to create any domain group that may be necessary; just make certain that the essential
|
---|
520 | domain groups (well known) have been created and assigned their default RIDs. Other groups you create may
|
---|
521 | be assigned any arbitrary RID you care to use.
|
---|
522 | </para>
|
---|
523 |
|
---|
524 | <para>
|
---|
525 | Be sure to map each domain group to a UNIX system group. That is the only way to ensure that the group
|
---|
526 | will be available for use as an NT domain group.
|
---|
527 | </para>
|
---|
528 |
|
---|
529 | <para>
|
---|
530 | <table frame="all" id="WKURIDS">
|
---|
531 | <title>Well-Known User Default RIDs</title>
|
---|
532 | <tgroup cols="4" align="left">
|
---|
533 | <colspec align="left"/>
|
---|
534 | <colspec align="left"/>
|
---|
535 | <colspec align="left"/>
|
---|
536 | <colspec align="center"/>
|
---|
537 | <thead>
|
---|
538 | <row>
|
---|
539 | <entry>Well-Known Entity</entry>
|
---|
540 | <entry>RID</entry>
|
---|
541 | <entry>Type</entry>
|
---|
542 | <entry>Essential</entry>
|
---|
543 | </row>
|
---|
544 | </thead>
|
---|
545 | <tbody>
|
---|
546 | <row>
|
---|
547 | <entry>Domain Administrator</entry>
|
---|
548 | <entry>500</entry>
|
---|
549 | <entry>User</entry>
|
---|
550 | <entry>No</entry>
|
---|
551 | </row>
|
---|
552 | <row>
|
---|
553 | <entry>Domain Guest</entry>
|
---|
554 | <entry>501</entry>
|
---|
555 | <entry>User</entry>
|
---|
556 | <entry>No</entry>
|
---|
557 | </row>
|
---|
558 | <row>
|
---|
559 | <entry>Domain KRBTGT</entry>
|
---|
560 | <entry>502</entry>
|
---|
561 | <entry>User</entry>
|
---|
562 | <entry>No</entry>
|
---|
563 | </row>
|
---|
564 | <row>
|
---|
565 | <entry>Domain Admins</entry>
|
---|
566 | <entry>512</entry>
|
---|
567 | <entry>Group</entry>
|
---|
568 | <entry>Yes</entry>
|
---|
569 | </row>
|
---|
570 | <row>
|
---|
571 | <entry>Domain Users</entry>
|
---|
572 | <entry>513</entry>
|
---|
573 | <entry>Group</entry>
|
---|
574 | <entry>Yes</entry>
|
---|
575 | </row>
|
---|
576 | <row>
|
---|
577 | <entry>Domain Guests</entry>
|
---|
578 | <entry>514</entry>
|
---|
579 | <entry>Group</entry>
|
---|
580 | <entry>Yes</entry>
|
---|
581 | </row>
|
---|
582 | <row>
|
---|
583 | <entry>Domain Computers</entry>
|
---|
584 | <entry>515</entry>
|
---|
585 | <entry>Group</entry>
|
---|
586 | <entry>No</entry>
|
---|
587 | </row>
|
---|
588 | <row>
|
---|
589 | <entry>Domain Controllers</entry>
|
---|
590 | <entry>516</entry>
|
---|
591 | <entry>Group</entry>
|
---|
592 | <entry>No</entry>
|
---|
593 | </row>
|
---|
594 | <row>
|
---|
595 | <entry>Domain Certificate Admins</entry>
|
---|
596 | <entry>517</entry>
|
---|
597 | <entry>Group</entry>
|
---|
598 | <entry>No</entry>
|
---|
599 | </row>
|
---|
600 | <row>
|
---|
601 | <entry>Domain Schema Admins</entry>
|
---|
602 | <entry>518</entry>
|
---|
603 | <entry>Group</entry>
|
---|
604 | <entry>No</entry>
|
---|
605 | </row>
|
---|
606 | <row>
|
---|
607 | <entry>Domain Enterprise Admins</entry>
|
---|
608 | <entry>519</entry>
|
---|
609 | <entry>Group</entry>
|
---|
610 | <entry>No</entry>
|
---|
611 | </row>
|
---|
612 | <row>
|
---|
613 | <entry>Domain Policy Admins</entry>
|
---|
614 | <entry>520</entry>
|
---|
615 | <entry>Group</entry>
|
---|
616 | <entry>No</entry>
|
---|
617 | </row>
|
---|
618 | <row>
|
---|
619 | <entry>Builtin Admins</entry>
|
---|
620 | <entry>544</entry>
|
---|
621 | <entry>Alias</entry>
|
---|
622 | <entry>No</entry>
|
---|
623 | </row>
|
---|
624 | <row>
|
---|
625 | <entry>Builtin users</entry>
|
---|
626 | <entry>545</entry>
|
---|
627 | <entry>Alias</entry>
|
---|
628 | <entry>No</entry>
|
---|
629 | </row>
|
---|
630 | <row>
|
---|
631 | <entry>Builtin Guests</entry>
|
---|
632 | <entry>546</entry>
|
---|
633 | <entry>Alias</entry>
|
---|
634 | <entry>No</entry>
|
---|
635 | </row>
|
---|
636 | <row>
|
---|
637 | <entry>Builtin Power Users</entry>
|
---|
638 | <entry>547</entry>
|
---|
639 | <entry>Alias</entry>
|
---|
640 | <entry>No</entry>
|
---|
641 | </row>
|
---|
642 | <row>
|
---|
643 | <entry>Builtin Account Operators</entry>
|
---|
644 | <entry>548</entry>
|
---|
645 | <entry>Alias</entry>
|
---|
646 | <entry>No</entry>
|
---|
647 | </row>
|
---|
648 | <row>
|
---|
649 | <entry>Builtin System Operators</entry>
|
---|
650 | <entry>549</entry>
|
---|
651 | <entry>Alias</entry>
|
---|
652 | <entry>No</entry>
|
---|
653 | </row>
|
---|
654 | <row>
|
---|
655 | <entry>Builtin Print Operators</entry>
|
---|
656 | <entry>550</entry>
|
---|
657 | <entry>Alias</entry>
|
---|
658 | <entry>No</entry>
|
---|
659 | </row>
|
---|
660 | <row>
|
---|
661 | <entry>Builtin Backup Operators</entry>
|
---|
662 | <entry>551</entry>
|
---|
663 | <entry>Alias</entry>
|
---|
664 | <entry>No</entry>
|
---|
665 | </row>
|
---|
666 | <row>
|
---|
667 | <entry>Builtin Replicator</entry>
|
---|
668 | <entry>552</entry>
|
---|
669 | <entry>Alias</entry>
|
---|
670 | <entry>No</entry>
|
---|
671 | </row>
|
---|
672 | <row>
|
---|
673 | <entry>Builtin RAS Servers</entry>
|
---|
674 | <entry>553</entry>
|
---|
675 | <entry>Alias</entry>
|
---|
676 | <entry>No</entry>
|
---|
677 | </row>
|
---|
678 | </tbody>
|
---|
679 | </tgroup>
|
---|
680 | </table>
|
---|
681 | </para>
|
---|
682 |
|
---|
683 | </sect2>
|
---|
684 |
|
---|
685 | <sect2>
|
---|
686 | <title>Example Configuration</title>
|
---|
687 |
|
---|
688 | <para>
|
---|
689 | <indexterm><primary>net</primary><secondary>groupmap</secondary><tertiary>list</tertiary></indexterm>
|
---|
690 | You can list the various groups in the mapping database by executing
|
---|
691 | <command>net groupmap list</command>. Here is an example:
|
---|
692 | </para>
|
---|
693 |
|
---|
694 | <para>
|
---|
695 | <indexterm><primary>net</primary><secondary>groupmap</secondary></indexterm>
|
---|
696 | <screen>
|
---|
697 | &rootprompt; <userinput>net groupmap list</userinput>
|
---|
698 | Domain Admins (S-1-5-21-2547222302-1596225915-2414751004-512) -> domadmin
|
---|
699 | Domain Users (S-1-5-21-2547222302-1596225915-2414751004-513) -> domuser
|
---|
700 | Domain Guests (S-1-5-21-2547222302-1596225915-2414751004-514) -> domguest
|
---|
701 | </screen>
|
---|
702 | </para>
|
---|
703 |
|
---|
704 | <para>
|
---|
705 | For complete details on <command>net groupmap</command>, refer to the net(8) man page.
|
---|
706 | </para>
|
---|
707 |
|
---|
708 | </sect2>
|
---|
709 |
|
---|
710 | </sect1>
|
---|
711 |
|
---|
712 | <sect1>
|
---|
713 | <title>Configuration Scripts</title>
|
---|
714 |
|
---|
715 | <para>
|
---|
716 | Everyone needs tools. Some of us like to create our own, others prefer to use canned tools
|
---|
717 | (i.e., prepared by someone else for general use).
|
---|
718 | </para>
|
---|
719 |
|
---|
720 | <sect2>
|
---|
721 | <title>Sample &smb.conf; Add Group Script</title>
|
---|
722 |
|
---|
723 | <para>
|
---|
724 | <indexterm><primary>smbgrpadd.sh</primary></indexterm>
|
---|
725 | <indexterm><primary>groupadd limitations</primary></indexterm>
|
---|
726 | <indexterm><primary>smbgrpadd.sh</primary></indexterm>
|
---|
727 | <indexterm><primary>/etc/group</primary></indexterm>
|
---|
728 | <indexterm><primary>groupadd</primary></indexterm>
|
---|
729 | A script to create complying group names for use by the Samba group interfaces
|
---|
730 | is provided in <link linkend="smbgrpadd.sh">smbgrpadd.sh</link>. This script
|
---|
731 | adds a temporary entry in the <filename>/etc/group</filename> file and then renames
|
---|
732 | it to the desired name. This is an example of a method to get around operating
|
---|
733 | system maintenance tool limitations such as those present in some version of the
|
---|
734 | <command>groupadd</command> tool.
|
---|
735 | <example id="smbgrpadd.sh">
|
---|
736 | <title>smbgrpadd.sh</title>
|
---|
737 | <programlisting>
|
---|
738 | #!/bin/bash
|
---|
739 |
|
---|
740 | # Add the group using normal system groupadd tool.
|
---|
741 | groupadd smbtmpgrp00
|
---|
742 |
|
---|
743 | thegid=`cat /etc/group | grep ^smbtmpgrp00 | cut -d ":" -f3`
|
---|
744 |
|
---|
745 | # Now change the name to what we want for the MS Windows networking end
|
---|
746 | cp /etc/group /etc/group.bak
|
---|
747 | cat /etc/group.bak | sed "s/^smbtmpgrp00/$1/g" > /etc/group
|
---|
748 | rm /etc/group.bak
|
---|
749 |
|
---|
750 | # Now return the GID as would normally happen.
|
---|
751 | echo $thegid
|
---|
752 | exit 0
|
---|
753 | </programlisting>
|
---|
754 | </example>
|
---|
755 | </para>
|
---|
756 |
|
---|
757 | <para>
|
---|
758 | The &smb.conf; entry for the above script shown in <link linkend="smbgrpadd">the configuration of
|
---|
759 | &smb.conf; for the add group Script</link> demonstrates how it may be used.
|
---|
760 |
|
---|
761 | <example id="smbgrpadd">
|
---|
762 | <title>Configuration of &smb.conf; for the add group Script</title>
|
---|
763 | <smbconfblock>
|
---|
764 | <smbconfsection name="[global]"/>
|
---|
765 | <smbconfoption name="add group script">/path_to_tool/smbgrpadd.sh "%g"</smbconfoption>
|
---|
766 | </smbconfblock>
|
---|
767 | </example>
|
---|
768 | </para>
|
---|
769 |
|
---|
770 | </sect2>
|
---|
771 |
|
---|
772 | <sect2>
|
---|
773 | <title>Script to Configure Group Mapping</title>
|
---|
774 |
|
---|
775 | <para>
|
---|
776 | <indexterm><primary>initGroups.sh</primary></indexterm>
|
---|
777 | In our example we have created a UNIX/Linux group called <literal>ntadmin</literal>.
|
---|
778 | Our script will create the additional groups <literal>Orks</literal>, <literal>Elves</literal>, and <literal>Gnomes</literal>.
|
---|
779 | It is a good idea to save this shell script for later use just in case you ever need to rebuild your mapping database.
|
---|
780 | For the sake of convenience we elect to save this script as a file called <filename>initGroups.sh</filename>.
|
---|
781 | This script is given in <link linkend="set-group-map">intGroups.sh</link>.
|
---|
782 | <indexterm><primary>initGroups.sh</primary></indexterm>
|
---|
783 | <example id="set-group-map">
|
---|
784 | <title>Script to Set Group Mapping</title>
|
---|
785 | <programlisting>
|
---|
786 | #!/bin/bash
|
---|
787 |
|
---|
788 | net groupmap add ntgroup="Domain Admins" unixgroup=ntadmin rid=512 type=d
|
---|
789 | net groupmap add ntgroup="Domain Users" unixgroup=users rid=513 type=d
|
---|
790 | net groupmap add ntgroup="Domain Guests" unixgroup=nobody rid=514 type=d
|
---|
791 |
|
---|
792 | groupadd Orks
|
---|
793 | groupadd Elves
|
---|
794 | groupadd Gnomes
|
---|
795 |
|
---|
796 | net groupmap add ntgroup="Orks" unixgroup=Orks type=d
|
---|
797 | net groupmap add ntgroup="Elves" unixgroup=Elves type=d
|
---|
798 | net groupmap add ntgroup="Gnomes" unixgroup=Gnomes type=d
|
---|
799 | </programlisting>
|
---|
800 | </example>
|
---|
801 | </para>
|
---|
802 |
|
---|
803 | <para>
|
---|
804 | Of course it is expected that the administrator will modify this to suit local needs.
|
---|
805 | For information regarding the use of the <command>net groupmap</command> tool please
|
---|
806 | refer to the man page.
|
---|
807 | </para>
|
---|
808 |
|
---|
809 | <note><para>
|
---|
810 | Versions of Samba-3 prior to 3.0.23 automatically create default group mapping for the
|
---|
811 | <literal>Domain Admins, Domain Users</literal> and <literal>Domain Guests</literal> Windows
|
---|
812 | groups, but do not map them to UNIX GIDs. This was a cause of administrative confusion and
|
---|
813 | trouble. Commencing with Samba-3.0.23 this anomaly has been fixed - thus all Windows groups
|
---|
814 | must now be manually and explicitly created and mapped to a valid UNIX GID by the Samba
|
---|
815 | administrator.
|
---|
816 | </para></note>
|
---|
817 |
|
---|
818 | </sect2>
|
---|
819 |
|
---|
820 | </sect1>
|
---|
821 |
|
---|
822 | <sect1>
|
---|
823 | <title>Common Errors</title>
|
---|
824 |
|
---|
825 | <para>
|
---|
826 | At this time there are many little surprises for the unwary administrator. In a real sense
|
---|
827 | it is imperative that every step of automated control scripts be carefully tested
|
---|
828 | manually before putting it into active service.
|
---|
829 | </para>
|
---|
830 |
|
---|
831 | <sect2>
|
---|
832 | <title>Adding Groups Fails</title>
|
---|
833 |
|
---|
834 | <para>
|
---|
835 | <indexterm><primary>groupadd</primary></indexterm>
|
---|
836 | This is a common problem when the <command>groupadd</command> is called directly
|
---|
837 | by the Samba interface script for the <smbconfoption name="add group script"/> in
|
---|
838 | the &smb.conf; file.
|
---|
839 | </para>
|
---|
840 |
|
---|
841 | <para>
|
---|
842 | <indexterm><primary>uppercase character</primary></indexterm>
|
---|
843 | <indexterm><primary>space character</primary></indexterm>
|
---|
844 | The most common cause of failure is an attempt to add an MS Windows group account
|
---|
845 | that has an uppercase character and/or a space character in it.
|
---|
846 | </para>
|
---|
847 |
|
---|
848 | <para>
|
---|
849 | <indexterm><primary>groupadd</primary></indexterm>
|
---|
850 | There are three possible workarounds. First, use only group names that comply
|
---|
851 | with the limitations of the UNIX/Linux <command>groupadd</command> system tool.
|
---|
852 | Second, it involves the use of the script mentioned earlier in this chapter, and
|
---|
853 | third is the option is to manually create a UNIX/Linux group account that can substitute
|
---|
854 | for the MS Windows group name, then use the procedure listed above to map that group
|
---|
855 | to the MS Windows group.
|
---|
856 | </para>
|
---|
857 |
|
---|
858 | </sect2>
|
---|
859 |
|
---|
860 | <sect2>
|
---|
861 | <title>Adding Domain Users to the Workstation Power Users Group</title>
|
---|
862 |
|
---|
863 | <para><quote>
|
---|
864 | What must I do to add domain users to the Power Users group?
|
---|
865 | </quote></para>
|
---|
866 |
|
---|
867 | <para>
|
---|
868 | <indexterm><primary>Domain Users group</primary></indexterm>
|
---|
869 | The Power Users group is a group that is local to each Windows 200x/XP Professional workstation.
|
---|
870 | You cannot add the Domain Users group to the Power Users group automatically, it must be done on
|
---|
871 | each workstation by logging in as the local workstation <emphasis>administrator</emphasis> and
|
---|
872 | then using the following procedure:
|
---|
873 | </para>
|
---|
874 |
|
---|
875 | <procedure>
|
---|
876 | <step><para>
|
---|
877 | Click <guimenu>Start -> Control Panel -> Users and Passwords</guimenu>.
|
---|
878 | </para></step>
|
---|
879 |
|
---|
880 | <step><para>
|
---|
881 | Click the <guimenuitem>Advanced</guimenuitem> tab.
|
---|
882 | </para></step>
|
---|
883 |
|
---|
884 | <step><para>
|
---|
885 | Click the <guibutton>Advanced</guibutton> button.
|
---|
886 | </para></step>
|
---|
887 |
|
---|
888 | <step><para>
|
---|
889 | Click <constant>Groups</constant>.
|
---|
890 | </para></step>
|
---|
891 |
|
---|
892 | <step><para>
|
---|
893 | Double-click <constant>Power Users</constant>. This will launch the panel to add users or groups
|
---|
894 | to the local machine <constant>Power Users</constant> group.
|
---|
895 | </para></step>
|
---|
896 |
|
---|
897 | <step><para>
|
---|
898 | Click the <guibutton>Add</guibutton> button.
|
---|
899 | </para></step>
|
---|
900 |
|
---|
901 | <step><para>
|
---|
902 | Select the domain from which the <constant>Domain Users</constant> group is to be added.
|
---|
903 | </para></step>
|
---|
904 |
|
---|
905 | <step><para>
|
---|
906 | Double-click the <constant>Domain Users</constant> group.
|
---|
907 | </para></step>
|
---|
908 |
|
---|
909 | <step><para>
|
---|
910 | Click the <guibutton>OK</guibutton> button. If a logon box is presented during this process,
|
---|
911 | please remember to enter the connect as <constant>DOMAIN\UserName</constant>, that is, for the
|
---|
912 | domain <constant>MIDEARTH</constant> and the user <constant>root</constant> enter
|
---|
913 | <constant>MIDEARTH\root</constant>.
|
---|
914 | </para></step>
|
---|
915 | </procedure>
|
---|
916 | </sect2>
|
---|
917 |
|
---|
918 | </sect1>
|
---|
919 |
|
---|
920 | </chapter>
|
---|