~zulcss/samba/server-dailies-3.4

<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Chapter�15.�User Rights and Privileges</title><link rel="stylesheet" href="../samba.css" type="text/css"><meta name="generator" content="DocBook XSL Stylesheets V1.74.0"><link rel="home" href="index.html" title="The Official Samba 3.4.x HOWTO and Reference Guide"><link rel="up" href="optional.html" title="Part�III.�Advanced Configuration"><link rel="prev" href="idmapper.html" title="Chapter�14.�Identity Mapping (IDMAP)"><link rel="next" href="AccessControls.html" title="Chapter�16.�File, Directory, and Share Access Controls"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter�15.�User Rights and Privileges</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="idmapper.html">Prev</a>�</td><th width="60%" align="center">Part�III.�Advanced Configuration</th><td width="20%" align="right">�<a accesskey="n" href="AccessControls.html">Next</a></td></tr></table><hr></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="rights"></a>Chapter�15.�User Rights and Privileges</h2></div><div><div class="author"><h3 class="author"><span class="firstname">Gerald</span> <span class="othername">(Jerry)</span> <span class="orgname">Samba Team</span> <span class="surname">Carter</span></h3><div class="affiliation"><span class="orgname">Samba Team<br></span><div class="address"><p><code class="email"><<a class="email" href="mailto:jerry@samba.org">jerry@samba.org</a>></code></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">John</span> <span class="othername">H.</span> <span class="orgname">Samba Team</span> <span class="surname">Terpstra</span></h3><div class="affiliation"><span class="orgname">Samba Team<br></span><div class="address"><p><code class="email"><<a class="email" href="mailto:jht@samba.org">jht@samba.org</a>></code></p></div></div></div></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="rights.html#id2608437">Rights Management Capabilities</a></span></dt><dd><dl><dt><span class="sect2"><a href="rights.html#id2608712">Using the net rpc rights Utility</a></span></dt><dt><span class="sect2"><a href="rights.html#id2609058">Description of Privileges</a></span></dt><dt><span class="sect2"><a href="rights.html#id2609373">Privileges Suppored by Windows 2000 Domain Controllers</a></span></dt></dl></dd><dt><span class="sect1"><a href="rights.html#id2609884">The Administrator Domain SID</a></span></dt><dt><span class="sect1"><a href="rights.html#id2610061">Common Errors</a></span></dt><dd><dl><dt><span class="sect2"><a href="rights.html#id2610067">What Rights and Privileges Will Permit Windows Client Administration?</a></span></dt></dl></dd></dl></div><p>

The administration of Windows user, group, and machine accounts in the Samba

domain-controlled network necessitates interfacing between the MS Windows

networking environment and the UNIX operating system environment. The right

(permission) to add machines to the Windows security domain can be assigned

(set) to non-administrative users both in Windows NT4 domains and

Active Directory domains.

</p><p>

The addition of Windows NT4/2kX/XPPro machines to the domain necessitates the

creation of a machine account for each machine added. The machine account is

a necessity that is used to validate that the machine can be trusted to permit

user logons.

</p><p>

Machine accounts are analogous to user accounts, and thus in implementing them on a UNIX machine that is

hosting Samba (i.e., on which Samba is running), it is necessary to create a special type of user account.

Machine accounts differ from normal user accounts in that the account name (login ID) is terminated with a

<code class="literal">$</code> sign. An additional difference is that this type of account should not ever be able to

log into the UNIX environment as a system user and therefore is set to have a shell of

<code class="literal">/bin/false</code> and a home directory of <code class="literal">/dev/null.</code> The machine

account is used only to authenticate domain member machines during start-up. This security measure

is designed to block man-in-the-middle attempts to violate network integrity.

</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>

Machine (computer) accounts are used in the Windows NT OS family to store security

credentials for domain member servers and workstations. When the domain member

starts up, it goes through a validation process that includes an exchange of

credentials with a domain controller. If the domain member fails to authenticate

using the credentials known for it by domain controllers, the machine will be refused

all access by domain users. The computer account is essential to the way that MS

Windows secures authentication.

</p></div><p>

The creation of UNIX system accounts has traditionally been the sole right of

