From 3d6bb1823c3a82958ee2b80be4f953e23703eb9d Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Wed, 30 Apr 2003 21:26:24 +0000 Subject: Docbook XML conversion: projdoc (This used to be commit f7c9df751459da2d4a996d5f0135334fb3f87f69) --- docs/docbook/projdoc/Samba-PDC-HOWTO.xml | 842 +++++++++++++++++++++++++++++++ 1 file changed, 842 insertions(+) create mode 100644 docs/docbook/projdoc/Samba-PDC-HOWTO.xml (limited to 'docs/docbook/projdoc/Samba-PDC-HOWTO.xml') diff --git a/docs/docbook/projdoc/Samba-PDC-HOWTO.xml b/docs/docbook/projdoc/Samba-PDC-HOWTO.xml new file mode 100644 index 0000000000..6a3bcacf17 --- /dev/null +++ b/docs/docbook/projdoc/Samba-PDC-HOWTO.xml @@ -0,0 +1,842 @@ + + + + + &author.jerry; + &author.jht; + + DavidBannon + + Samba Team +
dbannon@samba.org
+ + + (26 Apr 2001) + + + +Samba as an NT4 or Win2k Primary Domain Controller + + + + +Prerequisite Reading + + +Before you continue reading in this chapter, please make sure +that you are comfortable with configuring basic files services +in smb.conf and how to enable and administer password +encryption in Samba. Theses two topics are covered in the +&smb.conf; manpage. + + + + + + + + + +Background + + + +This article outlines the steps necessary for configuring Samba as a PDC. +It is necessary to have a working Samba server prior to implementing the +PDC functionality. + + + + + Domain logons for Windows NT 4.0 / 200x / XP Professional clients. + + + + Placing Windows 9x / Me clients in user level security + + + + Retrieving a list of users and groups from a Samba PDC to + Windows 9x / Me / NT / 200x / XP Professional clients + + + + Roaming Profiles + + + + Network/System Policies + + + + + +Roaming Profiles and System/Network policies are advanced network administration topics +that are covered separately in this document. + + + + +The following functionalities are new to the Samba 3.0 release: + + + + + Windows NT 4 domain trusts + + + + Adding users via the User Manager for Domains + + + + +The following functionalities are NOT provided by Samba 3.0: + + + + + SAM replication with Windows NT 4.0 Domain Controllers + (i.e. a Samba PDC and a Windows NT BDC or vice versa) + + + + Acting as a Windows 2000 Domain Controller (i.e. Kerberos and + Active Directory) + + + + +Please note that Windows 9x / Me / XP Home clients are not true members of a domain +for reasons outlined in this article. Therefore the protocol for +support of Windows 9x-style domain logons is completely different +from NT4 / Win2k type domain logons and has been officially supported for some +time. + + + +MS Windows XP Home edition is NOT able to join a domain and does not permit +the use of domain logons. + + + + +Implementing a Samba PDC can basically be divided into 3 broad +steps. + + + + + Configuring the Samba PDC + + + + Creating machine trust accounts and joining clients to the domain + + + + Adding and managing domain user accounts + + + + +There are other minor details such as user profiles, system +policies, etc... However, these are not necessarily specific +to a Samba PDC as much as they are related to Windows NT networking +concepts. + + + + + + +Configuring the Samba Domain Controller + + +The first step in creating a working Samba PDC is to +understand the parameters necessary in smb.conf. Here we +attempt to explain the parameters that are covered in +the &smb.conf; man page. + + + +Here is an example &smb.conf; for acting as a PDC: + + + +[global] + ; Basic server settings + netbios name = POGO + workgroup = NARNIA + + ; User and Machine Account Backends + ; Choices are: tdbsam, tdbsam_nua, smbpasswd, smbpasswd_nua, ldapsam, ldapsam_nua, ... + ; mysqlsam, xmlsam, guest + passdb backend = ldapsam, guest + + ; we should act as the domain and local master browser + os level = 64 + preferred master = yes + domain master = yes + local master = yes + + ; security settings (must user security = user) + security = user + + ; encrypted passwords are a requirement for a PDC + encrypt passwords = yes + + ; support domain logons + domain logons = yes + + ; where to store user profiles? + logon path = \\%N\profiles\%u + + ; where is a user's home directory and where should it be mounted at? + logon drive = H: + logon home = \\homeserver\%u + + ; specify a generic logon script for all users + ; this is a relative **DOS** path to the [netlogon] share + logon script = logon.cmd + +; necessary share for domain controller +[netlogon] + path = /usr/local/samba/lib/netlogon + read only = yes + write list = ntadmin + +; share for storing user profiles +[profiles] + path = /export/smb/ntprofile + read only = no + create mask = 0600 + directory mask = 0700 + + + +The above parameters make for a full set of parameters that may define the server's mode +of operation. The following parameters are the essentials alone: + + + workgroup = NARNIA + domain logons = Yes + security = User + + +The additional parameters shown in the longer listing above just makes for a +more complete environment. + + + +There are a couple of points to emphasize in the above configuration. + + + + + Encrypted passwords must be enabled. For more details on how + to do this, refer to the User Database chapter. + + + + The server must support domain logons and a + [netlogon] share + + + + The server must be the domain master browser in order for Windows + client to locate the server as a DC. Please refer to the various + Network Browsing documentation included with this distribution for + details. + + + + +Samba 3.0 offers a complete implementation of group mapping +between Windows NT groups and Unix groups (this is really quite +complicated to explain in a short space). + + + + + + +Creating Machine Trust Accounts and Joining Clients to the Domain + + +A machine trust account is a Samba account that is used to +authenticate a client machine (rather than a user) to the Samba +server. In Windows terminology, this is known as a "Computer +Account." + + +The password of a machine trust account acts as the shared secret for +secure communication with the Domain Controller. This is a security +feature to prevent an unauthorized machine with the same NetBIOS name +from joining the domain and gaining access to domain user/group +accounts. Windows NT, 200x, XP Professional clients use machine trust +accounts, but Windows 9x / Me / XP Home clients do not. Hence, a +Windows 9x / Me / XP Home client is never a true member of a domain +because it does not possess a machine trust account, and thus has no +shared secret with the domain controller. + + +A Windows PDC stores each machine trust account in the Windows +Registry. A Samba-3 PDC also has to store machine trust account information +in a suitable backend data store. With Samba-3 there can be multiple back-ends +for this including: + + + + + smbpasswd - the plain ascii file stored used by + earlier versions of Samba. This file configuration option requires + a Unix/Linux system account for EVERY entry (ie: both for user and for + machine accounts). This file will be located in the private + directory (default is /usr/local/samba/lib/private or on linux /etc/samba). + + + + smbpasswd_nua - This file is independant of the + system wide user accounts. The use of this back-end option requires + specification of the "non unix account range" option also. It is called + smbpasswd and will be located in the private directory. + + + + tdbsam - a binary database backend that will be + stored in the private directory in a file called + passwd.tdb. The key benefit of this binary format + file is that it can store binary objects that can not be accomodated + in the traditional plain text smbpasswd file. + + + + tdbsam_nua like the smbpasswd_nua option above, this + file allows the creation of arbitrary user and machine accounts without + requiring that account to be added to the system (/etc/passwd) file. It + too requires the specification of the "non unix account range" option + in the [globals] section of the &smb.conf; file. + + + + ldapsam - An LDAP based back-end. Permits the + LDAP server to be specified. eg: ldap://localhost or ldap://frodo.murphy.com + + + + ldapsam_nua - LDAP based back-end with no unix + account requirement, like smbpasswd_nua and tdbsam_nua above. + + + +Read the chapter about the User Database +for details. + + +The new tdbsam and ldapsam account backends store vastly more information than +smbpasswd is capable of. The new backend database includes capacity to specify +per user settings for many parameters, over-riding global settings given in the +smb.conf file. eg: logon drive, logon home, logon path, etc. + + + +A Samba PDC, however, stores each machine trust account in two parts, +as follows: + + + A Samba account, stored in the same location as user + LanMan and NT password hashes (currently + smbpasswd). The Samba account + possesses and uses only the NT password hash. + + A corresponding Unix account, typically stored in + /etc/passwd. (Future releases will alleviate the need to + create /etc/passwd entries.) + + + + +There are two ways to create machine trust accounts: + + + + Manual creation. Both the Samba and corresponding + Unix account are created by hand. + + "On-the-fly" creation. The Samba machine trust + account is automatically created by Samba at the time the client + is joined to the domain. (For security, this is the + recommended method.) The corresponding Unix account may be + created automatically or manually. + + + + + +Manual Creation of Machine Trust Accounts + + +The first step in manually creating a machine trust account is to +manually create the corresponding Unix account in +/etc/passwd. This can be done using +vipw or other 'add user' command that is normally +used to create new Unix accounts. The following is an example for a +Linux based Samba server: + + + + root# /usr/sbin/useradd -g 100 -d /dev/null -c "machine +nickname" -s /bin/false machine_name$ + + +root# passwd -l machine_name$ + + +On *BSD systems, this can be done using the 'chpass' utility: + + +root# chpass -a "machine_name$:*:101:100::0:0:Workstation machine_name:/dev/null:/sbin/nologin" + + + +The /etc/passwd entry will list the machine name +with a "$" appended, won't have a password, will have a null shell and no +home directory. For example a machine named 'doppy' would have an +/etc/passwd entry like this: + + + +doppy$:x:505:501:machine_nickname:/dev/null:/bin/false + + + +Above, machine_nickname can be any +descriptive name for the client, i.e., BasementComputer. +machine_name absolutely must be the NetBIOS +name of the client to be joined to the domain. The "$" must be +appended to the NetBIOS name of the client or Samba will not recognize +this as a machine trust account. + + + + +Now that the corresponding Unix account has been created, the next step is to create +the Samba account for the client containing the well-known initial +machine trust account password. This can be done using the smbpasswd(8) command +as shown here: + + + +root# smbpasswd -a -m machine_name + + + +where machine_name is the machine's NetBIOS +name. The RID of the new machine account is generated from the UID of +the corresponding Unix account. + + + + Join the client to the domain immediately + + + Manually creating a machine trust account using this method is the + equivalent of creating a machine trust account on a Windows NT PDC using + the "Server Manager". From the time at which the account is created + to the time which the client joins the domain and changes the password, + your domain is vulnerable to an intruder joining your domain using + a machine with the same NetBIOS name. A PDC inherently trusts + members of the domain and will serve out a large degree of user + information to such clients. You have been warned! + + + + + + +"On-the-Fly" Creation of Machine Trust Accounts + + +The second (and recommended) way of creating machine trust accounts is +simply to allow the Samba server to create them as needed when the client +is joined to the domain. + +Since each Samba machine trust account requires a corresponding +Unix account, a method for automatically creating the +Unix account is usually supplied; this requires configuration of the +add user script +option in smb.conf. This +method is not required, however; corresponding Unix accounts may also +be created manually. + + + +Below is an example for a RedHat 6.2 Linux system. + + + +[global] + # <...remainder of parameters...> + add user script = /usr/sbin/useradd -d /dev/null -g 100 -s /bin/false -M %u + + + + + +Joining the Client to the Domain + + +The procedure for joining a client to the domain varies with the +version of Windows. + + + +Windows 2000 + + + When the user elects to join the client to a domain, Windows prompts for + an account and password that is privileged to join the domain. A Samba administrative + account (i.e., a Samba account that has root privileges on the Samba server) must be + entered here; the operation will fail if an ordinary user account is given. + The password for this account should be set to a different password than the associated + /etc/passwd entry, for security reasons. + + + + The session key of the Samba administrative account acts as an + encryption key for setting the password of the machine trust + account. The machine trust account will be created on-the-fly, or + updated if it already exists. + + + + +Windows NT + + If the machine trust account was created manually, on the + Identification Changes menu enter the domain name, but do not + check the box "Create a Computer Account in the Domain." In this case, + the existing machine trust account is used to join the machine to + the domain. + + If the machine trust account is to be created + on-the-fly, on the Identification Changes menu enter the domain + name, and check the box "Create a Computer Account in the Domain." In + this case, joining the domain proceeds as above for Windows 2000 + (i.e., you must supply a Samba administrative account when + prompted). + + +Samba + Joining a samba client to a domain is documented in + the Domain Member chapter. + + + + + + + +Common Problems and Errors + + +I cannot include a '$' in a machine name + +A 'machine name' in (typically) /etc/passwd +of the machine name with a '$' appended. FreeBSD (and other BSD +systems?) won't create a user with a '$' in their name. + + + +The problem is only in the program used to make the entry. Once made, it works perfectly. +Create a user without the '$' using vipw to edit the entry, adding +the '$'. Or create the whole entry with vipw if you like, make sure you use a unique User ID! + + + + +I get told "You already have a connection to the Domain...." +or "Cannot join domain, the credentials supplied conflict with an +existing set.." when creating a machine trust account. + + +This happens if you try to create a machine trust account from the +machine itself and already have a connection (e.g. mapped drive) +to a share (or IPC$) on the Samba PDC. The following command +will remove all network drive connections: + + + +C:\WINNT\> net use * /d + + + +Further, if the machine is already a 'member of a workgroup' that +is the same name as the domain you are joining (bad idea) you will +get this message. Change the workgroup name to something else, it +does not matter what, reboot, and try again. + + + + +The system can not log you on (C000019B).... + +I joined the domain successfully but after upgrading +to a newer version of the Samba code I get the message, "The system +can not log you on (C000019B), Please try again or consult your +system administrator" when attempting to logon. + + + +This occurs when the domain SID stored in the secrets.tdb database +is changed. The most common cause of a change in domain SID is when +the domain name and/or the server name (netbios name) is changed. +The only way to correct the problem is to restore the original domain +SID or remove the domain client from the domain and rejoin. The domain +SID may be reset using either the net or rpcclient utilities. + + + +The reset or change the domain SID you can use the net command as follows: + + + net getlocalsid 'OLDNAME' + net setlocalsid 'SID' + + + + + + +The machine trust account for this computer either does not +exist or is not accessible. + + +When I try to join the domain I get the message "The machine account +for this computer either does not exist or is not accessible". What's +wrong? + + + +This problem is caused by the PDC not having a suitable machine trust account. +If you are using the add user script method to create +accounts then this would indicate that it has not worked. Ensure the domain +admin user system is working. + + + +Alternatively if you are creating account entries manually then they +have not been created correctly. Make sure that you have the entry +correct for the machine trust account in smbpasswd file on the Samba PDC. +If you added the account using an editor rather than using the smbpasswd +utility, make sure that the account name is the machine NetBIOS name +with a '$' appended to it ( i.e. computer_name$ ). There must be an entry +in both /etc/passwd and the smbpasswd file. Some people have reported +that inconsistent subnet masks between the Samba server and the NT +client have caused this problem. Make sure that these are consistent +for both client and server. + + + + +When I attempt to login to a Samba Domain from a NT4/W2K workstation, +I get a message about my account being disabled. + + +At first be ensure to enable the useraccounts with smbpasswd -e +%user%, this is normally done, when you create an account. + + + + + + + +Domain Control for Windows 9x/ME + + +A domain and a workgroup are exactly the same thing in terms of network +browsing. The difference is that a distributable authentication +database is associated with a domain, for secure login access to a +network. Also, different access rights can be granted to users if they +successfully authenticate against a domain logon server. Samba-3 does this +now in the same way that MS Windows NT/2K. + + + +The SMB client logging on to a domain has an expectation that every other +server in the domain should accept the same authentication information. +Network browsing functionality of domains and workgroups is identical and +is explained in this documentation under the browsing discussions. +It should be noted, that browsing is totally orthogonal to logon support. + + + +Issues related to the single-logon network model are discussed in this +section. Samba supports domain logons, network logon scripts, and user +profiles for MS Windows for workgroups and MS Windows 9X/ME clients +which are the focus of this section. + + + + +When an SMB client in a domain wishes to logon it broadcast requests for a +logon server. The first one to reply gets the job, and validates its +password using whatever mechanism the Samba administrator has installed. +It is possible (but very stupid) to create a domain where the user +database is not shared between servers, i.e. they are effectively workgroup +servers advertising themselves as participating in a domain. This +demonstrates how authentication is quite different from but closely +involved with domains. + + + + +Using these features you can make your clients verify their logon via +the Samba server; make clients run a batch file when they logon to +the network and download their preferences, desktop and start menu. + + + +Before launching into the configuration instructions, it is +worthwhile to look at how a Windows 9x/ME client performs a logon: + + + + + + The client broadcasts (to the IP broadcast address of the subnet it is in) + a NetLogon request. This is sent to the NetBIOS name DOMAIN<1c> at the + NetBIOS layer. The client chooses the first response it receives, which + contains the NetBIOS name of the logon server to use in the format of + \\SERVER. + + + + + + The client then connects to that server, logs on (does an SMBsessetupX) and + then connects to the IPC$ share (using an SMBtconX). + + + + + + The client then does a NetWkstaUserLogon request, which retrieves the name + of the user's logon script. + + + + + + The client then connects to the NetLogon share and searches for this + and if it is found and can be read, is retrieved and executed by the client. + After this, the client disconnects from the NetLogon share. + + + + + + The client then sends a NetUserGetInfo request to the server, to retrieve + the user's home share, which is used to search for profiles. Since the + response to the NetUserGetInfo request does not contain much more then + the user's home share, profiles for Win9X clients MUST reside in the user + home directory. + + + + + + The client then connects to the user's home share and searches for the + user's profile. As it turns out, you can specify the user's home share as + a sharename and path. For example, \\server\fred\.profile. + If the profiles are found, they are implemented. + + + + + + The client then disconnects from the user's home share, and reconnects to + the NetLogon share and looks for CONFIG.POL, the policies file. If this is + found, it is read and implemented. + + + + + + +Configuration Instructions: Network Logons + + +The main difference between a PDC and a Windows 9x logon +server configuration is that + + + + + +Password encryption is not required for a Windows 9x logon server. + + + +Windows 9x/ME clients do not possess machine trust accounts. + + + + + +Therefore, a Samba PDC will also act as a Windows 9x logon +server. + + + + +security mode and master browsers + + +There are a few comments to make in order to tie up some +loose ends. There has been much debate over the issue of whether +or not it is ok to configure Samba as a Domain Controller in security +modes other than USER. The only security mode +which will not work due to technical reasons is SHARE +mode security. DOMAIN and SERVER +mode security is really just a variation on SMB user level security. + + + +Actually, this issue is also closely tied to the debate on whether +or not Samba must be the domain master browser for its workgroup +when operating as a DC. While it may technically be possible +to configure a server as such (after all, browsing and domain logons +are two distinctly different functions), it is not a good idea to do +so. You should remember that the DC must register the DOMAIN#1b NetBIOS +name. This is the name used by Windows clients to locate the DC. +Windows clients do not distinguish between the DC and the DMB. +For this reason, it is very wise to configure the Samba DC as the DMB. + + + +Now back to the issue of configuring a Samba DC to use a mode other +than "security = user". If a Samba host is configured to use +another SMB server or DC in order to validate user connection +requests, then it is a fact that some other machine on the network +(the "password server") knows more about the user than the Samba host. +99% of the time, this other host is a domain controller. Now +in order to operate in domain mode security, the "workgroup" parameter +must be set to the name of the Windows NT domain (which already +has a domain controller, right?) + + + +Therefore configuring a Samba box as a DC for a domain that +already by definition has a PDC is asking for trouble. +Therefore, you should always configure the Samba DC to be the DMB +for its domain. + + + + + + -- cgit