docs/htmldocs/Samba-PDC-HOWTO.html

   1 <HTML
   2 ><HEAD
   3 ><TITLE
   4 >How to Configure Samba 2.2 as a Primary Domain Controller</TITLE
   5 ><META
   6 NAME="GENERATOR"
   7 CONTENT="Modular DocBook HTML Stylesheet Version 1.57"></HEAD
   8 ><BODY
   9 CLASS="ARTICLE"
  10 BGCOLOR="#FFFFFF"
  11 TEXT="#000000"
  12 LINK="#0000FF"
  13 VLINK="#840084"
  14 ALINK="#0000FF"
  15 ><DIV
  16 CLASS="ARTICLE"
  17 ><DIV
  18 CLASS="TITLEPAGE"
  19 ><H1
  20 CLASS="TITLE"
  21 ><A
  22 NAME="SAMBA-PDC"
  23 >How to Configure Samba 2.2 as a Primary Domain Controller</A
  24 ></H1
  25 ><HR></DIV
  26 ><DIV
  27 CLASS="SECT1"
  28 ><H1
  29 CLASS="SECT1"
  30 ><A
  31 NAME="AEN3"
  32 >Prerequisite Reading</A
  33 ></H1
  34 ><P
  35 >Before you continue reading in this chapter, please make sure
  36 that you are comfortable with configuring basic files services
  37 in smb.conf and how to enable and administer password
  38 encryption in Samba.  Theses two topics are covered in the
  39 <A
  40 HREF="smb.conf.5.html"
  41 TARGET="_top"
  42 ><TT
  43 CLASS="FILENAME"
  44 >smb.conf(5)</TT
  45 ></A
  46 >
  47 manpage and the <A
  48 HREF="ENCRYPTION.html"
  49 TARGET="_top"
  50 >Encryption chapter</A
  51 >
  52 of this HOWTO Collection.</P
  53 ></DIV
  54 ><DIV
  55 CLASS="SECT1"
  56 ><HR><H1
  57 CLASS="SECT1"
  58 ><A
  59 NAME="AEN9"
  60 >Background</A
  61 ></H1
  62 ><DIV
  63 CLASS="NOTE"
  64 ><BLOCKQUOTE
  65 CLASS="NOTE"
  66 ><P
  67 ><B
  68 >Note: </B
  69 ><I
  70 CLASS="EMPHASIS"
  71 >Author's Note:</I
  72 > This document is a combination
  73 of David Bannon's "Samba 2.2 PDC HOWTO" and "Samba NT Domain FAQ".
  74 Both documents are superseded by this one.</P
  75 ></BLOCKQUOTE
  76 ></DIV
  77 ><P
  78 >Versions of Samba prior to release 2.2 had marginal capabilities to act
  79 as a Windows NT 4.0 Primary Domain Controller
  80
  81 (PDC).  With Samba 2.2.0, we are proud to announce official support for
  82 Windows NT 4.0-style domain logons from Windows NT 4.0 and Windows
  83 2000 clients.  This article outlines the steps
  84 necessary for configuring Samba as a PDC.  It is necessary to have a
  85 working Samba server prior to implementing the PDC functionality.  If
  86 you have not followed the steps outlined in <A
  87 HREF="UNIX_INSTALL.html"
  88 TARGET="_top"
  89 > UNIX_INSTALL.html</A
  90 >, please make sure
  91 that your server is configured correctly before proceeding.  Another
  92 good resource in the <A
  93 HREF="smb.conf.5.html"
  94 TARGET="_top"
  95 >smb.conf(5) man
  96 page</A
  97 >. The following functionality should work in 2.2:</P
  98 ><P
  99 ></P
 100 ><UL
 101 ><LI
 102 ><P
 103 >       domain logons for Windows NT 4.0/2000 clients.
 104         </P
 105 ></LI
 106 ><LI
 107 ><P
 108 >       placing a Windows 9x client in user level security
 109         </P
 110 ></LI
 111 ><LI
 112 ><P
 113 >       retrieving a list of users and groups from a Samba PDC to
 114         Windows 9x/NT/2000 clients
 115         </P
 116 ></LI
 117 ><LI
 118 ><P
 119 >       roving (roaming) user profiles
 120         </P
 121 ></LI
 122 ><LI
 123 ><P
 124 >       Windows NT 4.0-style system policies
 125         </P
 126 ></LI
 127 ></UL
 128 ><P
 129 >The following pieces of functionality are not included in the 2.2 release:</P
 130 ><P
 131 ></P
 132 ><UL
 133 ><LI
 134 ><P
 135 >       Windows NT 4 domain trusts
 136         </P
 137 ></LI
 138 ><LI
 139 ><P
 140 >       SAM replication with Windows NT 4.0 Domain Controllers
 141         (i.e. a Samba PDC and a Windows NT BDC or vice versa)
 142         </P
 143 ></LI
 144 ><LI
 145 ><P
 146 >       Adding users via the User Manager for Domains
 147         </P
 148 ></LI
 149 ><LI
 150 ><P
 151 >       Acting as a Windows 2000 Domain Controller (i.e. Kerberos and
 152         Active Directory)
 153         </P
 154 ></LI
 155 ></UL
 156 ><P
 157 >Please note that Windows 9x clients are not true members of a domain
 158 for reasons outlined in this article.  Therefore the protocol for
 159 support Windows 9x-style domain logons is completely different
 160 from NT4 domain logons and has been officially supported for some
 161 time.</P
 162 ><P
 163 >Implementing a Samba PDC can basically be divided into 2 broad
 164 steps.</P
 165 ><P
 166 ></P
 167 ><OL
 168 TYPE="1"
 169 ><LI
 170 ><P
 171 >       Configuring the Samba PDC
 172         </P
 173 ></LI
 174 ><LI
 175 ><P
 176 >       Creating machine trust accounts and joining clients
 177         to the domain
 178         </P
 179 ></LI
 180 ></OL
 181 ><P
 182 >There are other minor details such as user profiles, system
 183 policies, etc...  However, these are not necessarily specific
 184 to a Samba PDC as much as they are related to Windows NT networking
 185 concepts.  They will be mentioned only briefly here.</P
 186 ></DIV
 187 ><DIV
 188 CLASS="SECT1"
 189 ><HR><H1
 190 CLASS="SECT1"
 191 ><A
 192 NAME="AEN48"
 193 >Configuring the Samba Domain Controller</A
 194 ></H1
 195 ><P
 196 >The first step in creating a working Samba PDC is to
 197 understand the parameters necessary in smb.conf.  I will not
 198 attempt to re-explain the parameters here as they are more that
 199 adequately covered in <A
 200 HREF="smb.conf.5.html"
 201 TARGET="_top"
 202 > the smb.conf
 203 man page</A
 204 >.  For convenience, the parameters have been
 205 linked with the actual smb.conf description.</P
 206 ><P
 207 >Here is an example <TT
 208 CLASS="FILENAME"
 209 >smb.conf</TT
 210 > for acting as a PDC:</P
 211 ><P
 212 ><PRE
 213 CLASS="PROGRAMLISTING"
 214 >[global]
 215     ; Basic server settings
 216     <A
 217 HREF="smb.conf.5.html#NETBIOSNAME"
 218 TARGET="_top"
 219 >netbios name</A
 220 > = <TT
 221 CLASS="REPLACEABLE"
 222 ><I
 223 >POGO</I
 224 ></TT
 225 >
 226     <A
 227 HREF="smb.conf.5.html#WORKGROUP"
 228 TARGET="_top"
 229 >workgroup</A
 230 > = <TT
 231 CLASS="REPLACEABLE"
 232 ><I
 233 >NARNIA</I
 234 ></TT
 235 >
 236
 237     ; we should act as the domain and local master browser
 238     <A
 239 HREF="smb.conf.5.html#OSLEVEL"
 240 TARGET="_top"
 241 >os level</A
 242 > = 64
 243     <A
 244 HREF="smb.conf.5.html#PERFERREDMASTER"
 245 TARGET="_top"
 246 >preferred master</A
 247 > = yes
 248     <A
 249 HREF="smb.conf.5.html#DOMAINMASTER"
 250 TARGET="_top"
 251 >domain master</A
 252 > = yes
 253     <A
 254 HREF="smb.conf.5.html#LOCALMASTER"
 255 TARGET="_top"
 256 >local master</A
 257 > = yes
 258
 259     ; security settings (must user security = user)
 260     <A
 261 HREF="smb.conf.5.html#SECURITYEQUALSUSER"
 262 TARGET="_top"
 263 >security</A
 264 > = user
 265
 266     ; encrypted passwords are a requirement for a PDC
 267     <A
 268 HREF="smb.conf.5.html#ENCRYPTPASSWORDS"
 269 TARGET="_top"
 270 >encrypt passwords</A
 271 > = yes
 272
 273     ; support domain logons
 274     <A
 275 HREF="smb.conf.5.html#DOMAINLOGONS"
 276 TARGET="_top"
 277 >domain logons</A
 278 > = yes
 279
 280     ; where to store user profiles?
 281     <A
 282 HREF="smb.conf.5.html#LOGONPATH"
 283 TARGET="_top"
 284 >logon path</A
 285 > = \\%N\profiles\%u
 286
 287     ; where is a user's home directory and where should it
 288     ; be mounted at?
 289     <A
 290 HREF="smb.conf.5.html#LOGONDRIVE"
 291 TARGET="_top"
 292 >logon drive</A
 293 > = H:
 294     <A
 295 HREF="smb.conf.5.html#LOGONHOME"
 296 TARGET="_top"
 297 >logon home</A
 298 > = \\homeserver\%u
 299
 300     ; specify a generic logon script for all users
 301     ; this is a relative **DOS** path to the [netlogon] share
 302     <A
 303 HREF="smb.conf.5.html#LOGONSCRIPT"
 304 TARGET="_top"
 305 >logon script</A
 306 > = logon.cmd
 307
 308 ; necessary share for domain controller
 309 [netlogon]
 310     <A
 311 HREF="smb.conf.5.html#PATH"
 312 TARGET="_top"
 313 >path</A
 314 > = /usr/local/samba/lib/netlogon
 315     <A
 316 HREF="smb.conf.5.html#READONLY"
 317 TARGET="_top"
 318 >read only</A
 319 > = yes
 320     <A
 321 HREF="smb.conf.5.html#WRITELIST"
 322 TARGET="_top"
 323 >write list</A
 324 > = <TT
 325 CLASS="REPLACEABLE"
 326 ><I
 327 >ntadmin</I
 328 ></TT
 329 >
 330
 331 ; share for storing user profiles
 332 [profiles]
 333     <A
 334 HREF="smb.conf.5.html#PATH"
 335 TARGET="_top"
 336 >path</A
 337 > = /export/smb/ntprofile
 338     <A
 339 HREF="smb.conf.5.html#READONLY"
 340 TARGET="_top"
 341 >read only</A
 342 > = no
 343     <A
 344 HREF="smb.conf.5.html#CREATEMASK"
 345 TARGET="_top"
 346 >create mask</A
 347 > = 0600
 348     <A
 349 HREF="smb.conf.5.html#DIRECTORYMASK"
 350 TARGET="_top"
 351 >directory mask</A
 352 > = 0700</PRE
 353 ></P
 354 ><P
 355 >There are a couple of points to emphasize in the above configuration.</P
 356 ><P
 357 ></P
 358 ><UL
 359 ><LI
 360 ><P
 361 >       Encrypted passwords must be enabled.  For more details on how
 362         to do this, refer to <A
 363 HREF="ENCRYPTION.html"
 364 TARGET="_top"
 365 >ENCRYPTION.html</A
 366 >.
 367         </P
 368 ></LI
 369 ><LI
 370 ><P
 371 >       The server must support domain logons and a
 372         <TT
 373 CLASS="FILENAME"
 374 >[netlogon]</TT
 375 > share
 376         </P
 377 ></LI
 378 ><LI
 379 ><P
 380 >       The server must be the domain master browser in order for Windows
 381         client to locate the server as a DC.  Please refer to the various
 382         Network Browsing documentation included with this distribution for
 383         details.
 384         </P
 385 ></LI
 386 ></UL
 387 ><P
 388 >As Samba 2.2 does not offer a complete implementation of group mapping
 389 between Windows NT groups and Unix groups (this is really quite
 390 complicated to explain in a short space), you should refer to the
 391 <A
 392 HREF="smb.conf.5.html#DOMAINADMINGROUP"
 393 TARGET="_top"
 394 >domain admin
 395 group</A
 396 > smb.conf parameter for information of creating "Domain
 397 Admins" style accounts.</P
 398 ></DIV
 399 ><DIV
 400 CLASS="SECT1"
 401 ><HR><H1
 402 CLASS="SECT1"
 403 ><A
 404 NAME="AEN91"
 405 >Creating Machine Trust Accounts and Joining Clients to the
 406 Domain</A
 407 ></H1
 408 ><P
 409 >A machine trust account is a Samba account that is used to
 410 authenticate a client machine (rather than a user) to the Samba
 411 server.  In Windows terminology, this is known as a "Computer
 412 Account."</P
 413 ><P
 414 >The password of a machine trust account acts as the shared secret for
 415 secure communication with the Domain Controller.  This is a security
 416 feature to prevent an unauthorized machine with the same NetBIOS name
 417 from joining the domain and gaining access to domain user/group
 418 accounts.  Windows NT and 2000 clients use machine trust accounts, but
 419 Windows 9x clients do not.  Hence, a Windows 9x client is never a true
 420 member of a domain because it does not possess a machine trust
 421 account, and thus has no shared secret with the domain controller.</P
 422 ><P
 423 >A Windows PDC stores each machine trust account in the Windows
 424 Registry.  A Samba PDC, however, stores each machine trust account
 425 in two parts, as follows:
 426
 427 <P
 428 ></P
 429 ><UL
 430 ><LI
 431 ><P
 432 >A Samba account, stored in the same location as user
 433     LanMan and NT password hashes (currently
 434     <TT
 435 CLASS="FILENAME"
 436 >smbpasswd</TT
 437 >). The Samba account
 438     possesses and uses only the NT password hash.</P
 439 ></LI
 440 ><LI
 441 ><P
 442 >A corresponding Unix account, typically stored in
 443     <TT
 444 CLASS="FILENAME"
 445 >/etc/passwd</TT
 446 >. (Future releases will alleviate the need to
 447     create <TT
 448 CLASS="FILENAME"
 449 >/etc/passwd</TT
 450 > entries.) </P
 451 ></LI
 452 ></UL
 453 ></P
 454 ><P
 455 >There are two ways to create machine trust accounts:</P
 456 ><P
 457 ></P
 458 ><UL
 459 ><LI
 460 ><P
 461 > Manual creation. Both the Samba and corresponding
 462         Unix account are created by hand.</P
 463 ></LI
 464 ><LI
 465 ><P
 466 > "On-the-fly" creation. The Samba machine trust
 467         account is automatically created by Samba at the time the client
 468         is joined to the domain. (For security, this is the
 469         recommended method.) The corresponding Unix account may be
 470         created automatically or manually. </P
 471 ></LI
 472 ></UL
 473 ><DIV
 474 CLASS="SECT2"
 475 ><HR><H2
 476 CLASS="SECT2"
 477 ><A
 478 NAME="AEN110"
 479 >Manual Creation of Machine Trust Accounts</A
 480 ></H2
 481 ><P
 482 >The first step in manually creating a machine trust account is to
 483 manually create the corresponding Unix account in
 484 <TT
 485 CLASS="FILENAME"
 486 >/etc/passwd</TT
 487 >.  This can be done using
 488 <B
 489 CLASS="COMMAND"
 490 >vipw</B
 491 > or other 'add user' command that is normally
 492 used to create new Unix accounts.  The following is an example for a
 493 Linux based Samba server:</P
 494 ><P
 495 >  <TT
 496 CLASS="PROMPT"
 497 >root# </TT
 498 ><B
 499 CLASS="COMMAND"
 500 >/usr/sbin/useradd -g 100 -d /dev/null -c <TT
 501 CLASS="REPLACEABLE"
 502 ><I
 503 >"machine
 504 nickname"</I
 505 ></TT
 506 > -s /bin/false <TT
 507 CLASS="REPLACEABLE"
 508 ><I
 509 >machine_name</I
 510 ></TT
 511 >$ </B
 512 ></P
 513 ><P
 514 ><TT
 515 CLASS="PROMPT"
 516 >root# </TT
 517 ><B
 518 CLASS="COMMAND"
 519 >passwd -l <TT
 520 CLASS="REPLACEABLE"
 521 ><I
 522 >machine_name</I
 523 ></TT
 524 >$</B
 525 ></P
 526 ><P
 527 >The <TT
 528 CLASS="FILENAME"
 529 >/etc/passwd</TT
 530 > entry will list the machine name
 531 with a "$" appended, won't have a password, will have a null shell and no
 532 home directory. For example a machine named 'doppy' would have an
 533 <TT
 534 CLASS="FILENAME"
 535 >/etc/passwd</TT
 536 > entry like this:</P
 537 ><P
 538 ><PRE
 539 CLASS="PROGRAMLISTING"
 540 >doppy$:x:505:501:<TT
 541 CLASS="REPLACEABLE"
 542 ><I
 543 >machine_nickname</I
 544 ></TT
 545 >:/dev/null:/bin/false</PRE
 546 ></P
 547 ><P
 548 >Above, <TT
 549 CLASS="REPLACEABLE"
 550 ><I
 551 >machine_nickname</I
 552 ></TT
 553 > can be any
 554 descriptive name for the client, i.e., BasementComputer.
 555 <TT
 556 CLASS="REPLACEABLE"
 557 ><I
 558 >machine_name</I
 559 ></TT
 560 > absolutely must be the NetBIOS
 561 name of the client to be joined to the domain.  The "$" must be
 562 appended to the NetBIOS name of the client or Samba will not recognize
 563 this as a machine trust account.</P
 564 ><P
 565 >Now that the corresponding Unix account has been created, the next step is to create
 566 the Samba account for the client containing the well-known initial
 567 machine trust account password.  This can be done using the <A
 568 HREF="smbpasswd.8.html"
 569 TARGET="_top"
 570 ><B
 571 CLASS="COMMAND"
 572 >smbpasswd(8)</B
 573 ></A
 574 > command
 575 as shown here:</P
 576 ><P
 577 ><TT
 578 CLASS="PROMPT"
 579 >root# </TT
 580 ><B
 581 CLASS="COMMAND"
 582 >smbpasswd -a -m <TT
 583 CLASS="REPLACEABLE"
 584 ><I
 585 >machine_name</I
 586 ></TT
 587 ></B
 588 ></P
 589 ><P
 590 >where <TT
 591 CLASS="REPLACEABLE"
 592 ><I
 593 >machine_name</I
 594 ></TT
 595 > is the machine's NetBIOS
 596 name.  The RID of the new machine account is generated from the UID of
 597 the corresponding Unix account.</P
 598 ><DIV
 599 CLASS="WARNING"
 600 ><P
 601 ></P
 602 ><TABLE
 603 CLASS="WARNING"
 604 BORDER="1"
 605 WIDTH="100%"
 606 ><TR
 607 ><TD
 608 ALIGN="CENTER"
 609 ><B
 610 >Join the client to the domain immediately</B
 611 ></TD
 612 ></TR
 613 ><TR
 614 ><TD
 615 ALIGN="LEFT"
 616 ><P
 617 >       Manually creating a machine trust account using this method is the
 618         equivalent of creating a machine trust account on a Windows NT PDC using
 619         the "Server Manager".  From the time at which the account is created
 620         to the time which the client joins the domain and changes the password,
 621         your domain is vulnerable to an intruder joining your domain using a
 622         a machine with the same NetBIOS name.  A PDC inherently trusts
 623         members of the domain and will serve out a large degree of user
 624         information to such clients.  You have been warned!
 625         </P
 626 ></TD
 627 ></TR
 628 ></TABLE
 629 ></DIV
 630 ></DIV
 631 ><DIV
 632 CLASS="SECT2"
 633 ><HR><H2
 634 CLASS="SECT2"
 635 ><A
 636 NAME="AEN145"
 637 >"On-the-Fly" Creation of Machine Trust Accounts</A
 638 ></H2
 639 ><P
 640 >The second (and recommended) way of creating machine trust accounts is
 641 simply to allow the Samba server to create them as needed when the client
 642 is joined to the domain. </P
 643 ><P
 644 >Since each Samba machine trust account requires a corresponding
 645 Unix account, a method for automatically creating the
 646 Unix account is usually supplied; this requires configuration of the
 647 <A
 648 HREF="smb.conf.5.html#ADDUSERSCRIPT"
 649 TARGET="_top"
 650 >add user script</A
 651 >
 652 option in <TT
 653 CLASS="FILENAME"
 654 >smb.conf</TT
 655 >.  This
 656 method is not required, however; corresponding Unix accounts may also
 657 be created manually.</P
 658 ><P
 659 >Below is an example for a RedHat 6.2 Linux system.</P
 660 ><P
 661 ><PRE
 662 CLASS="PROGRAMLISTING"
 663 >[global]
 664    # &#60;...remainder of parameters...&#62;
 665    add user script = /usr/sbin/useradd -d /dev/null -g 100 -s /bin/false -M %u </PRE
 666 ></P
 667 ></DIV
 668 ><DIV
 669 CLASS="SECT2"
 670 ><HR><H2
 671 CLASS="SECT2"
 672 ><A
 673 NAME="AEN154"
 674 >Joining the Client to the Domain</A
 675 ></H2
 676 ><P
 677 >The procedure for joining a client to the domain varies with the
 678 version of Windows.</P
 679 ><P
 680 ></P
 681 ><UL
 682 ><LI
 683 ><P
 684 ><I
 685 CLASS="EMPHASIS"
 686 >Windows 2000</I
 687 ></P
 688 ><P
 689 > When the user elects to join the client to a domain, Windows prompts for
 690         an account and password that is privileged to join the domain.  A
 691         Samba administrative account (i.e., a Samba account that has root
 692         privileges on the Samba server) must be entered here; the
 693         operation will fail if an ordinary user account is given.
 694         The password for this account should be
 695         set to a different password than the associated
 696         <TT
 697 CLASS="FILENAME"
 698 >/etc/passwd</TT
 699 > entry, for security
 700         reasons. </P
 701 ><P
 702 >The session key of the Samba administrative account acts as an
 703         encryption key for setting the password of the machine trust
 704         account. The machine trust account will be created on-the-fly, or
 705         updated if it already exists.</P
 706 ></LI
 707 ><LI
 708 ><P
 709 ><I
 710 CLASS="EMPHASIS"
 711 >Windows NT</I
 712 ></P
 713 ><P
 714 > If the machine trust account was created manually, on the
 715         Identification Changes menu enter the domain name, but do not
 716         check the box "Create a Computer Account in the Domain."  In this case,
 717         the existing machine trust account is used to join the machine to
 718         the domain.</P
 719 ><P
 720 > If the machine trust account is to be created
 721         on-the-fly, on the Identification Changes menu enter the domain
 722         name, and check the box "Create a Computer Account in the Domain."  In
 723         this case, joining the domain proceeds as above for Windows 2000
 724         (i.e., you must supply a Samba administrative account when
 725         prompted).</P
 726 ></LI
 727 ></UL
 728 ></DIV
 729 ></DIV
 730 ><DIV
 731 CLASS="SECT1"
 732 ><HR><H1
 733 CLASS="SECT1"
 734 ><A
 735 NAME="AEN169"
 736 >Common Problems and Errors</A
 737 ></H1
 738 ><P
 739 ></P
 740 ><P
 741 ></P
 742 ><UL
 743 ><LI
 744 ><P
 745 >       <I
 746 CLASS="EMPHASIS"
 747 >I cannot include a '$' in a machine name.</I
 748 >
 749         </P
 750 ><P
 751 >       A 'machine name' in (typically) <TT
 752 CLASS="FILENAME"
 753 >/etc/passwd</TT
 754 >
 755         of the machine name with a '$' appended. FreeBSD (and other BSD
 756         systems?) won't create a user with a '$' in their name.
 757         </P
 758 ><P
 759 >       The problem is only in the program used to make the entry, once
 760         made, it works perfectly. So create a user without the '$' and
 761         use <B
 762 CLASS="COMMAND"
 763 >vipw</B
 764 > to edit the entry, adding the '$'. Or create
 765         the whole entry with vipw if you like, make sure you use a
 766         unique User ID !
 767         </P
 768 ></LI
 769 ><LI
 770 ><P
 771 >       <I
 772 CLASS="EMPHASIS"
 773 >I get told "You already have a connection to the Domain...."
 774         or "Cannot join domain, the credentials supplied conflict with an
 775         existing set.." when creating a machine trust account.</I
 776 >
 777         </P
 778 ><P
 779 >       This happens if you try to create a machine trust account from the
 780         machine itself and already have a connection (e.g. mapped drive)
 781         to a share (or IPC$) on the Samba PDC.  The following command
 782         will remove all network drive connections:
 783         </P
 784 ><P
 785 >       <TT
 786 CLASS="PROMPT"
 787 >C:\WINNT\&#62;</TT
 788 > <B
 789 CLASS="COMMAND"
 790 >net use * /d</B
 791 >
 792         </P
 793 ><P
 794 >       Further, if the machine is a already a 'member of a workgroup' that
 795         is the same name as the domain you are joining (bad idea) you will
 796         get this message.  Change the workgroup name to something else, it
 797         does not matter what, reboot, and try again.
 798         </P
 799 ></LI
 800 ><LI
 801 ><P
 802 >       <I
 803 CLASS="EMPHASIS"
 804 >The system can not log you on (C000019B)....</I
 805 >
 806         </P
 807 ><P
 808 >I joined the domain successfully but after upgrading
 809         to a newer version of the Samba code I get the message, "The system
 810         can not log you on (C000019B), Please try a gain or consult your
 811         system administrator" when attempting to logon.
 812         </P
 813 ><P
 814 >       This occurs when the domain SID stored in
 815         <TT
 816 CLASS="FILENAME"
 817 >private/WORKGROUP.SID</TT
 818 > is
 819         changed.  For example, you remove the file and <B
 820 CLASS="COMMAND"
 821 >smbd</B
 822 > automatically
 823         creates a new one.  Or you are swapping back and forth between
 824         versions 2.0.7, TNG and the HEAD branch code (not recommended).  The
 825         only way to correct the problem is to restore the original domain
 826         SID or remove the domain client from the domain and rejoin.
 827         </P
 828 ></LI
 829 ><LI
 830 ><P
 831 >       <I
 832 CLASS="EMPHASIS"
 833 >The machine trust account for this computer either does not
 834         exist or is not accessible.</I
 835 >
 836         </P
 837 ><P
 838 >       When I try to join the domain I get the message "The machine account
 839         for this computer either does not exist or is not accessible". What's
 840         wrong?
 841         </P
 842 ><P
 843 >       This problem is caused by the PDC not having a suitable machine trust account.
 844         If you are using the <TT
 845 CLASS="PARAMETER"
 846 ><I
 847 >add user script</I
 848 ></TT
 849 > method to create
 850         accounts then this would indicate that it has not worked. Ensure the domain
 851         admin user system is working.
 852         </P
 853 ><P
 854 >       Alternatively if you are creating account entries manually then they
 855         have not been created correctly. Make sure that you have the entry
 856         correct for the machine trust account in smbpasswd file on the Samba PDC.
 857         If you added the account using an editor rather than using the smbpasswd
 858         utility, make sure that the account name is the machine NetBIOS name
 859         with a '$' appended to it ( i.e. computer_name$ ). There must be an entry
 860         in both /etc/passwd and the smbpasswd file. Some people have reported
 861         that inconsistent subnet masks between the Samba server and the NT
 862         client have caused this problem.   Make sure that these are consistent
 863         for both client and server.
 864         </P
 865 ></LI
 866 ><LI
 867 ><P
 868 >       <I
 869 CLASS="EMPHASIS"
 870 >When I attempt to login to a Samba Domain from a NT4/W2K workstation,
 871         I get a message about my account being disabled.</I
 872 >
 873         </P
 874 ><P
 875 >       This problem is caused by a PAM related bug in Samba 2.2.0.  This bug is
 876         fixed in 2.2.1.  Other symptoms could be unaccessible shares on
 877         NT/W2K member servers in the domain or the following error in your smbd.log:
 878         passdb/pampass.c:pam_account(268) PAM: UNKNOWN ERROR for User: %user%
 879         </P
 880 ><P
 881 >       At first be ensure to enable the useraccounts with <B
 882 CLASS="COMMAND"
 883 >smbpasswd -e
 884         %user%</B
 885 >, this is normally done, when you create an account.
 886         </P
 887 ><P
 888 >       In order to work around this problem in 2.2.0, configure the
 889         <TT
 890 CLASS="PARAMETER"
 891 ><I
 892 >account</I
 893 ></TT
 894 > control flag in
 895         <TT
 896 CLASS="FILENAME"
 897 >/etc/pam.d/samba</TT
 898 > file as follows:
 899         </P
 900 ><P
 901 ><PRE
 902 CLASS="PROGRAMLISTING"
 903 >       account required        pam_permit.so
 904         </PRE
 905 ></P
 906 ><P
 907 >       If you want to remain backward compatibility to samba 2.0.x use
 908         <TT
 909 CLASS="FILENAME"
 910 >pam_permit.so</TT
 911 >, it's also possible to use
 912         <TT
 913 CLASS="FILENAME"
 914 >pam_pwdb.so</TT
 915 >. There are some bugs if you try to
 916         use <TT
 917 CLASS="FILENAME"
 918 >pam_unix.so</TT
 919 >, if you need this, be ensure to use
 920         the most recent version of this file.
 921         </P
 922 ></LI
 923 ></UL
 924 ></DIV
 925 ><DIV
 926 CLASS="SECT1"
 927 ><HR><H1
 928 CLASS="SECT1"
 929 ><A
 930 NAME="AEN217"
 931 >System Policies and Profiles</A
 932 ></H1
 933 ><P
 934 >Much of the information necessary to implement System Policies and
 935 Roving User Profiles in a Samba domain is the same as that for
 936 implementing these same items in a Windows NT 4.0 domain.
 937 You should read the white paper <A
 938 HREF="http://www.microsoft.com/ntserver/management/deployment/planguide/prof_policies.asp"
 939 TARGET="_top"
 940 >Implementing
 941 Profiles and Policies in Windows NT 4.0</A
 942 > available from Microsoft.</P
 943 ><P
 944 >Here are some additional details:</P
 945 ><P
 946 ></P
 947 ><UL
 948 ><LI
 949 ><P
 950 >       <I
 951 CLASS="EMPHASIS"
 952 >What about Windows NT Policy Editor?</I
 953 >
 954         </P
 955 ><P
 956 >       To create or edit <TT
 957 CLASS="FILENAME"
 958 >ntconfig.pol</TT
 959 > you must use
 960         the NT Server Policy Editor, <B
 961 CLASS="COMMAND"
 962 >poledit.exe</B
 963 >       which
 964         is included with NT Server but <I
 965 CLASS="EMPHASIS"
 966 >not NT Workstation</I
 967 >.
 968         There is a Policy Editor on a NTws
 969         but it is not suitable for creating <I
 970 CLASS="EMPHASIS"
 971 >Domain Policies</I
 972 >.
 973         Further, although the Windows 95
 974         Policy Editor can be installed on an NT Workstation/Server, it will not
 975         work with NT policies because the registry key that are set by the policy templates.
 976         However, the files from the NT Server will run happily enough on an NTws.
 977         You need <TT
 978 CLASS="FILENAME"
 979 >poledit.exe, common.adm</TT
 980 > and <TT
 981 CLASS="FILENAME"
 982 >winnt.adm</TT
 983 >. It is convenient
 984         to put the two *.adm files in <TT
 985 CLASS="FILENAME"
 986 >c:\winnt\inf</TT
 987 > which is where
 988         the binary will look for them unless told otherwise. Note also that that
 989         directory is 'hidden'.
 990         </P
 991 ><P
 992 >       The Windows NT policy editor is also included with the Service Pack 3 (and
 993         later) for Windows NT 4.0. Extract the files using <B
 994 CLASS="COMMAND"
 995 >servicepackname /x</B
 996 >,
 997         i.e. that's <B
 998 CLASS="COMMAND"
 999 >Nt4sp6ai.exe /x</B