the system administrator, better known as the <code class="constant">root</code> account.

It is possible in the UNIX environment to create multiple users who have the

same UID. Any UNIX user who has a UID=0 is inherently the same as the

<code class="constant">root</code> account user.

</p><p>

All versions of Samba call system interface scripts that permit CIFS function

calls that are used to manage users, groups, and machine accounts

in the UNIX environment. All versions of Samba up to and including version 3.0.10

required the use of a Windows administrator account that unambiguously maps to

the UNIX <code class="constant">root</code> account to permit the execution of these

interface scripts. The requirement to do this has understandably met with some

disdain and consternation among Samba administrators, particularly where it became

necessary to permit people who should not possess <code class="constant">root</code>-level

access to the UNIX host system.

</p><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2608437"></a>Rights Management Capabilities</h2></div></div></div><p>

Samba 3.0.11 introduced support for the Windows privilege model. This model

allows certain rights to be assigned to a user or group SID. In order to enable

this feature, <a class="link" href="smb.conf.5.html#ENABLEPRIVILEGES" target="_top">enable privileges = yes</a>

must be defined in the <em class="parameter"><code>global</code></em> section of the <code class="filename">smb.conf</code> file.

</p><p>

Currently, the rights supported in Samba-3 are listed in <a class="link" href="rights.html#rp-privs" title="Table�15.1.�Current Privilege Capabilities">“Current Privilege Capabilities”</a>.

The remainder of this chapter explains how to manage and use these privileges on Samba servers.

</p><a class="indexterm" name="id2608536"></a><a class="indexterm" name="id2608543"></a><a class="indexterm" name="id2608550"></a><a class="indexterm" name="id2608557"></a><a class="indexterm" name="id2608564"></a><a class="indexterm" name="id2608571"></a><div class="table"><a name="rp-privs"></a><p class="title"><b>Table�15.1.�Current Privilege Capabilities</b></p><div class="table-contents"><table summary="Current Privilege Capabilities" border="1"><colgroup><col align="right"><col align="left"></colgroup><thead><tr><th align="left">Privilege</th><th align="left">Description</th></tr></thead><tbody><tr><td align="right"><p>SeMachineAccountPrivilege</p></td><td align="left"><p>Add machines to domain</p></td></tr><tr><td align="right"><p>SePrintOperatorPrivilege</p></td><td align="left"><p>Manage printers</p></td></tr><tr><td align="right"><p>SeAddUsersPrivilege</p></td><td align="left"><p>Add users and groups to the domain</p></td></tr><tr><td align="right"><p>SeRemoteShutdownPrivilege</p></td><td align="left"><p>Force shutdown from a remote system</p></td></tr><tr><td align="right"><p>SeDiskOperatorPrivilege</p></td><td align="left"><p>Manage disk share</p></td></tr><tr><td align="right"><p>SeTakeOwnershipPrivilege</p></td><td align="left"><p>Take ownership of files or other objects</p></td></tr></tbody></table></div></div><br class="table-break"><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2608712"></a>Using the “<span class="quote">net rpc rights</span>” Utility</h3></div></div></div><p>

There are two primary means of managing the rights assigned to users and groups

on a Samba server. The <code class="literal">NT4 User Manager for Domains</code> may be

used from any Windows NT4, 2000, or XP Professional domain member client to

connect to a Samba domain controller and view/modify the rights assignments.

This application, however, appears to have bugs when run on a client running

Windows 2000 or later; therefore, Samba provides a command-line utility for

100

performing the necessary administrative actions.

101

</p><p>

102

The <code class="literal">net rpc rights</code> utility in Samba 3.0.11 has three new subcommands:

103

</p><div class="variablelist"><dl><dt><span class="term">list [name|accounts]</span></dt><dd><p>

104

105

106

107

108

When called with no arguments, <code class="literal">net rpc list</code>

109

simply lists the available rights on the server. When passed

110

a specific user or group name, the tool lists the privileges

111

currently assigned to the specified account. When invoked using

112

the special string <code class="constant">accounts</code>,

113

<code class="literal">net rpc rights list</code> returns a list of all

114

privileged accounts on the server and the assigned rights.

