http:///https:///api.php?action=feedcontributions&user=Gazzonyx&feedformat=atomSambaWiki - User contributions [en]2024-03-28T12:02:34ZUser contributionsMediaWiki 1.39.5https://wiki.samba.org/index.php?title=Setting_up_Samba_as_a_Print_Server&diff=7987Setting up Samba as a Print Server2013-09-12T16:10:13Z<p>Gazzonyx: Mention the ability to load printers on the fly without creating a share for each one.</p>
<hr />
<div>= General =<br />
<br />
== Introduction ==<br />
<br />
This HowTo will provide you an easy guide to setup Samba to act as a Windows print server including Point'n'Click printer driver installation for users.<br />
<br />
'''This HowTo is valid for Samba 3 and 4 print server installations.'''<br />
<br />
<br />
<br />
== Some definitions ==<br />
<br />
; Printer share : Each printer is shared by a name. During the printing process, the client sends the printjob to it.<br />
<br />
; Print server backend : Samba can use e. g. CUPS, LPD/Lprng and other as backend. The print server forwards the job to local or network printers.<br />
<br />
; Windows printer driver : A piece of software, that converts the printed data to a printer specific form. The driver for each shared printer can be preconfigured with default values.<br />
<br />
; Point'n'Print : Windows 2000 and later support the abillity to automatically download and install drivers from the server including preconfiguring, when connecting a printer. The installation can be done by ordinary users, without special permissions.<br />
<br />
; Printer forms : Windows is already shipped with an amount of forms, that define the typical paper sizes. If a formular isn't known to the print server, the client could not use this, altought the printer is able to do it.<br />
<br />
<br />
<br />
== Driver models ==<br />
<br />
Supported by Samba: Printer driver version 3 (Windows 2000 to Windows 8)<br />
<br />
Currently not supported by Samba: [http://msdn.microsoft.com/en-us/library/windows/hardware/hh706306%28v=vs.85%29.aspx Printer driver version 4] (Windows 8)<br />
<br />
<br />
<br />
<br />
<br />
= Print server backend =<br />
<br />
The following sub-chapters will give you a short overview on possible backends, including adding a new network printer, we'll use in our later examples for sharing it by Samba. <br />
<br />
The examples setup a RAW printer (content is send directly to the device). We don't use filters or drivers on the backend, because a RAW printer allows us to render the output on the workstation and use the printer specific driver.<br />
<br />
We assume here, that you have the print server backend already basically configured and it's running, so printers can be added next.<br />
<br />
<br />
<br />
== CUPS ==<br />
<br />
[http://www.cups.org CUPS] is currently the most widely used spool system in *nix environments and shipped with most distributions. Samba has built-in support and defaults to CUPS if the development package (aka header files and libraries) could be found at compile time.<br />
<br />
Basically all sorts of files can be printed with CUPS, but using a Postscript or a RAW printer driver will give you the most benefit in combination with the Windows printer driver, because then all settings can be controlled on the Windows client. <br />
<br />
<br />
<br />
=== Adding a new printer ===<br />
<br />
* Open the CUPS admin webfrontend (https://servername:631/admin).<br />
<br />
* On the „Administration“ tab click the „Add Printer“ button.<br />
<br />
* Choose the way, how your printer is connected and enter the appropriate URL. Examples:<br />
# LPD protocol<br />
lpd://hostname/queue<br />
<br />
# Internet Printing Protocol<br />
ipp://hostname/ipp/port<br />
<br />
# Forwarding the jobs to a Windows print server.<br />
# Hint: Vista and higher, don't allow anonymous connects by default, so you must provide a username and password.<br />
smb://username:password@domain/servername/printername <br />
<br />
* Enter a name for the printer<br />
<br />
* When you reached the step, where to choose the vendor and model, choose „Raw“ for both, because the rendering is already done later by the Windows driver.<br />
<br />
* Save the new added printer.<br />
<br />
<br />
<br />
== LPD ==<br />
<br />
This was the first widely used printing system and still runs on many servers. It is very simple to install and configure. There are different implementations of LPD servers, like the often used [http://www.lprng.org/ LPRng].<br />
<br />
<br />
<br />
=== Adding a new printer ===<br />
<br />
* To add a new network printer, you simply need to add the following line to your 'printcap' (typically '/etc/printcap'). For the different options used in the example, see 'man printcap'.<br />
<br />
PRINTERNAME:sd=/path/to/spool/directory:sh:mx=0:mc=0:rm=IP_or_DNS_Name<br />
<br />
* After adding the new printer entry, run the following command to create the LPD spool directory and restart/reload the service, to take the changes affect.<br />
<br />
# checkpc -f<br />
# service lpd restart<br />
<br />
* The following command allows you query the state of the printer:<br />
<br />
# lpq -P PRINTERNAME<br />
Printer: PRINTERNAME@SAMPRINTSERVER (dest PRINTERNAME@IP_or_DNS_Name)<br />
Queue: no printable jobs in queue<br />
Ready<br />
<br />
no entries<br />
<br />
<br />
<br />
<br />
<br />
= Configuring Samba as print server =<br />
<br />
== General ==<br />
<br />
=== Granting print operator privileges ===<br />
<br />
Users or groups, who should be able to administrate printers on your server, have to be granted the „SePrintOperatorPrivilege“ privilege. It is recommended, to grant it to a domain group, because changes can be done quick and easily with the typical user management tools like ADUC.<br />
<br />
The following example grants the privilege to the domain group „Domain Admins“:<br />
<br />
# net rpc rights grant 'SAMDOM\Domain Admins' SePrintOperatorPrivilege -Uadministrator<br />
<br />
Existing privileges you can reviewed by<br />
<br />
# net rpc rights list accounts -Uadministrator<br />
<br />
<br />
<br />
=== Setup the [printers] share ===<br />
<br />
This share defines general information about your printing backend. See the „[printers]“ section in the man page for additional information.<br />
<br />
* Add the new section to your smb.conf<br />
[printers]<br />
path = /var/spool/samba<br />
printable = yes<br />
printing = CUPS|LPRNG|...<br />
<br />
* If you choose CUPS as backend, make sure, that your smbd is compiled with CUPS support:<br />
# smbd -b | grep CUPS<br />
HAVE_CUPS_CUPS_H<br />
HAVE_CUPS_LANGUAGE_H<br />
HAVE_CUPS<br />
HAVE_LIBCUPS<br />
If you don't get any output, make sure, that the CUPS header files and libraries are installed and recompile Samba with --with-cups.<br />
<br />
* The next step is to create the samba spool directory, defined in the „[printer]“ share. Set the appropriate permissions, depending to your needs.<br />
<br />
# mkdir -p /var/spool/samba/<br />
# chmod 1777 /var/spool/samba/<br />
<br />
<br />
<br />
=== Setup the [print$] share ===<br />
<br />
To enable Point'n'Print support, a share named „print$“ must exist. This share name is hardcoded in Windows clients and can't be choosen.<br />
<br />
* Add the share to your smb.conf<br />
<br />
[print$]<br />
path = /srv/samba/Printer_drivers<br />
comment = Printer Drivers<br />
writeable = yes<br />
<br />
* Create the folder, that will contain the drivers later:<br />
<br />
# mkdir -p /srv/samba/Printer_drivers<br />
<br />
* For special permissions on the share, set them on the folder on *nix side (Samba 3) or through windows (Samba 4).<br />
<br />
* Next we create the required directory structure for the print$ share (newer versions of Samba can create it on the fly when uploading):<br />
<br />
BASEDIR=/srv/samba/Printer_drivers<br />
for i in COLOR IA64 W32ALPHA W32MIPS W32PPC W32X86/{2,3} WIN40 x64; do <br />
mkdir -p $BASEDIR/$i;<br />
done<br />
<br />
* At last, set the appropriate permissions, depending to your needs. Example:<br />
<br />
# chmod -R 755 /srv/samba/Printer_drivers<br />
<br />
:If you're running Samba 4.x have a look at the [[Setup_and_configure_file_shares#Change_permissions_on_folder_of_a_share|Change permissions on a folder of a share]] HowTo, for chaning permissions.<br />
<br />
<br />
<br />
== Sharing a printer with Samba ==<br />
<br />
* For each printer you want to share via Samba, you have to create a separate share (unless you have "load printers = yes" defined in your smb.conf). The following is an example:<br />
<br />
[MyDemoPrinter]<br />
path = /var/spool/samba/<br />
browseable = yes<br />
printable = yes<br />
printer name = Printername_in_backend<br />
<br />
* Set the „printer name“ parameter to the name of your corresponding CUPS/LPD/... queue.<br />
<br />
* To bring the changes live, reload the Samba configuration:<br />
<br />
# smbcontrol all reload-config<br />
<br />
== Uploading printer drivers for Point'n'Print driver installation==<br />
<br />
If you have already uploaded the driver for your printer in the past, you can skip this section.<br />
<br />
If you have to provide a printer driver for x86 and x64 plattforms, you have to upload them from a x64 machine. A x86 client can only upload x86 drivers, while a x64 client can do both. <br />
<br />
It's important, that if you want to provide printing support for multiple plattforms on one printer, that you upload drivers for both, that have exactly the same driver name! Otherwise, the driver for the different plattforms can't be associated.<br />
<br />
The following steps are done on Windows7 64-Bit, to allow uploading x86 and x64 bit drivers, which should work for Windows 2000 to Windows 8.<br />
<br />
* Logon with an account, that has [[#Granting_print_operator_privileges|granted print operator privileges]] to.<br />
<br />
* Go to \\YourPrintserver and click the „View remote printers“ button<br />
:[[Image:Server_Share_List.png]]<br />
<br />
* You will see a list of all printers you have shared.<br />
: [[Image:View_remote_printers.png]]<br />
<br />
* Right-click somewhere in the empty part of the window and choose „Server Properties...“ from the appearing context menu.<br />
<br />
* Next go to the „Drivers“ tab and click the „Add...“ button. The „Add Printer wizzard will appear.<br />
<br />
* Select the driver architecture you want to upload (upload one by one) and click „Next“.<br />
<br />
* Click the „Have Disk...“ button and browse to the directory containing the driver you want to upload.<br />
<br />
* The wizzard will show you a list of all drivers, the directory you pointed to, contains. Select the appropriate driver for your printer and click „Next“.<br />
:[[Image:Printer_driver_selection.png]]<br />
<br />
* In the end, the wizzard will copy all required files to the print$ share of your print server.<br />
<br />
* If you want to upload drivers for a different plattform or other devices, repeat the steps.<br />
<br />
<br />
<br />
== Associating a shared printer with a driver and preconfiguring==<br />
<br />
* Logon with an account, that has [[#Granting_print_operator_privileges|granted print operator privileges]] to.<br />
<br />
* Go to \\YourPrintserver and click the „View remote printers“ button.<br />
:[[Image:Server_Share_List.png]]<br />
<br />
* You will see a list of all printers you have shared.<br />
:[[Image:View_remote_printers.png]]<br />
<br />
* You could do the association of the driver with the printer share on Windows or on *nix side:<br />
<br />
:* On Windows:<br />
<br />
::* Right-click to the shared printer, you would associate a driver with and choose „Properties“.<br />
<br />
::* If there's no driver associated with an printer yet, you'll been asked if you want to install the driver now. Answer this question with „No“!<br />
:::[[Image:Question_install_driver.png]]<br />
<br />
::* A default printer properties window will appear. Go to the „Advanved“ tab and choose the already uploaded driver from the list, that is suitable for the printer.<br />
:::[[Image:Choose_driver.png]]<br />
<br />
::* Close the windows with „OK“ to associate the driver with the printer.<br />
<br />
::* If you do this step on Vista or higher, Windows will ask you, if you trust the server (This can' be suppressed by a GPO. See [[#Setting_up_a_GPO_for_trusting_printer_drivers|Setting up a GPO for trusting printer drivers]]). Choose „Install driver“, if you are seeing this window.<br />
:::[[Image:Question_trust_printer.png]]<br />
<br />
::* After associating the driver, Windows renames the printer to the driver name. You can leave that or rename it again. For more clearness, it's better to set the name on Windows side to the one you used in your smb.conf.<br />
<br />
:* On *nix:<br />
<br />
::* Retrieve a list of all drivers, that are on the print$ share <pre># rpcclient localhost -U administrator -c 'enumdrivers'</pre><br />
<br />
::* Associate the driver with the printer (The driver name, must be exactly the same, like in the output of the above „enumdrivers“ output): <pre># rpcclient localhost -U administrator -c 'setdriver "MyDemoPrinter" "HP Universal Printing PS"'</pre><br />
<br />
::* You can review the associations with <pre># rpcclient localhost -U administrator -c 'enumprinters'</pre><br />
<br />
* On Windows, now right-click and choose „Properties“ again, to preconfigure the printer.<br />
<br />
* First you should take a look on the tabs on the properties windows. Typically there's a tab called „Device Settings“, „Settings“, „Configuration“ or something like that (depending on the driver). This usually allows you to configure the main printer settings (number of trays, duplex on/off, etc.). Set the values fitting to your device and click the „Apply“ button.<br />
:[[Image:Device_Settings.png]]<br />
<br />
* On the „Sharing“ tab, you can check „List in the directory“, to publish the printer in your Active Directory, what makes it easier for users to find.<br />
<br />
* To preconfigure the printers default settings, go to the „Advanced“ tab and click the „Printing defaults...“ button. A new window will appear. It's layout and possibilities differ and depent on the driver. Here you can set the default values, the user will receive, when connecting the printer.<br />
:[[Image:Printing_defaults.png]]<br />
<br />
* If you have finished configuring your printer, save all changes with „OK“.<br />
<br />
If you had uploaded drivers for multiple architectures to that printer, the settings will be retrieved connecting on the different plattforms - regardless on which they have been set. But as mentioned earlier, this requires, that all drivers for each plattform have the same name (versions can differ).<br />
<br />
Now it's time to connect to the printer and print a test page.<br />
<br />
<br />
<br />
<br />
<br />
= Setting up a GPO for trusting printer drivers =<br />
<br />
To keep the following guide simple, we setup the policy in the „Default Domain Policy“. If you have different requirements, adapt it to your needs.<br />
<br />
* Open the Group Policy Management console.<br />
<br />
* Go to „Forest: your.domain“ / „Domains“ / „your.domain“<br />
<br />
* Right-click „Default Domain Policy“ and choose „Edit“ to open the Group Policy Management Editor.<br />
:[[Image:Edit_group_policy.png]]<br />
<br />
* Navigate to „Computer Configuration“ / „Policies“ / „Administrative Templates“ / „Printers“ and double-click to the „Point and Print Restrictions“ Policy (if you want to setup the policy on a per-user base instead of machine-base, go to the same path, but just in the „User Configuration“ branch).<br />
<br />
* Enable the policy and set „When installing driver for a new connection“ and „When updating drivers for an existing connection“ each to „Do not show warning or elevation prompt“. You can restrict the policy in that window to prevent the warning just for defined hosts, too, if required..<br />
:[[Image:Point_and_print_restrictions.png]]<br />
<br />
* Save the changed policy by clicking „OK“ and closing the windows.<br />
<br />
After the clients have refreshed their policies (per default every 90 minutes, with a random offset of 0 to 30 minutes), the warning won't be shown up any more. The policy refresh can be forced by <br />
<br />
> gpupdate /force /target:computer<br />
<br />
<br />
<br />
<br />
<br />
= Enabling new paper sizes (Forms) =<br />
<br />
Only standard sizes of formulars are included by default. If you require other forms, you have to add them.<br />
<br />
* Logon with an account, that has [[#Granting_print_operator_privileges|granted print operator privileges]] to.<br />
<br />
* Go to \\YourPrintserver and click the „View remote printers“ button<br />
:[[Image:Server_Share_List.png]]<br />
<br />
* You will see a list of all printers you have shared.<br />
:[[Image:View_remote_printers.png]]<br />
<br />
* Right-click somewhere in the empty part of the window and choose „Server Properties...“ from the appearing context menu. The print server forms tab appears.<br />
<br />
* Check „Create a new form“, and fill the values. In the end click „Save Form“, to save your changes.<br />
:[[Image:Create_new_form.png]]<br />
<br />
The new added paper sizes will be selectable from all printer dialogs now.</div>Gazzonyxhttps://wiki.samba.org/index.php?title=Installing_RSAT&diff=7822Installing RSAT2013-07-09T20:48:22Z<p>Gazzonyx: Spelling fix.</p>
<hr />
<div>= Samba AD management from Windows =<br />
<br />
We need install Windows 2003 Adminpak into Windows XP in order to use<br />
GUI tools to manage the domain. Before you begin, make sure that the domain<br />
administrators have administrative rights to control your computer.(To<br />
give any user administrative rights in Windows XP Pro, right click My<br />
Computer, select Manage-> choose Groups-> double click Administrators<br />
and add members from domain into the member list. When you add<br />
members from Active Directory, it will prompt you to enter an<br />
Active Directory username and password).<br />
<br />
== Step 1: Installing Windows Remote Administration Tools onto Windows ==<br />
<br />
=== Windows Vista/7/8 ===<br />
<br />
#Download the Windows Remote Administration Tools from:<br />
#* http://www.microsoft.com/downloads/details.aspx?FamilyId=9FF6E897-23CE-4A36-B7FC-D52065DE9960&displaylang=en (Vista)<br />
#* http://www.microsoft.com/downloads/details.aspx?FamilyID=7D2F6AD7-656B-4313-A005-4E344E43997D&displaylang=en (Windows 7)<br />
#* http://www.microsoft.com/download/details.aspx?id=28972 (Windows 8)<br />
#Follow the "Install RSAT" instructions<br />
*Note: After installing, you have to enable the features in "Turn Windows features on or off" in "Programs" of the Control Panel!)''.<br />
<br />
=== Windows XP Pro ===<br />
<br />
==== Administration Tools Pack & Support Tools ====<br />
# Download adminpak and supporttools from:<br />
#* http://www.microsoft.com/downloads/en/details.aspx?FamilyID=86b71a4f-4122-44af-be79-3f101e533d95<br />
#* http://download.microsoft.com/download/3/e/4/3e438f5e-24ef-4637-abd1-981341d349c7/WindowsServer2003-KB892777-SupportTools-x86-ENU.exe<br />
#:If you installed an older version of the adminpak, you'll notice the dial-in tab is missing from property pages. Just follow the link above to get SP2 which does not have this issue.<br />
# Run through the installation.<br />
# Press start->run, type 'dsa.msc', if a window 'active directory users and computers' prompt up, it mean you had install adminpak it successfully. You can also find this at Start>Programs>Administrative Tools, which should have a lot more items now.<br />
# Go to c:\Program Files\Support Tools to check whether the support tools were installed correctly; if yes, then your XP workstation is ready to manage the Samba 4 Active Directory.<br />
<br />
==== Group Policy Management Console ====<br />
# You may also find the Group Policy Management Console useful. You can download it from<br />
#* http://www.microsoft.com/downloads/details.aspx?FamilyId=0A6D4C24-8CBD-4B35-9272-DD3CBFC81887&displaylang=en<br />
#:This is primarily useful when you have larger installs and are managing many machines. You may need to download the .NET Framework first.<br />
<br />
== Step 2: Viewing Samba Active Directory Content ==<br />
<br />
# When logged on as a Domain Administrator, start the Active Directory Users and Computers Snap-In, either by clicking Start -> Programs\Administrative Tools\Active Directory Users and Computers, or by clicking Start -> Run 'dsa.msc'<br />
# Expand the samdom.example.com tree to see existing objects in the domain.<br />
#:[[Image:Samba4dsa.msc.jpg]]<br />
<br />
*Note: You can also manage users using the normal Windows AD user management tools.<br />
<br />
= Setting Up Roaming Profiles =<br />
<br />
See the [[Samba_%26_Windows_Profiles|Samba & Windows Profiles HowTo]].<br />
<br />
= Adding Organization Units (OU) Into a Samba Domain = <br />
<br />
The Organizational Unit (OU) is a powerful feature in Active<br />
Directory. This is a type of container which allows you to drag & drop<br />
users and/or computers into it.<br />
<br />
We can link several types of group policies to an OU, and the settings<br />
will push out to all users/computers that sit under the OU. Within a single domain,<br />
you can have as many OUs and sub-OUs as you'd like. The result is that<br />
it can greatly reduce administrative overhead since you are able to<br />
manage everything via an OU. The implementation of Group Policy will<br />
be discussed in the next chapter.<br />
<br />
Before we create an OU, we must know what one looks like. By default<br />
we can see a sample OU called 'Domain Controllers', which uses a different<br />
icon in the Windows management tools than the 'users' and 'computers'<br />
containers. We can deploy Group Policy to the users or the computers container.<br />
<br />
# To create an OU as the Domain Administrator, click Start -> Run -> dsa.msc<br />
# Right click your domain.<br />
# Select New -> Organizational Unit<br />
# Type 'OU Demo'<br />
# You will see a new OU appear, with the name 'OU Demo'.<br />
# You can drag the user 'demo' into the new OU (Don't move other users! Unless you want to get stuck!).<br />
# Right click 'OU Demo', A sub-OU can be created with New -> Organizational Unit.<br />
<br />
Normally OUs are created according to the department setup of your<br />
organization. Be careful not to confuse Groups and OUs. Groups are<br />
used to control permissions, OUs are used for deploying settings to<br />
all users/computers within the OU.<br />
<br />
= Implementing Group Policies (GPO) in A Samba Domain =<br />
<br />
Samba Active Directory has support for Goup Plicies, and can create<br />
the Goup Plicy on the fly. The basic idea of Goup Plicies is:-<br />
<br />
# Group Policies have two kinds of settings: computers and users.<br />
# Computer settings apply to computers, while user settings apply to users.<br />
# We link the group policy to a particular OU, and the group policy will effect all computers/users under the OU.<br />
# To add a group policy, right click 'OU Demo' OU->properties.<br />
# Choose group policy.<br />
# Press new, and name it as 'GP Demo'.<br />
# Press edit to modify the policy.<br />
# Here will demonstrate how to block users from access to the control panel. Open the tree 'User Configuration'->'Administrative Templates'->'Control Panel'.<br />
# Double click on 'Prohibit access to the Control Panel'.<br />
# Press enabled and then press OK. Now the all users under 'OU Demo' won't able to access to the control panel.<br />
# Make sure that the user 'demo' is inside the 'OU Demo' (You can drag and drop it). <br />
# Logout and login as user 'demo'.<br />
# You'll find user demo is not able to access control panel.<br />
<br />
== Notes ==<br />
:User configuration will take effect once you logout and login.<br />
:Computer configuration will take effect when you restart the computer.<br />
:GPO Password Policies are not read by Samba when assigning passwords, to change the policy that Samba uses you must use '''samba-tool domain passwordsettings'''<br />
<br />
To learn more about managing and implementing organizational units, group policies, and Active Directory, try a web search for Google in Windows 2003 Active Directory implementation.</div>Gazzonyxhttps://wiki.samba.org/index.php?title=SWAT2&diff=7804SWAT22013-07-02T15:50:12Z<p>Gazzonyx: /* Dependencies */</p>
<hr />
<div>SWAT2 is a Python frontend to Samba 4, originally written by Ricardo Velhote.<br />
<br />
Repository:<br />
<br />
* git://git.samba.org/jelmer/swat.git<br />
<br />
= Dependencies =<br />
<br />
* [[Samba4]] (in particular, the Samba 4 Python bindings)<br />
* pylons<br />
* authkit module ("easy_install authkit") on RHEL based distros. You'll need python-setuptools installed before you can do this.<br />
<br />
= Installation =<br />
<br />
There are three ways in which you can run SWAT. Pick one:<br />
<br />
== Standalone ==<br />
<br />
Use paster:<br />
<br />
$ paster serve development.ini <br />
<br />
== From Samba ==<br />
<br />
First, install SWAT or make sure it is available in the Samba server's Python path:<br />
<br />
$ ./setup.py install<br />
<br />
Make sure that Samba is running the web service by adding the following line to the *[global]* section of the smb.conf file:<br />
<br />
$ server services = +web<br />
<br />
SWAT will now be available at http://localhost:901/.<br />
<br />
== From Apache ==<br />
<br />
TODO</div>Gazzonyxhttps://wiki.samba.org/index.php?title=Talk:Main_Page&diff=7799Talk:Main Page2013-06-28T20:15:02Z<p>Gazzonyx: RFC, add the AD DC HowTo directly under the HowTo heading.</p>
<hr />
<div>Can we add the link for the AD DC HowTo ([[Samba AD DC HOWTO]]) directly under the HOWTO section? This is the one all the users will be looking for.</div>Gazzonyxhttps://wiki.samba.org/index.php?title=User:Gazzonyx&diff=7798User:Gazzonyx2013-06-27T15:27:46Z<p>Gazzonyx: A very simple user page.</p>
<hr />
<div>Gazzonyx, AKA Scott Lovenberg. Wiki, Samba and cifs-utils contributor. <br />
<BR>Lurker in #Samba and #Samba-Technical under the handle "<B>SLovenberg</B>", "<B>SLovenberg-Home</B>", "<B>scottl</B>" or "<B>Gazzonyx</B>" depending on where I'm at.</div>Gazzonyxhttps://wiki.samba.org/index.php?title=Time_Synchronisation&diff=7796Time Synchronisation2013-06-25T16:53:14Z<p>Gazzonyx: Grammar fix.</p>
<hr />
<div>You require a recent ntpd version (=>4.2.6) that supports signed ntp. E. g. the version shipped with RHEL6 and Ubuntu < 11.04 are too old. The Ntpd of Debian Squeeze supports signed ntp.<br />
<br />
1a. Download ntpd from ntp.org (verify md5 sum) and compile it (add additionals ./configure parameters, if needed):<br />
<br />
$ tar -zxvf ntp-4.x.x.tar.gz<br />
$ cd ntp-4.x.x<br />
$ ./configure --enable-ntp-signd<br />
$ make<br />
$ make install<br />
<br />
1b. Set the permission of the ntp_signd directory (default /usr/local/samba/var/lib/ntp_signd/) to 0750 and its owner to root:ntp to ensure that it is readable from ntpd.<br />
<br />
2a. If you already have a supported ntpd version and ntp.conf, you have to add/adjust only the following lines for minimal:<br />
ntpsigndsocket /usr/local/samba/var/lib/ntp_signd/<br />
restrict default mssntp<br />
<br />
2b. If a minimal/simple ntp.conf is fine for you, then fill the file with the following:<br />
server 127.127.1.0<br />
fudge 127.127.1.0 stratum 12<br />
ntpsigndsocket /usr/local/samba/var/lib/ntp_signd/<br />
restrict default mssntp<br />
<br />
2c. A more complex ntp.conf is the following:<br />
server 127.127.1.0<br />
fudge 127.127.1.0 stratum 10<br />
server 0.pool.ntp.org iburst prefer<br />
server 1.pool.ntp.org iburst prefer<br />
driftfile /var/lib/ntp/ntp.drift<br />
logfile /var/log/ntp<br />
ntpsigndsocket /usr/local/samba/var/lib/ntp_signd/<br />
restrict default kod nomodify notrap nopeer mssntp<br />
restrict 127.0.0.1<br />
restrict 0.pool.ntp.org mask 255.255.255.255 nomodify notrap nopeer noquery<br />
restrict 1.pool.ntp.org mask 255.255.255.255 nomodify notrap nopeer noquery<br />
For explanation: This config allows clients to receive time from this NTP host, localhost<br />
doesn't have any restrictions, and the servers we receive the time from ,are not allowed<br />
to do anything else than providing the time to us. For more information about ntpd<br />
access controll, see<br />
http://support.ntp.org/bin/view/Support/AccessRestrictions<br />
<br />
3. On members of the domain you don't have to configure anything. Per default they will receive<br />
the time from the DC that has the FSMO role PDC.<br />
<br />
== Supported client versions == <br />
<br />
Please note that the ntp.org server we interface with does not support authenticated time to Windows 2000 clients. This is due to these clients not behaving as the ntp.org server expects (they send garbage - presumably un-initialised memory - when the server expects zeros). As these clients are now very old and unsupported, you may need to find another way to keep these clocks in sync. <br />
<br />
== Permissions, SELinux Labeling and Policy ==<br />
=== NTP ===<br />
Set Permissions:<br />
$ chgrp ntp /usr/local/samba/var/lib/ntp_signd<br />
<br />
Multiple attempts to set the context for ntp failed so the below policy was needed for windows clients time sync after joining the DOMAIN.<br />
$ chcon -u system_u -t ntpd_t /usr/local/samba/var/run/ntp_signd<br />
$ chcon -u system_u -t ntpd_t /usr/local/samba/var/run/<br />
$ chcon -t ntpd_t /usr/local/samba/var/run/ntp_signd/socket<br />
<br />
<tt>samba4.te</tt> policy:<br />
module samba4 1.0;<br />
<br />
<br />
require {<br />
type ntpd_t;<br />
type usr_t;<br />
type initrc_t;<br />
class sock_file write;<br />
class unix_stream_socket connectto;<br />
}<br />
<br />
#============= ntpd_t ==============<br />
allow ntpd_t usr_t:sock_file write;<br />
<br />
#============= ntpd_t ==============<br />
allow ntpd_t initrc_t:unix_stream_socket connectto;<br />
<br />
Check and load policy:<br />
$ checkmodule -M -m -o samba4.mod samba4.te <br />
$ semodule_package -o samba4.pp -m samba4.mod<br />
$ semodule -i samba4.pp</div>Gazzonyxhttps://wiki.samba.org/index.php?title=SWAT2&diff=7782SWAT22013-06-19T20:58:00Z<p>Gazzonyx: Added RHEL dependency.</p>
<hr />
<div>SWAT2 is a Python frontend to Samba 4, originally written by Ricardo Velhote.<br />
<br />
Repository:<br />
<br />
* git://git.samba.org/jelmer/swat.git<br />
<br />
= Dependencies =<br />
<br />
* [[Samba4]] (in particular, the Samba 4 Python bindings)<br />
* pylons<br />
* authkit module ("easy_install authkit") on RHEL based distros<br />
<br />
= Installation =<br />
<br />
There are three ways in which you can run SWAT. Pick one:<br />
<br />
== Standalone ==<br />
<br />
Use paster:<br />
<br />
$ paster serve development.ini <br />
<br />
== From Samba ==<br />
<br />
First, install SWAT or make sure it is available in the Samba server's Python path:<br />
<br />
$ ./setup.py install<br />
<br />
Make sure that Samba is running the web service by adding the following line to the *[global]* section of the smb.conf file:<br />
<br />
$ server services = +web<br />
<br />
SWAT will now be available at http://localhost:901/.<br />
<br />
== From Apache ==<br />
<br />
TODO</div>Gazzonyxhttps://wiki.samba.org/index.php?title=Samba&diff=7698Samba2013-05-28T22:29:02Z<p>Gazzonyx: Spelling fix.</p>
<hr />
<div>==Current status== <br />
'''Current Version: 4.0.6''' <br />
'''[http://www.samba.org/samba/ftp/stable/samba-4.0.6.tar.gz Download]'''<br />
'''[http://www.samba.org/samba/history/samba-4.0.6.html Release Notes]'''<br />
* [[Release_Planning_for_Samba_4.0|Release planning for Samba 4.0.x]]<br />
* [https://bugzilla.samba.org/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__open__&product=Samba+4.0 Open Bug Reports on Samba 4.0]<br />
<br />
<br />
'''The official press release of Samba 4 can be found on the [https://www.samba.org/samba/news/releases/4.0.0.html Samba website].'''<br />
<br />
Full Active Directory support has been incorporated into the Samba suite with Samba 4.x.x. With Samba 4, you can join a Windows (all recent releases should be supported) machine to a Samba Active Directory domain, and it will behave much as it does in AD, including Kerberos domain logins where applicable. Samba 4 is now at a point where it can begin replacing existing production deployments, and users are encouraged to try out Samba 4 in a test environment before implementing it in a work environment!<br />
<br />
Except for a small number of deprecated features, Samba continues to provide all the features and functionality found in Samba 3.6, and as such is an excellent file server and domain member as well.<br />
<br />
<br />
= General documentation on Samba =<br />
<br />
* [[BuildsystemUseAndWhy|Building Samba 4.0]] (Which build system to use and why)<br />
<br />
* [[CTDB_Project|CTDB Project]]<br />
<br />
* [[Samba4/FAQ|Samba 4 FAQ]]<br />
<br />
<br />
= Samba as a Active Directory Domain Controller =<br />
<br />
'''Here you can find everything to setup a Samba Active Directory Domain Controller and all that is related to this topic.'''<br />
<br />
* [[Samba_AD_DC_HOWTO|Samba Active Directory HOWTO]]: Contains everything for setting up a basic Samba Active Directory Controller<br />
<br />
* [[Samba4/samba-tool/domain/classicupgrade/HOWTO|Migrating a Samba 3 PDC to a Samba Active Directory Domain Controller]]: If you are running a Samba 3 NT4-style environment and want to move to Active Directory, this is the documentation that contains all the necessary information<br />
<br />
* [[Backup_and_Recovery|Backup and Recovery]]<br />
<br />
* [[Samba_AD_management_from_windows|Samba AD management from windows]]<br />
<br />
* [[Samba_AD_DC_HOWTO/AD_Delegation|Delegating administrative jobs to non-admin-accounts]]<br />
<br />
* [[Samba4/HOWTO/Join_a_domain_as_a_DC|Joining Samba as additional DC to the AD]]<br />
<br />
* [[Samba_AD_DC_HOWTO#Joining_a_Windows_Domain_Controller_as_an_Additional_DC_in_a_Domain|Joining a Windows Domain Controller as an Additional DC in a Domain]]<br />
<br />
* [[Configuring_a_windows_client_for_AD|Configuring a windows client for AD]]<br />
<br />
* [[DNS|Internal DNS and Bind DLZ module]]<br />
<br />
* [[Samba4/beyond|Beyond Samba]]: Connecting other Services/Daemons to your Samba Active Directory (e. g. authentication, etc.)<br />
<br />
* [[Samba4/Schema_extenstions|Samba Active Directory Schema Extensions]]<br />
<br />
* [[Samba4/Smart_Card_Login|Samba Smart Card Login HowTo]]<br />
<br />
* [[Samba4/HOWTO/Virtual_Private_Network|Creating a Single Sign On VPN with Samba AD]]<br />
<br />
* [[Samba4/videos|Samba 4 Demonstration Videos]]<br />
<br />
= Samba as a Domain Member Server =<br />
<br />
* [[Samba4/Domain_Member|Samba Member Server setup in an Active Directory environment]]: This HOWTO is based on Samba 4 (Recommended)<br />
<br />
* [[Samba_%26_Active_Directory|Samba and Active Directory]]: Samba 3 and AD<br />
<br />
<br />
= Miscellaneous Configuration topics =<br />
<br />
'''Here you'll find all configuration/setup topics that can't be associated directly to an ADC or member server'''<br />
<br />
* [[Samba_AD_DC_HOWTO#Setup_a_basic_File_Share_.28Optional.29|Setup a basic File Share]]<br />
<br />
* [[Setup_a_printer_share|Setup a printer share]]<br />
<br />
* [[Setup_FreeDOS_to_access_a_Samba_share|Setup FreeDOS to access a Samba share with MS Client 3.0]]<br />
<br />
<br />
= Developing Samba =<br />
<br />
* See the [[Developer_documentation|developer documentation]] page.<br />
<br />
<br />
= Historical Documentation on the Development of Samba4 =<br />
<br />
* [[Samba4/DRS_TODO_List|Samba4 DRS ToDo List]]<br />
<br />
* [[Samba4/Status|Samba 4 Status]]<br />
<br />
* [[Franky|Franky]]: A Hybrid Samba Active Directory Controller (outdated!)<br />
<br />
* [[Samba4/s3fs|An Explanation of the s3fs Architecture for Using smbd in the AD Server]]<br />
<br />
* [[Development Resources]]<br />
<br />
* [[Samba4/Tests|Test Status]]<br />
<br />
* [[SambaGtk|Gtk+ Frontends]]<br />
<br />
* [[Samba4/ActiveDirectory|Active Directory Plans]]<br />
<br />
* [[Samba4/Domain_Member|Domain Member plans]]<br />
<br />
* [[Samba4/LDAP_Backend|LDAP Directory Server Backend History Notes]]<br />
<br />
* [[Samba4 AD Plugfest 2010 TODO list|Samba 4 AD Plugfest 2010 TODO List]]<br />
<br />
* [ftp://ftp.samba.org/pub/samba/samba4/ Development Releases of Samba4 (technology previews, alphas, betas, release candidates)]</div>Gazzonyxhttps://wiki.samba.org/index.php?title=Winbindd&diff=7697Winbindd2013-05-28T22:16:18Z<p>Gazzonyx: Grammar fix</p>
<hr />
<div>== About Winbind and Samba4 ==<br />
<br />
Samba4 currently embeds its own Winbind implementation. Winbind is responsible for affecting an unix uid to user, gid to groups.<br />
<br />
It is also used to list groups of a given user, to translate SID to uid/gid and many other things.<br />
<br />
As soon as you use file server capabilities of Samba4 (for instance for serving GPO or login scripts), calls to Winbind will be made to get the user's uid (and allocate if none exists).<br />
This can be noticed by the fact that when a file is created from Windows in one of the samba4 server share you will see big numerical uid and gid. <br />
<br />
For example: <br />
<pre><br />
ls /home/mat/workspace/samba/homematwsnet/sysvol/home.matws.net/Policies/\{085C0631-6142-4637-9FED-2EC5B4FB6952\}/ -l<br />
total 0<br />
drwxr-sr-x 4 3000008 users 4096 2010-03-05 23:31 .<br />
drwxrwsrwx 10 3000008 3000008 4096 2010-03-05 23:31 ..<br />
-rw-r--r-- 1 3000017 users 68 2010-03-06 01:43 GPT.INI<br />
</pre><br />
<br />
The user interaction can be eased by the usage <tt>libnss_winbind</tt>. That's the point of the next paragraph.<br />
<br />
== Using libnss_winbind ==<br />
=== Installing and configuring ===<br />
<br />
The current installation process put the library libnss_winbind.so in <tt>&lt;PATH_TO_SAMBA&gt;/lib</tt> (ie. <tt>/usr/local/samba/lib</tt>). Use a current checkout as described in [[Samba4/HOWTO]].<br />
<br />
# ln -s /usr/local/samba/lib/libnss_winbind.so.2 /lib/libnss_winbind.so<br />
# ln -s /lib/libnss_winbind.so /lib/libnss_winbind.so.2<br />
<br />
You need to instruct the system to use the nss winbind library when searching for users or groups. For this add the keywork <tt>winbind</tt> to the stanza passwd and group in <tt>/etc/nsswitch.conf</tt>.<br />
<br />
It should look like:<br />
<pre><br />
passwd: files winbind<br />
group: files winbind<br />
shadow: files<br />
...<br />
</pre><br />
<br />
Use the following command to confirm that the library is loaded<br />
# ldconfig -v | grep winbind<br />
<br />
<u>Note:</u> On some systems it is the keyword compat that is used instead of files.<br />
<br />
=== Testing ===<br />
Check the following steps:<br />
* winbind is "pingable"<br />
$ /usr/local/samba/bin/wbinfo -p <br />
Ping to winbindd succeeded<br />
<br />
* winbind is able to provide user list, you should see something like this<br />
$ /usr/local/samba/bin/wbinfo -u<br />
...<br />
Administrator<br />
...<br />
* getent passwd returns a password like file with entries for domain users<br />
$ getent passwd<br />
...<br />
Administrator:x:0:100::/home/MATWS/Administrator:/bin/false<br />
...<br />
* The <tt>id</tt> command returns information about a user<br />
$ id Administrator<br />
uid=0(root) gid=100(users) groupes=0(root),100(users),3000004(Group Policy Creator Owners),3000008(Domain Admins)<br />
<br />
If all these steps are ok then the installation of libnss_winbind is successful and you can enjoy manipulating domain users uid and gid in a much more friendly way.<br />
<br />
You can now configure pam_winbind, if you want to be able to login on the server running samba 4, for this check next paragraph.<br />
<br />
== Using pam_winbind ==<br />
===Installing and configuring===<br />
Ensure that you built Samba 4 with libpam0g-dev installed on your system. If not, install the PAM development libraries and re-compile Samba 4 from the ./configure.developer stage. Install pam_winbind.so in the usual place:<br />
<br />
# ln -s /usr/local/samba/lib/security/pam_winbind.so /lib/security<br />
<br />
Make sure you have a similar entry in <tt>smb.conf</tt>:<br />
<pre><br />
[global]<br />
...<br />
template shell = /bin/bash<br />
...<br />
</pre><br />
<br />
Restart your samba 4 server so that it takes the new parameter.<br />
<br />
Then you need to instruct pam how to use this library.<br />
<br />
Note: The following actions can cause you not to be able to connect to your system if you do something wrong. You are invitated to make a backup of your previous configuration and to have a spare connection to the server as root to be able to restore them in case of problem.<br />
<br />
Note2: This guide is based on the fact that the pam configuration is in /etc/pam.d/common* files which seems to be common nowdays. If it's not the case for you, you have to decline it accordingly to your configuration.<br />
<br />
Files to modify:<br />
<br />
*;/etc/pam.d/common-auth<br />
::Add this line before pam_unix.so:<br />
::<pre>auth sufficient pam_winbind.so</pre><br />
::Also add the option <tt>use_first_pass</tt> to the <tt>pam_unix.so</tt> line<br />
*;/etc/pam.d/common-account<br />
::Add this line before pam_unix.so:<br />
::<pre>account sufficient pam_winbind.so</pre><br />
*;/etc/pam.d/common-session<br />
::Add these lines before any other session line:<br />
::<pre>session required pam_mkhomedir.so</pre><br />
::<pre>session required pam_winbind.so</pre><br />
<br />
=== Testing ===<br />
<br />
* Check that getent passwd return a correct entry:<br />
<pre><br />
getent passwd<br />
...<br />
Administrator:x:0:100::/home/MATWS/Administrator:/bin/bash<br />
...<br />
</pre><br />
It's important that the shell must be a real shell (and not /bin/false).<br />
<br />
* Check that you can connect as a non domain user (ie. root or any other account that was used before).<br />
<br />
* Connect to the server using a domain account:<br />
<pre>ssh administrator@localhost <br />
administrator@localhost's password: <br />
Linux ares 2.6.31-20-generic-pae #57-Ubuntu SMP Mon Feb 8 10:23:59 UTC 2010 i686<br />
<br />
To access official Ubuntu documentation, please visit:<br />
http://help.ubuntu.com/<br />
<br />
Last login: Tue Mar 9 00:19:30 2010<br />
root@ares:~# who<br />
mat tty7 2010-03-09 17:05 (:0)<br />
Administrator pts/4 2010-03-24 16:38 (localhost)<br />
</pre><br />
<br />
If the latest point didn't work the option debug can be added to the modified entries in the modified pam files to help to find out what's wrong.</div>Gazzonyxhttps://wiki.samba.org/index.php?title=Winbindd&diff=7696Winbindd2013-05-28T22:03:13Z<p>Gazzonyx: Grammar fix</p>
<hr />
<div>== About Winbind and Samba4 ==<br />
<br />
Samba4 currently embed its own Winbind implementation. Winbind is responsible for affecting an unix uid to user, gid to groups.<br />
<br />
It is also used to list groups of a given user, to translate SID to uid/gid and many other things.<br />
<br />
As soon as you use file server capabilities of Samba4 (for instance for serving GPO or login scripts), calls to Winbind will be made to get the user's uid (and allocate if none exists).<br />
This can be noticed by the fact that when a file is created from Windows in one of the samba4 server share you will see big numerical uid and gid. <br />
<br />
For example: <br />
<pre><br />
ls /home/mat/workspace/samba/homematwsnet/sysvol/home.matws.net/Policies/\{085C0631-6142-4637-9FED-2EC5B4FB6952\}/ -l<br />
total 0<br />
drwxr-sr-x 4 3000008 users 4096 2010-03-05 23:31 .<br />
drwxrwsrwx 10 3000008 3000008 4096 2010-03-05 23:31 ..<br />
-rw-r--r-- 1 3000017 users 68 2010-03-06 01:43 GPT.INI<br />
</pre><br />
<br />
The user interaction can be eased by the usage <tt>libnss_winbind</tt>. That's the point of the next paragraph.<br />
<br />
== Using libnss_winbind ==<br />
=== Installing and configuring ===<br />
<br />
The current installation process put the library libnss_winbind.so in <tt>&lt;PATH_TO_SAMBA&gt;/lib</tt> (ie. <tt>/usr/local/samba/lib</tt>). Use a current checkout as described in [[Samba4/HOWTO]].<br />
<br />
# ln -s /usr/local/samba/lib/libnss_winbind.so.2 /lib/libnss_winbind.so<br />
# ln -s /lib/libnss_winbind.so /lib/libnss_winbind.so.2<br />
<br />
You need to instruct the system to use the nss winbind library when searching for users or groups. For this add the keywork <tt>winbind</tt> to the stanza passwd and group in <tt>/etc/nsswitch.conf</tt>.<br />
<br />
It should look like:<br />
<pre><br />
passwd: files winbind<br />
group: files winbind<br />
shadow: files<br />
...<br />
</pre><br />
<br />
Use the following command to confirm that the library is loaded<br />
# ldconfig -v | grep winbind<br />
<br />
<u>Note:</u> On some systems it is the keyword compat that is used instead of files.<br />
<br />
=== Testing ===<br />
Check the following steps:<br />
* winbind is "pingable"<br />
$ /usr/local/samba/bin/wbinfo -p <br />
Ping to winbindd succeeded<br />
<br />
* winbind is able to provide user list, you should see something like this<br />
$ /usr/local/samba/bin/wbinfo -u<br />
...<br />
Administrator<br />
...<br />
* getent passwd returns a password like file with entries for domain users<br />
$ getent passwd<br />
...<br />
Administrator:x:0:100::/home/MATWS/Administrator:/bin/false<br />
...<br />
* The <tt>id</tt> command returns information about a user<br />
$ id Administrator<br />
uid=0(root) gid=100(users) groupes=0(root),100(users),3000004(Group Policy Creator Owners),3000008(Domain Admins)<br />
<br />
If all these steps are ok then the installation of libnss_winbind is successful and you can enjoy manipulating domain users uid and gid in a much more friendly way.<br />
<br />
You can now configure pam_winbind, if you want to be able to login on the server running samba 4, for this check next paragraph.<br />
<br />
== Using pam_winbind ==<br />
===Installing and configuring===<br />
Ensure that you built Samba 4 with libpam0g-dev installed on your system. If not, install the PAM development libraries and re-compile Samba 4 from the ./configure.developer stage. Install pam_winbind.so in the usual place:<br />
<br />
# ln -s /usr/local/samba/lib/security/pam_winbind.so /lib/security<br />
<br />
Make sure you have a similar entry in <tt>smb.conf</tt>:<br />
<pre><br />
[global]<br />
...<br />
template shell = /bin/bash<br />
...<br />
</pre><br />
<br />
Restart your samba 4 server so that it takes the new parameter.<br />
<br />
Then you need to instruct pam how to use this library.<br />
<br />
Note: The following actions can cause you not to be able to connect to your system if you do something wrong. You are invitated to make a backup of your previous configuration and to have a spare connection to the server as root to be able to restore them in case of problem.<br />
<br />
Note2: This guide is based on the fact that the pam configuration is in /etc/pam.d/common* files which seems to be common nowdays. If it's not the case for you, you have to decline it accordingly to your configuration.<br />
<br />
Files to modify:<br />
<br />
*;/etc/pam.d/common-auth<br />
::Add this line before pam_unix.so:<br />
::<pre>auth sufficient pam_winbind.so</pre><br />
::Also add the option <tt>use_first_pass</tt> to the <tt>pam_unix.so</tt> line<br />
*;/etc/pam.d/common-account<br />
::Add this line before pam_unix.so:<br />
::<pre>account sufficient pam_winbind.so</pre><br />
*;/etc/pam.d/common-session<br />
::Add these lines before any other session line:<br />
::<pre>session required pam_mkhomedir.so</pre><br />
::<pre>session required pam_winbind.so</pre><br />
<br />
=== Testing ===<br />
<br />
* Check that getent passwd return a correct entry:<br />
<pre><br />
getent passwd<br />
...<br />
Administrator:x:0:100::/home/MATWS/Administrator:/bin/bash<br />
...<br />
</pre><br />
It's important that the shell must be a real shell (and not /bin/false).<br />
<br />
* Check that you can connect as a non domain user (ie. root or any other account that was used before).<br />
<br />
* Connect to the server using a domain account:<br />
<pre>ssh administrator@localhost <br />
administrator@localhost's password: <br />
Linux ares 2.6.31-20-generic-pae #57-Ubuntu SMP Mon Feb 8 10:23:59 UTC 2010 i686<br />
<br />
To access official Ubuntu documentation, please visit:<br />
http://help.ubuntu.com/<br />
<br />
Last login: Tue Mar 9 00:19:30 2010<br />
root@ares:~# who<br />
mat tty7 2010-03-09 17:05 (:0)<br />
Administrator pts/4 2010-03-24 16:38 (localhost)<br />
</pre><br />
<br />
If the latest point didn't work the option debug can be added to the modified entries in the modified pam files to help to find out what's wrong.</div>Gazzonyxhttps://wiki.samba.org/index.php?title=Operating_System_Requirements&diff=7695Operating System Requirements2013-05-23T17:05:57Z<p>Gazzonyx: Added libaio-devel to RHEL dependencies.</p>
<hr />
<div>== Development libraries and Programs ==<br />
=== Required : ===<br />
These packages are required for a successful build of samba 4<br />
* Python -- A good portion of Samba is written using python, including the build system itself (waf).<br />
<br />
=== Recommended optional development libraries and Programs: ===<br />
In most distributions these libraries will be labeled with a lib*-dev or lib*-devel, for example for the Debian or Ubuntu acl would be libacl1-dev, but in Fedora, RHEL, CentOS, and openSUSE its named libacl-devel. <br />
* acl -- Required for a successful AD DC deployment. If this library is not included, samba will build successfully, however you will not be able to change ACL's from the windows frontend. You will receive and error when you provision and if you manually create the smb.conf with +s3fs, you will get '''Access is denied.''' from windows on any attempt to change ACL's. <br />
* xattr <br />
* blkid <br />
* gnutls <br />
* readline <br />
* openldap -- Required to build the Samba3 components with LDAP support. Lacking this library the build will complete but attempts to provision (via upgrade) an Active Directory domain from an existing Samba3 LDAP backend will fail. Also see [[Samba4/samba-tool/domain/classicupgrade/HOWTO|samba-tool domain classicupgrade]]<br />
* cups -- for printer sharing support<br />
* bsd or setproctitle - for process title updating support<br />
<br />
* xsltproc and docbook XSL stylesheets -- Required for building man pages and other documentation<br />
<br />
== Distribution Setup == <br />
The examples following will cover all of these libraries. It will also cover bind, kerberos, and file system tools. If you plan to use the internal DNS server, you do not need bind, but you do still need the package that contains the nsupdate binary.<br />
<br />
=== Debian or Ubuntu ===<br />
# apt-get install build-essential libacl1-dev libattr1-dev \<br />
libblkid-dev libgnutls-dev libreadline-dev python-dev \<br />
python-dnspython gdb pkg-config libpopt-dev libldap2-dev \<br />
dnsutils libbsd-dev attr krb5-user docbook-xsl libcups2-dev<br />
<br />
Note: docbook-xsl, xsltproc, and inkscape may be required for building the man pages.<br />
<br />
Note: if you need '''pam winbind''' support you will need the <tt>libpam0g-dev package</tt> installed.<br />
<br />
=== Fedora ===<br />
<br />
# yum install libacl-devel libblkid-devel gnutls-devel \<br />
readline-devel python-devel gdb pkgconfig libattr-devel \<br />
krb5-workstation<br />
<br />
=== Red Hat Enterprise Linux or CentOS ===<br />
<br />
# yum install gcc libacl-devel libblkid-devel gnutls-devel \<br />
readline-devel python-devel gdb pkgconfig krb5-workstation \ <br />
zlib-devel setroubleshoot-server libaio-devel \<br />
setroubleshoot-plugins policycoreutils-python \<br />
libsemanage-python setools-libs-python setools-libs \<br />
popt-devel libpcap-devel sqlite-devel libidn-devel \<br />
libxml2-devel libacl-devel libsepol-devel libattr-devel \<br />
keyutils-libs-devel cyrus-sasl-devel cups-devel bind-utils<br />
<br />
Note: docbook-style-xsl.noarch and libxslt.x86_64 may be required for the man pages to get installed correctly.<br />
<br />
=== openSUSE ===<br />
<br />
# zypper install libacl-devel python-selinux autoconf make \<br />
python-devel gdb sqlite3-devel libgnutls-devel binutils \<br />
policycoreutils-python setools-libs selinux-policy \<br />
setools-libs popt-devel libpcap-devel keyutils-devel \<br />
libidn-devel libxml2-devel libacl-devel libsepol-devel \<br />
libattr-devel zlib-devel cyrus-sasl-devel gcc \<br />
krb5-client openldap2-devel libopenssl-devel\<br />
bind-utils bind-lib<br />
<br />
=== Gentoo ===<br />
Please note that the following sections assume at least an intermediate understanding of the Gentoo packaging system.<br />
<br />
==== Python ====<br />
Gentoo uses python-3 as the default python interpreter, but at this time Samba requires python-2 (2.4.2 or greater) The following set of commands will install and set up python-2 as the default python interpreter.<br />
<br />
# emerge --ask --noreplace '<dev-lang/python-3'<br />
# eselect python set python2.7<br />
# python-updater<br />
<br />
==== Kerberos ====<br />
On Gentoo, you have two choices for a kerberos implementation, '''app-crypt/mit-krb5''' and '''app-crypt/heimdal'''. Unfortunately the two implementations can not be installed at the same time. Currently, the Samba developers recommend using '''app-crypt/heimdal'''. So you must first uninstall '''app-crypt/mit-krb5''' (if installed,) then install '''app-crypt/heimdal''' and rebuild any packages that were using the old kerberos implementation.<br />
<br />
# emerge --unmerge --ask app-crypt/mit-krb5<br />
# emerge --ask app-crypt/heimdal<br />
# revdep-rebuild -- -ask<br />
<br />
==== Bind ====<br />
To enable automatic zone management, '''net-dns/bind''' and '''net-dns/bind-tools''' should be emerged with the USE flags for '''berkdb''', '''dlz''' and '''gssapi''' set. To enable them permanently, add the following to '''/etc/package.use''':<br />
<br />
net-dns/bind berkdb dlz gssapi<br />
net-dns/bind-tools gssapi<br />
<br />
Then, emerge '''net-dns/bind''':<br />
<br />
# emerge --ask net-dns/bind net-dns/bind-tools<br />
<br />
Note that if you have problems with samba's gssapi updates to bind, try using the alternate kerberos implementation of app-crypt/mit-krb5.<br />
<br />
==== Samba-supplied Libraries (tdb/ldb/tevent) ====<br />
There are a few Samba libraries that need to be installed, note that these packages might be keyworded as unstable, so you might need to add the following to your '''/etc/package.keywords''':<br />
<br />
~sys-libs/tevent-0.9.17<br />
~sys-libs/tdb-1.2.10<br />
~sys-libs/ldb-1.1.12<br />
~sys-libs/talloc-2.0.7<br />
<br />
Additionally, Samba requires '''sys-libs/tdb''' and '''sys-libs/talloc''' to be emerged with the USE flag '''python''' set. To enable this permanently, add the following to '''/etc/package.use''':<br />
<br />
sys-libs/tdb python<br />
sys-libs/talloc python<br />
<br />
Note: In new(er) installations of gentoo, the above files will be located in '''/etc/portage/''', i.e. '''/etc/portage/package.keywords''' and '''/etc/portage/package.use'''. They may be symlinked to '''/etc''' for backward compatibility.<br />
<br />
Now, emerge the packages:<br />
<br />
# emerge --ask '=sys-libs/talloc-2.0.7' '=sys-libs/tdb-1.2.10' '=sys-libs/tevent-0.9.17' '=sys-libs/ldb-1.1.12'<br />
<br />
Note that ebuilds for the required versions of the above packages might not be availiable in the portage tree. In this case, check [https://bugs.gentoo.org/ Gentoo's Bugzilla] for updated ebuilds.<br />
<br />
==== Other Misc. Build/Run Dependencies ====<br />
To ensure a successful Samba-4 installation, there are a few other packages that should be installed, as shown below:<br />
<br />
# emerge --ask net-libs/gnutls sys-apps/acl dev-libs/cyrus-sasl dev-python/subunit dev-python/dnspython net-dns/libidn <br />
<br />
FIXME: Are dev-python/dnspython net-dns/libidn still required?<br />
<br />
== File System Support ==<br />
<br />
<br />
To use the advanced features of Samba4 you need a filesystem that<br />
supports both the "user" and "system" xattr namespaces.<br />
<br />
You need this support on file systems that you will share with samba. For many users that will be their /home volume. However the 'samba-tool' provision command also tests support by creating a temporary file in the 'sysvol'. This might be /usr/local/samba for a local install, or might be somewhere else. That filesystem also needs to have ACL and XATTR support.<br />
<br />
=== ext3/ext4 File System ===<br />
<br />
If you are using either ext3 or ext4 for your file system you will need to<br />
include the options "user_xattr","acl" and "barrier=1" in your /etc/fstab. For example:<br />
<br />
/dev/hda3 /home ext3 user_xattr,acl,barrier=1 1 1<br />
<br />
Simply change ext3 to ext4 if you are using it. Normally you will want to just modify the existing line to add those options. Please use caution when modifying your fstab as it can lead to an un-bootable system if the wrong thing is modified.<br />
<br />
The '''barrier=1''' option ensures that tdb transactions are safe against unexpected power loss. A number of sites have corrupted their AD database in sam.ldb by not having this option enabled.<br />
<br />
You also need to compile your kernel with the XATTR, SECURITY, and POSIX_ACL<br />
options for your filesystem. For ext3 (change the 3 to a 4 for ext4) that means you need:<br />
<br />
CONFIG_EXT3_FS_XATTR=y<br />
CONFIG_EXT3_FS_SECURITY=y<br />
CONFIG_EXT3_FS_POSIX_ACL=y<br />
<br />
If you are running a Linux 2.6 (or greater) kernel with CONFIG_IKCONFIG_PROC<br />
defined you can check this with the following command:<br />
<br />
$ zgrep CONFIG_EXT3_FS /proc/config.gz<br />
<br />
=== File Systems without xattr support ===<br />
<br />
If you don't have a filesystem with xattr support, then you can<br />
simulate it by adding the following line to your smb.conf:<br />
<br />
posix:eadb = /usr/local/samba/eadb.tdb<br />
<br />
that will place all extra file attributes (NT ACLs, DOS EAs, streams<br />
etc), in that tdb. It is not efficient, and doesn't scale well, but at<br />
least it gives you a choice when you don't have a modern filesystem.<br />
<br />
=== Testing your filesystem ===<br />
<br />
To test your filesystem support, install the 'attr' package and run<br />
the following 4 commands as root:<br />
<br />
# touch test.txt<br />
# setfattr -n user.test -v test test.txt<br />
# setfattr -n security.test -v test2 test.txt<br />
# getfattr -d test.txt<br />
# getfattr -n security.test -d test.txt<br />
<br />
You should see output like this:<br />
<br />
# file: test.txt<br />
user.test="test"<br />
<br />
# file: test.txt<br />
security.test="test2"<br />
<br />
For ACL testing do the following as root:<br />
# touch test3.txt<br />
# setfacl -m g:adm:rwx test3.txt<br />
# getfacl test3.txt<br />
<br />
and you should get a line like <tt>group:adm:rwx</tt> in your output.<br />
<br />
<br />
If you get any "Operation not supported" errors then it means your<br />
kernel is not configured correctly, or your filesystem is not mounted<br />
with the right options.<br />
<br />
If you get any "Operation not permitted" errors then it probably means<br />
you didn't try the test as root.<br />
<br />
If you are using the posix:eadb option then you don't need to test your filesystem in this manner.</div>Gazzonyxhttps://wiki.samba.org/index.php?title=Clustered_Samba&diff=7694Clustered Samba2013-05-23T16:55:24Z<p>Gazzonyx: Grammar fix</p>
<hr />
<div>== Introduction ==<br />
<br />
NOTE! A new cluster system for Samba called 'CTDB' has now been implemented. See http://ctdb.samba.org/ for details<br />
<br />
Current [[Samba3]] implementations can't be used directly on<br />
[[Cluster|clustered systems]] because they are oriented to single-server<br />
systems. The main reason is that [[smbd]] processes use [[TDB]]<br />
(local-oriented database) for [[messaging]], storing shared data, etc<br />
- there is no way to coordinate [[smbd]] processes run on different<br />
cluster nodes.<br />
<br />
A simple [[Clustered Samba]] system looks like this:<br />
<br />
[[Image:clustered_samba.png]]<br />
<br />
(you can get all images' SVG sources here - [http://samba.org/~ab/dralex/])<br />
<br />
Each node has its own [[smbd]] daemon - they should communicate with<br />
each other to avoid shared data corruption, treat [[oplock|oplocks]] and<br />
so on. So the most problem is the extending of the [[locking]] subsystem<br />
([[share mode locks|share mode locks]], [[oplock|opportunistic locks]],<br />
[[byte-range lock|byte-range locks]]) to multi-node system and cluster<br />
point of view.<br />
<br />
== Cluster Implementation Requirements ==<br />
<br />
This section lists a number of functional requirements that must be<br />
addressed by any [[Clustered Samba]] implementation.<br />
<br />
===Data integrity===<br />
Multiple Samba servers running on different cluster members and<br />
serving the same cluster filesystem should cooperate to ensure that<br />
users' data is no less safe than a standalone configuration.<br />
<br />
===Zero configuration===<br />
The extra administration required to set up a ClusteredSamba should be<br />
minimised, to nothing if possible. This means that the administrator<br />
should not have to configure any cluster membership in addition to<br />
that already configured in the underlying cluster. The administrator<br />
should not have to configure any setting that can be derived from<br />
the underlying cluster (eg. private interfaces).<br />
<br />
===Single set of binaries===<br />
Clustering should be a runtime option. That is, vendors should not<br />
have to ship separate sets of binaries for cluster and standalone<br />
installations.<br />
<br />
===Cluster independence===<br />
The implementation should work on a variety of clustering<br />
technologies. As a guideline, the clustering implementation should<br />
have acceptable results for a set of nodes sharing a cross-mounted<br />
NFS filesystem.<br />
<br />
This also means that the implementation must not rely on a cluster<br />
implementing any special CIFS features like share modes, file change<br />
notifications, oplocks, etc. The implementation should be able to<br />
take advantage of special cluster features if they exist, however.<br />
<br />
Across the Samba community, it will be necessary to support CXFS,<br />
GFS and GPFS.<br />
<br />
===Cluster membership===<br />
The implementation should tolerate arbitrary fluctuations in cluster<br />
membership. Specifically, this means that an implementation that<br />
relies on a single special node (eg. to arbitrate share mode access)<br />
must be able to tolerate the (possibly permanent) absence of that<br />
node.<br />
<br />
===Fault tolerance===<br />
The implementation should tolerate different degrees of reliability<br />
amongst cluster members, eg. node A might be really flaky but node<br />
B is ok. This tends to imply a loosely coupled model.<br />
<br />
===Scalability===<br />
It is acknowledged that certain workloads will not scale due to the<br />
underlying cluster technology. However, the Samba cluster should be<br />
designed such that all workloads might scale, since different clusters<br />
have different scalability characteristics and the scalability of<br />
even the same cluster technology might change across versions.<br />
<br />
Workloads that must scale are:<br />
* Multiple clients doing IO to disjoint subtrees<br />
* Multiple clients all reading the same files (ie. renderwall load) <br />
<br />
===Performance===<br />
A key performance criterion for the implementation is latency. The<br />
implementation should be designed to minimise the latency of any<br />
checks that might require cross-cluster communication.<br />
<br />
When applied to a single node, the implementation should not provide<br />
substantially worse performance than a non-cluster version of Samba.<br />
<br />
== The Cluster Synchronization Problem ==<br />
<br />
The fundamental problem in implementing a clustered Samba is distributing<br />
the Samba state across the cluster.<br />
<br />
Only a portion of the state Samba associates with each file is pushed<br />
down into the filesystem. We can assume that the state that is pushed<br />
into the filesystem is distributed by the cluster itself. This leaves us<br />
with the problem of distributing information that is stored outside the<br />
filesystem.<br />
<br />
From the point of view of providing strong data integrity, the primary<br />
information we need to be concerned about is the locking state. There is an<br />
implicit requirement to ensure that any information we manually distribute<br />
across the cluster is node-independent.<br />
<br />
=== Distributing Locking State ===<br />
<br />
Here we'll gather information on how locking mechanisms are done in<br />
[[Samba3]].<br />
<br />
Locking is used in different file operations (opening, closing, deleting),<br />
but the main place is huge [[open_file_ntcreate]] function (in fact,<br />
[[open_file_ntcreate]] gives high-level interface to share access<br />
testing).<br />
<br />
Share mode information consist of two different parts: share mode info<br />
and deferred opens info. The former is a collection of file sharing<br />
parameters (file name, list of processes opened the file, oplock info,<br />
etc). The latter is the part of the deferring open calls mechanism.<br />
<br />
All locking operations are presented on the scheme<br />
[[:Image:Samba_locking_calls.png]] (based on [[Analysing source code|code<br />
analysis]] of [[get_share_mode_lock]] function).<br />
<br />
Original smbd's locking operations include:<br />
<br />
* local file operations (file renaming and deleting, posix locking, etc);<br />
* modifications of locking storage (''locking.tdb'');<br />
* sending messages to other lock holders<br />
<br />
All this actions are made under a tdb chain lock to avoid file system or<br />
''locking.tdb'' conflict.<br />
<br />
Present locking mechanism uses single ''locking.tdb'' (database with<br />
shared information - share mode entries, [[deferred open]] entries,<br />
flags, etc) for all [[smbd]] processes:<br />
<br />
[[Image:samba locking 1.png]]<br />
<br />
=== Node-Independent State Information ===<br />
<br />
The information that [[Clustered Samba]] needs to distribute across<br />
the cluster varies widely. Effectively, this means that the contents of<br />
every message type need to be carefully designed to ensure that it will<br />
be valid in a cluster context.<br />
<br />
For example,<br />
* a ''ino_t, dev_t'' tuple is not valid across a CXFS cluster because the ''dev_t'' will be different on different cluster nodes. <br />
* in Tru64 cluster, the ''pid_t'' given as an argument to ''kill(2)'' is valid across the cluster, but the same is not true for CXFS or GPFS.<br />
<br />
There are many traps of this kind, so the cluster arhitecture needs<br />
to be carefully considered, and appropriate abstractions need to be<br />
put in place (eg. the ''process_id'' type) to make sure that cluster<br />
functionality is not broken by development on the standalone server.<br />
<br />
== Clustered Samba Prototypes ==<br />
<br />
Three prototypes of a clustered Samba implementation have been developed in<br />
branches on svn.samba.org:<br />
<br />
* http://viewcvs.samba.org/cgi-bin/viewcvs.cgi/branches/tmp/jpeach-cluster/<br />
* http://viewcvs.samba.org/cgi-bin/viewcvs.cgi/branches/tmp/vl-cluster/ <br />
* http://viewcvs.samba.org/cgi-bin/viewcvs.cgi/branches/tmp/vl-messaging/ <br />
<br />
Both of these prototypes take a ''shared TDB'' approach to distributing<br />
locking state. In this approach, all cluster nodes access the same<br />
TDB files. The cluster filesystem takes care of ensuring the TDB<br />
contents are consistent across the cluster. Bothe prototypes include<br />
extensive modifications to Samba internal data representations to make<br />
the information stored in various TDBs node-independent.<br />
<br />
The shared TDB approach is simple in terms of the implementation<br />
effort required, but it does not meet out performance criteria. The<br />
primary reason for this is that the design fundamentally depends on<br />
''token thrashing'' behaviour as every cluster node is making updates<br />
to the same TDB file. The prototypes attempt to minimise this impact<br />
by virtualising the TDB interface and splitting each TDB into a number<br />
of separate files. This postpones, but does not alleviate, the problems<br />
caused by token thrashing.<br />
<br />
== Proposed Cluster Architecture ==<br />
<br />
On [[Cluster|clustered systems]] internal [[messaging]] can be used to<br />
interconnect [[smbd]] processes and locking databases:<br />
<br />
[[Image:samba locking 2.png]]<br />
<br />
The first problem with using the SAN as shared storage is performance. If<br />
we simply relocate the TDB files to the SAN, we force multiple cluster<br />
nodes to access the same files for both read and write. In most cluster<br />
implementations this will cause token bouncing and poor performance. There<br />
will tend to be high latency for TDB accesses and scalability will be<br />
poor for certain workloads.<br />
<br />
Fundamentally, any algorithm that involves multiple nodes synchronising<br />
on the shared filesystem will suffer from two performance drawbacks:<br />
* it unpredictably increases the liklihood of token thrashing<br />
* the performance characterisitics will differ across different cluster implementations <br />
<br />
The second problem with using the SAN for IPC is that this will tend to<br />
trigger rarely used code paths in the cluster. Depending on the cluster<br />
in question, it may make the overall system more susceptible to deadlocks.<br />
<br />
===Application-level locking===<br />
We can alleviate the problems associated with shared filesystem<br />
IPC by designating a single node to be an authoritative arbiter of<br />
locking state access. We call this node the '''locking leader'''.<br />
<br />
[[Image:samba locking 3.png]]<br />
<br />
Instead of accessing the TDBs directly, cluster nodes send a locking query<br />
directly to the locking leader. This has good latency characteristics,<br />
since the cost of setting or checking a share mode is a single network<br />
round trip, whereas accessing a shared TDB file might cause round trips<br />
for multiple tokens. A further advantage of an application-specific<br />
locking protocol is that the protocol can be specifically designed for<br />
low latency.<br />
<br />
===Relocation and Recovery===<br />
The disadvantage of this locking scheme is that we suddenly have to<br />
deal with membership fluctuations. That is, if the current locking<br />
leader loses cluster membership we need to relocate that role to a<br />
different cluster member.<br />
<br />
The key to avoiding a complicated and error-prone distributed<br />
algorithm is to notice that all types of cluster has some kind of<br />
identified to uniquely name each member node. We can take advantage<br />
of the ordering implicit in this naming to statically define a policy<br />
that can be used to determine the current locking leader.<br />
<br />
In CXFS, we could say that the MDS or the CMS leader is always the locking<br />
leader. In a cluster of peer nodes, we could say that the lowest numbered<br />
node is always the oracle. All that is necessary is that nodes must be<br />
able to determine the leadership order (and hence the current leader)<br />
without requiring the agreement of any other node. This means we don't<br />
have to maintain a separate Samba cluster membership in sync with the<br />
underlying cluster membership.<br />
<br />
If the current locking leader fails, the next cluster member in our<br />
static ordering becomes the leader. If the distributed state has a<br />
persistent backing store in the shared filesystem, the new locking<br />
leader can taked over without any interruption in service. There are<br />
few performance implications to backing the distributed state in the<br />
shared filesystem, since only the locking leader is ever updating<br />
this state. We assume that any metadata tokens will be migrated<br />
to the locking leader, allowing us to approximate the latencies of<br />
local filesystems.<br />
<br />
If a higher-order cluster member joins the cluster, we have a<br />
dilemma. Does the new member become the locking leader or does the role<br />
stay with the current leader? I propose that that the current leader<br />
should relinquish the role of locking leader as soon as it becomes aware<br />
that a better candidate is present. This complicates the implementation a<br />
little, but makes the cluster rules consistent, which is generally a win.<br />
<br />
Note that this scheme relies on all cluster members having access to<br />
accurate and timely cluster membership information. I believe that<br />
this is not a very onerous requirement, since all clusters that I am<br />
aware of already maintain their own membership state. Also note that<br />
this does not introduce any additional membership state or algorithms.<br />
<br />
Absent cluster members: There may be administrative reasons for<br />
not enabling Samba on every node of the cluster. In this case the<br />
locking leadership order might have holes.<br />
<br />
In the case of a cluster where the locking leader can be present on<br />
any node, this could mean that finding the locking leader could take<br />
up to N network probes (in the absence of a cleverer mechanism). This<br />
might be acceptable provided that the locking leader does not relocate<br />
too often.</div>Gazzonyxhttps://wiki.samba.org/index.php?title=Clustered_Samba&diff=7693Clustered Samba2013-05-23T16:53:52Z<p>Gazzonyx: Grammar fix</p>
<hr />
<div>== Introduction ==<br />
<br />
NOTE! A new cluster system for Samba called 'CTDB' has now been implemented. See http://ctdb.samba.org/ for details<br />
<br />
Current [[Samba3]] implementations can't be used directly on<br />
[[Cluster|clustered systems]] because they are oriented to single-server<br />
systems. The main reason is that [[smbd]] processes use [[TDB]]<br />
(local-oriented database) for [[messaging]], storing shared data, etc<br />
- there is no way to coordinate [[smbd]] processes run on different<br />
cluster nodes.<br />
<br />
A simple [[Clustered Samba]] system looks like this:<br />
<br />
[[Image:clustered_samba.png]]<br />
<br />
(you can get all images's SVG sources here - [http://samba.org/~ab/dralex/])<br />
<br />
Each node has its own [[smbd]] daemon - they should communicate with<br />
each other to avoid shared data corruption, treat [[oplock|oplocks]] and<br />
so on. So the most problem is the extending of the [[locking]] subsystem<br />
([[share mode locks|share mode locks]], [[oplock|opportunistic locks]],<br />
[[byte-range lock|byte-range locks]]) to multi-node system and cluster<br />
point of view.<br />
<br />
== Cluster Implementation Requirements ==<br />
<br />
This section lists a number of functional requirements that must be<br />
addressed by any [[Clustered Samba]] implementation.<br />
<br />
===Data integrity===<br />
Multiple Samba servers running on different cluster members and<br />
serving the same cluster filesystem should cooperate to ensure that<br />
users' data is no less safe than a standalone configuration.<br />
<br />
===Zero configuration===<br />
The extra administration required to set up a ClusteredSamba should be<br />
minimised, to nothing if possible. This means that the administrator<br />
should not have to configure any cluster membership in addition to<br />
that already configured in the underlying cluster. The administrator<br />
should not have to configure any setting that can be derived from<br />
the underlying cluster (eg. private interfaces).<br />
<br />
===Single set of binaries===<br />
Clustering should be a runtime option. That is, vendors should not<br />
have to ship separate sets of binaries for cluster and standalone<br />
installations.<br />
<br />
===Cluster independence===<br />
The implementation should work on a variety of clustering<br />
technologies. As a guideline, the clustering implementation should<br />
have acceptable results for a set of nodes sharing a cross-mounted<br />
NFS filesystem.<br />
<br />
This also means that the implementation must not rely on a cluster<br />
implementing any special CIFS features like share modes, file change<br />
notifications, oplocks, etc. The implementation should be able to<br />
take advantage of special cluster features if they exist, however.<br />
<br />
Across the Samba community, it will be necessary to support CXFS,<br />
GFS and GPFS.<br />
<br />
===Cluster membership===<br />
The implementation should tolerate arbitrary fluctuations in cluster<br />
membership. Specifically, this means that an implementation that<br />
relies on a single special node (eg. to arbitrate share mode access)<br />
must be able to tolerate the (possibly permanent) absence of that<br />
node.<br />
<br />
===Fault tolerance===<br />
The implementation should tolerate different degrees of reliability<br />
amongst cluster members, eg. node A might be really flaky but node<br />
B is ok. This tends to imply a loosely coupled model.<br />
<br />
===Scalability===<br />
It is acknowledged that certain workloads will not scale due to the<br />
underlying cluster technology. However, the Samba cluster should be<br />
designed such that all workloads might scale, since different clusters<br />
have different scalability characteristics and the scalability of<br />
even the same cluster technology might change across versions.<br />
<br />
Workloads that must scale are:<br />
* Multiple clients doing IO to disjoint subtrees<br />
* Multiple clients all reading the same files (ie. renderwall load) <br />
<br />
===Performance===<br />
A key performance criterion for the implementation is latency. The<br />
implementation should be designed to minimise the latency of any<br />
checks that might require cross-cluster communication.<br />
<br />
When applied to a single node, the implementation should not provide<br />
substantially worse performance than a non-cluster version of Samba.<br />
<br />
== The Cluster Synchronization Problem ==<br />
<br />
The fundamental problem in implementing a clustered Samba is distributing<br />
the Samba state across the cluster.<br />
<br />
Only a portion of the state Samba associates with each file is pushed<br />
down into the filesystem. We can assume that the state that is pushed<br />
into the filesystem is distributed by the cluster itself. This leaves us<br />
with the problem of distributing information that is stored outside the<br />
filesystem.<br />
<br />
From the point of view of providing strong data integrity, the primary<br />
information we need to be concerned about is the locking state. There is an<br />
implicit requirement to ensure that any information we manually distribute<br />
across the cluster is node-independent.<br />
<br />
=== Distributing Locking State ===<br />
<br />
Here we'll gather information on how locking mechanisms are done in<br />
[[Samba3]].<br />
<br />
Locking is used in different file operations (opening, closing, deleting),<br />
but the main place is huge [[open_file_ntcreate]] function (in fact,<br />
[[open_file_ntcreate]] gives high-level interface to share access<br />
testing).<br />
<br />
Share mode information consist of two different parts: share mode info<br />
and deferred opens info. The former is a collection of file sharing<br />
parameters (file name, list of processes opened the file, oplock info,<br />
etc). The latter is the part of the deferring open calls mechanism.<br />
<br />
All locking operations are presented on the scheme<br />
[[:Image:Samba_locking_calls.png]] (based on [[Analysing source code|code<br />
analysis]] of [[get_share_mode_lock]] function).<br />
<br />
Original smbd's locking operations include:<br />
<br />
* local file operations (file renaming and deleting, posix locking, etc);<br />
* modifications of locking storage (''locking.tdb'');<br />
* sending messages to other lock holders<br />
<br />
All this actions are made under a tdb chain lock to avoid file system or<br />
''locking.tdb'' conflict.<br />
<br />
Present locking mechanism uses single ''locking.tdb'' (database with<br />
shared information - share mode entries, [[deferred open]] entries,<br />
flags, etc) for all [[smbd]] processes:<br />
<br />
[[Image:samba locking 1.png]]<br />
<br />
=== Node-Independent State Information ===<br />
<br />
The information that [[Clustered Samba]] needs to distribute across<br />
the cluster varies widely. Effectively, this means that the contents of<br />
every message type need to be carefully designed to ensure that it will<br />
be valid in a cluster context.<br />
<br />
For example,<br />
* a ''ino_t, dev_t'' tuple is not valid across a CXFS cluster because the ''dev_t'' will be different on different cluster nodes. <br />
* in Tru64 cluster, the ''pid_t'' given as an argument to ''kill(2)'' is valid across the cluster, but the same is not true for CXFS or GPFS.<br />
<br />
There are many traps of this kind, so the cluster arhitecture needs<br />
to be carefully considered, and appropriate abstractions need to be<br />
put in place (eg. the ''process_id'' type) to make sure that cluster<br />
functionality is not broken by development on the standalone server.<br />
<br />
== Clustered Samba Prototypes ==<br />
<br />
Three prototypes of a clustered Samba implementation have been developed in<br />
branches on svn.samba.org:<br />
<br />
* http://viewcvs.samba.org/cgi-bin/viewcvs.cgi/branches/tmp/jpeach-cluster/<br />
* http://viewcvs.samba.org/cgi-bin/viewcvs.cgi/branches/tmp/vl-cluster/ <br />
* http://viewcvs.samba.org/cgi-bin/viewcvs.cgi/branches/tmp/vl-messaging/ <br />
<br />
Both of these prototypes take a ''shared TDB'' approach to distributing<br />
locking state. In this approach, all cluster nodes access the same<br />
TDB files. The cluster filesystem takes care of ensuring the TDB<br />
contents are consistent across the cluster. Bothe prototypes include<br />
extensive modifications to Samba internal data representations to make<br />
the information stored in various TDBs node-independent.<br />
<br />
The shared TDB approach is simple in terms of the implementation<br />
effort required, but it does not meet out performance criteria. The<br />
primary reason for this is that the design fundamentally depends on<br />
''token thrashing'' behaviour as every cluster node is making updates<br />
to the same TDB file. The prototypes attempt to minimise this impact<br />
by virtualising the TDB interface and splitting each TDB into a number<br />
of separate files. This postpones, but does not alleviate, the problems<br />
caused by token thrashing.<br />
<br />
== Proposed Cluster Architecture ==<br />
<br />
On [[Cluster|clustered systems]] internal [[messaging]] can be used to<br />
interconnect [[smbd]] processes and locking databases:<br />
<br />
[[Image:samba locking 2.png]]<br />
<br />
The first problem with using the SAN as shared storage is performance. If<br />
we simply relocate the TDB files to the SAN, we force multiple cluster<br />
nodes to access the same files for both read and write. In most cluster<br />
implementations this will cause token bouncing and poor performance. There<br />
will tend to be high latency for TDB accesses and scalability will be<br />
poor for certain workloads.<br />
<br />
Fundamentally, any algorithm that involves multiple nodes synchronising<br />
on the shared filesystem will suffer from two performance drawbacks:<br />
* it unpredictably increases the liklihood of token thrashing<br />
* the performance characterisitics will differ across different cluster implementations <br />
<br />
The second problem with using the SAN for IPC is that this will tend to<br />
trigger rarely used code paths in the cluster. Depending on the cluster<br />
in question, it may make the overall system more susceptible to deadlocks.<br />
<br />
===Application-level locking===<br />
We can alleviate the problems associated with shared filesystem<br />
IPC by designating a single node to be an authoritative arbiter of<br />
locking state access. We call this node the '''locking leader'''.<br />
<br />
[[Image:samba locking 3.png]]<br />
<br />
Instead of accessing the TDBs directly, cluster nodes send a locking query<br />
directly to the locking leader. This has good latency characteristics,<br />
since the cost of setting or checking a share mode is a single network<br />
round trip, whereas accessing a shared TDB file might cause round trips<br />
for multiple tokens. A further advantage of an application-specific<br />
locking protocol is that the protocol can be specifically designed for<br />
low latency.<br />
<br />
===Relocation and Recovery===<br />
The disadvantage of this locking scheme is that we suddenly have to<br />
deal with membership fluctuations. That is, if the current locking<br />
leader loses cluster membership we need to relocate that role to a<br />
different cluster member.<br />
<br />
The key to avoiding a complicated and error-prone distributed<br />
algorithm is to notice that all types of cluster has some kind of<br />
identified to uniquely name each member node. We can take advantage<br />
of the ordering implicit in this naming to statically define a policy<br />
that can be used to determine the current locking leader.<br />
<br />
In CXFS, we could say that the MDS or the CMS leader is always the locking<br />
leader. In a cluster of peer nodes, we could say that the lowest numbered<br />
node is always the oracle. All that is necessary is that nodes must be<br />
able to determine the leadership order (and hence the current leader)<br />
without requiring the agreement of any other node. This means we don't<br />
have to maintain a separate Samba cluster membership in sync with the<br />
underlying cluster membership.<br />
<br />
If the current locking leader fails, the next cluster member in our<br />
static ordering becomes the leader. If the distributed state has a<br />
persistent backing store in the shared filesystem, the new locking<br />
leader can taked over without any interruption in service. There are<br />
few performance implications to backing the distributed state in the<br />
shared filesystem, since only the locking leader is ever updating<br />
this state. We assume that any metadata tokens will be migrated<br />
to the locking leader, allowing us to approximate the latencies of<br />
local filesystems.<br />
<br />
If a higher-order cluster member joins the cluster, we have a<br />
dilemma. Does the new member become the locking leader or does the role<br />
stay with the current leader? I propose that that the current leader<br />
should relinquish the role of locking leader as soon as it becomes aware<br />
that a better candidate is present. This complicates the implementation a<br />
little, but makes the cluster rules consistent, which is generally a win.<br />
<br />
Note that this scheme relies on all cluster members having access to<br />
accurate and timely cluster membership information. I believe that<br />
this is not a very onerous requirement, since all clusters that I am<br />
aware of already maintain their own membership state. Also note that<br />
this does not introduce any additional membership state or algorithms.<br />
<br />
Absent cluster members: There may be administrative reasons for<br />
not enabling Samba on every node of the cluster. In this case the<br />
locking leadership order might have holes.<br />
<br />
In the case of a cluster where the locking leader can be present on<br />
any node, this could mean that finding the locking leader could take<br />
up to N network probes (in the absence of a cleverer mechanism). This<br />
might be acceptable provided that the locking leader does not relocate<br />
too often.</div>Gazzonyxhttps://wiki.samba.org/index.php?title=Feature_Specific_HOWTOs&diff=7688Feature Specific HOWTOs2013-05-22T19:45:11Z<p>Gazzonyx: Added the AD DC HowTo link</p>
<hr />
<div>[[Event Logging]]<br><br />
<br />
[[Ldapsam Editposix]]<br><br />
<br />
[[Winbind Kerberos Locator]]<br><br />
<br />
[[Samba AD DC HOWTO]]<br />
<br />
== PAM Howtos ==<br />
<br />
[[PAM Offline Authentication]]<br><br />
<br />
[[PAM Kerberos Authentication]]<br><br />
<br />
== Joining Howtos ==<br />
<br />
[[Remote join]]<br><br />
<br />
[[Joining with empty smb.conf]]<br><br />
<br />
==File Replication Howtos==<br />
<br />
[[Directory Replication]]<br />
<br />
----<br />
[[Category:Category HowTos]]</div>Gazzonyxhttps://wiki.samba.org/index.php?title=Setting_up_Samba_as_an_Active_Directory_Domain_Controller&diff=7202Setting up Samba as an Active Directory Domain Controller2012-12-28T20:41:23Z<p>Gazzonyx: Added link to Implementing Roaming Profiles</p>
<hr />
<div>= HOWTO to set up Samba as an Active Directory compatible Domain Controller =<br />
<br />
This document explains how to setup a simple Samba<br />
server as an Domain Controller compatible with Microsoft's Active Directory, for use particularly by Microsoft Windows clients that are joined to the Active Directory Domain, for services such as Domain Logon. We refer to this capability as being an AD DC for short. <br />
<br />
== Video Demonstrations of This HOWTO ==<br />
<br />
A set of [[samba4/videos|demonstration videos]] is available that<br />
may provide a useful overview of the contents of this HOWTO.<br />
<br />
== A Note on Versions ==<br />
<br />
Samba is developing rapidly. This HOWTO is frequently updated to reflect the latest changes in the Samba git repository. Please see the [[Release_Planning_for_Samba_4.0|Samba 4.0 Release Planning]] more specifics on the release planning.<br />
<br />
== Samba OS Requirements ==<br />
<br />
Because of the constantly changing and ever expanding nature of Linux, the '''OS Requirements for Samba 4 have been moved''' from Step 2, to [[Samba_4/OS_Requirements]]<br />
This not only includes the required packages for a successful Samba AD DC deployment, but also the required file system features. Please consider that page as a prerequisite to a successful Samba AD DC setup.<br />
<br />
== Step 1: Download Samba ==<br />
<br />
Currently, there are three methods to download the current Samba sources, either as a tarball of the latest stable release, or a development version via git or rsync. If you hope to work with the team on a development version to resolve issues you may hit via code changes, we recommend using the git method for downloading Samba, as it makes getting updates easier, and also allows you to integrate test patches from Samba developers more easily in case of problems. <br />
<br />
In the following examples we will assume that your top-level source is named <tt>samba-master</tt>. If you downloaded a tarball this will instead be based on the name of the tarball downloaded (e.g. <tt>samba-4.0.0</tt> for the tarball samba-4.0.0.tar.gz). Also note that in the <tt>master</tt> branch the<br />
Samba 4 code in our current git tree is now located in the top level directory.<br />
<br />
=== Downloading a tarball ===<br />
<br />
If you wish to use a released version of Samba 4.0, you can download the latest Samba 4.0 tarball from [http://ftp.samba.org/pub/samba/ the Samba website]<br />
<br />
=== Downloading via git ===<br />
<br />
Git allows you to download the source tree via either the <tt>git</tt> or <tt>http</tt>protocols. In general, the <tt>git</tt> protocol is the preferred choice since it compresses the data being transferred. To download the source tree via <tt>git</tt>, run the following command:<br />
<br />
$ git clone git://git.samba.org/samba.git samba-master<br />
<br />
Alternatively, if you prefer to use the <tt>http</tt> protocol, run the following command:<br />
<br />
$ git clone http://gitweb.samba.org/samba.git samba-master<br />
<br />
Either command will create a directory called <tt>samba-master</tt> in the current<br />
directory.<br />
<br />
=== Updating via git ===<br />
<br />
If you already have downloaded the source tree via <tt>git</tt> and want to update the tree to the latest version, run the following command in your <tt>samba-master</tt> directory:<br />
<br />
$ git pull<br />
<br />
If you get an error like this:<br />
fatal: Unable to create '[...]/samba_master/.git/index.lock': File exists.<br />
Run the command below to reset your tree.<br />
<br />
If you are having trouble compiling the source, it may be due to stale files. You can reset your <tt>git</tt> tree to correct these errors. To reset your <tt>git</tt> tree, run the following command in your <tt>samba-master</tt> directory:<br />
<br />
$ git clean -x -f -d<br />
<br />
=== Downloading via rsync ===<br />
<br />
If <tt>git</tt> is not available to you, <tt>rsync</tt> is the next best choice. To download the source tree via <tt>rsync</tt>, run the following command:<br />
<br />
$ rsync -avz samba.org::ftp/unpacked/samba_4_0_test/ samba-master<br />
<br />
This command will create a directory called <tt>samba-master</tt> in the current directory, containing a checked out <tt>git</tt> repository. If you plan on using <tt>git</tt> to manage the tree, you will need to run the following commands in your <tt>samba-master</tt> directory:<br />
<br />
$ cd samba-master/<br />
$ rm .git/refs/tags/*<br />
$ rm -r .git/refs/remotes/<br />
$ git config remote.origin.url git://git.samba.org/samba.git<br />
$ git config --add remote.origin.fetch +refs/tags/*:refs/tags/* (this line is optional)<br />
$ git fetch<br />
<br />
Note you can ignore this error from <tt>git fetch</tt>:<br />
error: refs/heads/master does not point to a valid object!<br />
<br />
Refer to the [[#Updating via git|Updating via git]] instructions on how to manage the source tree with <tt>git</tt>.<br />
<br />
== Step 2: Compile Samba ==<br />
<br />
To build Samba, run the following command in your <tt>samba-master</tt> directory:<br />
<br />
$ cd samba-master<br />
$ ./configure --enable-debug --enable-selftest<br />
$ make<br />
<br />
The above command will setup Samba to install in <tt>/usr/local/samba</tt>. If you want Samba to install in a different directory, then you should use the <tt>--prefix</tt> option to <tt>configure</tt>.<br />
<br />
The reason we recommend using <tt>--enable-debug --enable-selftest</tt> for Samba is that it will include extra debug information that will help us diagnose problems in case of failures, and will also allow you to run our selftest <tt>make test</tt> to validate that Samba can behave correctly on your platform. Both of these are however, entirely '''optional'''.<br />
<br />
'''Profiling with google-perftools'''<br />
<br />
If you want to enable profiling support, change the configure command above to the following:<br />
$ LDFLAGS="-ltcmalloc -lprofiler" ./configure.developer<br />
:''(This also works for CFLAGS)''<br />
<br />
== Step 3: Install Samba ==<br />
<br />
To install Samba, run the following command in your <tt>samba-master</tt> directory:<br />
<br />
$ make install<br />
<br />
Note that this must be run as a user who has permission to write to the install directory, which defaults to <tt>/usr/local/samba</tt>. See [[#Step 2: Compile Samba4|Step 2: Compile Samba ]] for instructions on how to change the install directory.<br />
<br />
For the rest of this HOWTO we will assume that you have installed<br />
Samba in the default location. All future Samba commands will stem from the <tt>/usr/local/samba/sbin</tt> and <tt>/usr/local/samba/bin</tt> directories.<br />
<br />
Please review the [[Samba4#Previous_Releases|Release Notes]] for the version you have installed, it may contain important information not yet reflected in this HOWTO.<br />
<br />
=== Upgrading ===<br />
<br />
If you are upgrading from a previous release of Samba 4.x, be sure to review all the [[Samba4#Previous_Releases|Release Notes]] for the new version, as well as the notes for all the interim versions.<br />
<br />
== Step 4: Provision Samba ==<br />
<br />
The provision step sets up a basic user database, and is used when you are setting up your Samba<br />
server in its own domain. If you instead want to setup your Samba server as an additional domain controller<br />
in an existing domain, then please see the [[#Joining a Windows Domain Controller as an Additional DC in a Domain|Joining a Windows Domain Controller as an Additional DC in a Domain]] section on this page. If you want to migrate an existing Samba 3.x domain to Samba 4.0 as an AD DC, see the [[#Migrating an Existing Samba3 Domain to Samba4|Migrating an Existing Samba 3 Domain to Samba 4]] section on this page.<br />
<br />
For the rest of the HOWTO we will assume that your DNS domain name is<br />
<tt>samdom.example.com</tt>, your short (also known as NT4) domain name is<br />
<tt>samdom</tt>, your Samba server's hostname is <tt>samba</tt>, and the IP Address of your Samba server is <tt>192.168.1.2</tt>.<br />
<br />
The provision step must be run as a user with permission to write to the install directory.<br />
<br />
# /usr/local/samba/bin/samba-tool domain provision<br />
<br />
This will run the provision tool interactively. For realm use something like <tt>samdom.example.com</tt>, for domain (it should suggest this) use <tt>samdom</tt>.<br />
<br />
If you run the previous command with a user who does not have write permission to the install directory, you will get an error similar to this:<br />
tdb_open_ex: could not open file /usr/local/samba/private/sam.ldb.d/DC=SAMDOM,DC=EXAMPLE,DC=COM. ldb: Permission denied<br />
<br />
You can pass options to <tt>samba-tool domain provision</tt> command. You can run it with the <tt>--help</tt> option to see a list of them.<br />
<br />
* Note: As of September 11, 2012 (Samba 4.0.0 RC1) the provision command now uses Samba's internal DNS server, if you would like the older behavior, add <tt>--dns-backend=BIND9_DLZ</tt> to the above provision command.<br />
* Note: You may need to remove the <tt>/usr/local/samba/etc/smb.conf</tt> file if you are re-running the provision command.<br />
* Note: If you use the --adminpass='password' switch, be aware that there are password complexity requirements, so if you are getting some odd error with provision, try a more complex password ie. 'Pa$$w0rd'<br />
<br />
== Step 5: Starting Samba as an AD DC ==<br />
<br />
If you are planning to run Samba as a production server, then just run the <tt>samba</tt> binary as root<br />
<br />
# /usr/local/samba/sbin/samba<br />
<br />
That will run Samba in 'standard' mode, which is suitable for<br />
production use. Samba doesn't yet have init scripts included<br />
for each platform, but making one for your platform should not be<br />
difficult. There are some example scripts (for RedHat/Fedora, Debian and Ubuntu) on the [[Samba4/InitScript]] page.<br />
<br />
If you are running Samba as a developer you may find<br />
the following more useful:<br />
<br />
# /usr/local/samba/sbin/samba -i -M single<br />
<br />
This will start <tt>samba</tt> with all log messages printed to stdout, and restricting it to a<br />
single process. That mode of operation makes debugging <tt>samba</tt> with <tt>gdb</tt><br />
easier. If you want to launch it under <tt>gdb</tt>, run <tt>samba</tt> as follows:<br />
<br />
# gdb --args /usr/local/samba/sbin/samba -i -M single<br />
<br />
Note that if you are running any Samba 3 <tt>smbd</tt> or <tt>nmbd</tt> processes<br />
they need to be stopped before starting <tt>samba</tt> from Samba 4.<br />
<br />
Take care when running Samba commands if you also have a previous version of Samba installed. To avoid inadvertently running the wrong version, you should consider putting the <tt>/usr/local/samba/bin</tt> and <tt>/usr/local/samba/sbin</tt> directories in the beginning of your <tt>PATH</tt> variable.<br />
<br />
You can see what version of Samba, if any, is in your <tt>PATH</tt> variable by running the following:<br />
# samba -V<br />
<br />
== Step 6: Testing Samba as an AD DC ==<br />
<br />
First check you have the right version of <tt>smbclient</tt> by running the following command:<br />
<br />
$ /usr/local/samba/bin/smbclient --version<br />
<br />
This should show you a version starting with "Version 4.0.XXXXX". <br />
<br />
Now run this command to list the shares on your Samba server:<br />
<br />
$ /usr/local/samba/bin/smbclient -L localhost -U%<br />
<br />
The output of the command should be similar to what is shown below:<br />
<br />
Sharename Type Comment<br />
--------- ---- -------<br />
netlogon Disk<br />
sysvol Disk<br />
IPC$ IPC IPC Service (Samba 4.0.0)<br />
<br />
The <tt>netlogon</tt> and <tt>sysvol</tt> shares are basic shares needed for Active Directory server<br />
operation. <br />
<br />
If the command failed, restart samba by running the following:<br />
<br />
# killall samba<br />
# rm -v -- /usr/local/samba/var/run/smbd-fileserver.conf.pid<br />
# /usr/local/samba/sbin/samba<br />
<br />
To test that authentication is working, you should try to connect to the <tt>netlogon</tt> share<br />
using the Administrator password you set earlier:<br />
<br />
$ smbclient //localhost/netlogon -UAdministrator%'p4$$word' -c 'ls'<br />
<br />
The output of the command should be similar to what is shown below:<br />
<br />
Domain=[SAMDOM] OS=[Unix] Server=[Samba 4.0.0beta9-GIT-e4677e3]<br />
. D 0 Wed Sep 12 21:00:36 2012<br />
.. D 0 Wed Sep 12 21:02:28 2012<br />
<br />
== Step 7: Configure DNS ==<br />
<br />
A working DNS setup is essential to the correct operation of<br />
Samba. Without the right DNS entries, Kerberos won't work, which in<br />
turn means that many of the basic features of Samba won't work.<br />
<br />
It is worth spending some extra time to ensure your DNS setup is correct, as debugging problems caused by mis-configured DNS can take a<br />
lot of time later on.<br />
<br />
=== DNS Server ===<br />
==== Samba's Internal DNS Server ====<br />
<br />
If you specified <tt>--dns-backend=SAMBA_INTERNAL</TT> or did not specify any backend at all when you provisioned, there is no further setup required for the DNS server. However, you still need to configure your <tt>/etc/resolv.conf</tt> as shown in [[#Configure /etc/resolv.conf|Configure /etc/resolv.conf]]<br />
<br />
If you want the internal DNS server to forward requests it isn't responsible for, then add the following to your smb.conf:<br />
dns forwarder = {IP-Address of the DNS you want to forward to}<br />
<br />
'''Warning:''' If you are running X windows on your machine, networkmanager could be spawning dnsmasq, check the logs for lines like:<br />
<br />
Failed to bind to 0.0.0.0:53 TCP - NT_STATUS_ADDRESS_ALREADY_ASSOCIATED<br />
<br />
If you need to disable this you can open <tt>/etc/NetworkManager/NetworkManager.conf</tt> in your favorite editor as root, and comment out the line <tt>dns=dnsmasq</tt>, then <tt>restart network-manager</tt><br />
<br />
==== Bind 9.8.0 or newer ====<br />
<br />
If using BIND, the next step to get a working DNS setup for Samba is to start<br />
with the DNS configuration file that is created by the<br />
[[#Step 4: Provision Samba4|provision step]] or if you are using any of the other samba-tool options (classicupgrade for example) you can specify --dns-backend=BIND9_DLZ or --dns-backend=BIND9_FLATFILE.<br />
<br />
You can<br />
activate the configuration that the provision has created by including this configuration file in bind's named configuration file. This file is typically located in the <tt>/etc/bind</tt> directory, please refer to your distribution documentation for the location of this file on your system. Once located, add the following line to the configuration file:<br />
<br />
include "/usr/local/samba/private/named.conf";<br />
<br />
Edit that file to uncomment the correct dlz plugin line, based on your version of bind. Open the <tt>/usr/local/samba/private/named.conf</tt> file in a text editor and follow the instructions inside.<br />
<br />
After adding that line you should restart your Bind server and check<br />
in the system logs for any problems. If available, you can run <tt>named-checkconf</tt> to help you fix any problems with your named configuration.<br />
<br />
==== Bind 9.7.x ====<br />
<br />
Users of bind-9.7.x are strongly encouraged to upgrade to bind-9.8 or bind-9.9. If this is not possible, refer to the section [[#Step 9: Configure Kerberos DNS Dynamic Updates|Configure Kerberos DNS Dynamic Updates]] for instructions on configuring bind-9.7.<br />
<br />
==== Bind (All Versions) ====<br />
<br />
A common problem you may encounter is that many modern Linux distributions activate<br />
'Apparmor' or 'SELinux' by default, and these may be configured to<br />
deny access to Bind for your the <tt>named.conf</tt> and zone files created in<br />
the provision. If your Bind logs show that Bind is getting a access<br />
denied error accessing these files, please see your local system<br />
documentation for how to enable access to these files in Bind (hint:<br />
for Apparmor systems such as Ubuntu, the command <tt>aa-logprof</tt> may be<br />
useful).<br />
<br />
*Note: On Debian systems, the zone auto-generation might detect and use <tt>127.0.1.1</tt> as the domain controller's IP address. This will cause problems when trying to connect to the server from client machines. To fix this, you will need to adjust <tt>/usr/local/samba/private/named.conf</tt> by changing <tt>127.0.1.1</tt> to reflect the actual IP address of the server you're setting up.<br />
*Note: On Debian SID (bind9 package), <tt>/etc/bind/named.conf.options</tt> is missing and this will cause the <tt>named</tt> daemon to fail to start. To fix this either create an empty file, or comment out corresponding line in <tt>/etc/bind/named.conf</tt>. See your syslog messages for more information.<br />
<br />
=== Configure /etc/resolv.conf ===<br />
<br />
For all the local DNS lookups to resolve correctly, we need to modify the server's <tt>/etc/resolv.conf</tt> file. The following example should be sufficient to have DNS resolve properly:<br />
<br />
domain samdom.example.com<br />
nameserver 192.168.1.2<br />
<br />
*Note: Remember to change the IP Address to your Samba server's IP Address<br />
*Note: If your server is set up to receive its IP configuration via DHCP, the <tt>/etc/resolv.conf</tt> file might be automatically updated. Refer to your distribution's documentation on how to stop this behavior.<br />
<br />
=== Testing DNS ===<br />
<br />
To test that DNS is working properly, run the following commands and compare the output to what is shown:<br />
<br />
$ host -t SRV _ldap._tcp.samdom.example.com.<br />
_ldap._tcp.samdom.example.com has SRV record 0 100 389 samba.samdom.example.com.<br />
<br />
$ host -t SRV _kerberos._udp.samdom.example.com.<br />
_kerberos._udp.samdom.example.com has SRV record 0 100 88 samba.samdom.example.com.<br />
<br />
$ host -t A samba.samdom.example.com.<br />
samba.samdom.example.com has address 10.0.0.1<br />
<br />
The answers you get should be similar to the ones above (adjusted for your DNS domain name and hostname). If you get any errors, <br />
carefully check your system logs to locate the problem.<br />
<br />
== Step 8: Configure Kerberos ==<br />
<br />
Kerberos configuration is handled by the <tt>krb.conf</tt> file. This file is typically located in the <tt>/etc</tt> directory, please refer to your distribution documentation for the location of this file on your system. Replace the existing file, if any, with the sample from <tt>/usr/local/samba/share/setup/krb5.conf</tt>. Edit the file and replace <tt>${REALM}</tt> with the value you chose for the <tt>--realm</tt> parameter of the provision command above, make sure to enter the realm in '''uppercase letters''':<br />
<br />
[libdefaults]<br />
default_realm = SAMDOM.EXAMPLE.COM<br />
dns_lookup_realm = false<br />
dns_lookup_kdc = true<br />
<br />
=== Testing Kerberos ===<br />
<br />
The simplest test is to use the <tt>kinit</tt> command as follows:<br />
<br />
$ kinit administrator@SAMDOM.EXAMPLE.COM<br />
Password:<br />
<br />
*Note: You must specify your domain realm <tt>SAMDOM.EXAMPLE.COM</tt> in '''uppercase letters'''<br />
<br />
<tt>kinit</tt> will not give you any output. To verify that Kerberos is working, and that you received a ticket, run the following:<br />
<br />
$ klist<br />
Ticket cache: FILE:/tmp/krb5cc_1000<br />
Default principal: administrator@SAMDOM.EXAMPLE.COM<br />
<br />
Valid starting Expires Service principal<br />
02/10/10 19:39:48 02/11/10 19:39:46 krbtgt/SAMDOM.EXAMPLE.COM@SAMDOM.EXAMPLE.COM<br />
<br />
If either <tt>kinit</tt> or <tt>klist</tt> do not exist on your system, refer to [[Samba_4_OS_Requirements]] on how to install the necessary packages.<br />
<br />
You can also test Kerberos form a remote client, but you must first configure the client's <tt>krb5.conf</tt> and <tt>resolve.conf</tt> as shown previously.<br />
<br />
*Note: If you are using a client behind NAT then you have to add the following to the <tt>krb5.conf</tt> on the domain controller server:<br />
<br />
[kdc]<br />
check-ticket-addresses = false<br />
*Note: If provision generated you a password and you forgot it or didn't get it saved in some way, you can use "samba-tool user setpassword administrator" as root to reset it.<br />
<br />
== Step 9: Configure DNS Dynamic Updates via Kerberos ==<br />
<br />
Samba has the capability to automatically update the bind zone files via Kerberos. While this step is optional, it is highly recommended. If you are using Samba's internal DNS server, no configuration is needed, and you can skip this step.<br />
<br />
To setup dynamic DNS updates you need to have a recent version of bind installed. It is highly recommended that you install at least version 9.8.0 as that version includes a set of patches from the Samba Team to make dynamic DNS updates much more robust and easier to configure. In the instructions below we give instructions for both bind 9.7.2 and 9.8.0, but please use 9.8.0 or later if at all possible.<br />
<br />
You can tell what version of bind you have using the command <tt>/usr/sbin/named -V</tt>. If your OS does not have bind-9.8.0 or later, then please consider getting it from a package provided by a 3rd party (for example, on Ubuntu there is a ppa available with the newer versions of bind).<br />
<br />
=== Bind 9.8.0 or Later ===<br />
<br />
When using bind-9.8.0 or later you need to add the following to the options section of your bind config:<br />
options {<br />
[...]<br />
tkey-gssapi-keytab "/usr/local/samba/private/dns.keytab";<br />
[...]<br />
};<br />
<br />
This file is typically located in the <tt>/etc/bind</tt> directory, please refer to your distribution documentation for the location of this file on your system.<br />
<br />
=== Bind 9.7.x ===<br />
<br />
If you have bind-9.7.x (specifically 9.7.2 or later), then first determine if you can <br />
at all possibly run bind-9.8. You will have far fewer problems. Otherwise, follow these instructions.<br />
<br />
The Samba provision will have created a custom <tt>/usr/local/samba/private/named.conf.update</tt> configuration file. You need to include this file in your master <tt>named.conf</tt> to allow Samba/Kerberos DNS updates to automatically take place. Be advised that if you include this file in Bind versions that don't support it, Bind will fail to start.<br />
<br />
You additionally need to set two environment variables when using bind-9.7.x:<br />
<br />
KEYTAB_FILE="/usr/local/samba/private/dns.keytab"<br />
KRB5_KTNAME="/usr/local/samba/private/dns.keytab"<br />
export KEYTAB_FILE<br />
export KRB5_KTNAME<br />
<br />
These should be put in your settings file for bind. On Debian based<br />
systems (including Ubuntu) this is in <tt>/etc/default/bind9</tt>. On RedHat and SUSE derived systems it is<br />
in <tt>/etc/sysconfig/named</tt>, please refer to your distribution documentation for the correct location to set these environment variables. Strictly speaking you only either need<br />
<tt>KEYTAB_FILE</tt> or <tt>KRB5_KTNAME</tt>, but which you need depends on your distribution,<br />
so it's easier to just set both.<br />
<br />
The <tt>dns.keytab</tt> must be readable by the bind server process. Generally, this is accomplished by executing:<br />
$ chown named:named /usr/local/samba/private/dns.keytab<br />
<br />
(the provision should have setup these permissions for you automatically).<br />
<br />
Finally, you need to add the following to the options section of your bind config:<br />
options {<br />
[...]<br />
tkey-gssapi-credential "DNS/server.samdom.example.com";<br />
tkey-domain "SAMDOM.EXAMPLE.COM";<br />
[...]<br />
};<br />
<br />
The last part of the credential in the first line must match the dns name of the server you have set up. This file is typically located in the <tt>/etc/bind</tt> directory, please refer to your distribution documentation for the location of this file on your system.<br />
<br />
=== Testing/Debugging Dynamic DNS Updates ===<br />
<br />
The way the automatic DNS update in Samba works is that the provision<br />
will create a file <tt>/usr/local/samba/private/dns_update_list</tt>, which<br />
contains a list of DNS entries that Samba will try to dynamically<br />
update at startup and every 10 minutes thereafter using <tt>samba_dnsupdate</tt> utility.<br />
Updates will only happen if the DNS entries do not already exist.<br />
Remember that you need <tt>nsupdate</tt> utility from bind the distribution<br />
for all these to work.<br />
<br />
If you want to test or debug this process, then please run this as root:<br />
<br />
/usr/local/samba/sbin/samba_dnsupdate --verbose --all-names<br />
<br />
The command line options specified will force an update of all records in the <tt>dns_update_list</tt>, as well as output detailed information on what is being done.<br />
<br />
=== Interaction With Apparmor or SELinux ===<br />
<br />
If you are using Apparmor or SELinux, you have to ensure that the bind process has read access to the <tt>/usr/local/samba/private/dns.keytab</tt> file, the<br />
<tt>/usr/local/samba/private/named.conf</tt> file as well as read-write access to the <tt>/usr/local/samba/private/dns</tt> directory and it's own zone file. The Samba provision tries to setup the permissions<br />
correctly for these files, but you may find you need to make changes<br />
in your Apparmor or SELinux configuration if you are running either of<br />
those. If you are using Apparmor then the <tt>aa-logprof</tt> command may help<br />
you add any missing permissions you need to add after you start Samba<br />
and bind for the first time after configuring them.<br />
<br />
Please refer to [[#Step 11: Permissions, SELinux Labeling and Policy|Step 11: Permissions, SELinux Labeling and Policy]] for more information.<br />
<br />
== Step 10: Configure NTP (Optional) ==<br />
<br />
You require a recent ntpd version (=>4.2.6) that supports signed ntp. E. g. the version shipped with RHEL6 and Ubuntu < 11.04 are to old. The Ntpd of Debian Squeeze supports signed ntp.<br />
<br />
1. Download ntpd from ntp.org (verify md5 sum) and compile it (add additionals ./configure parameters, if needed):<br />
<br />
$ tar -zxvf ntp-4.x.x.tar.gz<br />
$ cd ntp-4.x.x<br />
$ ./configure --enable-ntp-signd<br />
$ make<br />
$ make install<br />
<br />
2a. If you already have a supported ntpd version and ntp.conf, you have to add/adjust only the following lines for minimal:<br />
ntpsigndsocket /usr/local/samba/var/lib/ntp_signd/<br />
restrict default mssntp<br />
<br />
2b. If a minimal/simple ntp.conf is fine for you, then fill the file with the following:<br />
server 127.127.1.0<br />
fudge 127.127.1.0 stratum 12<br />
ntpsigndsocket /usr/local/samba/var/lib/ntp_signd/<br />
restrict default mssntp<br />
<br />
2c. A more complex ntp.conf is the following:<br />
server 127.127.1.0<br />
fudge 127.127.1.0 stratum 10<br />
server 0.pool.ntp.org iburst prefer<br />
server 1.pool.ntp.org iburst prefer<br />
driftfile /var/lib/ntp/ntp.drift<br />
logfile /var/log/ntp<br />
ntpsigndsocket /usr/local/samba/var/lib/ntp_signd/<br />
restrict default kod nomodify notrap nopeer mssntp<br />
restrict 127.0.0.1<br />
restrict 0.pool.ntp.org mask 255.255.255.255 nomodify notrap nopeer noquery<br />
restrict 1.pool.ntp.org mask 255.255.255.255 nomodify notrap nopeer noquery<br />
For explanation: This config allows clients to receive time from this NTP host, localhost<br />
doesn't have any restrictions, and the servers we receive the time from ,are not allowed<br />
to do anything else than providing the time to us. For mor information about ntpd<br />
access controll, see<br />
http://support.ntp.org/bin/view/Support/AccessRestrictions<br />
<br />
3. On members of the domain you don't have to configure anything. Per default they will receive<br />
the time from the DC that has the FSMO role PDC.<br />
<br />
== Step 11: Permissions, SELinux Labeling and Policy ==<br />
<br />
These instructions are intended for RedHat 6.X, but may serve as a guide for other distributions/versions.<br />
<br />
There is still more work to be done in regards of creating a Samba 4 specific SELinux policy but for now you should be<br />
able to have everything working '''without''' disabling SELinux.<br />
<br />
For all the commands below, make sure you have set the following environment variable:<br />
MYREALM="samdom.example.com"<br />
<br />
=== Bind ===<br />
<br />
Set Permissions:<br />
chown named:named /usr/local/samba/private/dns<br />
chgrp named /usr/local/samba/private/dns.keytab<br />
chmod g+r /usr/local/samba/private/dns.keytab<br />
chmod 775 /usr/local/samba/private/dns<br />
<br />
Label files:<br />
chcon -t named_conf_t /usr/local/samba/private/dns.keytab<br />
chcon -t named_conf_t /usr/local/samba/private/named.conf.update<br />
chcon -t named_var_run_t /usr/local/samba/private/dns<br />
chcon -t named_var_run_t /usr/local/samba/private/dns/${MYREALM}.zone<br />
<br />
Set Label Persistence:<br />
semanage fcontext -a -t named_conf_t /usr/local/samba/private/dns.keytab<br />
semanage fcontext -a -t named_conf_t /usr/local/samba/private/named.conf<br />
semanage fcontext -a -t named_conf_t /usr/local/samba/private/named.conf.update<br />
semanage fcontext -a -t named_var_run_t /usr/local/samba/private/dns<br />
semanage fcontext -a -t named_var_run_t /usr/local/samba/private/dns/${MYREALM}.zone<br />
semanage fcontext -a -t named_var_run_t /usr/local/samba/private/dns/${MYREALM}.zone.jnl<br />
semanage fcontext -a -t ntpd_t /usr/local/samba/var/run/ntp_signd<br />
<br />
=== NTP ===<br />
Set Permissions:<br />
$ chgrp ntp /usr/local/samba/var/lib/ntp_signd<br />
<br />
Multiple attempts to set the context for ntp failed so the below policy was needed for windows clients time sync after joining the DOMAIN.<br />
$ chcon -u system_u -t ntpd_t /usr/local/samba/var/run/ntp_signd<br />
$ chcon -u system_u -t ntpd_t /usr/local/samba/var/run/<br />
$ chcon -t ntpd_t /usr/local/samba/var/run/ntp_signd/socket<br />
<br />
<tt>samba4.te</tt> policy:<br />
module samba4 1.0;<br />
<br />
<br />
require {<br />
type ntpd_t;<br />
type usr_t;<br />
type initrc_t;<br />
class sock_file write;<br />
class unix_stream_socket connectto;<br />
}<br />
<br />
#============= ntpd_t ==============<br />
allow ntpd_t usr_t:sock_file write;<br />
<br />
#============= ntpd_t ==============<br />
allow ntpd_t initrc_t:unix_stream_socket connectto;<br />
<br />
Check and load policy:<br />
$ checkmodule -M -m -o samba4.mod samba4.te <br />
$ semodule_package -o samba4.pp -m samba4.mod<br />
$ semodule -i samba4.pp<br />
<br />
== Step 12: Setup a File Share ==<br />
<br />
The provisioning will create a very simple <tt>/usr/local/samba/etc/smb.conf</tt> file with no non-system shares by<br />
default. For the server to be useful you, will need to update it to<br />
have at least one share. For example:<br />
<br />
[test]<br />
path = /data/test<br />
comment = Test Share<br />
read only = no<br />
<br />
*Note: In older alpha versions of Samba 4, you need to restart Samba to make new shares visible.<br />
<br />
== Step 13: Setup a Printer share ==<br />
<br />
You can share any printers already configured with CUPS, keep in mind that Samba communicates with CUPS via sockets, so you don't need to set any configure any special permissions beyond a listen directive for the CUPS socket.<br />
<br />
=== Basic Print Sharing ===<br />
<br />
# Create a print spool directory, and set the permissions properly. This is where Samba will store temporary files related to print documents:<br />
mkdir /usr/local/samba/var/spool<br />
chmod 1777 /usr/local/samba/var/spool<br />
<br />
# Configure samba to use it, by adding the following to <tt>/usr/local/samba/etc/smb.conf</tt>:<br />
<br />
[printers]<br />
comment = All Printers<br />
path = /usr/local/samba/var/spool<br />
browseable = Yes<br />
read only = No<br />
printable = Yes<br />
<br />
=== Point and Print Drivers ===<br />
<br />
For the sake of convenience, Windows clients can query the server that is sharing a printer for a print driver. To enable this functionality in Samba, we have to create a special <tt>print$</tt> file share.<br />
<br />
# Create the print file share directory, and architecture sub-directories:<br />
<br />
mkdir -p /usr/local/samba/var/print/{COLOR,IA64,W32ALPHA,W32MIPS,W32PPC,W32X86,WIN40,x64}<br />
<br />
# Configure samba to use it, by adding the following to <tt>/usr/local/samba/etc/smb.conf</tt>:<br />
<br />
[print$]<br />
comment = Point and Print Printer Drivers<br />
path = /usr/local/samba/var/print<br />
read only = No<br />
<br />
# Log in as a Domain Administrator on a client computer<br />
# Click Start -> Run '\\samba\'<br />
# In the list of shares, Double-Click 'Printers and Faxes'<br />
# Click File -> Server Properties<br />
# On the Drivers Tab, Click 'Add...', then 'Next'<br />
#:[[Image:SambaServerDrivers.jpg]]<br />
# In the following prompts, choose the driver you would like to install, and click 'Next'<br />
#:[[Image:SambaServerChooseDriver.jpg]]<br />
# Choose the architectures you are installing the drivers for. Be aware if you choose an architecture that the client computer does not have the driver for you will be prompted to provide a disk with the drivers.<br />
#:[[Image:SambaServerChooseArch.jpg]]<br />
# Close the Server Driver Dialog box<br />
# Right-click on the printer the driver is for and choose Properties<br />
# On the Advanced tab, change the Driver drop-down box to the driver you just installed<br />
<br />
== Note: Filesystem Support ==<br />
<br />
This information has been included in the [[Samba_4_OS_Requirements#File_System_Support]]<br />
<br />
= Configure a Windows Client to join a Samba 4 Active Directory =<br />
<br />
Active Directory is a powerful administration service which enables an Administrator to centrally manage a network of Windows 2000, Windows XP Pro, Windows 2003, Windows Vista Business Edition, and Windows 7 Professional (and up) effectively. To test the real Samba capability, we use Windows XP Pro as testing environment (Windows XP Home doesn't include Active Directory functionality and won't work).<br />
<br />
To allow Samba 4 Active Directory or Microsoft Active Directory to manage a computer, we need to join the computer into the active directory.<br />
It involves:<br />
<br />
# Configuring DNS Settings<br />
# Configuring Date & Time and Time Zone<br />
# Joining the domain<br />
<br />
== Step 1: Configure DNS Setting for Windows ==<br />
<br />
Before we configure the DNS settings, verify that you are able to ping the server's IP address. If you are not able to ping the server, double check your IP address, firewall, routing, etc.<br />
<br />
Once you have verified network connectivity between the Samba server and client,<br />
<br />
# Right Click My Network Places, Select Properties<br />
# Right Click Local Area Network, Select Properties<br />
# Double click TCP/IP<br />
# Use a static DNS server, add the Samba server's IP address inside the Primary DNS Server Column.<br />
#:[[Image:Samba4dnsclient.jpg]]<br />
# Press OK on all opened windows.<br />
# Open a command prompt, type 'ping samdom.example.com' (as per your provision).<br />
<br />
If you get replies, then it means that your Windows settings are correct for DNS, and the Samba server's DNS service is working as well.<br />
<br />
== Step 2: Configure Date & Time and Time Zone ==<br />
<br />
Active Directory uses Kerberos as the backend for authentication. Kerberos requires that the system clocks on the client and server be synchronized to within a few seconds of each other. If they are not synchronized, then authentication will fail for apparently no reason.<br />
<br />
=== Configure the Date & Time ===<br />
# Right-Click on the Time display in the system notification area, Select Adjust Date/Time.<br />
# Change the Date and Time so the client matches the server to the minute, and click OK<br />
#:[[Image:Samba4time.jpg]]<br />
<br />
=== Configure the Time Zone ===<br />
# Right-Click on the Time display in the system notification area, Select Adjust Date/Time.<br />
# Click on the Time Zone Tab<br />
# Change the Time Zone to match the Time Zone on the server.<br />
#:[[Image:Samba4timezone.jpg]]<br />
<br />
== Step 3: Joining Windows Clients to the Domain ==<br />
<br />
Now your Windows computer is ready to join the Active Directory (AD) domain,<br />
<br />
As an Administrator:<br />
<br />
# Right Click My Computer -> Properties<br />
# Choose the Computer Name tab, click Change...<br />
# Click option 'Domain', insert SAMDOM.EXAMPLE.COM. If this fails, try SAMDOM.<br />
#:[[Image:Samba4joindomain.jpg]]<br />
# When it requests a username and password, type '''Administrator''' as the username, and '''p4$$word''' as the password.<br />
# You should get a message box stating "Welcome to the SAMDOM.EXAMPLE.COM domain."<br />
# Click OK on this message box and the Properties window, and you will be instructed to restart your computer.<br />
# After restarting, you should be presented with the normal logon dialog.<br />
# Change the domain to SAMDOM and type '''Administrator''' as the username, and '''p4$$word''' as the password.<br />
#:[[Image:Samba4logindomain.jpg]]<br />
<br />
= Viewing Samba 4 Active Directory object from Windows =<br />
<br />
We need install Windows 2003 Adminpak into Windows XP in order to use<br />
GUI tools to manage the domain. Before you begin, make sure that the domain<br />
administrators have administrative rights to control your computer.(To<br />
give any user administrative rights in Windows XP Pro, right click My<br />
Computer, select Manage-> choose Groups-> double click Administrators<br />
and add members from domain into the member list. When you add<br />
members from Active Directory, it will prompt you to enter an<br />
Active Directory username and password).<br />
<br />
== Step 1: Installing Windows Remote Administration Tools onto Windows ==<br />
<br />
=== Windows 7/Vista ===<br />
<br />
#Download the Windows Remote Administration Tools from:<br />
#* http://www.microsoft.com/downloads/details.aspx?FamilyId=9FF6E897-23CE-4A36-B7FC-D52065DE9960&displaylang=en (Vista)<br />
#* http://www.microsoft.com/downloads/details.aspx?FamilyID=7D2F6AD7-656B-4313-A005-4E344E43997D&displaylang=en (Windows 7)<br />
#Follow the "Install RSAT" instructions<br />
<br />
=== Windows XP Pro ===<br />
<br />
==== Administration Tools Pack & Support Tools ====<br />
# Download adminpak and supporttools from:<br />
#* http://www.microsoft.com/downloads/en/details.aspx?FamilyID=86b71a4f-4122-44af-be79-3f101e533d95<br />
#* http://download.microsoft.com/download/3/e/4/3e438f5e-24ef-4637-abd1-981341d349c7/WindowsServer2003-KB892777-SupportTools-x86-ENU.exe<br />
#:If you installed an older version of the adminpak, you'll notice the dial-in tab is missing from property pages. Just follow the link above to get SP2 which does not have this issue.<br />
# Run through the installation.<br />
# Press start->run, type 'dsa.msc', if a window 'active directory users and computers' prompt up, it mean you had install adminpak it successfully. You can also find this at Start>Programs>Administrative Tools, which should have a lot more items now.<br />
# Go to c:\Program Files\Support Tools to check whether the support tools were installed correctly; if yes, then your XP workstation is ready to manage the Samba 4 Active Directory.<br />
<br />
==== Group Policy Management Console ====<br />
# You may also find the Group Policy Management Console useful. You can download it from<br />
#* http://www.microsoft.com/downloads/details.aspx?FamilyId=0A6D4C24-8CBD-4B35-9272-DD3CBFC81887&displaylang=en<br />
#:This is primarily useful when you have larger installs and are managing many machines. You may need to download the .NET Framework first.<br />
<br />
== Step 2: Viewing Samba Active Directory Content ==<br />
<br />
# When logged on as a Domain Administrator, start the Active Directory Users and Computers Snap-In, either by clicking Start -> Programs\Administrative Tools\Active Directory Users and Computers, or by clicking Start -> Run 'dsa.msc'<br />
# Expand the samdom.example.com tree to see existing objects in the domain.<br />
#:[[Image:Samba4dsa.msc.jpg]]<br />
<br />
= Managing Samba 4 Active Directory From a Windows Client =<br />
One of Samba 4's goals is to integrate with (and replace) Active Directory as a system. At this point, if everything has worked correctly you should have an "Administrative Tools" menu under Programs. If, under Administrative Tools you have "Active Directory Users and Computers", that is a very good sign. Most times, if there is a configuration or bug in Samba, the AD Users & Computers (among other interfaces) won't show up as an option. You can run it by hand (Start->Run->dsa.msc) but it's unlikely to work correctly.<br />
<br />
<br />
== Step 1: Adding Users into Samba 4 Active Directory ==<br />
Unlike Samba 3, Samba 4 does not require a local Unix user for each Samba user that is created.<br />
<br />
To create a Samba user, use the following command:<br />
<br />
/usr/local/samba/bin/samba-tool user add USERNAME<br />
<br />
To inspect the allocated user ID and SID, use the following command:<br />
<br />
$ /usr/local/samba/bin/wbinfo --name-to-sid USERNAME<br />
S-1-5-21-4036476082-4153129556-3089177936-1005 SID_USER (1)<br />
<br />
$ /usr/local/samba/bin/wbinfo --sid-to-uid S-1-5-21-4036476082-4153129556-3089177936-1005<br />
3000011<br />
<br />
If you want to change this mapping, then use <tt>ldbedit<tt> on the <tt>/usr/local/samba/private/idmap.ldb</tt>, as shown:<br />
<br />
$ ldbedit -e emacs -H /usr/local/samba/private/idmap.ldb objectsid=S-1-5-21-4036476082-4153129556-3089177936-1005<br />
<br />
*Note: You can replace <tt>emacs</tt> with your editor of choice.<br />
<br />
You will find records that look like this:<br />
<br />
# record 1<br />
dn: CN=S-1-5-21-4036476082-4153129556-3089177936-1005<br />
cn: S-1-5-21-4036476082-4153129556-3089177936-1005<br />
objectClass: sidMap<br />
objectSid: S-1-5-21-4036476082-4153129556-3089177936-1005<br />
type: ID_TYPE_BOTH<br />
xidNumber: 3000011<br />
distinguishedName: CN=S-1-5-21-4036476082-4153129556-3089177936-1005<br />
<br />
If you change the <tt>xidNumber</tt> attribute and save your editor then exit,<br />
then Samba will update the mapping to between the SID and the user<br />
ID. Updating group mappings works in the same way.<br />
<br />
*Note: You can also manage users using the normal Windows AD user management tools.<br />
<br />
= Setting Up Roaming Profiles =<br />
<br />
1. You will need to create a share for the profiles, typically named <tt>profiles</tt>. Edit the <tt>/usr/local/samba/etc/smb.conf</tt> to include:<br />
<br />
[profiles]<br />
path = /usr/local/samba/var/profiles<br />
read only = no<br />
<br />
2. Create the directory above using:<br />
<br />
$ sudo mkdir /usr/local/samba/var/profiles<br />
<br />
3. In Windows, start ''Active Directory Users and Computers'', select all the users, right click, and hit properties<br />
<br />
4. Under the profile tab, in the ''Profile path'', type the path to your share along with %USERNAME% as follows:<br />
<br />
\\sambaserver.samdom.example.com\profiles\%USERNAME%<br />
<br />
5. click OK, logout and login as one of those users. When you logout again, you should see that the profile has been synced onto the samba server.<br />
<br />
*Note: An excellent walk-through on configuring Roaming Profiles and Folder Redirection is available [http://www.grouppolicy.biz/2010/08/best-practice-roaming-profiles-and-folder-redirection-a-k-a-user-virtualization/ here.]<br />
<br />
* For more information on implementing roaming profiles, refer to the [https://wiki.samba.org/index.php/Samba_%26_Windows_Profiles#Implementing_Roaming_Profiles_with_Samba Implementing Roaming Profiles] section of the wiki.<br />
<br />
= Adding Organization Units (OU) Into a Samba Domain = <br />
<br />
The Organizational Unit (OU) is a powerful feature in Active<br />
Directory. This is a type of container which allows you to drag & drop<br />
users and/or computers into it.<br />
<br />
We can link several types of group policies to an OU, and the settings<br />
will push out to all users/computers that sit under the OU. Withing a single domain,<br />
you can have as many OUs and sub-OUs as you'd like. The result is that<br />
it can greatly reduce administrative overhead since you are able to<br />
manage everything via an OU. The implementation of Group Policy will<br />
be discussed in the next chapter.<br />
<br />
Before we create an OU, we must know what one looks like. By default<br />
we can see a sample OU called 'Domain Controllers', which uses a different<br />
icon in the Windows management tools than the 'users' and 'computers'<br />
containers. We can deploy Group Policy to the users or the computers container.<br />
<br />
# To create an OU as the Domain Administrator, click Start -> Run -> dsa.msc<br />
# Right click your domain.<br />
# Select New -> Organizational Unit<br />
# Type 'OU Demo'<br />
# You will see a new OU appear, with the name 'OU Demo'.<br />
# You can drag the user 'demo' into the new OU (Don't move other users! Unless you want to get stuck!).<br />
# Right click 'OU Demo', A sub-OU can be created with New -> Organizational Unit.<br />
<br />
Normally OUs are created according to the department setup of your<br />
organization. Be careful not to confuse Groups and OUs. Groups are<br />
used to control permissions, OUs are used for deploying settings to<br />
all users/computers within the OU.<br />
<br />
= Implementing Group Policies (GPO) in A Samba Domain =<br />
<br />
Samba Active Directory has support for Goup Plicies, and can create<br />
the Goup Plicy on the fly. The basic idea of Goup Plicies is:-<br />
<br />
# Group Policies have two kinds of settings: computers and users.<br />
# Computer settings apply to computers, while user settings apply to users.<br />
# We link the group policy to a particular OU, and the group policy will effect all computers/users under the OU.<br />
# To add a group policy, right click 'OU Demo' OU->properties.<br />
# Choose group policy.<br />
# Press new, and name it as 'GP Demo'.<br />
# Press edit to modify the policy.<br />
# Here will demonstrate how to block users from access to the control panel. Open the tree 'User Configuration'->'Administrative Templates'->'Control Panel'.<br />
# Double click on 'Prohibit access to the Control Panel'.<br />
# Press enabled and then press OK. Now the all users under 'OU Demo' won't able to access to the control panel.<br />
# Make sure that the user 'demo' is inside the 'OU Demo' (You can drag and drop it). <br />
# Logout and login as user 'demo'.<br />
# You'll find user demo is not able to access control panel.<br />
<br />
== Notes ==<br />
:User configuration will take effect once you logout and login.<br />
:Computer configuration will take effect when you restart the computer.<br />
:GPO Password Policies are not read by Samba when assigning passwords, to change the policy that Samba uses you must use '''samba-tool domain passwordsettings'''<br />
<br />
To learn more about managing and implementing organizational units, group policies, and Active Directory, try a web search for Google in Windows 2003 Active Directory implementation.<br />
<br />
= Joining a Windows Domain Controller as an Additional DC in a Domain =<br />
<br />
Once you have a Samba domain controller set up, you can choose to join<br />
additional domain controllers to the domain, whether they be<br />
additional Samba domain controllers, or additional Windows domain<br />
controllers.<br />
<br />
If you wish to join an additional Samba domain controller to a domain,<br />
then please see the [[Samba4/HOWTO/Join a domain as a DC|Joining a domain as a DC]] page. The instructions<br />
on that page are the same for joining Samba to a Windows domain as<br />
they are for joining Samba to an existing Samba domain.<br />
<br />
If you wish to join a new Windows domain controller to a Samba domain,<br />
then you should use the 'dcpromo' tool on the Windows machine. Please<br />
see the normal instructions for installing dcpromo on Windows, with<br />
the exception that you should not check the 'DNS server' option box<br />
when it is offered. Right now you should either use Windows for DNS,<br />
or use Samba and bind9 for DNS. Mixing the two can work, but it is an<br />
advanced topic that is beyond the scope of this howto.<br />
<br />
= Migrating an Existing Samba Domain to Samba =<br />
<br />
It is very likely that you already have a running Samba3 domain on your network. The question is, how do you migrate that domain and all of its users and machines over to a new Samba 4 based domain without having to move every user profile and machine to the new domain? The answer is the [[Samba4/samba-tool/domain/classicupgrade/HOWTO|samba-tool domain classicupgrade]] function.<br />
<br />
= Connecting other services to your new/migrated Active Directory =<br />
<br />
If you finished setting up or migrating to Samba 4, you maybe want to connect other services<br />
to your new Active Directory. Have a look at the [[Samba4/beyond|Beyond Samba]] page.<br />
<br />
= Report Your Success/Failure! =<br />
<br />
Samba, as a replicating domain controller, is still developing rapidly.<br />
We'd like to hear from users about their successes and<br />
failures. We would encourage you to report both your successes and failures<br />
to the [mailto:samba-technical@lists.samba.org samba-technical] mailing list on http://lists.samba.org</div>Gazzonyx