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="unixclients"> 4 <title>Adding Domain Member Servers and Clients</title> 5 6 <para><indexterm> 7 <primary>Open Magazine</primary> 8 </indexterm><indexterm> 9 <primary>survey</primary> 10 </indexterm> 11 The most frequently discussed Samba subjects over the past 2 years have focused around domain control and printing. 12 It is well known that Samba is a file and print server. A recent survey conducted by <emphasis>Open Magazine</emphasis> found 13 that of all respondents, 97 percent use Samba for file and print services, and 68 percent use Samba for Domain Control. See the 14 <ulink url="http://www.open-mag.com/cgi-bin/opencgi/surveys/survey.cgi?survey_name=samba">Open-Mag</ulink> 15 Web site for current information. The survey results as found on January 14, 2004, are shown in 16 <link linkend="ch09openmag"/>. 17 </para> 18 19 <figure id="ch09openmag"> 20 <title>Open Magazine Samba Survey</title> 21 <imagefile scale="60">openmag</imagefile> 22 </figure> 23 24 <para> 25 While domain control is an exciting subject, basic file and print sharing remains the staple bread-and-butter 26 function that Samba provides. Yet this book may give the appearance of having focused too much on more 27 exciting aspects of Samba deployment. This chapter directs your attention to provide important information on 28 the addition of Samba servers into your present Windows network &smbmdash; whatever the controlling technology 29 may be. So let's get back to our good friends at Abmas. 30 </para> 31 32<sect1> 33 <title>Introduction</title> 34 35 <para><indexterm> 36 <primary>Linux desktop</primary> 37 </indexterm><indexterm> 38 <primary>Domain Member</primary> 39 <secondary>server</secondary> 40 </indexterm> 41 Looking back over the achievements of the past year or two, daily events at Abmas are rather straightforward 42 with not too many distractions or problems. Your team is doing well, but a number of employees 43 are asking for Linux desktop systems. Your network has grown and demands additional domain member servers. Let's 44 get on with this; Christine and Stan are ready to go. 45 </para> 46 47 <para><indexterm> 48 <primary>Domain Member</primary> 49 <secondary>desktop</secondary> 50 </indexterm> 51 Stan is firmly in control of the department of the future, while Christine is enjoying a stable and 52 predictable network environment. It is time to add more servers and to add Linux desktops. It is 53 time to meet the demands of future growth and endure trial by fire. 54 </para> 55 56 <sect2> 57 <title>Assignment Tasks</title> 58 59 <para><indexterm> 60 <primary>Active Directory</primary> 61 </indexterm> 62 You must now add UNIX/Linux domain member servers to your network. You have a friend who has a Windows 2003 63 Active Directory domain network who wants to add a Samba/Linux server and has asked Christine to help him 64 out. Your real objective is to help Christine to see more of the way the Microsoft world lives and use 65 her help to get validation that Samba really does live up to expectations. 66 </para> 67 68 <para> 69 Over the past 6 months, you have hired several new staff who want Linux on their desktops. You must integrate 70 these systems to make sure that Abmas is not building islands of technology. You ask Christine to 71 do likewise at Swodniw Biz NL (your friend's company) to help them to evaluate a Linux desktop. You want to make 72 the right decision, don't you? 73 </para> 74 75 </sect2> 76</sect1> 77 78<sect1> 79 <title>Dissection and Discussion</title> 80 81 <para> 82 <indexterm><primary>winbind</primary></indexterm> 83 Recent Samba mailing-list activity is witness to how many sites are using winbind. Some have no trouble 84 at all with it, yet to others the problems seem insurmountable. Periodically there are complaints concerning 85 an inability to achieve identical user and group IDs between Windows and UNIX environments. 86 </para> 87 88 <para> 89 You provide step-by-step implementations of the various tools that can be used for identity 90 resolution. You also provide working examples of solutions for integrated authentication for 91 both UNIX/Linux and Windows environments. 92 </para> 93 94 <sect2> 95 <title>Technical Issues</title> 96 97 <para> 98 One of the great challenges we face when people ask us, <quote>What is the best way to solve 99 this problem?</quote> is to get beyond the facts so we not only can clearly comprehend 100 the immediate technical problem, but also can understand how needs may change. 101 </para> 102 103 <para> 104 <indexterm><primary>integrate</primary></indexterm> 105 There are a few facts we should note when dealing with the question of how best to 106 integrate UNIX/Linux clients and servers into a Windows networking environment: 107 </para> 108 109 <itemizedlist> 110 <listitem><para> 111 <indexterm><primary>Domain Controller</primary></indexterm> 112 <indexterm><primary>authoritative</primary></indexterm> 113 <indexterm><primary>accounts</primary><secondary>authoritative</secondary></indexterm> 114 <indexterm><primary>PDC</primary></indexterm> 115 <indexterm><primary>BDC</primary></indexterm> 116 A domain controller (PDC or BDC) is always authoritative for all accounts in its domain. 117 This means that a BDC must (of necessity) be able to resolve all account UIDs and GIDs 118 to the same values that the PDC resolved them to. 119 </para></listitem> 120 121 <listitem><para> 122 <indexterm><primary>local accounts</primary></indexterm> 123 <indexterm><primary>Domain Member</primary><secondary>authoritative</secondary><tertiary>local accounts</tertiary></indexterm> 124 <indexterm><primary>Domain accounts</primary></indexterm> 125 <indexterm><primary>winbindd</primary></indexterm> 126 A domain member can be authoritative for local accounts, but is never authoritative for 127 domain accounts. If a user is accessing a domain member server and that user's account 128 is not known locally, the domain member server must resolve the identity of that user 129 from the domain in which that user's account resides. It must then map that ID to a 130 UID/GID pair that it can use locally. This is handled by <command>winbindd</command>. 131 </para></listitem> 132 133 <listitem><para> 134 Samba, when running on a domain member server, can resolve user identities from a 135 number of sources: 136 </para> 137 138 <itemizedlist> 139 <listitem><para> 140 <indexterm><primary>getpwnam</primary></indexterm> 141 <indexterm><primary>getgrnam</primary></indexterm> 142 <indexterm><primary>NSS</primary></indexterm> 143 <indexterm><primary>LDAP</primary></indexterm> 144 <indexterm><primary>NIS</primary></indexterm> 145 By executing a system <command>getpwnam()</command> or <command>getgrnam()</command> call. 146 On systems that support it, this utilizes the name service switch (NSS) facility to 147 resolve names according to the configuration of the <filename>/etc/nsswitch.conf</filename> 148 file. NSS can be configured to use LDAP, winbind, NIS, or local files. 149 </para></listitem> 150 151 <listitem><para> 152 <indexterm><primary>passdb backend</primary></indexterm> 153 <indexterm><primary>PADL</primary></indexterm> 154 <indexterm><primary>nss_ldap</primary></indexterm> 155 Performing, via NSS, a direct LDAP search (where an LDAP passdb backend has been configured). 156 This requires the use of the PADL nss_ldap tool (or equivalent). 157 </para></listitem> 158 159 <listitem><para> 160 <indexterm><primary>winbindd</primary></indexterm> 161 <indexterm><primary>SID</primary></indexterm> 162 <indexterm><primary>winbindd_idmap.tdb</primary></indexterm> 163 <indexterm><primary>winbindd_cache.tdb</primary></indexterm> 164 Directly by querying <command>winbindd</command>. The <command>winbindd</command> 165 contacts a domain controller to attempt to resolve the identity of the user or group. It 166 receives the Windows networking security identifier (SID) for that appropriate 167 account and then allocates a local UID or GID from the range of available IDs and 168 creates an entry in its <filename>winbindd_idmap.tdb</filename> and 169 <filename>winbindd_cache.tdb</filename> files. 170 </para> 171 172 <para> 173 <indexterm><primary>idmap backend</primary></indexterm> 174 <indexterm><primary>mapping</primary></indexterm> 175 If the parameter <smbconfoption name="idmap backend">ldap:ldap://myserver.domain</smbconfoption> 176 was specified and the LDAP server has been configured with a container in which it may 177 store the IDMAP entries, all domain members may share a common mapping. 178 </para></listitem> 179 </itemizedlist> 180 181 <para> 182 Irrespective of how &smb.conf; is configured, winbind creates and caches a local copy of 183 the ID mapping database. It uses the <filename>winbindd_idmap.tdb</filename> and 184 <filename>winbindd_cache.tdb</filename> files to do this. 185 </para> 186 187 <para> 188 Which of the resolver methods is chosen is determined by the way that Samba is configured 189 in the &smb.conf; file. Some of the configuration options are rather less than obvious to the 190 casual user. 191 </para></listitem> 192 193 <listitem><para> 194 <indexterm><primary>winbind trusted domains only</primary></indexterm> 195 <indexterm><primary>domain member</primary><secondary>servers</secondary></indexterm> 196 <indexterm><primary>domain controllers</primary></indexterm> 197 If you wish to make use of accounts (users and/or groups) that are local to (i.e., capable 198 of being resolved using) the NSS facility, it is possible to use the 199 <smbconfoption name="winbind trusted domains only">Yes</smbconfoption> 200 in the &smb.conf; file. This parameter specifically applies to domain controllers, 201 and to domain member servers. 202 </para></listitem> 203 204 </itemizedlist> 205 206 <para> 207 <indexterm><primary>Posix accounts</primary></indexterm> 208 <indexterm><primary>Samba accounts</primary></indexterm> 209 <indexterm><primary>LDAP</primary></indexterm> 210 For many administrators, it should be plain that the use of an LDAP-based repository for all network 211 accounts (both for POSIX accounts and for Samba accounts) provides the most elegant and 212 controllable facility. You eventually appreciate the decision to use LDAP. 213 </para> 214 215 <para> 216 <indexterm><primary>nss_ldap</primary></indexterm> 217 <indexterm><primary>identifiers</primary></indexterm> 218 <indexterm><primary>resolve</primary></indexterm> 219 If your network account information resides in an LDAP repository, you should use it ahead of any 220 alternative method. This means that if it is humanly possible to use the <command>nss_ldap</command> 221 tools to resolve UNIX account UIDs/GIDs via LDAP, this is the preferred solution, because it provides 222 a more readily controllable method for asserting the exact same user and group identifiers 223 throughout the network. 224 </para> 225 226 <para> 227 <indexterm><primary>Domain Member</primary><secondary>server</secondary></indexterm> 228 <indexterm><primary>winbind trusted domains only</primary></indexterm> 229 <indexterm><primary>getpwnam</primary></indexterm> 230 <indexterm><primary>smbd</primary></indexterm> 231 <indexterm><primary>Trusted Domains</primary></indexterm> 232 <indexterm><primary>External Domains</primary></indexterm> 233 In the situation where UNIX accounts are held on the domain member server itself, the only effective 234 way to use them involves the &smb.conf; entry 235 <smbconfoption name="winbind trusted domains only">Yes</smbconfoption>. This forces 236 Samba (<command>smbd</command>) to perform a <command>getpwnam()</command> system call that can 237 then be controlled via <filename>/etc/nsswitch.conf</filename> file settings. The use of this parameter 238 disables the use of Samba with trusted domains (i.e., external domains). 239 </para> 240 241 <para> 242 <indexterm><primary>appliance mode</primary></indexterm> 243 <indexterm><primary>Domain Member</primary><secondary>server</secondary></indexterm> 244 <indexterm><primary>winbindd</primary></indexterm> 245 <indexterm><primary>automatically allocate</primary></indexterm> 246 Winbind can be used to create an appliance mode domain member server. In this capacity, <command>winbindd</command> 247 is configured to automatically allocate UIDs/GIDs from numeric ranges set in the &smb.conf; file. The allocation 248 is made for all accounts that connect to that domain member server, whether within its own domain or from 249 trusted domains. If not stored in an LDAP backend, each domain member maintains its own unique mapping database. 250 This means that it is almost certain that a given user who accesses two domain member servers does not have the 251 same UID/GID on both servers &smbmdash; however, this is transparent to the Windows network user. This data 252 is stored in the <filename>winbindd_idmap.tdb</filename> and <filename>winbindd_cache.tdb</filename> files. 253 </para> 254 255 <para> 256 <indexterm><primary>mapping</primary></indexterm> 257 The use of an LDAP backend for the Winbind IDMAP facility permits Windows domain SIDs 258 mappings to UIDs/GIDs to be stored centrally. The result is a consistent mapping across all domain member 259 servers so configured. This solves one of the major headaches for network administrators who need to copy 260 files between or across network file servers. 261 </para> 262 263 </sect2> 264 265 <sect2> 266 <title>Political Issues</title> 267 268 <para> 269 <indexterm><primary>OpenLDAP</primary></indexterm> 270 <indexterm><primary>NIS</primary></indexterm> 271 <indexterm><primary>yellow pages</primary><see>NIS</see></indexterm> 272 <indexterm><primary>identity management</primary></indexterm> 273 One of the most fierce conflicts recently being waged is resistance to the adoption of LDAP, in 274 particular OpenLDAP, as a replacement for UNIX NIS (previously called Yellow Pages). Let's face it, LDAP 275 is different and requires a new approach to the need for a better identity management solution. The more 276 you work with LDAP, the more its power and flexibility emerges from its dark, cavernous chasm. 277 </para> 278 279 <para> 280 LDAP is a most suitable solution for heterogenous environments. If you need crypto, add Kerberos. 281 The reason these are preferable is because they are heterogenous. Windows solutions of this sort are <emphasis>not</emphasis> 282 heterogenous by design. This is fundamental &smbmdash; it isn't religious or political. This also doesn't say that 283 you can't use Windows Active Directory in a heterogenous environment &smbmdash; it can be done, it just requires 284 commercial integration products. But it's not what Active Directory was designed for. 285 </para> 286 287 <para> 288 <indexterm><primary>directory</primary></indexterm> 289 <indexterm><primary>management</primary></indexterm> 290 A number of long-term UNIX devotees have recently commented in various communications that the Samba Team 291 is the first application group to almost force network administrators to use LDAP. It should be pointed 292 out that we resisted this for as long as we could. It is not out of laziness or malice that LDAP has 293 finally emerged as the preferred identity management backend for Samba. We recommend LDAP for your total 294 organizational directory needs. 295 </para> 296 297 </sect2> 298 299</sect1> 300 301<sect1> 302 <title>Implementation</title> 303 304 <para> 305 <indexterm><primary>Domain Member</primary><secondary>server</secondary></indexterm> 306 <indexterm><primary>Domain Member</primary><secondary>client</secondary></indexterm> 307 <indexterm><primary>Domain Controller</primary></indexterm> 308 The domain member server and the domain member client are at the center of focus in this chapter. 309 Configuration of Samba-3 domain controller is covered in earlier chapters, so if your 310 interest is in domain controller configuration, you will not find that here. You will find good 311 oil that helps you to add domain member servers and clients. 312 </para> 313 314 <para> 315 <indexterm><primary>Domain Member</primary><secondary>workstations</secondary></indexterm> 316 In practice, domain member servers and domain member workstations are very different entities, but in 317 terms of technology they share similar core infrastructure. A technologist would argue that servers 318 and workstations are identical. Many users would argue otherwise, given that in a well-disciplined 319 environment a workstation (client) is a device from which a user creates documents and files that 320 are located on servers. A workstation is frequently viewed as a disposable (easy to replace) item, 321 but a server is viewed as a core component of the business. 322 </para> 323 324 <para> 325 <indexterm><primary>workstation</primary></indexterm> 326 We can look at this another way. If a workstation breaks down, one user is affected, but if a 327 server breaks down, hundreds of users may not be able to work. The services that a workstation 328 must provide are document- and file-production oriented; a server provides information storage 329 and is distribution oriented. 330 </para> 331 332 <para> 333 <indexterm><primary>authentication process</primary></indexterm> 334 <indexterm><primary>logon process</primary></indexterm> 335 <indexterm><primary>user identities</primary></indexterm> 336 <emphasis>Why is this important?</emphasis> For starters, we must identify what 337 components of the operating system and its environment must be configured. Also, it is necessary 338 to recognize where the interdependencies between the various services to be used are. 339 In particular, it is important to understand the operation of each critical part of the 340 authentication process, the logon process, and how user identities get resolved and applied 341 within the operating system and applications (like Samba) that depend on this and may 342 actually contribute to it. 343 </para> 344 345 <para> 346 So, in this chapter we demonstrate how to implement the technology. It is done within a context of 347 what type of service need must be fulfilled. 348 </para> 349 350 <sect2 id="sdcsdmldap"> 351 <title>Samba Domain with Samba Domain Member Server &smbmdash; Using NSS LDAP</title> 352 353 <para> 354 <indexterm><primary>ldapsam</primary></indexterm> 355 <indexterm><primary>ldapsam backend</primary></indexterm> 356 <indexterm><primary>IDMAP</primary></indexterm> 357 <indexterm><primary>mapping</primary><secondary>consistent</secondary></indexterm> 358 <indexterm><primary>winbindd</primary></indexterm> 359 <indexterm><primary>foreign SID</primary></indexterm> 360 In this example, it is assumed that you have Samba PDC/BDC servers. This means you are using 361 an LDAP ldapsam backend. We are adding to the LDAP backend database (directory) 362 containers for use by the IDMAP facility. This makes it possible to have globally consistent 363 mapping of SIDs to and from UIDs and GIDs. This means that it is necessary to run 364 <command>winbindd</command> as part of your configuration. The primary purpose of running 365 <command>winbindd</command> (within this operational context) is to permit mapping of foreign 366 SIDs (those not originating from the the local Samba server). Foreign SIDs can come from any 367 domain member client or server, or from Windows clients that do not belong to a domain. Another 368 way to explain the necessity to run <command>winbindd</command> is that Samba can locally 369 resolve only accounts that belong to the security context of its own machine SID. Winbind 370 handles all non-local SIDs and maps them to a local UID/GID value. The UID and GID are allocated 371 from the parameter values set in the &smb.conf; file for the <parameter>idmap uid</parameter> and 372 <parameter>idmap gid</parameter> ranges. Where LDAP is used, the mappings can be stored in LDAP 373 so that all domain member servers can use a consistent mapping. 374 </para> 375 376 <para> 377 <indexterm><primary>winbindd</primary></indexterm> 378 <indexterm><primary>getpwnam</primary></indexterm> 379 <indexterm><primary>NSS</primary></indexterm> 380 If your installation is accessed only from clients that are members of your own domain, and all 381 user accounts are present in a local passdb backend then it is not necessary to run 382 <command>winbindd</command>. The local passdb backend can be in smbpasswd, tdbsam, or in ldapsam. 383 </para> 384 385 <para> 386 It is possible to use a local passdb backend with any convenient means of resolving the POSIX 387 user and group account information. The POSIX information is usually obtained using the 388 <command>getpwnam()</command> system call. On NSS-enabled systems, the actual POSIX account 389 source can be provided from 390 </para> 391 392 <itemizedlist> 393 <listitem><para> 394 <indexterm><primary>/etc/passwd</primary></indexterm> 395 <indexterm><primary>/etc/group</primary></indexterm> 396 Accounts in <filename>/etc/passwd</filename> or in <filename>/etc/group</filename>. 397 </para></listitem> 398 399 <listitem><para> 400 <indexterm><primary>NSS</primary></indexterm> 401 <indexterm><primary>compat</primary></indexterm> 402 <indexterm><primary>ldap</primary></indexterm> 403 <indexterm><primary>nis</primary></indexterm> 404 <indexterm><primary>nisplus</primary></indexterm> 405 <indexterm><primary>hesiod</primary></indexterm> 406 <indexterm><primary>ldap</primary></indexterm> 407 <indexterm><primary>nss_ldap</primary></indexterm> 408 <indexterm><primary>PADL Software</primary></indexterm> 409 Resolution via NSS. On NSS-enabled systems, there is usually a facility to resolve IDs 410 via multiple methods. The methods typically include <command>files</command>, 411 <command>compat</command>, <command>db</command>, <command>ldap</command>, 412 <command>nis</command>, <command>nisplus</command>, <command>hesiod.</command> When 413 correctly installed, Samba adds to this list the <command>winbindd</command> facility. 414 The ldap facility is frequently the nss_ldap tool provided by PADL Software. 415 </para></listitem> 416 </itemizedlist> 417 418 <note><para> 419 To advoid confusion the use of the term <literal>local passdb backend</literal> means that 420 the user account backend is not shared by any other Samba server &smbmdash; instead, it is 421 used only locally on the Samba domain member server under discussion. 422 </para></note> 423 424 <para> 425 <indexterm><primary>Identity resolution</primary></indexterm> 426 The diagram in <link linkend="ch9-sambadc"/> demonstrates the relationship of Samba and system 427 components that are involved in the identity resolution process where Samba is used as a domain 428 member server within a Samba domain control network. 429 </para> 430 431<figure id="ch9-sambadc"> 432 <title>Samba Domain: Samba Member Server</title> 433 <imagefile scale="60">chap9-SambaDC</imagefile> 434</figure> 435 436 <para> 437 <indexterm><primary>IDMAP</primary></indexterm> 438 <indexterm><primary>foreign</primary></indexterm> 439 In this example configuration, Samba will directly search the LDAP-based passwd backend ldapsam 440 to obtain authentication and user identity information. The IDMAP information is stored in the LDAP 441 backend so that it can be shared by all domain member servers so that every user will have a 442 consistent UID and GID across all of them. The IDMAP facility will be used for all foreign 443 (i.e., not having the same SID as the domain it is a member of) domains. The configuration of 444 NSS will ensure that all UNIX processes will obtain a consistent UID/GID. 445 </para> 446 447 <para> 448 The instructions given here apply to the Samba environment shown in <link linkend="happy"/> and <link linkend="net2000users"/>. 449 If the network does not have an LDAP slave server (i.e., <link linkend="happy"/> configuration), 450 change the target LDAP server from <constant>lapdc</constant> to <constant>massive.</constant> 451 </para> 452 453 <procedure> 454 <title>Configuration of NSS_LDAP-Based Identity Resolution</title> 455 456 <step><para> 457 Create the &smb.conf; file as shown in <link linkend="ch9-sdmsdc"/>. Locate 458 this file in the directory <filename>/etc/samba</filename>. 459 </para></step> 460 461 <step><para> 462 <indexterm><primary>ldap.conf</primary></indexterm> 463 Configure the file that will be used by <constant>nss_ldap</constant> to 464 locate and communicate with the LDAP server. This file is called <filename>ldap.conf</filename>. 465 If your implementation of <constant>nss_ldap</constant> is consistent with 466 the defaults suggested by PADL (the authors), it will be located in the 467 <filename>/etc</filename> directory. On some systems, the default location is 468 the <filename>/etc/openldap</filename> directory, however this file is intended 469 for use by the OpenLDAP utilities and should not really be used by the nss_ldap 470 utility since its content and structure serves the specific purpose of enabling 471 the resolution of user and group IDs via NSS. 472 </para> 473 474 <para> 475 Change the parameters inside the file that is located on your OS so it matches 476 <link linkend="ch9-sdmlcnf"/>. To find the correct location of this file, you 477 can obtain this from the library that will be used by executing the following: 478<screen> 479&rootprompt; strings /lib/libnss_ldap* | grep ldap.conf 480/etc/ldap.conf 481</screen> 482 </para></step> 483 484 <step><para> 485 Configure the NSS control file so it matches the one shown in 486 <link linkend="ch9-sdmnss"/>. 487 </para></step> 488 489 <step><para> 490 <indexterm><primary>Identity resolution</primary></indexterm> 491 <indexterm><primary>getent</primary></indexterm> 492 Before proceeding to configure Samba, validate the operation of the NSS identity 493 resolution via LDAP by executing: 494<screen> 495&rootprompt; getent passwd 496... 497root:x:0:512:Netbios Domain Administrator:/root:/bin/false 498nobody:x:999:514:nobody:/dev/null:/bin/false 499bobj:x:1000:513:Robert Jordan:/home/bobj:/bin/bash 500stans:x:1001:513:Stanley Soroka:/home/stans:/bin/bash 501chrisr:x:1002:513:Christine Roberson:/home/chrisr:/bin/bash 502maryv:x:1003:513:Mary Vortexis:/home/maryv:/bin/bash 503jht:x:1004:513:John H Terpstra:/home/jht:/bin/bash 504bldg1$:x:1006:553:bldg1$:/dev/null:/bin/false 505temptation$:x:1009:553:temptation$:/dev/null:/bin/false 506vaioboss$:x:1005:553:vaioboss$:/dev/null:/bin/false 507fran$:x:1008:553:fran$:/dev/null:/bin/false 508josephj:x:1007:513:Joseph James:/home/josephj:/bin/bash 509</screen> 510 You should notice the location of the users' home directories. First, make certain that 511 the home directories exist on the domain member server; otherwise, the home directory 512 share is not available. The home directories could be mounted off a domain controller 513 using NFS or by any other suitable means. Second, the absence of the domain name in the 514 home directory path is indicative that identity resolution is not being done via winbind. 515<screen> 516&rootprompt; getent group 517... 518Domain Admins:x:512:root,jht 519Domain Users:x:513:bobj,stans,chrisr,maryv,jht,josephj 520Domain Guests:x:514: 521Accounts:x:1000: 522Finances:x:1001: 523PIOps:x:1002: 524sammy:x:4321: 525</screen> 526 <indexterm><primary>secondary group</primary></indexterm> 527 <indexterm><primary>primary group</primary></indexterm> 528 <indexterm><primary>group membership</primary></indexterm> 529 This shows that all is working as it should be. Notice that in the LDAP database 530 the users' primary and secondary group memberships are identical. It is not 531 necessary to add secondary group memberships (in the group database) if the 532 user is already a member via primary group membership in the password database. 533 When using winbind, it is in fact undesirable to do this because it results in 534 doubling up of group memberships and may cause problems with winbind under certain 535 conditions. It is intended that these limitations with winbind will be resolved soon 536 after Samba-3.0.20 has been released. 537 </para></step> 538 539 <step><para> 540 <indexterm><primary>slapcat</primary></indexterm> 541 The LDAP directory must have a container object for IDMAP data. There are several ways you can 542 check that your LDAP database is able to receive IDMAP information. One of the simplest is to 543 execute: 544<screen> 545&rootprompt; slapcat | grep -i idmap 546dn: ou=Idmap,dc=abmas,dc=biz 547ou: idmap 548</screen> 549 <indexterm><primary>ldapadd</primary></indexterm> 550 If the execution of this command does not return IDMAP entries, you need to create an LDIF 551 template file (see <link linkend="ch9-ldifadd"/>). You can add the required entries using 552 the following command: 553<screen> 554&rootprompt; ldapadd -x -D "cn=Manager,dc=abmas,dc=biz" \ 555 -w not24get < /etc/openldap/idmap.LDIF 556</screen> 557 </para></step> 558 559 <step><para> 560 Samba automatically populates the LDAP directory container when it needs to. To permit Samba 561 write access to the LDAP directory it is necessary to set the LDAP administrative password 562 in the <filename>secrets.tdb</filename> file as shown here: 563<screen> 564&rootprompt; smbpasswd -w not24get 565</screen> 566 </para></step> 567 568 <step><para> 569 <indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>join</tertiary></indexterm> 570 <indexterm><primary>Domain join</primary></indexterm> 571 The system is ready to join the domain. Execute the following: 572<screen> 573&rootprompt; net rpc join -U root%not24get 574Joined domain MEGANET2. 575</screen> 576 This indicates that the domain join succeeded. 577 </para> 578 579 <para> 580 Failure to join the domain could be caused by any number of variables. The most common 581 causes of failure to join are: 582 </para> 583 584 <para> 585 <itemizedlist> 586 <listitem><para>Broken resolution of NetBIOS names to the respective IP address.</para></listitem> 587 <listitem><para>Incorrect username and password credentials.</para></listitem> 588 <listitem><para>The NT4 <parameter>restrict anonymous</parameter> is set to exclude anonymous 589 connections.</para></listitem> 590 </itemizedlist> 591 </para> 592 593 <para> 594 The connection setup can be diagnosed by executing: 595<screen> 596&rootprompt; net rpc join -S 'pdc-name' -U administrator%password -d 5 597</screen> 598 <indexterm><primary>failed</primary></indexterm> 599 <indexterm><primary>failed join</primary></indexterm> 600 <indexterm><primary>rejected</primary></indexterm> 601 <indexterm><primary>restrict anonymous</primary></indexterm> 602 Note: Use "root" for UNIX/Linux and Samba, use "Administrator" for Windows NT4/200X. If the cause of 603 the failure appears to be related to a rejected or failed NT_SESSION_SETUP* or an error message that 604 says NT_STATUS_ACCESS_DENIED immediately check the Windows registry setting that controls the 605 <constant>restrict anonymous</constant> setting. Set this to the value 0 so that an anonymous connection 606 can be sustained, then try again. 607 </para> 608 609 <para> 610 It is possible (perhaps even recommended) to use the following to validate the ability to connect 611 to an NT4 PDC/BDC: 612<screen> 613&rootprompt; net rpc info -S 'pdc-name' -U Administrator%not24get 614Domain Name: MEGANET2 615Domain SID: S-1-5-21-422319763-4138913805-7168186429 616Sequence number: 1519909596 617Num users: 7003 618Num domain groups: 821 619Num local groups: 8 620 621&rootprompt; net rpc testjoin -S 'pdc-name' -U Administrator%not24get 622Join to 'MEGANET2' is OK 623</screen> 624 If for any reason the following response is obtained to the last command above,it is time to 625 call in the Networking Super-Snooper task force (i.e., start debugging): 626<screen> 627NT_STATUS_ACCESS_DENIED 628Join to 'MEGANET2' failed. 629</screen> 630 </para></step> 631 632 <step><para> 633 <indexterm><primary>wbinfo</primary></indexterm> 634 Just joining the domain is not quite enough; you must now provide a privileged set 635 of credentials through which <command>winbindd</command> can interact with the 636 domain servers. Execute the following to implant the necessary credentials: 637<screen> 638&rootprompt; wbinfo --set-auth-user=Administrator%not24get 639</screen> 640 The configuration is now ready to obtain the Samba domain user and group information. 641 </para></step> 642 643 <step><para> 644 You may now start Samba in the usual manner, and your Samba domain member server 645 is ready for use. Just add shares as required. 646 </para></step> 647 648 </procedure> 649 650<example id="ch9-sdmsdc"> 651<title>Samba Domain Member in Samba Domain Using LDAP &smbmdash; &smb.conf; File</title> 652<smbconfblock> 653<smbconfcomment>Global parameters</smbconfcomment> 654<smbconfsection name="[global]"/> 655<smbconfoption name="unix charset">LOCALE</smbconfoption> 656<smbconfoption name="workgroup">MEGANET2</smbconfoption> 657<smbconfoption name="security">DOMAIN</smbconfoption> 658<smbconfoption name="username map">/etc/samba/smbusers</smbconfoption> 659<smbconfoption name="log level">10</smbconfoption> 660<smbconfoption name="syslog">0</smbconfoption> 661<smbconfoption name="log file">/var/log/samba/%m</smbconfoption> 662<smbconfoption name="max log size">50</smbconfoption> 663<smbconfoption name="smb ports">139</smbconfoption> 664<smbconfoption name="name resolve order">wins bcast hosts</smbconfoption> 665<smbconfoption name="printcap name">CUPS</smbconfoption> 666<smbconfoption name="wins server">192.168.2.1</smbconfoption> 667<smbconfoption name="ldap suffix">dc=abmas,dc=biz</smbconfoption> 668<smbconfoption name="ldap machine suffix">ou=People</smbconfoption> 669<smbconfoption name="ldap user suffix">ou=People</smbconfoption> 670<smbconfoption name="ldap group suffix">ou=Groups</smbconfoption> 671<smbconfoption name="ldap idmap suffix">ou=Idmap</smbconfoption> 672<smbconfoption name="ldap admin dn">cn=Manager,dc=abmas,dc=biz</smbconfoption> 673<smbconfoption name="idmap backend">ldap:ldap://lapdc.abmas.biz</smbconfoption> 674<smbconfoption name="idmap uid">10000-20000</smbconfoption> 675<smbconfoption name="idmap gid">10000-20000</smbconfoption> 676<smbconfoption name="winbind trusted domains only">Yes</smbconfoption> 677<smbconfoption name="printer admin">root</smbconfoption> 678<smbconfoption name="printing">cups</smbconfoption> 679 680<smbconfsection name="[homes]"/> 681<smbconfoption name="comment">Home Directories</smbconfoption> 682<smbconfoption name="valid users">%S</smbconfoption> 683<smbconfoption name="read only">No</smbconfoption> 684<smbconfoption name="browseable">No</smbconfoption> 685 686<smbconfsection name="[printers]"/> 687<smbconfoption name="comment">SMB Print Spool</smbconfoption> 688<smbconfoption name="path">/var/spool/samba</smbconfoption> 689<smbconfoption name="guest ok">Yes</smbconfoption> 690<smbconfoption name="printable">Yes</smbconfoption> 691<smbconfoption name="browseable">No</smbconfoption> 692 693<smbconfsection name="[print$]"/> 694<smbconfoption name="comment">Printer Drivers</smbconfoption> 695<smbconfoption name="path">/var/lib/samba/drivers</smbconfoption> 696<smbconfoption name="admin users">root, Administrator</smbconfoption> 697<smbconfoption name="write list">root</smbconfoption> 698</smbconfblock> 699</example> 700 701<example id="ch9-ldifadd"> 702<title>LDIF IDMAP Add-On Load File &smbmdash; File: /etc/openldap/idmap.LDIF</title> 703<screen> 704dn: ou=Idmap,dc=abmas,dc=biz 705objectClass: organizationalUnit 706ou: idmap 707structuralObjectClass: organizationalUnit 708</screen> 709</example> 710 711<example id="ch9-sdmlcnf"> 712<title>Configuration File for NSS LDAP Support &smbmdash; <filename>/etc/ldap.conf</filename></title> 713<screen> 714URI ldap://massive.abmas.biz ldap://massive.abmas.biz:636 715host 192.168.2.1 716base dc=abmas,dc=biz 717binddn cn=Manager,dc=abmas,dc=biz 718bindpw not24get 719 720pam_password exop 721 722nss_base_passwd ou=People,dc=abmas,dc=biz?one 723nss_base_shadow ou=People,dc=abmas,dc=biz?one 724nss_base_group ou=Groups,dc=abmas,dc=biz?one 725ssl no 726</screen> 727</example> 728 729<example id="ch9-sdmnss"> 730<title>NSS using LDAP for Identity Resolution &smbmdash; File: <filename>/etc/nsswitch.conf</filename></title> 731<screen> 732passwd: files ldap 733shadow: files ldap 734group: files ldap 735 736hosts: files dns wins 737networks: files dns 738 739services: files 740protocols: files 741rpc: files 742ethers: files 743netmasks: files 744netgroup: files 745publickey: files 746 747bootparams: files 748automount: files 749aliases: files 750</screen> 751</example> 752 753 </sect2> 754 755 <sect2 id="wdcsdm"> 756 <title>NT4/Samba Domain with Samba Domain Member Server: Using NSS and Winbind</title> 757 758 <para> 759 You need to use this method for creating a Samba domain member server if any of the following conditions 760 prevail: 761 </para> 762 763 <itemizedlist> 764 <listitem><para> 765 LDAP support (client) is not installed on the system. 766 </para></listitem> 767 768 <listitem><para> 769 There are mitigating circumstances forcing a decision not to use LDAP. 770 </para></listitem> 771 772 <listitem><para> 773 The Samba domain member server must be part of a Windows NT4 Domain, or a Samba Domain. 774 </para></listitem> 775 </itemizedlist> 776 777 <para> 778 <indexterm><primary>Windows ADS Domain</primary></indexterm> 779 <indexterm><primary>Samba Domain</primary></indexterm> 780 <indexterm><primary>LDAP</primary></indexterm> 781 Later in the chapter, you can see how to configure a Samba domain member server for a Windows ADS domain. 782 Right now your objective is to configure a Samba server that can be a member of a Windows NT4-style 783 domain and/or does not use LDAP. 784 </para> 785 786 <note><para> 787 <indexterm><primary>duplicate accounts</primary></indexterm> 788 If you use <command>winbind</command> for identity resolution, make sure that there are no 789 duplicate accounts. 790 </para> 791 792 <para> 793 <indexterm><primary>/etc/passwd</primary></indexterm> 794 For example, do not have more than one account that has UID=0 in the password database. If there 795 is an account called <constant>root</constant> in the <filename>/etc/passwd</filename> database, 796 it is okay to have an account called <constant>root</constant> in the LDAP ldapsam or in the 797 tdbsam. But if there are two accounts in the passdb backend that have the same UID, winbind will 798 break. This means that the <constant>Administrator</constant> account must be called 799 <constant>root</constant>. 800 </para> 801 802 <para> 803 <indexterm><primary>/etc/passwd</primary></indexterm> 804 <indexterm><primary>ldapsam</primary></indexterm> 805 <indexterm><primary>tdbsam</primary></indexterm> 806 Winbind will break if there is an account in <filename>/etc/passwd</filename> that has 807 the same UID as an account that is in LDAP ldapsam (or in tdbsam) but that differs in name only. 808 </para></note> 809 810 <para> 811 <indexterm><primary>credentials</primary></indexterm> 812 <indexterm><primary>traverse</primary></indexterm> 813 <indexterm><primary>wide-area</primary></indexterm> 814 <indexterm><primary>network</primary><secondary>wide-area</secondary></indexterm> 815 <indexterm><primary>tdbdump</primary></indexterm> 816 The following configuration uses CIFS/SMB protocols alone to obtain user and group credentials. 817 The winbind information is locally cached in the <filename>winbindd_cache.tdb winbindd_idmap.tdb</filename> 818 files. This provides considerable performance benefits compared with the LDAP solution, particularly 819 where the LDAP lookups must traverse WAN links. You may examine the contents of these 820 files using the tool <command>tdbdump</command>, though you may have to build this from the Samba 821 source code if it has not been supplied as part of a binary package distribution that you may be using. 822 </para> 823 824 <procedure> 825 <title>Configuration of Winbind-Based Identity Resolution</title> 826 827 <step><para> 828 Using your favorite text editor, create the &smb.conf; file so it has the contents 829 shown in <link linkend="ch0-NT4DSDM"/>. 830 </para></step> 831 832 <step><para> 833 <indexterm><primary>/etc/nsswitch.conf</primary></indexterm> 834 Edit the <filename>/etc/nsswitch.conf</filename> so it has the entries shown in 835 <link linkend="ch9-sdmnss"/>. 836 </para></step> 837 838 <step><para> 839 <indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>join</tertiary></indexterm> 840 The system is ready to join the domain. Execute the following: 841<screen> 842net rpc join -U root%not2g4et 843Joined domain MEGANET2. 844</screen> 845 This indicates that the domain join succeed. 846 847 </para></step> 848 849 <step><para> 850 <indexterm><primary>winbind</primary></indexterm> 851 <indexterm><primary>wbinfo</primary></indexterm> 852 Validate operation of <command>winbind</command> using the <command>wbinfo</command> 853 tool as follows: 854<screen> 855&rootprompt; wbinfo -u 856MEGANET2+root 857MEGANET2+nobody 858MEGANET2+jht 859MEGANET2+maryv 860MEGANET2+billr 861MEGANET2+jelliott 862MEGANET2+dbrady 863MEGANET2+joeg 864MEGANET2+balap 865</screen> 866 This shows that domain users have been listed correctly. 867<screen> 868&rootprompt; wbinfo -g 869MEGANET2+Domain Admins 870MEGANET2+Domain Users 871MEGANET2+Domain Guests 872MEGANET2+Accounts 873MEGANET2+Finances 874MEGANET2+PIOps 875</screen> 876 This shows that domain groups have been correctly obtained also. 877 </para></step> 878 879 <step><para> 880 <indexterm><primary>NSS</primary></indexterm> 881 <indexterm><primary>getent</primary></indexterm> 882 <indexterm><primary>winbind</primary></indexterm> 883 The next step verifies that NSS is able to obtain this information 884 correctly from <command>winbind</command> also. 885<screen> 886&rootprompt; getent passwd 887... 888MEGANET2+root:x:10000:10001:NetBIOS Domain Admin: 889 /home/MEGANET2/root:/bin/bash 890MEGANET2+nobody:x:10001:10001:nobody: 891 /home/MEGANET2/nobody:/bin/bash 892MEGANET2+jht:x:10002:10001:John H Terpstra: 893 /home/MEGANET2/jht:/bin/bash 894MEGANET2+maryv:x:10003:10001:Mary Vortexis: 895 /home/MEGANET2/maryv:/bin/bash 896MEGANET2+billr:x:10004:10001:William Randalph: 897 /home/MEGANET2/billr:/bin/bash 898MEGANET2+jelliott:x:10005:10001:John G Elliott: 899 /home/MEGANET2/jelliott:/bin/bash 900MEGANET2+dbrady:x:10006:10001:Darren Brady: 901 /home/MEGANET2/dbrady:/bin/bash 902MEGANET2+joeg:x:10007:10001:Joe Green: 903 /home/MEGANET2/joeg:/bin/bash 904MEGANET2+balap:x:10008:10001:Bala Pillay: 905 /home/MEGANET2/balap:/bin/bash 906</screen> 907 The user account information has been correctly obtained. This information has 908 been merged with the winbind template information configured in the &smb.conf; file. 909<screen> 910&rootprompt;# getent group 911... 912MEGANET2+Domain Admins:x:10000:MEGANET2+root,MEGANET2+jht 913MEGANET2+Domain Users:x:10001:MEGANET2+jht,MEGANET2+maryv,\ 914 MEGANET2+billr,MEGANET2+jelliott,MEGANET2+dbrady,\ 915 MEGANET2+joeg,MEGANET2+balap 916MEGANET2+Domain Guests:x:10002:MEGANET2+nobody 917MEGANET2+Accounts:x:10003: 918MEGANET2+Finances:x:10004: 919MEGANET2+PIOps:x:10005: 920</screen> 921 </para></step> 922 923 <step><para> 924 The Samba member server of a Windows NT4 domain is ready for use. 925 </para></step> 926 927 </procedure> 928 929<example id="ch0-NT4DSDM"> 930<title>Samba Domain Member Server Using Winbind &smb.conf; File for NT4 Domain</title> 931<smbconfblock> 932<smbconfcomment>Global parameters</smbconfcomment> 933<smbconfsection name="[global]"/> 934<smbconfoption name="unix charset">LOCALE</smbconfoption> 935<smbconfoption name="workgroup">MEGANET2</smbconfoption> 936<smbconfoption name="security">DOMAIN</smbconfoption> 937<smbconfoption name="username map">/etc/samba/smbusers</smbconfoption> 938<smbconfoption name="log level">1</smbconfoption> 939<smbconfoption name="syslog">0</smbconfoption> 940<smbconfoption name="log file">/var/log/samba/%m</smbconfoption> 941<smbconfoption name="max log size">0</smbconfoption> 942<smbconfoption name="smb ports">139</smbconfoption> 943<smbconfoption name="name resolve order">wins bcast hosts</smbconfoption> 944<smbconfoption name="printcap name">CUPS</smbconfoption> 945<smbconfoption name="wins server">192.168.2.1</smbconfoption> 946<smbconfoption name="idmap uid">10000-20000</smbconfoption> 947<smbconfoption name="idmap gid">10000-20000</smbconfoption> 948<smbconfoption name="template primary group">"Domain Users"</smbconfoption> 949<smbconfoption name="template shell">/bin/bash</smbconfoption> 950<smbconfoption name="winbind separator">+</smbconfoption> 951<smbconfoption name="printer admin">root</smbconfoption> 952<smbconfoption name="hosts allow">192.168.2., 192.168.3., 127.</smbconfoption> 953<smbconfoption name="printing">cups</smbconfoption> 954 955<smbconfsection name="[homes]"/> 956<smbconfoption name="comment">Home Directories</smbconfoption> 957<smbconfoption name="valid users">%S</smbconfoption> 958<smbconfoption name="read only">No</smbconfoption> 959<smbconfoption name="browseable">No</smbconfoption> 960 961<smbconfsection name="[printers]"/> 962<smbconfoption name="comment">SMB Print Spool</smbconfoption> 963<smbconfoption name="path">/var/spool/samba</smbconfoption> 964<smbconfoption name="guest ok">Yes</smbconfoption> 965<smbconfoption name="printable">Yes</smbconfoption> 966<smbconfoption name="browseable">No</smbconfoption> 967 968<smbconfsection name="[print$]"/> 969<smbconfoption name="comment">Printer Drivers</smbconfoption> 970<smbconfoption name="path">/var/lib/samba/drivers</smbconfoption> 971<smbconfoption name="admin users">root, Administrator</smbconfoption> 972<smbconfoption name="write list">root</smbconfoption> 973</smbconfblock> 974</example> 975 976 </sect2> 977 978 <sect2 id="dcwonss"> 979 <title>NT4/Samba Domain with Samba Domain Member Server without NSS Support</title> 980 981 <para> 982 No matter how many UNIX/Linux administrators there may be who believe that a UNIX operating 983 system that does not have NSS and PAM support to be outdated, the fact is there 984 are still many such systems in use today. Samba can be used without NSS support, but this 985 does limit it to the use of local user and group accounts only. 986 </para> 987 988 <para> 989 The following steps may be followed to implement Samba with support for local accounts. 990 In this configuration Samba is made a domain member server. All incoming connections 991 to the Samba server will cause the look-up of the incoming username. If the account 992 is found, it is used. If the account is not found, one will be automatically created 993 on the local machine so that it can then be used for all access controls. 994 </para> 995 996 <procedure> 997 <title>Configuration Using Local Accounts Only</title> 998 999 <step><para> 1000 Using your favorite text editor, create the &smb.conf; file so it has the contents 1001 shown in <link linkend="ch0-NT4DSCM"/>. 1002 </para></step> 1003 1004 <step> 1005 <para><indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>join</tertiary></indexterm> 1006 The system is ready to join the domain. Execute the following: 1007<screen> 1008net rpc join -U root%not24get 1009Joined domain MEGANET2. 1010</screen> 1011 This indicates that the domain join succeed. 1012 </para></step> 1013 1014 <step><para> 1015 Be sure to run all three Samba daemons: <command>smbd</command>, <command>nmbd</command>, <command>winbindd</command>. 1016 </para></step> 1017 1018 <step><para> 1019 The Samba member server of a Windows NT4 domain is ready for use. 1020 </para></step> 1021 </procedure> 1022 1023<example id="ch0-NT4DSCM"> 1024<title>Samba Domain Member Server Using Local Accounts &smb.conf; File for NT4 Domain</title> 1025<smbconfblock> 1026<smbconfcomment>Global parameters</smbconfcomment> 1027<smbconfsection name="[global]"/> 1028<smbconfoption name="unix charset">LOCALE</smbconfoption> 1029<smbconfoption name="workgroup">MEGANET3</smbconfoption> 1030<smbconfoption name="netbios name">BSDBOX</smbconfoption> 1031<smbconfoption name="security">DOMAIN</smbconfoption> 1032<smbconfoption name="username map">/etc/samba/smbusers</smbconfoption> 1033<smbconfoption name="log level">1</smbconfoption> 1034<smbconfoption name="syslog">0</smbconfoption> 1035<smbconfoption name="add user script">/usr/sbin/useradd -m '%u'</smbconfoption> 1036<smbconfoption name="add machine script">/usr/sbin/useradd -M '%u'</smbconfoption> 1037<smbconfoption name="add group script">/usr/sbin/groupadd '%g'</smbconfoption> 1038<smbconfoption name="log file">/var/log/samba/%m</smbconfoption> 1039<smbconfoption name="max log size">0</smbconfoption> 1040<smbconfoption name="smb ports">139</smbconfoption> 1041<smbconfoption name="name resolve order">wins bcast hosts</smbconfoption> 1042<smbconfoption name="printcap name">CUPS</smbconfoption> 1043<smbconfoption name="wins server">192.168.2.1</smbconfoption> 1044<smbconfoption name="printer admin">root</smbconfoption> 1045<smbconfoption name="hosts allow">192.168.2., 192.168.3., 127.</smbconfoption> 1046<smbconfoption name="printing">cups</smbconfoption> 1047 1048<smbconfsection name="[homes]"/> 1049<smbconfoption name="comment">Home Directories</smbconfoption> 1050<smbconfoption name="valid users">%S</smbconfoption> 1051<smbconfoption name="read only">No</smbconfoption> 1052<smbconfoption name="browseable">No</smbconfoption> 1053 1054<smbconfsection name="[printers]"/> 1055<smbconfoption name="comment">SMB Print Spool</smbconfoption> 1056<smbconfoption name="path">/var/spool/samba</smbconfoption> 1057<smbconfoption name="guest ok">Yes</smbconfoption> 1058<smbconfoption name="printable">Yes</smbconfoption> 1059<smbconfoption name="browseable">No</smbconfoption> 1060 1061<smbconfsection name="[print$]"/> 1062<smbconfoption name="comment">Printer Drivers</smbconfoption> 1063<smbconfoption name="path">/var/lib/samba/drivers</smbconfoption> 1064<smbconfoption name="admin users">root, Administrator</smbconfoption> 1065<smbconfoption name="write list">root</smbconfoption> 1066</smbconfblock> 1067</example> 1068 </sect2> 1069 1070 <sect2 id="adssdm"> 1071 <title>Active Directory Domain with Samba Domain Member Server</title> 1072 1073 <para> 1074 <indexterm><primary>Active Directory</primary><secondary>join</secondary></indexterm> 1075 <indexterm><primary>Kerberos</primary></indexterm> 1076 <indexterm><primary>Domain Member</primary><secondary>server</secondary></indexterm> 1077 One of the much-sought-after features new to Samba-3 is the ability to join an Active Directory 1078 domain using Kerberos protocols. This makes it possible to operate an entire Windows network 1079 without the need to run NetBIOS over TCP/IP and permits more secure networking in general. An 1080 exhaustively complete discussion of the protocols is not possible in this book; perhaps a 1081 later book may explore the intricacies of the NetBIOS-less operation that Samba-3 can participate 1082 in. For now, we simply focus on how a Samba-3 server can be made a domain member server. 1083 </para> 1084 1085 <para> 1086 <indexterm><primary>Active Directory</primary></indexterm> 1087 <indexterm><primary>LDAP</primary></indexterm> 1088 <indexterm><primary>Identity resolution</primary></indexterm> 1089 <indexterm><primary>Kerberos</primary></indexterm> 1090 The diagram in <link linkend="ch9-adsdc"/> demonstrates how Samba-3 interfaces with 1091 Microsoft Active Directory components. It should be noted that if Microsoft Windows Services 1092 for UNIX (SFU) has been installed and correctly configured, it is possible to use client LDAP 1093 for identity resolution just as can be done with Samba-3 when using an LDAP passdb backend. 1094 The UNIX tool that you need for this, as in the case of LDAP on UNIX/Linux, is the PADL 1095 Software nss_ldap tool-set. Compared with use of winbind and Kerberos, the use of 1096 LDAP-based identity resolution is a little less secure. In view of the fact that this solution 1097 requires additional software to be installed on the Windows 200x ADS domain controllers, 1098 and that means more management overhead, it is likely that most Samba-3 ADS client sites 1099 may elect to use winbind. 1100 </para> 1101 1102 <para> 1103 Do not attempt to use this procedure if you are not 100 percent certain that the build of Samba-3 1104 you are using has been compiled and linked with all the tools necessary for this to work. 1105 Given the importance of this step, you must first validate that the Samba-3 message block 1106 daemon (<command>smbd</command>) has the necessary features. 1107 </para> 1108 1109 <para> 1110 The hypothetical domain you are using in this example assumes that the Abmas London office 1111 decided to take its own lead (some would say this is a typical behavior in a global 1112 corporate world; besides, a little divergence and conflict makes for an interesting life). 1113 The Windows Server 2003 ADS domain is called <constant>london.abmas.biz</constant> and the 1114 name of the server is <constant>W2K3S</constant>. In ADS realm terms, the domain controller 1115 is known as <constant>w2k3s.london.abmas.biz</constant>. In NetBIOS nomenclature, the 1116 domain name is <constant>LONDON</constant> and the server name is <constant>W2K3S</constant>. 1117 </para> 1118 1119 <figure id="ch9-adsdc"> 1120 <title>Active Directory Domain: Samba Member Server</title> 1121 <imagefile scale="60">chap9-ADSDC</imagefile> 1122 </figure> 1123 1124 <procedure> 1125 <title>Joining a Samba Server as an ADS Domain Member</title> 1126 1127 <step><para> 1128 <indexterm><primary>smbd</primary></indexterm> 1129 Before you try to use Samba-3, you want to know for certain that your executables have 1130 support for Kerberos and for LDAP. Execute the following to identify whether or 1131 not this build is perhaps suitable for use: 1132<screen> 1133&rootprompt; cd /usr/sbin 1134&rootprompt; smbd -b | grep KRB 1135 HAVE_KRB5_H 1136 HAVE_ADDR_TYPE_IN_KRB5_ADDRESS 1137 HAVE_KRB5 1138 HAVE_KRB5_AUTH_CON_SETKEY 1139 HAVE_KRB5_GET_DEFAULT_IN_TKT_ETYPES 1140 HAVE_KRB5_GET_PW_SALT 1141 HAVE_KRB5_KEYBLOCK_KEYVALUE 1142 HAVE_KRB5_KEYTAB_ENTRY_KEYBLOCK 1143 HAVE_KRB5_MK_REQ_EXTENDED 1144 HAVE_KRB5_PRINCIPAL_GET_COMP_STRING 1145 HAVE_KRB5_SET_DEFAULT_IN_TKT_ETYPES 1146 HAVE_KRB5_STRING_TO_KEY 1147 HAVE_KRB5_STRING_TO_KEY_SALT 1148 HAVE_LIBKRB5 1149</screen> 1150 This output was obtained on a SUSE Linux system and shows the output for 1151 Samba that has been compiled and linked with the Heimdal Kerberos libraries. 1152 The following is a typical output that will be found on a Red Hat Linux system that 1153 has been linked with the MIT Kerberos libraries: 1154<screen> 1155&rootprompt; cd /usr/sbin 1156&rootprompt; smbd -b | grep KRB 1157 HAVE_KRB5_H 1158 HAVE_ADDRTYPE_IN_KRB5_ADDRESS 1159 HAVE_KRB5 1160 HAVE_KRB5_AUTH_CON_SETUSERUSERKEY 1161 HAVE_KRB5_ENCRYPT_DATA 1162 HAVE_KRB5_FREE_DATA_CONTENTS 1163 HAVE_KRB5_FREE_KTYPES 1164 HAVE_KRB5_GET_PERMITTED_ENCTYPES 1165 HAVE_KRB5_KEYTAB_ENTRY_KEY 1166 HAVE_KRB5_LOCATE_KDC 1167 HAVE_KRB5_MK_REQ_EXTENDED 1168 HAVE_KRB5_PRINCIPAL2SALT 1169 HAVE_KRB5_PRINC_COMPONENT 1170 HAVE_KRB5_SET_DEFAULT_TGS_KTYPES 1171 HAVE_KRB5_SET_REAL_TIME 1172 HAVE_KRB5_STRING_TO_KEY 1173 HAVE_KRB5_TKT_ENC_PART2 1174 HAVE_KRB5_USE_ENCTYPE 1175 HAVE_LIBGSSAPI_KRB5 1176 HAVE_LIBKRB5 1177</screen> 1178 You can validate that Samba has been compiled and linked with LDAP support 1179 by executing: 1180<screen> 1181&rootprompt; smbd -b | grep LDAP 1182massive:/usr/sbin # smbd -b | grep LDAP 1183 HAVE_LDAP_H 1184 HAVE_LDAP 1185 HAVE_LDAP_DOMAIN2HOSTLIST 1186 HAVE_LDAP_INIT 1187 HAVE_LDAP_INITIALIZE 1188 HAVE_LDAP_SET_REBIND_PROC 1189 HAVE_LIBLDAP 1190 LDAP_SET_REBIND_PROC_ARGS 1191</screen> 1192 This does look promising; <command>smbd</command> has been built with Kerberos and LDAP 1193 support. You are relieved to know that it is safe to progress. 1194 </para></step> 1195 1196 <step><para> 1197 <indexterm><primary>Kerberos</primary><secondary>libraries</secondary></indexterm> 1198 <indexterm><primary>MIT Kerberos</primary></indexterm> 1199 <indexterm><primary>Heimdal Kerberos</primary></indexterm> 1200 <indexterm><primary>Kerberos</primary><secondary>MIT</secondary></indexterm> 1201 <indexterm><primary>Kerberos</primary><secondary>Heimdal</secondary></indexterm> 1202 <indexterm><primary>Red Hat Linux</primary></indexterm> 1203 <indexterm><primary>SUSE Linux</primary></indexterm> 1204 <indexterm><primary>SerNet</primary></indexterm> 1205 <indexterm><primary>validated</primary></indexterm> 1206 The next step is to identify which version of the Kerberos libraries have been used. 1207 In order to permit Samba-3 to interoperate with Windows 2003 Active Directory, it is 1208 essential that it has been linked with either MIT Kerberos version 1.3.1 or later, 1209 or that it has been linked with Heimdal Kerberos 0.6 plus specific patches. You may 1210 identify what version of the MIT Kerberos libraries are installed on your system by 1211 executing (on Red Hat Linux): 1212<screen> 1213&rootprompt; rpm -q krb5 1214</screen> 1215 Or on SUSE Linux, execute: 1216<screen> 1217&rootprompt; rpm -q heimdal 1218</screen> 1219 Please note that the RPMs provided by the Samba-Team are known to be working and have 1220 been validated. Red Hat Linux RPMs may be obtained from the Samba FTP sites. SUSE 1221 Linux RPMs may be obtained from <ulink url="ftp://ftp.sernet.de">Sernet</ulink> in 1222 Germany. 1223 </para> 1224 1225 <para> 1226 From this point on, you are certain that the Samba-3 build you are using has the 1227 necessary capabilities. You can now configure Samba-3 and the NSS. 1228 </para></step> 1229 1230 <step><para> 1231 Using you favorite editor, configure the &smb.conf; file that is located in the 1232 <filename>/etc/samba</filename> directory so that it has the contents shown 1233 in <link linkend="ch9-adssdm"/>. 1234 </para></step> 1235 1236 <step><para> 1237 Edit or create the NSS control file so it has the contents shown in <link linkend="ch9-sdmnss"/>. 1238 </para></step> 1239 1240 <step><para> 1241 <indexterm><primary>/etc/samba/secrets.tdb</primary></indexterm> 1242 Delete the file <filename>/etc/samba/secrets.tdb</filename> if it exists. Of course, you 1243 do keep a backup, don't you? 1244 </para></step> 1245 1246 <step><para> 1247 Delete the tdb files that cache Samba information. You keep a backup of the old 1248 files, of course. You also remove all files to ensure that nothing can pollute your 1249 nice, new configuration. Execute the following (example is for SUSE Linux): 1250<screen> 1251&rootprompt; rm /var/lib/samba/*tdb 1252</screen> 1253 </para></step> 1254 1255 <step><para> 1256 <indexterm><primary>testparm</primary></indexterm> 1257 Validate your &smb.conf; file using <command>testparm</command> (as you have 1258 done previously). Correct all errors reported before proceeding. The command you 1259 execute is: 1260<screen> 1261&rootprompt; testparm -s | less 1262</screen> 1263 Now that you are satisfied that your Samba server is ready to join the Windows 1264 ADS domain, let's move on. 1265 </para></step> 1266 1267 <step><para> 1268 <indexterm><primary>net</primary><secondary>ads</secondary><tertiary>join</tertiary></indexterm> 1269 <indexterm><primary>Kerberos</primary></indexterm> 1270 This is a good time to double-check everything and then execute the following 1271 command when everything you have done has checked out okay: 1272<screen> 1273&rootprompt; net ads join -UAdministrator%not24get 1274Using short domain name -- LONDON 1275Joined 'FRAN' to realm 'LONDON.ABMAS.BIZ' 1276</screen> 1277 You have successfully made your Samba-3 server a member of the ADS domain 1278 using Kerberos protocols. 1279 </para> 1280 1281 <para> 1282 <indexterm><primary>silent return</primary></indexterm> 1283 <indexterm><primary>failed join</primary></indexterm> 1284 In the event that you receive no output messages, a silent return means that the 1285 domain join failed. You should use <command>ethereal</command> to identify what 1286 may be failing. Common causes of a failed join include: 1287 1288 <itemizedlist> 1289 <listitem><para> 1290 <indexterm><primary>name resolution</primary><secondary>Defective</secondary></indexterm> 1291 Defective or misconfigured DNS name resolution. 1292 </para></listitem> 1293 1294 <listitem><para> 1295 <indexterm><primary>Restrictive security</primary></indexterm> 1296 Restrictive security settings on the Windows 200x ADS domain controller 1297 preventing needed communications protocols. You can check this by searching 1298 the Windows Server 200x Event Viewer. 1299 </para></listitem> 1300 1301 <listitem><para> 1302 Incorrectly configured &smb.conf; file settings. 1303 </para></listitem> 1304 1305 <listitem><para> 1306 Lack of support of necessary Kerberos protocols because the version of MIT 1307 Kerberos (or Heimdal) in use is not up to date enough to support the necessary 1308 functionality. 1309 </para></listitem> 1310 </itemizedlist> 1311 1312 <indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>join</tertiary></indexterm> 1313 <indexterm><primary>RPC</primary></indexterm> 1314 <indexterm><primary>mixed mode</primary></indexterm> 1315 In any case, never execute the <command>net rpc join</command> command in an attempt 1316 to join the Samba server to the domain, unless you wish not to use the Kerberos 1317 security protocols. Use of the older RPC-based domain join facility requires that 1318 Windows Server 200x ADS has been configured appropriately for mixed mode operation. 1319 </para></step> 1320 1321 <step><para> 1322 <indexterm><primary>tdbdump</primary></indexterm> 1323 <indexterm><primary>/etc/samba/secrets.tdb</primary></indexterm> 1324 If the <command>tdbdump</command> is installed on your system (not essential), 1325 you can look inside the <filename>/etc/samba/secrets.tdb</filename> file. If 1326 you wish to do this, execute: 1327<screen> 1328&rootprompt; tdbdump secrets.tdb 1329{ 1330key = "SECRETS/SID/LONDON" 1331data = "\01\04\00\00\00\00\00\05\15\00\00\00\EBw\86\F1\ED\BD\ 1332 F6{\5C6\E5W\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\ 1333 00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\ 1334 00\00\00\00\00\00\00\00" 1335} 1336{ 1337key = "SECRETS/MACHINE_PASSWORD/LONDON" 1338data = "le3Q5FPnN5.ueC\00" 1339} 1340{ 1341key = "SECRETS/MACHINE_SEC_CHANNEL_TYPE/LONDON" 1342data = "\02\00\00\00" 1343} 1344{ 1345key = "SECRETS/MACHINE_LAST_CHANGE_TIME/LONDON" 1346data = "E\89\F6?" 1347} 1348</screen> 1349 This is given to demonstrate to the skeptics that this process truly does work. 1350 </para></step> 1351 1352 <step><para> 1353 It is now time to start Samba in the usual way (as has been done many time before 1354 in this book). 1355 </para></step> 1356 1357 <step><para> 1358 <indexterm><primary>wbinfo</primary></indexterm> 1359 This is a good time to verify that everything is working. First, check that 1360 winbind is able to obtain the list of users and groups from the ADS domain controller. 1361 Execute the following: 1362<screen> 1363&rootprompt; wbinfo -u 1364LONDON+Administrator 1365LONDON+Guest 1366LONDON+SUPPORT_388945a0 1367LONDON+krbtgt 1368LONDON+jht 1369</screen> 1370 Good, the list of users was obtained. Now do likewise for group accounts: 1371<screen> 1372&rootprompt; wbinfo -g 1373LONDON+Domain Computers 1374LONDON+Domain Controllers 1375LONDON+Schema Admins 1376LONDON+Enterprise Admins 1377LONDON+Domain Admins 1378LONDON+Domain Users 1379LONDON+Domain Guests 1380LONDON+Group Policy Creator Owners 1381LONDON+DnsUpdateProxy 1382</screen> 1383 Excellent. That worked also, as expected. 1384 </para></step> 1385 1386 <step><para><indexterm> 1387 <primary>getent</primary> 1388 </indexterm> 1389 Now repeat this via NSS to validate that full identity resolution is 1390 functional as required. Execute: 1391<screen> 1392&rootprompt; getent passwd 1393... 1394LONDON+Administrator:x:10000:10000:Administrator: 1395 /home/LONDON/administrator:/bin/bash 1396LONDON+Guest:x:10001:10001:Guest: 1397 /home/LONDON/guest:/bin/bash 1398LONDON+SUPPORT_388945a0:x:10002:10000:SUPPORT_388945a0: 1399 /home/LONDON/support_388945a0:/bin/bash 1400LONDON+krbtgt:x:10003:10000:krbtgt: 1401 /home/LONDON/krbtgt:/bin/bash 1402LONDON+jht:x:10004:10000:John H. Terpstra: 1403 /home/LONDON/jht:/bin/bash 1404</screen> 1405 Okay, ADS user accounts are being resolved. Now you try group resolution: 1406<screen> 1407&rootprompt; getent group 1408... 1409LONDON+Domain Computers:x:10002: 1410LONDON+Domain Controllers:x:10003: 1411LONDON+Schema Admins:x:10004:LONDON+Administrator 1412LONDON+Enterprise Admins:x:10005:LONDON+Administrator 1413LONDON+Domain Admins:x:10006:LONDON+jht,LONDON+Administrator 1414LONDON+Domain Users:x:10000: 1415LONDON+Domain Guests:x:10001: 1416LONDON+Group Policy Creator Owners:x:10007:LONDON+Administrator 1417LONDON+DnsUpdateProxy:x:10008: 1418</screen> 1419 This is very pleasing. Everything works as expected. 1420 </para></step> 1421 1422 <step><para> 1423 <indexterm><primary>net</primary><secondary>ads</secondary><tertiary>info</tertiary></indexterm> 1424 <indexterm><primary>Active Directory</primary><secondary>server</secondary></indexterm> 1425 <indexterm><primary>Kerberos</primary></indexterm> 1426 You may now perform final verification that communications between Samba-3 winbind and 1427 the Active Directory server is using Kerberos protocols. Execute the following: 1428<screen> 1429&rootprompt; net ads info 1430LDAP server: 192.168.2.123 1431LDAP server name: w2k3s 1432Realm: LONDON.ABMAS.BIZ 1433Bind Path: dc=LONDON,dc=ABMAS,dc=BIZ 1434LDAP port: 389 1435Server time: Sat, 03 Jan 2004 02:44:44 GMT 1436KDC server: 192.168.2.123 1437Server time offset: 2 1438</screen> 1439 It should be noted that Kerberos protocols are time-clock critical. You should 1440 keep all server time clocks synchronized using the network time protocol (NTP). 1441 In any case, the output we obtained confirms that all systems are operational. 1442 </para></step> 1443 1444 <step><para> 1445 <indexterm><primary>net</primary><secondary>ads</secondary><tertiary>status</tertiary></indexterm> 1446 There is one more action you elect to take, just because you are paranoid and disbelieving, 1447 so you execute the following command: 1448<programlisting> 1449&rootprompt; net ads status -UAdministrator%not24get 1450objectClass: top 1451objectClass: person 1452objectClass: organizationalPerson 1453objectClass: user 1454objectClass: computer 1455cn: fran 1456distinguishedName: CN=fran,CN=Computers,DC=london,DC=abmas,DC=biz 1457instanceType: 4 1458whenCreated: 20040103092006.0Z 1459whenChanged: 20040103092006.0Z 1460uSNCreated: 28713 1461uSNChanged: 28717 1462name: fran 1463objectGUID: 58f89519-c467-49b9-acb0-f099d73696e 1464userAccountControl: 69632 1465badPwdCount: 0 1466codePage: 0 1467countryCode: 0 1468badPasswordTime: 0 1469lastLogoff: 0 1470lastLogon: 127175965783327936 1471localPolicyFlags: 0 1472pwdLastSet: 127175952062598496 1473primaryGroupID: 515 1474objectSid: S-1-5-21-4052121579-2079768045-1474639452-1109 1475accountExpires: 9223372036854775807 1476logonCount: 13 1477sAMAccountName: fran$ 1478sAMAccountType: 805306369 1479operatingSystem: Samba 1480operatingSystemVersion: 3.0.20-SUSE 1481dNSHostName: fran 1482userPrincipalName: HOST/fran@LONDON.ABMAS.BIZ 1483servicePrincipalName: CIFS/fran.london.abmas.biz 1484servicePrincipalName: CIFS/fran 1485servicePrincipalName: HOST/fran.london.abmas.biz 1486servicePrincipalName: HOST/fran 1487objectCategory: CN=Computer,CN=Schema,CN=Configuration, 1488 DC=london,DC=abmas,DC=biz 1489isCriticalSystemObject: FALSE 1490-------------- Security Descriptor (revision: 1, type: 0x8c14) 1491owner SID: S-1-5-21-4052121579-2079768045-1474639452-512 1492group SID: S-1-5-21-4052121579-2079768045-1474639452-513 1493------- (system) ACL (revision: 4, size: 120, number of ACEs: 2) 1494------- ACE (type: 0x07, flags: 0x5a, size: 0x38, 1495 mask: 0x20, object flags: 0x3) 1496access SID: S-1-1-0 1497access type: AUDIT OBJECT 1498Permissions: 1499 [Write All Properties] 1500------- ACE (type: 0x07, flags: 0x5a, size: 0x38, 1501 mask: 0x20, object flags: 0x3) 1502access SID: S-1-1-0 1503access type: AUDIT OBJECT 1504Permissions: 1505 [Write All Properties] 1506------- (user) ACL (revision: 4, size: 1944, number of ACEs: 40) 1507------- ACE (type: 0x00, flags: 0x00, size: 0x24, mask: 0xf01ff) 1508access SID: S-1-5-21-4052121579-2079768045-1474639452-512 1509access type: ALLOWED 1510Permissions: [Full Control] 1511------- ACE (type: 0x00, flags: 0x00, size: 0x18, mask: 0xf01ff) 1512access SID: S-1-5-32-548 1513... 1514------- ACE (type: 0x05, flags: 0x12, size: 0x38, 1515 mask: 0x10, object flags: 0x3) 1516access SID: S-1-5-9 1517access type: ALLOWED OBJECT 1518Permissions: 1519 [Read All Properties] 1520-------------- End Of Security Descriptor 1521</programlisting> 1522 And now you have conclusive proof that your Samba-3 ADS domain member server 1523 called <constant>FRAN</constant> is able to communicate fully with the ADS 1524 domain controllers. 1525 </para></step> 1526 1527 </procedure> 1528 1529 1530 <para> 1531 Your Samba-3 ADS domain member server is ready for use. During training sessions, 1532 you may be asked what is inside the <filename>winbindd_cache.tdb and winbindd_idmap.tdb</filename> 1533 files. Since curiosity just took hold of you, execute the following: 1534<programlisting> 1535&rootprompt; tdbdump /var/lib/samba/winbindd_idmap.tdb 1536{ 1537key = "S-1-5-21-4052121579-2079768045-1474639452-501\00" 1538data = "UID 10001\00" 1539} 1540{ 1541key = "UID 10005\00" 1542data = "S-1-5-21-4052121579-2079768045-1474639452-1111\00" 1543} 1544{ 1545key = "GID 10004\00" 1546data = "S-1-5-21-4052121579-2079768045-1474639452-518\00" 1547} 1548{ 1549key = "S-1-5-21-4052121579-2079768045-1474639452-502\00" 1550data = "UID 10003\00" 1551} 1552... 1553 1554&rootprompt; tdbdump /var/lib/samba/winbindd_cache.tdb 1555{ 1556key = "UL/LONDON" 1557data = "\00\00\00\00bp\00\00\06\00\00\00\0DAdministrator\0D 1558 Administrator-S-1-5-21-4052121579-2079768045-1474639452-500- 1559 S-1-5-21-4052121579-2079768045-1474639452-513\05Guest\05 1560 Guest-S-1-5-21-4052121579-2079768045-1474639452-501- 1561 S-1-5-21-4052121579-2079768045-1474639452-514\10 1562 SUPPORT_388945a0\10SUPPORT_388945a0. 1563 S-1-5-21-4052121579-2079768045-1474639452-1001- 1564 S-1-5-21-4052121579-2079768045-1474639452-513\06krbtgt\06 1565 krbtgt-S-1-5-21-4052121579-2079768045-1474639452-502- 1566 S-1-5-21-4052121579-2079768045-1474639452-513\03jht\10 1567 John H. Terpstra.S-1-5-21-4052121579-2079768045-1474639452-1110- 1568 S-1-5-21-4052121579-2079768045-1474639452-513" 1569} 1570{ 1571key = "GM/S-1-5-21-4052121579-2079768045-1474639452-512" 1572data = "\00\00\00\00bp\00\00\02\00\00\00. 1573 S-1-5-21-4052121579-2079768045-1474639452-1110\03 1574 jht\01\00\00\00-S-1-5-21-4052121579-2079768045-1474639452-500\0D 1575 Administrator\01\00\00\00" 1576} 1577{ 1578key = "SN/S-1-5-21-4052121579-2079768045-1474639452-513" 1579data = "\00\00\00\00xp\00\00\02\00\00\00\0CDomain Users" 1580} 1581{ 1582key = "GM/S-1-5-21-4052121579-2079768045-1474639452-518" 1583data = "\00\00\00\00bp\00\00\01\00\00\00- 1584 S-1-5-21-4052121579-2079768045-1474639452-500\0D 1585 Administrator\01\00\00\00" 1586} 1587{ 1588key = "SEQNUM/LONDON\00" 1589data = "xp\00\00C\92\F6?" 1590} 1591{ 1592key = "U/S-1-5-21-4052121579-2079768045-1474639452-1110" 1593data = "\00\00\00\00xp\00\00\03jht\10John H. Terpstra. 1594 S-1-5-21-4052121579-2079768045-1474639452-1110- 1595 S-1-5-21-4052121579-2079768045-1474639452-513" 1596} 1597{ 1598key = "NS/S-1-5-21-4052121579-2079768045-1474639452-502" 1599data = "\00\00\00\00bp\00\00- 1600 S-1-5-21-4052121579-2079768045-1474639452-502" 1601} 1602{ 1603key = "SN/S-1-5-21-4052121579-2079768045-1474639452-1001" 1604data = "\00\00\00\00bp\00\00\01\00\00\00\10SUPPORT_388945a0" 1605} 1606{ 1607key = "SN/S-1-5-21-4052121579-2079768045-1474639452-500" 1608data = "\00\00\00\00bp\00\00\01\00\00\00\0DAdministrator" 1609} 1610{ 1611key = "U/S-1-5-21-4052121579-2079768045-1474639452-502" 1612data = "\00\00\00\00bp\00\00\06krbtgt\06krbtgt- 1613 S-1-5-21-4052121579-2079768045-1474639452-502- 1614 S-1-5-21-4052121579-2079768045-1474639452-513" 1615} 1616.... 1617</programlisting> 1618 Now all is revealed. Your curiosity, as well as that of your team, has been put at ease. 1619 May this server serve well all who happen upon it. 1620 </para> 1621 1622<example id="ch9-adssdm"> 1623<title>Samba Domain Member &smb.conf; File for Active Directory Membership</title> 1624<smbconfblock> 1625<smbconfcomment>Global parameters</smbconfcomment> 1626<smbconfsection name="[global]"/> 1627<smbconfoption name="unix charset">LOCALE</smbconfoption> 1628<smbconfoption name="workgroup">LONDON</smbconfoption> 1629<smbconfoption name="realm">LONDON.ABMAS.BIZ</smbconfoption> 1630<smbconfoption name="server string">Samba 3.0.20</smbconfoption> 1631<smbconfoption name="security">ADS</smbconfoption> 1632<smbconfoption name="username map">/etc/samba/smbusers</smbconfoption> 1633<smbconfoption name="log level">1</smbconfoption> 1634<smbconfoption name="syslog">0</smbconfoption> 1635<smbconfoption name="log file">/var/log/samba/%m</smbconfoption> 1636<smbconfoption name="max log size">50</smbconfoption> 1637<smbconfoption name="printcap name">CUPS</smbconfoption> 1638<smbconfoption name="ldap ssl">no</smbconfoption> 1639<smbconfoption name="idmap uid">10000-20000</smbconfoption> 1640<smbconfoption name="idmap gid">10000-20000</smbconfoption> 1641<smbconfoption name="template primary group">"Domain Users"</smbconfoption> 1642<smbconfoption name="template shell">/bin/bash</smbconfoption> 1643<smbconfoption name="winbind separator">+</smbconfoption> 1644<smbconfoption name="printing">cups</smbconfoption> 1645 1646<smbconfsection name="[homes]"/> 1647<smbconfoption name="comment">Home Directories</smbconfoption> 1648<smbconfoption name="valid users">%S</smbconfoption> 1649<smbconfoption name="read only">No</smbconfoption> 1650<smbconfoption name="browseable">No</smbconfoption> 1651 1652<smbconfsection name="[printers]"/> 1653<smbconfoption name="comment">SMB Print Spool</smbconfoption> 1654<smbconfoption name="path">/var/spool/samba</smbconfoption> 1655<smbconfoption name="guest ok">Yes</smbconfoption> 1656<smbconfoption name="printable">Yes</smbconfoption> 1657<smbconfoption name="browseable">No</smbconfoption> 1658 1659<smbconfsection name="[print$]"/> 1660<smbconfoption name="comment">Printer Drivers</smbconfoption> 1661<smbconfoption name="path">/var/lib/samba/drivers</smbconfoption> 1662<smbconfoption name="admin users">root, Administrator</smbconfoption> 1663<smbconfoption name="write list">root</smbconfoption> 1664</smbconfblock> 1665</example> 1666 1667 <sect3> 1668 <title>IDMAP_RID with Winbind</title> 1669 1670 <para> 1671 <indexterm><primary>idmap_rid</primary></indexterm> 1672 <indexterm><primary>SID</primary></indexterm> 1673 <indexterm><primary>RID</primary></indexterm> 1674 <indexterm><primary>IDMAP</primary></indexterm> 1675 The <command>idmap_rid</command> facility is a new tool that, unlike native winbind, creates a 1676 predictable mapping of MS Windows SIDs to UNIX UIDs and GIDs. The key benefit of this method 1677 of implementing the Samba IDMAP facility is that it eliminates the need to store the IDMAP data 1678 in a central place. The downside is that it can be used only within a single ADS domain and 1679 is not compatible with trusted domain implementations. 1680 </para> 1681 1682 <para> 1683 <indexterm><primary>SID</primary></indexterm> 1684 <indexterm><primary>allow trusted domains</primary></indexterm> 1685 <indexterm><primary>idmap uid</primary></indexterm> 1686 <indexterm><primary>idmap gid</primary></indexterm> 1687 This alternate method of SID to UID/GID mapping can be achieved with the idmap_rid 1688 plug-in. This plug-in uses the RID of the user SID to derive the UID and GID by adding the 1689 RID to a base value specified. This utility requires that the parameter 1690 <quote>allow trusted domains = No</quote> must be specified, as it is not compatible 1691 with multiple domain environments. The <parameter>idmap uid</parameter> and 1692 <parameter>idmap gid</parameter> ranges must be specified. 1693 </para> 1694 1695 <para> 1696 <indexterm><primary>idmap_rid</primary></indexterm> 1697 <indexterm><primary>realm</primary></indexterm> 1698 The idmap_rid facility can be used both for NT4/Samba-style domains as well as with Active Directory. 1699 To use this with an NT4 domain, the <parameter>realm</parameter> is not used. Additionally the 1700 method used to join the domain uses the <constant>net rpc join</constant> process. 1701 </para> 1702 1703 <para> 1704 An example &smb.conf; file for an ADS domain environment is shown in <link linkend="sbe-idmapridex"/>. 1705 </para> 1706 1707<example id="sbe-idmapridex"> 1708<title>Example &smb.conf; File Using <constant>idmap_rid</constant></title> 1709<smbconfblock> 1710<smbconfcomment>Global parameters</smbconfcomment> 1711<smbconfsection name="[global]"/> 1712<smbconfoption name="workgroup">KPAK</smbconfoption> 1713<smbconfoption name="netbios name">BIGJOE</smbconfoption> 1714<smbconfoption name="realm">CORP.KPAK.COM</smbconfoption> 1715<smbconfoption name="server string">Office Server</smbconfoption> 1716<smbconfoption name="security">ADS</smbconfoption> 1717<smbconfoption name="allow trusted domains">No</smbconfoption> 1718<smbconfoption name="idmap backend">idmap_rid:KPAK=500-100000000</smbconfoption> 1719<smbconfoption name="idmap uid">500-100000000</smbconfoption> 1720<smbconfoption name="idmap gid">500-100000000</smbconfoption> 1721<smbconfoption name="template shell">/bin/bash</smbconfoption> 1722<smbconfoption name="winbind use default domain">Yes</smbconfoption> 1723<smbconfoption name="winbind enum users">No</smbconfoption> 1724<smbconfoption name="winbind enum groups">No</smbconfoption> 1725<smbconfoption name="winbind nested groups">Yes</smbconfoption> 1726<smbconfoption name="printer admin">"KPAK\Domain Admins"</smbconfoption> 1727</smbconfblock> 1728</example> 1729 1730 <para> 1731 <indexterm><primary>large domain</primary></indexterm> 1732 <indexterm><primary>Active Directory</primary></indexterm> 1733 <indexterm><primary>response</primary></indexterm> 1734 <indexterm><primary>getent</primary></indexterm> 1735 In a large domain with many users, it is imperative to disable enumeration of users and groups. 1736 For example, at a site that has 22,000 users in Active Directory the winbind-based user and 1737 group resolution is unavailable for nearly 12 minutes following first start-up of 1738 <command>winbind</command>. Disabling of such enumeration results in instantaneous response. 1739 The disabling of user and group enumeration means that it will not be possible to list users 1740 or groups using the <command>getent passwd</command> and <command>getent group</command> 1741 commands. It will be possible to perform the lookup for individual users, as shown in the procedure 1742 below. 1743 </para> 1744 1745 <para> 1746 <indexterm><primary>NSS</primary></indexterm> 1747 <indexterm><primary>/etc/nsswitch.conf</primary></indexterm> 1748 The use of this tool requires configuration of NSS as per the native use of winbind. Edit the 1749 <filename>/etc/nsswitch.conf</filename> so it has the following parameters: 1750<screen> 1751... 1752passwd: files winbind 1753shadow: files winbind 1754group: files winbind 1755... 1756hosts: files wins 1757... 1758</screen> 1759 </para> 1760 1761 <para> 1762 The following procedure can be used to utilize the idmap_rid facility: 1763 </para> 1764 1765 <procedure> 1766 <step><para> 1767 Create or install and &smb.conf; file with the above configuration. 1768 </para></step> 1769 1770 <step><para> 1771 Edit the <filename>/etc/nsswitch.conf</filename> file as shown above. 1772 </para></step> 1773 1774 <step><para> 1775 Execute: 1776<screen> 1777&rootprompt; net ads join -UAdministrator%password 1778Using short domain name -- KPAK 1779Joined 'BIGJOE' to realm 'CORP.KPAK.COM' 1780</screen> 1781 </para> 1782 1783 <para> 1784 <indexterm><primary>failed join</primary></indexterm> 1785 An invalid or failed join can be detected by executing: 1786<screen> 1787&rootprompt; net ads testjoin 1788BIGJOE$@'s password: 1789[2004/11/05 16:53:03, 0] utils/net_ads.c:ads_startup(186) 1790 ads_connect: No results returned 1791Join to domain is not valid 1792</screen> 1793 The specific error message may differ from the above because it depends on the type of failure that 1794 may have occurred. Increase the <parameter>log level</parameter> to 10, repeat the above test, 1795 and then examine the log files produced to identify the nature of the failure. 1796 </para></step> 1797 1798 <step><para> 1799 Start the <command>nmbd</command>, <command>winbind,</command> and <command>smbd</command> daemons in the order shown. 1800 </para></step> 1801 1802 <step><para> 1803 Validate the operation of this configuration by executing: 1804 <indexterm><primary></primary></indexterm> 1805<screen> 1806&rootprompt; getent passwd administrator 1807administrator:x:1000:1013:Administrator:/home/BE/administrator:/bin/bash 1808</screen> 1809 </para></step> 1810 </procedure> 1811 1812 </sect3> 1813 1814 <sect3> 1815 <title>IDMAP Storage in LDAP using Winbind</title> 1816 1817 <para> 1818 <indexterm><primary>ADAM</primary></indexterm> 1819 <indexterm><primary>ADS</primary></indexterm> 1820 The storage of IDMAP information in LDAP can be used with both NT4/Samba-3-style domains as well as 1821 with ADS domains. OpenLDAP is a commonly used LDAP server for this purpose, although any standards-compliant 1822 LDAP server can be used. It is therefore possible to deploy this IDMAP configuration using 1823 the Sun iPlanet LDAP server, Novell eDirectory, Microsoft ADS plus ADAM, and so on. 1824 </para> 1825 1826 <para> 1827 The example in <link linkend="sbeunxa"/> is for an ADS-style domain. 1828 </para> 1829 1830<example id="sbeunxa"> 1831<title>Typical ADS Style Domain &smb.conf; File</title> 1832<smbconfblock> 1833<smbconfcomment>Global parameters</smbconfcomment> 1834<smbconfsection name="[global]"/> 1835<smbconfoption name="workgroup">SNOWSHOW</smbconfoption> 1836<smbconfoption name="netbios name">GOODELF</smbconfoption> 1837<smbconfoption name="realm">SNOWSHOW.COM</smbconfoption> 1838<smbconfoption name="server string">Samba Server</smbconfoption> 1839<smbconfoption name="security">ADS</smbconfoption> 1840<smbconfoption name="log level">1 ads:10 auth:10 sam:10 rpc:10</smbconfoption> 1841<smbconfoption name="ldap admin dn">cn=Manager,dc=SNOWSHOW,dc=COM</smbconfoption> 1842<smbconfoption name="ldap idmap suffix">ou=Idmap</smbconfoption> 1843<smbconfoption name="ldap suffix">dc=SNOWSHOW,dc=COM</smbconfoption> 1844<smbconfoption name="idmap backend">ldap:ldap://ldap.snowshow.com</smbconfoption> 1845<smbconfoption name="idmap uid">150000-550000</smbconfoption> 1846<smbconfoption name="idmap gid">150000-550000</smbconfoption> 1847<smbconfoption name="template shell">/bin/bash</smbconfoption> 1848<smbconfoption name="winbind use default domain">Yes</smbconfoption> 1849</smbconfblock> 1850</example> 1851 1852 <para> 1853 <indexterm><primary>realm</primary></indexterm> 1854 In the case of an NT4 or Samba-3-style domain the <parameter>realm</parameter> is not used, and the 1855 command used to join the domain is <command>net rpc join</command>. The above example also demonstrates 1856 advanced error reporting techniques that are documented in the chapter called "Reporting Bugs" in 1857 <quote>The Official Samba-3 HOWTO and Reference Guide, Second Edition</quote> (TOSHARG2). 1858 </para> 1859 1860 <para> 1861 <indexterm><primary>MIT kerberos</primary></indexterm> 1862 <indexterm><primary>Heimdal kerberos</primary></indexterm> 1863 <indexterm><primary>/etc/krb5.conf</primary></indexterm> 1864 Where MIT kerberos is installed (version 1.3.4 or later), edit the <filename>/etc/krb5.conf</filename> 1865 file so it has the following contents: 1866<screen> 1867[logging] 1868 default = FILE:/var/log/krb5libs.log 1869 kdc = FILE:/var/log/krb5kdc.log 1870 admin_server = FILE:/var/log/kadmind.log 1871 1872[libdefaults] 1873 default_realm = SNOWSHOW.COM 1874 dns_lookup_realm = false 1875 dns_lookup_kdc = true 1876 1877[appdefaults] 1878 pam = { 1879 debug = false 1880 ticket_lifetime = 36000 1881 renew_lifetime = 36000 1882 forwardable = true 1883 krb4_convert = false 1884 } 1885</screen> 1886 </para> 1887 1888 <para> 1889 Where Heimdal kerberos is installed, edit the <filename>/etc/krb5.conf</filename> 1890 file so it is either empty (i.e., no contents) or it has the following contents: 1891<screen> 1892[libdefaults] 1893 default_realm = SNOWSHOW.COM 1894 clockskew = 300 1895 1896[realms] 1897 SNOWSHOW.COM = { 1898 kdc = ADSDC.SHOWSHOW.COM 1899 } 1900 1901[domain_realm] 1902 .snowshow.com = SNOWSHOW.COM 1903</screen> 1904 </para> 1905 1906 <note><para> 1907 Samba cannot use the Heimdal libraries if there is no <filename>/etc/krb5.conf</filename> file. 1908 So long as there is an empty file, the Heimdal kerberos libraries will be usable. There is no 1909 need to specify any settings because Samba, using the Heimdal libraries, can figure this out automatically. 1910 </para></note> 1911 <para> 1912 Edit the NSS control file <filename>/etc/nsswitch.conf</filename> so it has the following entries: 1913<screen> 1914... 1915passwd: files ldap 1916shadow: files ldap 1917group: files ldap 1918... 1919hosts: files wins 1920... 1921</screen> 1922 </para> 1923 1924 <para> 1925 <indexterm><primary>PADL</primary></indexterm> 1926 <indexterm><primary>/etc/ldap.conf</primary></indexterm> 1927 You will need the <ulink url="http://www.padl.com">PADL</ulink> <command>nss_ldap</command> 1928 tool set for this solution. Configure the <filename>/etc/ldap.conf</filename> file so it has 1929 the information needed. The following is an example of a working file: 1930<screen> 1931host 192.168.2.1 1932base dc=snowshow,dc=com 1933binddn cn=Manager,dc=snowshow,dc=com 1934bindpw not24get 1935 1936pam_password exop 1937 1938nss_base_passwd ou=People,dc=snowshow,dc=com?one 1939nss_base_shadow ou=People,dc=snowshow,dc=com?one 1940nss_base_group ou=Groups,dc=snowshow,dc=com?one 1941ssl no 1942</screen> 1943 </para> 1944 1945 <para> 1946 The following procedure may be followed to affect a working configuration: 1947 </para> 1948 <procedure> 1949 <step><para> 1950 Configure the &smb.conf; file as shown above. 1951 </para></step> 1952 1953 <step><para> 1954 Create the <filename>/etc/krb5.conf</filename> file following the indications above. 1955 </para></step> 1956 1957 <step><para> 1958 Configure the <filename>/etc/nsswitch.conf</filename> file as shown above. 1959 </para></step> 1960 1961 <step><para> 1962 Download, build, and install the PADL nss_ldap tool set. Configure the 1963 <filename>/etc/ldap.conf</filename> file as shown above. 1964 </para></step> 1965 1966 <step><para> 1967 Configure an LDAP server and initialize the directory with the top-level entries needed by IDMAP 1968 as shown in the following LDIF file: 1969<screen> 1970dn: dc=snowshow,dc=com 1971objectClass: dcObject 1972objectClass: organization 1973dc: snowshow 1974o: The Greatest Snow Show in Singapore. 1975description: Posix and Samba LDAP Identity Database 1976 1977dn: cn=Manager,dc=snowshow,dc=com 1978objectClass: organizationalRole 1979cn: Manager 1980description: Directory Manager 1981 1982dn: ou=Idmap,dc=snowshow,dc=com 1983objectClass: organizationalUnit 1984ou: idmap 1985</screen> 1986 </para></step> 1987 1988 <step><para> 1989 Execute the command to join the Samba domain member server to the ADS domain as shown here: 1990<screen> 1991&rootprompt; net ads testjoin 1992Using short domain name -- SNOWSHOW 1993Joined 'GOODELF' to realm 'SNOWSHOW.COM' 1994</screen> 1995 </para></step> 1996 1997 <step><para> 1998 Store the LDAP server access password in the Samba <filename>secrets.tdb</filename> file as follows: 1999<screen> 2000&rootprompt; smbpasswd -w not24get 2001</screen> 2002 </para></step> 2003 2004 <step><para> 2005 Start the <command>nmbd</command>, <command>winbind</command>, and <command>smbd</command> daemons in the order shown. 2006 </para></step> 2007 </procedure> 2008 2009 2010 <para> 2011 <indexterm><primary>diagnostic</primary></indexterm> 2012 Follow the diagnostic procedures shown earlier in this chapter to identify success or failure of the join. 2013 In many cases a failure is indicated by a silent return to the command prompt with no indication of the 2014 reason for failure. 2015 </para> 2016 2017 </sect3> 2018 2019 <sect3> 2020 <title>IDMAP and NSS Using LDAP from ADS with RFC2307bis Schema Extension</title> 2021 2022 <para> 2023 <indexterm><primary>rfc2307bis</primary></indexterm> 2024 <indexterm><primary>schema</primary></indexterm> 2025 The use of this method is messy. The information provided in this section is for guidance only 2026 and is very definitely not complete. This method does work; it is used in a number of large sites 2027 and has an acceptable level of performance. 2028 </para> 2029 2030 <para> 2031 An example &smb.conf; file is shown in <link linkend="sbewinbindex"/>. 2032 </para> 2033 2034<example id="sbewinbindex"> 2035<title>ADS Membership Using RFC2307bis Identity Resolution &smb.conf; File</title> 2036<smbconfblock> 2037<smbconfcomment>Global parameters</smbconfcomment> 2038<smbconfsection name="[global]"/> 2039<smbconfoption name="workgroup">BUBBAH</smbconfoption> 2040<smbconfoption name="netbios name">MADMAX</smbconfoption> 2041<smbconfoption name="realm">BUBBAH.COM</smbconfoption> 2042<smbconfoption name="server string">Samba Server</smbconfoption> 2043<smbconfoption name="security">ADS</smbconfoption> 2044<smbconfoption name="idmap uid">150000-550000</smbconfoption> 2045<smbconfoption name="idmap gid">150000-550000</smbconfoption> 2046<smbconfoption name="template shell">/bin/bash</smbconfoption> 2047<smbconfoption name="winbind use default domain">Yes</smbconfoption> 2048<smbconfoption name="winbind trusted domains only">Yes</smbconfoption> 2049<smbconfoption name="winbind nested groups">Yes</smbconfoption> 2050</smbconfblock> 2051</example> 2052 2053 <para> 2054 <indexterm><primary>nss_ldap</primary></indexterm> 2055 The DMS must be joined to the domain using the usual procedure. Additionally, it is necessary 2056 to build and install the PADL nss_ldap tool set. Be sure to build this tool set with the 2057 following: 2058<screen> 2059./configure --enable-rfc2307bis --enable-schema-mapping 2060make install 2061</screen> 2062 </para> 2063 2064 <para> 2065 <indexterm><primary>/etc/nsswitch.conf</primary></indexterm> 2066 The following <filename>/etc/nsswitch.conf</filename> file contents are required: 2067<screen> 2068... 2069passwd: files ldap 2070shadow: files ldap 2071group: files ldap 2072... 2073hosts: files wins 2074... 2075</screen> 2076 </para> 2077 2078 <para> 2079 <indexterm><primary>/etc/ldap.conf</primary></indexterm> 2080 <indexterm><primary>nss_ldap</primary></indexterm> 2081 The <filename>/etc/ldap.conf</filename> file must be configured also. Refer to the PADL documentation 2082 and source code for nss_ldap instructions. 2083 </para> 2084 2085 <para> 2086 The next step involves preparation on the ADS schema. This is briefly discussed in the remaining 2087 part of this chapter. 2088 </para> 2089 2090 <sect4> 2091 <title>IDMAP, Active Directory, and MS Services for UNIX 3.5</title> 2092 2093 <para> 2094 <indexterm><primary>SFU</primary></indexterm> 2095 The Microsoft Windows Service for UNIX version 3.5 is available for free 2096 <ulink url="http://www.microsoft.com/windows/sfu/">download</ulink> 2097 from the Microsoft Web site. You will need to download this tool and install it following 2098 Microsoft instructions. 2099 </para> 2100 2101 </sect4> 2102 2103 <sect4> 2104 <title>IDMAP, Active Directory, and AD4UNIX</title> 2105 2106 <para> 2107 Instructions for obtaining and installing the AD4UNIX tool set can be found from the 2108 <ulink url="http://www.geekcomix.com/cgi-bin/classnotes/wiki.pl?LDAP01/An_Alternative_Approach"> 2109 Geekcomix</ulink> Web site. 2110 </para> 2111 2112 </sect4> 2113 2114 </sect3> 2115 2116 </sect2> 2117 2118 <sect2> 2119 <title>UNIX/Linux Client Domain Member</title> 2120 2121 <para><indexterm> 2122 <primary>user credentials</primary> 2123 </indexterm> 2124 So far this chapter has been mainly concerned with the provision of file and print 2125 services for domain member servers. However, an increasing number of UNIX/Linux 2126 workstations are being installed that do not act as file or print servers to anyone 2127 other than a single desktop user. The key demand for desktop systems is to be able 2128 to log onto any UNIX/Linux or Windows desktop using the same network user credentials. 2129 </para> 2130 2131 <para><indexterm> 2132 <primary>Single Sign-On</primary> 2133 <see>SSO</see> 2134 </indexterm> 2135 The ability to use a common set of user credential across a variety of network systems 2136 is generally regarded as a single sign-on (SSO) solution. SSO systems are sold by a 2137 large number of vendors and include a range of technologies such as: 2138 </para> 2139 2140 <itemizedlist> 2141 <listitem><para> 2142 Proxy sign-on 2143 </para></listitem> 2144 2145 <listitem><para> 2146 Federated directory provisioning 2147 </para></listitem> 2148 2149 <listitem><para> 2150 Metadirectory server solutions 2151 </para></listitem> 2152 2153 <listitem><para> 2154 Replacement authentication systems 2155 </para></listitem> 2156 </itemizedlist> 2157 2158 <para><indexterm> 2159 <primary>Identity management</primary> 2160 </indexterm> 2161 There are really four solutions that provide integrated authentication and 2162 user identity management facilities: 2163 </para> 2164 2165 <itemizedlist> 2166 <listitem><para> 2167 Samba winbind (free). Samba-3.0.20 introduced a complete replacement for Winbind that now 2168 provides a greater level of scalability in large ADS environments. 2169 </para></listitem> 2170 2171 <listitem><para> 2172 <ulink url="http://www.padl.com">PADL</ulink> PAM and LDAP tools (free). 2173 </para></listitem> 2174 2175 <listitem><para> 2176 <ulink url="http://www.vintela.com">Vintela</ulink> Authentication Services (commercial). 2177 </para></listitem> 2178 2179 <listitem><para> 2180 <ulink url="http://www.centrify.com">Centrify</ulink> DirectControl (commercial). 2181 Centrify's commercial product allows UNIX and Linux systems to use Active Directory 2182 security, directory and policy services. Enhancements include a centralized ID mapping that 2183 allows Samba, DirectControl and Active Directory to seamlessly work together. 2184 </para></listitem> 2185 </itemizedlist> 2186 2187 <para> 2188 The following guidelines are pertinent to the deployment of winbind-based authentication 2189 and identity resolution with the express purpose of allowing users to log on to UNIX/Linux desktops 2190 using Windows network domain user credentials (username and password). 2191 </para> 2192 2193 <para> 2194 You should note that it is possible to use LDAP-based PAM and NSS tools to permit distributed 2195 systems logons (SSO), providing user and group accounts are stored in an LDAP directory. This 2196 provides logon services for UNIX/Linux users, while Windows users obtain their sign-on 2197 support via Samba-3. 2198 </para> 2199 2200 <para> 2201 <indexterm><primary>Windows Services for UNIX</primary><see>SUS</see></indexterm> 2202 On the other hand, if the authentication and identity resolution backend must be provided by 2203 a Windows NT4-style domain or from an Active Directory Domain that does not have the Microsoft 2204 Windows Services for UNIX installed, winbind is your best friend. Specific guidance for these 2205 situations now follows. 2206 </para> 2207 2208 <para> 2209 <indexterm><primary>PAM</primary></indexterm> 2210 <indexterm><primary>Identity resolution</primary></indexterm> 2211 <indexterm><primary>NSS</primary></indexterm> 2212 To permit users to log on to a Linux system using Windows network credentials, you need to 2213 configure identity resolution (NSS) and PAM. This means that the basic steps include those 2214 outlined above with the addition of PAM configuration. Given that most workstations (desktop/client) 2215 usually do not need to provide file and print services to a group of users, the configuration 2216 of shares and printers is generally less important. Often this allows the share specifications 2217 to be entirely removed from the &smb.conf; file. That is obviously an administrator decision. 2218 </para> 2219 2220 <sect3> 2221 <title>NT4 Domain Member</title> 2222 2223 <para> 2224 The following steps provide a Linux system that users can log onto using 2225 Windows NT4 (or Samba-3) domain network credentials: 2226 </para> 2227 2228 <procedure> 2229 <step><para> 2230 Follow the steps outlined in <link linkend="wdcsdm"/> and ensure that 2231 all validation tests function as shown. 2232 </para></step> 2233 2234 <step><para> 2235 Identify what services users must log on to. On Red Hat Linux, if it is 2236 intended that the user shall be given access to all services, it may be 2237 most expeditious to simply configure the file 2238 <filename>/etc/pam.d/system-auth</filename>. 2239 </para></step> 2240 2241 <step><para> 2242 Carefully make a backup copy of all PAM configuration files before you 2243 begin making changes. If you break the PAM configuration, please note 2244 that you may need to use an emergency boot process to recover your Linux 2245 system. It is possible to break the ability to log into the system if 2246 PAM files are incorrectly configured. The entire directory 2247 <filename>/etc/pam.d</filename> should be backed up to a safe location. 2248 </para></step> 2249 2250 <step><para> 2251 If you require only console login support, edit the <filename>/etc/pam.d/login</filename> 2252 so it matches <link linkend="ch9-pamwnbdlogin"/>. 2253 </para></step> 2254 2255 <step><para> 2256 To provide the ability to log onto the graphical desktop interface, you must edit 2257 the files <filename>gdm</filename> and <filename>xdm</filename> in the 2258 <filename>/etc/pam.d</filename> directory. 2259 </para></step> 2260 2261 <step><para> 2262 Edit only one file at a time. Carefully validate its operation before attempting 2263 to reboot the machine. 2264 </para></step> 2265 </procedure> 2266 2267 </sect3> 2268 2269 <sect3> 2270 <title>ADS Domain Member</title> 2271 2272 <para> 2273 This procedure should be followed to permit a Linux network client (workstation/desktop) 2274 to permit users to log on using Microsoft Active Directory-based user credentials. 2275 </para> 2276 2277 <procedure> 2278 <step><para> 2279 Follow the steps outlined in <link linkend="adssdm"/> and ensure that 2280 all validation tests function as shown. 2281 </para></step> 2282 2283 <step><para> 2284 Identify what services users must log on to. On Red Hat Linux, if it is 2285 intended that the user shall be given access to all services, it may be 2286 most expeditious to simply configure the file 2287 <filename>/etc/pam.d/system-auth</filename> as shown in <link linkend="ch9-rhsysauth"/>. 2288 </para></step> 2289 2290 <step><para> 2291 Carefully make a backup copy of all PAM configuration files before you 2292 begin making changes. If you break the PAM configuration, please note 2293 that you may need to use an emergency boot process to recover your Linux 2294 system. It is possible to break the ability to log into the system if 2295 PAM files are incorrectly configured. The entire directory 2296 <filename>/etc/pam.d</filename> should be backed up to a safe location. 2297 </para></step> 2298 2299 <step><para> 2300 If you require only console login support, edit the <filename>/etc/pam.d/login</filename> 2301 so it matches <link linkend="ch9-pamwnbdlogin"/>. 2302 </para></step> 2303 2304 <step><para> 2305 To provide the ability to log onto the graphical desktop interface, you must edit 2306 the files <filename>gdm</filename> and <filename>xdm</filename> in the 2307 <filename>/etc/pam.d</filename> directory. 2308 </para></step> 2309 2310 <step><para> 2311 Edit only one file at a time. Carefully validate its operation before attempting 2312 to reboot the machine. 2313 </para></step> 2314 </procedure> 2315 2316 </sect3> 2317 2318<example id="ch9-pamwnbdlogin"> 2319<title>SUSE: PAM <filename>login</filename> Module Using Winbind</title> 2320<screen> 2321# /etc/pam.d/login 2322 2323#%PAM-1.0 2324auth sufficient pam_unix2.so nullok 2325auth sufficient pam_winbind.so use_first_pass use_authtok 2326auth required pam_securetty.so 2327auth required pam_nologin.so 2328auth required pam_env.so 2329auth required pam_mail.so 2330account sufficient pam_unix2.so 2331account sufficient pam_winbind.so user_first_pass use_authtok 2332password required pam_pwcheck.so nullok 2333password sufficient pam_unix2.so nullok use_first_pass use_authtok 2334password sufficient pam_winbind.so use_first_pass use_authtok 2335session sufficient pam_unix2.so none 2336session sufficient pam_winbind.so use_first_pass use_authtok 2337session required pam_limits.so 2338</screen> 2339</example> 2340 2341<example id="ch9-pamwbndxdm"> 2342<title>SUSE: PAM <filename>xdm</filename> Module Using Winbind</title> 2343<screen> 2344# /etc/pam.d/gdm (/etc/pam.d/xdm) 2345 2346#%PAM-1.0 2347auth sufficient pam_unix2.so nullok 2348auth sufficient pam_winbind.so use_first_pass use_authtok 2349account sufficient pam_unix2.so 2350account sufficient pam_winbind.so use_first_pass use_authtok 2351password sufficient pam_unix2.so 2352password sufficient pam_winbind.so use_first_pass use_authtok 2353session sufficient pam_unix2.so 2354session sufficient pam_winbind.so use_first_pass use_authtok 2355session required pam_dev perm.so 2356session required pam_resmgr.so 2357</screen> 2358</example> 2359 2360<example id="ch9-rhsysauth"> 2361<title>Red Hat 9: PAM System Authentication File: <filename>/etc/pam.d/system-auth</filename> Module Using Winbind</title> 2362<screen> 2363#%PAM-1.0 2364auth required /lib/security/$ISA/pam_env.so 2365auth sufficient /lib/security/$ISA/pam_unix.so likeauth nullok 2366auth sufficient /lib/security/$ISA/pam_winbind.so use_first_pass 2367auth required /lib/security/$ISA/pam_deny.so 2368 2369account required /lib/security/$ISA/pam_unix.so 2370account sufficient /lib/security/$ISA/pam_winbind.so use_first_pass 2371 2372password required /lib/security/$ISA/pam_cracklib.so retry=3 type= 2373# Note: The above line is complete. There is nothing following the '=' 2374password sufficient /lib/security/$ISA/pam_unix.so \ 2375 nullok use_authtok md5 shadow 2376password sufficient /lib/security/$ISA/pam_winbind.so use_first_pass 2377password required /lib/security/$ISA/pam_deny.so 2378 2379session required /lib/security/$ISA/pam_limits.so 2380session sufficient /lib/security/$ISA/pam_unix.so 2381session sufficient /lib/security/$ISA/pam_winbind.so use_first_pass 2382</screen> 2383</example> 2384 2385 </sect2> 2386 2387 <sect2> 2388 <title>Key Points Learned</title> 2389 2390 <para> 2391 The addition of UNIX/Linux Samba servers and clients is a common requirement. In this chapter, you 2392 learned how to integrate such servers so that the UID/GID mappings they use can be consistent 2393 across all domain member servers. You also discovered how to implement the ability to use Samba 2394 or Windows domain account credentials to log on to a UNIX/Linux client. 2395 </para> 2396 2397 <para> 2398 The following are key points made in this chapter: 2399 </para> 2400 2401 <itemizedlist> 2402 <listitem><para> 2403 Domain controllers are always authoritative for the domain. 2404 </para></listitem> 2405 2406 <listitem><para> 2407 Domain members may have local accounts and must be able to resolve the identity of 2408 domain user accounts. Domain user account identity must map to a local UID/GID. That 2409 local UID/GID can be stored in LDAP. This way, it is possible to share the IDMAP data 2410 across all domain member machines. 2411 </para></listitem> 2412 2413 <listitem><para> 2414 Resolution of user and group identities on domain member machines may be implemented 2415 using direct LDAP services or using winbind. 2416 </para></listitem> 2417 2418 <listitem><para> 2419 On NSS/PAM enabled UNIX/Linux systems, NSS is responsible for identity management 2420 and PAM is responsible for authentication of logon credentials (username and password). 2421 </para></listitem> 2422 </itemizedlist> 2423 2424 </sect2> 2425 2426</sect1> 2427 2428<sect1> 2429 <title>Questions and Answers</title> 2430 2431 <para> 2432 The following questions were obtained from the mailing list and also from private discussions 2433 with Windows network administrators. 2434 </para> 2435 2436 <qandaset defaultlabel="chap09qa" type="number"> 2437 <qandaentry> 2438 <question> 2439 2440 <para> 2441 We use NIS for all UNIX accounts. Why do we need winbind? 2442 </para> 2443 2444 </question> 2445 <answer> 2446 2447 <para> 2448 <indexterm><primary>NIS</primary></indexterm> 2449 <indexterm><primary>encrypted passwords</primary></indexterm> 2450 <indexterm><primary>smbpasswd</primary></indexterm> 2451 <indexterm><primary>tdbsam</primary></indexterm> 2452 <indexterm><primary>passdb backend</primary></indexterm> 2453 <indexterm><primary>Winbind</primary></indexterm> 2454 You can use NIS for your UNIX accounts. NIS does not store the Windows encrypted 2455 passwords that need to be stored in one of the acceptable passdb backends. 2456 Your choice of backend is limited to <parameter>smbpasswd</parameter> or 2457 <parameter>tdbsam</parameter>. Winbind is needed to handle the resolution of 2458 SIDs from trusted domains to local UID/GID values. 2459 </para> 2460 2461 <para> 2462 <indexterm><primary>winbind trusted domains only</primary></indexterm> 2463 <indexterm><primary>getpwnam()</primary></indexterm> 2464 On a domain member server, you effectively map Windows domain users to local users 2465 that are in your NIS database by specifying the <parameter>winbind trusted domains 2466 only</parameter>. This causes user and group account lookups to be routed via 2467 the <command>getpwnam()</command> family of systems calls. On an NIS-enabled client, 2468 this pushes the resolution of users and groups out through NIS. 2469 </para> 2470 2471 <para> 2472 As a general rule, it is always a good idea to run winbind on all Samba servers. 2473 </para> 2474 2475 </answer> 2476 </qandaentry> 2477 2478 <qandaentry> 2479 <question> 2480 2481 <para> 2482 Our IT management people do not like LDAP but are looking at Microsoft Active Directory. 2483 Which is better?<indexterm> 2484 <primary>Active Directory</primary> 2485 </indexterm> 2486 </para> 2487 2488 </question> 2489 <answer> 2490 2491 <para><indexterm> 2492 <primary>LDAP</primary> 2493 <secondary>server</secondary> 2494 </indexterm><indexterm> 2495 <primary>Kerberos</primary> 2496 </indexterm><indexterm> 2497 <primary>schema</primary> 2498 </indexterm> 2499 Microsoft Active Directory is an LDAP server that is intricately tied to a Kerberos 2500 infrastructure. Most IT managers who object to LDAP do so because 2501 an LDAP server is most often supplied as a raw tool that needs to be configured and 2502 for which the administrator must create the schema, create the administration tools, and 2503 devise the backup and recovery facilities in a site-dependent manner. LDAP servers 2504 in general are seen as a high-energy, high-risk facility. 2505 </para> 2506 2507 <para><indexterm> 2508 <primary>management</primary> 2509 </indexterm> 2510 Microsoft Active Directory by comparison is easy to install and configure and 2511 is supplied with all tools necessary to implement and manage the directory. For sites 2512 that lack a lot of technical competence, Active Directory is a good choice. For sites 2513 that have the technical competence to handle Active Directory well, LDAP is a good 2514 alternative. The real issue is, What type of solution does 2515 the site want? If management wants a choice to use an alternative, they may want to 2516 consider the options. On the other hand, if management just wants a solution that works, 2517 Microsoft Active Directory is a good solution. 2518 </para> 2519 2520 </answer> 2521 </qandaentry> 2522 2523 <qandaentry> 2524 <question> 2525 2526 <para> 2527 We want to implement a Samba PDC, four Samba BDCs, and 10 Samba servers. Is it possible 2528 to use NIS in place of LDAP? 2529 </para> 2530 2531 </question> 2532 <answer> 2533 2534 <para><indexterm> 2535 <primary>NIS</primary> 2536 </indexterm><indexterm> 2537 <primary>LDAP</primary> 2538 </indexterm><indexterm> 2539 <primary>encrypted passwords</primary> 2540 </indexterm><indexterm> 2541 <primary>synchronized</primary> 2542 </indexterm><indexterm> 2543 <primary>secure account password</primary> 2544 </indexterm><indexterm> 2545 <primary>PDC</primary> 2546 </indexterm><indexterm> 2547 <primary>BDC</primary> 2548 </indexterm> 2549 Yes, it is possible to use NIS in place of LDAP, but there may be problems with keeping 2550 the Windows (SMB) encrypted passwords database correctly synchronized across the entire 2551 network. Workstations (Windows client machines) periodically change their domain 2552 membership secure account password. How can you keep changes that are on remote BDCs 2553 synchronized on the PDC? 2554 </para> 2555 2556 <para><indexterm> 2557 <primary>centralized storage</primary> 2558 </indexterm><indexterm> 2559 <primary>management</primary> 2560 </indexterm><indexterm> 2561 <primary>network Identities</primary> 2562 </indexterm> 2563 LDAP is a more elegant solution because it permits centralized storage and management 2564 of all network identities (user, group, and machine accounts) together with all information 2565 Samba needs to provide to network clients and their users. 2566 </para> 2567 2568 </answer> 2569 </qandaentry> 2570 2571 <qandaentry> 2572 <question> 2573 2574 <para> 2575 Are you suggesting that users should not log on to a domain member server? If so, why? 2576 </para> 2577 2578 </question> 2579 <answer> 2580 2581 <para><indexterm> 2582 <primary>security</primary> 2583 </indexterm><indexterm> 2584 <primary>data</primary> 2585 <secondary>integrity</secondary> 2586 </indexterm><indexterm> 2587 <primary>mapped drives</primary> 2588 </indexterm> 2589 Many UNIX administrators mock the model that the personal computer industry has adopted 2590 as normative since the early days of Novell NetWare. The old 2591 perception of the necessity to keep users off file and print servers was a result of 2592 fears concerning the security and integrity of data. It was a simple and generally 2593 effective measure to keep users away from servers, except through mapped drives. 2594 </para> 2595 2596 <para><indexterm> 2597 <primary>user logins</primary> 2598 </indexterm><indexterm> 2599 <primary>risk</primary> 2600 </indexterm><indexterm> 2601 <primary>user errors</primary> 2602 </indexterm><indexterm> 2603 <primary>strategy</primary> 2604 </indexterm><indexterm> 2605 <primary>policy</primary> 2606 </indexterm> 2607 UNIX administrators are fully correct in asserting that UNIX servers and workstations 2608 are identical in terms of the software that is installed. They correctly assert that 2609 in a well-secured environment it is safe to store files on a system that has hundreds 2610 of users. But all network administrators must factor into the decision to allow or 2611 reject general user logins to a UNIX system that is principally a file and print 2612 server the risk to operations through simple user errors. 2613 Only then can one begin to appraise the best strategy and adopt a site-specific 2614 policy that best protects the needs of users and of the organization alike. 2615 </para> 2616 2617 <para><indexterm> 2618 <primary>system level logins</primary> 2619 </indexterm> 2620 From experience, it is my recommendation to keep general system-level logins to a 2621 practical minimum and to eliminate them if possible. This should not be taken as a 2622 hard rule, though. The better question is, what works best for the site? 2623 </para> 2624 2625 </answer> 2626 </qandaentry> 2627 2628 <qandaentry> 2629 <question> 2630 2631 <para><indexterm> 2632 <primary>trusted domains</primary> 2633 </indexterm><indexterm> 2634 <primary>domain</primary> 2635 <secondary>trusted</secondary> 2636 </indexterm><indexterm> 2637 <primary>winbind trusted domains only</primary> 2638 </indexterm><indexterm> 2639 <primary>domain members</primary> 2640 </indexterm> 2641 We want to ensure that only users from our own domain plus from trusted domains can use our 2642 Samba servers. In the &smb.conf; file on all servers, we have enabled the <parameter>winbind 2643 trusted domains only</parameter> parameter. We now find that users from trusted domains 2644 cannot access our servers, and users from Windows clients that are not domain members 2645 can also access our servers. Is this a Samba bug? 2646 </para> 2647 2648 </question> 2649 <answer> 2650 2651 <para><indexterm> 2652 <primary>distributed</primary> 2653 </indexterm><indexterm> 2654 <primary>NIS</primary> 2655 </indexterm><indexterm> 2656 <primary>rsync</primary> 2657 </indexterm><indexterm> 2658 <primary>LDAP</primary> 2659 </indexterm><indexterm> 2660 <primary>winbindd</primary> 2661 </indexterm><indexterm> 2662 <primary>/etc/passwd</primary> 2663 </indexterm> 2664 The manual page for this <parameter>winbind trusted domains only</parameter> parameter says, 2665 <quote>This parameter is designed to allow Samba servers that are members of a Samba-controlled 2666 domain to use UNIX accounts distributed vi NIS, rsync, or LDAP as the UIDs for winbindd users 2667 in the hosts primary domain. Therefore, the user <constant>SAMBA\user1</constant> would be 2668 mapped to the account <constant>user1</constant> in <filename>/etc/passwd</filename> instead 2669 of allocating a new UID for him or her.</quote> This clearly suggests that you are trying 2670 to use this parameter inappropriately. 2671 </para> 2672 2673 <para><indexterm> 2674 <primary>valid users</primary> 2675 </indexterm> 2676 A far better solution is to use the <parameter>valid users</parameter> by specifying 2677 precisely the domain users and groups that should be permitted access to the shares. You could, 2678 for example, set the following parameters: 2679<screen> 2680[demoshare] 2681 path = /export/demodata 2682 valid users = @"Domain Users", @"OTHERDOMAIN\Domain Users" 2683</screen> 2684 </para> 2685 2686 2687 </answer> 2688 </qandaentry> 2689 2690 <qandaentry> 2691 <question> 2692 2693 <para> 2694 What are the benefits of using LDAP for my domain member servers? 2695 </para> 2696 2697 </question> 2698 <answer> 2699 2700 <para><indexterm> 2701 <primary>LDAP</primary> 2702 </indexterm><indexterm> 2703 <primary>benefit</primary> 2704 </indexterm><indexterm> 2705 <primary>UID</primary> 2706 </indexterm><indexterm> 2707 <primary>GID</primary> 2708 </indexterm><indexterm> 2709 <primary>Domain Controllers</primary> 2710 </indexterm><indexterm> 2711 <primary>Domain Member servers</primary> 2712 </indexterm><indexterm> 2713 <primary>copy</primary> 2714 </indexterm><indexterm> 2715 <primary>replicate</primary> 2716 </indexterm><indexterm> 2717 <primary>identity</primary> 2718 </indexterm> 2719 The key benefit of using LDAP is that the UID of all users and the GID of all groups 2720 are globally consistent on domain controllers as well as on domain member servers. 2721 This means that it is possible to copy/replicate files across servers without 2722 loss of identity. 2723 </para> 2724 2725 <para><indexterm> 2726 <primary>Identity resolution</primary> 2727 </indexterm><indexterm> 2728 <primary>winbind</primary> 2729 </indexterm><indexterm> 2730 <primary>IDMAP backend</primary> 2731 </indexterm><indexterm> 2732 <primary>LDAP</primary> 2733 </indexterm><indexterm> 2734 <primary>Domain Controllers</primary> 2735 </indexterm><indexterm> 2736 <primary>Domain Member</primary> 2737 <secondary>servers</secondary> 2738 </indexterm><indexterm> 2739 <primary>Posix</primary> 2740 </indexterm><indexterm> 2741 <primary>account information</primary> 2742 </indexterm> 2743 When use is made of account identity resolution via winbind, even when an IDMAP backend 2744 is stored in LDAP, the UID/GID on domain member servers is consistent, but differs 2745 from the ID that the user/group has on domain controllers. The winbind allocated UID/GID 2746 that is stored in LDAP (or locally) will be in the numeric range specified in the <parameter> 2747 idmap uid/gid</parameter> in the &smb.conf; file. On domain controllers, the UID/GID is 2748 that of the POSIX value assigned in the LDAP directory as part of the POSIX account information. 2749 </para> 2750 2751 </answer> 2752 </qandaentry> 2753 2754 <qandaentry> 2755 <question> 2756 2757 <para> 2758 Is proper DNS operation necessary for Samba-3 plus LDAP? If so, what must I put into 2759 my DNS configuration? 2760 </para> 2761 2762 </question> 2763 <answer> 2764 2765 <para><indexterm> 2766 <primary>DNS</primary> 2767 <secondary>configuration</secondary> 2768 </indexterm><indexterm> 2769 <primary>DNS</primary> 2770 <secondary>lookup</secondary> 2771 </indexterm><indexterm> 2772 <primary>hosts</primary> 2773 </indexterm><indexterm> 2774 <primary>/etc/nsswitch.conf</primary> 2775 </indexterm><indexterm> 2776 <primary>NSS</primary> 2777 </indexterm><indexterm> 2778 <primary>/etc/hosts</primary> 2779 </indexterm><indexterm> 2780 <primary>WINS</primary> 2781 <secondary>lookup</secondary> 2782 </indexterm> 2783 Samba depends on correctly functioning resolution of hostnames to their IP address. Samba 2784 makes no direct DNS lookup calls, but rather redirects all name-to-address calls via the 2785 <command>getXXXbyXXX()</command> function calls. The configuration of the <constant>hosts</constant> 2786 entry in the NSS <filename>/etc/nsswitch.conf</filename> file determines how the underlying 2787 resolution process is implemented. If the <constant>hosts</constant> entry in your NSS 2788 control file says: 2789<screen> 2790hosts: files dns wins 2791</screen> 2792 this means that a hostname lookup first tries the <filename>/etc/hosts</filename>. 2793 If this fails to resolve, it attempts a DNS lookup, and if that fails, it tries a 2794 WINS lookup. 2795 </para> 2796 2797 <para><indexterm> 2798 <primary>NetBIOS</primary> 2799 </indexterm><indexterm> 2800 <primary>TCP/IP</primary> 2801 </indexterm><indexterm> 2802 <primary>name resolution</primary> 2803 </indexterm> 2804 The addition of the WINS-based name lookup makes sense only if NetBIOS over TCP/IP has 2805 been enabled on all Windows clients. Where NetBIOS over TCP/IP has been disabled, DNS 2806 is the preferred name resolution technology. This usually makes most sense when Samba 2807 is a client of an Active Directory domain, where NetBIOS use has been disabled. In this 2808 case, the Windows 200x autoregisters all locator records it needs with its own DNS 2809 server or servers. 2810 </para> 2811 2812 </answer> 2813 </qandaentry> 2814 2815 <qandaentry> 2816 <question> 2817 2818 <para> 2819 Our Windows 2003 Server Active Directory domain runs with NetBIOS disabled. Can we 2820 use Samba-3 with that configuration? 2821 </para> 2822 2823 </question> 2824 <answer> 2825 2826 <para> 2827 Yes. 2828 </para> 2829 2830 </answer> 2831 </qandaentry> 2832 2833 <qandaentry> 2834 <question> 2835 2836 <para><indexterm> 2837 <primary>net</primary> 2838 <secondary>ads</secondary> 2839 <tertiary>join</tertiary> 2840 </indexterm><indexterm> 2841 <primary>net</primary> 2842 <secondary>rpc</secondary> 2843 <tertiary>join</tertiary> 2844 </indexterm> 2845 When I tried to execute net ads join, I got no output. It did not work, so 2846 I think that it failed. I then executed net rpc join and that worked fine. 2847 That is okay, isn't it? 2848 </para> 2849 2850 </question> 2851 <answer> 2852 2853 <para><indexterm> 2854 <primary>Kerberos</primary> 2855 </indexterm><indexterm> 2856 <primary>authentication</primary> 2857 </indexterm> 2858 No. This is not okay. It means that your Samba-3 client has joined the ADS domain as 2859 a Windows NT4 client, and Samba-3 will not be using Kerberos-based authentication. 2860 </para> 2861 2862 </answer> 2863 </qandaentry> 2864 2865 </qandaset> 2866 2867</sect1> 2868 2869</chapter> 2870