There are sample configuration files in the examples subdirectory in the distribution. I suggest you read them carefully so you can see how the options go together in practice. See the man page for all the options.

The simplest useful configuration file would be something like this:

	[global]
		workgroup = MYGROUP

	[homes]
		guest ok = no
		read only = no
	

This will allow connections by anyone with an account on the server, using either their login name or "homes" as the service name. (Note that the workgroup that Samba must also be set.)

Make sure you put the smb.conf file in the same place you specified in the Makefile (the default is to look for it in /usr/local/samba/lib/).

For more information about security settings for the [homes] share please refer to the chapter Securing Samba.

SWAT is a web-based interface that helps you configure samba. SWAT might not be available in the samba package on your platform, but in a separate package. Please read the swat manpage on compiling, installing and configuring swat from source.

To launch SWAT just run your favorite web browser and point it at http://localhost:901/. Replace localhost with the name of the computer you are running samba on if you are running samba on a different computer than your browser.

Note that you can attach to SWAT from any IP connected machine but connecting from a remote machine leaves your connection open to password sniffing as passwords will be sent in the clear over the wire.

“ Site that is running Samba on an AIX box. They are sharing out about 2 terabytes using samba. Samba was installed using smitty and the binaries. We seem to be experiencing a memory problem with this box. When I do a svmon -Pu the monitoring program shows that smbd has several processes of smbd running: ”

“ Is samba suppose to start this many different smbd processes? Or does it run as one smbd process? Also is it normal for it to be taking up this much memory? ”

Inuse * 4096 = amount of memory being used by this process

     Pid Command        Inuse      Pin     Pgsp  Virtual   64-bit    Mthrd
   20950 smbd           33098     1906      181     5017        N        N
   22262 smbd            9104     1906      5410
   21060 smbd            9048     1906      181     5479        N        N
   25972 smbd            8678     1906      181     5109        N        N
   24524 smbd            8674     1906      181     5105        N        N
   19262 smbd            8582     1906      181     5013        N        N
   20722 smbd            8572     1906      181     5003        N        N
   21454 smbd            8572     1906      181     5003        N        N
   28946 smbd            8567     1906      181     4996        N        N
   24076 smbd            8566     1906      181     4996        N        N
   20138 smbd            8566     1906      181     4996        N        N
   17608 smbd            8565     1906      181     4996        N        N
   21820 smbd            8565     1906      181     4996        N        N
   26940 smbd            8565     1906      181     4996        N        N
   19884 smbd            8565     1906      181     4996        N        N
    9912 smbd            8565     1906      181     4996        N        N
   25800 smbd            8564     1906      181     4995        N        N
   20452 smbd            8564     1906      181     4995        N        N
   18592 smbd            8562     1906      181     4993        N        N
   28216 smbd            8521     1906      181     4954        N        N
   19110 smbd            8404     1906      181     4862        N        N

   Total memory used:  841,592,832 bytes

Samba consists on three core programs: nmbd, smbd, winbindd. nmbd is the name server message daemon, smbd is the server message daemon, winbindd is the daemon that handles communication with Domain Controllers.

If your system is NOT running as a WINS server, then there will be one (1) single instance of nmbd running on your system. If it is running as a WINS server then there will be two (2) instances - one to handle the WINS requests.

smbd handles ALL connection requests and then spawns a new process for each client connection made. That is why you are seeing so many of them, one (1) per client connection.

winbindd will run as one or two daemons, depending on whether or not it is being run in "split mode" (in which case there will be two instances).

Your loopback device isn't working correctly. Make sure it's running.

We will describe user level security first, as it's simpler. In user level security, the client will send a session setup command directly after the protocol negotiation. This contains a username and password. The server can either accept or reject that username/password combination. Note that at this stage the server has no idea what share the client will eventually try to connect to, so it can't base the accept/reject on anything other than:

If the server accepts the username/password then the client expects to be able to mount shares (using a tree connection) without specifying a password. It expects that all access rights will be as the username/password specified in the session setup.

It is also possible for a client to send multiple session setup requests. When the server responds, it gives the client a uid to use as an authentication tag for that username/password. The client can maintain multiple authentication contexts in this way (WinDD is an example of an application that does this).

	security = user

Ok, now for share level security. In share level security, the client authenticates itself separately for each share. It will send a password along with each tree connection (share mount). It does not explicitly send a username with this operation. The client expects a password to be associated with each share, independent of the user. This means that Samba has to work out what username the client probably wants to use. It is never explicitly sent the username. Some commercial SMB servers such as NT actually associate passwords directly with shares in share level security, but Samba always uses the unix authentication scheme where it is a username/password pair that is authenticated, not a share/password pair.

To gain understanding of the MS Windows networking parallels to this, one should think in terms of MS Windows 9x/Me where one can create a shared folder that provides read-only or full access, with or without a password.

Many clients send a session setup even if the server is in share level security. They normally send a valid username but no password. Samba records this username in a list of possible usernames. When the client then does a tree connection it also adds to this list the name of the share they try to connect to (useful for home directories) and any users listed in the user = smb.conf line. The password is then checked in turn against these possible usernames. If a match is found then the client is authenticated as that user.

	security = share

When Samba is operating in security = domain mode, the Samba server has a domain security trust account (a machine account) and will cause all authentication requests to be passed through to the domain controllers.

        security = domain
        workgroup = "name_of_NT_domain"

root# smbpasswd -j DOMAIN_NAME -r PDC_NAME -U Administrator%password

root# net join -U Administrator%password

Both Samba 2.2 and 3.0 can join an Active Directory domain. This is possible even if the domain is run in native mode. Active Directory in native mode perfectly allows NT4-style domain members, contrary to popular belief. The only thing that Active Directory in native mode prohibits is Backup Domain Controllers running NT4.

If you are running Active Directory starting with Samba 3.0 you can however join as a native AD member. Why would you want to do that? Your security policy might prohibit the use of NT-compatible authentication protocols. All your machines are running Windows 2000 and above and all use full Kerberos. In this case Samba as a NT4-style domain would still require NT-compatible authentication data. Samba in AD-member mode can accept Kerberos.

	realm = your.kerberos.REALM
	security = ADS

	ads server = your.kerberos.server

Server security mode is a left over from the time when Samba was not capable of acting as a domain member server. It is highly recommended NOT to use this feature. Server security mode has many draw backs. The draw backs include:

In server security mode the Samba server reports to the client that it is in user level security. The client then does a session setup as described earlier. The Samba server takes the username/password that the client sends and attempts to login to the password server by sending exactly the same username/password that it got from the client. If that server is in user level security and accepts the password, then Samba accepts the clients connection. This allows the Samba server to use another SMB server as the password server.

You should also note that at the very start of all this, where the server tells the client what security level it is in, it also tells the client if it supports encryption. If it does then it supplies the client with a random cryptkey. The client will then send all passwords in encrypted form. Samba supports this type of encryption by default.

The parameter security = server means that Samba reports to clients that it is running in user mode but actually passes off all authentication requests to another user mode server. This requires an additional parameter password server that points to the real authentication server. That real authentication server can be another Samba server or can be a Windows NT server, the later natively capable of encrypted password support.

        encrypt passwords = Yes
        security = server
        password server = "NetBIOS_name_of_a_DC"

To some the nature of the Samba security mode is very obvious, but entirely wrong all the same. It is assumed that security = server means that Samba will act as a server. Not so! See above - this setting means that Samba will try to use another SMB server as its source of user authentication alone.

