The smb.conf file uses the same syntax as the various old .ini files in Windows 3.1: Each file consists of various sections, which are started by putting the section name between brackets ([]) on a new line. Each contains zero or more key/value-pairs seperated by an equality sign (=). The file is just a plain-text file, so you can open and edit it with your favorite editing tool.

Each section in the smb.conf file represents a share on the Samba server. The section “global” is special, since it contains settings that apply to the whole Samba server and not to one share in particular.

contains a very minimal smb.conf.

There are sample configuration files in the examples subdirectory in the distribution. It is suggested you read them carefully so you can see how the options go together in practice. See the man page for all the options. It might be worthwhile to start out with the smb.conf.default configuration file and adapt it to your needs. It contains plenty of comments.

The simplest useful configuration file would contain something like shown in .

This will allow connections by anyone with an account on the server, using either their login name or homes as the service name. (Note: The workgroup that Samba should appear in must also be set. The default workgroup name is WORKGROUP.)

Make sure you put the smb.conf file in the correct place.

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

	root#  testparm /etc/samba/smb.conf
	

SWAT is a Web-based interface that can be used to facilitate the configuration of Samba. SWAT might not be available in the Samba package that shipped with 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 to http://localhost:901/. Replace localhost with the name of the computer on which Samba is running if that is a different computer than your browser.

SWAT can be used from a browser on any IP-connected machine, but be aware that connecting from a remote machine leaves your connection open to password sniffing as passwords will be sent over the wire in the clear.

More information about SWAT can be found in .

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

If Samba is not running as a WINS server, then there will be one single instance of nmbd running on your system. If it is running as a WINS server then there will be two instances one to handle the WINS requests.

smbd handles all connection requests. It spawns a new process for each client connection made. That is why you may see so many of them, one 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).

An error message is observed in the log files when smbd is started: “open_oplock_ipc: Failed to get local UDP socket for address 100007f. Error was Cannot assign requested.”

Your loopback device isn't working correctly. Make sure it is configured correctly. The loopback device is an internal (virtual) network device with the IP address 127.0.0.1. Read your OS documentation for details on how to configure the loopback on your system.

This error can be caused by one of these misconfigurations:

We will describe User Level Security first, as its simpler. In User Level Security, the client will send a session setup request directly following protocol negotiation. This request provides a username and password. The server can either accept or reject that username/password combination. 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).

In Share Level security, the client authenticates itself separately for each share. It sends 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 understand the MS Windows networking parallels, 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 parameter in the smb.conf file. The password is then checked in turn against these possible usernames. If a match is found then the client is authenticated as that user.

When Samba is operating in security = domain mode, the Samba server has a domain security trust account (a machine account) and causes all authentication requests to be passed through to the Domain Controllers. In other words, this configuration makes the Samba server a Domain Member server.

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

root# net rpc join -U Administrator%password

Both Samba-2.2, and Samba-3 can join an Active Directory domain. This is possible if the domain is run in native mode. Active Directory in native mode perfectly allows NT4-style Domain Members. This is contrary to popular belief. Active Directory in native mode prohibits only the use of Backup Domain Controllers running MS Windows NT4.

If you are using Active Directory, starting with Samba-3 you can 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 Kerberos. In this case Samba as an NT4-style domain would still require NT-compatible authentication data. Samba in AD-member mode can accept Kerberos tickets.

Server Security Mode is 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 drawbacks that 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 client's connection. This allows the Samba server to use another SMB server as the password server.

You should also note that at the 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, 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. The real authentication server can be another Samba server, or it can be a Windows NT server, the latter being natively capable of encrypted password support.

To some the nature of the Samba security mode is obvious, but entirely wrong all the same. It is assumed that security = server means that Samba will act as a server. Not so! This setting means that Samba will try to use another SMB server as its source for 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 manufacturer's manual before the warranty expires. See for more information.

