| 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 annomaly 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> | 
|---|