115

</p></dd><dt><span class="term">grant <user> <right [right ...]></span></dt><dd><p>

116

117

118

119

120

When called with no arguments, this function is used to assign

121

a list of rights to a specified user or group. For example,

122

to grant the members of the Domain Admins group on a Samba domain controller,

123

the capability to add client machines to the domain, one would run:

124

</p><pre class="screen">

125

<code class="prompt">root# </code> net -S server -U domadmin rpc rights grant \

126

'DOMAIN\Domain Admins' SeMachineAccountPrivilege

127

</pre><p>

128

The following syntax has the same result:

129

130

</p><pre class="screen">

131

<code class="prompt">root# </code> net rpc rights grant 'DOMAIN\Domain Admins' \

132

SeMachineAccountPrivilege -S server -U domadmin

133

</pre><p>

134

More than one privilege can be assigned by specifying a

135

list of rights separated by spaces. The parameter 'Domain\Domain Admins'

136

must be quoted with single ticks or using double-quotes to prevent

137

the backslash and the space from being interpreted by the system shell.

138

</p></dd><dt><span class="term">revoke <user> <right [right ...]></span></dt><dd><p>

139

This command is similar in format to <code class="literal">net rpc rights grant</code>. Its

140

effect is to remove an assigned right (or list of rights) from a user or group.

141

</p></dd></dl></div><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>

142

143

144

145

You must be connected as a member of the Domain Admins group to be able to grant or revoke privileges assigned

146

to an account. This capability is inherent to the Domain Admins group and is not configurable. There are no

147

default rights and privileges, except the ability for a member of the Domain Admins group to assign them.

148

This means that all administrative rights and privileges (other than the ability to assign them) must be

149

explicitly assigned, even for the Domain Admins group.

150

</p></div><p>

151

152

153

154

155

By default, no privileges are initially assigned to any account because certain actions will be performed as

156

root once smbd determines that a user has the necessary rights. For example, when joining a client to a

157

Windows domain, <em class="parameter"><code>add machine script</code></em> must be executed with superuser rights in most

158

cases. For this reason, you should be very careful about handing out privileges to accounts.

159

</p><p>

160

161

162

163

Access as the root user (UID=0) bypasses all privilege checks.

164

</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2609058"></a>Description of Privileges</h3></div></div></div><p>

165

166

167

168

The privileges that have been implemented in Samba-3.0.11 are shown below. It is possible, and likely, that

169

additional privileges may be implemented in later releases of Samba. It is also likely that any privileges

170

currently implemented but not used may be removed from future releases as a housekeeping matter, so it is

171

important that the successful as well as unsuccessful use of these facilities should be reported on the Samba

172

mailing lists.

173

</p><div class="variablelist"><dl><dt><span class="term">SeAddUsersPrivilege</span></dt><dd><p>

174

175

176

177

This right determines whether or not smbd will allow the

178

user to create new user or group accounts via such tools

179

as <code class="literal">net rpc user add</code> or

180

<code class="literal">NT4 User Manager for Domains.</code>

181

</p></dd><dt><span class="term">SeDiskOperatorPrivilege</span></dt><dd><p>

182

183

184

185

Accounts that possess this right will be able to execute

186

scripts defined by the <code class="literal">add/delete/change</code>

187

share command in <code class="filename">smb.conf</code> file as root. Such users will

188

also be able to modify the ACL associated with file shares

189

on the Samba server.

190

</p></dd><dt><span class="term">SeMachineAccountPrivilege</span></dt><dd><p>

191

192

193

194

This right controls whether or not the user can join client

195

machines to a Samba-controlled domain.

196

</p></dd><dt><span class="term">SePrintOperatorPrivilege</span></dt><dd><p>

197

198

199

200

201

202

This privilege operates identically to the <a class="link" href="smb.conf.5.html#PRINTERADMIN" target="_top">printer admin</a>

203

option in the <code class="filename">smb.conf</code> file (see section 5 man page for <code class="filename">smb.conf</code>)

204

except that it is a global right (not on a per-printer basis).

205

Eventually the smb.conf option will be deprecated and administrative

206

rights to printers will be controlled exclusively by this right and