“ Why does server_validate() simply give up rather than re-establish 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 MS Windows NT4. In Windows 200x Domain Control architecture, this role is held by Domain Controllers. Folklore dictates that because of its role in the MS Windows network, the Domain Controller should be the most powerful and most capable machine in the network. As strange as it may seem to say this here, good overall network performance dictates that the entire infrastructure needs to be balanced. It is advisable to invest more in Stand-alone (Domain Member) servers than in the Domain Controllers.

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

With MS Windows 200x Server-based Active Directory domains, one Domain Controller initiates a potential hierarchy of Domain Controllers, each with their own area of delegated control. The master domain controller has the ability to override any downstream controller, but a downline controller has control only over its downline. With Samba-3, this functionality can be implemented using an LDAP-based user and machine account backend.

New to Samba-3 is the ability to use a backend database that holds the same type of data as the NT4-style SAM database (one of the registry files)^[1].

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 most likely 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 online 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 also need to be made.

With MS Windows NT4, a decision is made at installation to determine what type of machine the server will be. It is possible to promote a BDC to a PDC and vice versa. 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 also supports the MS Windows 200x Domain Control protocols.

At this time any appearance that Samba-3 is capable of acting as an Domain Controller in native ADS mode 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. Samba can act as a NT4-style DC in a Windows 2000/XP environment. However, there are certain compromises:

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 involves no special configuration other than the machine being configured so the network configuration has a commonly used name for its workgroup entry. It is not uncommon for the name WORKGROUP to be used for this. With this mode of configurationi, 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 neighborhood to be logically grouped together. Again, just to be clear: workgroup mode does not involve 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 effect Domain Membership. This procedure, which can be done only by the local machine Administrator account, will create the Domain machine account (if it 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:

It is rather easy to configure Samba to provide these. Each Samba Domain Controller must provide the NETLOGON service that Samba calls the domain logons functionality (after the name of the parameter in the smb.conf file). Additionally, one server in a Samba-3 Domain must advertise itself as the Domain Master Browser^[3]. This causes the Primary Domain Controller to claim a domain-specific NetBIOS name that identifies it as a Domain Master Browser for its given domain or workgroup. Local master browsers in the same domain or 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.

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 it is okay to configure Samba as a Domain Controller in security modes other than user. The only security mode that 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 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. A DMB is a Domain Master Browser see . For this reason, it is 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, it is a fact that some other machine on the network (the password server) knows more about the user than the Samba host. About 99% of the time, this other host is a Domain Controller. Now 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, 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) will not create a user with a “$” in the 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 login 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:\> 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 cannot 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.

To reset or change the domain SID you can use the net command as follows:

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

Workstation Machine Trust Accounts work only with the Domain (or network) SID. If this SID changes Domain Members (workstations) will not be able to log onto the domain. The original Domain SID can be recovered from the secrets.tdb file. The alternative is to visit each workstation to re-join it to the domain.

“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.

Alternately, 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.

“When I attempt to login to a Samba Domain from a NT4/W200x workstation, I get a message about my account being disabled.”

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

