Domain control for Windows 9x/ME

Note: The following section contains much of the original DOMAIN.txt file previously included with Samba. Much of the material is based on what went into the book Special Edition, Using Samba. (Richard Sharpe)

A domain and a workgroup are exactly the same thing in terms of network browsing. The difference is that a distributable authentication database is associated with a domain, for secure login access to a network. Also, different access rights can be granted to users if they successfully authenticate against a domain logon server (NT server and other systems based on NT server support this, as does at least Samba TNG now).

The SMB client logging on to a domain has an expectation that every other server in the domain should accept the same authentication information. Network browsing functionality of domains and workgroups is identical and is explained in BROWSING.txt. It should be noted, that browsing is total orthogonal to logon support.

Issues related to the single-logon network model are discussed in this document. Samba supports domain logons, network logon scripts, and user profiles for MS Windows for workgroups and MS Windows 9X clients.

When an SMB client in a domain wishes to logon it broadcast requests for a logon server. The first one to reply gets the job, and validates its password using whatever mechanism the Samba administrator has installed. It is possible (but very stupid) to create a domain where the user database is not shared between servers, i.e. they are effectively workgroup servers advertising themselves as participating in a domain. This demonstrates how authentication is quite different from but closely involved with domains.

Another thing commonly associated with single-logon domains is remote administration over the SMB protocol. Again, there is no reason why this cannot be implemented with an underlying username database which is different from the Windows NT SAM. Support for the Remote Administration Protocol is planned for a future release of Samba.

Network logon support as discussed in this section is aimed at Window for Workgroups, and Windows 9X clients.

Support for profiles is confirmed as working for Win95, NT 4.0 and NT 3.51. It is possible to specify: the profile location; script file to be loaded on login; the user's home directory; and for NT a kick-off time could also now easily be supported. However, there are some differences between Win9X profile support and WinNT profile support. These are discussed below.

With NT Workstations, all this does not require the use or intervention of an NT 4.0 or NT 3.51 server: Samba can now replace the logon services provided by an NT server, to a limited and experimental degree (for example, running "User Manager for Domains" will not provide you with access to a domain created by a Samba Server).

With Win95, the help of an NT server can be enlisted, both for profile storage and for user authentication. For details on user authentication, see security_level.txt. For details on profile storage, see below.

Using these features you can make your clients verify their logon via the Samba server; make clients run a batch file when they logon to the network and download their preferences, desktop and start menu.

Before launching into the configuration instructions, it is worthwhile looking at how a Win9X client performs a logon:

The client broadcasts (to the IP broadcast address of the subnet it is in) a NetLogon request. This is sent to the NetBIOS address DOMAIN<00> at the NetBIOS layer. The client chooses the first response it receives, which contains the NetBIOS name of the logon server to use in the format of \SERVER.

The client then connects to that server, logs on (does an SMBsessetupX) and then connects to the IPC$ share (using an SMBtconX).

The client then does a NetWkstaUserLogon request, which retrieves the name of the user's logon script.

The client then connects to the NetLogon share and searches for this and if it is found and can be read, is retrieved and executed by the client. After this, the client disconnects from the NetLogon share.

The client then sends a NetUserGetInfo request to the server, to retrieve the user's home share, which is used to search for profiles. Since the response to the NetUserGetInfo request does not contain much more the user's home share, profiles for Win9X clients MUST reside in the user home directory.

The client then connects to the user's home share and searches for the user's profile. As it turns out, you can specify the user's home share as a sharename and path. For example, \server\fred\.profile. If the profiles are found, they are implemented.

The client then disconnects from the user's home share, and reconnects to the NetLogon share and looks for CONFIG.POL, the policies file. If this is found, it is read and implemented.