| Intro | Install | Configure | Troubleshoot | Optimize | PDC | Security |
David Lechnyr <david@lechnyr.com>
Fri, 9 May 2003 13:02:25 -0700
"I tried to get some documentation out of Digital on this, but as far as I can tell even _they_ don't have it ;-)" -- Linus Torvalds, in an article on a dnserver
To run as a Primary Domain controller (PDC), you will need to add the following entries to your smb.conf file:
[global] domain logons = yes encrypt passwords = yes guest account = smbguest log level = 2 log file = /var/log/samba.log logon drive = p: logon home = \\example-server\%U netbios name = example-server os level = 99 preferred master = yes security = user socket options = TCP_NODELAY IPTOS_LOWDELAY SO_RCVBUF=8192 SO_SNDBUF=8192 wins support = yes workgroup = example-wrkgrp [homes] read only = no create mode = 0600 directory mode = 0700 [netlogon] path = /home/netlogon
To effectively manage your Samba/Windows collection of computers, it is critical that you understand how Windows NT/2000/2003 Servers provide security through the use of Users and Groups. Specifically, you must be aware that there is a difference between the following four different types of Users and Groups:
Local Users are accounts that are unique to a single workstation. Each Windows 2000/XP workstation has two built-in Users: Administrator and Guest. Local Users are not available on Domain Controllers.
Local Groups are groups that are unique to a single workstation. Each Windows 2000/XP workstation has several built-in Groups: Administrators have complete and unrestricted access to the workstation; Power Users have most administrative powers with some restrictions and can run legacy applications in addition to certified applications; Users are prevented from making accidental or intentional system-wide changes, and can run certified applications but not most legacy applications; the Guests Local Group actually has the same access permissions as the Users group (something that is often overlooked). Local Groups are not available on Domain Controllers.
Domain Users are accounts that are created on a Windows NT/2000/2003 Server that is acting as a Primary Domain Controller. Samba mimics this behavior by treating every user in smbpasswd(8) as a Domain User. If the user root is defined in smbpasswd, it is equivalent to the Administrator account on Windows NT/2000/2003.
Domain Groups are groups that are created on a Windows NT/2000/2003 Server that is acting as a Primary Domain Controller. Samba technically only has two Domain Groups: the root user, and everyone else. However, Samba mimics additional group behavior by honoring filesystem permission restrictions using the group membership information in /etc/groups -- see groups(1) for more information.
Samba has no knowledge of Windows 2000/XP Local Accounts; as far as it is concerned, there are only multiple users (defined in smbpasswd) and a single Administrator named root (if defined in smbpasswd). Samba also has no knowledge (nor does it care) about Windows 2000/XP Local Groups; all Samba group memberships are defined in /etc/groups.
The reverse is also true -- Windows 2000/XP has no direct knowledge of Samba Domain Users or the /etc/groups file on the Samba box. Therefore, it is possible to log into the domain as root (not advised for the security conscious) yet not have any administrative authority over the Windows 2000/XP box!
Under Windows NT/2000/2003 Servers, you can add Local Users, Global Users, and Global Groups to Local Groups. With Samba, you can add Local Users and Global Users to Local Groups. However, with both Windows NT/2000/2003 Servers and Samba Servers, you cannot add Local Users and Local Groups to Global Groups.
One option to get around this is to select one account from Samba to add it to each Windows 2000/XP workstation's Administrators Local Group. This needs to be done on a per-workstation basis since Local Groups are just that -- local to the box itself, and to no one else. There is no way to do this from the Samba server (nor should there be) or even from a Windows 2000 Server.
Regarding setting up security and the Group Policy Editor, see Microsoft Knowledge Base Article 307882.
Microsoft's description of Local/Domain Users/Groups is available in their helpfile %SYSTEMROOT%\Help\LOCALSEC.CHM.
It's fairly easy to join a domain with Windows 95/98/ME. You can join the domain by adjusting the properties to "Client for Microsoft Networks" in the Network Control Panel. This is not a big area of interest for most, so it's probably the shortest section ;-) Please note that Windows 95 and 95A don't use encrypted passwords, so this option must be disabled in your smb.conf to support these clients (and your non-Win95 clients will need a patch then; see /docs/Registry/ in the Samba source code).
Unfortunately, the most common problem with Windows XP Home Edition is using Windows XP Home Edition itself. There are several limits to its design, most noteworthy being the inability to join or access a domain-based network.
To allow Windows XP Professional (not W2K) to join a Samba Domain, you will need to first make the following changes to your registry and reboot:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters] "requiresignorseal"=dword:00000000 "signsecurechannel"=dword:00000000
When establishing your machine as a member of a domain, you'll need to add each Windows machine into your Linux machine's password file using vipw(8) or an equivalent. Regardless, the entry in /etc/passwd should look something like this (below). Note the dollar sign ($) at the end of the workstation name; if your workstation's name is PC-LAB15, your entry in /etc/passwd should begin with PC-LAB15$ -- this is commonly overlooked. For information on the fields in /etc/passwd itself, try `man 5 passwd`.
pc-lab15$:x:1200:300:Workstation:/dev/null:/bin/falseYou should also have a group account specific to workstation-only accounts, using vigr(8) or an equivalent:
workstation::300:And your entry in /etc/shadow (hint: try `vipw -s`) should look like:
pc-lab15$:*:9797:0:::::Finally, you need to add this account to the Samba password file. Note the lack of a dollar-sign here! The -m switch tells Samba that this is a machine account, and the -a switch tells it to add this account to the database. Note that this account won't have an initial password, so it's important to run this step immediately prior to having the workstation join your domain.
smbpasswd -m -a pc-lab15To allow anyone to actually join, however, you'll need to add a smbpasswd entry for the user "root" -- this is required!
Log in with an account that is a member of the Local Administrator's group. Note that this account should not exist on your Samba box.
Next, drop to a MS-DOS prompt and delete any existing NetBIOS connections. This will ensure that no ghosted connections to NETLOGON or $IPC exist:
NET USE * /DELETE /YESIn your System Properties, locate the Computer Name section, and click Change. From here, you can join your Samba domain, which is the "Workgroup" parameter from your smb.conf file. You'll be prompted for a name and password of an account with permissions to join the domain; only the user account "root" will work here, and the account must exist both on your Linux box (of course) and in your smbpasswd file.
Possible error messages you might encounter when trying to join the domain are:
It's also worth mentioning a bit about notepad: If you find that notepad starts with:
"[.ShellClassInfo] LocalizedResourceName=@%SystemRoot%\System32\Shell32.dll,-21787"
when you log into your Samba domain, please see Microsoft Knowledge Base Article 330132. This annoying problem is actually a non-Samba-related issue (although it comes up frequently).
If you'd like to enable roaming profiles for Windows 2000/XP, make the following changes to your smb.conf file (below). Note that this is strongly discouraged unless you know what you're doing (headache prevention)!
[global] logon path = \\example-server\profile\%U [profile] create mode = 0600 csc policy = disable directory mode = 0700 path = /home/profile profile acls = yes read only = no
Due to some changes introduced with Windows XP Service Pack 1/1a, you must choose one of the following methods regarding how you intend to implement Roaming Policies:
If you're running your Samba server to act as a Primary Domain Controller (PDC) for Windows clients, you can have a batch file execute upon login. This can be enabled by adding the following to your smb.conf file:
[global] logon script = logon.bat [netlogon] path = /home/netlogon
All login scripts must reside in the [netlogon] share and should be formatted to be readable by your Windows clients (see Line Feeds CR/LF below). Here's a sample script which I've found to be quite useful:
@echo off REM Synchronize the client's clock with the server. REM Requires Power User rights, however NET TIME \\example-server /SET /YES REM Map some drives NET USE F: \\example-server\PUBLIC /YES NET USE I: \\example-server\INSTALL /YES REM Map the user's home directory NET USE P: /HOME /YES REM Run Symantec Liveupdate (silently) for Antivirus definitions. REM Does not require the user to have local adminstrator rights ;-) IF EXIST "C:\Program Files\Symantec\LiveUpdate\Luall.exe" "C:\Program Files\Symantec\LiveUpdate\Luall.exe" -s REM Run WinNT/2K/XP/2003 specific stuff IF NOT "%OS%"=="Windows_NT" goto noxp IF NOT EXIST "\\example-server\%USERNAME%\xpbackup" mkdir "\\example-server\%USERNAME%\xpbackup" REM /c ignore errors, /h copy hidden/system files, /r copy read-only files, /y no promp, /d only copy newer files
XCOPY "%HOMEDRIVE%\%HOMEPATH%\*.*" "\\example-server\%USERNAME%\xpbackup\*.* /S /E /C /H /R /Y /D IF ERRORLEVEL 0 GOTO services ECHO There was an error backing up your files :services REM Adjust some services NET STOP "Protected Storage" NET START "Automatic Updates" REM Back up the client's registry REGEDIT /E P:\Registry.bak REM Update (silently) the client's registry REM Depending on what you import, you need the appropriate user rights REGEDIT /S "\\example-serverNAME\NETLOGON\winxp.reg" :noxp echo Done!
Another issue to become aware of with login scripts is linefeeds. If you're working in a Linux/Windows mixed environment, you're bound to come across files that are littered with '^M' at the end of every line. This is the Windows command for 'newline', which uses a combination of CR/LF, whereas Linux uses just the single LF. To convert a text file from DOS to Linux, thereby removing the '^M' newline characters in the file, use the fromdos command:
fromdos < dosfile > linuxfile
To convert a text file from Linux to DOS, thus adding the '^M' newline characters so that the file can be read by your Windows clients, use todos:
todos < linuxfile > dosfile
Alternately, if you find you don't have the fromdos/todos utilities, you can try this simple trick:
cat dosfile | col -b > linuxfile
It's worth noting that if you're running into this problem in the first place, it means you're working on a file that is being edited in both your Linux and Windows environments. As such, you should probably read the section on Oplocks to prevent any data loss...
If you'd rather take care of things from the Windows side of the coin, you can simply use a text editor that can convert between DOS/Linux. My personal favorite is Jean-Pierre Menicucci's Editeur which includes syntax highlighting, although you're encouraged to look around for what fits your needs best.
Copyright © 2003 David Lechnyr <david@lechnyr.com>
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free
Software Foundation. A copy of the license is available at http://www.gnu.org/licenses/fdl.txt.
| Intro | Install | Configure | Troubleshoot | Optimize | PDC | Security |