4 >SAMBA Project Documentation</TITLE
7 CONTENT="Modular DocBook HTML Stylesheet Version 1.57"></HEAD
18 NAME="SAMBA-PROJECT-DOCUMENTATION"
25 NAME="SAMBA-PROJECT-DOCUMENTATION"
26 >SAMBA Project Documentation</A
41 >This book is a collection of HOWTOs added to Samba documentation over the years.
42 I try to ensure that all are current, but sometimes the is a larger job
43 than one person can maintain. The most recent version of this document
45 HREF="http://www.samba.org/"
47 >http://www.samba.org/</A
49 on the "Documentation" page. Please send updates to <A
50 HREF="mailto:jerry@samba.org"
66 >How to Install and Test SAMBA</A
73 >Step 0: Read the man pages</A
78 >Step 1: Building the Binaries</A
83 >Step 2: The all important step</A
88 >Step 3: Create the smb configuration file.</A
93 >Step 4: Test your config file with
102 >Step 5: Starting the smbd and nmbd</A
109 >Step 5a: Starting from inetd.conf</A
114 >Step 5b. Alternative: starting it as a daemon</A
121 >Step 6: Try listing the shares available on your
127 >Step 7: Try connecting with the unix client</A
132 >Step 8: Try connecting from a DOS, WfWg, Win9x, WinNT,
133 Win2k, OS/2, etc... client</A
138 >What If Things Don't Work?</A
145 >Diagnosing Problems</A
155 >Choosing the Protocol Level</A
160 >Printing from UNIX to a Client PC</A
170 >Mapping Usernames</A
175 >Other Character Sets</A
184 >LanMan and NT Password Encryption in Samba 2.x</A
196 >How does it work?</A
201 >Important Notes About Security</A
208 >Advantages of SMB Encryption</A
213 >Advantages of non-encrypted passwords</A
221 NAME="SMBPASSWDFILEFORMAT"
223 >The smbpasswd file</A
228 >The smbpasswd Command</A
233 >Setting up Samba to support LanManager Encryption</A
240 >Hosting a Microsoft Distributed File System tree on Samba</A
263 >Printing Support in Samba 2.2.x</A
282 >Creating [print$]</A
287 >Setting Drivers for Existing Printers</A
292 >Support a large number of printers</A
297 >Adding New Printers via the Windows NT APW</A
302 >Samba and Printer Ports</A
309 >The Imprints Toolset</A
316 >What is Imprints?</A
321 >Creating Printer Driver Packages</A
326 >The Imprints server</A
331 >The Installation Client</A
341 >Migration to from Samba 2.0.x to 2.2.x</A
348 >security = domain in Samba 2.x</A
355 >Joining an NT Domain with Samba 2.2</A
360 >Samba and Windows 2000 Domains</A
365 >Why is this better than security = server?</A
372 >How to Configure Samba 2.2 as a Primary Domain Controller</A
379 >Prerequisite Reading</A
389 >Configuring the Samba Domain Controller</A
394 >Creating Machine Trust Accounts and Joining Clients
402 >Manually creating machine trust accounts</A
407 >Creating machine trust accounts "on the fly"</A
414 >Common Problems and Errors</A
419 >System Policies and Profiles</A
424 >What other help can I get ?</A
429 >Domain Control for Windows 9x/ME</A
436 >Configuration Instructions: Network Logons</A
441 >Configuration Instructions: Setting up Roaming User Profiles</A
448 >Windows NT Configuration</A
453 >Windows 9X Configuration</A
458 >Win9X and WinNT Configuration</A
463 >Windows 9X Profile Setup</A
468 >Windows NT Workstation 4.0</A
473 >Windows NT Server</A
478 >Sharing Profiles between W95 and NT Workstation 4.0</A
487 >DOMAIN_CONTROL.txt : Windows NT Domain Control & Samba</A
494 >Unifed Logons between Windows NT and UNIX using Winbind</A
511 >What Winbind Provides</A
525 >How Winbind Works</A
532 >Microsoft Remote Procedure Calls</A
537 >Name Service Switch</A
542 >Pluggable Authentication Modules</A
547 >User and Group ID Allocation</A
559 >Installation and Configuration</A
576 >UNIX Permission Bits and WIndows NT Access Control Lists</A
583 >Viewing and changing UNIX permissions using the NT
589 >How to view file security on a Samba share</A
594 >Viewing file ownership</A
599 >Viewing file or directory permissions</A
611 >Directory Permissions</A
618 >Modifying file or directory permissions</A
623 >Interaction with the standard Samba create mask
629 >Interaction with the standard Samba file attribute
651 >How can I configure OS/2 Warp Connect or
652 OS/2 Warp 4 as a client for Samba?</A
657 >How can I configure OS/2 Warp 3 (not Connect),
658 OS/2 1.2, 1.3 or 2.x for Samba?</A
663 >Are there any other issues when OS/2 (any version)
664 is used as a client?</A
669 >How do I get printer driver download working
679 >HOWTO Access Samba source code via CVS</A
691 >CVS Access to samba.org</A
698 >Access via CVSweb</A
716 >Chapter 1. How to Install and Test SAMBA</A
724 >1.1. Step 0: Read the man pages</A
727 >The man pages distributed with SAMBA contain
728 lots of useful info that will help to get you started.
729 If you don't know how to read man pages then try
738 >nroff -man smbd.8 | more
743 >Other sources of information are pointed to
744 by the Samba web site,<A
745 HREF="http://www.samba.org/"
747 > http://www.samba.org</A
756 >1.2. Step 1: Building the Binaries</A
759 >To do this, first run the program <B
763 > in the source directory. This should automatically
764 configure Samba for your operating system. If you have unusual
765 needs then you may wish to run</P
778 >first to see what special options you can enable.
791 >will create the binaries. Once it's successfully
792 compiled you can use </P
804 >to install the binaries and manual pages. You can
805 separately install the binaries and/or man pages using</P
831 >Note that if you are upgrading for a previous version
832 of Samba you might like to know that the old versions of
833 the binaries will be renamed with a ".old" extension. You
834 can go back to the previous version with</P
847 >if you find this version a disaster!</P
855 >1.3. Step 2: The all important step</A
858 >At this stage you must fetch yourself a
859 coffee or other drink you find stimulating. Getting the rest
860 of the install right can sometimes be tricky, so you will
863 >If you have installed samba before then you can skip
872 >1.4. Step 3: Create the smb configuration file.</A
875 >There are sample configuration files in the examples
876 subdirectory in the distribution. I suggest you read them
877 carefully so you can see how the options go together in
878 practice. See the man page for all the options.</P
880 >The simplest useful configuration file would be
881 something like this:</P
890 CLASS="PROGRAMLISTING"
903 >which would allow connections by anyone with an
904 account on the server, using either their login name or
905 "homes" as the service name. (Note that I also set the
906 workgroup that Samba is part of. See BROWSING.txt for defails)</P
915 > file. You need to create it
918 >Make sure you put the smb.conf file in the same place
919 you specified in the<TT
925 >/usr/local/samba/lib/</TT
928 >For more information about security settings for the
929 [homes] share please refer to the document UNIX_SECURITY.txt.</P
937 >1.5. Step 4: Test your config file with
944 >It's important that you test the validity of your
948 > file using the testparm program.
949 If testparm runs OK then it will list the loaded services. If
950 not it will give an error message.</P
952 >Make sure it runs OK and that the services look
953 resonable before proceeding. </P
961 >1.6. Step 5: Starting the smbd and nmbd</A
964 >You must choose to start smbd and nmbd either
965 as daemons or from <B
969 to do both! Either you can put them in <TT
972 > and have them started on demand
976 >, or you can start them as
977 daemons either from the command line or in <TT
980 >. See the man pages for details
981 on the command line options. Take particular care to read
982 the bit about what user you need to be in order to start
983 Samba. In many cases you must be root.</P
985 >The main advantage of starting <B
992 > as a daemon is that they will
993 respond slightly more quickly to an initial connection
994 request. This is, however, unlikely to be a problem.</P
1001 >1.6.1. Step 5a: Starting from inetd.conf</A
1004 >NOTE; The following will be different if
1005 you use NIS or NIS+ to distributed services maps.</P
1011 What is defined at port 139/tcp. If nothing is defined
1012 then add a line like this:</P
1017 >netbios-ssn 139/tcp</B
1021 >similarly for 137/udp you should have an entry like:</P
1026 >netbios-ns 137/udp</B
1032 >/etc/inetd.conf</TT
1034 and add two lines something like this:</P
1043 CLASS="PROGRAMLISTING"
1044 > netbios-ssn stream tcp nowait root /usr/local/samba/bin/smbd smbd
1045 netbios-ns dgram udp wait root /usr/local/samba/bin/nmbd nmbd
1052 >The exact syntax of <TT
1054 >/etc/inetd.conf</TT
1056 varies between unixes. Look at the other entries in inetd.conf
1059 >NOTE: Some unixes already have entries like netbios_ns
1060 (note the underscore) in <TT
1064 You must either edit <TT
1070 >/etc/inetd.conf</TT
1071 > to make them consistant.</P
1073 >NOTE: On many systems you may need to use the
1074 "interfaces" option in smb.conf to specify the IP address
1075 and netmask of your interfaces. Run <B
1079 as root if you don't know what the broadcast is for your
1083 > tries to determine it at run
1084 time, but fails on somunixes. See the section on "testing nmbd"
1085 for a method of finding if you need to do this.</P
1087 >!!!WARNING!!! Many unixes only accept around 5
1088 parameters on the command line in <TT
1092 This means you shouldn't use spaces between the options and
1093 arguments, or you should use a script, and start the script
1102 >, perhaps just send
1103 it a HUP. If you have installed an earlier version of <B
1106 > then you may need to kill nmbd as well.</P
1114 >1.6.2. Step 5b. Alternative: starting it as a daemon</A
1117 >To start the server as a daemon you should create
1118 a script something like this one, perhaps calling
1131 CLASS="PROGRAMLISTING"
1133 /usr/local/samba/bin/smbd -D
1134 /usr/local/samba/bin/nmbd -D
1141 >then make it executable with <B
1147 >You can then run <B
1151 hand or execute it from <TT
1157 >To kill it send a kill signal to the processes
1166 >NOTE: If you use the SVR4 style init system then
1167 you may like to look at the <TT
1169 >examples/svr4-startup</TT
1171 script to make Samba fit into that system.</P
1180 >1.7. Step 6: Try listing the shares available on your
1200 >Your should get back a list of shares available on
1201 your server. If you don't then something is incorrectly setup.
1202 Note that this method can also be used to see what shares
1203 are available on other LanManager clients (such as WfWg).</P
1205 >If you choose user level security then you may find
1206 that Samba requests a password before it will list the shares.
1210 > man page for details. (you
1211 can force it to list the shares without a password by
1212 adding the option -U% to the command line. This will not work
1213 with non-Samba servers)</P
1221 >1.8. Step 7: Try connecting with the unix client</A
1233 > //yourhostname/aservice</I
1245 would be the name of the host where you installed <B
1254 any service you have defined in the <TT
1258 file. Try your user name if you just have a [homes] section
1264 >For example if your unix host is bambi and your login
1265 name is fred you would type:</P
1273 >smbclient //bambi/fred
1284 >1.9. Step 8: Try connecting from a DOS, WfWg, Win9x, WinNT,
1285 Win2k, OS/2, etc... client</A
1288 >Try mounting disks. eg:</P
1292 >C:\WINDOWS\> </TT
1296 >net use d: \\servername\service
1301 >Try printing. eg:</P
1305 >C:\WINDOWS\> </TT
1310 \\servername\spoolservice</B
1316 >C:\WINDOWS\> </TT
1325 >Celebrate, or send me a bug report!</P
1333 >1.10. What If Things Don't Work?</A
1336 >If nothing works and you start to think "who wrote
1337 this pile of trash" then I suggest you do step 2 again (and
1338 again) till you calm down.</P
1340 >Then you might read the file DIAGNOSIS.txt and the
1341 FAQ. If you are still stuck then try the mailing list or
1342 newsgroup (look in the README for details). Samba has been
1343 successfully installed at thousands of sites worldwide, so maybe
1344 someone else has hit your problem and has overcome it. You could
1345 also use the WWW site to scan back issues of the samba-digest.</P
1347 >When you fix the problem PLEASE send me some updates to the
1348 documentation (or source code) so that the next person will find it
1356 >1.10.1. Diagnosing Problems</A
1359 >If you have instalation problems then go to
1363 > to try to find the
1372 >1.10.2. Scope IDs</A
1375 >By default Samba uses a blank scope ID. This means
1376 all your windows boxes must also have a blank scope ID.
1377 If you really want to use a non-blank scope ID then you will
1378 need to use the -i <scope> option to nmbd, smbd, and
1379 smbclient. All your PCs will need to have the same setting for
1380 this to work. I do not recommend scope IDs.</P
1388 >1.10.3. Choosing the Protocol Level</A
1391 >The SMB protocol has many dialects. Currently
1392 Samba supports 5, called CORE, COREPLUS, LANMAN1,
1395 >You can choose what maximum protocol to support
1399 > file. The default is
1400 NT1 and that is the best for the vast majority of sites.</P
1402 >In older versions of Samba you may have found it
1403 necessary to use COREPLUS. The limitations that led to
1404 this have mostly been fixed. It is now less likely that you
1405 will want to use less than LANMAN1. The only remaining advantage
1406 of COREPLUS is that for some obscure reason WfWg preserves
1407 the case of passwords in this protocol, whereas under LANMAN1,
1408 LANMAN2 or NT1 it uppercases all passwords before sending them,
1409 forcing you to use the "password level=" option in some cases.</P
1411 >The main advantage of LANMAN2 and NT1 is support for
1412 long filenames with some clients (eg: smbclient, Windows NT
1415 >See the smb.conf(5) manual page for more details.</P
1417 >Note: To support print queue reporting you may find
1418 that you have to use TCP/IP as the default protocol under
1419 WfWg. For some reason if you leave Netbeui as the default
1420 it may break the print queue reporting on some systems.
1421 It is presumably a WfWg bug.</P
1429 >1.10.4. Printing from UNIX to a Client PC</A
1432 >To use a printer that is available via a smb-based
1433 server from a unix host you will need to compile the
1434 smbclient program. You then need to install the script
1435 "smbprint". Read the instruction in smbprint for more details.
1438 >There is also a SYSV style script that does much
1439 the same thing called smbprint.sysv. It contains instructions.</P
1450 >One area which sometimes causes trouble is locking.</P
1452 >There are two types of locking which need to be
1453 performed by a SMB server. The first is "record locking"
1454 which allows a client to lock a range of bytes in a open file.
1455 The second is the "deny modes" that are specified when a file
1458 >Samba supports "record locking" using the fcntl() unix system
1459 call. This is often implemented using rpc calls to a rpc.lockd process
1460 running on the system that owns the filesystem. Unfortunately many
1461 rpc.lockd implementations are very buggy, particularly when made to
1462 talk to versions from other vendors. It is not uncommon for the
1463 rpc.lockd to crash.</P
1465 >There is also a problem translating the 32 bit lock
1466 requests generated by PC clients to 31 bit requests supported
1467 by most unixes. Unfortunately many PC applications (typically
1468 OLE2 applications) use byte ranges with the top bit set
1469 as semaphore sets. Samba attempts translation to support
1470 these types of applications, and the translation has proved
1471 to be quite successful.</P
1473 >Strictly a SMB server should check for locks before
1474 every read and write call on a file. Unfortunately with the
1475 way fcntl() works this can be slow and may overstress the
1476 rpc.lockd. It is also almost always unnecessary as clients
1477 are supposed to independently make locking calls before reads
1478 and writes anyway if locking is important to them. By default
1479 Samba only makes locking calls when explicitly asked
1480 to by a client, but if you set "strict locking = yes" then it will
1481 make lock checking calls on every read and write. </P
1483 >You can also disable by range locking completely
1484 using "locking = no". This is useful for those shares that
1485 don't support locking or don't need it (such as cdroms). In
1486 this case Samba fakes the return codes of locking calls to
1487 tell clients that everything is OK.</P
1489 >The second class of locking is the "deny modes". These
1490 are set by an application when it opens a file to determine
1491 what types of access should be allowed simultaneously with
1492 its open. A client may ask for DENY_NONE, DENY_READ, DENY_WRITE
1493 or DENY_ALL. There are also special compatability modes called
1494 DENY_FCB and DENY_DOS.</P
1496 >You can disable share modes using "share modes = no".
1497 This may be useful on a heavily loaded server as the share
1498 modes code is very slow. See also the FAST_SHARE_MODES
1499 option in the Makefile for a way to do full share modes
1500 very fast using shared memory (if your OS supports it).</P
1508 >1.10.6. Mapping Usernames</A
1511 >If you have different usernames on the PCs and
1512 the unix server then take a look at the "username map" option.
1513 See the smb.conf man page for details.</P
1521 >1.10.7. Other Character Sets</A
1524 >If you have problems using filenames with accented
1525 characters in them (like the German, French or Scandinavian
1526 character sets) then I recommmend you look at the "valid chars"
1527 option in smb.conf and also take a look at the validchars
1528 package in the examples directory.</P
1537 >Chapter 2. LanMan and NT Password Encryption in Samba 2.x</A
1545 >2.1. Introduction</A
1548 >With the development of LanManager and Windows NT
1549 compatible password encryption for Samba, it is now able
1550 to validate user connections in exactly the same way as
1551 a LanManager or Windows NT server.</P
1553 >This document describes how the SMB password encryption
1554 algorithm works and what issues there are in choosing whether
1555 you want to use it. You should read it carefully, especially
1556 the part about security and the "PROS and CONS" section.</P
1564 >2.2. How does it work?</A
1567 >LanManager encryption is somewhat similar to UNIX
1568 password encryption. The server uses a file containing a
1569 hashed value of a user's password. This is created by taking
1570 the user's plaintext password, capitalising it, and either
1571 truncating to 14 bytes or padding to 14 bytes with null bytes.
1572 This 14 byte value is used as two 56 bit DES keys to encrypt
1573 a 'magic' eight byte value, forming a 16 byte value which is
1574 stored by the server and client. Let this value be known as
1575 the "hashed password".</P
1577 >Windows NT encryption is a higher quality mechanism,
1578 consisting of doing an MD4 hash on a Unicode version of the user's
1579 password. This also produces a 16 byte hash value that is
1582 >When a client (LanManager, Windows for WorkGroups, Windows
1583 95 or Windows NT) wishes to mount a Samba drive (or use a Samba
1584 resource), it first requests a connection and negotiates the
1585 protocol that the client and server will use. In the reply to this
1586 request the Samba server generates and appends an 8 byte, random
1587 value - this is stored in the Samba server after the reply is sent
1588 and is known as the "challenge". The challenge is different for
1589 every client connection.</P
1591 >The client then uses the hashed password (16 byte values
1592 described above), appended with 5 null bytes, as three 56 bit
1593 DES keys, each of which is used to encrypt the challenge 8 byte
1594 value, forming a 24 byte value known as the "response".</P
1596 >In the SMB call SMBsessionsetupX (when user level security
1597 is selected) or the call SMBtconX (when share level security is
1598 selected), the 24 byte response is returned by the client to the
1599 Samba server. For Windows NT protocol levels the above calculation
1600 is done on both hashes of the user's password and both responses are
1601 returned in the SMB call, giving two 24 byte values.</P
1603 >The Samba server then reproduces the above calculation, using
1604 its own stored value of the 16 byte hashed password (read from the
1608 > file - described later) and the challenge
1609 value that it kept from the negotiate protocol reply. It then checks
1610 to see if the 24 byte value it calculates matches the 24 byte value
1611 returned to it from the client.</P
1613 >If these values match exactly, then the client knew the
1614 correct password (or the 16 byte hashed value - see security note
1615 below) and is thus allowed access. If not, then the client did not
1616 know the correct password and is denied access.</P
1618 >Note that the Samba server never knows or stores the cleartext
1619 of the user's password - just the 16 byte hashed values derived from
1620 it. Also note that the cleartext password or 16 byte hashed values
1621 are never transmitted over the network - thus increasing security.</P
1629 >2.3. Important Notes About Security</A
1632 >The unix and SMB password encryption techniques seem similar
1633 on the surface. This similarity is, however, only skin deep. The unix
1634 scheme typically sends clear text passwords over the nextwork when
1635 logging in. This is bad. The SMB encryption scheme never sends the
1636 cleartext password over the network but it does store the 16 byte
1637 hashed values on disk. This is also bad. Why? Because the 16 byte hashed
1638 values are a "password equivalent". You cannot derive the user's
1639 password from them, but they could potentially be used in a modified
1640 client to gain access to a server. This would require considerable
1641 technical knowledge on behalf of the attacker but is perfectly possible.
1642 You should thus treat the smbpasswd file as though it contained the
1643 cleartext passwords of all your users. Its contents must be kept
1644 secret, and the file should be protected accordingly.</P
1646 >Ideally we would like a password scheme which neither requires
1647 plain text passwords on the net or on disk. Unfortunately this
1648 is not available as Samba is stuck with being compatible with
1649 other SMB systems (WinNT, WfWg, Win95 etc). </P
1669 >Note that Windows NT 4.0 Service pack 3 changed the
1670 default for permissible authentication so that plaintext
1673 > sent over the wire.
1674 The solution to this is either to switch to encrypted passwords
1675 with Samba or edit the Windows NT registry to re-enable plaintext
1676 passwords. See the document WinNT.txt for details on how to do
1679 >Other Microsoft operating systems which also exhibit
1680 this behavior includes</P
1686 >MS DOS Network client 3.0 with
1687 the basic network redirector installed</P
1691 >Windows 95 with the network redirector
1706 >All current release of
1707 Microsoft SMB/CIFS clients support authentication via the
1708 SMB Challenge/Response mechanism described here. Enabling
1709 clear text authentication does not disable the ability
1710 of the client to particpate in encrypted authentication.</P
1721 >2.3.1. Advantages of SMB Encryption</A
1728 >plain text passwords are not passed across
1729 the network. Someone using a network sniffer cannot just
1730 record passwords going to the SMB server.</P
1734 >WinNT doesn't like talking to a server
1735 that isn't using SMB encrypted passwords. It will refuse
1736 to browse the server if the server is also in user level
1737 security mode. It will insist on prompting the user for the
1738 password on each connection, which is very annoying. The
1739 only things you can do to stop this is to use SMB encryption.
1750 >2.3.2. Advantages of non-encrypted passwords</A
1757 >plain text passwords are not kept
1762 >uses same password file as other unix
1763 services such as login and ftp</P
1767 >you are probably already using other
1768 services (such as telnet and ftp) which send plain text
1769 passwords over the net, so sending them for SMB isn't
1782 NAME="SMBPASSWDFILEFORMAT"
1784 >The smbpasswd file</A
1787 >In order for Samba to participate in the above protocol
1788 it must be able to look up the 16 byte hashed values given a user name.
1789 Unfortunately, as the UNIX password value is also a one way hash
1790 function (ie. it is impossible to retrieve the cleartext of the user's
1791 password given the UNIX hash of it), a separate password file
1792 containing this 16 byte value must be kept. To minimise problems with
1793 these two password files, getting out of sync, the UNIX <TT
1803 >, is provided to generate
1804 a smbpasswd file from a UNIX <TT
1810 >To generate the smbpasswd file from your <TT
1814 > file use the following command :</P
1822 >cat /etc/passwd | mksmbpasswd.sh
1823 > /usr/local/samba/private/smbpasswd</B
1827 >If you are running on a system that uses NIS, use</P
1835 >ypcat passwd | mksmbpasswd.sh
1836 > /usr/local/samba/private/smbpasswd</B
1843 > program is found in
1844 the Samba source directory. By default, the smbpasswd file is
1849 >/usr/local/samba/private/smbpasswd</TT
1852 >The owner of the <TT
1854 >/usr/local/samba/private/</TT
1856 directory should be set to root, and the permissions on it should
1859 >chmod 500 /usr/local/samba/private</B
1863 >Likewise, the smbpasswd file inside the private directory should
1864 be owned by root and the permissions on is should be set to 0600
1867 >chmod 600 smbpasswd</B
1870 >The format of the smbpasswd file is (The line has been
1871 wrapped here. It should appear as one entry per line in
1872 your smbpasswd file.)</P
1881 CLASS="PROGRAMLISTING"
1882 >username:uid:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:
1883 [Account type]:LCT-<last-change-time>:Long name
1890 >Although only the <TT
1904 > XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX</I
1915 > last-change-time</I
1917 > sections are significant
1918 and are looked at in the Samba code.</P
1922 > important that there by 32
1923 'X' characters between the two ':' characters in the XXX sections -
1924 the smbpasswd and Samba code will fail to validate any entries that
1925 do not have 32 characters between ':' characters. The first XXX
1926 section is for the Lanman password hash, the second is for the
1927 Windows NT version.</P
1929 >When the password file is created all users have password entries
1930 consisting of 32 'X' characters. By default this disallows any access
1931 as this user. When a user has a password set, the 'X' characters change
1932 to 32 ascii hexadecimal digits (0-9, A-F). These are an ascii
1933 representation of the 16 byte hashed value of a user's password.</P
1935 >To set a user to have no password (not recommended), edit the file
1936 using vi, and replace the first 11 characters with the ascii text
1940 > (minus the quotes).</P
1942 >For example, to clear the password for user bob, his smbpasswd file
1943 entry would look like :</P
1952 CLASS="PROGRAMLISTING"
1953 > bob:100:NO PASSWORDXXXXXXXXXXXXXXXXXXXXX:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:[U ]:LCT-00000000:Bob's full name:/bobhome:/bobshell
1960 >If you are allowing users to use the smbpasswd command to set
1961 their own passwords, you may want to give users NO PASSWORD initially
1962 so they do not have to enter a previous password when changing to their
1963 new password (not recommended). In order for you to allow this the
1967 > program must be able to connect to the
1971 > daemon as that user with no password. Enable this
1972 by adding the line :</P
1976 >null passwords = yes</B
1979 >to the [global] section of the smb.conf file (this is why
1980 the above scenario is not recommended). Preferably, allocate your
1981 users a default password to begin with, so you do not have
1982 to enable this on your server.</P
1986 >This file should be protected very
1987 carefully. Anyone with access to this file can (with enough knowledge of
1988 the protocols) gain access to your SMB server. The file is thus more
1989 sensitive than a normal unix <TT
2000 >2.5. The smbpasswd Command</A
2003 >The smbpasswd command maintains the two 32 byte password fields
2004 in the smbpasswd file. If you wish to make it similar to the unix
2014 >/usr/local/samba/bin/</TT
2016 main Samba binary directory).</P
2018 >Note that as of Samba 1.9.18p4 this program <EM
2021 > setuid root (the new <B
2025 code enforces this restriction so it cannot be run this way by
2031 > now works in a client-server mode
2032 where it contacts the local smbd to change the user's password on its
2033 behalf. This has enormous benefits - as follows.</P
2039 >smbpasswd no longer has to be setuid root -
2040 an enormous range of potential security problems is
2048 > now has the capability
2049 to change passwords on Windows NT servers (this only works when
2050 the request is sent to the NT Primary Domain Controller if you
2051 are changing an NT Domain user's password).</P
2055 >To run smbpasswd as a normal user just type :</P
2069 >Old SMB password: </TT
2073 ><type old value here -
2074 or hit return if there was no old password></B
2080 >New SMB Password: </TT
2084 ><type new value>
2091 >Repeat New SMB Password: </TT
2095 ><re-type new value
2100 >If the old value does not match the current value stored for
2101 that user, or the two new values do not match each other, then the
2102 password will not be changed.</P
2104 >If invoked by an ordinary user it will only allow the user
2105 to change his or her own Samba password.</P
2107 >If run by the root user smbpasswd may take an optional
2108 argument, specifying the user name whose SMB password you wish to
2109 change. Note that when run as root smbpasswd does not prompt for
2110 or check the old password value, thus allowing root to set passwords
2111 for users who have forgotten their passwords.</P
2116 > is designed to work in the same way
2117 and be familiar to UNIX users who use the <B
2126 >For more details on using <B
2130 to the man page which will always be the definitive reference.</P
2138 >2.6. Setting up Samba to support LanManager Encryption</A
2141 >This is a very brief description on how to setup samba to
2142 support password encryption. </P
2149 >compile and install samba as usual</P
2153 >enable encrypted passwords in <TT
2156 > by adding the line <B
2160 > in the [global] section</P
2164 >create the initial <TT
2168 password file in the place you specified in the Makefile
2169 (--prefix=<dir>). See the notes under the <A
2170 HREF="#SMBPASSWDFILEFORMAT"
2171 >The smbpasswd File</A
2173 section earlier in the document for details.</P
2177 >Note that you can test things using smbclient.</P
2185 >Chapter 3. Hosting a Microsoft Distributed File System tree on Samba</A
2193 >3.1. Instructions</A
2196 >The Distributed File System (or Dfs) provides a means of
2197 separating the logical view of files and directories that users
2198 see from the actual physical locations of these resources on the
2199 network. It allows for higher availability, smoother storage expansion,
2200 load balancing etc. For more information about Dfs, refer to <A
2201 HREF="http://www.microsoft.com/NTServer/nts/downloads/winfeatures/NTSDistrFile/AdminGuide.asp"
2203 > Microsoft documentation</A
2206 >This document explains how to host a Dfs tree on a Unix
2207 machine (for Dfs-aware clients to browse) using Samba.</P
2209 >To enable SMB-based DFS for Samba, configure it with the
2215 > option. Once built, a
2216 Samba server can be made a Dfs server by setting the global
2218 HREF="smb.conf.5.html#HOSTMSDFS"
2226 > parameter in the <TT
2230 > file. You designate a share as a Dfs root using the share
2232 HREF="smb.conf.5.html#MSDFSROOT"
2240 > parameter. A Dfs root directory on
2241 Samba hosts Dfs links in the form of symbolic links that point
2242 to other servers. For example, a symbolic link
2245 >junction->msdfs:storage1\share1</TT
2247 the share directory acts as the Dfs junction. When Dfs-aware
2248 clients attempt to access the junction link, they are redirected
2249 to the storage location (in this case, \\storage1\share1).</P
2251 >Dfs trees on Samba work with all Dfs-aware clients ranging
2252 from Windows 95 to 2000.</P
2254 >Here's an example of setting up a Dfs tree on a Samba
2264 CLASS="PROGRAMLISTING"
2265 ># The smb.conf file:
2267 netbios name = SAMBA
2271 path = /export/dfsroot
2279 >In the /export/dfsroot directory we set up our dfs links to
2280 other servers on the network.</P
2288 >cd /export/dfsroot</B
2298 >chown root /export/dfsroot</B
2308 >chmod 755 /export/dfsroot</B
2318 >ln -s msdfs:storageA\\shareA linka</B
2328 >ln -s msdfs:serverB\\share,serverC\\share linkb</B
2332 >You should set up the permissions and ownership of
2333 the directory acting as the Dfs root such that only designated
2334 users can create, delete or modify the msdfs links. Also note
2335 that symlink names should be all lowercase. This limitation exists
2336 to have Samba avoid trying all the case combinations to get at
2337 the link name. Finally set up the symbolic links to point to the
2338 network shares you want, and start Samba.</P
2340 >Users on Dfs-aware clients can now browse the Dfs tree
2341 on the Samba server at \\samba\dfs. Accessing
2342 links linka or linkb (which appear as directories to the client)
2343 takes users directly to the appropriate shares on the network.</P
2357 >Windows clients need to be rebooted
2358 if a previously mounted non-dfs share is made a dfs
2359 root or vice versa. A better way is to introduce a
2360 new share and make it the dfs root.</P
2364 >Currently there's a restriction that msdfs
2365 symlink names should all be lowercase.</P
2369 >For security purposes, the directory
2370 acting as the root of the Dfs tree should have ownership
2371 and permissions set so that only designated users can
2372 modify the symbolic links in the directory.</P
2383 >Chapter 4. Printing Support in Samba 2.2.x</A
2391 >4.1. Introduction</A
2394 >Beginning with the 2.2.0 release, Samba supports
2395 the native Windows NT printing mechanisms implemented via
2396 MS-RPC (i.e. the SPOOLSS named pipe). Previous versions of
2397 Samba only supported LanMan printing calls.</P
2399 >The additional functionality provided by the new
2400 SPOOLSS support includes:</P
2406 >Support for downloading printer driver
2407 files to Windows 95/98/NT/2000 clients upon demand.
2412 >Uploading of printer drivers via the
2413 Windows NT Add Printer Wizard (APW) or the
2414 Imprints tool set (refer to <A
2415 HREF="http://imprints.sourceforge.net"
2417 >http://imprints.sourceforge.net</A
2423 >Support for the native MS-RPC printing
2424 calls such as StartDocPrinter, EnumJobs(), etc... (See
2425 the MSDN documentation at <A
2426 HREF="http://msdn.microsoft.com/"
2428 >http://msdn.microsoft.com/</A
2430 for more information on the Win32 printing API)
2435 >Support for NT Access Control Lists (ACL)
2436 on printer objects</P
2440 >Improved support for printer queue manipulation
2441 through the use of an internal databases for spooled job
2446 >There has been some initial confusion about what all this means
2447 and whether or not it is a requirement for printer drivers to be
2448 installed on a Samba host in order to support printing from Windows
2449 clients. A bug existed in Samba 2.2.0 which made Windows NT/2000 clients
2450 require that the Samba server possess a valid driver for the printer.
2451 This is fixed in Samba 2.2.1 and once again, Windows NT/2000 clients
2452 can use the local APW for installing drivers to be used with a Samba
2453 served printer. This is the same behavior exhibited by Windows 9x clients.
2454 As a side note, Samba does not use these drivers in any way to process
2455 spooled files. They are utilized entirely by the clients.</P
2457 >The following MS KB article, may be of some help if you are dealing with
2458 Windows 2000 clients: <EM
2459 >How to Add Printers with No User
2460 Interaction in Windows 2000</EM
2464 HREF="http://support.microsoft.com/support/kb/articles/Q189/1/05.ASP"
2466 >http://support.microsoft.com/support/kb/articles/Q189/1/05.ASP</A
2475 >4.2. Configuration</A
2489 >[print$] vs. [printer$]</B
2496 >Previous versions of Samba recommended using a share named [printer$].
2497 This name was taken from the printer$ service created by Windows 9x
2498 clients when a printer was shared. Windows 9x printer servers always have
2499 a printer$ service which provides read-only access via no
2500 password in order to support printer driver downloads.</P
2502 >However, the initial implementation allowed for a
2506 >printer driver location</I
2509 to be used on a per share basis to specify the location of
2510 the driver files associated with that printer. Another
2517 a means of defining the printer driver name to be sent to
2520 >These parameters, including <TT
2526 > parameter, are being depreciated and should not
2527 be used in new installations. For more information on this change,
2528 you should refer to the <A
2530 >Migration section</A
2532 of this document.</P
2543 >4.2.1. Creating [print$]</A
2546 >In order to support the uploading of printer driver
2547 files, you must first configure a file share named [print$].
2548 The name of this share is hard coded in Samba's internals so
2549 the name is very important (print$ is the service used by
2550 Windows NT print servers to provide support for printer driver
2553 >You should modify the server's smb.conf file to create the
2554 following file share (of course, some of the parameter values,
2555 such as 'path' are arbitrary and should be replaced with
2556 appropriate values for your site):</P
2565 CLASS="PROGRAMLISTING"
2567 path = /usr/local/samba/printers
2571 ; since this share is configured as read only, then we need
2572 ; a 'write list'. Check the file system permissions to make
2573 ; sure this account can copy files to the share. If this
2574 ; is setup to a non-root account, then it should also exist
2575 ; as a 'printer admin'
2576 write list = ntadmin</PRE
2583 HREF="smb.conf.5.html#WRITELIST"
2591 > is used to allow administrative
2592 level user accounts to have write access in order to update files
2593 on the share. See the <A
2594 HREF="smb./conf.5.html"
2598 > for more information on configuring file shares.</P
2600 >The requirement for <A
2601 HREF="smb.conf.5.html#GUESTOK"
2608 > depends upon how your
2609 site is configured. If users will be guaranteed to have
2610 an account on the Samba host, then this is a non-issue.</P
2618 >The non-issue is that if all your Windows NT users are guaranteed to be
2619 authenticated by the Samba server (such as a domain member server and the NT
2620 user has already been validated by the Domain Controller in
2621 order to logon to the Windows NT console), then guest access
2622 is not necessary. Of course, in a workgroup environment where
2623 you just want to be able to print without worrying about
2624 silly accounts and security, then configure the share for
2625 guest access. You'll probably want to add <A
2626 HREF="smb.conf.5.html#MAPTOGUEST"
2630 >map to guest = Bad User</B
2632 > in the [global] section as well. Make sure
2633 you understand what this parameter does before using it
2638 >In order for a Windows NT print server to support
2639 the downloading of driver files by multiple client architectures,
2640 it must create subdirectories within the [print$] service
2641 which correspond to each of the supported client architectures.
2642 Samba follows this model as well.</P
2644 >Next create the directory tree below the [print$] share
2645 for each architecture you wish to support.</P
2654 CLASS="PROGRAMLISTING"
2656 |-W32X86 ; "Windows NT x86"
2657 |-WIN40 ; "Windows 95/98"
2658 |-W32ALPHA ; "Windows NT Alpha_AXP"
2659 |-W32MIPS ; "Windows NT R4000"
2660 |-W32PPC ; "Windows NT PowerPC"</PRE
2677 >ATTENTION! REQUIRED PERMISSIONS</B
2684 >In order to currently add a new driver to you Samba host,
2685 one of two conditions must hold true:</P
2691 >The account used to connect to the Samba host
2692 must have a uid of 0 (i.e. a root account)</P
2696 >The account used to connect to the Samba host
2697 must be a member of the <A
2698 HREF="smb.conf.5.html#PRINTERADMIN"
2711 >Of course, the connected account must still possess access
2712 to add files to the subdirectories beneath [print$]. Remember
2713 that all file shares are set to 'read only' by default.</P
2719 >Once you have created the required [print$] service and
2720 associated subdirectories, simply log onto the Samba server using
2727 from a Windows NT 4.0 client. Navigate to the "Printers" folder
2728 on the Samba server. You should see an initial listing of printers
2729 that matches the printer shares defined on your Samba host.</P
2737 >4.2.2. Setting Drivers for Existing Printers</A
2740 >The initial listing of printers in the Samba host's
2741 Printers folder will have no real printer driver assigned
2742 to them. By default, in Samba 2.2.0 this driver name was set to
2744 >NO PRINTER DRIVER AVAILABLE FOR THIS PRINTER</EM
2746 Later versions changed this to a NULL string to allow the use
2747 tof the local Add Printer Wizard on NT/2000 clients.
2748 Attempting to view the printer properties for a printer
2749 which has this default driver assigned will result in
2750 the error message:</P
2753 >Device settings cannot be displayed. The driver
2754 for the specified printer is not installed, only spooler
2755 properties will be displayed. Do you want to install the
2759 >Click "No" in the error dialog and you will be presented with
2760 the printer properties window. The way assign a driver to a
2761 printer is to either</P
2767 >Use the "New Driver..." button to install
2768 a new printer driver, or</P
2772 >Select a driver from the popup list of
2773 installed drivers. Initially this list will be empty.</P
2777 >If you wish to install printer drivers for client
2778 operating systems other than "Windows NT x86", you will need
2779 to use the "Sharing" tab of the printer properties dialog.</P
2781 >Assuming you have connected with a root account, you
2782 will also be able modify other printer properties such as
2783 ACLs and device settings using this dialog box.</P
2785 >A few closing comments for this section, it is possible
2786 on a Windows NT print server to have printers
2787 listed in the Printers folder which are not shared. Samba does
2788 not make this distinction. By definition, the only printers of
2789 which Samba is aware are those which are specified as shares in
2795 >Another interesting side note is that Windows NT clients do
2796 not use the SMB printer share, but rather can print directly
2797 to any printer on another Windows NT host using MS-RPC. This
2798 of course assumes that the printing client has the necessary
2799 privileges on the remote host serving the printer. The default
2800 permissions assigned by Windows NT to a printer gives the "Print"
2801 permissions to the "Everyone" well-known group.</P
2809 >4.2.3. Support a large number of printers</A
2812 >One issue that has arisen during the development
2813 phase of Samba 2.2 is the need to support driver downloads for
2814 100's of printers. Using the Windows NT APW is somewhat
2815 awkward to say the list. If more than one printer are using the
2817 HREF="rpcclient.1.html"
2822 setdriver command</B
2824 > can be used to set the driver
2825 associated with an installed driver. The following is example
2826 of how this could be accomplished:</P
2835 CLASS="PROGRAMLISTING"
2840 >rpcclient pogo -U root%secret -c "enumdrivers"
2841 Domain=[NARNIA] OS=[Unix] Server=[Samba 2.2.0-alpha3]
2844 Printer Driver Info 1:
2845 Driver Name: [HP LaserJet 4000 Series PS]
2847 Printer Driver Info 1:
2848 Driver Name: [HP LaserJet 2100 Series PS]
2850 Printer Driver Info 1:
2851 Driver Name: [HP LaserJet 4Si/4SiMX PS]
2856 >rpcclient pogo -U root%secret -c "enumprinters"
2857 Domain=[NARNIA] OS=[Unix] Server=[Samba 2.2.0-alpha3]
2859 name:[\\POGO\hp-print]
2860 description:[POGO\\POGO\hp-print,NO DRIVER AVAILABLE FOR THIS PRINTER,]
2866 >rpcclient pogo -U root%secret \
2870 > -c "setdriver hp-print \"HP LaserJet 4000 Series PS\""
2871 Domain=[NARNIA] OS=[Unix] Server=[Samba 2.2.0-alpha3]
2872 Successfully set hp-print to driver HP LaserJet 4000 Series PS.</PRE
2884 >4.2.4. Adding New Printers via the Windows NT APW</A
2887 >By default, Samba offers all printer shares defined in <TT
2891 in the "Printers..." folder. Also existing in this folder is the Windows NT
2892 Add Printer Wizard icon. The APW will be show only if</P
2898 >The connected user is able to successfully
2899 execute an OpenPrinterEx(\\server) with administrative
2900 priviledges (i.e. root or <TT
2911 HREF="smb.conf.5.html#SHOWADDPRINTERWIZARD"
2917 add printer wizard = yes</I
2925 >In order to be able to use the APW to successfully add a printer to a Samba
2927 HREF="smb.conf.5.html#ADDPRINTERCOMMAND"
2936 > must have a defined value. The program
2937 hook must successfully add the printer to the system (i.e.
2941 > or appropriate files) and
2947 >When using the APW from a client, if the named printer share does
2951 > will execute the <TT
2957 > and reparse to the <TT
2961 to attempt to locate the new printer share. If the share is still not defined,
2962 an error of "Access Denied" is returned to the client. Note that the
2966 >add printer program</I
2968 > is executed under the context
2969 of the connected user, not necessarily a root account.</P
2971 >There is a complementing <A
2972 HREF="smb.conf.5.html#DELETEPRINTERCOMMAND"
2981 > for removing entries from the "Printers..."
2990 >4.2.5. Samba and Printer Ports</A
2993 >Windows NT/2000 print servers associate a port with each printer. These normally
2994 take the form of LPT1:, COM1:, FILE:, etc... Samba must also support the
2995 concept of ports associated with a printer. By default, only one printer port,
2996 named "Samba Printer Port", exists on a system. Samba does not really a port in
2997 order to print, rather it is a requirement of Windows clients. </P
2999 >Note that Samba does not support the concept of "Printer Pooling" internally
3000 either. This is when a logical printer is assigned to multiple ports as
3001 a form of load balancing or fail over.</P
3003 >If you require that multiple ports be defined for some reason,
3008 HREF="smb.conf.5.html#ENUMPORTSCOMMAND"
3017 > which can be used to define an external program
3018 that generates a listing of ports on a system.</P
3027 >4.3. The Imprints Toolset</A
3030 >The Imprints tool set provides a UNIX equivalent of the
3031 Windows NT Add Printer Wizard. For complete information, please
3032 refer to the Imprints web site at <A
3033 HREF="http://imprints.sourceforge.net/"
3035 > http://imprints.sourceforge.net/</A
3036 > as well as the documentation
3037 included with the imprints source distribution. This section will
3038 only provide a brief introduction to the features of Imprints.</P
3045 >4.3.1. What is Imprints?</A
3048 >Imprints is a collection of tools for supporting the goals
3055 >Providing a central repository information
3056 regarding Windows NT and 95/98 printer driver packages</P
3060 >Providing the tools necessary for creating
3061 the Imprints printer driver packages.</P
3065 >Providing an installation client which
3066 will obtain and install printer drivers on remote Samba
3067 and Windows NT 4 print servers.</P
3077 >4.3.2. Creating Printer Driver Packages</A
3080 >The process of creating printer driver packages is beyond
3081 the scope of this document (refer to Imprints.txt also included
3082 with the Samba distribution for more information). In short,
3083 an Imprints driver package is a gzipped tarball containing the
3084 driver files, related INF files, and a control file needed by the
3085 installation client.</P
3093 >4.3.3. The Imprints server</A
3096 >The Imprints server is really a database server that
3097 may be queried via standard HTTP mechanisms. Each printer
3098 entry in the database has an associated URL for the actual
3099 downloading of the package. Each package is digitally signed
3100 via GnuPG which can be used to verify that package downloaded
3101 is actually the one referred in the Imprints database. It is
3104 > recommended that this security check
3113 >4.3.4. The Installation Client</A
3116 >More information regarding the Imprints installation client
3117 is available in the <TT
3119 >Imprints-Client-HOWTO.ps</TT
3121 file included with the imprints source package.</P
3123 >The Imprints installation client comes in two forms.</P
3129 >a set of command line Perl scripts</P
3133 >a GTK+ based graphical interface to
3134 the command line perl scripts</P
3138 >The installation client (in both forms) provides a means
3139 of querying the Imprints database server for a matching
3140 list of known printer model names as well as a means to
3141 download and install the drivers on remote Samba and Windows
3142 NT print servers.</P
3144 >The basic installation process is in four steps and
3145 perl code is wrapped around <B
3161 CLASS="PROGRAMLISTING"
3163 foreach (supported architecture for a given driver)
3165 1. rpcclient: Get the appropriate upload directory
3166 on the remote server
3167 2. smbclient: Upload the driver files
3168 3. rpcclient: Issues an AddPrinterDriver() MS-RPC
3171 4. rpcclient: Issue an AddPrinterEx() MS-RPC to actually
3172 create the printer</PRE
3178 >One of the problems encountered when implementing
3179 the Imprints tool set was the name space issues between
3180 various supported client architectures. For example, Windows
3181 NT includes a driver named "Apple LaserWriter II NTX v51.8"
3182 and Windows 95 callsits version of this driver "Apple
3183 LaserWriter II NTX"</P
3185 >The problem is how to know what client drivers have
3186 been uploaded for a printer. As astute reader will remember
3187 that the Windows NT Printer Properties dialog only includes
3188 space for one printer driver name. A quick look in the
3189 Windows NT 4.0 system registry at</P
3193 >HKLM\System\CurrentControlSet\Control\Print\Environment
3197 >will reveal that Windows NT always uses the NT driver
3198 name. This is ok as Windows NT always requires that at least
3199 the Windows NT version of the printer driver is present.
3200 However, Samba does not have the requirement internally.
3201 Therefore, how can you use the NT driver name if is has not
3202 already been installed?</P
3204 >The way of sidestepping this limitation is to require
3205 that all Imprints printer driver packages include both the Intel
3206 Windows NT and 95/98 printer drivers and that NT driver is
3219 >Migration to from Samba 2.0.x to 2.2.x</A
3222 >Given that printer driver management has changed (we hope improved) in
3223 2.2 over prior releases, migration from an existing setup to 2.2 can
3224 follow several paths.</P
3226 >Windows clients have a tendency to remember things for quite a while.
3227 For example, if a Windows NT client has attached to a Samba 2.0 server,
3228 it will remember the server as a LanMan printer server. Upgrading
3229 the Samba host to 2.2 makes support for MSRPC printing possible, but
3230 the NT client will still remember the previous setting.</P
3232 >In order to give an NT client printing "amesia" (only necessary if you
3233 want to use the newer MSRPC printing functionality in Samba), delete
3234 the registry keys associated with the print server contained in
3237 >[HKLM\SYSTEM\CurrentControlSet\Control\Print]</TT
3239 spooler service on the client should be stopped prior to doing this:</P
3243 >C:\WINNT\ ></TT
3247 >net stop spooler</B
3252 >All the normal disclaimers about editing the registry go
3254 > Be careful, and know what you are doing.</P
3256 >The spooler service should be restarted after you have finished
3257 removing the appropriate registry entries by replacing the
3261 > command above with <B
3266 >Windows 9x clients will continue to use LanMan printing calls
3267 with a 2.2 Samba server so there is no need to perform any of these
3268 modifications on non-NT clients.</P
3288 >The following smb.conf parameters are considered to be depreciated and will
3289 be removed soon. Do not use them in new installations</P
3298 >printer driver file (G)</I
3308 >printer driver (S)</I
3318 >printer driver location (S)</I
3329 >Here are the possible scenarios for supporting migration:</P
3335 >If you do not desire the new Windows NT
3336 print driver support, nothing needs to be done.
3337 All existing parameters work the same.</P
3341 >If you want to take advantage of NT printer
3342 driver support but do not want to migrate the
3343 9x drivers to the new setup, the leave the existing
3344 printers.def file. When smbd attempts to locate a
3345 9x driver for the printer in the TDB and fails it
3346 will drop down to using the printers.def (and all
3347 associated parameters). The <B
3351 tool will also remain for backwards compatibility but will
3352 be moved to the "this tool is the old way of doing it"
3357 >If you install a Windows 9x driver for a printer
3358 on your Samba host (in the printing TDB), this information will
3359 take precedence and the three old printing parameters
3360 will be ignored (including print driver location).</P
3364 >If you want to migrate an existing <TT
3368 file into the new setup, the current only solution is to use the Windows
3369 NT APW to install the NT drivers and the 9x drivers. This can be scripted
3377 Imprints installation client at <A
3378 HREF="http://imprints.sourceforge.net/"
3380 >http://imprints.sourceforge.net/</A
3393 >Chapter 5. security = domain in Samba 2.x</A
3401 >5.1. Joining an NT Domain with Samba 2.2</A
3404 >In order for a Samba-2 server to join an NT domain,
3405 you must first add the NetBIOS name of the Samba server to the
3406 NT domain on the PDC using Server Manager for Domains. This creates
3407 the machine account in the domain (PDC) SAM. Note that you should
3408 add the Samba server as a "Windows NT Workstation or Server",
3411 > as a Primary or backup domain controller.</P
3413 >Assume you have a Samba-2 server with a NetBIOS name of
3417 > and are joining an NT domain called
3421 >, which has a PDC with a NetBIOS name
3425 > and two backup domain controllers
3426 with NetBIOS names <TT
3435 >In order to join the domain, first stop all Samba daemons
3436 and run the command:</P
3444 >smbpasswd -j DOM -r DOMPDC
3449 >as we are joining the domain DOM and the PDC for that domain
3450 (the only machine that has write access to the domain SAM database)
3451 is DOMPDC. If this is successful you will see the message:</P
3454 CLASS="COMPUTEROUTPUT"
3455 >smbpasswd: Joined domain DOM.</TT
3459 >in your terminal window. See the <A
3460 HREF="smbpasswd.8.html"
3463 > man page for more details.</P
3465 >There is existing development code to join a domain
3466 without having to create the machine trust account on the PDC
3467 beforehand. This code will hopefully be available soon
3468 in release branches as well.</P
3470 >This command goes through the machine account password
3471 change protocol, then writes the new (random) machine account
3472 password for this Samba server into a file in the same directory
3473 in which an smbpasswd file would be stored - normally :</P
3477 >/usr/local/samba/private</TT
3480 >In Samba 2.0.x, the filename looks like this:</P
3487 ><NT DOMAIN NAME></I
3501 > suffix stands for machine account
3502 password file. So in our example above, the file would be called:</P
3509 >In Samba 2.2, this file has been replaced with a TDB
3510 (Trivial Database) file named <TT
3516 >This file is created and owned by root and is not
3517 readable by any other user. It is the key to the domain-level
3518 security for your system, and should be treated as carefully
3519 as a shadow password file.</P
3521 >Now, before restarting the Samba daemons you must
3523 HREF="smb.conf.5.html"
3530 > file to tell Samba it should now use domain security.</P
3532 >Change (or add) your <A
3533 HREF="smb.conf.5.html#SECURITY"
3541 > line in the [global] section
3542 of your smb.conf to read:</P
3546 >security = domain</B
3550 HREF="smb.conf.5.html#WORKGROUP"
3558 > line in the [global] section to read: </P
3565 >as this is the name of the domain we are joining. </P
3567 >You must also have the parameter <A
3568 HREF="smb.conf.5.html#ENCRYPTPASSWORDS"
3573 >encrypt passwords</I
3580 > in order for your users to authenticate to the NT PDC.</P
3582 >Finally, add (or modify) a <A
3583 HREF="smb.conf.5.html#PASSWORDSERVER"
3588 >password server =</I
3591 > line in the [global]
3592 section to read: </P
3596 >password server = DOMPDC DOMBDC1 DOMBDC2</B
3599 >These are the primary and backup domain controllers Samba
3600 will attempt to contact in order to authenticate users. Samba will
3601 try to contact each of these servers in order, so you may want to
3602 rearrange this list in order to spread out the authentication load
3603 among domain controllers.</P
3605 >Alternatively, if you want smbd to automatically determine
3606 the list of Domain controllers to use for authentication, you may
3607 set this line to be :</P
3611 >password server = *</B
3614 >This method, which was introduced in Samba 2.0.6,
3615 allows Samba to use exactly the same mechanism that NT does. This
3616 method either broadcasts or uses a WINS database in order to
3617 find domain controllers to authenticate against.</P
3619 >Finally, restart your Samba daemons and get ready for
3620 clients to begin using domain security!</P
3628 >5.2. Samba and Windows 2000 Domains</A
3631 >Many people have asked regarding the state of Samba's ability to participate in
3632 a Windows 2000 Domain. Samba 2.2 is able to act as a member server of a Windows
3633 2000 domain operating in mixed or native mode.</P
3635 >There is much confusion between the circumstances that require a "mixed" mode
3636 Win2k DC and a when this host can be switched to "native" mode. A "mixed" mode
3637 Win2k domain controller is only needed if Windows NT BDCs must exist in the same
3638 domain. By default, a Win2k DC in "native" mode will still support
3639 NetBIOS and NTLMv1 for authentication of legacy clients such as Windows 9x and
3640 NT 4.0. Samba has the same requirements as a Windows NT 4.0 member server.</P
3642 >The steps for adding a Samba 2.2 host to a Win2k domain are the same as those
3643 for adding a Samba server to a Windows NT 4.0 domain. The only exception is that
3644 the "Server Manager" from NT 4 has been replaced by the "Active Directory Users and
3645 Computers" MMC (Microsoft Management Console) plugin.</P
3653 >5.3. Why is this better than security = server?</A
3656 >Currently, domain security in Samba doesn't free you from
3657 having to create local Unix users to represent the users attaching
3658 to your server. This means that if domain user <TT
3662 > attaches to your domain security Samba server, there needs
3663 to be a local Unix user fred to represent that user in the Unix
3664 filesystem. This is very similar to the older Samba security mode
3666 HREF="smb.conf.5.html#SECURITYEQUALSSERVER"
3668 >security = server</A
3670 where Samba would pass through the authentication request to a Windows
3671 NT server in the same way as a Windows 95 or Windows 98 server would.
3674 >Please refer to the <A
3679 > for information on a system to automatically
3680 assign UNIX uids and gids to Windows NT Domain users and groups.
3681 This code is available in development branches only at the moment,
3682 but will be moved to release branches soon.</P
3684 >The advantage to domain-level security is that the
3685 authentication in domain-level security is passed down the authenticated
3686 RPC channel in exactly the same way that an NT server would do it. This
3687 means Samba servers now participate in domain trust relationships in
3688 exactly the same way NT servers do (i.e., you can add Samba servers into
3689 a resource domain and have the authentication passed on from a resource
3690 domain PDC to an account domain PDC.</P
3692 >In addition, with <B
3694 >security = server</B
3696 daemon on a server has to keep a connection open to the
3697 authenticating server for as long as that daemon lasts. This can drain
3698 the connection resources on a Microsoft NT server and cause it to run
3699 out of available connections. With <B
3701 >security = domain</B
3703 however, the Samba daemons connect to the PDC/BDC only for as long
3704 as is necessary to authenticate the user, and then drop the connection,
3705 thus conserving PDC connection resources.</P
3707 >And finally, acting in the same manner as an NT server
3708 authenticating to a PDC means that as part of the authentication
3709 reply, the Samba server gets the user identification information such
3710 as the user SID, the list of NT groups the user belongs to, etc. All
3711 this information will allow Samba to be extended in the future into
3712 a mode the developers currently call appliance mode. In this mode,
3713 no local Unix users will be necessary, and Samba will generate Unix
3714 uids and gids from the information passed back from the PDC when a
3715 user is authenticated, making a Samba server truly plug and play
3716 in an NT domain environment. Watch for this code soon.</P
3720 > Much of the text of this document
3721 was first published in the Web magazine <A
3722 HREF="http://www.linuxworld.com"
3727 HREF="http://www.linuxworld.com/linuxworld/lw-1998-10/lw-10-samba.html"
3739 >Chapter 6. How to Configure Samba 2.2 as a Primary Domain Controller</A
3747 >6.1. Prerequisite Reading</A
3750 >Before you continue readingin this chapter, please make sure
3751 that you are comfortable with configuring basic files services
3752 in smb.conf and how to enable and administrate password
3753 encryption in Samba. Theses two topics are covered in the
3755 HREF="smb.conf.5.html"
3763 HREF="EMCRYPTION.html"
3765 >Encryption chapter</A
3767 of this HOWTO Collection.</P
3785 >Author's Note :</EM
3786 > This document is a combination
3787 of David Bannon's Samba 2.2 PDC HOWTO and the Samba NT Domain FAQ.
3788 Both documents are superceeded by this one.</P
3792 >Version of Samba prior to release 2.2 had marginal capabilities to
3793 act as a Windows NT 4.0 Primary Domain Controller (PDC). Beginning with
3794 Samba 2.2.0, we are proud to announce official support for Windows NT 4.0
3795 style domain logons from Windows NT 4.0 (through SP6) and Windows 2000 (through
3796 SP1) clients. This article outlines the steps necessary for configuring Samba
3797 as a PDC. It is necessary to have a working Samba server prior to implementing the