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="kerberos"> 4 <title>Active Directory, Kerberos, and Security</title> 5 6 <para><indexterm> 7 <primary>experiment</primary> 8 </indexterm> 9 By this point in the book, you have been exposed to many Samba-3 features and capabilities. 10 More importantly, if you have implemented the examples given, you are well on your way to becoming 11 a Samba-3 networking guru who knows a lot about Microsoft Windows. If you have taken the time to 12 practice, you likely have thought of improvements and scenarios with which you can experiment. You 13 are rather well plugged in to the many flexible ways Samba can be used. 14 </para> 15 16 <para><indexterm> 17 <primary>criticism</primary> 18 </indexterm> 19 This is a book about Samba-3. Understandably, its intent is to present it in a positive light. 20 The casual observer might conclude that this book is one-eyed about Samba. It is &smbmdash; what 21 would you expect? This chapter exposes some criticisms that have been raised concerning 22 the use of Samba. For each criticism, there are good answers and appropriate solutions. 23 </para> 24 25 <para> 26 Some criticism always comes from deep inside ranks that one would expect to be supportive of a particular 27 decision. Criticism can be expected from the outside. Let's see how the interesting dynamic of 28 criticism develops with respect to Abmas. 29 </para> 30 31 <para><indexterm> 32 <primary>straw-man</primary> 33 </indexterm> 34 This chapter provides a shameless self-promotion of Samba-3. The objections raised were not pulled 35 out of thin air. They were drawn from comments made by Samba users and from criticism during 36 discussions with Windows network administrators. The tone of the objections reflects as closely 37 as possible that of the original. The case presented is a straw-man example that is designed to 38 permit each objection to be answered as it might occur in real life. 39 </para> 40 41<sect1> 42 <title>Introduction</title> 43 44 <para><indexterm> 45 <primary>acquisitions</primary> 46 </indexterm><indexterm> 47 <primary>risk</primary> 48 </indexterm><indexterm> 49 <primary>assessment</primary> 50 </indexterm><indexterm> 51 <primary>Active Directory</primary> 52 </indexterm><indexterm> 53 <primary>Windows 2003 Serve</primary> 54 </indexterm> 55 Abmas is continuing its meteoric growth with yet further acquisitions. The investment community took 56 note of the spectacular projection of Abmas onto the global business stage. Abmas is building an 57 interesting portfolio of companies that includes accounting services, financial advice, investment 58 portfolio management, property insurance, risk assessment, and the recent addition of a a video rental 59 business. The pieces do not always appear to fit together, but Mr. Meany is certainly executing an 60 interesting business growth and development plan. Abmas Video Rentals was recently acquired. 61 During the time that the acquisition was closing, the Video Rentals business upgraded its Windows 62 NT4-based network to Windows 2003 Server and Active Directory. 63 </para> 64 65 <para><indexterm> 66 <primary>Active Directory</primary> 67 </indexterm> 68 You have accepted the fact that Abmas Video Rentals will use Microsoft Active Directory. 69 The IT team, led by Stan Soroka, is committed to Samba-3 and to maintaining a uniform technology platform. 70 Stan Soroka's team voiced its disapproval over the decision to permit this business to continue to 71 operate with a solution that is viewed by Christine and her group as <quote>an island of broken 72 technologies.</quote> This comment was made by one of Christine's staff as they were installing a new 73 Samba-3 server at the new business. 74 </para> 75 76 77 <para><indexterm> 78 <primary>consultant</primary> 79 </indexterm><indexterm> 80 <primary>hypothetical</primary> 81 </indexterm> 82 Abmas Video Rentals' head of IT heard of this criticism. He was offended that a junior engineer 83 should make such a comment. He felt that he had to prepare in case he might be criticized for his 84 decision to use Active Directory. He decided he would defend his decision by hiring the services 85 of an outside security systems consultant to report<footnote><para>This report is entirely fictitious. 86 Any resemblance to a factual report is purely coincidental.</para></footnote> on his unit's operations 87 and to investigate the role of Samba at his site. Here are key extracts from this hypothetical 88 report: 89 </para> 90 91 <blockquote><para><indexterm> 92 <primary>vulnerabilities</primary> 93 </indexterm><indexterm> 94 <primary>integrity</primary> 95 </indexterm><indexterm> 96 <primary>practices</primary> 97 </indexterm><indexterm> 98 <primary>Active Directory</primary> 99 </indexterm> 100 ... the implementation of Microsoft Active Directory at the Abmas Video Rentals, Bamingsham site, 101 has been examined. We find no evidence to support a notion that vulnerabilities exist at your site. 102 ... we took additional steps to validate the integrity of the installation and operation of Active 103 Directory and are pleased that your staff are following sound practices. 104 </para> 105 106 <para> 107 ... 108 </para> 109 110 <para><indexterm> 111 <primary>accounts</primary> 112 <secondary>user</secondary> 113 </indexterm><indexterm> 114 <primary>accounts</primary> 115 <secondary>group</secondary> 116 </indexterm><indexterm> 117 <primary>Backup</primary> 118 </indexterm><indexterm> 119 <primary>disaster recovery</primary> 120 </indexterm><indexterm> 121 <primary>validated</primary> 122 </indexterm><indexterm> 123 <primary>off-site storage</primary> 124 </indexterm> 125 User and group accounts, and respective privileges, have been well thought out. File system shares are 126 appropriately secured. Backup and disaster recovery plans are well managed and validated regularly, and 127 effective off-site storage practices are considered to exceed industry norms. 128 </para> 129 130 <para><indexterm> 131 <primary>compromise</primary> 132 </indexterm><indexterm> 133 <primary>secure</primary> 134 </indexterm><indexterm> 135 <primary>network</primary> 136 <secondary>secure</secondary> 137 </indexterm> 138 Your staff are justifiably concerned that the use of Samba may compromise their good efforts to maintain 139 a secure network. 140 </para> 141 142 <para><indexterm> 143 <primary>winbind</primary> 144 </indexterm><indexterm> 145 <primary>security</primary> 146 </indexterm><indexterm> 147 <primary>secure</primary> 148 </indexterm><indexterm> 149 <primary>network</primary> 150 <secondary>management</secondary> 151 </indexterm> 152 The recently installed Linux file and application server uses a tool called <command>winbind</command> 153 that is indiscriminate about security. All user accounts in Active Directory can be used to access data 154 stored on the Linux system. We are alarmed that secure information is accessible to staff who should 155 not even be aware that it exists. We share the concerns of your network management staff who have gone 156 to great lengths to set fine-grained controls that limit information access to those who need access. 157 It seems incongruous to us that Samba winbind should be permitted to be used considering that it voids this fine work. 158 </para> 159 160 <para><indexterm> 161 <primary>isolated</primary> 162 </indexterm><indexterm> 163 <primary>firewall</primary> 164 </indexterm><indexterm> 165 <primary>best practices</primary> 166 </indexterm> 167 Graham Judd [head of network administration] has locked down the security of all systems and is following 168 the latest Microsoft guidelines. ... null session connections have been disabled ... the internal network 169 is isolated from the outside world, the [product name removed] firewall is under current contract 170 maintenance support from [the manufacturer]. ... our attempts to penetrate security of your systems 171 failed to find problems common to Windows networking sites. We commend your staff on their attention to 172 detail and for following Microsoft recommended best practices. 173 </para> 174 175 <para> 176 ... 177 </para> 178 179 <para><indexterm> 180 <primary>security</primary> 181 </indexterm><indexterm> 182 <primary>disable</primary> 183 </indexterm><indexterm> 184 <primary>essential</primary> 185 </indexterm><indexterm> 186 <primary>trusted computing</primary> 187 </indexterm> 188 Regarding the use of Samba, we offer the following comments: Samba is in use in nearly half of 189 all sites we have surveyed. ... It is our opinion that Samba offers no better security than Microsoft 190 ... what worries us regarding Samba is the need to disable essential Windows security features such as 191 secure channel support, digital sign'n'seal on all communication traffic, and running Active Directory in 192 mixed mode so that Samba clients and servers can authenticate all of it. Additionally, we are concerned that 193 Samba is not at the full capabilities of Microsoft Windows NT4 server. Microsoft has moved well beyond that 194 with trusted computing initiatives that the Samba developers do not participate in. 195 </para> 196 197 <para><indexterm> 198 <primary>integrity</primary> 199 </indexterm><indexterm> 200 <primary>hackers</primary> 201 </indexterm><indexterm> 202 <primary>accountable</primary> 203 </indexterm><indexterm> 204 <primary>flaws</primary> 205 </indexterm><indexterm> 206 <primary>updates</primary> 207 </indexterm><indexterm> 208 <primary>bug fixes</primary> 209 </indexterm><indexterm> 210 <primary>alarm</primary> 211 </indexterm> 212 One wonders about the integrity of an open source program that is developed by a team of hackers 213 who cannot be held accountable for the flaws in their code. The sheer number of updates and bug 214 fixes they have released should ring alarm bells in any business. 215 </para> 216 217 <para><indexterm> 218 <primary>employment</primary> 219 </indexterm><indexterm> 220 <primary>jobs</primary> 221 </indexterm><indexterm> 222 <primary>risk</primary> 223 </indexterm> 224 Another factor that should be considered is that buying Microsoft products and services helps to 225 provide employment in the IT industry. Samba and Open Source software place those jobs at risk. 226 </para></blockquote> 227 228 <para><indexterm> 229 <primary>Active Directory</primary> 230 </indexterm><indexterm> 231 <primary>independent expert</primary> 232 </indexterm> 233 This is also a challenge to rise above the trouble spot. You call Stan's team together for a simple 234 discussion, but it gets further out of hand. When you return to your office, you find the following 235 email in your in-box: 236 </para> 237 238 <para> 239 Good afternoon, 240 </para> 241 242 <blockquote><attribution>Stan</attribution><para> 243 I apologize for the leak of internal discussions to the new business. It reflects poorly on our 244 professionalism and has put you in an unpleasant position. I regret the incident. 245 </para> 246 247 <para> 248 I also wish to advise that two of the recent recruits want to implement Kerberos authentication 249 across all systems. I concur with the desire to improve security. One of the new guys who is championing 250 the move to Kerberos was responsible for the comment that caused the embarrassment. 251 </para> 252 253 <para><indexterm> 254 <primary>Kerberos</primary> 255 </indexterm><indexterm> 256 <primary>OpenLDAP</primary> 257 </indexterm><indexterm> 258 <primary>Active Directory</primary> 259 </indexterm><indexterm> 260 <primary>consultant</primary> 261 </indexterm> 262 I am experiencing difficulty in handling the sharp push for Kerberos. He claims that Kerberos, OpenLDAP, 263 plus Samba-3 will seamlessly replace Microsoft Active Directory. I am a little out of my depth with respect 264 to the feasibility of such a move, but have taken steps to pull both of them into line. With your consent, 265 I would like to hire the services of a well-known Samba consultant to set the record straight. 266 </para> 267 268 <para><indexterm> 269 <primary>criticism</primary> 270 </indexterm><indexterm> 271 <primary>policy</primary> 272 </indexterm><indexterm> 273 <primary>Windows Servers</primary> 274 </indexterm><indexterm> 275 <primary>Active Directory</primary> 276 </indexterm><indexterm> 277 <primary>budgetted</primary> 278 </indexterm><indexterm> 279 <primary>financial responsibility</primary> 280 </indexterm> 281 I intend to use this report to answer the criticism raised and would like to establish a policy that we 282 will approve the use of Microsoft Windows Servers (and Active Directory) subject to all costs being covered 283 out of the budget of the division that wishes to go its own way. I propose that dissenters will still remain 284 responsible to meet the budgeted contribution to IT operations as a whole. I believe we should not coerce 285 use of any centrally proposed standards, but make all noncompliance the financial responsibility of the 286 out-of-step division. Hopefully, this will encourage all divisions to walk with us and not alone. 287 </para></blockquote> 288 289 <sect2> 290 <title>Assignment Tasks</title> 291 292 <para> 293 You agreed with Stan's recommendations and hired a consultant to help defuse the powder 294 keg. The consultant's task is to provide a tractable answer to each of the issues raised. The consultant must be able 295 to support his or her claims, keep emotions to the side, and answer technically. 296 </para> 297 298 </sect2> 299</sect1> 300 301<sect1> 302 <title>Dissection and Discussion</title> 303 304 <para><indexterm> 305 <primary>tool</primary> 306 </indexterm><indexterm> 307 <primary>benefit</primary> 308 </indexterm><indexterm> 309 <primary>choice</primary> 310 </indexterm><indexterm> 311 <primary>consultant</primary> 312 </indexterm><indexterm> 313 <primary>installation</primary> 314 </indexterm><indexterm> 315 <primary>income</primary> 316 </indexterm><indexterm> 317 <primary>employment</primary> 318 </indexterm> 319 Samba-3 is a tool. No one is pounding your door to make you use Samba. That is a choice that you are free to 320 make or reject. It is likely that your decision to use Samba can greatly benefit your company. 321 The Samba Team obviously believes that the Samba software is a worthy choice. 322 If you hire a consultant to assist with the installation and/or deployment of Samba, or if you hire 323 someone to help manage your Samba installation, you can create income and employment. Alternately, 324 money saved by not spending in the IT area can be spent elsewhere in the business. All money saved 325 or spent creates employment. 326 </para> 327 328 <para><indexterm> 329 <primary>economically sustainable</primary> 330 </indexterm><indexterm> 331 <primary>inter-operability</primary> 332 </indexterm><indexterm> 333 <primary>file and print service</primary> 334 </indexterm><indexterm> 335 <primary>cost</primary> 336 </indexterm><indexterm> 337 <primary>alternative</primary> 338 </indexterm> 339 In the long term, the use of Samba must be economically sustainable. In some situations, Samba is adopted 340 purely to provide file and print service interoperability on platforms that otherwise cannot provide 341 access to data and to printers for Microsoft Windows clients. Samba is used by some businesses to 342 effect a reduction in the cost of providing IT services. Obviously, it is also used by some as an 343 alternative to the use of a Microsoft file and print serving platforms with no consideration of costs. 344 </para> 345 346 <para><indexterm> 347 <primary>documentation</primary> 348 </indexterm><indexterm> 349 <primary>responsibility</primary> 350 </indexterm><indexterm> 351 <primary>fix</primary> 352 </indexterm><indexterm> 353 <primary>broken</primary> 354 </indexterm> 355 It would be foolish to adopt a technology that might put any data or users at risk. Security affects 356 everyone. The Samba-Team is fully cognizant of the responsibility they have to their users. 357 The Samba documentation clearly reveals that full responsibility is accepted to fix anything 358 that is broken. 359 </para> 360 361 <para><indexterm> 362 <primary>commercial</primary> 363 </indexterm><indexterm> 364 <primary>software</primary> 365 </indexterm><indexterm> 366 <primary>commercial software</primary> 367 </indexterm><indexterm> 368 <primary>End User License Agreement</primary> 369 <see>EULA</see> 370 </indexterm><indexterm> 371 <primary>accountable</primary> 372 </indexterm><indexterm> 373 <secondary>liability</secondary> 374 </indexterm><indexterm> 375 <primary>accepts liability</primary> 376 </indexterm><indexterm> 377 <primary>price paid</primary> 378 </indexterm><indexterm> 379 <primary>product defects</primary> 380 </indexterm><indexterm> 381 <primary>reimburse</primary> 382 </indexterm><indexterm> 383 <primary>extent</primary> 384 </indexterm> 385 There is a mistaken perception in the IT industry that commercial software providers are fully 386 accountable for the defects in products. Open Source software comes with no warranty, so it is 387 often assumed that its use confers a higher degree of risk. Everyone should read commercial software 388 End User License Agreements (EULAs). You should determine what real warranty is offered and the 389 extent of liability that is accepted. Doing so soon dispels the popular notion that 390 commercial software vendors are willingly accountable for product defects. In many cases, the 391 commercial vendor accepts liability only to reimburse the price paid for the software. 392 </para> 393 394 <para><indexterm> 395 <primary>consumer</primary> 396 </indexterm><indexterm> 397 <primary>EULA</primary> 398 </indexterm><indexterm> 399 <primary>track record</primary> 400 </indexterm><indexterm> 401 <primary>commercial software</primary> 402 </indexterm><indexterm> 403 <primary>support</primary> 404 </indexterm><indexterm> 405 <primary>vendor</primary> 406 </indexterm> 407 The real issues that a consumer (like you) needs answered are What is the way of escape from technical 408 problems, and how long will it take? The average problem turnaround time in the Open Source community is 409 approximately 48 hours. What does the EULA offer? What is the track record in the commercial software 410 industry? What happens when your commercial vendor decides to cease providing support? 411 </para> 412 413 <para><indexterm> 414 <primary>source code</primary> 415 </indexterm><indexterm> 416 <primary>Open Source</primary> 417 </indexterm><indexterm> 418 <primary>hire</primary> 419 </indexterm><indexterm> 420 <primary>programmer</primary> 421 </indexterm><indexterm> 422 <primary>solve</primary> 423 </indexterm><indexterm> 424 <primary>fix</primary> 425 </indexterm><indexterm> 426 <secondary>problem</secondary> 427 </indexterm> 428 Open Source software at least puts you in possession of the source code. This means that when 429 all else fails, you can hire a programmer to solve the problem. 430 </para> 431 432 <sect2> 433 <title>Technical Issues</title> 434 435 <para> 436 Each issue is now discussed and, where appropriate, example implementation steps are 437 provided. 438 </para> 439 440 <variablelist> 441 <varlistentry> 442 <term>Winbind and Security</term> 443 <listitem><para><indexterm> 444 <primary>Winbind</primary> 445 </indexterm><indexterm> 446 <primary>Security</primary> 447 </indexterm><indexterm> 448 <primary>network</primary> 449 <secondary>administrators</secondary> 450 </indexterm><indexterm> 451 <primary>Domain users</primary> 452 </indexterm><indexterm> 453 <secondary>Domain account</secondary> 454 </indexterm><indexterm> 455 <primary>credentials</primary> 456 </indexterm><indexterm> 457 <primary>Network Neighborhood</primary> 458 </indexterm><indexterm> 459 <primary>UNIX/Linux server</primary> 460 </indexterm><indexterm> 461 <primary>browse</primary> 462 </indexterm><indexterm> 463 <primary>shares</primary> 464 </indexterm> 465 Windows network administrators may be dismayed to find that <command>winbind</command> 466 exposes all domain users so that they may use their domain account credentials to 467 log on to a UNIX/Linux system. The fact that all users in the domain can see the 468 UNIX/Linux server in their Network Neighborhood and can browse the shares on the 469 server seems to excite them further. 470 </para> 471 472 <para><indexterm> 473 <primary>Domain Member server</primary> 474 </indexterm><indexterm> 475 <primary>familiar</primary> 476 </indexterm><indexterm> 477 <primary>fear</primary> 478 </indexterm><indexterm> 479 <primary>unknown</primary> 480 </indexterm> 481 <command>winbind</command> provides for the UNIX/Linux domain member server or 482 client, the same as one would obtain by adding a Microsoft Windows server or 483 client to the domain. The real objection is the fact that Samba is not MS Windows 484 and therefore requires handling a little differently from the familiar Windows systems. 485 One must recognize fear of the unknown. 486 </para> 487 488 <para><indexterm> 489 <primary>network administrators</primary> 490 </indexterm><indexterm> 491 <primary>recognize</primary> 492 </indexterm><indexterm> 493 <primary>winbind</primary> 494 </indexterm><indexterm> 495 <primary>over-ride</primary> 496 </indexterm><indexterm> 497 <primary>Active Directory</primary> 498 <secondary>management tools</secondary> 499 </indexterm><indexterm> 500 <primary>fears</primary> 501 </indexterm> 502 Windows network administrators need to recognize that <command>winbind</command> does 503 not, and cannot, override account controls set using the Active Directory management 504 tools. The control is the same. Have no fear. 505 </para> 506 507 <para><indexterm> 508 <primary>ADS Domain</primary> 509 </indexterm><indexterm> 510 <primary>account</primary> 511 <secondary>ADS Domain</secondary> 512 </indexterm><indexterm> 513 <primary>winbind</primary> 514 </indexterm><indexterm> 515 <primary>browsing</primary> 516 </indexterm><indexterm> 517 <primary>permits</primary> 518 </indexterm><indexterm> 519 <primary>access</primary> 520 </indexterm><indexterm> 521 <primary>drive mapping</primary> 522 </indexterm><indexterm> 523 <primary>protected</primary> 524 </indexterm><indexterm> 525 <primary>security controls</primary> 526 </indexterm><indexterm> 527 <primary>access controls</primary> 528 </indexterm> 529 Where Samba and the ADS domain account information obtained through the use of 530 <command>winbind</command> permits access, by browsing or by the drive mapping to 531 a share, to data that should be better protected. This can only happen when security 532 controls have not been properly implemented. Samba permits access controls to be set 533 on: 534 </para> 535 536 <itemizedlist> 537 <listitem><para>Shares themselves (i.e., the logical share itself)</para></listitem> 538 <listitem><para>The share definition in &smb.conf;</para></listitem> 539 <listitem><para>The shared directories and files using UNIX permissions</para></listitem> 540 <listitem><para>Using Windows 2000 ACLs &smbmdash; if the file system is POSIX enabled</para></listitem> 541 </itemizedlist> 542 543 <para> 544 Examples of each are given in <link linkend="ch10expl"/>. 545 </para> 546 </listitem> 547 </varlistentry> 548 549 <varlistentry> 550 <term>User and Group Controls</term> 551 <listitem><para><indexterm> 552 <primary>User and Group Controls</primary> 553 </indexterm><indexterm> 554 <primary>management</primary> 555 <secondary>User</secondary> 556 </indexterm><indexterm> 557 <primary>management</primary> 558 <secondary>group</secondary> 559 </indexterm><indexterm> 560 <primary>ADS</primary> 561 </indexterm><indexterm> 562 <primary>permissions</primary> 563 </indexterm><indexterm> 564 <primary>privileges</primary> 565 </indexterm><indexterm> 566 <primary>flexibility</primary> 567 </indexterm><indexterm> 568 <primary>access controls</primary> 569 </indexterm><indexterm> 570 <primary>share definition</primary> 571 </indexterm> 572 User and group management facilities as known in the Windows ADS environment may be 573 used to provide equivalent access control constraints or to provide equivalent 574 permissions and privileges on Samba servers. Samba offers greater flexibility in the 575 use of user and group controls because it has additional layers of control compared to 576 Windows 200x/XP. For example, access controls on a Samba server may be set within 577 the share definition in a manner for which Windows has no equivalent. 578 </para> 579 580 <para><indexterm> 581 <primary>analysis</primary> 582 </indexterm><indexterm> 583 <primary>system security</primary> 584 </indexterm><indexterm> 585 <primary>safe-guards</primary> 586 </indexterm><indexterm> 587 <primary>permissions</primary> 588 <secondary>excessive</secondary> 589 </indexterm><indexterm> 590 <primary>file system</primary> 591 </indexterm><indexterm> 592 <primary>shared resource</primary> 593 </indexterm><indexterm> 594 <primary>share definition</primary> 595 </indexterm> 596 In any serious analysis of system security, it is important to examine the safeguards 597 that remain when all other protective measures fail. An administrator may inadvertently 598 set excessive permissions on the file system of a shared resource, or he may set excessive 599 privileges on the share itself. If that were to happen in a Windows 2003 Server environment, 600 the data would indeed be laid bare to abuse. Yet, within a Samba share definition, it is 601 possible to guard against that by enforcing controls on the share definition itself. You 602 see a practical example of this a little later in this chapter. 603 </para> 604 605 <para><indexterm> 606 <primary>diligence</primary> 607 </indexterm><indexterm> 608 <primary>weakness</primary> 609 </indexterm> 610 The report that is critical of Samba really ought to have exercised greater due 611 diligence: the real weakness is on the side of a Microsoft Windows environment. 612 </para></listitem> 613 </varlistentry> 614 615 <varlistentry> 616 <term>Security Overall</term> 617 <listitem><para><indexterm> 618 <primary>defects</primary> 619 </indexterm> 620 Samba is designed in such a manner that weaknesses inherent in the design of 621 Microsoft Windows networking ought not to expose the underlying UNIX/Linux file 622 system in any way. All software has potential defects, and Samba is no exception. 623 What matters more is how defects that are discovered get dealt with. 624 </para> 625 626 <para><indexterm> 627 <primary>security</primary> 628 </indexterm><indexterm> 629 <primary>protection</primary> 630 </indexterm><indexterm> 631 <primary>compromise</primary> 632 </indexterm><indexterm> 633 <primary>consequential risk</primary> 634 </indexterm> 635 The Samba Team totally agrees with the necessity to observe and fully implement 636 every security facility to provide a level of protection and security that is necessary 637 and that the end user (or network administrator) needs. Never would the Samba Team 638 recommend a compromise to system security, nor would deliberate defoliation of 639 security be publicly condoned; yet this is the practice by many Windows network 640 administrators just to make happy users who have no notion of consequential risk. 641 </para> 642 643 <para><indexterm> 644 <primary>condemns</primary> 645 </indexterm><indexterm> 646 <primary>security fixes</primary> 647 </indexterm><indexterm> 648 <primary>updates</primary> 649 </indexterm><indexterm> 650 <primary>development</primary> 651 </indexterm><indexterm> 652 <primary>documentation</primary> 653 </indexterm><indexterm> 654 <primary>security updates</primary> 655 </indexterm><indexterm> 656 <primary>turn-around time</primary> 657 </indexterm> 658 The report condemns Samba for releasing updates and security fixes, yet Microsoft 659 online updates need to be applied almost weekly. The answer to the criticism 660 lies in the fact that Samba development is continuing, documentation is improving, 661 user needs are being increasingly met or exceeded, and security updates are issued 662 with a short turnaround time. 663 </para> 664 665 <para><indexterm> 666 <primary>modularization</primary> 667 </indexterm><indexterm> 668 <primary>next generation</primary> 669 </indexterm><indexterm> 670 <primary>responsible</primary> 671 </indexterm><indexterm> 672 <primary>dependability</primary> 673 </indexterm><indexterm> 674 <primary>road-map</primary> 675 <secondary>published</secondary> 676 </indexterm> 677 The release of Samba-4 is expected around late 2004 to early 2005 and involves a near 678 complete rewrite to permit extensive modularization and to prepare Samba for new 679 functionality planned for addition during the next-generation series. The Samba Team 680 is responsible and can be depended upon; the history to date suggests a high 681 degree of dependability and on charter development consistent with published 682 roadmap projections. 683 </para> 684 685 <para><indexterm> 686 <primary>foundation members</primary> 687 </indexterm><indexterm> 688 <primary>Common Internet File System</primary> 689 <see>CIFS</see> 690 </indexterm><indexterm> 691 <primary>network attached storage</primary> 692 <see>NAS</see> 693 </indexterm><indexterm> 694 <primary>conferences</primary> 695 </indexterm><indexterm> 696 <primary>presence and leadership</primary> 697 </indexterm><indexterm> 698 <primary>leadership</primary> 699 </indexterm><indexterm> 700 <primary>inter-operability</primary> 701 </indexterm> 702 Not well published is the fact that Microsoft was a foundation member of 703 the Common Internet File System (CIFS) initiative, together with the participation 704 of the network attached storage (NAS) industry. Unfortunately, for the past few years, 705 Microsoft has been absent from active involvement at CIFS conferences and has 706 not exercised the leadership expected of a major force in the networking technology 707 space. The Samba Team has maintained consistent presence and leadership at all 708 CIFS conferences and at the interoperability laboratories run concurrently with 709 them. 710 </para></listitem> 711 </varlistentry> 712 713 <varlistentry> 714 <term>Cryptographic Controls (schannel, sign'n'seal)</term> 715 <listitem><para><indexterm> 716 <primary>Cryptographic</primary> 717 </indexterm><indexterm> 718 <primary>schannel</primary> 719 </indexterm><indexterm> 720 <primary>digital sign'n'seal</primary> 721 </indexterm> 722 The report correctly mentions that Samba did not support the most recent 723 <constant>schannel</constant> and <constant>digital sign'n'seal</constant> features 724 of Microsoft Windows NT/200x/XPPro products. This is one of the key features 725 of the Samba-3 release. Market research reports take so long to generate that they are 726 seldom a reflection of current practice, and in many respects reports are like a 727 pathology report &smbmdash; they reflect accurately (at best) status at a snapshot in time. 728 Meanwhile, the world moves on. 729 </para> 730 731 <para><indexterm> 732 <primary>public specifications</primary> 733 </indexterm><indexterm> 734 <primary>protocols</primary> 735 </indexterm><indexterm> 736 <primary>algorithm</primary> 737 </indexterm><indexterm> 738 <primary>compatible</primary> 739 </indexterm><indexterm> 740 <primary>network</primary> 741 <secondary>traffic</secondary> 742 <tertiary>observation</tertiary> 743 </indexterm><indexterm> 744 <primary>defensible standards</primary> 745 </indexterm><indexterm> 746 <primary>secure networking</primary> 747 </indexterm> 748 It should be pointed out that had clear public specifications for the protocols 749 been published, it would have been much easier to implement these features and would have 750 taken less time to do. The sole mechanism used to find an algorithm that is compatible 751 with the methods used by Microsoft has been based on observation of network traffic 752 and trial-and-error implementation of potential techniques. The real value of public 753 and defensible standards is obvious to all and would have enabled more secure networking 754 for everyone. 755 </para> 756 757 <para><indexterm> 758 <primary>Critics</primary> 759 </indexterm><indexterm> 760 <primary>digital sign'n'seal</primary> 761 </indexterm> 762 Critics of Samba often ignore fundamental problems that may plague (or may have plagued) 763 the users of Microsoft's products also. Those who are first to criticize Samba 764 for not rushing into release of <constant>digital sign'n'seal</constant> support 765 often dismiss the problems that Microsoft has 766 <ulink url="http://support.microsoft.com/default.aspx?kbid=321733">acknowledged</ulink> 767 and for which a fix was provided. In fact, 768 <ulink url="http://www.tangent-systems.com/support/delayedwrite.html">Tangent Systems</ulink> 769 have documented a significant problem with delays writes that can be connected with the 770 implementation of sign'n'seal. They provide a work-around that is not trivial for many 771 Windows networking sites. From notes such as this it is clear that there are benefits 772 from not rushing new technology out of the door too soon. 773 </para> 774 775 <para><indexterm> 776 <primary>secure networking protocols</primary> 777 </indexterm><indexterm> 778 <primary>refereed standards</primary> 779 </indexterm><indexterm> 780 <primary>proprietary</primary> 781 </indexterm><indexterm> 782 <primary>digital rights</primary> 783 </indexterm><indexterm> 784 <primary>protection</primary> 785 </indexterm><indexterm> 786 <primary>networking protocols</primary> 787 </indexterm><indexterm> 788 <primary>diffusion</primary> 789 </indexterm><indexterm> 790 <primary>consumer</primary> 791 </indexterm><indexterm> 792 <primary>choice</primary> 793 </indexterm> 794 One final comment is warranted. If companies want more secure networking protocols, 795 the most effective method by which this can be achieved is by users seeking 796 and working together to help define open and publicly refereed standards. The 797 development of closed source, proprietary methods that are developed in a 798 clandestine framework of secrecy, under claims of digital rights protection, does 799 not favor the diffusion of safe networking protocols and certainly does not 800 help the consumer to make a better choice. 801 </para></listitem> 802 </varlistentry> 803 804 <varlistentry> 805 <term>Active Directory Replacement with Kerberos, LDAP, and Samba 806 <indexterm> 807 <primary>Active Directory</primary> 808 <secondary>Replacement</secondary> 809 </indexterm><indexterm> 810 <primary>Kerberos</primary> 811 </indexterm><indexterm> 812 <primary>LDAP</primary> 813 </indexterm><indexterm> 814 <primary>remote procedure call</primary> 815 <see>RPC</see> 816 </indexterm> 817 818 </term> 819 <listitem><para> 820 <literallayout> </literallayout> 821 The Microsoft networking protocols extensively make use of remote procedure call (RPC) 822 technology. Active Directory is not a simple mixture of LDAP and Kerberos together 823 with file and print services, but rather is a complex, intertwined implementation 824 of them that uses RPCs that are not supported by any of these component technologies 825 and yet by which they are made to interoperate in ways that the components do not 826 support. 827 </para> 828 829 <para><indexterm> 830 <primary>Active Directory</primary> 831 <secondary>Server</secondary> 832 </indexterm><indexterm> 833 <primary>OpenLDAP</primary> 834 </indexterm><indexterm> 835 <primary>Kerberos</primary> 836 </indexterm><indexterm> 837 <primary>project maintainers</primary> 838 </indexterm><indexterm> 839 <primary>LDAP</primary> 840 </indexterm> 841 In order to make the popular request for Samba to be an Active Directory Server a 842 reality, it is necessary to add to OpenLDAP, Kerberos, as well as Samba, RPC calls 843 that are not presently supported. The Samba Team has not been able to gain critical 844 overall support for all project maintainers to work together on the complex 845 challenge of developing and integrating the necessary technologies. Therefore, if 846 the Samba Team does not make it a priority to absorb Kerberos and LDAP functionality 847 into the Samba project, this dream request cannot become a reality. 848 </para> 849 850 <para><indexterm> 851 <primary>missing RPC's</primary> 852 </indexterm><indexterm> 853 <primary>road-map</primary> 854 </indexterm><indexterm> 855 <primary>ADS</primary> 856 <secondary>server</secondary> 857 </indexterm><indexterm> 858 <primary>MMC</primary> 859 </indexterm><indexterm> 860 <primary>managed</primary> 861 </indexterm> 862 At this time, the integration of LDAP, Kerberos, and the missing RPCs is not on the 863 Samba development roadmap. If it is not on the published roadmap, it cannot be delivered 864 anytime soon. Ergo, ADS server support is not a current goal for Samba development. 865 The Samba Team is most committed to permitting Samba to be a full ADS domain member 866 that is increasingly capable of being managed using Microsoft Windows MMC tools. 867 </para></listitem> 868 </varlistentry> 869 </variablelist> 870 871 <sect3> 872 <title>Kerberos Exposed</title> 873 874 <para><indexterm> 875 <primary>kerberos</primary> 876 </indexterm><indexterm> 877 <primary>unauthorized activities</primary> 878 </indexterm><indexterm> 879 <primary>authorized location</primary> 880 </indexterm> 881 Kerberos is a network authentication protocol that provides secure authentication for 882 client-server applications by using secret-key cryptography. Firewalls are an insufficient 883 barrier mechanism in today's networking world; at best they only restrict incoming network 884 traffic but cannot prevent network traffic that comes from authorized locations from 885 performing unauthorized activities. 886 </para> 887 888 <para><indexterm> 889 <primary>strong cryptography</primary> 890 </indexterm><indexterm> 891 <primary>identity</primary> 892 </indexterm><indexterm> 893 <primary>integrity</primary> 894 </indexterm> 895 Kerberos was created by MIT as a solution to network security problems. The Kerberos protocol uses 896 strong cryptography so that a client can prove its identity to a server (and vice versa) across an 897 insecure network connection. After a client and server has used Kerberos to prove their identity, 898 they can also encrypt all of their communications to assure privacy and data integrity as they go 899 about their business. 900 </para> 901 902 <para><indexterm> 903 <primary>trusted third-party</primary> 904 </indexterm><indexterm> 905 <primary>principals</primary> 906 </indexterm><indexterm> 907 <primary>trusting</primary> 908 </indexterm><indexterm> 909 <primary>kerberos</primary> 910 <secondary>server</secondary> 911 </indexterm><indexterm> 912 <primary>secret</primary> 913 </indexterm> 914 Kerberos is a trusted third-party service. That means that there is a third party (the kerberos 915 server) that is trusted by all the entities on the network (users and services, usually called 916 principals). All principals share a secret password (or key) with the kerberos server and this 917 enables principals to verify that the messages from the kerberos server are authentic. Therefore, 918 trusting the kerberos server, users and services can authenticate each other. 919 </para> 920 921 <para> 922 <indexterm><primary>restricted export</primary></indexterm> 923 <indexterm><primary>MIT Kerberos</primary></indexterm> 924 <indexterm><primary>Heimdal Kerberos</primary></indexterm> 925 Kerberos was, until recently, a technology that was restricted from being exported from the United States. 926 For many years that hindered global adoption of more secure networking technologies both within the United States 927 and abroad. A free and unencumbered implementation of MIT Kerberos has been produced in Europe 928 and is available from the <ulink url="http://www.pdc.kth.se/heimdal/">Royal Institute</ulink> of 929 Technology (KTH), Sweden. It is known as the Heimdal Kerberos project. In recent times the U.S. government 930 has removed sanctions affecting the global distribution of MIT Kerberos. It is likely that there will be a 931 significant surge forward in the development of Kerberos-enabled applications and in the general deployment 932 and use of Kerberos across the spectrum of the information technology industry. 933 </para> 934 935 <para> 936 <indexterm><primary>Kerberos</primary><secondary>interoperability</secondary></indexterm> 937 A storm has broken out concerning interoperability between MIT Kerberos and Microsofts' implementation 938 of it. For example, a 2002 939 <ulink url="http://www.idg.com.sg/idgwww.nsf/0/5DDA8D153A7505A748256BAB000D992A?OpenDocument">IDG</ulink> 940 report<footnote><para>Note: This link is no longer active. The same article is still 941 available from <ulink url="http://199.105.191.226/Man/2699/020430msdoj/">ITWorld.com</ulink> (July 5, 2005)</para></footnote> by 942 states: 943 </para> 944 945 <blockquote><para> 946 A Microsoft Corp. executive testified at the software giant's remedy hearing that the company goes to 947 great lengths to disclose interfaces and protocols that allow third-party software products to interact 948 with Windows. But a lawyer with the states suing Microsoft pointed out that when it comes to the company's 949 use of the Kerberos authentication specification, not everyone agrees. 950 </para> 951 952 <para> 953 <indexterm><primary>Kerberos</primary><secondary>unspecified fields</secondary></indexterm> 954 Robert Short, vice president of Windows core technology at Microsoft, wrote in his direct testimony prepared 955 before his appearance that non-Microsoft operating systems can disregard the portion of the Kerberos version 956 5 specification that Windows clients use for proprietary purposes and still achieve interoperability with 957 the Microsoft OS. Microsoft takes advantage of unspecified fields in the Kerberos specification for storing 958 Windows-specific authorization data, Short wrote. The designers of Kerberos left these fields undefined so 959 that software developers could add their own authorization information, he said. 960 </para></blockquote> 961 962 <para> 963 <indexterm><primary>DCE</primary></indexterm> 964 <indexterm><primary>RPC</primary></indexterm> 965 It so happens that Microsoft Windows clients depend on and expect the contents of the <emphasis>unspecified 966 fields</emphasis> in the Kerberos 5 communications data stream for their Windows interoperability, 967 particularly when Samba is expected to emulate a Windows Server 200x domain controller. But the interoperability 968 issue goes far deeper than this. In the domain control protocols that are used by MS Windows XP Professional, 969 there is a tight interdependency between the Kerberos protocols and the Microsoft distributed computing environment 970 (DCE) RPCs that themselves are an integral part of the SMB/CIFS protocols as used by 971 Microsoft. 972 </para> 973 974 <para> 975 Microsoft makes the following comment in a reference in a 976 <ulink url="http://www.microsoft.com/technet/itsolutions/interop/mgmt/kerberos.asp"> 977 technet</ulink> article: 978 </para> 979 980 <blockquote><para><indexterm> 981 <primary>Privilege Attribute Certificates</primary> 982 <see>PAC</see> 983 </indexterm><indexterm> 984 <primary>access control</primary> 985 </indexterm> 986 The DCE Security Services are also layered on the Kerberos protocol. DCE authentication services use RPC 987 representation of Kerberos protocol messages. In addition, DCE uses the authorization data field in Kerberos 988 tickets to convey Privilege Attribute Certificates (PACs) that define user identity and group membership. 989 The DCE PAC is used in a similar manner as Windows NT Security IDs for user authorization and access control. 990 Windows NT services will not be able to translate DCE PACs into Windows NT user and group identifiers. This 991 is not an issue with Kerberos interoperability, but rather an issue of interoperability between DCE and 992 Windows NT access control information. 993 </para></blockquote> 994 995 </sect3> 996 997 </sect2> 998 999</sect1> 1000 1001<sect1 id="ch10expl"> 1002 <title>Implementation</title> 1003 1004 <para> 1005 The following procedures outline the implementation of the security measures discussed so far. 1006 </para> 1007 1008 <sect2> 1009 <title>Share Access Controls</title> 1010 1011 <para><indexterm> 1012 <primary>Share Access Controls</primary> 1013 </indexterm><indexterm> 1014 <primary>filter</primary> 1015 </indexterm><indexterm> 1016 <primary>connection</primary> 1017 </indexterm> 1018 Access control entries placed on the share itself act as a filter at the time a when CIFS/SMB client (such as 1019 Windows XP Pro) attempts to make a connection to the Samba server. 1020 </para> 1021 1022 <procedure> 1023 <title>Create/Edit/Delete Share ACLs</title> 1024 <step><para><indexterm> 1025 <primary>Domain Administrator</primary> 1026 </indexterm><indexterm> 1027 <primary>account</primary> 1028 </indexterm> 1029 From a Windows 200x/XP Professional workstation, log on to the domain using the Domain Administrator 1030 account (on Samba domains, this is usually the account called <constant>root</constant>). 1031 </para></step> 1032 1033 <step><para> 1034 Click 1035 <menuchoice> 1036 <guimenu>Start</guimenu> 1037 <guimenuitem>Settings</guimenuitem> 1038 <guimenuitem>Control Panel</guimenuitem> 1039 <guimenuitem>Administrative Tools</guimenuitem> 1040 <guimenuitem>Computer Management</guimenuitem> 1041 </menuchoice>. 1042 </para></step> 1043 1044 <step><para> 1045 In the left panel, 1046 <menuchoice> 1047 <guimenu>[Right mouse menu item] Computer Management (Local)</guimenu> 1048 <guimenuitem>Connect to another computer ...</guimenuitem> 1049 <guimenuitem>Browse...</guimenuitem> 1050 <guimenuitem>Advanced</guimenuitem> 1051 <guimenuitem>Find Now</guimenuitem> 1052 </menuchoice>. In the lower panel, click on the name of the server you wish to 1053 administer. Click <menuchoice> 1054 <guimenu>OK</guimenu> 1055 <guimenuitem>OK</guimenuitem> 1056 <guimenuitem>OK</guimenuitem> 1057 </menuchoice>.<indexterm> 1058 <primary>Computer Management</primary> 1059 </indexterm> 1060 In the left panel, the entry <guimenu>Computer Management (Local)</guimenu> should now reflect 1061 the change made. For example, if the server you are administering is called <constant>FRODO</constant>, 1062 the Computer Management entry should now say <guimenu>Computer Management (FRODO)</guimenu>. 1063 </para></step> 1064 1065 <step><para> 1066 In the left panel, click <menuchoice> 1067 <guimenu>Computer Management (FRODO)</guimenu> 1068 <guimenuitem>[+] Shared Folders</guimenuitem> 1069 <guimenuitem>Shares</guimenuitem> 1070 </menuchoice>. 1071 </para></step> 1072 1073 <step><para><indexterm> 1074 <primary>ACLs</primary> 1075 </indexterm><indexterm> 1076 <primary>Share Permissions</primary> 1077 </indexterm> 1078 In the right panel, double-click on the share on which you wish to set/edit ACLs. This 1079 will bring up the Properties panel. Click the <guimenu>Share Permissions</guimenu> tab. 1080 </para></step> 1081 1082 <step><para><indexterm> 1083 <primary>access control settings</primary> 1084 </indexterm><indexterm> 1085 <primary>Everyone</primary> 1086 </indexterm><indexterm> 1087 <primary>full control</primary> 1088 </indexterm><indexterm> 1089 <primary>over-rule</primary> 1090 </indexterm><indexterm> 1091 <primary>permissions</primary> 1092 </indexterm><indexterm> 1093 <primary>rejected</primary> 1094 </indexterm> 1095 You may now edit/add/remove access control settings. Be very careful. Many problems have been 1096 created by people who decided that everyone should be rejected but one particular group should 1097 have full control. This is a catch-22 situation because members of that particular group also 1098 belong to the group <constant>Everyone</constant>, which therefore overrules any permissions 1099 set for the permitted group. 1100 </para></step> 1101 1102 <step><para> 1103 When you are done with editing, close all panels by clicking through the <guimenu>OK</guimenu> 1104 buttons. 1105 </para></step> 1106 </procedure> 1107 1108 </sect2> 1109 1110 <sect2> 1111 <title>Share Definition Controls</title> 1112 1113 <para><indexterm> 1114 <primary>Share Definition</primary> 1115 <secondary>Controls</secondary> 1116 </indexterm><indexterm> 1117 <primary>check-point</primary> 1118 </indexterm><indexterm> 1119 <primary>pile-driver</primary> 1120 </indexterm><indexterm> 1121 <primary>credential</primary> 1122 </indexterm><indexterm> 1123 <primary>powers</primary> 1124 </indexterm><indexterm> 1125 <primary>privileges</primary> 1126 </indexterm> 1127 Share-definition-based access controls can be used like a checkpoint or like a pile-driver. Just as a 1128 checkpoint can be used to require someone who wants to get through to meet certain requirements, so 1129 it is possible to require the user (or group the user belongs to) to meet specified credential-related 1130 objectives. It can be likened to a pile-driver by overriding default controls in that having met the 1131 credential-related objectives, the user can be granted powers and privileges that would not normally be 1132 available under default settings. 1133 </para> 1134 1135 <para><indexterm> 1136 <primary>access controls</primary> 1137 </indexterm><indexterm> 1138 <primary>ACLs</primary> 1139 </indexterm><indexterm> 1140 <primary>share definition controls</primary> 1141 </indexterm><indexterm> 1142 <primary>hierarchy of control</primary> 1143 </indexterm> 1144 It must be emphasized that the controls discussed here can act as a filter or give rights of passage 1145 that act as a superstructure over normal directory and file access controls. However, share-level 1146 ACLs act at a higher level than do share definition controls because the user must filter through the 1147 share-level controls to get to the share-definition controls. The proper hierarchy of controls implemented 1148 by Samba and Windows networking consists of: 1149 </para> 1150 1151 <orderedlist> 1152 <listitem><para>Share-level ACLs</para></listitem> 1153 <listitem><para>Share-definition controls</para></listitem> 1154 <listitem><para>Directory and file permissions</para></listitem> 1155 <listitem><para>Directory and file POSIX ACLs</para></listitem> 1156 </orderedlist> 1157 1158 <sect3> 1159 <title>Checkpoint Controls</title> 1160 1161 <para><indexterm> 1162 <primary>Checkpoint Controls</primary> 1163 </indexterm> 1164 Consider the following extract from a &smb.conf; file defining the share called <constant>Apps</constant>: 1165<screen> 1166[Apps] 1167 comment = Application Share 1168 path = /data/apps 1169 read only = Yes 1170 valid users = @Employees 1171</screen> 1172 This definition permits only those who are members of the group called <constant>Employees</constant> to 1173 access the share. 1174 </para> 1175 1176 <note><para><indexterm> 1177 <primary>Domain Member</primary> 1178 <secondary>servers</secondary> 1179 </indexterm><indexterm> 1180 <primary>winbind use default domain</primary> 1181 </indexterm><indexterm> 1182 <primary>fully qualified</primary> 1183 </indexterm><indexterm> 1184 <primary>valid users</primary> 1185 </indexterm><indexterm> 1186 <primary>delimiter</primary> 1187 </indexterm> 1188 On domain member servers and clients, even when the <parameter>winbind use default domain</parameter> has 1189 been specified, the use of domain accounts in security controls requires fully qualified domain specification, 1190 for example, <smbconfoption name="valid users">@"MEGANET\Northern Engineers"</smbconfoption>. 1191 Note the necessity to use the double quotes to avoid having the space in the Windows group name interpreted as a 1192 delimiter. 1193 </para></note> 1194 1195 <para><indexterm> 1196 <primary>ACL</primary> 1197 </indexterm><indexterm> 1198 <primary>access</primary> 1199 </indexterm><indexterm> 1200 <primary>validate</primary> 1201 </indexterm> 1202 If there is an ACL on the share itself to permit read/write access for all <constant>Employees</constant> 1203 as well as read/write for the group <constant>Doctors</constant>, both groups are permitted through 1204 to the share. However, at the moment an attempt is made to set up a connection to the share, a member of 1205 the group <constant>Doctors</constant>, who is not also a member of the group <constant>Employees</constant>, 1206 would immediately fail to validate. 1207 </para> 1208 1209 <para><indexterm> 1210 <primary>share definition controls</primary> 1211 </indexterm> 1212 Consider another example. In this case, you want to permit all members of the group <constant>Employees</constant> 1213 except the user <constant>patrickj</constant> to access the <constant>Apps</constant> share. This can be 1214 easily achieved by setting a share-level ACL permitting only <constant>Employees</constant> to access the share, 1215 and then in the share definition controls excluding just <constant>patrickj</constant>. Here is how that might 1216 be done: 1217<screen> 1218[Apps] 1219 comment = Application Share 1220 path = /data/apps 1221 read only = Yes 1222 invalid users = patrickj 1223</screen> 1224 <indexterm> 1225 <primary>permissions</primary> 1226 </indexterm> 1227 Let us assume that you want to permit the user <constant>gbshaw</constant> to manage any file in the 1228 UNIX/Linux file system directory <filename>/data/apps</filename>, but you do not want to grant any write 1229 permissions beyond that directory tree. Here is one way this can be done: 1230<screen> 1231[Apps] 1232 comment = Application Share 1233 path = /data/apps 1234 read only = Yes 1235 invalid users = patrickj 1236 admin users = gbshaw 1237</screen> 1238 <indexterm> 1239 <primary>administrative rights</primary> 1240 </indexterm> 1241 Now we have a set of controls that permits only <constant>Employees</constant> who are also members of 1242 the group <constant>Doctors</constant>, excluding the user <constant>patrickj</constant>, to have 1243 read-only privilege, but the user <constant>gbshaw</constant> is granted administrative rights. 1244 The administrative rights conferred upon the user <constant>gbshaw</constant> permit operation as 1245 if that user has logged in as the user <constant>root</constant> on the UNIX/Linux system and thus, 1246 for access to the directory tree that has been shared (exported), permit the user to override controls 1247 that apply to all other users on that resource. 1248 </para> 1249 1250 <para> 1251 There are additional checkpoint controls that may be used. For example, if for the same share we now 1252 want to provide the user <constant>peters</constant> with the ability to write to one directory to 1253 which he has write privilege in the UNIX file system, you can specifically permit that with the 1254 following settings: 1255<screen> 1256[Apps] 1257 comment = Application Share 1258 path = /data/apps 1259 read only = Yes 1260 invalid users = patrickj 1261 admin users = gbshaw 1262 write list = peters 1263</screen> 1264 <indexterm> 1265 <primary>check-point controls</primary> 1266 </indexterm> 1267 This is a particularly complex example at this point, but it begins to demonstrate the possibilities. 1268 You should refer to the online manual page for the &smb.conf; file for more information regarding 1269 the checkpoint controls that Samba implements. 1270 </para> 1271 1272 </sect3> 1273 1274 <sect3> 1275 <title>Override Controls</title> 1276 1277 <para><indexterm> 1278 <primary>over-ride controls</primary> 1279 </indexterm> 1280 Override controls implemented by Samba permit actions like the adoption of a different identity 1281 during file system operations, the forced overwriting of normal file and directory permissions, 1282 and so on. You should refer to the online manual page for the &smb.conf; file for more information regarding 1283 the override controls that Samba implements. 1284 </para> 1285 1286 <para> 1287 In the following example, you want to create a Windows networking share that any user can access. 1288 However, you want all read and write operations to be performed as if the user <constant>billc</constant> 1289 and member of the group <constant>Mentors</constant> read/write the files. Here is one way this 1290 can be done: 1291<screen> 1292[someshare] 1293 comment = Some Files Everyone May Overwrite 1294 path = /data/somestuff 1295 read only = No 1296 force user = billc 1297 force group = Mentors 1298</screen> 1299 <indexterm> 1300 <primary>forced settings</primary> 1301 </indexterm><indexterm> 1302 <primary>overheads</primary> 1303 </indexterm> 1304 That is all there is to it. Well, it is almost that simple. The downside of this method is that 1305 users are logged onto the Windows client as themselves, and then immediately before accessing the 1306 file, Samba makes system calls to change the effective user and group to the forced settings 1307 specified, completes the file transaction, and then reverts to the actually logged-on identity. 1308 This imposes significant overhead on Samba. The alternative way to effectively achieve the same result 1309 (but with lower system CPU overheads) is described next. 1310 </para> 1311 1312 <para><indexterm> 1313 <primary>force user</primary> 1314 </indexterm><indexterm> 1315 <primary>force group</primary> 1316 </indexterm><indexterm> 1317 <primary>opportunistic</primary> 1318 <secondary>locking</secondary> 1319 </indexterm><indexterm> 1320 <primary>oplock break</primary> 1321 </indexterm><indexterm> 1322 <primary>performance degradation</primary> 1323 </indexterm> 1324 The use of the <parameter>force user</parameter> or the <parameter>force group</parameter> may 1325 also have a severe impact on system (particularly on Windows client) performance. If opportunistic 1326 locking is enabled on the share (the default), it causes an <constant>oplock break</constant> to be 1327 sent to the client even if the client has not opened the file. On networks that have high traffic 1328 density, or on links that are routed to a remote network segment, <constant>oplock breaks</constant> 1329 can be lost. This results in possible retransmission of the request, or the client may time-out while 1330 waiting for the file system transaction (read or write) to complete. The result can be a profound 1331 apparent performance degradation as the client continually attempts to reconnect to overcome the 1332 effect of the lost <constant>oplock break</constant>, or time-out. 1333 </para> 1334 1335 </sect3> 1336 1337 </sect2> 1338 1339 <sect2> 1340 <title>Share Point Directory and File Permissions</title> 1341 1342 <para><indexterm> 1343 <primary>security</primary> 1344 </indexterm><indexterm> 1345 <primary>privilege controls</primary> 1346 </indexterm><indexterm> 1347 <primary>permission</primary> 1348 </indexterm><indexterm> 1349 <primary>share definition controls</primary> 1350 </indexterm> 1351 Samba has been designed and implemented so that it respects as far as is feasible the security and 1352 user privilege controls that are built into the UNIX/Linux operating system. Samba does nothing 1353 with respect to file system access that violates file system permission settings, unless it is 1354 explicitly instructed to do otherwise through share definition controls. Given that Samba obeys 1355 UNIX file system controls, this chapter does not document simple information that can be obtained 1356 from a basic UNIX training guide. Instead, one common example of a typical problem is used 1357 to demonstrate the most effective solution referred to in the immediately preceding paragraph. 1358 </para> 1359 1360 <para><indexterm> 1361 <primary>Microsoft Office</primary> 1362 </indexterm><indexterm> 1363 <primary>Word</primary> 1364 </indexterm><indexterm> 1365 <primary>Excel</primary> 1366 </indexterm> 1367 One of the common issues that repeatedly pops up on the Samba mailing lists involves the saving of 1368 Microsoft Office files (Word and Excel) to a network drive. Here is the typical sequence: 1369 </para> 1370 1371 <orderedlist> 1372 <listitem><para> 1373 A user opens a Word document from a network drive. The file was owned by user <constant>janetp</constant> 1374 and <constant>users</constant>, and was set read/write-enabled for everyone. 1375 </para></listitem> 1376 1377 <listitem><para> 1378 File changes and edits are made. 1379 </para></listitem> 1380 1381 <listitem><para> 1382 The file is saved, and MS Word is closed. 1383 </para></listitem> 1384 1385 <listitem><para> 1386 The file is now owned by the user <constant>billc</constant> and group <constant>doctors</constant>, 1387 and is set read/write by <constant>billc</constant>, read-only by <constant>doctors</constant>, and 1388 no access by everyone. 1389 </para></listitem> 1390 1391 <listitem><para> 1392 The original owner cannot now access her own file and is <quote>justifiably</quote> upset. 1393 </para></listitem> 1394 </orderedlist> 1395 1396 <para> 1397 There have been many postings over the years that report the same basic problem. Frequently Samba users 1398 want to know when this <quote>bug</quote> will be fixed. The fact is, this is not a bug in Samba at all. 1399 Here is the real sequence of what happens in this case. 1400 </para> 1401 1402 <para><indexterm> 1403 <primary>MS Word</primary> 1404 </indexterm><indexterm> 1405 <primary>ownership</primary> 1406 </indexterm><indexterm> 1407 <primary>permissions</primary> 1408 </indexterm> 1409 When the user saves a file, MS Word creates a new (temporary) file. This file is naturally owned 1410 by the user who creates the file (<constant>billc</constant>) and has the permissions that follow 1411 that user's default settings within the operating system (UNIX/Linux). When MS Word has finished writing 1412 the file to disk, it then renames the new (temporary) file to the name of the old one. MS Word does not 1413 change the ownership or permissions to what they were on the original file. The file is thus a totally 1414 new file, and the old one has been deleted in the process. 1415 </para> 1416 1417 <para> 1418 Samba received a request to create a new file, and then to rename the file to a new name. The old file that 1419 has the same name is now automatically deleted. Samba has no way of knowing that the new file should 1420 perhaps have the same ownership and permissions as the old file. To Samba, these are entirely independent 1421 operations. 1422 </para> 1423 1424 <para> 1425 The question is, <quote>How can we solve the problem?</quote> 1426 </para> 1427 1428 <para> 1429 The solution is simple. Use UNIX file system permissions and controls to your advantage. Follow these 1430 simple steps to create a share in which all files will consistently be owned by the same user and the 1431 same group: 1432 </para> 1433 1434 1435 <procedure> 1436 <title>Using Directory Permissions to Force File User and Group Ownership</title> 1437 <step><para> 1438 Change your share definition so that it matches this pattern: 1439<screen> 1440[finance] 1441 path = /usr/data/finance 1442 browseable = Yes 1443 read only = No 1444</screen> 1445 </para></step> 1446 1447 <step><para><indexterm> 1448 <primary>permissions</primary> 1449 <secondary>user</secondary> 1450 </indexterm><indexterm> 1451 <primary>permissions</primary> 1452 <secondary>group</secondary> 1453 </indexterm> 1454 Set consistent user and group permissions recursively down the directory tree as shown here: 1455<screen> 1456&rootprompt; chown -R janetp.users /usr/data/finance 1457</screen> 1458 </para></step> 1459 1460 <step><para><indexterm> 1461 <primary>accessible</primary> 1462 </indexterm> 1463 Set the files and directory permissions to be read/write for owner and group, and not accessible 1464 to others (everyone), using the following command: 1465<screen> 1466&rootprompt; chmod ug+rwx,o-rwx /usr/data/finance 1467</screen> 1468 </para></step> 1469 1470 <step><para><indexterm> 1471 <primary>SGID</primary> 1472 </indexterm> 1473 Set the SGID (supergroup) bit on all directories from the top down. This means all files 1474 can be created with the permissions of the group set on the directory. It means all users 1475 who are members of the group <constant>finance</constant> can read and write all files in 1476 the directory. The directory is not readable or writable by anyone who is not in the 1477 <constant>finance</constant> group. Simply follow this example: 1478<screen> 1479&rootprompt; find /usr/data/finance -type d -exec chmod ug+s {}\; 1480</screen> 1481 1482 </para></step> 1483 1484 <step><para><indexterm> 1485 <primary>group membership</primary> 1486 </indexterm><indexterm> 1487 <primary>primary group</primary> 1488 </indexterm><indexterm> 1489 <primary>/etc/passwd</primary> 1490 </indexterm> 1491 Make sure all users that must have read/write access to the directory have 1492 <constant>finance</constant> group membership as their primary group, 1493 for example, the group they belong to in <filename>/etc/passwd</filename>. 1494 </para></step> 1495 </procedure> 1496 1497 </sect2> 1498 1499 <sect2> 1500 <title>Managing Windows 200x ACLs</title> 1501 1502 <para><indexterm> 1503 <primary>translate</primary> 1504 </indexterm><indexterm> 1505 <primary>Windows 2000 ACLs</primary> 1506 </indexterm><indexterm> 1507 <primary>Posix ACLs</primary> 1508 </indexterm><indexterm> 1509 <primary>side effects</primary> 1510 </indexterm> 1511 Samba must translate Windows 2000 ACLs to UNIX POSIX ACLs. This has some interesting side effects because 1512 there is not a one-to-one equivalence between them. The as-close-as-possible ACLs match means 1513 that some transactions are not possible from MS Windows clients. One of these is to reset the ownership 1514 of directories and files. If you want to reset ownership, this must be done from a UNIX/Linux login. 1515 </para> 1516 1517 <para> 1518 There are two possible ways to set ACLs on UNIX/Linux file systems from a Windows network workstation, 1519 either via File Manager or via the Microsoft Management Console (MMC) Computer Management interface. 1520 </para> 1521 1522 <sect3> 1523 <title>Using the MMC Computer Management Interface</title> 1524 1525 <procedure> 1526 <step><para> 1527 From a Windows 200x/XP Professional workstation, log on to the domain using the Domain Administrator 1528 account (on Samba domains, this is usually the account called <constant>root</constant>). 1529 </para></step> 1530 1531 <step><para> 1532 Click 1533 <menuchoice> 1534 <guimenu>Start</guimenu> 1535 <guimenuitem>Settings</guimenuitem> 1536 <guimenuitem>Control Panel</guimenuitem> 1537 <guimenuitem>Administrative Tools</guimenuitem> 1538 <guimenuitem>Computer Management</guimenuitem> 1539 </menuchoice>. 1540 </para></step> 1541 1542 <step><para> 1543 In the left panel, 1544 <menuchoice> 1545 <guimenu>[Right mouse menu item] Computer Management (Local)</guimenu> 1546 <guimenuitem>Connect to another computer ...</guimenuitem> 1547 <guimenuitem>Browse...</guimenuitem> 1548 <guimenuitem>Advanced</guimenuitem> 1549 <guimenuitem>Find Now</guimenuitem> 1550 </menuchoice>. In the lower panel, click on the name of the server you wish to 1551 administer. Click <menuchoice> 1552 <guimenu>OK</guimenu> 1553 <guimenuitem>OK</guimenuitem> 1554 <guimenuitem>OK</guimenuitem> 1555 </menuchoice>. 1556 In the left panel, the entry <guimenu>Computer Management (Local)</guimenu> should now reflect 1557 the change made. For example, if the server you are administering is called <constant>FRODO</constant>, 1558 the Computer Management entry should now say: <guimenu>Computer Management (FRODO)</guimenu>. 1559 </para></step> 1560 1561 <step><para> 1562 In the left panel, click <menuchoice> 1563 <guimenu>Computer Management (FRODO)</guimenu> 1564 <guimenuitem>[+] Shared Folders</guimenuitem> 1565 <guimenuitem>Shares</guimenuitem> 1566 </menuchoice>. 1567 </para></step> 1568 1569 <step><para><indexterm> 1570 <primary>Security</primary> 1571 </indexterm><indexterm> 1572 <primary>Properties</primary> 1573 </indexterm><indexterm> 1574 <primary>Permissions</primary> 1575 </indexterm><indexterm> 1576 <primary>Samba Domain server</primary> 1577 </indexterm> 1578 In the right panel, double-click on the share on which you wish to set/edit ACLs. This 1579 brings up the Properties panel. Click the <guimenu>Security</guimenu> tab. It is best 1580 to edit ACLs using the <constant>Advanced</constant> editing features. Click the 1581 <guimenu>Advanced</guimenu> button. This opens a panel that has four tabs. Only the 1582 functionality under the <constant>Permissions</constant> tab can be utilized with respect 1583 to a Samba domain server. 1584 </para></step> 1585 1586 <step><para><indexterm> 1587 <primary>access control</primary> 1588 </indexterm><indexterm> 1589 <primary>permitted group</primary> 1590 </indexterm> 1591 You may now edit/add/remove access control settings. Be very careful. Many problems have been 1592 created by people who decided that everyone should be rejected but one particular group should 1593 have full control. This is a catch-22 situation because members of that particular group also 1594 belong to the group <constant>Everyone</constant>, which therefore overrules any permissions 1595 set for the permitted group. 1596 </para></step> 1597 1598 <step><para> 1599 When you are done with editing, close all panels by clicking through the <guimenu>OK</guimenu> 1600 buttons until the last panel closes. 1601 </para></step> 1602 </procedure> 1603 1604 </sect3> 1605 1606 <sect3> 1607 <title>Using MS Windows Explorer (File Manager)</title> 1608 1609 <para> 1610 The following alternative method may be used from a Windows workstation. In this example we work 1611 with a domain called <constant>MEGANET</constant>, a server called <constant>MASSIVE</constant>, and a 1612 share called <constant>Apps</constant>. The underlying UNIX/Linux share point for this share is 1613 <filename>/data/apps</filename>. 1614 </para> 1615 1616 <procedure> 1617 <step><para> 1618 Click <menuchoice> 1619 <guimenu>Start</guimenu> 1620 <guimenuitem>[right-click] My Computer</guimenuitem> 1621 <guimenuitem>Explore</guimenuitem> 1622 <guimenuitem>[left panel] [+] My Network Places</guimenuitem> 1623 <guimenuitem>[+] Entire Network</guimenuitem> 1624 <guimenuitem>[+] Microsoft Windows Network</guimenuitem> 1625 <guimenuitem>[+] Meganet</guimenuitem> 1626 <guimenuitem>[+] Massive</guimenuitem> 1627 <guimenuitem>[right-click] Apps</guimenuitem> 1628 <guimenuitem>Properties</guimenuitem> 1629 <guimenuitem>Security</guimenuitem> 1630 <guimenuitem>Advanced</guimenuitem> 1631 </menuchoice>. This opens a panel that has four tabs. Only the functionality under the 1632 <constant>Permissions</constant> tab can be utilized for a Samba domain server. 1633 </para></step> 1634 1635 <step><para><indexterm> 1636 <primary>full control</primary> 1637 </indexterm><indexterm> 1638 <primary>over-rule</primary> 1639 </indexterm> 1640 You may now edit/add/remove access control settings. Be very careful. Many problems have been 1641 created by people who decided that everyone should be rejected but one particular group should 1642 have full control. This is a catch-22 situation because members of that particular group also 1643 belong to the group <constant>Everyone</constant>, which therefore overrules any permissions 1644 set for the permitted group. 1645 </para></step> 1646 1647 <step><para> 1648 When you are done with editing, close all panels by clicking through the <guimenu>OK</guimenu> 1649 buttons until the last panel closes. 1650 </para></step> 1651 </procedure> 1652 1653 </sect3> 1654 1655 <sect3> 1656 <title>Setting Posix ACLs in UNIX/Linux</title> 1657 1658 <para><indexterm> 1659 <primary>desired security setting</primary> 1660 </indexterm><indexterm> 1661 <primary>shared resource</primary> 1662 </indexterm> 1663 Yet another alternative method for setting desired security settings on the shared resource files and 1664 directories can be achieved by logging into UNIX/Linux and setting POSIX ACLs directly using command-line 1665 tools. Here is an example session on the same resource as in the immediately preceding example on a SUSE 9 1666 Linux system: 1667 </para> 1668 1669 <procedure> 1670 <step><para> 1671 Log into the Linux system as the user <constant>root</constant>. 1672 </para></step> 1673 1674 <step><para> 1675 Change directory to the location of the exported (shared) Windows file share (Apps), which is in 1676 the directory <filename>/data</filename>. Execute the following: 1677<screen> 1678&rootprompt; cd /data 1679</screen> 1680 Retrieve the existing POSIX ACLs entry by executing: 1681<screen> 1682&rootprompt; getfacl apps 1683# file: apps 1684# owner: root 1685# group: root 1686user::rwx 1687group::rwx 1688other::r-x 1689</screen> 1690 </para></step> 1691 1692 <step><para><indexterm> 1693 <primary>recursively</primary> 1694 </indexterm> 1695 You want to add permission for <constant>AppsMgrs</constant> to enable them to 1696 manage the applications (apps) share. It is important to set the ACL recursively 1697 so that the AppsMgrs have this capability throughout the directory tree that is 1698 being shared. This is done using the <constant>-R</constant> option as shown. 1699 Execute the following: 1700<screen> 1701&rootprompt; setfacl -m -R group:AppsMgrs:rwx /data/apps 1702</screen> 1703 Because setting an ACL does not provide a response, you immediately validate the command executed 1704 as follows: 1705<screen> 1706&rootprompt; getfacl /data/apps 1707# file: apps 1708# owner: root 1709# group: root 1710user::rwx 1711group::rwx 1712group:AppsMgrs:rwx 1713mask::rwx 1714other::r-x 1715</screen> 1716 This confirms that the change of POSIX ACL permissions has been effective. 1717 </para></step> 1718 1719 <step><para><indexterm> 1720 <primary>setfacl</primary> 1721 </indexterm><indexterm> 1722 <primary>getfacl</primary> 1723 </indexterm><indexterm> 1724 <primary>directory tree</primary> 1725 </indexterm><indexterm> 1726 <primary>Windows ACLs</primary> 1727 </indexterm><indexterm> 1728 <primary>inheritance</primary> 1729 </indexterm> 1730 It is highly recommended that you read the online manual page for the <command>setfacl</command> 1731 and <command>getfacl</command> commands. This provides information regarding how to set/read the default 1732 ACLs and how that may be propagated through the directory tree. In Windows ACLs terms, this is the equivalent 1733 of setting <constant>inheritance</constant> properties. 1734 </para></step> 1735 </procedure> 1736 1737 </sect3> 1738 1739 </sect2> 1740 1741 <sect2> 1742 <title>Key Points Learned</title> 1743 1744 <para> 1745 The mish-mash of issues were thrown together into one chapter because it seemed like a good idea. 1746 Looking back, this chapter could be broken into two, but it's too late now. It has been done. 1747 The highlights covered are as follows: 1748 </para> 1749 1750 <itemizedlist> 1751 <listitem><para><indexterm> 1752 <primary>Winbind</primary> 1753 </indexterm><indexterm> 1754 <primary>Active Directory</primary> 1755 </indexterm><indexterm> 1756 <primary>password change</primary> 1757 </indexterm><indexterm> 1758 <primary>logon hours</primary> 1759 </indexterm> 1760 Winbind honors and does not override account controls set in Active Directory. 1761 This means that password change, logon hours, and so on, are (or soon will be) enforced 1762 by Samba winbind. At this time, an out-of-hours login is denied and password 1763 change is enforced. At this time, if logon hours expire, the user is not forcibly 1764 logged off. That may be implemented at some later date. 1765 </para></listitem> 1766 1767 <listitem><para><indexterm> 1768 <primary>Sign'n'seal</primary> 1769 </indexterm><indexterm> 1770 <primary>schannel</primary> 1771 </indexterm> 1772 Sign'n'seal (plus schannel support) has been implemented in Samba-3. Beware of potential 1773 problems acknowledged by Microsoft as having been fixed but reported by some as still 1774 possibly an open issue. 1775 </para></listitem> 1776 1777 <listitem><para><indexterm> 1778 <primary>Kerberos</primary> 1779 </indexterm><indexterm> 1780 <primary>OpenLDAP</primary> 1781 </indexterm><indexterm> 1782 <primary>Active Directory</primary> 1783 </indexterm><indexterm> 1784 <primary>inter-operability</primary> 1785 </indexterm> 1786 The combination of Kerberos 5, plus OpenLDAP, plus Samba, cannot replace Microsoft 1787 Active Directory. The possibility to do this is not planned in the current Samba-3 1788 roadmap. Samba-3 does aim to provide further improvements in interoperability so that 1789 UNIX/Linux systems may be fully integrated into Active Directory domains. 1790 </para></listitem> 1791 1792 <listitem><para> 1793 This chapter reviewed mechanisms by which Samba servers may be kept secure. Each of 1794 the four key methodologies was reviewed with specific reference to example deployment 1795 techniques. 1796 </para></listitem> 1797 </itemizedlist> 1798 1799 </sect2> 1800 1801</sect1> 1802 1803<sect1> 1804 <title>Questions and Answers</title> 1805 1806 <para> 1807 </para> 1808 1809 <qandaset defaultlabel="chap10qa" type="number"> 1810 <qandaentry> 1811 <question> 1812 1813 <para><indexterm> 1814 <primary>Sign'n'seal</primary> 1815 </indexterm><indexterm> 1816 <primary>registry hacks</primary> 1817 </indexterm> 1818 Does Samba-3 require the <constant>Sign'n'seal</constant> registry hacks needed by Samba-2? 1819 </para> 1820 1821 </question> 1822 <answer> 1823 1824 <para><indexterm> 1825 <primary>schannel</primary> 1826 </indexterm><indexterm> 1827 <primary>Sign'n'seal</primary> 1828 </indexterm><indexterm> 1829 <primary>registry change</primary> 1830 </indexterm> 1831 No. Samba-3 fully supports <constant>Sign'n'seal</constant> as well as <constant>schannel</constant> 1832 operation. The registry change should not be applied when Samba-3 is used as a domain controller. 1833 </para> 1834 1835 </answer> 1836 </qandaentry> 1837 1838 <qandaentry> 1839 <question> 1840 1841 <para> 1842 Does Samba-3 support Active Directory? 1843 </para> 1844 1845 </question> 1846 <answer> 1847 1848 <para><indexterm> 1849 <primary>Active Directory</primary> 1850 </indexterm> 1851 Yes. Samba-3 can be a fully participating native mode Active Directory client. Samba-3 does not 1852 provide Active Directory services. It cannot be used to replace a Microsoft Active Directory 1853 server implementation. Samba-3 can function as an Active Directory client (workstation) toolkit, 1854 and it can function as an Active Directory domain member server. 1855 </para> 1856 1857 </answer> 1858 </qandaentry> 1859 1860 <qandaentry> 1861 <question> 1862 1863 <para><indexterm> 1864 <primary>mixed-mode</primary> 1865 </indexterm> 1866 When Samba-3 is used with Active Directory, is it necessary to run mixed-mode operation, as was 1867 necessary with Samba-2? 1868 </para> 1869 1870 </question> 1871 <answer> 1872 1873 <para><indexterm> 1874 <primary>native</primary> 1875 </indexterm> 1876 No. Samba-3 can be used with NetBIOS over TCP/IP disabled, just as can be done with Windows 200x 1877 Server and 200x/XPPro client products. It is no longer necessary to run mixed-mode operation, 1878 because Samba-3 can join a native Windows 2003 Server ADS domain. 1879 </para> 1880 1881 </answer> 1882 </qandaentry> 1883 1884 <qandaentry> 1885 <question> 1886 1887 <para><indexterm> 1888 <primary>share level access controls</primary> 1889 </indexterm> 1890 Is it safe to set share-level access controls in Samba? 1891 </para> 1892 1893 </question> 1894 <answer> 1895 1896 <para> 1897 Yes. Share-level access controls have been supported since early versions of Samba-2. This is 1898 very mature technology. Not enough sites make use of this powerful capability, neither on 1899 Windows server or with Samba servers. 1900 </para> 1901 1902 </answer> 1903 </qandaentry> 1904 1905 <qandaentry> 1906 <question> 1907 1908 <para><indexterm> 1909 <primary>share ACLs</primary> 1910 </indexterm> 1911 Is it mandatory to set share ACLs to get a secure Samba-3 server? 1912 </para> 1913 1914 </question> 1915 <answer> 1916 1917 <para><indexterm> 1918 <primary>file system security</primary> 1919 </indexterm><indexterm> 1920 <primary>Windows 200x ACLs</primary> 1921 </indexterm><indexterm> 1922 <primary>share definition controls</primary> 1923 </indexterm><indexterm> 1924 <primary>share level ACL</primary> 1925 </indexterm><indexterm> 1926 <primary>security</primary> 1927 </indexterm> 1928 No. Samba-3 honors UNIX/Linux file system security, supports Windows 200x ACLs, and provides 1929 means of securing shares through share definition controls in the &smb.conf; file. The additional 1930 support for share-level ACLs is like frosting on the cake. It adds to security but is not essential 1931 to it. 1932 </para> 1933 1934 </answer> 1935 </qandaentry> 1936 1937 <qandaentry> 1938 <question> 1939 1940 <para><indexterm> 1941 <primary>valid users</primary> 1942 </indexterm> 1943 The <parameter>valid users</parameter> did not work on the <smbconfsection name="[homes]"/>. 1944 Has this functionality been restored yet? 1945 </para> 1946 1947 </question> 1948 <answer> 1949 1950 <para><indexterm> 1951 <primary>meta-service</primary> 1952 </indexterm> 1953 Yes. This was fixed in Samba-3.0.2. The use of this parameter is strongly recommended as a safeguard 1954 on the <smbconfsection name="[homes]"/> meta-service. The correct way to specify this is: 1955 <smbconfoption name="valid users">%S</smbconfoption>. 1956 </para> 1957 1958 </answer> 1959 </qandaentry> 1960 1961 <qandaentry> 1962 <question> 1963 1964 <para><indexterm> 1965 <primary>force user</primary> 1966 </indexterm><indexterm> 1967 <primary>force group</primary> 1968 </indexterm><indexterm> 1969 <primary>bias</primary> 1970 </indexterm> 1971 Is the bias against use of the <parameter>force user</parameter> and <parameter>force group</parameter> 1972 really warranted? 1973 </para> 1974 1975 </question> 1976 <answer> 1977 1978 <para><indexterm> 1979 <primary>performance</primary> 1980 </indexterm> 1981 There is no bias. There is a determination to recommend the right tool for the task at hand. 1982 After all, it is better than putting users through performance problems, isn't it? 1983 </para> 1984 1985 </answer> 1986 </qandaentry> 1987 1988 <qandaentry> 1989 <question> 1990 1991 <para> 1992 The example given for file and directory access control forces all files to be owned by one 1993 particular user. I do not like that. Is there any way I can see who created the file? 1994 </para> 1995 1996 </question> 1997 <answer> 1998 1999 <para><indexterm> 2000 <primary>SUID</primary> 2001 </indexterm> 2002 Sure. You do not have to set the SUID bit on the directory. Simply execute the following command 2003 to permit file ownership to be retained by the user who created it: 2004<screen> 2005&rootprompt; find /usr/data/finance -type d -exec chmod g+s {}\; 2006</screen> 2007 Note that this required no more than removing the <constant>u</constant> argument so that the 2008 SUID bit is not set for the owner. 2009 </para> 2010 2011 </answer> 2012 </qandaentry> 2013 2014 <qandaentry> 2015 <question> 2016 2017 <para><indexterm> 2018 <primary>Computer Management</primary> 2019 </indexterm> 2020 In the book, <quote>The Official Samba-3 HOWTO and Reference Guide</quote>, you recommended use 2021 of the Windows NT4 Server Manager (part of the <filename>SRVTOOLS.EXE</filename>) utility. Why 2022 have you mentioned only the use of the Windows 200x/XP MMC Computer Management utility? 2023 </para> 2024 2025 </question> 2026 <answer> 2027 2028 <para><indexterm> 2029 <primary>MMC</primary> 2030 </indexterm><indexterm> 2031 <primary>SRVTOOLS.EXE</primary> 2032 </indexterm> 2033 Either tool can be used with equal effect. There is no benefit of one over the other, except that 2034 the MMC utility is present on all Windows 200x/XP systems and does not require additional software 2035 to be downloaded and installed. Note that if you want to manage user and group accounts in your 2036 Samba-controlled domain, the only tool that permits that is the NT4 Domain User Manager, which 2037 is provided as part of the <filename>SRVTOOLS.EXE</filename> utility. 2038 </para> 2039 2040 </answer> 2041 </qandaentry> 2042 2043 <qandaentry> 2044 <question> 2045 2046 <para><indexterm> 2047 <primary>valid users</primary> 2048 </indexterm><indexterm> 2049 <primary>Active Directory</primary> 2050 </indexterm><indexterm> 2051 <primary>Domain Member server</primary> 2052 </indexterm> 2053 I tried to set <parameter>valid users = @Engineers</parameter>, but it does not work. My Samba 2054 server is an Active Directory domain member server. Has this been fixed now? 2055 </para> 2056 2057 </question> 2058 <answer> 2059 2060 <para> 2061 The use of this parameter has always required the full specification of the domain account, for 2062 example, <parameter>valid users = @"MEGANET2\Domain Admins"</parameter>. 2063 </para> 2064 2065 </answer> 2066 </qandaentry> 2067 2068 </qandaset> 2069 2070</sect1> 2071 2072</chapter> 2073 2074