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:

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 correct place (usually in /etc/samba).

For more information about security settings for the [homes] share please refer to "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.

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 configured properly. 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 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).

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.

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.

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

root# net rpc join -U Administrator%password

Both Samba 2.2 and 3.0 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. The only thing that Active Directory in native mode prohibits is Backup Domain Controllers running 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 a NT4-style domain would still require NT-compatible authentication data. Samba in AD-member mode can accept Kerberos tickets.

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.

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 chapter about domain membership 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. In Windows 200x Domain Control architecture this role is held by domain controllers. There is folk lore that dictates that because of it's role in the MS Windows network, the domain controllers 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 Stand-Alone (or 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 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 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 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). ^[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 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 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 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^[2]. 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.

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. A DMB is a Domain Master Browser - see Domain Master Browser. 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!

“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 can not log you on (C000019B), Please try again or consult your system administrator when attempting to logon.”

This occurs when the domain SID stored in the secrets.tdb database is changed. The most common cause of a change in domain SID is when the domain name and/or the server name (NetBIOS name) is changed. The only way to correct the problem is to restore the original domain SID or remove the domain client from the domain and rejoin. The domain SID may be reset using either the net or rpcclient utilities.

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

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

Workstation machine trust accounts work only with the Domain (or network) SID. If this SID changes then 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.

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.

“When I attempt to login to a Samba Domain from a NT4/W2K 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 on the network who it is. This usually takes a while.

After successfully joining the domain user logons fail with one of two messages:

One to the effect that the domain controller can not be found, the other claiming 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 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.

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:

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.

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 Samba-3.

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

If the machine from which you are trying to manage the domain is an MS Windows NT4 workstation or MS Windows 200x / XP Professional 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 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: http://support.microsoft.com/default.aspx?scid=kb;en-us;173673 http://support.microsoft.com/default.aspx?scid=kb;en-us;172540

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.

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:

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

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:

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:

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 rpc 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 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! The way you can restart your samba daemons depends on your distribution, but in most cases running

	root# /etc/init.d/samba restart

does the job.

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 chapter on winbind 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:

In case samba can't figure out your ads server using your realm name, use the ads server option in smb.conf:

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.

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

root#  net ads 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 this will be fixed later in service packs.

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

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:

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 :

The domain master browser should also 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 :

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 :

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 :

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 :

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 :

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.

The remote announce parameter of smb.conf can be used to forcibly ensure that all the NetBIOS names on a network get announced to a remote network. The syntax of the remote announce parameter is:

or

where:

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.

The syntax of the remote browse sync parameter is:

where a.b.c.d is either the IP address of the remote LMB or else is the network broadcast address of the remote segment.

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 [global] section add the line

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 :

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

Entries in wins.dat take the form of

"NAME#TYPE" TTL ADDRESS+ FLAGS

where NAME is the NetBIOS name, TYPE is the NetBIOS type, TTL is the time-to-live as an absolute time in seconds, ADDRESS+ is one or more addresses corresponding to the registration and FLAGS are the NetBIOS flags for the registration.

A typical dynamic entry looks like:

"MADMAN#03" 1055298378 192.168.1.2 66R

To make it static, all that has to be done is set the TTL to 0:

"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:

Many sites want to restrict DNS lookups and want to avoid broadcast name resolution traffic. The name resolve order parameter is of great help here. The syntax of the name resolve order parameter is:

or

The default is:

where "host" refers to the native methods used by the UNIX system to implement the gethostbyname() function call. This is normally controlled by /etc/host.conf, /etc/nsswitch.conf and /etc/resolv.conf.

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.

How does cross subnet browsing work ?

Cross subnet browsing is a complicated dance, containing multiple moving parts. It has taken Microsoft several years to get the code that achieves this correct, and Samba lags behind in some areas. Samba is capable of cross subnet browsing when configured correctly.

Consider a network set up as in the diagram below.

Figure 10.1. Cross subnet browsing example