“Until a few minutes after Samba has started, clients get the error `Domain Controller Unavailable'”

A Domain Controller has to announce its role on the network. This usually takes a while. Be patient for up to fifteen minutes, then try again.

After successfully joining the domain, user logons fail with one of two messages: one to the effect that the Domain Controller cannot be found; the other claims that the account does not exist in the domain or that the password is incorrect. This may be due to incompatible settings between the Windows client and the Samba-3 server for schannel (secure channel) settings or smb signing settings. Check your Samba settings for client schannel, server schannel, client signing, server signing by executing:

testparm -v | more and looking for the value of these parameters.

Also use the Microsoft Management Console Local Security Settings. This tool is available from the Control Panel. The Policy settings are found in the Local Policies/Securty Options area and are prefixed by Secure Channel: ..., and Digitally sign .....

It is important that these be set consistently with the Samba-3 server settings.

Whenever a user logs into a Windows NT4/200x/XP Professional Workstation, the workstation connects to a Domain Controller (authentication server) to validate that the username and password the user entered are valid. If the information entered does not match account information that has been stored in the Domain Control database (the SAM, or Security Account Manager database), 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:\Windows NT\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 inter-operation of a PDC and its BDCs in a true Windows NT4 environemt is worth mentioning here. 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 synchronization. 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.

Samba-3 can not participate in true SAM replication and is therefore not able to employ precisely the same protocols used by MS Windows NT4. A Samba-3 BDC will not create SAM update delta files. It will not inter-operate with a PDC (NT4 or Samba) to synchronize the SAM from delta files that are held by BDCs.

Samba-3 cannot function as a BDC to an MS Windows NT4 PDC, and Samba-3 can not function correctly as a PDC to an MS Windows NT4 BDC. Both Samba-3 and MS Windows NT4 can function as a BDC to its own type of PDC.

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

In the event that the NT4 PDC should need to be taken out of service, or if it dies, one of the NT4 BDCs can be promoted to a PDC. If this happens while the original NT4 PDC is on line, it is automatically demoted to an NT4 BDC. This is an important aspect of Domain Controller management. The tool that is used to effect a promotion or a demotion is the Server Manager for Domains. It should be noted that Samba-3 BDCs can not be promoted in this manner because reconfiguration of Samba requires changes to the smb.conf file.

When configuring a master and a slave LDAP server, it is advisable to use the master LDAP server for the PDC and slave LDAP servers for the BDCs. It is not essential to use slave LDAP servers, however, many administrators will want to do so in order to provide redundant services. Of course, one or more BDCs may use any slave LDAP server. Then again, it is entirely possible to use a single LDAP server for the entire network.

When configuring a master LDAP server that will have slave LDAP servers, do not forget to configure this in the /etc/openldap/slapd.conf file. It must be noted that the DN of a server certificate must use the CN attribute to name the server, and the CN must carry the servers' fully qualified domain name. Additional alias names and wildcards may be present in the subjectAltName certificate extension. More details on server certificate names are in RFC2830.

It does not really fit within the scope of this document, but a working LDAP installation is basic to LDAP enabled Samba operation. When using an OpenLdap server with Transport Layer Security (TLS), the machine name in /etc/ssl/certs/slapd.pem must be the same as in /etc/openldap/sldap.conf. The Red Hat Linux startup script creates the slapd.pem file with hostname “localhost.localdomain.” It is impossible to access this LDAP server from a slave LDAP server (i.e., a Samba BDC) unless the certificate is recreated with a correct hostname.

Do not install a Samba PDC on a OpenLDAP slave server. Joining client machines to the domain will fail in this configuration because the change to the machine account in the LDAP tree must take place on the master LDAP server. This is not replicated rapidly enough to the slave server that the PDC queries. It therfore gives an error message on the client machine about not being able to set up account credentials. The machine account is created on the LDAP server but the password fields will be empty.

Possible PDC/BDC plus LDAP configurations include:

In order to have a fall-back configuration (secondary) LDAP server one would specify the secondary LDAP server in the smb.conf file as shown in .

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 cannot be an Active Directory server. This means that Samba-3 also cannot act as a Backup Domain Controller to an Active Directory Domain Controller.

Every machine that is a Domain Controller for the domain MIDEARTH has to register the NetBIOS group name MIDEARTH<#1c> with the WINS server and/or by broadcast on the local network. The PDC also registers the unique NetBIOS name MIDEARTH<#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.

Where a WINS server is not used, broadcast name registrations alone must suffice. Refer to for more information regarding TCP/IP network protocols and how SMB/CIFS names are handled.

There are two different mechanisms to locate a domain controller, one method is used when NetBIOS over TCP/IP is enabled and the other when it has been disabled in the TCP/IP network configuration.

Where NetBIOS over TCP/IP is disabled, all name resolution involves the use of DNS, broadcast messaging over UDP, as well as Active Directory communication technologies. In this type of environment all machines require appropriate DNS entries. More information may be found in .

Finally, the BDC has to be found by the workstations. This can be done by setting Samba as shown in .

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.

The idmap backend will redirect the winbindd utility to use the LDAP database to resolve all UIDs and GIDs for UNIX accounts.

The use of the idmap backend = ldap://master.quenya/org option on a BDC only make sense where ldapsam is used on a PDC. The purpose for an LDAP based idmap backend is also to allow a domain-member (without its own passdb backend) to use winbindd to resolve Windows network users and groups to common UID/GIDs. In other words, this option is generally intended for use on BDCs and on Domain Member servers.

This problem will occur when the passdb (SAM) files are copied from a central server but the local Backup Domain Controller is acting as a PDC. This results in the application of Local Machine Trust Account password updates to the local SAM. Such updates are not copied back to the central server. The newer machine account password is then over written when the SAM is re-copied from the PDC. The result is that the Domain Member machine on start up will find that its passwords do 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 is to use a more robust passdb backend, such as the ldapsam backend, setting up a slave LDAP server for each BDC, and a master LDAP server for the PDC.

No. The native NT4 SAM replication protocols have not yet been fully implemented.

Can I get the benefits of a BDC with Samba? Yes, but only to a Samba PDC.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 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 machines -d /dev/null -c "machine nickname" \
   -s /bin/false machine_name$ 

root# passwd -l machine_name$

In the above example above there is an existing system group “machines” which is used as the primary group for all machine accounts. In the following examples the “machines” group has numeric GID equal 100.

On *BSD systems, this can be done using the chpass utility:

root# chpass -a \
'machine_name$:*:101:100::0:0:Windows machine_name:/dev/null:/sbin/nologin'

The /etc/passwd entry will list the machine name with a “$” appended, will not 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:100: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 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.

A working add machine script script is essential for machine trust accounts to be automatically created. This applies no matter whether one uses automatic account creation, or if one wishes to use the NT4 Domain Server Manager.

If the machine from which you are trying to manage the domain is an MS Windows NT4 workstation or MS Windows 200x/XP Professional, the tool of choice is the package called SRVTOOLS.EXE. When executed in the target directory it will unpack SrvMgr.exe and UsrMgr.exe (both are domain management tools for MS Windows NT4 workstation).

If your workstation is a Microsoft Windows 9x/Me family 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 this platform.

Further information about these tools may be obtained from the following locations:

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.

Here is an example for a Red Hat Linux system.

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

lists names that have been used in the remainder of this chapter.

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:

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

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. This is the defaulty setting if this parameter is not specified. There is no need to specify this parameter, but if it is specified in the smb.conf file, it must be set to Yes.

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

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.

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

This method allows Samba to use exactly the same mechanism that NT does. The method either uses broadcast-based name resolution, performs a WINS database lookup in order to find a Domain Controller against which to authenticate, or locates the Domain Controller using DNS name resolution.

To join the domain, run this command:

root# net join -S DOMPDC -UAdministrator%password

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

The machine is joining the domain DOM, and the PDC for that domain (the only machine that has write access to the domain SAM database) is DOMPDC, therefore use the -S option. The Administrator%password is the login name and password for an account that has the necessary privilege to add machines to the domain. If this is successful, you will see the message in your terminal window the text shown below. Where the older NT4 style domain architecture is used:

Joined domain DOM.

Where Active Directory is used:

Joined SERV1 to realm MYREALM.

Refer to the net man page for further information.

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 a smbpasswd file would be normally stored:

/usr/local/samba/private/secrets.tdb
or 
/etc/samba/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. The way you can restart your Samba daemons depends on your distribution, but in most cases the following will suffice:

root# /etc/init.d/samba restart

Currently, domain security in Samba does not 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 file system. This is 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 , 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, and so on.

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

In case samba cannot correctly identify the appropriate ADS server using the realm name, use the password server option in smb.conf:

With both MIT and Heimdal Kerberos, this is unnecessary, and may be detrimental. All ADS domains will automatically create SRV records in the DNS zone _kerberos.REALM.NAME for each KDC in the realm. MIT's, as well as Heimdal's, KRB5 libraries default to checking for these records, so they will automatically find the KDCs. In addition, krb5.conf only allows specifying a single KDC, even there if there is more than one. Using the DNS lookup allows the KRB5 libraries to use whichever KDCs are available.

When manually configuring krb5.conf, the minimal configuration is:

[libdefaults]
   default_realm = YOUR.KERBEROS.REALM

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

When using Heimdal versions before 0.6 use the following configuration settings:

[libdefaults]
   default_realm      = YOUR.KERBEROS.REALM
   default_etypes     = des-cbc-crc des-cbc-md5
   default_etypes_des = des-cbc-crc des-cbc-md5

        [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.

With Heimdal versions earlier than 0.6.x you only can use newly created accounts in ADS or accounts that have had the password changed once after migration, or in case of Administrator after installation. At the moment, a Windows 2003 KDC can only be used with a Heimdal releases later than 0.6 (and no default etypes in krb5.conf). Unfortunatly this whole area is still in a state of flux.

Clock skew limits are configurable in the Kerberos protocols. The default setting is five minutes.

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 (i.e., the hostname with no domain attached) or it can alternately 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 do not get this correct 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 directly to now. and are needed only if you want Kerberos support for smbd and winbindd.

As a user who has write permission on the Samba private directory (usually root), run:

root#  net ads join -U Administrator%password

When making a Windows client a member of an ADS domain within a complex organization, you may want to create the machine account within a particular organizational unit. Samba-3 permits this to be done using the following syntax:

root#   kinit Administrator@your.kerberos.REALM
root#  net ads join “organizational_unit”

For example, you may want to create the machine account in a container called “Servers” under the organizational directory “Computers\BusinessUnit\Department” like this:

root#  net ads join "Computers\BusinessUnit\Department\Servers"

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 encryption 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 encryption types.

Windows 200x does not seem to create the _kerberos._udp and _ldap._tcp in the default DNS setup. Perhaps this will be fixed later in service packs.

“A Windows workstation was re-installed. 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 does not. 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 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 its 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:

The add machine script does not create the machine account in the Samba backend database, it is there only to create a UNIX system account to which the Samba backend database account can be mapped.

Windows 2003 requires SMB signing. Client side SMB signing has been implemented in Samba-3.0. Set client use spnego = yes when communicating with a Windows 2003 server.

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

In above, the machine name is set to GANDALF, the workgroup is set to the name of the local workgroup (MIDEARTH) so the machine will appear together with systems with which users are familiar. The only password backend required is the “guest” backend to allow default unprivileged account names to be used. As there is a WINS server on this networki, we of obviously make use of it.

Configuration of a simple print server is easy 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:

The contents of the smb.conf file is shown in .

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 effect 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 machine as the WINS server. This makes it easy to manage the browsing environment. If each network segment is configured with its 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 effect 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 (i.e., 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 stabilize, particularly across network segments.

All TCP/IP-enabled systems use various forms of host name resolution. The primary methods for TCP/IP hostname resolution involve either a static file (/etc/hosts) or the Domain Name System (DNS). 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 its 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 unable to locate each other, so 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 its 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 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 configure cross-subnet browsing on a network containing machines 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 another subnet. It is the presence of a Domain Master Browser that makes cross-subnet browsing possible for a workgroup.

In a 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:

The Domain Master Browser should preferably 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 as shown in .

The Domain Master Browser may be the same machine as the WINS server, if necessary.

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/200x/XP machine should be able to do this, as will Windows 9x/Me machines (although these tend to get rebooted more often, so it is 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 as shown in :

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 it should win any browser elections.

If you have an NT machine on the subnet that you wish to be the Local Master Browser, you can disable Samba from becoming a Local Master Browser by setting the following options in the [global] section of the smb.conf file as shown in :

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. Network browsing may 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 as shown in :

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 refer to .

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

Who becomes the master browser is determined by an election process using broadcasts. Each election packet contains a number of parameters that determine what precedence (bias) a host should have in the election. By default Samba uses a low precedence and thus loses elections to just about every Windows network server or client.

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

An os level of two would make it beat Windows for Workgroups and Windows 9x/Me, but not MS Windows NT/200x Server. An MS Windows NT/200x Server Domain Controller uses level 32. The maximum os level is 255.

If you want Samba to force an election on startup, 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 Perferred Master Browsers. Use this parameter with care, as if you have two hosts (whether they are Windows 9x/Me or NT/200x/XP 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.