The smb.conf parameter security = domain does NOT really make Samba behave as a Domain Controller! This setting means we want Samba to be a domain member!

Guess! So many others do. But whatever you do, do NOT think that security = user makes Samba act as a domain member. Read the manufacturers manual before the warranty expires! See the Domain Member section of this Howto for more information.

Why does server_validate() simply give up rather than re-establishing its connection to the password server? Though I am not fluent in the SMB protocol, perhaps the cluster server process passes along to its client workstation the session key it receives from the password server, which means the password hashes submitted by the client would not work on a subsequent connection, whose session key would be different. So server_validate() must give up.

Indeed. That's why security = server is at best a nasty hack. Please use security = domain. security = server mode is also known as pass-through authentication.

The Primary Domain Controller or PDC plays an important role in the MS Windows NT4 and Windows 200x Domain Control architecture, but not in the manner that so many expect. There is folk lore that dictates that because of it's role in the MS Windows network, the PDC should be the most powerful and most capable machine in the network. As strange as it may seem to say this here, good over all network performance dictates that the entire infrastructure needs to be balanced. It is advisable to invest more in the Backup Domain Controllers and Stand-Alone (or Domain Member) servers than in the PDC.

In the case of MS Windows NT4 style domains, it is the PDC seeds the Domain Control database, a part of the Windows registry called the SAM (Security Account Manager). It plays a key part in NT4 type domain user authentication and in synchronisation of the domain authentication database with Backup Domain Controllers.

With MS Windows 200x Server based Active Directory domains, one domain controller seeds a potential hierarchy of domain controllers, each with their own area of delegated control. The master domain controller has the ability to override any down-stream controller, but a down-line controller has control only over it's down-line. With Samba-3 this functionality can be implemented using an LDAP based user and machine account back end.

New to Samba-3 is the ability to use a back-end database that holds the same type of data as the NT4 style SAM (Security Account Manager) database (one of the registry files). The Samba-3 SAM can be specified via the smb.conf file parameter passwd backend and valid options include smbpasswd, tdbsam, ldapsam, nisplussam, xmlsam, mysqlsam, guest.

The Backup Domain Controller or BDC plays a key role in servicing network authentication requests. The BDC is biased to answer logon requests in preference to the PDC. On a network segment that has a BDC and a PDC the BDC will be most likely to service network logon requests. The PDC will answer network logon requests when the BDC is too busy (high load). A BDC can be promoted to a PDC. If the PDC is on line at the time that a BDC is promoted to PDC, the previous PDC is automatically demoted to a BDC. With Samba-3 this is NOT an automatic operation; the PDC and BDC must be manually configured and changes need to be made likewise.

With MS Windows NT4, it is an install time decision what type of machine the server will be. It is possible to change the promote a BDC to a PDC and vice versa only, but the only way to convert a domain controller to a domain member server or a stand-alone server is to reinstall it. The install time choices offered are:

With MS Windows 2000 the configuration of domain control is done after the server has been installed. Samba-3 is capable of acting fully as a native member of a Windows 200x server Active Directory domain.

New to Samba-3 is the ability to function fully as an MS Windows NT4 style Domain Controller, excluding the SAM replication components. However, please be aware that Samba-3 support the MS Windows 200x domain control protocols also.

At this time any appearance that Samba-3 is capable of acting as an ADS Domain Controller is limited and experimental in nature. This functionality should not be used until the Samba-Team offers formal support for it. At such a time, the documentation will be revised to duly reflect all configuration and management requirements.

There are two ways that MS Windows machines may interact with each other, with other servers, and with Domain Controllers: Either as Stand-Alone systems, more commonly called Workgroup members, or as full participants in a security system, more commonly called Domain members.

It should be noted that Workgroup membership involve no special configuration other than the machine being configured so that the network configuration has a commonly used name for it's workgroup entry. It is not uncommon for the name WORKGROUP to be used for this. With this mode of configuration there are NO machine trust accounts and any concept of membership as such is limited to the fact that all machines appear in the network neighbourhood to be logically grouped together. Again, just to be clear: workgroup mode does not involve any security machine accounts.

Domain member machines have a machine account in the Domain accounts database. A special procedure must be followed on each machine to affect Domain membership. This procedure, which can be done only by the local machine Administrator account, will create the Domain machine account (if if does not exist), and then initializes that account. When the client first logs onto the Domain it triggers a machine password change.

The following are necessary for configuring Samba-3 as an MS Windows NT4 style PDC for MS Windows NT4 / 200x / XP clients.

The following provisions are required to serve MS Windows 9x / Me Clients:

A Domain Controller is an SMB/CIFS server that:

For Samba to provide these is rather easy to configure. Each Samba Domain Controller must provide the NETLOGON service which Samba calls the domain logons functionality (after the name of the parameter in the smb.conf file). Additionally, one (1) server in a Samba-3 Domain must advertise itself as the domain master browser. This causes the Primary Domain Controller to claim domain specific NetBIOS name that identifies it as a domain master browser for its given domain/workgroup. Local master browsers in the same domain/workgroup on broadcast-isolated subnets then ask for a complete copy of the browse list for the whole wide area network. Browser clients will then contact their local master browser, and will receive the domain-wide browse list, instead of just the list for their broadcast-isolated subnet.

All Domain Controllers must run the netlogon service (domain logons in Samba). One Domain Controller must be configured with domain master = Yes (the Primary Domain Controller); on ALL Backup Domain Controllers domain master = No must be set.

	[global]
		domain logons = Yes
		domain master = (Yes on PDC, No on BDCs)

	[netlogon]
		comment = Network Logon Service
		path = /var/lib/samba/netlogon
		guest ok = Yes
		browseable = No

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 are 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). If the domain does NOT already have a Domain Controller then you do not yet have a Domain!

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 and set security = user. This is the only officially supported mode of operation.

A 'machine account', (typically) stored in /etc/passwd, takes the form 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 '$'. Then use 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!

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.

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.

root# net getlocalsid 'OLDNAME'
root# net setlocalsid 'SID'

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 machine 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 also reported that inconsistent subnet masks between the Samba server and the NT client can cause this problem. Make sure that these are consistent for both client and server.

Enable the user accounts with smbpasswd -e username , this is normally done as an account is created.

A domain controller has to announce on the network who it is. This usually takes a while.

Whenever a user logs into a Windows NT4 / 200x / XP Professional Workstation, the workstation connects to a Domain Controller (authentication server) to validate the username and password that the user entered are valid. If the information entered does not validate against the account information that has been stored in the Domain Control database (the SAM, or Security Account Manager database) then a set of error codes is returned to the workstation that has made the authentication request.

When the username / password pair has been validated, the Domain Controller (authentication server) will respond with full enumeration of the account information that has been stored regarding that user in the User and Machine Accounts database for that Domain. This information contains a complete network access profile for the user but excludes any information that is particular to the user's desktop profile, or for that matter it excludes all desktop profiles for groups that the user may belong to. It does include password time limits, password uniqueness controls, network access time limits, account validity information, machine names from which the user may access the network, and much more. All this information was stored in the SAM in all versions of MS Windows NT (3.10, 3.50, 3.51, 4.0).

The account information (user and machine) on Domain Controllers is stored in two files, one containing the Security information and the other the SAM. These are stored in files by the same name in the C:\WinNT\System32\config directory. These are the files that are involved in replication of the SAM database where Backup Domain Controllers are present on the network.

There are two situations in which it is desirable to install Backup Domain Controllers:

