4.5 Domain and Network Logon Configuration

The subject of Network or Domain Logons is discussed here because it forms an integral part of the essential functionality that is provided by a Domain Controller.

4.5.1 Domain Network Logon Service

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.

4.5.1.1 Example Configuration

Example 4.2 smb.conf for being a PDC

  [global]   domain logons = Yes   domain master = (Yes on PDC, No on BDCs)   [netlogon]   comment = Network Logon Service   path = /var/lib/samba/netlogon   guest ok = Yes   browseable = No  

4.5.1.2 The Special Case of MS Windows XP Home Edition

To be completely clear: If you want MS Windows XP Home Edition to integrate with your MS Windows NT4 or Active Directory Domain Security, understand it cannot be done. The only option is to purchase the upgrade from MS Windows XP Home Edition to MS Windows XP Professional.

N OTE

MS Windows XP Home Edition does not have the ability to join any type of Domain Security facility. Unlike MS Windows 9x/Me, MS Windows XP Home Edition also completely lacks the ability to log onto a network.

Now that this has been said, please do not ask the mailing list or email any of the Samba Team members with your questions asking how to make this work. It can't be done. If it can be done, then to do so would violate your software license agreement with Microsoft, and we recommend that you do not do that.

4.5.1.3 The Special Case of Windows 9x/Me

A domain and a workgroup are exactly the same in terms of network browsing. The difference is that a distributable authentication database is associated with a domain, for secure login access to a network. Also, different access rights can be granted to users if they successfully authenticate against a domain logon server. Samba-3 does this now in the same way as MS Windows NT/200x.

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

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

When an SMB client in a domain wishes to logon, it broadcasts 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 ill advised) to create a domain where the user database is not shared between servers, i.e., they are effectively workgroup servers advertising themselves as participating in a domain. This demonstrates how authentication is quite different from but closely involved with domains.

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

MS Windows XP Home edition is not able to join a domain and does not permit the use of domain logons .

Before launching into the configuration instructions, it is worthwhile to look at how a Windows 9x/Me client performs a logon:

1. The client broadcasts (to the IP broadcast address of the subnet it is in) a NetLogon request. This is sent to the NetBIOS name DOMAIN<#1c> at the NetBIOS layer.

   The client chooses the first response it receives, which contains the NetBIOS name of the logon server to use in the format of \\SERVER .

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

3. The client does a Net WkstaUserLogon request, which retrieves the name of the user's logon script.

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

5. The client 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 than the user's home share, profiles for Windows 9x clients must reside in the user home directory.

6. The client 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\.winprofile . If the profiles are found, they are implemented.

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

The main difference between a PDC and a Windows 9x/Me logon server configuration is:

• Password encryption is not required for a Windows 9x/Me logon server. But note that beginning with MS Windows 98 the default setting is that plain-text password support is disabled. It can be re-enabled with the registry changes that are documented in Chapter 22, System and Account Policies .

• Windows 9x/Me clients do not require and do not use Machine Trust Accounts.

A Samba PDC will act as a Windows 9x/Me logon server; after all, it does provide the network logon services that MS Windows 9x/Me expect to find.

N OTE

Use of plain-text passwords is strongly discouraged. Where used they are easily detected using a sniffer tool to examine network traffic.

4.5.2 Security Mode and Master Browsers

There are a few comments to make in order to tie up some loose ends. There has been much debate over the issue of whether 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 Browse see Section 9.4.1. 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 only officially supported mode of operation.