207

the security descriptor associated with the printer object in the

208

<code class="filename">ntprinters.tdb</code> file.

209

</p></dd><dt><span class="term">SeRemoteShutdownPrivilege</span></dt><dd><p>

210

211

212

213

Samba provides two hooks for shutting down or rebooting

214

the server and for aborting a previously issued shutdown

215

command. Since this is an operation normally limited by

216

the operating system to the root user, an account must possess this

217

right to be able to execute either of these hooks.

218

</p></dd><dt><span class="term">SeTakeOwnershipPrivilege</span></dt><dd><p>

219

220

221

This right permits users to take ownership of files and directories.

222

</p></dd></dl></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2609373"></a>Privileges Suppored by Windows 2000 Domain Controllers</h3></div></div></div><p>

223

For reference purposes, a Windows NT4 Primary Domain Controller reports support for the following

224

privileges:

225

226

227

228

229

230

231

232

233

234

235

236

237

238

239

240

241

242

243

244

245

246

247

248

</p><pre class="screen">

249

SeCreateTokenPrivilege Create a token object

250

SeAssignPrimaryTokenPrivilege Replace a process level token

251

SeLockMemoryPrivilege Lock pages in memory

252

SeIncreaseQuotaPrivilege Increase quotas

253

SeMachineAccountPrivilege Add workstations to domain

254

SeTcbPrivilege Act as part of the operating system

255

SeSecurityPrivilege Manage auditing and security log

256

SeTakeOwnershipPrivilege Take ownership of files or other objects

257

SeLoadDriverPrivilege Load and unload device drivers

258

SeSystemProfilePrivilege Profile system performance

259

SeSystemtimePrivilege Change the system time

260

SeProfileSingleProcessPrivilege Profile single process

261

SeIncreaseBasePriorityPrivilege Increase scheduling priority

262

SeCreatePagefilePrivilege Create a pagefile

263

SeCreatePermanentPrivilege Create permanent shared objects

264

SeBackupPrivilege Back up files and directories

265

SeRestorePrivilege Restore files and directories

266

SeShutdownPrivilege Shut down the system

267

SeDebugPrivilege Debug programs

268

SeAuditPrivilege Generate security audits

269

SeSystemEnvironmentPrivilege Modify firmware environment values

270

SeChangeNotifyPrivilege Bypass traverse checking

271

SeRemoteShutdownPrivilege Force shutdown from a remote system

272

</pre><p>

273

And Windows 200x/XP Domain Controllers and workstations reports to support the following privileges:

274

275

276

277

278

279

280

281

282

283

284

285

286

287

288

289

290

291

292

293

294

295

296

297

298

299

300

301

302

303

</p><pre class="screen">

304

SeCreateTokenPrivilege Create a token object

305

SeAssignPrimaryTokenPrivilege Replace a process level token

306

SeLockMemoryPrivilege Lock pages in memory

307

SeIncreaseQuotaPrivilege Increase quotas

308

SeMachineAccountPrivilege Add workstations to domain

309

SeTcbPrivilege Act as part of the operating system

310

SeSecurityPrivilege Manage auditing and security log

311

SeTakeOwnershipPrivilege Take ownership of files or other objects

312

SeLoadDriverPrivilege Load and unload device drivers

313

SeSystemProfilePrivilege Profile system performance

314

SeSystemtimePrivilege Change the system time

315

SeProfileSingleProcessPrivilege Profile single process

316

SeIncreaseBasePriorityPrivilege Increase scheduling priority

317

SeCreatePagefilePrivilege Create a pagefile

318

SeCreatePermanentPrivilege Create permanent shared objects

319

SeBackupPrivilege Back up files and directories

320

SeRestorePrivilege Restore files and directories

321

SeShutdownPrivilege Shut down the system

322

SeDebugPrivilege Debug programs

323

SeAuditPrivilege Generate security audits

324

SeSystemEnvironmentPrivilege Modify firmware environment values

325

SeChangeNotifyPrivilege Bypass traverse checking

326

SeRemoteShutdownPrivilege Force shutdown from a remote system

327

SeUndockPrivilege Remove computer from docking station

328