The PDC contains the master copy of the SAM. In the event that an administrator makes a change to the user account database while physically present on the local network that has the PDC, the change will likely be made directly to the PDC instance of the master copy of the SAM. In the event that this update may be performed in a branch office the change will likely be stored in a delta file on the local BDC. The BDC will then send a trigger to the PDC to commence the process of SAM synchronisation. The PDC will then request the delta from the BDC and apply it to the master SAM. The PDC will then contact all the BDCs in the Domain and trigger them to obtain the update and then apply that to their own copy of the SAM.

Thus the BDC is said to hold a read-only of the SAM from which it is able to process network logon requests and to authenticate users. The BDC can continue to provide this service, particularly while, for example, the wide area network link to the PDC is down. Thus a BDC plays a very important role in both maintenance of Domain security as well as in network integrity.

In the event that the PDC should need to be taken out of service, or if it dies, then one of the BDCs can be promoted to a PDC. If this happens while the original PDC is on line then it is automatically demoted to a BDC. This is an important aspect of Domain Controller management. The tool that is used to affect a promotion or a demotion is the Server Manager for Domains.

	workgroup = SAMBA
	domain master = yes
	domain logons = yes

As of the release of MS Windows 2000 and Active Directory, this information is now stored in a directory that can be replicated and for which partial or full administrative control can be delegated. Samba-3 is NOT able to be a Domain Controller within an Active Directory tree, and it can not be an Active Directory server. This means that Samba-3 also can NOT act as a Backup Domain Controller to an Active Directory Domain Controller.

Every machine that is a Domain Controller for the domain SAMBA has to register the NetBIOS group name SAMBA<#1c> with the WINS server and/or by broadcast on the local network. The PDC also registers the unique NetBIOS name SAMBA<#1b> with the WINS server. The name type <#1b> name is normally reserved for the Domain Master Browser, a role that has nothing to do with anything related to authentication, but the Microsoft Domain implementation requires the domain master browser to be on the same machine as the PDC.

An MS Windows NT4 / 200x / XP Professional workstation in the domain SAMBA that wants a local user to be authenticated has to find the domain controller for SAMBA. It does this by doing a NetBIOS name query for the group name SAMBA<#1c>. It assumes that each of the machines it gets back from the queries is a domain controller and can answer logon requests. To not open security holes both the workstation and the selected domain controller authenticate each other. After that the workstation sends the user's credentials (name and password) to the local Domain Controller, for validation.

Finally, the BDC has to be found by the workstations. This can be done by setting:

	workgroup = SAMBA
	domain master = no
	domain logons = yes

in the [global]-section of the smb.conf of the BDC. This makes the BDC only register the name SAMBA<#1c> with the WINS server. This is no problem as the name SAMBA<#1c> is a NetBIOS group name that is meant to be registered by more than one machine. The parameter 'domain master = no' forces the BDC not to register SAMBA<#1b> which as a unique NetBIOS name is reserved for the Primary Domain Controller.

This problem will occur when occur when the passdb (SAM) files are copied from a central server but the local Backup Domain Controllers. Local machine trust account password updates are not copied back to the central server. The newer machine account password is then over written when the SAM is copied from the PDC. The result is that the Domain member machine on start up will find that it's passwords does not match the one now in the database and since the startup security check will now fail, this machine will not allow logon attempts to proceed and the account expiry error will be reported.

The solution: use a more robust passdb backend, such as the ldapsam backend, setting up an slave LDAP server for each BDC, and a master LDAP server for the PDC.

With version 2.2, no. The native NT4 SAM replication protocols have not yet been fully implemented. The Samba Team is working on understanding and implementing the protocols, but this work has not been finished for version 2.2.

With version 3.0, the work on both the replication protocols and a suitable storage mechanism has progressed, and some form of NT4 BDC support is expected soon.

Can I get the benefits of a BDC with Samba? Yes. The main reason for implementing a BDC is availability. If the PDC is a Samba machine, a second Samba machine can be set up to service logon requests whenever the PDC is down.

Replication of the smbpasswd file is sensitive. It has to be done whenever changes to the SAM are made. Every user's password change is done in the smbpasswd file and has to be replicated to the BDC. So replicating the smbpasswd file very often is necessary.

As the smbpasswd file contains plain text password equivalents, it must not be sent unencrypted over the wire. The best way to set up smbpasswd replication from the PDC to the BDC is to use the utility rsync. rsync can use ssh as a transport. Ssh itself can be set up to accept only rsync transfer without requiring the user to type a password.

As said a few times before, use of this method is broken and flawed. Machine trust accounts will go out of sync, resulting in a very broken domain. This method is not recommended. Try using LDAP instead.

The simple answer is YES. Samba's pdb_ldap code supports binding to a replica LDAP server, and will also follow referrals and rebind to the master if it ever needs to make a modification to the database. (Normally BDCs are read only, so this will not occur often).

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 another '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.