Consisting of 3 subnets (1, 2, 3) connected by two routers (R1, R2) - these do not pass broadcasts. Subnet 1 has 5 machines on it, subnet 2 has 4 machines, subnet 3 has 4 machines. Assume for the moment that all these machines are configured to be in the same workgroup (for simplicity's sake). Machine N1_C on subnet 1 is configured as Domain Master Browser (ie. it will collate the browse lists for the workgroup). Machine N2_D is configured as WINS server and all the other machines are configured to register their NetBIOS names with it.

As all these machines are booted up, elections for master browsers will take place on each of the three subnets. Assume that machine N1_C wins on subnet 1, N2_B wins on subnet 2, and N3_D wins on subnet 3 - these machines are known as local master browsers for their particular subnet. N1_C has an advantage in winning as the local master browser on subnet 1 as it is set up as Domain Master Browser.

On each of the three networks, machines that are configured to offer sharing services will broadcast that they are offering these services. The local master browser on each subnet will receive these broadcasts and keep a record of the fact that the machine is offering a service. This list of records is the basis of the browse list. For this case, assume that all the machines are configured to offer services so all machines will be on the browse list.

For each network, the local master browser on that network is considered 'authoritative' for all the names it receives via local broadcast. This is because a machine seen by the local master browser via a local broadcast must be on the same network as the local master browser and thus is a 'trusted' and 'verifiable' resource. Machines on other networks that the local master browsers learn about when collating their browse lists have not been directly seen - these records are called 'non-authoritative'.

At this point the browse lists look as follows (these are the machines you would see in your network neighborhood if you looked in it on a particular network right now).

Table 10.1. Browse subnet example 1

Subnet	Browse Master	List
Subnet1	N1_C	N1_A, N1_B, N1_C, N1_D, N1_E
Subnet2	N2_B	N2_A, N2_B, N2_C, N2_D
Subnet3	N3_D	N3_A, N3_B, N3_C, N3_D

Note that at this point all the subnets are separate, no machine is seen across any of the subnets.

Now examine subnet 2. As soon as N2_B has become the local master browser it looks for a Domain master browser to synchronize its browse list with. It does this by querying the WINS server (N2_D) for the IP address associated with the NetBIOS name WORKGROUP<1B>. This name was registered by the Domain master browser (N1_C) with the WINS server as soon as it was booted.

Once N2_B knows the address of the Domain master browser it tells it that is the local master browser for subnet 2 by sending a MasterAnnouncement packet as a UDP port 138 packet. It then synchronizes with it by doing a NetServerEnum2 call. This tells the Domain Master Browser to send it all the server names it knows about. Once the domain master browser receives the MasterAnnouncement packet it schedules a synchronization request to the sender of that packet. After both synchronizations are done the browse lists look like :

Table 10.2. Browse subnet example 2

Subnet	Browse Master	List
Subnet1	N1_C	N1_A, N1_B, N1_C, N1_D, N1_E, N2_A(*), N2_B(*), N2_C(*), N2_D(*)
Subnet2	N2_B	N2_A, N2_B, N2_C, N2_D, N1_A(*), N1_B(*), N1_C(*), N1_D(*), N1_E(*)
Subnet3	N3_D	N3_A, N3_B, N3_C, N3_D

Servers with a (*) after them are non-authoritative names.

At this point users looking in their network neighborhood on subnets 1 or 2 will see all the servers on both, users on subnet 3 will still only see the servers on their own subnet.

The same sequence of events that occurred for N2_B now occurs for the local master browser on subnet 3 (N3_D). When it synchronizes browse lists with the domain master browser (N1_A) it gets both the server entries on subnet 1, and those on subnet 2. After N3_D has synchronized with N1_C and vica-versa the browse lists look like.

Table 10.3. Browse subnet example 3

Subnet	Browse Master	List
Subnet1	N1_C	N1_A, N1_B, N1_C, N1_D, N1_E, N2_A(*), N2_B(*), N2_C(*), N2_D(*), N3_A(*), N3_B(*), N3_C(*), N3_D(*)
Subnet2	N2_B	N2_A, N2_B, N2_C, N2_D, N1_A(*), N1_B(*), N1_C(*), N1_D(*), N1_E(*)
Subnet3	N3_D	N3_A, N3_B, N3_C, N3_D, N1_A(*), N1_B(*), N1_C(*), N1_D(*), N1_E(*), N2_A(*), N2_B(*), N2_C(*), N2_D(*)

Servers with a (*) after them are non-authoritative names.

At this point users looking in their network neighborhood on subnets 1 or 3 will see all the servers on all subnets, users on subnet 2 will still only see the servers on subnets 1 and 2, but not 3.

Finally, the local master browser for subnet 2 (N2_B) will sync again with the domain master browser (N1_C) and will receive the missing server entries. Finally - and as a steady state (if no machines are removed or shut off) the browse lists will look like :

Table 10.4. Browse subnet example 4

Subnet	Browse Master	List
Subnet1	N1_C	N1_A, N1_B, N1_C, N1_D, N1_E, N2_A(*), N2_B(*), N2_C(*), N2_D(*), N3_A(*), N3_B(*), N3_C(*), N3_D(*)
Subnet2	N2_B	N2_A, N2_B, N2_C, N2_D, N1_A(*), N1_B(*), N1_C(*), N1_D(*), N1_E(*), N3_A(*), N3_B(*), N3_C(*), N3_D(*)
Subnet3	N3_D	N3_A, N3_B, N3_C, N3_D, N1_A(*), N1_B(*), N1_C(*), N1_D(*), N1_E(*), N2_A(*), N2_B(*), N2_C(*), N2_D(*)

Servers with a (*) after them are non-authoritative names.

Synchronizations between the domain master browser and local master browsers will continue to occur, but this should be a steady state situation.

If either router R1 or R2 fails the following will occur:

1. Names of computers on each side of the inaccessible network fragments will be maintained for as long as 36 minutes, in the network neighbourhood lists.

2. Attempts to connect to these inaccessible computers will fail, but the names will not be removed from the network neighbourhood lists.

3. If one of the fragments is cut off from the WINS server, it will only be able to access servers on its local subnet, by using subnet-isolated broadcast NetBIOS name resolution. The effects are similar to that of losing access to a DNS server.