SeSyncAgentPrivilege Synchronize directory service data

329

SeEnableDelegationPrivilege Enable computer and user accounts to

330

be trusted for delegation

331

SeManageVolumePrivilege Perform volume maintenance tasks

332

SeImpersonatePrivilege Impersonate a client after authentication

333

SeCreateGlobalPrivilege Create global objects

334

</pre><p>

335

336

The Samba Team is implementing only those privileges that are logical and useful in the UNIX/Linux

337

environment. Many of the Windows 200X/XP privileges have no direct equivalence in UNIX.

338

</p></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2609884"></a>The Administrator Domain SID</h2></div></div></div><p>

339

340

341

342

343

344

Please note that every Windows NT4 and later server requires a domain Administrator account. Samba versions

345

commencing with 3.0.11 permit Administrative duties to be performed via assigned rights and privileges

346

(see <a class="link" href="rights.html" title="Chapter�15.�User Rights and Privileges">User Rights and Privileges</a>). An account in the server's passdb backend can

347

be set to the well-known RID of the default administrator account. To obtain the domain SID on a Samba domain

348

controller, run the following command:

349

</p><pre class="screen">

350

<code class="prompt">root# </code> net getlocalsid

351

SID for domain FOO is: S-1-5-21-4294955119-3368514841-2087710299

352

</pre><p>

353

354

You may assign the domain administrator RID to an account using the <code class="literal">pdbedit</code>

355

command as shown here:

356

357

</p><pre class="screen">

358

<code class="prompt">root# </code> pdbedit -U S-1-5-21-4294955119-3368514841-2087710299-500 -u root -r

359

</pre><p>

360

</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>

361

362

363

364

365

The RID 500 is the well known standard value of the default Administrator account. It is the RID

366

that confers the rights and privileges that the Administrator account has on a Windows machine

367

or domain. Under UNIX/Linux the equivalent is UID=0 (the root account).

368

</p></div><p>

369

370

371

372

373

Releases of Samba version 3.0.11 and later make it possible to operate without an Administrator account

374

provided equivalent rights and privileges have been established for a Windows user or a Windows

375

group account.

376

</p></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2610061"></a>Common Errors</h2></div></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2610067"></a>What Rights and Privileges Will Permit Windows Client Administration?</h3></div></div></div><p>

377

378

379

380

381

When a Windows NT4 (or later) client joins a domain, the domain global <code class="literal">Domain Admins</code> group

382

is added to the membership of the local <code class="literal">Administrators</code> group on the client. Any user who is

383

a member of the domain global <code class="literal">Domain Admins</code> group will have administrative rights on the

384

Windows client.

385

</p><p>

386

387

388

389

390

391

This is often not the most desirable solution because it means that the user will have administrative

392

rights and privileges on domain servers also. The <code class="literal">Power Users</code> group on Windows client

393

workstations permits local administration of the workstation alone. Any domain global user or domain global

394

group can be added to the membership of the local workstation group <code class="literal">Power Users</code>.

395

</p><p>

396

397

398

399

400

See <a class="link" href="NetCommand.html#nestedgrpmgmgt" title="Nested Group Support">Nested Group Support</a> for an example of how to add domain users

401

and groups to a local group that is on a Windows workstation. The use of the <code class="literal">net</code>

402

command permits this to be done from the Samba server.

403

</p><p>

404

405

406

407

Another way this can be done is to log onto the Windows workstation as the user

408

<code class="literal">Administrator</code>, then open a <code class="literal">cmd</code> shell, then execute:

409

</p><pre class="screen">

410

<code class="prompt">C:\> </code> net localgroup administrators /add <strong class="userinput"><code>domain_name\entity</code></strong>

411

</pre><p>

412

where <code class="literal">entity</code> is either a domain user or a domain group account name.

413

</p></div></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="idmapper.html">Prev</a>�</td><td width="20%" align="center"><a accesskey="u" href="optional.html">Up</a></td><td width="40%" align="right">�<a accesskey="n" href="AccessControls.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter�14.�Identity Mapping (IDMAP)�</td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top">�Chapter�16.�File, Directory, and Share Access Controls</td></tr></table></div></body></html>