If the machine from which you are trying to manage the domain is an MS Windows NT4 workstation then the tool of choice is the package called SRVTOOLS.EXE. When executed in the target directory this will unpack SrvMge.exe and UsrMgr.exe (both are Domain Management tools for MS Windows NT4 workstation.

If your workstation is any other MS Windows product you should download the Nexus.exe package from the Microsoft web site. When executed from the target directory this will unpack the same tools but for use on MS Windows 9x/Me/200x/XP.

Launch the srvmgr.exe (Server Manager for Domains) and follow these steps:

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 machine 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 Linux system.

[global]
   # <...remainder of parameters...>
   add machine script = /usr/sbin/useradd -d /dev/null -g 100 -s /bin/false -M %u 

The procedure for making an MS Windows workstation of server a member of the domain varies with the version of Windows:

First, you must edit your smb.conf file to tell Samba it should now use domain security.

Change (or add) your security line in the [global] section of your smb.conf to read:

security = domain

Next change the workgroup line in the [global] section to read:

workgroup = DOM

as this is the name of the domain we are joining.

You must also have the parameter encrypt passwords set to yes in order for your users to authenticate to the NT PDC.

Finally, add (or modify) a password server line in the [global] section to read:

password server = DOMPDC DOMBDC1 DOMBDC2

These are the primary and backup domain controllers Samba will attempt to contact in order to authenticate users. Samba will try to contact each of these servers in order, so you may want to rearrange this list in order to spread out the authentication load among domain controllers.

Alternatively, if you want smbd to automatically determine the list of Domain controllers to use for authentication, you may set this line to be:

password server = *

This method allows Samba to use exactly the same mechanism that NT does. This method either broadcasts or uses a WINS database in order to find domain controllers to authenticate against.

In order to actually join the domain, you must run this command:

root# net join -S DOMPDC -UAdministrator%password

If the -S DOMPDC argument is not given then the domain name will be obtained from smb.conf.

As we are joining the domain DOM and the PDC for that domain (the only machine that has write access to the domain SAM database) is DOMPDC, we use it for the -S option. The Administrator%password is the login name and password for an account which has the necessary privilege to add machines to the domain. If this is successful you will see the message:

Joined domain DOM. or Joined 'SERV1' to realm 'MYREALM'

in your terminal window. See the net(8) man page for more details.

This process joins the server to the domain without having to create the machine trust account on the PDC beforehand.

This command goes through the machine account password change protocol, then writes the new (random) machine account password for this Samba server into a file in the same directory in which an smbpasswd file would be stored - normally:

/usr/local/samba/private/secrets.tdb

This file is created and owned by root and is not readable by any other user. It is the key to the domain-level security for your system, and should be treated as carefully as a shadow password file.

Finally, restart your Samba daemons and get ready for clients to begin using domain security!

Currently, domain security in Samba doesn't free you from having to create local Unix users to represent the users attaching to your server. This means that if domain user DOM\fred attaches to your domain security Samba server, there needs to be a local Unix user fred to represent that user in the Unix filesystem. This is very similar to the older Samba security mode security = server, where Samba would pass through the authentication request to a Windows NT server in the same way as a Windows 95 or Windows 98 server would.

Please refer to the Winbind chapter for information on a system to automatically assign UNIX uids and gids to Windows NT Domain users and groups.

The advantage to domain-level security is that the authentication in domain-level security is passed down the authenticated RPC channel in exactly the same way that an NT server would do it. This means Samba servers now participate in domain trust relationships in exactly the same way NT servers do (i.e., you can add Samba servers into a resource domain and have the authentication passed on from a resource domain PDC to an account domain PDC).

In addition, with security = server every Samba daemon on a server has to keep a connection open to the authenticating server for as long as that daemon lasts. This can drain the connection resources on a Microsoft NT server and cause it to run out of available connections. With security = domain, however, the Samba daemons connect to the PDC/BDC only for as long as is necessary to authenticate the user, and then drop the connection, thus conserving PDC connection resources.

And finally, acting in the same manner as an NT server authenticating to a PDC means that as part of the authentication reply, the Samba server gets the user identification information such as the user SID, the list of NT groups the user belongs to, etc.

You must use at least the following 3 options in smb.conf:

	realm = your.kerberos.REALM
	security = ADS
	encrypt passwords = yes

	ads server = your.kerberos.server

The minimal configuration for krb5.conf is:

        [libdefaults]
            default_realm = YOUR.KERBEROS.REALM

	[realms]
	    YOUR.KERBEROS.REALM = {
		kdc = your.kerberos.server
	    }

Test your config by doing a kinit USERNAME@REALM and making sure that your password is accepted by the Win2000 KDC.

You also must ensure that you can do a reverse DNS lookup on the IP address of your KDC. Also, the name that this reverse lookup maps to must either be the NetBIOS name of the KDC (ie. the hostname with no domain attached) or it can alternatively be the NetBIOS name followed by the realm.

The easiest way to ensure you get this right is to add a /etc/hosts entry mapping the IP address of your KDC to its NetBIOS name. If you don't get this right then you will get a local error when you try to join the realm.

If all you want is Kerberos support in smbclient then you can skip straight to Test with smbclient now. Creating a computer account and testing your servers is only needed if you want Kerberos support for smbd and winbindd.

	root# net join -U Administrator%password

If the join was successful, you will see a new computer account with the NetBIOS name of your Samba server in Active Directory (in the "Computers" folder under Users and Computers.

On a Windows 2000 client try net use * \\server\share. You should be logged in with Kerberos without needing to know a password. If this fails then run klist tickets. Did you get a ticket for the server? Does it have an encoding type of DES-CBC-MD5 ?

On your Samba server try to login to a Win2000 server or your Samba server using smbclient and Kerberos. Use smbclient as usual, but specify the -k option to choose Kerberos authentication.

You must change administrator password at least once after DC install, to create the right encoding types

W2k doesn't seem to create the _kerberos._udp and _ldap._tcp in their defaults DNS setup. Maybe fixed in service packs?

Problem: A Windows workstation was reinstalled. The original domain machine account was deleted and added immediately. The workstation will not join the domain if I use the same machine name. Attempts to add the machine fail with a message that the machine already exists on the network - I know it doesn't. Why is this failing?

The original name is still in the NetBIOS name cache and must expire after machine account deletion BEFORE adding that same name as a domain member again. The best advice is to delete the old account and then to add the machine with a new name.

Adding a Windows 200x or XP Professional machine to the Samba PDC Domain fails with a message that, The machine could not be added at this time, there is a network problem. Please try again later. Why?

You should check that there is an add machine script in your smb.conf file. If there is not, please add one that is appropriate for your OS platform. If a script has been defined you will need to debug it's operation. Increase the log level in the smb.conf file to level 10, then try to rejoin the domain. Check the logs to see which operation is failing.

Possible causes include:

Configuration of a read-only data server that EVERYONE can access is very simple. Here is the smb.conf file that will do this. Assume that all the reference documents are stored in the directory /export, that the documents are owned by a user other than nobody. No home directories are shared, that are no users in the /etc/passwd Unix system database. This is a very simple system to administer.

	# Global parameters
	[global]
		workgroup = MYGROUP
		netbios name = REFDOCS
		security = SHARE
		passdb backend = guest
		wins server = 192.168.1.1

	[data]
		comment = Data
		path = /export
		guest only = Yes

In the above example the machine name is set to REFDOCS, the workgroup is set to the name of the local workgroup so that the machine will appear in with systems users are familiar with. The only password backend required is the "guest" backend so as to allow default unprivileged account names to be used. Given that there is a WINS server on this network we do use it.

Configuration of a simple print server is very simple if you have all the right tools on your system.

In this example our print server will spool all incoming print jobs to /var/spool/samba until the job is ready to be submitted by Samba to the CUPS print processor. Since all incoming connections will be as the anonymous (guest) user, two things will be required:

	# Global parameters
	[global]
		workgroup = MYGROUP
		netbios name = PTRSVR1
		security = SHARE
		passdb backend = guest
		wins server = 192.168.1.1

	[printers]
		comment = All Printers
		path = /var/spool/samba
		printer admin = root
		guest ok = Yes
		printable = Yes
		printing = cups
		use client driver = Yes
		browseable = No

Samba implements NetBIOS, as does MS Windows NT / 200x / XP, by encapsulating it over TCP/IP. MS Windows products can do likewise. NetBIOS based networking uses broadcast messaging to affect browse list management. When running NetBIOS over TCP/IP, this uses UDP based messaging. UDP messages can be broadcast or unicast.

Normally, only unicast UDP messaging can be forwarded by routers. The remote announce parameter to smb.conf helps to project browse announcements to remote network segments via unicast UDP. Similarly, the remote browse sync parameter of smb.conf implements browse list collation using unicast UDP.

Secondly, in those networks where Samba is the only SMB server technology, wherever possible nmbd should be configured on one (1) machine as the WINS server. This makes it easy to manage the browsing environment. If each network segment is configured with it's own Samba WINS server, then the only way to get cross segment browsing to work is by using the remote announce and the remote browse sync parameters to your smb.conf file.

If only one WINS server is used for an entire multi-segment network then the use of the remote announce and the remote browse sync parameters should NOT be necessary.

As of Samba 3 WINS replication is being worked on. The bulk of the code has been committed, but it still needs maturation. This is NOT a supported feature of the Samba-3.0.0 release. Hopefully, this will become a supported feature of one of the Samba-3 release series.

Right now Samba WINS does not support MS-WINS replication. This means that when setting up Samba as a WINS server there must only be one nmbd configured as a WINS server on the network. Some sites have used multiple Samba WINS servers for redundancy (one server per subnet) and then used remote browse sync and remote announce to affect browse list collation across all segments. Note that this means clients will only resolve local names, and must be configured to use DNS to resolve names on other subnets in order to resolve the IP addresses of the servers they can see on other subnets. This setup is not recommended, but is mentioned as a practical consideration (ie: an 'if all else fails' scenario).

Lastly, take note that browse lists are a collection of unreliable broadcast messages that are repeated at intervals of not more than 15 minutes. This means that it will take time to establish a browse list and it can take up to 45 minutes to stabilise, particularly across network segments.

All TCP/IP using systems use various forms of host name resolution. The primary methods for TCP/IP hostname resolutions involves either a static file (/etc/hosts ) or DNS (the Domain Name System). DNS is the technology that makes the Internet usable. DNS based host name resolution is supported by nearly all TCP/IP enabled systems. Only a few embedded TCP/IP systems do not support DNS.

When an MS Windows 200x / XP system attempts to resolve a host name to an IP address it follows a defined path:

Windows 200x / XP can register it's host name with a Dynamic DNS server. You can force register with a Dynamic DNS server in Windows 200x / XP using: ipconfig /registerdns

With Active Directory (ADS), a correctly functioning DNS server is absolutely essential. In the absence of a working DNS server that has been correctly configured, MS Windows clients and servers will be totally unable to locate each other, consequently network services will be severely impaired.

The use of Dynamic DNS is highly recommended with Active Directory, in which case the use of BIND9 is preferred for it's ability to adequately support the SRV (service) records that are needed for Active Directory.

Occasionally we hear from Unix network administrators who want to use a Unix based Dynamic DNS server in place of the Microsoft DNS server. While this might be desirable to some, the MS Windows 200x DNS server is auto-configured to work with Active Directory. It is possible to use BIND version 8 or 9, but it will almost certainly be necessary to create service records so that MS Active Directory clients can resolve host names to locate essential network services. The following are some of the default service records that Active Directory requires:

To set up cross subnet browsing on a network containing machines in up to be in a WORKGROUP, not an NT Domain you need to set up one Samba server to be the Domain Master Browser (note that this is *NOT* the same as a Primary Domain Controller, although in an NT Domain the same machine plays both roles). The role of a Domain master browser is to collate the browse lists from local master browsers on all the subnets that have a machine participating in the workgroup. Without one machine configured as a domain master browser each subnet would be an isolated workgroup, unable to see any machines on any other subnet. It is the presence of a domain master browser that makes cross subnet browsing possible for a workgroup.

In an WORKGROUP environment the domain master browser must be a Samba server, and there must only be one domain master browser per workgroup name. To set up a Samba server as a domain master browser, set the following option in the [global] section of the smb.conf file :

	domain master = yes

The domain master browser should also preferrably be the local master browser for its own subnet. In order to achieve this set the following options in the [global] section of the smb.conf file :

	domain master = yes
	local master = yes
	preferred master = yes
	os level = 65

The domain master browser may be the same machine as the WINS server, if you require.

Next, you should ensure that each of the subnets contains a machine that can act as a local master browser for the workgroup. Any MS Windows NT/2K/XP/2003 machine should be able to do this, as will Windows 9x machines (although these tend to get rebooted more often, so it's not such a good idea to use these). To make a Samba server a local master browser set the following options in the [global] section of the smb.conf file :

	domain master = no
	local master = yes
	preferred master = yes
	os level = 65

Do not do this for more than one Samba server on each subnet, or they will war with each other over which is to be the local master browser.

The local master parameter allows Samba to act as a local master browser. The preferred master causes nmbd to force a browser election on startup and the os level parameter sets Samba high enough so that it should win any browser elections.

If you have an NT machine on the subnet that you wish to be the local master browser then you can disable Samba from becoming a local master browser by setting the following options in the [global] section of the smb.conf file :

	domain master = no
	local master = no
	preferred master = no
	os level = 0

If you are adding Samba servers to a Windows NT Domain then you must not set up a Samba server as a domain master browser. By default, a Windows NT Primary Domain Controller for a domain is also the Domain master browser for that domain, and many things will break if a Samba server registers the Domain master browser NetBIOS name (DOMAIN<1B>) with WINS instead of the PDC.

For subnets other than the one containing the Windows NT PDC you may set up Samba servers as local master browsers as described. To make a Samba server a local master browser set the following options in the [global] section of the smb.conf file :

	domain master = no
	local master = yes
	preferred master = yes
	os level = 65

If you wish to have a Samba server fight the election with machines on the same subnet you may set the os level parameter to lower levels. By doing this you can tune the order of machines that will become local master browsers if they are running. For more details on this see the section Forcing Samba to be the master browser below.

If you have Windows NT machines that are members of the domain on all subnets, and you are sure they will always be running then you can disable Samba from taking part in browser elections and ever becoming a local master browser by setting following options in the [global] section of the smb.conf file :

        domain master = no
        local master = no
        preferred master = no
        os level = 0

Who becomes the master browser is determined by an election process using broadcasts. Each election packet contains a number of parameters which determine what precedence (bias) a host should have in the election. By default Samba uses a very low precedence and thus loses elections to just about anyone else.

If you want Samba to win elections then just set the os level global option in smb.conf to a higher number. It defaults to 0. Using 34 would make it win all elections over every other system (except other samba systems!)

A os level of 2 would make it beat WfWg and Win95, but not MS Windows NT/2K Server. A MS Windows NT/2K Server domain controller uses level 32.

The maximum os level is 255

If you want Samba to force an election on startup, then set the preferred master global option in smb.conf to yes. Samba will then have a slight advantage over other potential master browsers that are not preferred master browsers. Use this parameter with care, as if you have two hosts (whether they are Windows 95 or NT or Samba) on the same local subnet both set with preferred master to yes, then periodically and continually they will force an election in order to become the local master browser.

If you want Samba to be a domain master browser, then it is recommended that you also set preferred master to yes, because Samba will not become a domain master browser for the whole of your LAN or WAN if it is not also a local master browser on its own broadcast isolated subnet.

It is possible to configure two Samba servers to attempt to become the domain master browser for a domain. The first server that comes up will be the domain master browser. All other Samba servers will attempt to become the domain master browser every 5 minutes. They will find that another Samba server is already the domain master browser and will fail. This provides automatic redundancy, should the current domain master browser fail.

The domain master is responsible for collating the browse lists of multiple subnets so that browsing can occur between subnets. You can make Samba act as the domain master by setting domain master = yes in smb.conf. By default it will not be a domain master.

Note that you should not set Samba to be the domain master for a workgroup that has the same name as an NT Domain.

When Samba is the domain master and the master browser, it will listen for master announcements (made roughly every twelve minutes) from local master browsers on other subnets and then contact them to synchronise browse lists.

If you want Samba to be the domain master then I suggest you also set the os level high enough to make sure it wins elections, and set preferred master to yes, to get Samba to force an election on startup.

Note that all your servers (including Samba) and clients should be using a WINS server to resolve NetBIOS names. If your clients are only using broadcasting to resolve NetBIOS names, then two things will occur:

If, however, both Samba and your clients are using a WINS server, then:

If your network uses a "0" based broadcast address (for example if it ends in a 0) then you will strike problems. Windows for Workgroups does not seem to support a 0's broadcast and you will probably find that browsing and name lookups won't work.

Samba now supports machines with multiple network interfaces. If you have multiple interfaces then you will need to use the interfaces option in smb.conf to configure them.

	remote announce = a.b.c.d [e.f.g.h] ...

	remote announce = a.b.c.d/WORKGROUP [e.f.g.h/WORKGROUP] ...

The remote browse sync parameter of smb.conf is used to announce to another LMB that it must synchronise its NetBIOS name list with our Samba LMB. It works ONLY if the Samba server that has this option is simultaneously the LMB on its network segment.

remote browse sync = a.b.c.d

Either a Samba machine or a Windows NT Server machine may be set up as a WINS server. To set a Samba machine to be a WINS server you must add the following option to the smb.conf file on the selected machine : in the [globals] section add the line

	wins support = yes

Versions of Samba prior to 1.9.17 had this parameter default to yes. If you have any older versions of Samba on your network it is strongly suggested you upgrade to a recent version, or at the very least set the parameter to 'no' on all these machines.

Machines with wins support = yes will keep a list of all NetBIOS names registered with them, acting as a DNS for NetBIOS names.

You should set up only ONE WINS server. Do NOT set the wins support = yes option on more than one Samba server.

To set up a Windows NT Server as a WINS server you need to set up the WINS service - see your NT documentation for details. Note that Windows NT WINS Servers can replicate to each other, allowing more than one to be set up in a complex subnet environment. As Microsoft refuses to document these replication protocols, Samba cannot currently participate in these replications. It is possible in the future that a Samba->Samba WINS replication protocol may be defined, in which case more than one Samba machine could be set up as a WINS server but currently only one Samba server should have the wins support = yes parameter set.

After the WINS server has been configured you must ensure that all machines participating on the network are configured with the address of this WINS server. If your WINS server is a Samba machine, fill in the Samba machine IP address in the Primary WINS Server field of the Control Panel->Network->Protocols->TCP->WINS Server dialogs in Windows 95 or Windows NT. To tell a Samba server the IP address of the WINS server add the following line to the [global] section of all smb.conf files :

	wins server = <name or IP address>

where <name or IP address> is either the DNS name of the WINS server machine or its IP address.

Note that this line MUST NOT BE SET in the smb.conf file of the Samba server acting as the WINS server itself. If you set both the wins support = yes option and the wins server = <name> option then nmbd will fail to start.

There are two possible scenarios for setting up cross subnet browsing. The first details setting up cross subnet browsing on a network containing Windows 95, Samba and Windows NT machines that are not configured as part of a Windows NT Domain. The second details setting up cross subnet browsing on networks that contain NT Domains.

Samba-3 permits WINS replication through the use of the wrepld utility. This tool is not currently capable of being used as it is still in active development. As soon as this tool becomes moderately functional we will prepare man pages and enhance this section of the documentation to provide usage and technical details.

Adding static entries to your Samba-3 WINS server is actually fairly easy. All you have to do is add a line to wins.dat, typically located in /usr/local/samba/var/locks.

"NAME#TYPE" TTL ADDRESS+ FLAGS

"MADMAN#03" 1055298378 192.168.1.2 66R

"MADMAN#03" 0 192.168.1.2 66R

Though this method works with early Samba-3 versions, there's a possibility that it may change in future versions if WINS replication is added.

A very common cause of browsing problems results from installing more than one protocol on an MS Windows machine.

Every NetBIOS machine takes part in a process of electing the LMB (and DMB) every 15 minutes. A set of election criteria is used to determine the order of precedence for winning this election process. A machine running Samba or Windows NT will be biased so that the most suitable machine will predictably win and thus retain it's role.

The election process is "fought out" so to speak over every NetBIOS network interface. In the case of a Windows 9x machine that has both TCP/IP and IPX installed and has NetBIOS enabled over both protocols the election will be decided over both protocols. As often happens, if the Windows 9x machine is the only one with both protocols then the LMB may be won on the NetBIOS interface over the IPX protocol. Samba will then lose the LMB role as Windows 9x will insist it knows who the LMB is. Samba will then cease to function as an LMB and thus browse list operation on all TCP/IP only machines will fail.

Windows 95, 98, 98se, Me are referred to generically as Windows 9x. The Windows NT4, 2000, XP and 2003 use common protocols. These are roughly referred to as the WinNT family, but it should be recognised that 2000 and XP/2003 introduce new protocol extensions that cause them to behave differently from MS Windows NT4. Generally, where a server does NOT support the newer or extended protocol, these will fall back to the NT4 protocols.

The safest rule of all to follow it this - USE ONLY ONE PROTOCOL!

Resolution of NetBIOS names to IP addresses can take place using a number of methods. The only ones that can provide NetBIOS name_type information are:

Alternative means of name resolution includes:

name resolve order = wins lmhosts bcast host

name resolve order = wins lmhosts  	(eliminates bcast and host)

name resolve order = host lmhost wins bcast

Samba facilitates browsing. The browsing is supported by nmbd and is also controlled by options in the smb.conf file. Samba can act as a local browse master for a workgroup and the ability to support domain logons and scripts is now available.

Samba can also act as a domain master browser for a workgroup. This means that it will collate lists from local browse masters into a wide area network server list. In order for browse clients to resolve the names they may find in this list, it is recommended that both Samba and your clients use a WINS server.

Note that you should NOT set Samba to be the domain master for a workgroup that has the same name as an NT Domain: on each wide area network, you must only ever have one domain master browser per workgroup, regardless of whether it is NT, Samba or any other type of domain master that is providing this service.

To get browsing to work you need to run nmbd as usual, but will need to use the workgroup option in smb.conf to control what workgroup Samba becomes a part of.

Samba also has a useful option for a Samba server to offer itself for browsing on another subnet. It is recommended that this option is only used for 'unusual' purposes: announcements over the internet, for example. See remote announce in the smb.conf man page.

If something doesn't work then hopefully the log.nmbd file will help you track down the problem. Try a debug level of 2 or 3 for finding problems. Also note that the current browse list usually gets stored in text form in a file called browse.dat.

Note that if it doesn't work for you, then you should still be able to type the server name as \\SERVER in filemanager then hit enter and filemanager should display the list of available shares.

Some people find browsing fails because they don't have the global guest account set to a valid account. Remember that the IPC$ connection that lists the shares is done as guest, and thus you must have a valid guest account.

MS Windows 2000 and upwards (as with Samba) can be configured to disallow anonymous (ie: Guest account) access to the IPC$ share. In that case, the MS Windows 2000/XP/2003 machine acting as an SMB/CIFS client will use the name of the currently logged in user to query the IPC$ share. MS Windows 9X clients are not able to do this and thus will NOT be able to browse server resources.

The other big problem people have is that their broadcast address, netmask or IP address is wrong (specified with the "interfaces" option in smb.conf)

Since the release of Samba 1.9.17(alpha1), Samba has supported the replication of browse lists across subnet boundaries. This section describes how to set this feature up in different settings.

To see browse lists that span TCP/IP subnets (ie. networks separated by routers that don't pass broadcast traffic), you must set up at least one WINS server. The WINS server acts as a DNS for NetBIOS names, allowing NetBIOS name to IP address translation to be done by doing a direct query of the WINS server. This is done via a directed UDP packet on port 137 to the WINS server machine. The reason for a WINS server is that by default, all NetBIOS name to IP address translation is done by broadcasts from the querying machine. This means that machines on one subnet will not be able to resolve the names of machines on another subnet without using a WINS server.

Remember, for browsing across subnets to work correctly, all machines, be they Windows 95, Windows NT, or Samba servers must have the IP address of a WINS server given to them by a DHCP server, or by manual configuration (for Win95 and WinNT, this is in the TCP/IP Properties, under Network settings) for Samba this is in the smb.conf file.

                                   (DMB)
             N1_A      N1_B        N1_C       N1_D        N1_E
              |          |           |          |           |
          -------------------------------------------------------
            |          subnet 1                       |
          +---+                                      +---+
          |R1 | Router 1                  Router 2   |R2 |
          +---+                                      +---+
            |                                          |
            |  subnet 2              subnet 3          |
  --------------------------       ------------------------------------
  |     |     |      |               |        |         |           |
 N2_A  N2_B  N2_C   N2_D           N3_A     N3_B      N3_C        N3_D 
                    (WINS)

Samba's nmbd process controls all browse list handling. Under normal circumstances it is safe to restart nmbd. This will effectively flush the Samba NetBIOS name cache and cause it to be rebuilt. Note that this does NOT make certain that a rogue machine name will not re-appear in the browse list. When nmbd is taken out of service another machine on the network will become the browse master. This new list may still have the rogue entry in it. If you really want to clear a rogue machine from the list then every machine on the network will need to be shut down and restarted at after all machines are down. Failing a complete restart, the only other thing you can do is wait until the entry times out and is then flushed from the list. This may take a long time on some networks (months).

Your guest account is probably invalid for some reason. Samba uses the guest account for browsing in smbd. Check that your guest account is valid.

See also guest account in the smb.conf man page.

The unix and SMB password encryption techniques seem similar on the surface. This similarity is, however, only skin deep. The unix scheme typically sends clear text passwords over the network when logging in. This is bad. The SMB encryption scheme never sends the cleartext password over the network but it does store the 16 byte hashed values on disk. This is also bad. Why? Because the 16 byte hashed values are a "password equivalent". You cannot derive the user's password from them, but they could potentially be used in a modified client to gain access to a server. This would require considerable technical knowledge on behalf of the attacker but is perfectly possible. You should thus treat the data stored in whatever passdb backend you use (smbpasswd file, ldap, mysql) as though it contained the cleartext passwords of all your users. Its contents must be kept secret, and the file should be protected accordingly.

Ideally we would like a password scheme that involves neither plain text passwords on the net nor on disk. Unfortunately this is not available as Samba is stuck with having to be compatible with other SMB systems (WinNT, WfWg, Win95 etc).

Windows NT 4.0 Service pack 3 changed the default setting so that plaintext passwords are disabled from being sent over the wire. This mandates either the use of encrypted password support or edit the Windows NT registry to re-enable plaintext passwords.

The following versions of MS Windows do not support full domain security protocols, although they may log onto a domain environment:

The following versions of MS Windows fully support domain security protocols.

All current release of Microsoft SMB/CIFS clients support authentication via the SMB Challenge/Response mechanism described here. Enabling clear text authentication does not disable the ability of the client to participate in encrypted authentication. Instead, it allows the client to negotiate either plain text _or_ encrypted password handling.

MS Windows clients will cache the encrypted password alone. Where plain text passwords are re-enabled, through the appropriate registry change, the plain text password is NEVER cached. This means that in the event that a network connections should become disconnected (broken) only the cached (encrypted) password will be sent to the resource server to affect a auto-reconnect. If the resource server does not support encrypted passwords the auto-reconnect will fail. USE OF ENCRYPTED PASSWORDS IS STRONGLY ADVISED.

Every operation in Unix/Linux requires a user identifier (UID), just as in MS Windows NT4 / 200x this requires a Security Identifier (SID). Samba provides two means for mapping an MS Windows user to a Unix/Linux UID.

Firstly, all Samba SAM (Security Account Manager database) accounts require a Unix/Linux UID that the account will map to. As users are added to the account information database, Samba-3 will call the add user script interface to add the account to the Samba host OS. In essence, all accounts in the local SAM require a local user account.

The second way to affect Windows SID to Unix UID mapping is via the idmap uid, idmap gid parameters in smb.conf. Please refer to the man page for information about these parameters. These parameters are essential when mapping users from a remote SAM server.

The smbpasswd utility is a utility similar to the passwd or yppasswd programs. It maintains the two 32 byte password fields in the passdb backend.

smbpasswd works in a client-server mode where it contacts the local smbd to change the user's password on its behalf. This has enormous benefits as follows:

smbpasswd has the capability to change passwords on Windows NT servers (this only works when the request is sent to the NT Primary Domain Controller if changing an NT Domain user's password).

smbpasswd can be used to:

To run smbpasswd as a normal user just type:

		$ smbpasswd
		Old SMB password: secret
		

		New SMB Password: new secret
		Repeat New SMB Password: new secret
		

If the old value does not match the current value stored for that user, or the two new values do not match each other, then the password will not be changed.

When invoked by an ordinary user it will only allow change of their own SMB password.

When run by root smbpasswd may take an optional argument, specifying the user name whose SMB password you wish to change. When run as root, smbpasswd does not prompt for or check the old password value, thus allowing root to set passwords for users who have forgotten their passwords.

smbpasswd is designed to work in the way familiar to UNIX users who use the passwd or yppasswd commands. While designed for administrative use, this tool provides essential user level password change capabilities.

For more details on using smbpasswd refer to the man page (the definitive reference).

pdbedit is a tool that can be used only by root. It is used to manage the passdb backend. pdbedit can be used to:

The pdbedit tool is the only one that can manage the account security and policy settings. It is capable of all operations that smbpasswd can do as well as a super set of them.

One particularly important purpose of the pdbedit is to allow the migration of account information from one passdb backend to another. See the XML password backend section of this chapter.

The following is an example of the user account information that is stored in a tdbsam password backend. This listing was produced by running:

		$ pdbedit -Lv met
		Unix username:        met
		NT username:
		Account Flags:        [UX         ]
		User SID:             S-1-5-21-1449123459-1407424037-3116680435-2004
		Primary Group SID:    S-1-5-21-1449123459-1407424037-3116680435-1201
		Full Name:            Melissa E Terpstra
		Home Directory:       \\frodo\met\Win9Profile
		HomeDir Drive:        H:
		Logon Script:         scripts\logon.bat
		Profile Path:         \\frodo\Profiles\met
		Domain:               MIDEARTH
		Account desc:
		Workstations:         melbelle
		Munged dial:
		Logon time:           0
		Logoff time:          Mon, 18 Jan 2038 20:14:07 GMT
		Kickoff time:         Mon, 18 Jan 2038 20:14:07 GMT
		Password last set:    Sat, 14 Dec 2002 14:37:03 GMT
		Password can change:  Sat, 14 Dec 2002 14:37:03 GMT
		Password must change: Mon, 18 Jan 2038 20:14:07 GMT
		

Older versions of Samba retrieved user information from the unix user database and eventually some other fields from the file /etc/samba/smbpasswd or /etc/smbpasswd. When password encryption is disabled, no SMB specific data is stored at all. Instead all operations are conducted via the way that the Samba host OS will access its /etc/passwd database. eg: On Linux systems that is done via PAM.

Traditionally, when configuring encrypt passwords = yes in Samba's smb.conf file, user account information such as username, LM/NT password hashes, password change times, and account flags have been stored in the smbpasswd(5) file. There are several disadvantages to this approach for sites with very large numbers of users (counted in the thousands).

As a result of these deficiencies, a more robust means of storing user attributes used by smbd was developed. The API which defines access to user accounts is commonly referred to as the samdb interface (previously this was called the passdb API, and is still so named in the Samba CVS trees).

Samba-3 provides an enhanced set of passdb backends that overcome the deficiencies of the smbpasswd plain text database. These are tdbsam, ldapsam, and xmlsam. Of these ldapsam will be of most interest to large corporate or enterprise sites.

Samba can store user and machine account data in a "TDB" (Trivial Database). Using this backend doesn't require any additional configuration. This backend is recommended for new installations that do not require LDAP.

As a general guide the Samba-Team does NOT recommend using the tdbsam backend for sites that have 250 or more users. Additionally, tdbsam is not capable of scaling for use in sites that require PDB/BDC implementations that requires replication of the account database. Clearly, for reason of scalability, the use of ldapsam should be encouraged.

There are a few points to stress that the ldapsam does not provide. The LDAP support referred to in the this documentation does not include:

The second item can be accomplished by using LDAP NSS and PAM modules. LGPL versions of these libraries can be obtained from PADL Software (http://www.padl.com/). More information about the configuration of these packages may be found at "LDAP, System Administration; Gerald Carter, O'Reilly; Chapter 6: Replacing NIS". Refer to http://safari.oreilly.com/?XmlId=1-56592-491-6 for those who might wish to know more about configuration and administration of an OpenLDAP server.

This document describes how to use an LDAP directory for storing Samba user account information traditionally stored in the smbpasswd(5) file. It is assumed that the reader already has a basic understanding of LDAP concepts and has a working directory server already installed. For more information on LDAP architectures and Directories, please refer to the following sites.

Two additional Samba resources which may prove to be helpful are

objectclass ( 1.3.6.1.4.1.7165.2.2.3 NAME 'sambaSamAccount' SUP top AUXILIARY
    DESC 'Samba Auxiliary Account'
    MUST ( uid $ rid )
    MAY  ( cn $ lmPassword $ ntPassword $ pwdLastSet $ logonTime $
           logoffTime $ kickoffTime $ pwdCanChange $ pwdMustChange $ acctFlags $
           displayName $ smbHome $ homeDrive $ scriptPath $ profilePath $
           description $ userWorkstations $ primaryGroupID $ domain ))

root# cp samba.schema /etc/openldap/schema/

## /etc/openldap/slapd.conf

## schema files (core.schema is required by default)
include	           /etc/openldap/schema/core.schema

## needed for sambaSamAccount
include            /etc/openldap/schema/cosine.schema
include            /etc/openldap/schema/inetorgperson.schema
include            /etc/openldap/schema/samba.schema
include            /etc/openldap/schema/nis.schema
....

# Indices to maintain
## required by OpenLDAP
index objectclass             eq

index cn                      pres,sub,eq
index sn                      pres,sub,eq
## required to support pdb_getsampwnam
index uid                     pres,sub,eq
## required to support pdb_getsambapwrid()
index displayName             pres,sub,eq

## uncomment these if you are storing posixAccount and
## posixGroup entries in the directory as well
##index uidNumber               eq
##index gidNumber               eq
##index memberUid               eq

index   sambaSID              eq
index   sambaPrimaryGroupSID  eq
index   sambaDomainName       eq
index   default               sub

./sbin/slapindex -f slapd.conf

root# /etc/init.d/slapd restart

# Organization for Samba Base
dn: dc=plainjoe,dc=org
objectclass: dcObject
objectclass: organization
dc: plainjoe
o: Terpstra Org Network
description: The Samba-3 Network LDAP Example

# Organizational Role for Directory Management
dn: cn=Manager,dc=plainjoe,dc=org
objectclass: organizationalRole
cn: Manager
description: Directory Manager

# Setting up container for users
dn: ou=People,dc=plainjoe,dc=org
objectclass: top
objectclass: organizationalUnit
ou: People

# Setting up admin handle for People OU
dn: cn=admin,ou=People,dc=plainjoe,dc=org
cn: admin
objectclass: top
objectclass: organizationalRole
objectclass: simpleSecurityObject
userPassword: {SSHA}c3ZM9tBaBo9autm1dL3waDS21+JSfQVz

$ slapadd -v -l initldap.dif

root#  smbpasswd -w secret
		

## /usr/local/samba/lib/smb.conf
[global]
     security = user
     encrypt passwords = yes

     netbios name = TASHTEGO
     workgroup = NARNIA

     # ldap related parameters

     # define the DN to use when binding to the directory servers
     # The password for this DN is not stored in smb.conf.  Rather it
     # must be set by using 'smbpasswd -w secretpw' to store the
     # passphrase in the secrets.tdb file.  If the "ldap admin dn" values
     # change, this password will need to be reset.
     ldap admin dn = "cn=Samba Manager,ou=people,dc=samba,dc=org"

     # Define the SSL option when connecting to the directory
     # ('off', 'start tls', or 'on' (default))
     ldap ssl = start tls

     # syntax: passdb backend = ldapsam:ldap://server-name[:port]
     passdb backend = ldapsam:ldap://funball.samba.org, guest

     # smbpasswd -x delete the entire dn-entry
     ldap delete dn = no

     # the machine and user suffix added to the base suffix
     # wrote WITHOUT quotes. NULL suffixes by default
     ldap user suffix = ou=People
     ldap machine suffix = ou=Systems

     # Trust unix account information in LDAP
     #  (see the smb.conf manpage for details)
     ldap trust ids = Yes

     # specify the base DN to use when searching the directory
     ldap suffix = "ou=people,dc=samba,dc=org"

     # generally the default ldap search filter is ok
     # ldap filter = "(&(uid=%u)(objectclass=sambaSamAccount))"

## allow the "ldap admin dn" access, but deny everyone else
access to attrs=lmPassword,ntPassword
     by dn="cn=Samba Admin,ou=people,dc=plainjoe,dc=org" write
     by * none

	dn: uid=guest2, ou=people,dc=plainjoe,dc=org
	ntPassword: 878D8014606CDA29677A44EFA1353FC7
	pwdMustChange: 2147483647
	primaryGroupID: 1201
	lmPassword: 552902031BEDE9EFAAD3B435B51404EE
	pwdLastSet: 1010179124
	logonTime: 0
	objectClass: sambaSamAccount
	uid: guest2
	kickoffTime: 2147483647
	acctFlags: [UX         ]
	logoffTime: 2147483647
	rid: 19006
	pwdCanChange: 0
	

	dn: uid=gcarter, ou=people,dc=plainjoe,dc=org
	logonTime: 0
	displayName: Gerald Carter
	lmPassword: 552902031BEDE9EFAAD3B435B51404EE
	primaryGroupID: 1201
	objectClass: posixAccount
	objectClass: sambaSamAccount
	acctFlags: [UX         ]
	userPassword: {crypt}BpM2ej8Rkzogo
	uid: gcarter
	uidNumber: 9000
	cn: Gerald Carter
	loginShell: /bin/bash
	logoffTime: 2147483647
	gidNumber: 100
	kickoffTime: 2147483647
	pwdLastSet: 1010179230
	rid: 19000
	homeDirectory: /home/tashtego/gcarter
	pwdCanChange: 0
	pwdMustChange: 2147483647
	ntPassword: 878D8014606CDA29677A44EFA1353FC7

Every so often someone will come along with a great new idea. Storing of user accounts in an SQL backend is one of them. Those who want to do this are in the best position to know what the specific benefits are to them. This may sound like a cop-out, but in truth we can not attempt to document every nitty little detail why certain things of marginal utility to the bulk of Samba users might make sense to the rest. In any case, the following instructions should help the determined SQL user to implement a working system.

$ mysql -uusername -hhostname -ppassword \
databasename < /path/to/samba/examples/pdb/mysql/mysql.dump

			passdb backend = [other-plugins] mysql:identifier [other-plugins]