1000 > for service pack 6a.  The policy editor,
1001         <B
1002 CLASS="COMMAND"
1003 >poledit.exe</B
1004 > and the associated template files (*.adm) should
1005         be extracted as well.  It is also possible to downloaded the policy template
1006         files for Office97 and get a copy of the policy editor.  Another possible
1007         location is with the Zero Administration Kit available for download from Microsoft.
1008         </P
1009 ></LI
1010 ><LI
1011 ><P
1012 >       <I
1013 CLASS="EMPHASIS"
1014 >Can Win95 do Policies?</I
1015 >
1016         </P
1017 ><P
1018 >       Install the group policy handler for Win9x to pick up group
1019         policies.   Look on the Win98 CD in <TT
1020 CLASS="FILENAME"
1021 >\tools\reskit\netadmin\poledit</TT
1022 >.
1023         Install group policies on a Win9x client by double-clicking
1024         <TT
1025 CLASS="FILENAME"
1026 >grouppol.inf</TT
1027 >. Log off and on again a couple of
1028         times and see if Win98 picks up group policies.  Unfortunately this needs
1029         to be done on every Win9x machine that uses group policies....
1030         </P
1031 ><P
1032 >       If group policies don't work one reports suggests getting the updated
1033         (read: working) grouppol.dll for Windows 9x. The group list is grabbed
1034         from /etc/group.
1035         </P
1036 ></LI
1037 ><LI
1038 ><P
1039 >       <I
1040 CLASS="EMPHASIS"
1041 >How do I get 'User Manager' and 'Server Manager'</I
1042 >
1043         </P
1044 ><P
1045 >       Since I don't need to buy an NT Server CD now, how do I get
1046         the 'User Manager for Domains', the 'Server Manager'?
1047         </P
1048 ><P
1049 >       Microsoft distributes a version of these tools called nexus for
1050         installation on Windows 95 systems.  The tools set includes
1051         </P
1052 ><P
1053 ></P
1054 ><UL
1055 ><LI
1056 ><P
1057 >Server Manager</P
1058 ></LI
1059 ><LI
1060 ><P
1061 >User Manager for Domains</P
1062 ></LI
1063 ><LI
1064 ><P
1065 >Event Viewer</P
1066 ></LI
1067 ></UL
1068 ><P
1069 >       Click here to download the archived file <A
1070 HREF="ftp://ftp.microsoft.com/Softlib/MSLFILES/NEXUS.EXE"
1071 TARGET="_top"
1072 >ftp://ftp.microsoft.com/Softlib/MSLFILES/NEXUS.EXE</A
1073 >
1074         </P
1075 ><P
1076 >       The Windows NT 4.0 version of the 'User Manager for
1077         Domains' and 'Server Manager' are available from Microsoft via ftp
1078         from <A
1079 HREF="ftp://ftp.microsoft.com/Softlib/MSLFILES/SRVTOOLS.EXE"
1080 TARGET="_top"
1081 >ftp://ftp.microsoft.com/Softlib/MSLFILES/SRVTOOLS.EXE</A
1082 >
1083         </P
1084 ></LI
1085 ></UL
1086 ></DIV
1087 ><DIV
1088 CLASS="SECT1"
1089 ><HR><H1
1090 CLASS="SECT1"
1091 ><A
1092 NAME="AEN261"
1093 >What other help can I get?</A
1094 ></H1
1095 ><P
1096 >There are many sources of information available in the form
1097 of mailing lists, RFC's and documentation.  The docs that come
1098 with the samba distribution contain very good explanations of
1099 general SMB topics such as browsing.</P
1100 ><P
1101 ></P
1102 ><UL
1103 ><LI
1104 ><P
1105 >       <I
1106 CLASS="EMPHASIS"
1107 >What are some diagnostics tools I can use to debug the domain logon
1108         process and where can I find them?</I
1109 >
1110         </P
1111 ><P
1112 >       One of the best diagnostic tools for debugging problems is Samba itself.
1113         You can use the -d option for both smbd and nmbd to specify what
1114         'debug level' at which to run.  See the man pages on smbd, nmbd  and
1115         smb.conf for more information on debugging options.  The debug
1116         level can range from 1 (the default) to 10 (100 for debugging passwords).
1117         </P
1118 ><P
1119 >       Another helpful method of debugging is to compile samba using the
1120         <B
1121 CLASS="COMMAND"
1122 >gcc -g </B
1123 > flag.   This will include debug
1124         information in the binaries and allow you to attach gdb to the
1125         running smbd / nmbd process.  In order to attach gdb to an smbd
1126         process for an NT workstation, first get the workstation to make the
1127         connection. Pressing ctrl-alt-delete and going down to the domain box
1128         is sufficient (at least, on the first time you join the domain) to
1129         generate a 'LsaEnumTrustedDomains'. Thereafter, the workstation
1130         maintains an open connection, and therefore there will be an smbd
1131         process running (assuming that you haven't set a really short smbd
1132         idle timeout)  So, in between pressing ctrl alt delete, and actually
1133         typing in your password, you can gdb attach and continue.
1134         </P
1135 ><P
1136 >       Some useful samba commands worth investigating:
1137         </P
1138 ><P
1139 ></P
1140 ><UL
1141 ><LI
1142 ><P
1143 >testparam | more</P
1144 ></LI
1145 ><LI
1146 ><P
1147 >smbclient -L //{netbios name of server}</P
1148 ></LI
1149 ></UL
1150 ><P
1151 >       An SMB enabled version of tcpdump is available from
1152         <A
1153 HREF="http://www.tcpdump.org/"
1154 TARGET="_top"
1155 >http://www.tcpdup.org/</A
1156 >.
1157         Ethereal, another good packet sniffer for Unix and Win32
1158         hosts, can be downloaded from <A
1159 HREF="http://www.ethereal.com/"
1160 TARGET="_top"
1161 >http://www.ethereal.com</A
1162 >.
1163         </P
1164 ><P
1165 >       For tracing things on the Microsoft Windows NT, Network Monitor
1166         (aka. netmon) is available on the Microsoft Developer Network CD's,
1167         the Windows NT Server install CD and the SMS CD's.  The version of
1168         netmon that ships with SMS allows for dumping packets between any two
1169         computers (i.e. placing the network interface in promiscuous mode).
1170         The version on the NT Server install CD will only allow monitoring
1171         of network traffic directed to the local NT box and broadcasts on the
1172         local subnet.  Be aware that Ethereal can read and write netmon
1173         formatted files.
1174         </P
1175 ></LI
1176 ><LI
1177 ><P
1178 >       <I
1179 CLASS="EMPHASIS"
1180 >How do I install 'Network Monitor' on an NT Workstation
1181         or a Windows 9x box?</I
1182 >
1183         </P
1184 ><P
1185 >       Installing netmon on an NT workstation requires a couple
1186         of steps.  The following are for installing Netmon V4.00.349, which comes
1187         with Microsoft Windows NT Server 4.0, on Microsoft Windows NT
1188         Workstation 4.0.  The process should be similar for other version of
1189         Windows NT / Netmon.  You will need both the Microsoft Windows
1190         NT Server 4.0 Install CD and the Workstation 4.0 Install CD.
1191         </P
1192 ><P
1193 >       Initially you will need to install 'Network Monitor Tools and Agent'
1194         on the NT Server.  To do this
1195         </P
1196 ><P
1197 ></P
1198 ><UL
1199 ><LI
1200 ><P
1201 >Goto Start - Settings - Control Panel -
1202                 Network - Services - Add </P
1203 ></LI
1204 ><LI
1205 ><P
1206 >Select the 'Network Monitor Tools and Agent' and
1207                 click on 'OK'.</P
1208 ></LI
1209 ><LI
1210 ><P
1211 >Click 'OK' on the Network Control Panel.
1212                 </P
1213 ></LI
1214 ><LI
1215 ><P
1216 >Insert the Windows NT Server 4.0 install CD
1217                 when prompted.</P
1218 ></LI
1219 ></UL
1220 ><P
1221 >       At this point the Netmon files should exist in
1222         <TT
1223 CLASS="FILENAME"
1224 >%SYSTEMROOT%\System32\netmon\*.*</TT
1225 >.
1226         Two subdirectories exist as well, <TT
1227 CLASS="FILENAME"
1228 >parsers\</TT
1229 >
1230         which contains the necessary DLL's for parsing the netmon packet
1231         dump, and <TT
1232 CLASS="FILENAME"
1233 >captures\</TT
1234 >.
1235         </P
1236 ><P
1237 >       In order to install the Netmon tools on an NT Workstation, you will
1238         first need to install the 'Network  Monitor Agent' from the Workstation
1239         install CD.
1240         </P
1241 ><P
1242 ></P
1243 ><UL
1244 ><LI
1245 ><P
1246 >Goto Start - Settings - Control Panel -
1247                 Network - Services - Add</P
1248 ></LI
1249 ><LI
1250 ><P
1251 >Select the 'Network Monitor Agent' and click
1252                 on 'OK'.</P
1253 ></LI
1254 ><LI
1255 ><P
1256 >Click 'OK' on the Network Control Panel.
1257                 </P
1258 ></LI
1259 ><LI
1260 ><P
1261 >Insert the Windows NT Workstation 4.0 install
1262                 CD when prompted.</P
1263 ></LI
1264 ></UL
1265 ><P
1266 >       Now copy the files from the NT Server in %SYSTEMROOT%\System32\netmon\*.*
1267         to %SYSTEMROOT%\System32\netmon\*.* on the Workstation and set
1268         permissions as  you deem appropriate for your site. You will need
1269         administrative rights on the NT box to run netmon.
1270         </P
1271 ><P
1272 >       To install Netmon on a Windows 9x box install the network monitor agent
1273         from the Windows 9x CD (\admin\nettools\netmon).  There is a readme
1274         file located with the netmon driver files on the CD if you need
1275         information on how to do this.  Copy the files from a working
1276         Netmon installation.
1277         </P
1278 ></LI
1279 ><LI
1280 ><P
1281 >       The following is a list if helpful URLs and other links:
1282         </P
1283 ><P
1284 ></P
1285 ><UL
1286 ><LI
1287 ><P
1288 >Home of Samba site <A
1289 HREF="http://samba.org"
1290 TARGET="_top"
1291 >        http://samba.org</A
1292 >. We have a mirror near you !</P
1293 ></LI
1294 ><LI
1295 ><P
1296 > The <I
1297 CLASS="EMPHASIS"
1298 >Development</I
1299 > document
1300         on the Samba mirrors might mention your problem. If so,
1301         it might mean that the developers are working on it.</P
1302 ></LI
1303 ><LI
1304 ><P
1305 >See how Scott Merrill simulates a BDC behavior at
1306         <A
1307 HREF="http://www.skippy.net/linux/smb-howto.html"
1308 TARGET="_top"
1309 >        http://www.skippy.net/linux/smb-howto.html</A
1310 >. </P
1311 ></LI
1312 ><LI
1313 ><P
1314 >Although 2.0.7 has almost had its day as a PDC, David Bannon will
1315         keep the 2.0.7 PDC pages at <A
1316 HREF="http://bioserve.latrobe.edu.au/samba"
1317 TARGET="_top"
1318 >        http://bioserve.latrobe.edu.au/samba</A
1319 > going for a while yet.</P
1320 ></LI
1321 ><LI
1322 ><P
1323 >Misc links to CIFS information
1324         <A
1325 HREF="http://samba.org/cifs/"
1326 TARGET="_top"
1327 >http://samba.org/cifs/</A
1328 ></P
1329 ></LI
1330 ><LI
1331 ><P
1332 >NT Domains for Unix <A
1333 HREF="http://mailhost.cb1.com/~lkcl/ntdom/"
1334 TARGET="_top"
1335 >        http://mailhost.cb1.com/~lkcl/ntdom/</A
1336 ></P
1337 ></LI
1338 ><LI
1339 ><P
1340 >FTP site for older SMB specs:
1341         <A
1342 HREF="ftp://ftp.microsoft.com/developr/drg/CIFS/"
1343 TARGET="_top"
1344 >        ftp://ftp.microsoft.com/developr/drg/CIFS/</A
1345 ></P
1346 ></LI
1347 ></UL
1348 ></LI
1349 ></UL
1350 ><P
1351 ></P
1352 ><UL
1353 ><LI
1354 ><P
1355 >       <I
1356 CLASS="EMPHASIS"
1357 >How do I get help from the mailing lists?</I
1358 >
1359         </P
1360 ><P
1361 >       There are a number of Samba related mailing lists. Go to <A
1362 HREF="http://samba.org"
1363 TARGET="_top"
1364 >http://samba.org</A
1365 >, click on your nearest mirror
1366         and then click on <B
1367 CLASS="COMMAND"
1368 >Support</B
1369 > and then click on <B
1370 CLASS="COMMAND"
1371 >       Samba related mailing lists</B
1372 >.
1373         </P
1374 ><P
1375 >       For questions relating to Samba TNG go to
1376         <A
1377 HREF="http://www.samba-tng.org/"
1378 TARGET="_top"
1379 >http://www.samba-tng.org/</A
1380 >
1381         It has been requested that you don't post questions about Samba-TNG to the
1382         main stream Samba lists.</P
1383 ><P
1384 >       If you post a message to one of the lists please observe the following guide lines :
1385         </P
1386 ><P
1387 ></P
1388 ><UL
1389 ><LI
1390 ><P
1391 > Always remember that the developers are volunteers, they are
1392                 not paid and they never guarantee to produce a particular feature at
1393                 a particular time. Any time lines are 'best guess' and nothing more.
1394                 </P
1395 ></LI
1396 ><LI
1397 ><P
1398 > Always mention what version of samba you are using and what
1399                 operating system its running under. You should probably list the
1400         relevant sections of your smb.conf file, at least the options
1401         in [global] that affect PDC support.</P
1402 ></LI
1403 ><LI
1404 ><P
1405 >In addition to the version, if you obtained Samba via
1406         CVS mention the date when you last checked it out.</P
1407 ></LI
1408 ><LI
1409 ><P
1410 > Try and make your question clear and brief, lots of long,
1411                 convoluted questions get deleted before they are completely read !
1412                 Don't post html encoded messages (if you can select colour or font
1413                 size its html).</P
1414 ></LI
1415 ><LI
1416 ><P
1417 > If you run one of those nifty 'I'm on holidays' things when
1418                 you are away, make sure its configured  to not answer mailing lists.
1419                 </P
1420 ></LI
1421 ><LI
1422 ><P
1423 > Don't cross post. Work out which is the best list to post to
1424                 and see what happens, i.e. don't post to both samba-ntdom and samba-technical.
1425         Many people active on the lists subscribe to more
1426                 than one list and get annoyed to see the same message two or more times.
1427                 Often someone will see a message and thinking it would be better dealt
1428                 with on another, will forward it on for you.</P
1429 ></LI
1430 ><LI
1431 ><P
1432 >You might include <I
1433 CLASS="EMPHASIS"
1434 >partial</I
1435 >
1436         log files written at a debug level set to as much as 20.
1437         Please don't send the entire log but enough to give the context of the
1438         error messages.</P
1439 ></LI
1440 ><LI
1441 ><P
1442 >(Possibly) If you have a complete netmon trace ( from the opening of
1443         the pipe to the error ) you can send the *.CAP file as well.</P
1444 ></LI
1445 ><LI
1446 ><P
1447 >Please think carefully before attaching a document to an email.
1448         Consider pasting the relevant parts into the body of the message. The samba
1449         mailing lists go to a huge number of people, do they all need a copy of your
1450         smb.conf in their attach directory?</P
1451 ></LI
1452 ></UL
1453 ></LI
1454 ><LI
1455 ><P
1456 >       <I
1457 CLASS="EMPHASIS"
1458 >How do I get off the mailing lists?</I
1459 >
1460         </P
1461 ><P
1462 >To have your name removed from a samba mailing list, go to the
1463         same place you went to to get on it. Go to <A
1464 HREF="http://lists.samba.org/"
1465 TARGET="_top"
1466 >http://lists.samba.org</A
1467 >,
1468         click on your nearest mirror and then click on <B
1469 CLASS="COMMAND"
1470 >Support</B
1471 > and
1472         then click on <B
1473 CLASS="COMMAND"
1474 > Samba related mailing lists</B
1475 >. Or perhaps see
1476         <A
1477 HREF="http://lists.samba.org/mailman/roster/samba-ntdom"
1478 TARGET="_top"
1479 >here</A
1480 >
1481         </P
1482 ><P
1483 >       Please don't post messages to the list asking to be removed, you will just
1484         be referred to the above address (unless that process failed in some way...)
1485         </P
1486 ></LI
1487 ></UL
1488 ></DIV
1489 ><DIV
1490 CLASS="SECT1"
1491 ><HR><H1
1492 CLASS="SECT1"
1493 ><A
1494 NAME="AEN375"
1495 >Domain Control for Windows 9x/ME</A
1496 ></H1
1497 ><DIV
1498 CLASS="NOTE"
1499 ><BLOCKQUOTE
1500 CLASS="NOTE"
1501 ><P
1502 ><B
1503 >Note: </B
1504 >The following section contains much of the original
1505 DOMAIN.txt file previously included with Samba.  Much of
1506 the material is based on what went into the book <I
1507 CLASS="EMPHASIS"
1508 >Special
1509 Edition, Using Samba</I
1510 >, by Richard Sharpe.</P
1511 ></BLOCKQUOTE
1512 ></DIV
1513 ><P
1514 >A domain and a workgroup are exactly the same thing in terms of network
1515 browsing.  The difference is that a distributable authentication
1516 database is associated with a domain, for secure login access to a
1517 network.  Also, different access rights can be granted to users if they
1518 successfully authenticate against a domain logon server (NT server and
1519 other systems based on NT server support this, as does at least Samba TNG now).</P
1520 ><P
1521 >The SMB client logging on to a domain has an expectation that every other
1522 server in the domain should accept the same authentication information.
1523 Network browsing functionality of domains and workgroups is
1524 identical and is explained in BROWSING.txt. It should be noted, that browsing
1525 is totally orthogonal to logon support.</P
1526 ><P
1527 >Issues related to the single-logon network model are discussed in this
1528 section.  Samba supports domain logons, network logon scripts, and user
1529 profiles for MS Windows for workgroups and MS Windows 9X/ME clients
1530 which will be the focus of this section.</P
1531 ><P
1532 >When an SMB client in a domain wishes to logon it broadcast requests for a
1533 logon server.  The first one to reply gets the job, and validates its
1534 password using whatever mechanism the Samba administrator has installed.
1535 It is possible (but very stupid) to create a domain where the user
1536 database is not shared between servers, i.e. they are effectively workgroup
1537 servers advertising themselves as participating in a domain.  This
1538 demonstrates how authentication is quite different from but closely
1539 involved with domains.</P
1540 ><P
1541 >Using these features you can make your clients verify their logon via
1542 the Samba server; make clients run a batch file when they logon to
1543 the network and download their preferences, desktop and start menu.</P
1544 ><P
1545 >Before launching into the configuration instructions, it is
1546 worthwhile lookingat how a Windows 9x/ME client performs a logon:</P
1547 ><P
1548 ></P
1549 ><OL
1550 TYPE="1"
1551 ><LI
1552 ><P
1553 >       The client broadcasts (to the IP broadcast address of the subnet it is in)
1554         a NetLogon request. This is sent to the NetBIOS name DOMAIN&#60;1c&#62; at the
1555         NetBIOS layer.  The client chooses the first response it receives, which
1556         contains the NetBIOS name of the logon server to use in the format of
1557         \\SERVER.
1558         </P
1559 ></LI
1560 ><LI
1561 ><P
1562 >       The client then connects to that server, logs on (does an SMBsessetupX) and
1563         then connects to the IPC$ share (using an SMBtconX).
1564         </P
1565 ></LI
1566 ><LI
1567 ><P
1568 >       The client then does a NetWkstaUserLogon request, which retrieves the name
1569         of the user's logon script.
1570         </P
1571 ></LI
1572 ><LI
1573 ><P
1574 >       The client then connects to the NetLogon share and searches for this
1575         and if it is found and can be read, is retrieved and executed by the client.
1576         After this, the client disconnects from the NetLogon share.
1577         </P
1578 ></LI
1579 ><LI
1580 ><P
1581 >       The client then sends a NetUserGetInfo request to the server, to retrieve
1582         the user's home share, which is used to search for profiles. Since the
1583         response to the NetUserGetInfo request does not contain much more
1584         the user's home share, profiles for Win9X clients MUST reside in the user
1585         home directory.
1586         </P
1587 ></LI
1588 ><LI
1589 ><P
1590 >       The client then connects to the user's home share and searches for the
1591         user's profile. As it turns out, you can specify the user's home share as
1592         a sharename and path. For example, \\server\fred\.profile.
1593         If the profiles are found, they are implemented.
1594         </P
1595 ></LI
1596 ><LI
1597 ><P
1598 >       The client then disconnects from the user's home share, and reconnects to
1599         the NetLogon share and looks for CONFIG.POL, the policies file. If this is
1600         found, it is read and implemented.
1601         </P
1602 ></LI
1603 ></OL
1604 ><DIV
1605 CLASS="SECT2"
1606 ><HR><H2
1607 CLASS="SECT2"
1608 ><A
1609 NAME="AEN401"
1610 >Configuration Instructions:    Network Logons</A
1611 ></H2
1612 ><P
1613 >The main difference between a PDC and a Windows 9x logon
1614 server configuration is that</P
1615 ><P
1616 ></P
1617 ><UL
1618 ><LI
1619 ><P
1620 >Password encryption is not required for a Windows 9x logon server.</P
1621 ></LI
1622 ><LI
1623 ><P
1624 >Windows 9x/ME clients do not possess machine trust accounts.</P
1625 ></LI
1626 ></UL
1627 ><P
1628 >Therefore, a Samba PDC will also act as a Windows 9x logon
1629 server.</P
1630 ><DIV
1631 CLASS="WARNING"
1632 ><P
1633 ></P
1634 ><TABLE
1635 CLASS="WARNING"
1636 BORDER="1"
1637 WIDTH="100%"
1638 ><TR
1639 ><TD
1640 ALIGN="CENTER"
1641 ><B
1642 >security mode and master browsers</B
1643 ></TD
1644 ></TR
1645 ><TR
1646 ><TD
1647 ALIGN="LEFT"
1648 ><P
1649 >There are a few comments to make in order to tie up some
1650 loose ends.  There has been much debate over the issue of whether
1651 or not it is ok to configure Samba as a Domain Controller in security
1652 modes other than <TT
1653 CLASS="CONSTANT"
1654 >USER</TT
1655 >.  The only security mode
1656 which  will not work due to technical reasons is <TT
1657 CLASS="CONSTANT"
1658 >SHARE</TT
1659 >
1660 mode security.  <TT
1661 CLASS="CONSTANT"
1662 >DOMAIN</TT
1663 > and <TT
1664 CLASS="CONSTANT"
1665 >SERVER</TT
1666 >
1667 mode security is really just a variation on SMB user level security.</P
1668 ><P
1669 >Actually, this issue is also closely tied to the debate on whether
1670 or not Samba must be the domain master browser for its workgroup
1671 when operating as a DC.  While it may technically be possible
1672 to configure a server as such (after all, browsing and domain logons
1673 are two distinctly different functions), it is not a good idea to
1674 so.  You should remember that the DC must register the DOMAIN#1b NetBIOS
1675 name.  This is the name used by Windows clients to locate the DC.
1676 Windows clients do not distinguish between the DC and the DMB.
1677 For this reason, it is very wise to configure the Samba DC as the DMB.</P
1678 ><P
1679 >Now back to the issue of configuring a Samba DC to use a mode other
1680 than "security = user".  If a Samba host is configured to use
1681 another SMB server or DC in order to validate user connection
1682 requests, then it is a fact that some other machine on the network
1683 (the "password server") knows more about user than the Samba host.
1684 99% of the time, this other host is a domain controller.  Now
1685 in order to operate in domain mode security, the "workgroup" parameter
1686 must be set to the name of the Windows NT domain (which already
1687 has a domain controller, right?)</P
1688 ><P
1689 >Therefore configuring a Samba box as a DC for a domain that
1690 already by definition has a PDC is asking for trouble.
1691 Therefore, you should always configure the Samba DC to be the DMB
1692 for its domain.</P
1693 ></TD
1694 ></TR
1695 ></TABLE
1696 ></DIV
1697 ></DIV
1698 ><DIV
1699 CLASS="SECT2"
1700 ><HR><H2
1701 CLASS="SECT2"
1702 ><A
1703 NAME="AEN420"
1704 >Configuration Instructions:    Setting up Roaming User Profiles</A
1705 ></H2
1706 ><DIV
1707 CLASS="WARNING"
1708 ><P
1709 ></P
1710 ><TABLE
1711 CLASS="WARNING"
1712 BORDER="1"
1713 WIDTH="100%"
1714 ><TR
1715 ><TD
1716 ALIGN="CENTER"
1717 ><B
1718 >Warning</B
1719 ></TD
1720 ></TR
1721 ><TR
1722 ><TD
1723 ALIGN="LEFT"
1724 ><P
1725 ><I
1726 CLASS="EMPHASIS"
1727 >NOTE!</I
1728 > Roaming profiles support is different
1729 for Win9X and WinNT.</P
1730 ></TD
1731 ></TR
1732 ></TABLE
1733 ></DIV
1734 ><P
1735 >Before discussing how to configure roaming profiles, it is useful to see how
1736 Win9X and WinNT clients implement these features.</P
1737 ><P
1738 >Win9X clients send a NetUserGetInfo request to the server to get the user's
1739 profiles location. However, the response does not have room for a separate
1740 profiles location field, only the user's home share. This means that Win9X
1741 profiles are restricted to being in the user's home directory.</P
1742 ><P
1743 >WinNT clients send a NetSAMLogon RPC request, which contains many fields,
1744 including a separate field for the location of the user's profiles.
1745 This means that support for profiles is different for Win9X and WinNT.</P
1746 ><DIV
1747 CLASS="SECT3"
1748 ><HR><H3
1749 CLASS="SECT3"
1750 ><A
1751 NAME="AEN428"
1752 >Windows NT Configuration</A
1753 ></H3
1754 ><P
1755 >To support WinNT clients, in the [global] section of smb.conf set the
1756 following (for example):</P
1757 ><P
1758 ><PRE
1759 CLASS="PROGRAMLISTING"
1760 >logon path = \\profileserver\profileshare\profilepath\%U\moreprofilepath</PRE
1761 ></P
1762 ><P
1763 >The default for this option is \\%N\%U\profile, namely
1764 \\sambaserver\username\profile.  The \\N%\%U service is created
1765 automatically by the [homes] service.
1766 If you are using a samba server for the profiles, you _must_ make the
1767 share specified in the logon path browseable. </P
1768 ><DIV
1769 CLASS="NOTE"
1770 ><BLOCKQUOTE
1771 CLASS="NOTE"
1772 ><P
1773 ><B
1774 >Note: </B
1775 >[lkcl 26aug96 - we have discovered a problem where Windows clients can
1776 maintain a connection to the [homes] share in between logins.  The
1777 [homes] share must NOT therefore be used in a profile path.]</P
1778 ></BLOCKQUOTE
1779 ></DIV
1780 ></DIV
1781 ><DIV
1782 CLASS="SECT3"
1783 ><HR><H3
1784 CLASS="SECT3"
1785 ><A
1786 NAME="AEN436"
1787 >Windows 9X Configuration</A
1788 ></H3
1789 ><P
1790 >To support Win9X clients, you must use the "logon home" parameter. Samba has
1791 now been fixed so that "net use/home" now works as well, and it, too, relies
1792 on the "logon home" parameter.</P
1793 ><P
1794 >By using the logon home parameter, you are restricted to putting Win9X
1795 profiles in the user's home directory.   But wait! There is a trick you
1796 can use. If you set the following in the [global] section of your
1797 smb.conf file:</P
1798 ><P
1799 ><PRE
1800 CLASS="PROGRAMLISTING"
1801 >logon home = \\%L\%U\.profiles</PRE
1802 ></P
1803 ><P
1804 >then your Win9X clients will dutifully put their clients in a subdirectory
1805 of your home directory called .profiles (thus making them hidden).</P
1806 ><P
1807 >Not only that, but 'net use/home' will also work, because of a feature in
1808 Win9X. It removes any directory stuff off the end of the home directory area
1809 and only uses the server and share portion. That is, it looks like you
1810 specified \\%L\%U for "logon home".</P
1811 ></DIV
1812 ><DIV
1813 CLASS="SECT3"
1814 ><HR><H3
1815 CLASS="SECT3"
1816 ><A
1817 NAME="AEN444"
1818 >Win9X and WinNT Configuration</A
1819 ></H3
1820 ><P
1821 >You can support profiles for both Win9X and WinNT clients by setting both the
1822 "logon home" and "logon path" parameters. For example:</P
1823 ><P
1824 ><PRE
1825 CLASS="PROGRAMLISTING"
1826 >logon home = \\%L\%U\.profiles
1827 logon path = \\%L\profiles\%U</PRE
1828 ></P
1829 ><DIV
1830 CLASS="NOTE"
1831 ><BLOCKQUOTE
1832 CLASS="NOTE"
1833 ><P
1834 ><B
1835 >Note: </B
1836 >I have not checked what 'net use /home' does on NT when "logon home" is
1837 set as above.</P
1838 ></BLOCKQUOTE
1839 ></DIV
1840 ></DIV
1841 ><DIV
1842 CLASS="SECT3"
1843 ><HR><H3
1844 CLASS="SECT3"
1845 ><A
1846 NAME="AEN451"
1847 >Windows 9X Profile Setup</A
1848 ></H3
1849 ><P
1850 >When a user first logs in on Windows 9X, the file user.DAT is created,
1851 as are folders "Start Menu", "Desktop", "Programs" and "Nethood".
1852 These directories and their contents will be merged with the local
1853 versions stored in c:\windows\profiles\username on subsequent logins,
1854 taking the most recent from each.  You will need to use the [global]
1855 options "preserve case = yes", "short preserve case = yes" and
1856 "case sensitive = no" in order to maintain capital letters in shortcuts
1857 in any of the profile folders.</P
1858 ><P
1859 >The user.DAT file contains all the user's preferences.  If you wish to
1860 enforce a set of preferences, rename their user.DAT file to user.MAN,
1861 and deny them write access to this file.</P
1862 ><P
1863 ></P
1864 ><OL
1865 TYPE="1"
1866 ><LI
1867 ><P
1868 >       On the Windows 95 machine, go to Control Panel | Passwords and
1869         select the User Profiles tab.  Select the required level of
1870         roaming preferences.  Press OK, but do _not_ allow the computer
1871         to reboot.
1872         </P
1873 ></LI
1874 ><LI
1875 ><P
1876 >       On the Windows 95 machine, go to Control Panel | Network |
1877         Client for Microsoft Networks | Preferences.  Select 'Log on to
1878         NT Domain'.  Then, ensure that the Primary Logon is 'Client for
1879         Microsoft Networks'.  Press OK, and this time allow the computer
1880         to reboot.
1881         </P
1882 ></LI
1883 ></OL
1884 ><P
1885 >Under Windows 95, Profiles are downloaded from the Primary Logon.
1886 If you have the Primary Logon as 'Client for Novell Networks', then
1887 the profiles and logon script will be downloaded from your Novell
1888 Server.  If you have the Primary Logon as 'Windows Logon', then the
1889 profiles will be loaded from the local machine - a bit against the
1890 concept of roaming profiles, if you ask me.</P
1891 ><P
1892 >You will now find that the Microsoft Networks Login box contains
1893 [user, password, domain] instead of just [user, password].  Type in
1894 the samba server's domain name (or any other domain known to exist,
1895 but bear in mind that the user will be authenticated against this
1896 domain and profiles downloaded from it, if that domain logon server
1897 supports it), user name and user's password.</P
1898 ><P
1899 >Once the user has been successfully validated, the Windows 95 machine
1900 will inform you that 'The user has not logged on before' and asks you
1901 if you wish to save the user's preferences?  Select 'yes'.</P
1902 ><P
1903 >Once the Windows 95 client comes up with the desktop, you should be able
1904 to examine the contents of the directory specified in the "logon path"
1905 on the samba server and verify that the "Desktop", "Start Menu",
1906 "Programs" and "Nethood" folders have been created.</P
1907 ><P
1908 >These folders will be cached locally on the client, and updated when
1909 the user logs off (if you haven't made them read-only by then :-).
1910 You will find that if the user creates further folders or short-cuts,
1911 that the client will merge the profile contents downloaded with the
1912 contents of the profile directory already on the local client, taking
1913 the newest folders and short-cuts from each set.</P
1914 ><P
1915 >If you have made the folders / files read-only on the samba server,
1916 then you will get errors from the w95 machine on logon and logout, as
1917 it attempts to merge the local and the remote profile.  Basically, if
1918 you have any errors reported by the w95 machine, check the Unix file
1919 permissions and ownership rights on the profile directory contents,
1920 on the samba server.</P
1921 ><P
1922 >If you have problems creating user profiles, you can reset the user's
1923 local desktop cache, as shown below.  When this user then next logs in,
1924 they will be told that they are logging in "for the first time".</P
1925 ><P
1926 ></P
1927 ><OL
1928 TYPE="1"
1929 ><LI
1930 ><P
1931 >       instead of logging in under the [user, password, domain] dialog,
1932         press escape.
1933         </P
1934 ></LI
1935 ><LI
1936 ><P
1937 >       run the regedit.exe program, and look in:
1938         </P
1939 ><P
1940 >       HKEY_LOCAL_MACHINE\Windows\CurrentVersion\ProfileList
1941         </P
1942 ><P
1943 >       you will find an entry, for each user, of ProfilePath.  Note the
1944         contents of this key (likely to be c:\windows\profiles\username),
1945         then delete the key ProfilePath for the required user.
1946         </P
1947 ><P
1948 >       [Exit the registry editor].
1949         </P
1950 ></LI
1951 ><LI
1952 ><P
1953 >       <I
1954 CLASS="EMPHASIS"
1955 >WARNING</I
1956 > - before deleting the contents of the
1957         directory listed in
1958    the ProfilePath (this is likely to be c:\windows\profiles\username),
1959    ask them if they have any important files stored on their desktop
1960    or in their start menu.  delete the contents of the directory
1961    ProfilePath (making a backup if any of the files are needed).
1962         </P
1963 ><P
1964 >   This will have the effect of removing the local (read-only hidden
1965    system file) user.DAT in their profile directory, as well as the
1966    local "desktop", "nethood", "start menu" and "programs" folders.
1967         </P
1968 ></LI
1969 ><LI
1970 ><P
1971 >       search for the user's .PWL password-caching file in the c:\windows
1972         directory, and delete it.
1973         </P
1974 ></LI
1975 ><LI
1976 ><P
1977 >       log off the windows 95 client.
1978         </P
1979 ></LI
1980 ><LI
1981 ><P
1982 >       check the contents of the profile path (see "logon path" described
1983         above), and delete the user.DAT or user.MAN file for the user,
1984         making a backup if required.
1985         </P
1986 ></LI
1987 ></OL
1988 ><P
1989 >If all else fails, increase samba's debug log levels to between 3 and 10,
1990 and / or run a packet trace program such as tcpdump or netmon.exe, and
1991 look for any error reports.</P
1992 ><P
1993 >If you have access to an NT server, then first set up roaming profiles
1994 and / or netlogons on the NT server.  Make a packet trace, or examine
1995 the example packet traces provided with NT server, and see what the
1996 differences are with the equivalent samba trace.</P
1997 ></DIV
1998 ><DIV
1999 CLASS="SECT3"
2000 ><HR><H3
2001 CLASS="SECT3"
2002 ><A
2003 NAME="AEN487"
2004 >Windows NT Workstation 4.0</A
2005 ></H3
2006 ><P
2007 >When a user first logs in to a Windows NT Workstation, the profile
2008 NTuser.DAT is created.  The profile location can be now specified
2009 through the "logon path" parameter.  </P
2010 ><DIV
2011 CLASS="NOTE"
2012 ><BLOCKQUOTE
2013 CLASS="NOTE"
2014 ><P
2015 ><B
2016 >Note: </B
2017 >[lkcl 10aug97 - i tried setting the path to
2018 \\samba-server\homes\profile, and discovered that this fails because
2019 a background process maintains the connection to the [homes] share
2020 which does _not_ close down in between user logins.  you have to
2021 have \\samba-server\%L\profile, where user is the username created
2022 from the [homes] share].</P
2023 ></BLOCKQUOTE
2024 ></DIV
2025 ><P
2026 >There is a parameter that is now available for use with NT Profiles:
2027 "logon drive".  This should be set to "h:" or any other drive, and
2028 should be used in conjunction with the new "logon home" parameter.</P
2029 ><P
2030 >The entry for the NT 4.0 profile is a _directory_ not a file.  The NT
2031 help on profiles mentions that a directory is also created with a .PDS
2032 extension.  The user, while logging in, must have write permission to
2033 create the full profile path (and the folder with the .PDS extension)
2034 [lkcl 10aug97 - i found that the creation of the .PDS directory failed,
2035 and had to create these manually for each user, with a shell script.
2036 also, i presume, but have not tested, that the full profile path must
2037 be browseable just as it is for w95, due to the manner in which they
2038 attempt to create the full profile path: test existence of each path
2039 component; create path component].</P
2040 ><P
2041 >In the profile directory, NT creates more folders than 95.  It creates
2042 "Application Data" and others, as well as "Desktop", "Nethood",
2043 "Start Menu" and "Programs".  The profile itself is stored in a file
2044 NTuser.DAT.  Nothing appears to be stored in the .PDS directory, and
2045 its purpose is currently unknown.</P
2046 ><P
2047 >You can use the System Control Panel to copy a local profile onto
2048 a samba server (see NT Help on profiles: it is also capable of firing
2049 up the correct location in the System Control Panel for you).  The
2050 NT Help file also mentions that renaming NTuser.DAT to NTuser.MAN
2051 turns a profile into a mandatory one.</P
2052 ><DIV
2053 CLASS="NOTE"
2054 ><BLOCKQUOTE
2055 CLASS="NOTE"
2056 ><P
2057 ><B
2058 >Note: </B
2059 >[lkcl 10aug97 - i notice that NT Workstation tells me that it is
2060 downloading a profile from a slow link.  whether this is actually the
2061 case, or whether there is some configuration issue, as yet unknown,
2062 that makes NT Workstation _think_ that the link is a slow one is a
2063 matter to be resolved].</P
2064 ><P
2065 >[lkcl 20aug97 - after samba digest correspondence, one user found, and
2066 another confirmed, that profiles cannot be loaded from a samba server
2067 unless "security = user" and "encrypt passwords = yes" (see the file
2068 ENCRYPTION.txt) or "security = server" and "password server = ip.address.
2069 of.yourNTserver" are used.  Either of these options will allow the NT
2070 workstation to access the samba server using LAN manager encrypted
2071 passwords, without the user intervention normally required by NT
2072 workstation for clear-text passwords].</P
2073 ><P
2074 >[lkcl 25aug97 - more comments received about NT profiles: the case of
2075 the profile _matters_.  the file _must_ be called NTuser.DAT or, for
2076 a mandatory profile, NTuser.MAN].</P
2077 ></BLOCKQUOTE
2078 ></DIV
2079 ></DIV
2080 ><DIV
2081 CLASS="SECT3"
2082 ><HR><H3
2083 CLASS="SECT3"
2084 ><A
2085 NAME="AEN500"
2086 >Windows NT Server</A
2087 ></H3
2088 ><P
2089 >There is nothing to stop you specifying any path that you like for the
2090 location of users' profiles.  Therefore, you could specify that the
2091 profile be stored on a samba server, or any other SMB server, as long as
2092 that SMB server supports encrypted passwords.</P
2093 ></DIV
2094 ><DIV
2095 CLASS="SECT3"
2096 ><HR><H3
2097 CLASS="SECT3"
2098 ><A
2099 NAME="AEN503"
2100 >Sharing Profiles between W95 and NT Workstation 4.0</A
2101 ></H3
2102 ><DIV
2103 CLASS="WARNING"
2104 ><P
2105 ></P
2106 ><TABLE
2107 CLASS="WARNING"
2108 BORDER="1"
2109 WIDTH="100%"
2110 ><TR
2111 ><TD
2112 ALIGN="CENTER"
2113 ><B
2114 >Potentially outdated or incorrect material follows</B
2115 ></TD
2116 ></TR
2117 ><TR
2118 ><TD
2119 ALIGN="LEFT"
2120 ><P
2121 >I think this is all bogus, but have not deleted it. (Richard Sharpe)</P
2122 ></TD
2123 ></TR
2124 ></TABLE
2125 ></DIV
2126 ><P
2127 >The default logon path is \\%N\U%.  NT Workstation will attempt to create
2128 a directory "\\samba-server\username.PDS" if you specify the logon path
2129 as "\\samba-server\username" with the NT User Manager.  Therefore, you
2130 will need to specify (for example) "\\samba-server\username\profile".
2131 NT 4.0 will attempt to create "\\samba-server\username\profile.PDS", which
2132 is more likely to succeed.</P
2133 ><P
2134 >If you then want to share the same Start Menu / Desktop with W95, you will
2135 need to specify "logon path = \\samba-server\username\profile" [lkcl 10aug97
2136 this has its drawbacks: i created a shortcut to telnet.exe, which attempts
2137 to run from the c:\winnt\system32 directory.  this directory is obviously
2138 unlikely to exist on a Win95-only host].</P
2139 ><P
2140 >&#13;If you have this set up correctly, you will find separate user.DAT and
2141 NTuser.DAT files in the same profile directory.</P
2142 ><DIV
2143 CLASS="NOTE"
2144 ><BLOCKQUOTE
2145 CLASS="NOTE"
2146 ><P
2147 ><B
2148 >Note: </B
2149 >[lkcl 25aug97 - there are some issues to resolve with downloading of
2150 NT profiles, probably to do with time/date stamps.  i have found that
2151 NTuser.DAT is never updated on the workstation after the first time that
2152 it is copied to the local workstation profile directory.  this is in
2153 contrast to w95, where it _does_ transfer / update profiles correctly].</P
2154 ></BLOCKQUOTE
2155 ></DIV
2156 ></DIV
2157 ></DIV
2158 ></DIV
2159 ><DIV
2160 CLASS="SECT1"
2161 ><HR><H1
2162 CLASS="SECT1"
2163 ><A
2164 NAME="AEN513"
2165 >DOMAIN_CONTROL.txt : Windows NT Domain Control &#38; Samba</A
2166 ></H1
2167 ><DIV
2168 CLASS="WARNING"
2169 ><P
2170 ></P
2171 ><TABLE
2172 CLASS="WARNING"
2173 BORDER="1"
2174 WIDTH="100%"
2175 ><TR
2176 ><TD
2177 ALIGN="CENTER"
2178 ><B
2179 >Possibly Outdated Material</B
2180 ></TD
2181 ></TR
2182 ><TR
2183 ><TD
2184 ALIGN="LEFT"
2185 ><P
2186 >       This appendix was originally authored by John H Terpstra of
2187         the Samba Team and is included here for posterity.
2188         </P
2189 ></TD
2190 ></TR
2191 ></TABLE
2192 ></DIV
2193 ><P
2194 ><I
2195 CLASS="EMPHASIS"
2196 >NOTE :</I
2197 >
2198 The term "Domain Controller" and those related to it refer to one specific
2199 method of authentication that can underly an SMB domain. Domain Controllers
2200 prior to Windows NT Server 3.1 were sold by various companies and based on
2201 private extensions to the LAN Manager 2.1 protocol. Windows NT introduced
2202 Microsoft-specific ways of distributing the user authentication database.
2203 See DOMAIN.txt for examples of how Samba can participate in or create
2204 SMB domains based on shared authentication database schemes other than the
2205 Windows NT SAM.</P
2206 ><P
2207 >Windows NT Server can be installed as either a plain file and print server
2208 (WORKGROUP workstation or server) or as a server that participates in Domain
2209 Control (DOMAIN member, Primary Domain controller or Backup Domain controller).
2210 The same is true for OS/2 Warp Server, Digital Pathworks and other similar
2211 products, all of which can participate in Domain Control along with Windows NT.</P
2212 ><P
2213 >To many people these terms can be confusing, so let's try to clear the air.</P
2214 ><P
2215 >Every Windows NT system (workstation or server) has a registry database.
2216 The registry contains entries that describe the initialization information
2217 for all services (the equivalent of Unix Daemons) that run within the Windows
2218 NT environment. The registry also contains entries that tell application
2219 software where to find dynamically loadable libraries that they depend upon.
2220 In fact, the registry contains entries that describes everything that anything
2221 may need to know to interact with the rest of the system.</P
2222 ><P
2223 >The registry files can be located on any Windows NT machine by opening a
2224 command prompt and typing:</P
2225 ><P
2226 ><TT
2227 CLASS="PROMPT"
2228 >C:\WINNT\&#62;</TT
2229 > dir %SystemRoot%\System32\config</P
2230 ><P
2231 >The environment variable %SystemRoot% value can be obtained by typing:</P
2232 ><P
2233 ><TT
2234 CLASS="PROMPT"
2235 >C:\WINNT&#62;</TT
2236 >echo %SystemRoot%</P
2237 ><P
2238 >The active parts of the registry that you may want to be familiar with are
2239 the files called: default, system, software, sam and security.</P
2240 ><P
2241 >In a domain environment, Microsoft Windows NT domain controllers participate
2242 in replication of the SAM and SECURITY files so that all controllers within
2243 the domain have an exactly identical copy of each.</P
2244 ><P
2245 >The Microsoft Windows NT system is structured within a security model that
2246 says that all applications and services must authenticate themselves before
2247 they can obtain permission from the security manager to do what they set out
2248 to do.</P
2249 ><P
2250 >The Windows NT User database also resides within the registry. This part of
2251 the registry contains the user's security identifier, home directory, group
2252 memberships, desktop profile, and so on.</P
2253 ><P
2254 >Every Windows NT system (workstation as well as server) will have its own
2255 registry. Windows NT Servers that participate in Domain Security control
2256 have a database that they share in common - thus they do NOT own an
2257 independent full registry database of their own, as do Workstations and
2258 plain Servers.</P
2259 ><P
2260 >The User database is called the SAM (Security Access Manager) database and
2261 is used for all user authentication as well as for authentication of inter-
2262 process authentication (i.e. to ensure that the service action a user has
2263 requested is permitted within the limits of that user's privileges).</P
2264 ><P
2265 >The Samba team have produced a utility that can dump the Windows NT SAM into
2266 smbpasswd format: see ENCRYPTION.txt for information on smbpasswd and
2267 /pub/samba/pwdump on your nearest Samba mirror for the utility. This
2268 facility is useful but cannot be easily used to implement SAM replication
2269 to Samba systems.</P
2270 ><P
2271 >Windows for Workgroups, Windows 95, and Windows NT Workstations and Servers
2272 can participate in a Domain security system that is controlled by Windows NT
2273 servers that have been correctly configured. Almost every domain will have
2274 ONE Primary Domain Controller (PDC). It is desirable that each domain will
2275 have at least one Backup Domain Controller (BDC).</P
2276 ><P
2277 >The PDC and BDCs then participate in replication of the SAM database so that
2278 each Domain Controlling participant will have an up to date SAM component
2279 within its registry.</P
2280 ></DIV
2281 ></DIV
2282 ></BODY
2283 ></HTML
2284 >