http:///https:///api.php?action=feedcontributions&user=Hortimech&feedformat=atomSambaWiki - User contributions [en]2024-03-19T03:51:05ZUser contributionsMediaWiki 1.39.5https://wiki.samba.org/index.php?title=Windows_User_Home_Folders&diff=19172Windows User Home Folders2024-02-01T09:57:20Z<p>Hortimech: </p>
<hr />
<div>= Introduction =<br />
<br />
Home folders contain files of an individual account. Using Samba, you can share the directories to enable network users to store own files on their home folder on the file server.<br />
<br />
This documentation does not use the Samba built-in <code>[homes]</code> section that dynamically shares the user's home directory using the <code>\\server\''user_name''\</code> path. While this can be helpful in certain scenarios, it has some disadvantages:<br />
* Windows does not support this feature, and certain settings, such as folder redirection in an Active Directory (AD), require a workaround instead and you cannot use the official solution.<br />
* You must create each new user's home directory manually.<br />
* Whilst The <code>[homes]</code> feature is supported on a Samba Active Directory (AD) domain controller (DC), it will not work for Windows users home directories. It will work for Unix home directories, but this setup is not shown here.<br />
<br />
In the following, the directory containing the home folders are shared using the <code>users</code> share name. Each user's home directory is created as a subdirectory on the <code>\\server\users\</code> share, such as, <code>\\server\users\''user_name''</code>. This is the same format used in a Microsoft Windows environment and requires no additional work to set up.<br />
<br />
<br />
<br />
<br />
<br />
= Setting up the Share on the Samba File Server =<br />
<br />
== Using Windows ACLs ==<br />
<br />
Setting extended access control lists (ACL) on the share that hosts home directories enables you to create new users in the <code>Active Directory Users and Computers</code> application without manually creating the user's home folder and setting permissions.<br />
<br />
To create a share, for example, <code>users</code> for hosting the user home folders on a Samba file server: <br />
<br />
* Create a new share. For details, see [[Setting up a Share Using Windows ACLs]]. Set the following permissions:<br />
<br />
<br />
'''On Earlier versions of Samba, you may need to set the follow permissions on the 'Share' tab:'''<br />
<br />
<br />
:* Share permissions:<br />
::{| class="wikitable"<br />
!Principal<br />
!Access<br />
|-<br />
|Domain Users<br />
|Change<br />
|-<br />
|Domain Admins<br />
|Full Control<br />
|}<br />
<br />
<br />
''' Later versions of Samba do not require any modification of the 'Share' tab. If in doubt, try setting the permissions without modifying the 'Share' tab.<br />
<br />
<br />
:* File system permissions on the 'Security' tab of the <code>users</code> share 'Properties':<br />
<br />
::{| class="wikitable"<br />
!Principal<br />
!Access<br />
!Applies to<br />
|-<br />
|Domain Users*<br />
|Read & execute<br />
|This folder only<br />
|-<br />
|CREATOR OWNER<br />
|Full control<br />
|Subfolders and files only<br />
|-<br />
|Domain Admins<br />
|Full control<br />
|This folder, subfolders and files<br />
|}<br />
<br />
::<nowiki>*</nowiki> You can alternatively set other groups, to enable the group members to store their user profile on the share. When using different groups, apply the permissions as displayed for <code>Domain Users</code> in the previous example.<br />
<br />
:: Verify that permission inheritance is disabled on the root of the share. If any permission entry in the <code>Advanced Security Settings</code> window displays a path in the <code>Inherited from</code> column, click the <code>Disable inheritance</code> button. On Windows 7, unselect the <code>Include inheritable permissions from this object's parent</code> check box to set the same setting.<br />
<br />
::[[Image:Home_Folder_File_System_ACLs.png]]<br />
<br />
:: On a Samba share, you can omit the <code>SYSTEM</code> account in the file system ACLs. For details, see [[The SYSTEM Account]].<br />
<br />
These settings enable members of the <code>Domain Admins</code> group to set the user home folder in the <code>Active Directory Users and Computers</code> application, that automatically creates the home folder and sets the correct permissions.<br />
<br />
<br />
<br />
== Using POSIX ACLs ==<br />
<br />
Instead of using Windows access control lists (ACL), you can set up a share using POSIX ACLs on your Samba server. This is useful if you're also supporting linux users, say mounting shares via NFS. The Samba DC then does its best to set up POSIX ACLs which will provide both linux and Windows users with the security restrictions they expect to see. If you use the RSAT tools to set a remote home directory for the user ''my_user'' on a Samba fileserver, the resulting POSIX permissions on the (automatically created) home directory will look something like this:<br />
<br />
root@my_samba_fileserver:/home# getfacl my_user<br />
# file: my_user<br />
# owner: root<br />
# group: root<br />
user::rwx<br />
user:root:rwx<br />
user:my_user:rwx<br />
group::---<br />
group:root:---<br />
group:BUILTIN\\administrators:rwx<br />
group:my_user:rwx<br />
mask::rwx<br />
other::---<br />
default:user::rwx<br />
default:user:root:rwx<br />
default:user:my_user:rwx<br />
default:group::---<br />
default:group:root:---<br />
default:group:BUILTIN\\administrators:rwx<br />
default:group:my_user:rwx<br />
default:mask::rwx<br />
default:other::---<br />
<br />
The ''my_user'' user has complete control over /home/my_user despite root being the primary owner of the folder.<br />
<br />
<br />
{{Imbox<br />
| type = note<br />
| text = When setting up the share on a Samba Active Directory (AD) domain controller (DC), you cannot use POSIX ACLs. On an Samba DC, only shares using extended ACLs are supported. For further details, see [[Setting_up_a_Share_Using_Windows_ACLs#Enable_Extended_ACL_Support_in_the_smb.conf_File|Enable Extended ACL Support in the smb.conf File]]. To set up the share on a Samba AD DC, see [[#Using_Windows_ACLs|Setting up the Home Folder Share on the Samba File Server - Using Windows ACLs]].<br />
}}<br />
<br />
For example, to create the <code>users</code> share: <br />
<br />
* Add the following share configuration section to your <code>smb.conf</code> file:<br />
<br />
[users]<br />
path = /srv/samba/users/<br />
read only = no<br />
force create mode = 0600<br />
force directory mode = 0700<br />
<br />
: For details about the parameters used, see the descriptions in the smb.conf(5) man page.<br />
<br />
: Do not use <code>homes</code> as name of the share. For further details, see [[#Introduction|Introduction]].<br />
<br />
* Create the directory and set the correct permissions:<br />
<br />
# mkdir -p /srv/samba/users/<br />
# chgrp -R "''Domain Users''" /srv/samba/users/<br />
# chmod 2750 /srv/samba/users/<br />
<br />
: In a domain, the <code>Domain Users</code> group is a group, all domain user accounts are member of. Alternatively, or if you are running a non-domain environment, you can set it to any group that exists locally. However, user accounts must be member of this group to access the share.<br />
<br />
* Reload Samba:<br />
<br />
# smbcontrol all reload-config<br />
<br />
= Creating the Home Folder for a New User =<br />
<br />
== Using Windows ACLs ==<br />
<br />
If you are using the <code>Active Directory Users and Computers</code> application, the user's home directory is automatically created and the correct permissions applied when you set the path to the user folder in the application.<br />
<br />
<br />
If you are not using <code>Active Directory Users and Computers</code>, you must create the folder manually and set the correct permissions. For example:<br />
<br />
* Log in to a Windows machine using an account that has permissions to create new folders on the <code>\\server\users\</code> share.<br />
<br />
* Navigate to the <code>\\server\users\</code> share.<br />
<br />
* Create a new home folder for the user.<br />
<br />
* Add the user to the access control list (ACL) of the folder and grant <code>Full control</code> to the user. For details, see [[Setting_up_a_Share_Using_Windows_ACLs#Setting_ACLs_on_a_Folder|Setting ACLs on a Folder]].<br />
<br />
<br />
<br />
== Using POSIX ACLs ==<br />
<br />
When you set up the <code>users</code> share using POSIX access control lists (ACL), you must create the home folder for each new user manually. To create the home folder for the <code>demo</code> user:<br />
<br />
* Create the directory:<br />
<br />
# mkdir /srv/samba/users/demo/<br />
<br />
* Set the following permissions to only enable the <code>demo</code> user to access the directory:<br />
<br />
# chown ''user_name'' /srv/samba/users/demo/<br />
# chmod 700 /srv/samba/users/demo/<br />
<br />
<br />
<br />
<br />
<br />
= Assigning a Home Folder to a User =<br />
<br />
== In an Active Directory ==<br />
<br />
=== Using <code>Active Directory Users and Computers</code> ===<br />
<br />
In an Active Directory, you can use the <code>Active Directory Users and Computers</code> Windows application to set the path to the user home folder and the assigned drive letter. If you do not have the Remote Server Administration Tools (RSAT) installed, see [[Installing RSAT|Installing RSAT]].<br />
<br />
To assign the <code>\\server\users\demo\</code> path as home folder to the <code>demo</code> account:<br />
<br />
* Log in to a computer using an account that is able to edit user accounts.<br />
<br />
* Open the <code>Active Directory Users and Computers</code> application.<br />
<br />
* Navigate to the directory container that contains the <code>demo</code> account.<br />
<br />
* Right-click to the <code>demo</code> user account and select <code>Properties</code>.<br />
<br />
* Select the <code>Profile</code> tab.<br />
<br />
* Select <code>Connect</code>, the drive letter Windows assigns the mapped home folder to, and enter the path to the home folder into the <code>To</code> field.<br />
<br />
:[[Image:ADUC_Set_Home_Folder.png]].<br />
<br />
* Click <code>OK</code>.<br />
<br />
If a warning is displayed when saving the settings that the home folder was not created:<br />
* the permissions on the <code>users</code> share were incorrectly set when you set up the share using Windows access control lists (ACL). To fix the problem, set the permissions described in [[#Using_Windows_ACLs|Using Windows ACLs]].<br />
* you set up the share using POSIX ACL. To fix the problem, create the directory manually. See [[#Using_POSIX_ACLs_2|Creating the Home Folder for a New User - Using POSIX ACLs]].<br />
<br />
<br />
<br />
=== Using a Group Policy Preference ===<br />
<br />
{{:Using_a_Group_Policy_Preference}}<br />
<br />
=== Using <code>ldbedit</code> on a Domain Controller ===<br />
<br />
On a domain controller (DC), for example, to assign the <code>\\server\users\demo</code> path as home folder to the <code>demo</code> account and set the assigned drive letter to <code>H:</code><br />
<br />
* Edit the <code>demo</code>user account:<br />
<br />
# ldbedit -H /usr/local/samba/private/sam.ldb 'sAMAccountName=demo'<br />
<br />
* The accounts attributes are displayed in an editor. Append the following attributes and values to the end of the list:<br />
<br />
homeDrive: H:<br />
homeDirectory: \\server\users\demo\<br />
<br />
* Save the changes.<br />
<br />
The setting is applied the next time the user logs in.<br />
<br />
<br />
<br />
== In an NT4 Domain ==<br />
<br />
In an Samba NT4 domain, to set <code>\\server\users\%U</code> as path to the home folder and to map the drive to the <code>H:</code> drive letter:<br />
<br />
* Add the following parameters to the <code>[global]</code> section in your <code>smb.conf</code> file:<br />
<br />
logon drive = H:<br />
logon home = \\server\users\%U<br />
<br />
: During logging in to the domain member, Samba automatically replaces the <code>%U</code> variable with the session user name. For further details, see the <code>Variable Substitutions</code> section in the <code>smb.conf(5)</code> man page.<br />
<br />
* Reload Samba:<br />
<br />
# smbcontrol all reload-config<br />
<br />
<br />
<br />
== In a Non-domain Environment ==<br />
<br />
=== Using a Windows Professional or Higher Edition ===<br />
<br />
If your Samba server and clients are not part of a domain, set the user home folder mapping in the local user account's properties:<br />
<br />
* Log on to the Windows machine using an account that is member of the local <code>Administrators</code> group.<br />
<br />
* Open the <code>lusrmgr.msc</code> (Local User and Groups) application.<br />
: The <code>lusrmgr.msc</code> application is not available in Windows Home editions.<br />
<br />
* Click <code>Users</code> in the navigation on the left side.<br />
<br />
* Right-click the account you want to assign a home folder to, and select <code>Properties</code><br />
<br />
* Navigate to the <code>Profile</code> tab.<br />
<br />
* Select <code>Connect</code>, the drive letter Windows assigns the mapped home folder to, and enter the path to the home folder into the <code>To</code> field.<br />
<br />
* Click <code>OK</code>.<br />
<br />
You must set the mapping for each user on every Windows client manually.<br />
<br />
<br />
<br />
=== Using Windows Home Edition ===<br />
<br />
Windows Home editions do not provide the necessary application to set the user home folder mapping in the local account properties. Instead each user must map the drive manually:<br />
<br />
* Log on to the Windows machine as the user that should get the home folder mapped<br />
<br />
* Open a command prompt.<br />
<br />
* For example, to map the <code>\\server\users\demo\</code> folder to the <code>H:</code> drive letter, enter:<br />
<br />
> net use H: \\server\users\demo\ /persistent:yes<br />
<br />
The user home folder is automatically connected when the user logs in. To stop the automatic mapping, disconnect the drive. For example:<br />
<br />
> net use H: /delete<br />
<br />
<br />
<br />
<br />
<br />
----<br />
[[Category:Active Directory]]<br />
[[Category:Domain Members]]<br />
[[Category:File Serving]]<br />
[[Category:NT4 Domains]]<br />
[[Category:Standalone Server]]</div>Hortimechhttps://wiki.samba.org/index.php?title=Setting_up_a_Share_Using_Windows_ACLs&diff=19171Setting up a Share Using Windows ACLs2024-02-01T09:00:30Z<p>Hortimech: </p>
<hr />
<div>= Introduction =<br />
<br />
Extended access control lists (ACL) enable you to set permissions on shares, files, and directories using Windows ACLs and applications. Samba supports shares using extended ACLs on:<br />
* Domain members<br />
* Active Directory (AD) domain controllers (DC)<br />
* NT4 primary domain controller (PDC)<br />
* NT4 backup domain controllers (BDC)<br />
* Standalone hosts<br />
<br />
<br />
<br />
<br />
<br />
= Preparing the Host =<br />
<br />
You need to set up Samba before you are able to create a share. Depending on what type of Samba server you require, see:<br />
* [[Setting_up_Samba_as_a_Domain_Member|Setting up Samba as a Domain Member]]<br />
* [[Active_Directory_Domain_Controller|Setting up Samba as AD DC]]<br />
* [[Setting_up_Samba_as_an_NT4_PDC_(Quick_Start)|Setting up Samba as an NT4 PDC (Quick Start)]]<br />
* [[Setting_up_Samba_as_an_NT4_BDC|Setting up Samba as an NT4 BDC]]<br />
* [[Setting_up_Samba_as_a_Standalone_Server|Setting up Samba as a Standalone Server]]<br />
<br />
<br />
<br />
== File System Support ==<br />
<br />
The file system, the share will be created on, must support:<br />
* user and system <code>xattr</code> name spaces.<br />
* extended access control lists (ACL).<br />
<br />
For further details, see [[File_System_Support|File system support]].<br />
<br />
<br />
<br />
== Samba Extended ACL Support ==<br />
<br />
To create a share with extended access control list (ACL) support, the <code>smbd</code> service must have been built with ACL support enabled. A Samba host working as an Active Directory (AD) domain controller (DC), is always enabled with extended ACL support.<br />
<br />
To verify if Samba has been built with ACL support, enter:<br />
<br />
# smbd -b | grep HAVE_LIBACL<br />
HAVE_LIBACL<br />
<br />
If no output is displayed:<br />
* Samba was built using the <code>--with-acl-support=no</code> parameter.<br />
* The Samba <code>configure</code> script was unable to locate the required libraries for ACL support. For details, see [[Package Dependencies Required to Build Samba]].<br />
<br />
<br />
<br />
<br />
<br />
== Enable Extended ACL Support on a Unix domain member ==<br />
<br />
Ideally you have a system that supports [[NFS4_ACL_overview|NFS4 ACLs]]. The following example is for systems like Linux, where you don't have those kind of ACLs. To configure shares using extended access control lists (ACL) on a Unix domain member, you must enable the support in the <code>smb.conf</code> file. To enable extended ACL support globally, add the following settings to the <code>[global]</code> section of your <code>smb.conf</code> file:<br />
<br />
vfs objects = acl_xattr<br />
map acl inherit = yes<br />
# the next line is only required on Samba versions less than 4.9.0<br />
store dos attributes = yes<br />
<br />
{{Imbox<br />
| type = important<br />
| text = On a Samba Active Directory (AD) domain controller (DC), extended ACL support is automatically enabled globally. You must not enable the support manually.<br />
}}<br />
<br />
Alternatively, to enable extended ACL support only for a specific share, add the parameters to the share's section.<br />
<br />
For further details about the parameters, see the <code>smb.conf(5)</code> man page.<br />
<br />
<br />
<br />
<br />
<br />
== Granting the <code>SeDiskOperatorPrivilege</code> Privilege ==<br />
<br />
Only users and groups having the <code>SeDiskOperatorPrivilege</code> privilege granted can configure share permissions.<br />
<br />
{{Imbox<br />
| type = note<br />
| text = Only users or groups that are known to Unix can be used. This means that if you use the winbind 'ad' backend on Unix domain members, you must add a uidNumber attribute to users, or a gidNumber to groups in AD. <br />
}}<br />
<br />
{{Imbox<br />
| type = note<br />
| text = If you use the winbind 'ad' backend on Unix domain members and you add a gidNumber attribute to the <code>Domain Admins</code> group in AD, you will break the mapping in <code>idmap.ldb</code>. <code>Domain Admins</code> is mapped as <code>ID_TYPE_BOTH</code> in <code>idmap.ldb</code>, this is to allow the group to own files in <code>Sysvol</code> on a Samba AD DC. It is suggested you create a new AD group (<code>Unix Admins</code> for instance), give this group a <code>gidNumber</code> attribute and add it to the <code>Administrators</code> group and then, on Unix, use the group wherever you would normally use <code>Domain Admins</code>. <br />
}}<br />
<br />
<br />
If you are using the 'ad' winbind idmap backend, then you should use the 'Unix Admins' group you were advised to create above. However, if you use any other winbind idmap backend (autorid or rid, for instance), then you can use the 'Domain Admins' group.<br />
<br />
<br />
To grant the privilege to the <code>Domain Admins</code> group, enter:<br />
<br />
# net rpc rights grant "SAMDOM\Domain Admins" SeDiskOperatorPrivilege -U "SAMDOM\administrator"<br />
Enter SAMDOM\administrator's password:<br />
Successfully granted rights.<br />
<br />
<br />
To grant the privilege to the <code>Unix Admins</code> group, enter:<br />
<br />
# net rpc rights grant "SAMDOM\Unix Admins" SeDiskOperatorPrivilege -U "SAMDOM\administrator"<br />
Enter SAMDOM\administrator's password:<br />
Successfully granted rights.<br />
<br />
<br />
{{Imbox<br />
| type = note<br />
| text = It is recommended to grant the privilege to a group instead of individual accounts. This enables you to add and revoke the privilege by updating the group membership.<br />
}}<br />
<br />
To list all users and groups having the <code>SeDiskOperatorPrivilege</code> privilege granted, enter:<br />
<br />
# net rpc rights list privileges SeDiskOperatorPrivilege -U "SAMDOM\administrator"<br />
Enter administrator's password:<br />
SeDiskOperatorPrivilege:<br />
BUILTIN\Administrators<br />
SAMDOM\Unix Admins<br />
<br />
{{Imbox<br />
| type = important<br />
| text = You need to grant the <code>SeDiskOperatorPrivilege</code> privilege on the Samba server that holds the share.<br />
}}<br />
<br />
<br />
<br />
<br />
<br />
= Adding a Share =<br />
<br />
To share the <code>/srv/samba/Demo/</code> directory using the <code>Demo</code> share name:<br />
<br />
* As the <code>root</code> user, create the directory:<br />
<br />
# mkdir -p /srv/samba/Demo/<br />
<br />
* To enable accounts other than the domain user <code>Administrator</code> to set permissions on Windows, grant <code>Full control</code> (<code>rwx</code>) to the user or group you granted the <code>SeDiskOperatorPrivilege</code> privilege. For example (if using the 'ad' backend):<br />
<br />
# chown root:"Unix Admins" /srv/samba/Demo/<br />
# chmod 0770 /srv/samba/Demo/<br />
<br />
* Otherwise for any other backend:<br />
<br />
# chown root:"Domain Admins" /srv/samba/Demo/<br />
# chmod 0770 /srv/samba/Demo/<br />
<br />
* Add the <code>[Demo]</code> share definition to your <code>smb.conf</code> file:<br />
<br />
[Demo]<br />
path = /srv/samba/Demo/<br />
read only = no<br />
<br />
: Further share-specific settings and file system permissions are set using the Windows utilities.<br />
<br />
<br />
:{{Imbox<br />
| type = note<br />
| text = If you set the shares permissions from Windows (The recommended way), you can add the line <code>'acl_xattr:ignore system acls = yes'</code> to your share. If the line is added, Samba will ignore the standard Unix system ACL's (ugo). Once the line is added, running <code>setfacl</code> on the shares directory will not show any permission modifications you may have made from Windows. '''You must not add this line until you have set up the share permissions from Windows, otherwise you may find that you are denied permission to change the permissions from Windows.'''. Only add the line if you will only connect to share via Samba.<br />
}}<br />
<br />
<br />
:{{Imbox<br />
| type = important<br />
| text = Do not set <code>ANY</code> additional share parameters, such as <code>force user</code> or <code>valid users</code>. Adding them to the share definition can prevent you from configuring or using the share.<br />
}}<br />
<br />
<br />
<br />
<br />
<br />
* Reload the Samba configuration:<br />
<br />
# smbcontrol all reload-config<br />
<br />
= Setting Share Permissions and ACLs =<br />
<br />
When you configure a share with extended access control lists (ACL) support, you set the share permissions using Windows utilities instead of adding parameters to the share section in the <code>smb.conf</code> file.<br />
<br />
To set permissions and ACLs on the <code>Demo</code> share:<br />
<br />
* Log on to a Windows host using an account that has the <code>SeDiskOperatorPrivilege</code> privilege granted. e.g. <code>SAMDOM\Administrator</code> or <code>SAMDOM\john</code> where <code>john</code> is a member of <code>Unix Admins</code>.<br />
<br />
* Click <code>Start</code>, enter <code>Computer Management</code>, and start the application.<br />
<br />
* Select <code>Action</code> / <code>Connect to another computer</code>.<br />
<br />
* Enter the name of the Samba host and click <code>OK</code> to connect the console to the host.<br />
<br />
* Open the <code>System Tools</code> / <code>Shared Folders</code> / <code>Shares</code> menu entry.<br />
<br />
:[[Image:Computer_Management_Shares.png]]<br />
<br />
<br />
<br />
<br />
* Right-click to the share and select <code>Properties</code>.<br />
<br />
* Select the <code>Share Permissions</code> tab and check the share permissions, you need to see just <code>Everyone</code>. For example:<br />
:[[Image:share.png]]<br />
<br />
{{Imbox<br />
| type = important<br />
| text = If the permissions are as above, do not change anything, if not, change it to just allow <code>Everyone</code> : <code>Full Control, Change and Read</code>. You only make changes to the <code>Security</code> tab.<br />
}}<br />
<br />
: Samba stores the share tab permissions in the <code>/usr/local/samba/var/locks/share_info.tdb</code> database.<br />
<br />
<br />
<br />
<br />
* Select the <code>Security</code> tab.<br />
<br />
* Click the <code>Edit</code> button and set the file system ACLs on the share's root directory. For example:<br />
<br />
:[[Image:Demo_Share_Security.png]]<br />
<br />
: For details about using the <code>SYSTEM</code> account on a Samba share see [[The SYSTEM Account]].<br />
<br />
: For details where the ACLs are stored, see [[#File_System_ACLs_in_the_Back_End|File System ACLs in the Back End]].<br />
<br />
* Click the <code>Add</code> button.<br />
<br />
* Click <code>Advanced</code> button<br />
<br />
* Click <code>Find Now</code><br />
<br />
* Select a user or group from the list, <code>Domain Users</code> for instance.<br />
<br />
* Click <code>OK</code><br />
<br />
* Click <code>OK</code><br />
<br />
* Select permissions to grant, <code>Full control</code> for instance.<br />
<br />
* A windows security box should open, asking if you want to continue, Click <code>Yes</code><br />
<br />
* If you check the list of <code>Group or user names</code>, you should find <code>Domain Users</code> listed<br />
<br />
* Click <code>OK</code> to close the <code>Permissions for Demo</code> window.<br />
<br />
* Click <code>OK</code> to store the updated settings.<br />
<br />
For further details about configuring share permissions and ACLs, see the Windows documentation.<br />
<br />
<br />
<br />
<br />
<br />
= Setting ACLs on a Folder =<br />
<br />
To set file system permissions on a folder located on a share that uses extended access control lists (ACL):<br />
<br />
* Log on to a Windows host using an account that has <code>Full control</code> on the folder you want to modify the file system ACLs.<br />
<br />
* Navigate to the folder.<br />
<br />
* Right-click to the folder and select <code>Properties</code>.<br />
<br />
* Select the <code>Security</code> tab and click the <code>Edit</code> button.<br />
<br />
* Set the permission. For example:<br />
<br />
:[[Image:Folder_Permissions.png]]<br />
<br />
: For details about using the <code>SYSTEM</code> account on a Samba share see [[The SYSTEM Account]].<br />
<br />
: For details where the ACLs are stored, see [[#File_System_ACLs_in_the_Back_End|File System ACLs in the Back End]].<br />
<br />
* Click <code>OK</code> to close the <code>Permissions for Folder</code> window.<br />
<br />
* Click <code>OK</code> to store the updated settings.<br />
<br />
For further details about setting ACLs, see the Windows documentation.<br />
<br />
<br />
<br />
<br />
<br />
= File System ACLs in the Back End =<br />
<br />
Samba stores the file system permissions in extended file system access control lists (ACL) and in an extended attribute. For example:<br />
<br />
* To list the extended ACLs of the <code>/srv/samba/Demo/</code> directory, enter:<br />
<br />
# getfacl /srv/samba/Demo/<br />
# file: srv/samba/Demo/<br />
# owner: root<br />
# group: root<br />
user::rwx<br />
user:root:rwx<br />
group::---<br />
group:root:---<br />
group:domain\040users:rwx<br />
group:unix\040admins:rwx<br />
mask::rwx<br />
other::---<br />
default:user::rwx<br />
default:user:root:rwx<br />
default:group::---<br />
default:group:root:---<br />
default:group:domain\040users:rwx<br />
default:group:unix\040admins:rwx<br />
default:mask::rwx<br />
default:other::---<br />
<br />
* To list the <code>security.NTACL</code> extended attribute of the <code>/srv/samba/Demo/</code> directory, enter:<br />
<br />
# getfattr -n security.NTACL -d /srv/samba/Demo/<br />
# file: srv/samba/Demo/<br />
security.NTACL=0sBAAEAAAAAgAEAAIAAQC4zK0lHchKFvwXwbPR/h8P8sXMj5dNIT5QQuWsYwO3RAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcG9zaXhfYWNsAEbGxuGu39MBuiZRk2pYxeL5ZWc4au0ikqRAk53MkjVd2b4quyk2WwcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEABJy0AAAA0AAAAAAAAADsAAAAAQUAAAAAAAUVAAAASSVmaZneO8cxOHk/9AEAAAEFAAAAAAAFFQAAAEklZmmZ3jvHMTh5P0oIAAACAMQABwAAAAALFACpABIAAQEAAAAAAAEAAAAAAAAUAAAAEAABAQAAAAAAAQAAAAAACxQA/wEfAAEBAAAAAAADAAAAAAALFACpABIAAQEAAAAAAAMBAAAAAAMkAP8BHwABBQAAAAAABRUAAABJJWZpmd47xzE4eT9KCAAAAAAkAP8BHwABBQAAAAAABRUAAABJJWZpmd47xzE4eT/0AQAAAAMkAL8BEwABBQAAAAAABRUAAABJJWZpmd47xzE4eT8BAgAA<br />
<br />
The previous example of file system ACLs and the extended attribute is mapped to the following Windows ACLs:<br />
<br />
{| class="wikitable"<br />
!Principal<br />
!Permissions<br />
!Applies to<br />
|-<br />
|Domain Users (SAMDOM\Domain Users)<br />
|Modify, Read & execute, List folder contents, Read, Write<br />
|(This folder, subfolders and files)<br />
|-<br />
|Unix Admins (SAMDOM\Unix Admins)<br />
|Full control<br />
|(This folder, subfolders and files)<br />
|}<br />
<br />
* To get the ACL in a more readable form, enter:<br />
<br />
# samba-tool ntacl get /usr/local/samba/var/locks/sysvol --as-sddl<br />
# O:BAG:SYD:PAI(A;OICIIO;WOWDGRGWGX;;;CO)(A;OICIIO;GRGX;;;AU)(A;;0x001200a9;;;AU)(A;OICIIO;GA;;;SY)(A;;0x001f01ff;;;SY)(A;OICIIO;WOWDGRGWGX;;;BA)(A;;0x001e01bf;;;BA)(A;OICIIO;GRGX;;;SO)(A;;0x001200a9;;;SO)<br />
<br />
<br />
<br />
<br />
= Troubleshooting = <br />
<br />
For troubleshooting, see:<br />
* [[Troubleshooting_Samba_Domain_Members|Troubleshooting Samba Domain Members]]<br />
* [[Samba_AD_DC_Troubleshooting|Samba AD DC Troubleshooting]]<br />
<br />
<br />
<br />
<br />
<br />
----<br />
[[Category:Active Directory]]<br />
[[Category:Domain Members]]<br />
[[Category:File Serving]]<br />
[[Category:NT4 Domains]]</div>Hortimechhttps://wiki.samba.org/index.php?title=Bidirectional_Rsync/Unison_based_SysVol_replication_workaround&diff=19149Bidirectional Rsync/Unison based SysVol replication workaround2024-01-01T08:13:13Z<p>Hortimech: /* Setup Unison defaults running parameters */</p>
<hr />
<div>= Introduction =<br />
Samba AD currently doesn't provide support for SysVol replication. To achieve this important feature in a Multi-DC environment, until it's implemented, workarounds are necessary to keep it in sync. This HowTo provides a basic workaround solution based on rsync and unison.<br />
<br />
= Information on unison + rsync replication =<br />
<br />
This HowTo describes a solution for SysVol replication, that is based on rsync and unison. As Compare to the rsync method, it is bidirectional. This howto only covers a two DC setup.<br />
<br />
It has the following advantages: <br />
* Quick setup<br />
* Configuration is very easy<br />
* Can work with windows (Please add in)<br />
<br />
We will use rsync through a SSH tunnel.<br />
<br />
= Setup the SysVol replication =<br />
<br />
Some assumptions:<br />
You are running all commands as root.<br />
rsync location /usr/bin/rsync<br />
sysvol is located at /var/lib/samba/sysvol on both DC1 and DC2<br />
unison location /usr/bin/unison<br />
The first DC is DC1<br />
The second DC is DC2<br />
sysvolsync log location /var/log/sysvol-sync.log<br />
<br />
Change the paths if your setup is different.<br />
<br />
=== Setup on the Domain Controller with the PDC Emulator FSMO role ===<br />
* Install rsync by using your package manager or compile from source. Make sure, that you use a version that supports extended ACLs!<br />
* You don't need to setup the rsync server.<br />
* Install unison by using your package manager or compile from source. (On Gentoo you need to do <code>eselect unison</code> to create the link)<br />
<br />
==== Creating SSH Public Key and ssh-copy to DC2====<br />
ssh-keygen -t rsa<br />
ssh-copy-id -i ~/.ssh/id_rsa.pub root@DC2<br />
<br />
You can try to access DC2 via ssh <br />
ssh DC2<br />
<br />
==== Setup ssh Control ====<br />
If the remote system enforces rate limits on incoming ssh connections, unison will fail if you try to run it this way.<br />
So we create the first ssh connection as a controlpath file in the location specified, all subsequent connections will reuse on the first connection.<br />
<br />
mkdir ~/.ssh/ctl<br />
cat << EOF > ~/.ssh/ctl/config<br />
Host *<br />
ControlMaster auto<br />
ControlPath ~/.ssh/ctl/%h_%p_%r<br />
ControlPersist 1<br />
EOF<br />
<br />
==== Setup Sysvolsync Log files ====<br />
Do the following on DC1 so that you can check what happens during the sync.<br />
Please include this file into logrotate as the log size is not controlled.<br />
<br />
touch /var/log/sysvol-sync.log<br />
chmod 640 /var/log/sysvol-sync.log<br />
<br />
==== Setup Unison defaults running parameters ====<br />
Please run the following on DC1 <br />
<br />
install -o root -g root -m 0750 -d /root/.unison<br />
cat << EOF > /root/.unison/default.prf<br />
# Unison preferences file<br />
# Roots of the synchronization<br />
#<br />
# copymax & maxthreads params were set to 1 for easier troubleshooting.<br />
# Have to experiment to see if they can be increased again.<br />
root = /var/lib/samba<br />
# Note that 2 x / behind DC2, it is required<br />
root = ssh://root@DC2//var/lib/samba <br />
# <br />
# Paths to synchronize<br />
path = sysvol<br />
#<br />
#ignore = Path stats ## ignores /var/www/stats<br />
auto=true<br />
batch=true<br />
perms=0<br />
rsync=true<br />
maxthreads=1<br />
retry=3<br />
confirmbigdeletes=false<br />
servercmd=/usr/bin/unison<br />
copythreshold=0<br />
copyprog = /usr/bin/rsync -XAavz --rsh='ssh -p 22' --inplace --compress<br />
copyprogrest = /usr/bin/rsync -XAavz --rsh='ssh -p 22' --partial --inplace --compress<br />
#copyquoterem = true<br />
copymax = 1<br />
logfile = /var/log/sysvol-sync.log<br />
EOF<br />
<br />
=== Setup SysVol on DC2 ===<br />
* On DC2 Install rsync by using your package manager or compile from source. Make sure, that you use a version that supports extended ACLs!<br />
* On DC2 Install unison by using your package manager or compile from source. (On Gentoo you need to do <code>eselect unison</code> to create the link)<br />
* Make sure, that you have [[Joining_a_Samba_DC_to_an_Existing_Active_Directory#Built-in_User_.26_Group_ID_Mappings|identical IDs of built-in groups on all DCs]].<br />
<br />
<br />
== 1st Trial == <br />
You now use rsync to create the directory structure with extended attributes<br />
Then the unison setup will only copy the extended attributes on files.<br />
<br />
<BR>Please make a '''backup''' of your sysvol, just in case, this is because there is no <code>dry-run</code><br />
<br />
/usr/bin/rsync -XAavz --log-file /var/log/sysvol-sync.log --delete-after -f"+ */" -f"- *" /var/lib/samba/sysvol root@DC2:/var/lib/samba && /usr/bin/unison<br />
<br />
:'''Note: The path on DC2 is just /var/lib/samba which is different from DC1, it is by design, there is nothing wrong!'''<br />
<br />
== Add to Crontab on DC1 ==<br />
On DC1 run the following:<br />
crontab -e <br />
*/5 * * * * /usr/bin/unison -silent<br />
<br />
= When you try to resync the folder =<br />
:'''Warning: Please follow the steps below OR you can end up with an empty sysvol folder.'''<br />
# Disable Cron on DC1, like Add a "#" on the line with <code>crontab -e</code><br />
# Check if rsync or unison are currently running in <code>ps -aux</code> if yes, wait for it to finish OR kill it (if it is zombie)<br />
# Remove the hash files on both DC1 and DC2 on <code>/root/.unison</code><br />
# Now check your sysvol and resync<br />
# Confirm that everything is ok again<br />
# Re-enable the cron on DC1 again<br />
<br />
= FAQ =<br />
<br />
* How can I do this on windows?<br />
** I don't have an answer, please post on the mailing list<br />
<br />
<br />
* What to do if I've more than two DC's?<br />
** In Theory, We would just make more cron jobs on DC1 and the complete sync will be perform next sync to all server. Follow below steps:<br />
:# Copy '''default.prf''' to another file called, eg: '''root1.prf'''<br />
:# Open '''root1.prf''' and named '''root = ...''' line to '''root1 = ...''' and save the file<br />
:# Repeat step 1 and 2 for all DCs <br />
:# Change cronjob to:<br />
* * * * * /usr/bin/unison root1 -silent<br />
* * * * * /usr/bin/unison root2 -silent<br />
and so on.<br />
<br />
<br />
* Why can't I simply use a distributed filesystem like GlusterFS, Lustre, etc. for SysVol?<br />
** A cluster file system with Samba requires CTDB to be able to do it safely. And CTDB and AD DC are incompatible.<br />
<br />
<br />
<br />
<br />
<br />
----<br />
[[Category:Active Directory]]</div>Hortimechhttps://wiki.samba.org/index.php?title=Setting_up_a_Share_Using_Windows_ACLs&diff=19144Setting up a Share Using Windows ACLs2023-12-13T10:01:16Z<p>Hortimech: </p>
<hr />
<div>= Introduction =<br />
<br />
Extended access control lists (ACL) enable you to set permissions on shares, files, and directories using Windows ACLs and applications. Samba supports shares using extended ACLs on:<br />
* Domain members<br />
* Active Directory (AD) domain controllers (DC)<br />
* NT4 primary domain controller (PDC)<br />
* NT4 backup domain controllers (BDC)<br />
* Standalone hosts<br />
<br />
<br />
<br />
<br />
<br />
= Preparing the Host =<br />
<br />
You need to set up Samba before you are able to create a share. Depending on what type of Samba server you require, see:<br />
* [[Setting_up_Samba_as_a_Domain_Member|Setting up Samba as a Domain Member]]<br />
* [[Active_Directory_Domain_Controller|Setting up Samba as AD DC]]<br />
* [[Setting_up_Samba_as_an_NT4_PDC_(Quick_Start)|Setting up Samba as an NT4 PDC (Quick Start)]]<br />
* [[Setting_up_Samba_as_an_NT4_BDC|Setting up Samba as an NT4 BDC]]<br />
* [[Setting_up_Samba_as_a_Standalone_Server|Setting up Samba as a Standalone Server]]<br />
<br />
<br />
<br />
== File System Support ==<br />
<br />
The file system, the share will be created on, must support:<br />
* user and system <code>xattr</code> name spaces.<br />
* extended access control lists (ACL).<br />
<br />
For further details, see [[File_System_Support|File system support]].<br />
<br />
<br />
<br />
== Samba Extended ACL Support ==<br />
<br />
To create a share with extended access control list (ACL) support, the <code>smbd</code> service must have been built with ACL support enabled. A Samba host working as an Active Directory (AD) domain controller (DC), is always enabled with extended ACL support.<br />
<br />
To verify if Samba has been built with ACL support, enter:<br />
<br />
# smbd -b | grep HAVE_LIBACL<br />
HAVE_LIBACL<br />
<br />
If no output is displayed:<br />
* Samba was built using the <code>--with-acl-support=no</code> parameter.<br />
* The Samba <code>configure</code> script was unable to locate the required libraries for ACL support. For details, see [[Package Dependencies Required to Build Samba]].<br />
<br />
<br />
<br />
<br />
<br />
== Enable Extended ACL Support on a Unix domain member ==<br />
<br />
Ideally you have a system that supports [[NFS4_ACL_overview|NFS4 ACLs]]. The following example is for systems like Linux, where you don't have those kind of ACLs. To configure shares using extended access control lists (ACL) on a Unix domain member, you must enable the support in the <code>smb.conf</code> file. To enable extended ACL support globally, add the following settings to the <code>[global]</code> section of your <code>smb.conf</code> file:<br />
<br />
vfs objects = acl_xattr<br />
map acl inherit = yes<br />
# the next line is only required on Samba versions less than 4.9.0<br />
store dos attributes = yes<br />
<br />
{{Imbox<br />
| type = important<br />
| text = On a Samba Active Directory (AD) domain controller (DC), extended ACL support is automatically enabled globally. You must not enable the support manually.<br />
}}<br />
<br />
Alternatively, to enable extended ACL support only for a specific share, add the parameters to the share's section.<br />
<br />
For further details about the parameters, see the <code>smb.conf(5)</code> man page.<br />
<br />
<br />
<br />
<br />
<br />
== Granting the <code>SeDiskOperatorPrivilege</code> Privilege ==<br />
<br />
Only users and groups having the <code>SeDiskOperatorPrivilege</code> privilege granted can configure share permissions.<br />
<br />
{{Imbox<br />
| type = note<br />
| text = Only users or groups that are known to Unix can be used. This means that if you use the winbind 'ad' backend on Unix domain members, you must add a uidNumber attribute to users, or a gidNumber to groups in AD. <br />
}}<br />
<br />
{{Imbox<br />
| type = note<br />
| text = If you use the winbind 'ad' backend on Unix domain members and you add a gidNumber attribute to the <code>Domain Admins</code> group in AD, you will break the mapping in <code>idmap.ldb</code>. <code>Domain Admins</code> is mapped as <code>ID_TYPE_BOTH</code> in <code>idmap.ldb</code>, this is to allow the group to own files in <code>Sysvol</code> on a Samba AD DC. It is suggested you create a new AD group (<code>Unix Admins</code> for instance), give this group a <code>gidNumber</code> attribute and add it to the <code>Administrators</code> group and then, on Unix, use the group wherever you would normally use <code>Domain Admins</code>. <br />
}}<br />
<br />
<br />
If you are using the 'ad' winbind idmap backend, then you should use the 'Unix Admins' group you were advised to create above. However, if you use any other winbind idmap backend (autorid or rid, for instance), then you can use the 'Domain Admins' group.<br />
<br />
<br />
To grant the privilege to the <code>Domain Admins</code> group, enter:<br />
<br />
# net rpc rights grant "SAMDOM\Domain Admins" SeDiskOperatorPrivilege -U "SAMDOM\administrator"<br />
Enter SAMDOM\administrator's password:<br />
Successfully granted rights.<br />
<br />
<br />
To grant the privilege to the <code>Unix Admins</code> group, enter:<br />
<br />
# net rpc rights grant "SAMDOM\Unix Admins" SeDiskOperatorPrivilege -U "SAMDOM\administrator"<br />
Enter SAMDOM\administrator's password:<br />
Successfully granted rights.<br />
<br />
<br />
{{Imbox<br />
| type = note<br />
| text = It is recommended to grant the privilege to a group instead of individual accounts. This enables you to add and revoke the privilege by updating the group membership.<br />
}}<br />
<br />
To list all users and groups having the <code>SeDiskOperatorPrivilege</code> privilege granted, enter:<br />
<br />
# net rpc rights list privileges SeDiskOperatorPrivilege -U "SAMDOM\administrator"<br />
Enter administrator's password:<br />
SeDiskOperatorPrivilege:<br />
BUILTIN\Administrators<br />
SAMDOM\Unix Admins<br />
<br />
{{Imbox<br />
| type = important<br />
| text = You need to grant the <code>SeDiskOperatorPrivilege</code> privilege on the Samba server that holds the share.<br />
}}<br />
<br />
<br />
<br />
<br />
<br />
= Adding a Share =<br />
<br />
To share the <code>/srv/samba/Demo/</code> directory using the <code>Demo</code> share name:<br />
<br />
* As the <code>root</code> user, create the directory:<br />
<br />
# mkdir -p /srv/samba/Demo/<br />
<br />
* To enable accounts other than the domain user <code>Administrator</code> to set permissions on Windows, grant <code>Full control</code> (<code>rwx</code>) to the user or group you granted the <code>SeDiskOperatorPrivilege</code> privilege. For example (if using the 'ad' backend):<br />
<br />
# chown root:"Unix Admins" /srv/samba/Demo/<br />
# chmod 0770 /srv/samba/Demo/<br />
<br />
* Otherwise for any other backend:<br />
<br />
# chown root:"Domain Admins" /srv/samba/Demo/<br />
# chmod 0770 /srv/samba/Demo/<br />
<br />
* Add the <code>[Demo]</code> share definition to your <code>smb.conf</code> file:<br />
<br />
[Demo]<br />
path = /srv/samba/Demo/<br />
read only = no<br />
<br />
: Further share-specific settings and file system permissions are set using the Windows utilities.<br />
<br />
<br />
:{{Imbox<br />
| type = note<br />
| text = If you set the shares permissions from Windows (The recommended way), you can add the line <code>'acl_xattr:ignore system acls = yes'</code> to your share. If the line is added, Samba will ignore the standard Unix system ACL's (ugo). Once the line is added, running <code>setfacl</code> on the shares directory will not show any permission modifications you may have made from Windows. '''You must not add this line until you have set up the share permissions from Windows, otherwise you may find that you are denied permission to change the permissions from Windows.'''. Only add the line if you will only connect to share via Samba.<br />
}}<br />
<br />
<br />
:{{Imbox<br />
| type = important<br />
| text = Do not set <code>ANY</code> additional share parameters, such as <code>force user</code> or <code>valid users</code>. Adding them to the share definition can prevent you from configuring or using the share.<br />
}}<br />
<br />
<br />
<br />
<br />
<br />
* Reload the Samba configuration:<br />
<br />
# smbcontrol all reload-config<br />
<br />
= Setting Share Permissions and ACLs =<br />
<br />
When you configure a share with extended access control lists (ACL) support, you set the share permissions using Windows utilities instead of adding parameters to the share section in the <code>smb.conf</code> file.<br />
<br />
To set permissions and ACLs on the <code>Demo</code> share:<br />
<br />
* Log on to a Windows host using an account that has the <code>SeDiskOperatorPrivilege</code> privilege granted. e.g. <code>SAMDOM\Administrator</code> or <code>SAMDOM\john</code> where <code>john</code> is a member of <code>Unix Admins</code>.<br />
<br />
* Click <code>Start</code>, enter <code>Computer Management</code>, and start the application.<br />
<br />
* Select <code>Action</code> / <code>Connect to another computer</code>.<br />
<br />
* Enter the name of the Samba host and click <code>OK</code> to connect the console to the host.<br />
<br />
* Open the <code>System Tools</code> / <code>Shared Folders</code> / <code>Shares</code> menu entry.<br />
<br />
:[[Image:Computer_Management_Shares.png]]<br />
<br />
<br />
<br />
<br />
* Right-click to the share and select <code>Properties</code>.<br />
<br />
* Select the <code>Share Permissions</code> tab and check the share permissions, you need to see <code>Everyone</code>. For example:<br />
:[[Image:share.png]]<br />
<br />
{{Imbox<br />
| type = important<br />
| text = If the permissions are as above, you do not need to change anything, if not, change it to just allow <code>Everyone</code> : <code>Full Control, Change and Read</code>. You should only need to make changes to the <code>Security</code> tab.<br />
}}<br />
<br />
: Samba stores the share tab permissions in the <code>/usr/local/samba/var/locks/share_info.tdb</code> database.<br />
<br />
<br />
<br />
<br />
* Select the <code>Security</code> tab.<br />
<br />
* Click the <code>Edit</code> button and set the file system ACLs on the share's root directory. For example:<br />
<br />
:[[Image:Demo_Share_Security.png]]<br />
<br />
: For details about using the <code>SYSTEM</code> account on a Samba share see [[The SYSTEM Account]].<br />
<br />
: For details where the ACLs are stored, see [[#File_System_ACLs_in_the_Back_End|File System ACLs in the Back End]].<br />
<br />
* Click the <code>Add</code> button.<br />
<br />
* Click <code>Advanced</code> button<br />
<br />
* Click <code>Find Now</code><br />
<br />
* Select a user or group from the list, <code>Domain Users</code> for instance.<br />
<br />
* Click <code>OK</code><br />
<br />
* Click <code>OK</code><br />
<br />
* Select permissions to grant, <code>Full control</code> for instance.<br />
<br />
* A windows security box should open, asking if you want to continue, Click <code>Yes</code><br />
<br />
* If you check the list of <code>Group or user names</code>, you should find <code>Domain Users</code> listed<br />
<br />
* Click <code>OK</code> to close the <code>Permissions for Demo</code> window.<br />
<br />
* Click <code>OK</code> to store the updated settings.<br />
<br />
For further details about configuring share permissions and ACLs, see the Windows documentation.<br />
<br />
<br />
<br />
<br />
<br />
= Setting ACLs on a Folder =<br />
<br />
To set file system permissions on a folder located on a share that uses extended access control lists (ACL):<br />
<br />
* Log on to a Windows host using an account that has <code>Full control</code> on the folder you want to modify the file system ACLs.<br />
<br />
* Navigate to the folder.<br />
<br />
* Right-click to the folder and select <code>Properties</code>.<br />
<br />
* Select the <code>Security</code> tab and click the <code>Edit</code> button.<br />
<br />
* Set the permission. For example:<br />
<br />
:[[Image:Folder_Permissions.png]]<br />
<br />
: For details about using the <code>SYSTEM</code> account on a Samba share see [[The SYSTEM Account]].<br />
<br />
: For details where the ACLs are stored, see [[#File_System_ACLs_in_the_Back_End|File System ACLs in the Back End]].<br />
<br />
* Click <code>OK</code> to close the <code>Permissions for Folder</code> window.<br />
<br />
* Click <code>OK</code> to store the updated settings.<br />
<br />
For further details about setting ACLs, see the Windows documentation.<br />
<br />
<br />
<br />
<br />
<br />
= File System ACLs in the Back End =<br />
<br />
Samba stores the file system permissions in extended file system access control lists (ACL) and in an extended attribute. For example:<br />
<br />
* To list the extended ACLs of the <code>/srv/samba/Demo/</code> directory, enter:<br />
<br />
# getfacl /srv/samba/Demo/<br />
# file: srv/samba/Demo/<br />
# owner: root<br />
# group: root<br />
user::rwx<br />
user:root:rwx<br />
group::---<br />
group:root:---<br />
group:domain\040users:rwx<br />
group:unix\040admins:rwx<br />
mask::rwx<br />
other::---<br />
default:user::rwx<br />
default:user:root:rwx<br />
default:group::---<br />
default:group:root:---<br />
default:group:domain\040users:rwx<br />
default:group:unix\040admins:rwx<br />
default:mask::rwx<br />
default:other::---<br />
<br />
* To list the <code>security.NTACL</code> extended attribute of the <code>/srv/samba/Demo/</code> directory, enter:<br />
<br />
# getfattr -n security.NTACL -d /srv/samba/Demo/<br />
# file: srv/samba/Demo/<br />
security.NTACL=0sBAAEAAAAAgAEAAIAAQC4zK0lHchKFvwXwbPR/h8P8sXMj5dNIT5QQuWsYwO3RAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcG9zaXhfYWNsAEbGxuGu39MBuiZRk2pYxeL5ZWc4au0ikqRAk53MkjVd2b4quyk2WwcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEABJy0AAAA0AAAAAAAAADsAAAAAQUAAAAAAAUVAAAASSVmaZneO8cxOHk/9AEAAAEFAAAAAAAFFQAAAEklZmmZ3jvHMTh5P0oIAAACAMQABwAAAAALFACpABIAAQEAAAAAAAEAAAAAAAAUAAAAEAABAQAAAAAAAQAAAAAACxQA/wEfAAEBAAAAAAADAAAAAAALFACpABIAAQEAAAAAAAMBAAAAAAMkAP8BHwABBQAAAAAABRUAAABJJWZpmd47xzE4eT9KCAAAAAAkAP8BHwABBQAAAAAABRUAAABJJWZpmd47xzE4eT/0AQAAAAMkAL8BEwABBQAAAAAABRUAAABJJWZpmd47xzE4eT8BAgAA<br />
<br />
The previous example of file system ACLs and the extended attribute is mapped to the following Windows ACLs:<br />
<br />
{| class="wikitable"<br />
!Principal<br />
!Permissions<br />
!Applies to<br />
|-<br />
|Domain Users (SAMDOM\Domain Users)<br />
|Modify, Read & execute, List folder contents, Read, Write<br />
|(This folder, subfolders and files)<br />
|-<br />
|Unix Admins (SAMDOM\Unix Admins)<br />
|Full control<br />
|(This folder, subfolders and files)<br />
|}<br />
<br />
* To get the ACL in a more readable form, enter:<br />
<br />
# samba-tool ntacl get /usr/local/samba/var/locks/sysvol --as-sddl<br />
# O:BAG:SYD:PAI(A;OICIIO;WOWDGRGWGX;;;CO)(A;OICIIO;GRGX;;;AU)(A;;0x001200a9;;;AU)(A;OICIIO;GA;;;SY)(A;;0x001f01ff;;;SY)(A;OICIIO;WOWDGRGWGX;;;BA)(A;;0x001e01bf;;;BA)(A;OICIIO;GRGX;;;SO)(A;;0x001200a9;;;SO)<br />
<br />
<br />
<br />
<br />
= Troubleshooting = <br />
<br />
For troubleshooting, see:<br />
* [[Troubleshooting_Samba_Domain_Members|Troubleshooting Samba Domain Members]]<br />
* [[Samba_AD_DC_Troubleshooting|Samba AD DC Troubleshooting]]<br />
<br />
<br />
<br />
<br />
<br />
----<br />
[[Category:Active Directory]]<br />
[[Category:Domain Members]]<br />
[[Category:File Serving]]<br />
[[Category:NT4 Domains]]</div>Hortimechhttps://wiki.samba.org/index.php?title=Roaming_Windows_User_Profiles&diff=19135Roaming Windows User Profiles2023-11-30T12:20:06Z<p>Hortimech: </p>
<hr />
<div>= Introduction =<br />
<br />
A Windows profile is a set of files that contains all settings of a user including per-user configuration files and registry settings. In an Active Directory or NT4 domain you can set that the profile of a user is stored on a server. This enables the user to log on to different Windows domain members and use the same settings.<br />
<br />
When using roaming user profiles, a copy of the profile is downloaded from the server to the Windows domain member when a user logs into. Until the user logs out, all settings are stored and updated in the local copy. During the log out, the profile is uploaded to the server.<br />
<br />
<br />
<br />
<br />
<br />
= Windows Roaming Profile Versions =<br />
<br />
Depending on the operating system version, Windows uses separate profile folders for a user to support Windows version-specific features. Version 2 profiles and later append the <code>.V*</code> suffix to the user's profile folder.<br />
<br />
The following Windows profile versions exist:<br />
<br />
:{| class="wikitable"<br />
!Windows Client OS Version<br />
!Windows Server OS Version<br />
!Profile Suffix<br />
!Example Profile Folder Name<br />
|-<br />
|Windows NT 4.0 - Windows Vista<br />
|Windows NT Server 4.0 - Windows Server 2008<br />
|''none''<br />
|user<br />
|-<br />
|Windows 7<br />
|Windows Server 2008 R2<br />
|V2<br />
|user.V2<br />
|-<br />
|Windows 8.0 - 8.1*<br />
|Windows Server 2012 - 2012 R2*<br />
|V3<br />
|user.V3<br />
|-<br />
|Windows 8.1*<br />
|Windows Server 2012 R2*<br />
|V4<br />
|user.V4<br />
|-<br />
|Windows 10 (1507 to 1511)<br />
|Windows Server 2016<br />
|V5<br />
|user.V5<br />
|-<br />
|Windows 10 (1607 and later)<br />
|<br />
|V6<br />
|user.V6<br />
|}<br />
<br />
: <nowiki>*</nowiki> Using the default settings, Windows 8.1 and Windows Server 2012 R2 use V3 profiles. However, the profiles are incompatible with Windows 8.0 and Windows Server 2012. For this reason it is recommended that you configure Windows 8.1 and Windows Server 2012 R2 to use V4 profiles. For further details, see: [https://support.microsoft.com/en-us/help/2890783/incompatibility-between-windows-8.1-roaming-user-profiles-and-those-in-earlier-versions-of-windows Incompatibility between Windows 8.1 roaming user profiles and those in earlier versions of Windows].<br />
<br />
When you set the profile path for a user, you always set the path without any version suffix. For example:<br />
\\server\profiles\user_name<br />
<br />
<br />
<br />
<br />
<br />
= Setting up the Share on the Samba File Server =<br />
<br />
== Using Windows ACLs ==<br />
<br />
To create a share, for example, <code>profiles</code> for hosting the roaming profiles on a Samba file server: <br />
<br />
* Create a new share using these lines.<br />
<br />
[profiles]<br />
comment = Users profiles<br />
path = /srv/samba/profiles/<br />
;browseable = No<br />
read only = No<br />
csc policy = disable<br />
vfs objects = acl_xattr<br />
<br />
As 'root':<br />
<br />
mkdir -p /srv/samba/profiles<br />
chown root:"Domain Admins" /srv/samba/profiles<br />
chmod 0770 /srv/samba/profiles<br />
<br />
<br />
{{Imbox<br />
| type = note<br />
| text = If you are using the 'ad' idmap backend, then you should not give the 'Domain Admins' group a gidNumber attribute, it will break Sysvol, in which case you should create a new group, make this group a member of 'Domain Admins' and give the new group a gidNumber. Now use the new group name instead of 'Domain Admins' .<br />
}}<br />
<br />
<br />
<br />
{{Imbox<br />
| type = note<br />
| text = In the share above, <code>browseable = No</code> is commented out, this is done so that you can see the <code>profiles</code> share in RSAT to set the initial permissions. Once the permissions are set, you should uncomment the line (remove the ';').<br />
}}<br />
<br />
<br />
Set the following permissions:<br />
<br />
:* Share tab permissions:<br />
::{| class="wikitable"<br />
!Principal<br />
!Allow<br />
|-<br />
|Everyone<br />
|Full Control / Change / Read<br />
|}<br />
<br />
:* Security tab file system permissions on the root of the <code>profiles</code> share:<br />
<br />
::{| class="wikitable"<br />
!Principal<br />
!Access<br />
!Applies to<br />
|- style="vertical-align:top;"<br />
|Domain Users *<br />
|Traverse folder / execute file<br />List folder / read data<br />Create folder / append data<br />
|This folder only<br />
|-<br />
|CREATOR OWNER<br />
|Full control<br />
|Subfolders and files only<br />
|-<br />
|Domain Admins<br />
|Full control<br />
|This folder, subfolders and files<br />
|-<br />
|SYSTEM **<br />
|Full control<br />
|This folder, subfolders and files<br />
|}<br />
::<nowiki>*</nowiki> You can alternatively set other groups, to enable the group members to store their user profile on the share. When using different groups, apply the permissions as displayed for <code>Domain Users</code> in the previous example.<br />
<br />
::<nowiki>**</nowiki> For details, see [[The SYSTEM Account]].<br />
<br />
:: Verify that permission inheritance is disabled on the root of the share. If any permission entry in the <code>Advanced Security Settings</code> window displays a path in the <code>Inherited from</code> column, click the <code>Disable inheritance</code> button. On Windows 7, unselect the <code>Include inheritable permissions from this object's parent</code> check box to set the same setting.<br />
<br />
::[[Image:Profiles_Folder_File_System_ACLs.png]]<br />
<br />
These settings enable members of the <code>Domain Users</code> group to store their roaming profiles on the share, without being able to access other user's profiles. Members of the <code>Domain Admins</code> group are able to access all directories on the share.<br />
<br />
== Using POSIX ACLs on a Unix domain member ==<br />
<br />
On a Unix domain member server, you can set up the <code>profiles</code> share using POSIX ACLs instead of using Windows access control lists (ACL). This will not work on a Samba Active Directory Controller.<br />
<br />
<br />
{{Imbox<br />
| type = note<br />
| text = Whilst it is possible to use POSIX ACLs for the profiles share on an Unix domain member, it is recommended that you set up the permissions from Windows. To do this, see [[#Using_Windows_ACLs|Setting up the Profiles Share on the Samba File Server - Using Windows ACLs]].<br />
}}<br />
<br />
<br />
<br />
{{Imbox<br />
| type = warning<br />
| text = When setting up the share on a Samba Active Directory (AD) domain controller (DC), you cannot use POSIX ACLs. On an Samba DC, only shares using extended ACLs are supported. For further details, see [[Setting_up_a_Share_Using_Windows_ACLs#Enable_Extended_ACL_Support_in_the_smb.conf_File|Enable Extended ACL Support in the smb.conf File]]. To set up the share on a Samba AD DC, see [[#Using_Windows_ACLs|Setting up the Profiles Share on the Samba File Server - Using Windows ACLs]].<br />
}}<br />
<br />
<br />
* Add the following share configuration section to your <code>smb.conf</code> file:<br />
<br />
[profiles]<br />
comment = Users profiles<br />
path = /srv/samba/profiles/<br />
browseable = No<br />
read only = No<br />
force create mode = 0600<br />
force directory mode = 0700<br />
csc policy = disable<br />
store dos attributes = yes<br />
vfs objects = acl_xattr<br />
<br />
: For details about the parameters used, see the descriptions in the <code>smb.conf(5)</code> man page.<br />
<br />
* Create the directory and set permissions:<br />
<br />
# mkdir -p /srv/samba/profiles/<br />
# chgrp -R "Domain Users" /srv/samba/profiles/<br />
# chmod 1750 /srv/samba/profiles/<br />
<br />
: These settings enable members of the <code>Domain Users</code> group to store their roaming profiles on the share, without being able to access other user's profiles. Alternatively, you can set a different group.<br />
<br />
* Reload Samba:<br />
<br />
# smbcontrol all reload-config<br />
<br />
<br />
<br />
<br />
<br />
= Assigning a Roaming Profile to a User =<br />
<br />
Depending on the Windows version, Windows uses different folders to store the roaming profile of a user. However, when you set the profile path for a user, you always set the path to the folder without any version suffix. For example:<br />
\\server\profiles\user_name<br />
<br />
For further details, see [[#The_Windows_Roaming_Profile_Versions|The Windows Roaming Profile Versions]].<br />
<br />
Note that you must not set a trailing backslash.<br />
<br />
<br />
<br />
== In an Active Directory ==<br />
<br />
=== Using <code>Active Directory Users and Computers</code> ===<br />
<br />
In an Active Directory, you can use the <code>Active Directory Users and Computers</code> Windows application to set the path to the user's profile folder. If you do not have the Remote Server Administration Tools (RSAT) installed, see [[Installing RSAT|Installing RSAT]].<br />
<br />
To assign <code>\\server\profiles\demo</code> as profile folder to the <code>demo</code> account:<br />
<br />
* Log in to a computer using an account that is enabled to edit user accounts.<br />
<br />
* Open the <code>Active Directory Users and Computers</code> application.<br />
<br />
* Navigate to the directory container that contains the <code>demo</code> account.<br />
<br />
* Right-click to the <code>demo</code> user account and select <code>Properties</code>.<br />
<br />
* Select the <code>Profile</code> tab.<br />
<br />
* Fill the path to the home folder into the <code>Profile path</code> field.<br />
: Set the path always without any profile version suffix and without trailing backslash. For details, see [[#The_Windows_Roaming_Profile_Versions|The Windows Roaming Profile Versions]].<br />
<br />
:[[Image:ADUC_Set_Profile_Folder.png]].<br />
<br />
* Click <code>OK</code>.<br />
<br />
The setting is applied the next time the user logs in.<br />
<br />
<br />
<br />
=== Using a Group Policy Object ===<br />
<br />
Using group policy objects (GPO), you can assign settings to organizational units (OU) or to a domain. This enables you, for example, to automatically assign profile paths to all users that log on to a computer that is a member of the OU or domain. If you move the computer to a different OU or domain, the setting is removed or updated. Using this way, you do not have to assign manually the settings to each user account.<br />
<br />
{{Imbox<br />
| type = note<br />
| text = Windows only supports assigning a profile path using GPOs on a per-computer basis. This means that the path is also applied to local users on domain members, which have no access to the profile share. To set the profile path on a per-user basis, see [[#Using_Active_Directory_Users_and_Computers|Using Active Directory Users and Computers]].<br />
}}<br />
<br />
To create a group policy object (GPO) for the domain that automatically assigns the <code>\\server\path\''user_name''</code> path to every user that logs on to a Windows domain member:<br />
<br />
* Log in to a computer using an account that is allowed to edit group policies, such as the AD domain <code>Administrator</code> account.<br />
<br />
* Open the <code>Group Policy Management Console</code>. If you are not having the Remote Server Administration Tools (RSAT) installed on this computer, see [[Installing RSAT|Installing RSAT]].<br />
<br />
* Right-click to your AD domain and select <code>Create a GPO in this domain, and Link it here</code>.<br />
<br />
:[[Image:GPMC_Create_GPO.png]]<br />
<br />
* Enter a name for the GPO, such as <code>Profiles on ''server''</code>. The new GPO is shown below the domain entry.<br />
<br />
* Right-click to the newly-created GPO and select <code>Edit</code> to open the <code>Group Policy Management Editor</code>.<br />
<br />
* Navigate to the <code>Computer Configuration</code> &rarr; <code>Policies</code> &rarr; <code>Administrative Templates</code> &rarr; <code>System</code> &rarr; <code>User Profiles</code> entry.<br />
<br />
* Double-click the <code>Set roaming profile path for all users logging onto this computer</code> policy to edit:<br />
<br />
:* Enable the policy and set the profile path. For example:<br />
<br />
\\server\profiles\%USERNAME%<br />
<br />
:: Windows replaces the <code>%USERNAME%</code> variable with the user name during login. Set the path without trailing backslash.<br />
<br />
::[[Image:GPME_Set_Profiles_Properties.png]]<br />
<br />
:* Click <code>OK</code>.<br />
<br />
* Close the <code>Group Policy Management Editor</code>. The GPOs are automatically saved on the <code>Sysvol</code> share on the domain controller (DC).<br />
<br />
* Close the <code>Group Policy Management Console</code>.<br />
<br />
The GPO is applied at the next reboot of the Windows domain members or when they reload the group policies.<br />
<br />
<br />
<br />
=== Using <code>ldbedit</code> on a Domain Controller ===<br />
<br />
On a domain controller (DC), to assign, for example, the <code>\\server\profiles\demo\</code> path as profile folder to the <code>demo</code> account:<br />
<br />
* Edit the <code>demo</code> user account:<br />
<br />
# ldbedit -H /usr/local/samba/private/sam.ldb 'sAMAccountName=demo'<br />
<br />
* The accounts attributes are displayed in an editor. Append the following attribute and value to the end of the list:<br />
<br />
profilePath: \\server\profiles\demo<br />
<br />
: You must not set a trailing backslash to the path.<br />
<br />
* Save the changes.<br />
<br />
The setting is applied the next time the user logs in. <br />
<br />
<br />
<br />
== In an NT4 Domain ==<br />
<br />
In an Samba NT4 domain, to set <code>\\server\profiles\%U</code> as path to the profile folder:<br />
<br />
* Add the following parameter to the <code>[global]</code> section in your <code>smb.conf</code> file:<br />
<br />
logon path = \\%L\Profiles\%U<br />
<br />
: During logging in to the domain member, Samba automatically replaces the <code>%U</code> variable with the session user name. For further details, see the <code>Variable Substitutions</code> section in the <code>smb.conf(5)</code> man page.<br />
<br />
* Reload Samba:<br />
<br />
# smbcontrol all reload-config<br />
<br />
<br />
<br />
<br />
<br />
= Configuring Windows Profile Folder Redirections =<br />
<br />
See [[Configuring Windows Profile Folder Redirections]].</div>Hortimechhttps://wiki.samba.org/index.php?title=Setting_up_Samba_as_an_Active_Directory_Domain_Controller&diff=19134Setting up Samba as an Active Directory Domain Controller2023-11-30T12:03:07Z<p>Hortimech: </p>
<hr />
<div>= Introduction =<br />
<br />
Starting from version 4.0 (released in 2012,) Samba is able to serve as an Active Directory (AD) domain controller (DC). Samba operates at the forest functional level of '''Windows Server 2008 R2''' which is more than sufficient to manage sophisticated enterprises that use Windows 10/11 with strict compliance requirements (including NIST 800-171.)<br />
<br />
If you are installing Samba in a production environment, it is recommended to run two or more DCs for failover reasons, more detail on the provisioning of a failover DC can be found elsewhere on the wiki. This documentation describes how to set up Samba as the first DC to build a new AD forest. Additionally, use this documentation if you are migrating a Samba NT4 domain to Samba AD. To join Samba as an additional DC to an existing AD forest, see [[Joining_a_Samba_DC_to_an_Existing_Active_Directory|Joining a Samba DC to an Existing Active Directory]]. <br />
<br />
Samba as an AD DC only supports:<br />
* The integrated LDAP server as AD back end. For details, see the frequently asked question (FAQ) [[FAQ#Does_Samba_AD_DCs_Support_OpenLDAP_or_Other_LDAP_Servers_as_Back_End.3F|Does Samba AD DCs Support OpenLDAP or Other LDAP Servers as Back End?]]<br />
* The [http://www.h5l.se/ Heimdal] Kerberos Key Distribution Center (KDC).<br />
: Samba provides experimental support for the [https://web.mit.edu/kerberos/ MIT Kerberos] KDC provided by your operating system if you run Samba 4.7 or later and has been built using the <code>--with-system-mitkrb5</code> option. In other cases Samba uses the Heimdal KDC included in Samba. For further details about Samba using the MIT KDC, and why it is experimental see [[Running a Samba AD DC with MIT Kerberos KDC]].<br />
* Hosting and Administering of Group Policy Objects to be used for enterprise fleet management<br />
: {{Imbox<br />
| type = important<br />
| text = Installation of Samba and associated provisioning of a domain controller does not automatically translate into Group Policy functionality. Please keep this in mind, and expect to update this flag in the <code>smb.conf</code> post provisioning<br />
}}<br />
<br />
This tutorial assumes that this is a fresh installation of Samba on a fresh operating system installation. It is important to note that there is a distinction between installing of Samba and Provisioning of Samba. In general, the entire process of setting up a Samba domain controller consists of 5 steps which are relatively straight forward. These steps are as follows:<br />
<br />
# Installation of Samba and associated packages<br />
# Deletion of pre-configured Samba and Kerberos placeholder configuration files<br />
# Provisioning of Samba using the automatic provisioning tool<br />
# Editing of the <code>smb.conf</code> as needed (enabling of Group Policy and/or other features as needed) see [[Group_Policy|Group Policy]] for more information<br />
# Any environmental configuration based on Unix/Linux Distribution<br />
<br />
This page covers a lot of ground for Samba installations on both Unix and Linux systems. The installation process varies slightly based on environment, so expect to follow the linked web pages in multiple tabs throughout this read. For the remainder of this tutorial the following example information is used:<br />
<br />
* Hostname = <code>DC1</code><br />
* DC local IP Address = <code>10.99.0.1</code><br />
* Authentication Domain = <code>SAMDOM.EXAMPLE.COM</code><br />
* Top level Domain = <code>EXAMPLE.COM</code><br />
<br />
= Preparing the Installation =<br />
<br />
==== Fresh Installation ====<br />
<br />
<br />
* Select a DNS domain for your AD forest. It is not recommended to use the top level domain for your organization. This is because the domain used during the installation of Samba will resolve to the domain controller. For Example: If your organization used <code>EXAMPLE.COM</code> as their domain and this was used during the Samba installation process, then the public facing website would no longer be acceptable (assuming the publicly accessible website was not running on the DC, which it shouldn't!) It would be wise to define a subdomain for your Domain Controller to reside in. In this tutorial <code>SAMDOM.EXAMPLE.COM</code> is used, however in a lab environment it is not necessary to own a publicly accessible domain and <code>.INTERNAL</code> could hypothetically be used. The name will also be used as the AD Kerberos realm.<br />
: {{Imbox<br />
| type = important<br />
| text = Make sure that you provision the AD using a DNS domain that will not need to be changed. Samba does not support renaming the AD DNS zone and Kerberos realm. Do not use <code>.local</code> for the TLD, this is used by Avahi.<br />
}}<br />
: For additional information, see [[Active_Directory_Naming_FAQ|Active Directory Naming FAQ]].<br />
<br />
* Select a host name for your AD DC which consists of less than 15 characters (netbios limitation.) A fantastic hostname is <code>DC1</code><br />
: Do not use NT4-only terms as host name, such as <code>PDC</code> or <code>BDC</code>. These modes do not exist in an AD and cause confusion.<br />
<br />
* Set a static IP address on the DC and make the associated reservation on your router. '''Important:''' The Samba domain controller will become your DNS resolver for all domain-joined workstations. As a result it may be required to assign this IP address outside of your DHCP pool<br />
<br />
* Disable tools, such as <code>resolvconf</code>, that automatically update your <code>/etc/resolv.conf</code> DNS resolver configuration file. AD DCs and domain members must use an DNS server that is able to resolve the AD DNS zones. (More information on this on the [[Distribution-specific_Package_Installation| Distribution Specific Package Installation]] page)<br />
<br />
* Verify that the <code>/etc/hosts</code> file on the DC correctly resolves the fully-qualified domain name (FQDN) and short host name to the LAN IP address of the DC. For example:<br />
127.0.0.1 localhost<br />
10.99.0.1 DC1.samdom.example.com DC1<br />
:The host name and FQDN must not resolve to the <code>127.0.0.1</code> IP address or any other IP address than the one used on the LAN interface of the DC.<br />
<br />
* Remove any existing <code>smb.conf</code> file. To list the path to the file:<br />
<br />
# smbd -b | grep "CONFIGFILE"<br />
CONFIGFILE: /usr/local/samba/etc/samba/smb.conf<br />
<br />
==== Only Applicable if Samba was Previously Installed ====<br />
* If you previously ran a Samba installation on this host:<br />
:<br />
<br />
:* Remove all Samba database files, such as <code>*.tdb</code> and <code>*.ldb</code> files. To list the folders containing Samba databases:<br />
<br />
# smbd -b | egrep "LOCKDIR|STATEDIR|CACHEDIR|PRIVATE_DIR"<br />
LOCKDIR: /usr/local/samba/var/lock/<br />
STATEDIR: /usr/local/samba/var/locks/<br />
CACHEDIR: /usr/local/samba/var/cache/<br />
PRIVATE_DIR: /usr/local/samba/private/<br />
<br />
: Starting with a clean environment helps to prevent confusion and ensures that no files from any previous Samba installation will be mixed with your new domain DC installation.<br />
<br />
<br />
= Installing Samba =<br />
<br />
<br />
{{:Installing_Samba}}<br />
<br />
<br />
<br />
= Provisioning a Samba Active Directory =<br />
<br />
{{Imbox<br />
| type = note<br />
| text = The AD provisioning requires root permissions to create files and set permissions.<br />
}}<br />
<br />
The Samba AD provisioning process creates the AD databases and adds initial records, such as the domain administrator account and required DNS entries. Samba comes with a built in command lined tool called <code>samba-tool</code> which can be used to automatically configure your <code>smb.conf</code> when ran in interactive mode. <br />
<br />
If you are migrating a Samba NT4 domain to AD, skip this step and run the Samba classic upgrade. For details, see [[Migrating_a_Samba_NT4_Domain_to_Samba_AD_(Classic_Upgrade)|Migrating a Samba NT4 Domain to Samba AD (Classic Upgrade)]].<br />
<br />
<br />
The <code>samba-tool domain provision</code> command provides several parameters to use with the interactive and non-interactive setup. For details, see:<br />
<br />
# samba-tool domain provision --help<br />
<br />
<br />
{{Imbox<br />
| type = note<br />
| text = When provisioning a new AD, it is recommended to enable the NIS extensions by passing the <code>--use-rfc2307</code> parameter to the <code>samba-tool domain provision</code> command. There are no disadvantages to enabling the NIS extensions, but enabling them in an existing domain requires manually extending the AD schema. For further details about Unix attributes in AD, see:<br />
* [[Setting_up_RFC2307_in_AD|Setting up RFC2307 in AD]]<br />
* [[Idmap_config_ad|idmap config = ad]]<br />
}}<br />
<br />
<br />
<br />
==== Parameter Reference ====<br />
<br />
Set the following parameters during the provisioning:<br />
<br />
{| class="wikitable"<br />
!Interactive Mode Setting<br />
!Non-interactive Mode Parameter<br />
!Explanation<br />
|-<br />
|<code>--use-rfc2307</code><br />
|<code>--use-rfc2307</code><br />
|Enables the NIS extensions required for the ADUC Unix Attributes tab.<br />
|-<br />
|<code>Realm</code><br />
|<code>--realm</code><br />
|Kerberos realm. The uppercase version of the AD DNS domain. For example: <code>SAMDOM.EXAMPLE.COM</code>.<br />
|-<br />
|<code>Domain</code><br />
|<code>--domain</code><br />
|NetBIOS domain name (Workgroup). This can be anything, but it must be one word, not longer than 15 characters and not containing a dot. It is recommended to use the first part of the AD DNS domain. For example: <code>samdom</code>. Do not use the computers short hostname.<br />
|-<br />
|<code>Server Role</code><br />
|<code>--server-role</code><br />
|Installs the domain controller <code>DC</code> role.<br />
|-<br />
|<code>DNS backend</code><br />
|<code>--dns-backend</code><br />
|Sets the DNS back end. The first DC in an AD must be installed using a DNS back end. Note that the <code>BIND9_FLATFILE</code> is not supported and will be removed in a future Samba version.<br />
|-<br />
|<code>DNS forwarder IP address</code><br />
|not available<br />
|This setting is only available when using the <code>SAMBA_INTERNAL</code> DNS back end. For details, see [[Samba_Internal_DNS_Back_End#Setting_up_a_DNS_Forwarder|Setting up a DNS Forwarder]].<br />
|-<br />
|<code>Administrator password</code><br />
|<code>--adminpass</code><br />
|Sets the domain administrator password. If the password does not match the complexity requirements, the provisioning fails. For details, see [https://technet.microsoft.com/en-us/library/cc786468%28v=ws.10%29.aspx Microsoft TechNet: Passwords must meet complexity requirements].<br />
|}<br />
<br />
Other parameters frequently used with the <code>samba-tool domain provision</code> command:<br />
* <code>--option="interfaces=lo eth0" --option="bind interfaces only=yes"</code>: If your server has multiple network interfaces, use these options to bind Samba to the specified interfaces. This enables the <code>samba-tool</code> command to register the correct LAN IP address in the directory during the join.<br />
<br />
<br />
{{Imbox<br />
| type = important<br />
| text = do NOT use <code>NONE</code> as the DNS backend, it is not supported and will be removed in a future Samba version.<br />
}}<br />
<br />
{{Imbox<br />
| type = important<br />
| text = If using Bind as the DNS backend, do NOT use <code>BIND9_FLATFILE</code>, it is not supported and will be removed in a future Samba version.<br />
}}<br />
<br />
{{Imbox<br />
| type = important<br />
| text = Once you have provisioned the first DC in an AD domain, do not provision any further DCs in the same domain, [[Joining_a_Samba_DC_to_an_Existing_Active_Directory|Join]] any further DCs.<br />
}}<br />
<br />
<br />
<br />
== Provisioning Samba AD in Interactive Mode ==<br />
<br />
As mentioned above, when run as root, <code>samba-tool</code> will automatically configure your <code>smb.conf</code> to build a domain controller. Interactive Mode will not automatically enable Group Policy support. However this can be added in afterwards by manually editing <code>smb.conf</code>.<br />
<br />
{{Imbox<br />
| type = note<br />
| text = When following the instructions below, it may be helpful to have the [[Group_Policy#Winbind|Group Policy]] page open in a separate browser tab or window.<br />
}}<br />
<br />
{{Imbox<br />
| type = warning<br />
| text = The installation of Samba will create a <code>smb.conf</code> file that must be discarded prior to running the Provisioning Tool in Interactive mode, or else it will fail. On most Linux distributions this can be done by running:<br />
# mv /etc/samba/smb.conf /etc/samba/smb.conf.initial<br />
}}<br />
<br />
With the existing <code>smb.conf</code> file removed, provision a Samba AD interactively by running:<br />
<br />
# samba-tool domain provision --use-rfc2307 --interactive<br />
Realm [SAMDOM.EXAMPLE.COM]: SAMDOM.EXAMPLE.COM<br />
Domain [SAMDOM]: SAMDOM<br />
Server Role (dc, member, standalone) [dc]: dc<br />
DNS backend (SAMBA_INTERNAL, BIND9_FLATFILE, BIND9_DLZ, NONE) [SAMBA_INTERNAL]: SAMBA_INTERNAL<br />
DNS forwarder IP address (write 'none' to disable forwarding) [10.99.0.1]: 8.8.8.8<br />
Administrator password: Passw0rd<br />
Retype password: Passw0rd<br />
Looking up IPv4 addresses<br />
Looking up IPv6 addresses<br />
No IPv6 address will be assigned<br />
Setting up share.ldb<br />
Setting up secrets.ldb<br />
Setting up the registry<br />
Setting up the privileges database<br />
Setting up idmap db<br />
Setting up SAM db<br />
Setting up sam.ldb partitions and settings<br />
Setting up sam.ldb rootDSE<br />
Pre-loading the Samba 4 and AD schema<br />
Adding DomainDN: DC=samdom,DC=example,DC=com<br />
Adding configuration container<br />
Setting up sam.ldb schema<br />
Setting up sam.ldb configuration data<br />
Setting up display specifiers<br />
Modifying display specifiers<br />
Adding users container <br />
Modifying users container <br />
Adding computers container <br />
Modifying computers container <br />
Setting up sam.ldb data <br />
Setting up well known security principals <br />
Setting up sam.ldb users and groups <br />
Setting up self join <br />
Adding DNS accounts <br />
Creating CN=MicrosoftDNS,CN=System,DC=samdom,DC=example,DC=com <br />
Creating DomainDnsZones and ForestDnsZones partitions <br />
Populating DomainDnsZones and ForestDnsZones partitions <br />
Setting up sam.ldb rootDSE marking as synchronized <br />
Fixing provision GUIDs <br />
A Kerberos configuration suitable for Samba 4 has been generated at /usr/local/samba/private/krb5.conf <br />
Setting up fake yp server settings <br />
Once the above files are installed, your Samba4 server will be ready to use <br />
Server Role: active directory domain controller <br />
Hostname: DC1 <br />
NetBIOS Domain: SAMDOM <br />
DNS Domain: samdom.example.com <br />
DOMAIN SID: S-1-5-21-2614513918-2685075268-614796884<br />
<br />
{{Imbox<br />
| type = note<br />
| text = The interactive provisioning mode supports passing further parameters to the <code>samba-tool domain provision</code> command. This enables you to modify parameters that are not part of the interactive setup.<br />
}}<br />
<br />
== Provisioning Samba AD in Non-interactive Mode ==<br />
<br />
For example, to provision a Samba AD non-interactively with the following settings:<br />
* Server role: <code>dc</code><br />
* NIS extensions enabled<br />
* Internal DNS back end<br />
* Kerberos realm and AD DNS zone: <code>samdom.example.com</code><br />
* NetBIOS domain name: <code>SAMDOM</code><br />
* Domain administrator password: <code>Passw0rd</code><br />
<br />
# samba-tool domain provision --server-role=dc --use-rfc2307 --dns-backend=SAMBA_INTERNAL --realm=SAMDOM.EXAMPLE.COM --domain=SAMDOM --adminpass=Passw0rd<br />
<br />
<br />
<br />
<br />
<br />
= Setting up the AD DNS back end =<br />
<br />
Skip this step if you provisioned the DC using the <code>SAMBA_INTERNAL</code> DNS back end.<br />
<br />
* Set up the BIND DNS server and the <code>BIND9_DLZ</code> module. For details, see [[Setting_up_a_BIND_DNS_Server|Setting up a BIND DNS Server]].<br />
<br />
* Start the BIND DNS server. For example:<br />
# systemctl start named<br />
: For details how to start services, see you distribution's documentation.<br />
<br />
<br />
<br />
<br />
= Configuring the DNS Resolver =<br />
<br />
Domain members in an AD use DNS to locate services, such as LDAP and Kerberos. For that, they need to use a DNS server that is able to resolve the AD DNS zone.<br />
<br />
On your DC, set the AD DNS domain in the <code>search</code> and the IP of your DC in the <code>nameserver</code> parameter of the <code>/etc/resolv.conf</code> file. For example:<br />
<br />
search samdom.example.com<br />
nameserver 10.99.0.1<br />
<br />
<br />
<br />
<br />
<br />
= Configuring Kerberos =<br />
<br />
In an AD, Kerberos is used to authenticate users, machines, and services.<br />
<br />
During the provisioning, Samba created a Kerberos configuration file for your DC. Copy this file to your operating system's Kerberos configuration. For instance, if you built Samba yourself:<br />
<br />
# cp /usr/local/samba/private/krb5.conf /etc/krb5.conf<br />
<br />
Your <code>krb5.conf</code> path probably will be different, always use the path in the provision output. However, wherever Samba creates the <code>krb5.conf</code>, you need to copy it to <code>/etc/krb5.conf</code>.<br />
<br />
<br />
{{Imbox<br />
| type = important<br />
| text = Do not create a symbolic link to the the generated <code>krb5.conf</code> file. In Samba 4.7 and later, the <code>/usr/local/samba/private/</code> directory is no longer accessible by other users than the <code>root</code> user. If the file is a symbolic link, other users are not able to read the file and, for example, dynamic DNS updates fail if you use the <code>BIND_DLZ</code> DNS back end.<br />
}}<br />
<br />
The pre-created Kerberos configuration uses DNS service (SRV) resource records to locate the KDC.<br />
<br />
<br />
<br />
<br />
<br />
= Testing your Samba AD DC =<br />
<br />
To start the <code>samba</code> service manually, enter:<br />
<br />
# samba<br />
<br />
Samba does not provide System V init scripts, <code>systemd</code>, <code>upstart</code>, or other services configuration files.<br />
* If you installed Samba using packages, use the script or service configuration file included in the package to start Samba.<br />
* If you built Samba, see [[Managing_the_Samba_AD_DC_Service|Managing the Samba AD DC Service]].<br />
<br />
<br />
<br />
<br />
= Create a reverse zone =<br />
<br />
You can optionally add a reverse lookup zone.<br />
<br />
# samba-tool dns zonecreate <Your-AD-DNS-Server-IP-or-hostname> 0.99.10.in-addr.arpa -U Administrator<br />
Password for [administrator@SAMDOM.EXAMPLE.COM]:<br />
Zone 0.99.10.in-addr.arpa created successfully<br />
<br />
If you need more than one reverse zone (multiple subnets), just run the above command again but with the data for the other subnet.<br />
<br />
The reverse zone is directly live without restarting Samba or BIND.<br />
<br />
{{Imbox<br />
| type = note<br />
| text = You must start the Samba AD DC before you can add a reverse zone.<br />
}}<br />
<br />
<br />
Now that you have created a reversezone, it would be a good time to create the <code>PTR</code> (reverse) dns record for the new DC.<br />
<br />
For a DC with the FQDN of <code>dc1.samdom.example.com</code> and the ipaddress of <code>10.99.0.1</code>, to add a record to the <code>0.99.10.in-addr.arpa</code>, you would run a command like this:<br />
<br />
# samba-tool dns add <Your-AD-DNS-Server-IP-or-hostname> 0.99.10.in-addr.arpa 1 PTR dc1.samdom.example.com -U Administrator<br />
Password for [administrator@SAMDOM.EXAMPLE.COM]:<br />
Record added successfully<br />
<br />
{{Imbox<br />
| type = note<br />
| text = The reverse records are not added automatically, you must add them manually, or set Windows computers to add them when updating their dns records.<br />
}}<br />
<br />
<br />
<br />
<br />
<br />
== Verifying the File Server (Optional)==<br />
<br />
To list all shares provided by the DC:<br />
<br />
Before Samba 4.11.0:<br />
<br />
$ smbclient -L localhost -N<br />
Anonymous login successful<br />
Domain=[SAMDOM] OS=[Unix] Server=[Samba x.y.z]<br />
<br />
Sharename Type Comment<br />
--------- ---- -------<br />
netlogon Disk <br />
sysvol Disk <br />
IPC$ IPC IPC Service (Samba x.y.z)<br />
Domain=[SAMDOM] OS=[Unix] Server=[Samba x.y.z]<br />
<br />
Server Comment<br />
--------- -------<br />
<br />
Workgroup Master<br />
--------- -------<br />
<br />
From Samba 4.11.0:<br />
<br />
smbclient -L localhost -N<br />
Anonymous login successful<br />
<br />
Sharename Type Comment<br />
--------- ---- -------<br />
sysvol Disk <br />
netlogon Disk <br />
IPC$ IPC IPC Service (Samba 4.12.6-Debian)<br />
SMB1 disabled -- no workgroup available<br />
<br />
<br />
{{Imbox<br />
| type = note<br />
| text = The <code>netlogon</code> and <code>sysvol</code> shares were auto-created during the provisioning and must exist on a DC.<br />
}}<br />
<br />
To verify authentication, connect to the <code>netlogon</code> share using the domain administrator account:<br />
<br />
$ smbclient //localhost/netlogon -UAdministrator -c 'ls'<br />
Enter Administrator's password: <br />
Domain=[SAMDOM] OS=[Unix] Server=[Samba x.y.z]<br />
. D 0 Tue Nov 1 08:40:00 2016<br />
.. D 0 Tue Nov 1 08:40:00 2016<br />
<br />
49386 blocks of size 524288. 42093 blocks available<br />
<br />
If one or more tests fail, see [[#Troubleshooting|Troubleshooting]].<br />
<br />
<br />
<br />
== Verifying DNS (Optional)==<br />
<br />
To verify that your AD DNS configuration works correctly, query some DNS records:<br />
<br />
* The tcp-based <code>_ldap</code> SRV record in the domain:<br />
<br />
$ host -t SRV _ldap._tcp.samdom.example.com.<br />
_ldap._tcp.samdom.example.com has SRV record 0 100 389 dc1.samdom.example.com.<br />
<br />
* The udp-based <code>_kerberos</code> SRV resource record in the domain:<br />
<br />
$ host -t SRV _kerberos._udp.samdom.example.com.<br />
_kerberos._udp.samdom.example.com has SRV record 0 100 88 dc1.samdom.example.com.<br />
<br />
* The A record of the domain controller:<br />
<br />
$ host -t A dc1.samdom.example.com.<br />
dc1.samdom.example.com has address 10.99.0.1<br />
<br />
* If you have created a reverse zone, the PTR record of the domain controller:<br />
<br />
$ host -t PTR 10.99.0.1<br />
1.0.99.10.in-addr.arpa domain name pointer dc1.samdom.example.com.<br />
<br />
If one or more tests fail, see [[#Troubleshooting|Troubleshooting]].<br />
<br />
<br />
<br />
== Verifying Kerberos (Optional) ==<br />
<br />
This is not explicitly required, but it is a good idea to verify that your Domain Controller's authentication mechanisms are operating as intended. To test this, login by requesting a Kerberos ticket for the Domain Administrator account:<br />
<br />
$ kinit administrator<br />
Password for administrator@SAMDOM.EXAMPLE.COM:<br />
<br />
: {{Imbox<br />
| type = note<br />
| text = If you do not pass the principal in the <code>user@REALM</code> format to the <code>kinit</code> command, the Kerberos realm is automatically appended.<br />Always enter the Kerberos realm in uppercase.<br />
}}<br />
<br />
* List the cached Kerberos tickets:<br />
<br />
$ klist<br />
Ticket cache: FILE:/tmp/krb5cc_0<br />
Default principal: administrator@SAMDOM.EXAMPLE.COM<br />
<br />
Valid starting Expires Service principal<br />
01.11.2016 08:45:00 12.11.2016 18:45:00 krbtgt/SAMDOM.EXAMPLE.COM@SAMDOM.EXAMPLE.COM<br />
renew until 02.11.2016 08:44:59<br />
<br />
If one or more tests fail, see [[#Troubleshooting|Troubleshooting]].<br />
<br />
<br />
<br />
<br />
<br />
= Configuring Time Synchronization (Optional Depending on Use-Case)=<br />
<br />
Kerberos requires synchronized time on all domain members. For further details and how to set up the <code>ntpd</code> or <code>chrony</code> service, see [[Time_Synchronisation|Time Synchronization]]. However if Samba is being used as a domain controller to administer Group Policy, it is possible to define a Group Policy Object that synchronizes workstations with <code>time.windows.com</code> post installation which simplifies this<br />
<br />
<br />
<br />
= Using the Domain Controller as a File Server (Optional) =<br />
<br />
{{Imbox<br />
| type = warning<br />
| text = Do not use an AD DC as a fileserver if you have multiple DC's. You should only use a DC as a fileserver, if it is the only Samba instance running in a domain. If you have multiple DC's, you should also set up Unix domain members and use them as fileservers. You should be aware that it is problematic to use a DC as a fileserver and can cause strange errors.<br />
}}<br />
<br />
<br />
While the Samba AD DC is able to provide file shares like all other installation modes, the Samba team does not recommend using a DC as a file server for the following reasons:<br />
<br />
* For anything but the smallest organizations, having more than one DC is a really good backup measure, and makes upgrades safer<br />
* It encourages upgrades of the DC to also be upgrades of the host OS every year or two, because there isn't complex data to transition or other services involved. <br />
* This means upgrades can be done by installing fresh, and replicating in the changes, which is better tested in Samba, gains new features and avoids a number of lingering data corruption risks. <br />
* The DC and file-server have different points at which an organization would wish to upgrade. The needs for new features on the DC and file server come at different times. Currently the AD DC is evolving rapidly to gain features, whereas the fileserver, after over 20 years, is quite rightly more conservative.<br />
* mandatory smb signing is enforced on the DC.<br />
<br />
<br />
If you do decide to use the Samba DC as a fileserver, please consider running a VM, on the DC, containing a separate Samba Unix domain member and use this instead.<br />
<br />
If you must use the Samba DC as a fileserver, you should be aware that the auto-enabled <code>acl_xattr</code> virtual file system (VFS) object enables you to only configure shares with Windows access control lists (ACL). Using POSIX ACLs with shares on a Samba DC does not work. <br />
<br />
You should be aware that if wish to use a vfs object on a DC share e.g. recycle, you must not just set <code>vfs objects = recycle</code> in the share. Doing this will turn off the default vfs objects <code>dfs_samba4</code> and <code>acl_xattr</code>. You must set <code>vfs objects = dfs_samba4 acl_xattr recycle</code>. <br />
<br />
To provide network shares with the full capabilities of Samba, set up a Samba domain member with file shares. For details, see:<br />
* [[Setting_up_Samba_as_a_Domain_Member|Setting up Samba as a Domain Member]]<br />
* [[Samba_File_Serving|Samba File Serving]]<br />
<br />
<br />
If you only have a small domain (small office, home network) and do not want to follow the Samba team's recommendation and use the DC additionally as a file server, configure Winbindd before you start setting up shares. For details, see [[Configuring_Winbindd_on_a_Samba_AD_DC|Configuring Winbindd on a Samba AD DC]].<br />
<br />
<br />
{{Imbox<br />
| type = warning<br />
| text = If you do use an AD DC as a fileserver, you must be aware that it can be problematic and can cause strange errors.<br />
}}<br />
<br />
{{Imbox<br />
| type = warning<br />
| text = If you do use an AD DC as a fileserver, do not add any of the 'idmap config' lines used on a Unix domain member. They will not work and will cause problems.<br />
}}<br />
<br />
{{Imbox<br />
| type = warning<br />
| text = If you do use an AD DC as a fileserver, You must set the permissions from Windows, do not attempt to use any of the old methods (force user etc) . They will not work correctly and will cause problems.<br />
}}<br />
<br />
= Troubleshooting =<br />
<br />
For further details, see [[Samba_AD_DC_Troubleshooting|Samba AD DC Troubleshooting]].<br />
<br />
<br />
<br />
<br />
<br />
= Further Samba-related Documentation =<br />
<br />
See [[User_Documentation|User Documentation]].<br />
<br />
<br />
<br />
<br />
<br />
----<br />
[[Category:Domain Control]]<br />
[[Category:Active Directory]]</div>Hortimechhttps://wiki.samba.org/index.php?title=Roaming_Windows_User_Profiles&diff=19129Roaming Windows User Profiles2023-11-28T19:05:40Z<p>Hortimech: /* Using Windows ACLs */</p>
<hr />
<div>= Introduction =<br />
<br />
A Windows profile is a set of files that contains all settings of a user including per-user configuration files and registry settings. In an Active Directory or NT4 domain you can set that the profile of a user is stored on a server. This enables the user to log on to different Windows domain members and use the same settings.<br />
<br />
When using roaming user profiles, a copy of the profile is downloaded from the server to the Windows domain member when a user logs into. Until the user logs out, all settings are stored and updated in the local copy. During the log out, the profile is uploaded to the server.<br />
<br />
<br />
<br />
<br />
<br />
= Windows Roaming Profile Versions =<br />
<br />
Depending on the operating system version, Windows uses separate profile folders for a user to support Windows version-specific features. Version 2 profiles and later append the <code>.V*</code> suffix to the user's profile folder.<br />
<br />
The following Windows profile versions exist:<br />
<br />
:{| class="wikitable"<br />
!Windows Client OS Version<br />
!Windows Server OS Version<br />
!Profile Suffix<br />
!Example Profile Folder Name<br />
|-<br />
|Windows NT 4.0 - Windows Vista<br />
|Windows NT Server 4.0 - Windows Server 2008<br />
|''none''<br />
|user<br />
|-<br />
|Windows 7<br />
|Windows Server 2008 R2<br />
|V2<br />
|user.V2<br />
|-<br />
|Windows 8.0 - 8.1*<br />
|Windows Server 2012 - 2012 R2*<br />
|V3<br />
|user.V3<br />
|-<br />
|Windows 8.1*<br />
|Windows Server 2012 R2*<br />
|V4<br />
|user.V4<br />
|-<br />
|Windows 10 (1507 to 1511)<br />
|Windows Server 2016<br />
|V5<br />
|user.V5<br />
|-<br />
|Windows 10 (1607 and later)<br />
|<br />
|V6<br />
|user.V6<br />
|}<br />
<br />
: <nowiki>*</nowiki> Using the default settings, Windows 8.1 and Windows Server 2012 R2 use V3 profiles. However, the profiles are incompatible with Windows 8.0 and Windows Server 2012. For this reason it is recommended that you configure Windows 8.1 and Windows Server 2012 R2 to use V4 profiles. For further details, see: [https://support.microsoft.com/en-us/help/2890783/incompatibility-between-windows-8.1-roaming-user-profiles-and-those-in-earlier-versions-of-windows Incompatibility between Windows 8.1 roaming user profiles and those in earlier versions of Windows].<br />
<br />
When you set the profile path for a user, you always set the path without any version suffix. For example:<br />
\\server\profiles\user_name<br />
<br />
<br />
<br />
<br />
<br />
= Setting up the Share on the Samba File Server =<br />
<br />
== Using Windows ACLs ==<br />
<br />
To create a share, for example, <code>profiles</code> for hosting the roaming profiles on a Samba file server: <br />
<br />
* Create a new share using these lines.<br />
<br />
[profiles]<br />
comment = Users profiles<br />
path = /srv/samba/profiles/<br />
;browseable = No<br />
read only = No<br />
csc policy = disable<br />
vfs objects = acl_xattr<br />
<br />
For further details on setting the share permissions, see [[Setting up a Share Using Windows ACLs]].<br />
<br />
<br />
{{Imbox<br />
| type = note<br />
| text = In the share above, <code>browseable = No</code> is commented out, this is done so that you can see the <code>profiles</code> share in RSAT to set the initial permissions. Once the permissions are set, you should uncomment the line (remove the ';').<br />
}}<br />
<br />
<br />
Set the following permissions:<br />
<br />
:* Share tab permissions:<br />
::{| class="wikitable"<br />
!Principal<br />
!Allow<br />
|-<br />
|Everyone<br />
|Full Control / Change / Read<br />
|}<br />
<br />
:* Security tab file system permissions on the root of the <code>profiles</code> share:<br />
<br />
::{| class="wikitable"<br />
!Principal<br />
!Access<br />
!Applies to<br />
|- style="vertical-align:top;"<br />
|Domain Users *<br />
|Traverse folder / execute file<br />List folder / read data<br />Create folder / append data<br />
|This folder only<br />
|-<br />
|CREATOR OWNER<br />
|Full control<br />
|Subfolders and files only<br />
|-<br />
|Domain Admins<br />
|Full control<br />
|This folder, subfolders and files<br />
|-<br />
|SYSTEM **<br />
|Full control<br />
|This folder, subfolders and files<br />
|}<br />
::<nowiki>*</nowiki> You can alternatively set other groups, to enable the group members to store their user profile on the share. When using different groups, apply the permissions as displayed for <code>Domain Users</code> in the previous example.<br />
<br />
::<nowiki>**</nowiki> For details, see [[The SYSTEM Account]].<br />
<br />
:: Verify that permission inheritance is disabled on the root of the share. If any permission entry in the <code>Advanced Security Settings</code> window displays a path in the <code>Inherited from</code> column, click the <code>Disable inheritance</code> button. On Windows 7, unselect the <code>Include inheritable permissions from this object's parent</code> check box to set the same setting.<br />
<br />
::[[Image:Profiles_Folder_File_System_ACLs.png]]<br />
<br />
These settings enable members of the <code>Domain Users</code> group to store their roaming profiles on the share, without being able to access other user's profiles. Members of the <code>Domain Admins</code> group are able to access all directories on the share.<br />
<br />
== Using POSIX ACLs on a Unix domain member ==<br />
<br />
On a Unix domain member server, you can set up the <code>profiles</code> share using POSIX ACLs instead of using Windows access control lists (ACL). This will not work on a Samba Active Directory Controller.<br />
<br />
<br />
{{Imbox<br />
| type = note<br />
| text = Whilst it is possible to use POSIX ACLs for the profiles share on an Unix domain member, it is recommended that you set up the permissions from Windows. To do this, see [[#Using_Windows_ACLs|Setting up the Profiles Share on the Samba File Server - Using Windows ACLs]].<br />
}}<br />
<br />
<br />
<br />
{{Imbox<br />
| type = warning<br />
| text = When setting up the share on a Samba Active Directory (AD) domain controller (DC), you cannot use POSIX ACLs. On an Samba DC, only shares using extended ACLs are supported. For further details, see [[Setting_up_a_Share_Using_Windows_ACLs#Enable_Extended_ACL_Support_in_the_smb.conf_File|Enable Extended ACL Support in the smb.conf File]]. To set up the share on a Samba AD DC, see [[#Using_Windows_ACLs|Setting up the Profiles Share on the Samba File Server - Using Windows ACLs]].<br />
}}<br />
<br />
<br />
* Add the following share configuration section to your <code>smb.conf</code> file:<br />
<br />
[profiles]<br />
comment = Users profiles<br />
path = /srv/samba/profiles/<br />
browseable = No<br />
read only = No<br />
force create mode = 0600<br />
force directory mode = 0700<br />
csc policy = disable<br />
store dos attributes = yes<br />
vfs objects = acl_xattr<br />
<br />
: For details about the parameters used, see the descriptions in the <code>smb.conf(5)</code> man page.<br />
<br />
* Create the directory and set permissions:<br />
<br />
# mkdir -p /srv/samba/profiles/<br />
# chgrp -R "Domain Users" /srv/samba/profiles/<br />
# chmod 1750 /srv/samba/profiles/<br />
<br />
: These settings enable members of the <code>Domain Users</code> group to store their roaming profiles on the share, without being able to access other user's profiles. Alternatively, you can set a different group.<br />
<br />
* Reload Samba:<br />
<br />
# smbcontrol all reload-config<br />
<br />
<br />
<br />
<br />
<br />
= Assigning a Roaming Profile to a User =<br />
<br />
Depending on the Windows version, Windows uses different folders to store the roaming profile of a user. However, when you set the profile path for a user, you always set the path to the folder without any version suffix. For example:<br />
\\server\profiles\user_name<br />
<br />
For further details, see [[#The_Windows_Roaming_Profile_Versions|The Windows Roaming Profile Versions]].<br />
<br />
Note that you must not set a trailing backslash.<br />
<br />
<br />
<br />
== In an Active Directory ==<br />
<br />
=== Using <code>Active Directory Users and Computers</code> ===<br />
<br />
In an Active Directory, you can use the <code>Active Directory Users and Computers</code> Windows application to set the path to the user's profile folder. If you do not have the Remote Server Administration Tools (RSAT) installed, see [[Installing RSAT|Installing RSAT]].<br />
<br />
To assign <code>\\server\profiles\demo</code> as profile folder to the <code>demo</code> account:<br />
<br />
* Log in to a computer using an account that is enabled to edit user accounts.<br />
<br />
* Open the <code>Active Directory Users and Computers</code> application.<br />
<br />
* Navigate to the directory container that contains the <code>demo</code> account.<br />
<br />
* Right-click to the <code>demo</code> user account and select <code>Properties</code>.<br />
<br />
* Select the <code>Profile</code> tab.<br />
<br />
* Fill the path to the home folder into the <code>Profile path</code> field.<br />
: Set the path always without any profile version suffix and without trailing backslash. For details, see [[#The_Windows_Roaming_Profile_Versions|The Windows Roaming Profile Versions]].<br />
<br />
:[[Image:ADUC_Set_Profile_Folder.png]].<br />
<br />
* Click <code>OK</code>.<br />
<br />
The setting is applied the next time the user logs in.<br />
<br />
<br />
<br />
=== Using a Group Policy Object ===<br />
<br />
Using group policy objects (GPO), you can assign settings to organizational units (OU) or to a domain. This enables you, for example, to automatically assign profile paths to all users that log on to a computer that is a member of the OU or domain. If you move the computer to a different OU or domain, the setting is removed or updated. Using this way, you do not have to assign manually the settings to each user account.<br />
<br />
{{Imbox<br />
| type = note<br />
| text = Windows only supports assigning a profile path using GPOs on a per-computer basis. This means that the path is also applied to local users on domain members, which have no access to the profile share. To set the profile path on a per-user basis, see [[#Using_Active_Directory_Users_and_Computers|Using Active Directory Users and Computers]].<br />
}}<br />
<br />
To create a group policy object (GPO) for the domain that automatically assigns the <code>\\server\path\''user_name''</code> path to every user that logs on to a Windows domain member:<br />
<br />
* Log in to a computer using an account that is allowed to edit group policies, such as the AD domain <code>Administrator</code> account.<br />
<br />
* Open the <code>Group Policy Management Console</code>. If you are not having the Remote Server Administration Tools (RSAT) installed on this computer, see [[Installing RSAT|Installing RSAT]].<br />
<br />
* Right-click to your AD domain and select <code>Create a GPO in this domain, and Link it here</code>.<br />
<br />
:[[Image:GPMC_Create_GPO.png]]<br />
<br />
* Enter a name for the GPO, such as <code>Profiles on ''server''</code>. The new GPO is shown below the domain entry.<br />
<br />
* Right-click to the newly-created GPO and select <code>Edit</code> to open the <code>Group Policy Management Editor</code>.<br />
<br />
* Navigate to the <code>Computer Configuration</code> &rarr; <code>Policies</code> &rarr; <code>Administrative Templates</code> &rarr; <code>System</code> &rarr; <code>User Profiles</code> entry.<br />
<br />
* Double-click the <code>Set roaming profile path for all users logging onto this computer</code> policy to edit:<br />
<br />
:* Enable the policy and set the profile path. For example:<br />
<br />
\\server\profiles\%USERNAME%<br />
<br />
:: Windows replaces the <code>%USERNAME%</code> variable with the user name during login. Set the path without trailing backslash.<br />
<br />
::[[Image:GPME_Set_Profiles_Properties.png]]<br />
<br />
:* Click <code>OK</code>.<br />
<br />
* Close the <code>Group Policy Management Editor</code>. The GPOs are automatically saved on the <code>Sysvol</code> share on the domain controller (DC).<br />
<br />
* Close the <code>Group Policy Management Console</code>.<br />
<br />
The GPO is applied at the next reboot of the Windows domain members or when they reload the group policies.<br />
<br />
<br />
<br />
=== Using <code>ldbedit</code> on a Domain Controller ===<br />
<br />
On a domain controller (DC), to assign, for example, the <code>\\server\profiles\demo\</code> path as profile folder to the <code>demo</code> account:<br />
<br />
* Edit the <code>demo</code> user account:<br />
<br />
# ldbedit -H /usr/local/samba/private/sam.ldb 'sAMAccountName=demo'<br />
<br />
* The accounts attributes are displayed in an editor. Append the following attribute and value to the end of the list:<br />
<br />
profilePath: \\server\profiles\demo<br />
<br />
: You must not set a trailing backslash to the path.<br />
<br />
* Save the changes.<br />
<br />
The setting is applied the next time the user logs in. <br />
<br />
<br />
<br />
== In an NT4 Domain ==<br />
<br />
In an Samba NT4 domain, to set <code>\\server\profiles\%U</code> as path to the profile folder:<br />
<br />
* Add the following parameter to the <code>[global]</code> section in your <code>smb.conf</code> file:<br />
<br />
logon path = \\%L\Profiles\%U<br />
<br />
: During logging in to the domain member, Samba automatically replaces the <code>%U</code> variable with the session user name. For further details, see the <code>Variable Substitutions</code> section in the <code>smb.conf(5)</code> man page.<br />
<br />
* Reload Samba:<br />
<br />
# smbcontrol all reload-config<br />
<br />
<br />
<br />
<br />
<br />
= Configuring Windows Profile Folder Redirections =<br />
<br />
See [[Configuring Windows Profile Folder Redirections]].</div>Hortimechhttps://wiki.samba.org/index.php?title=Setting_up_a_Share_Using_Windows_ACLs&diff=19128Setting up a Share Using Windows ACLs2023-11-28T18:55:26Z<p>Hortimech: /* Adding a Share */</p>
<hr />
<div>= Introduction =<br />
<br />
Extended access control lists (ACL) enable you to set permissions on shares, files, and directories using Windows ACLs and applications. Samba supports shares using extended ACLs on:<br />
* Domain members<br />
* Active Directory (AD) domain controllers (DC)<br />
* NT4 primary domain controller (PDC)<br />
* NT4 backup domain controllers (BDC)<br />
* Standalone hosts<br />
<br />
<br />
<br />
<br />
<br />
= Preparing the Host =<br />
<br />
You need to set up Samba before you are able to create a share. Depending on what type of Samba server you require, see:<br />
* [[Setting_up_Samba_as_a_Domain_Member|Setting up Samba as a Domain Member]]<br />
* [[Active_Directory_Domain_Controller|Setting up Samba as AD DC]]<br />
* [[Setting_up_Samba_as_an_NT4_PDC_(Quick_Start)|Setting up Samba as an NT4 PDC (Quick Start)]]<br />
* [[Setting_up_Samba_as_an_NT4_BDC|Setting up Samba as an NT4 BDC]]<br />
* [[Setting_up_Samba_as_a_Standalone_Server|Setting up Samba as a Standalone Server]]<br />
<br />
<br />
<br />
== File System Support ==<br />
<br />
The file system, the share will be created on, must support:<br />
* user and system <code>xattr</code> name spaces.<br />
* extended access control lists (ACL).<br />
<br />
For further details, see [[File_System_Support|File system support]].<br />
<br />
<br />
<br />
== Samba Extended ACL Support ==<br />
<br />
To create a share with extended access control list (ACL) support, the <code>smbd</code> service must have been built with ACL support enabled. A Samba host working as an Active Directory (AD) domain controller (DC), is always enabled with extended ACL support.<br />
<br />
To verify if Samba has been built with ACL support, enter:<br />
<br />
# smbd -b | grep HAVE_LIBACL<br />
HAVE_LIBACL<br />
<br />
If no output is displayed:<br />
* Samba was built using the <code>--with-acl-support=no</code> parameter.<br />
* The Samba <code>configure</code> script was unable to locate the required libraries for ACL support. For details, see [[Package Dependencies Required to Build Samba]].<br />
<br />
<br />
<br />
<br />
<br />
== Enable Extended ACL Support on a Unix domain member ==<br />
<br />
Ideally you have a system that supports [[NFS4_ACL_overview|NFS4 ACLs]]. The following example is for systems like Linux, where you don't have those kind of ACLs. To configure shares using extended access control lists (ACL) on a Unix domain member, you must enable the support in the <code>smb.conf</code> file. To enable extended ACL support globally, add the following settings to the <code>[global]</code> section of your <code>smb.conf</code> file:<br />
<br />
vfs objects = acl_xattr<br />
map acl inherit = yes<br />
# the next line is only required on Samba versions less than 4.9.0<br />
store dos attributes = yes<br />
<br />
{{Imbox<br />
| type = important<br />
| text = On a Samba Active Directory (AD) domain controller (DC), extended ACL support is automatically enabled globally. You must not enable the support manually.<br />
}}<br />
<br />
Alternatively, to enable extended ACL support only for a specific share, add the parameters to the share's section.<br />
<br />
For further details about the parameters, see the <code>smb.conf(5)</code> man page.<br />
<br />
<br />
<br />
<br />
<br />
== Granting the <code>SeDiskOperatorPrivilege</code> Privilege ==<br />
<br />
Only users and groups having the <code>SeDiskOperatorPrivilege</code> privilege granted can configure share permissions.<br />
<br />
{{Imbox<br />
| type = note<br />
| text = Only users or groups that are known to Unix can be used. This means that if you use the winbind 'ad' backend on Unix domain members, you must add a uidNumber attribute to users, or a gidNumber to groups in AD. <br />
}}<br />
<br />
{{Imbox<br />
| type = note<br />
| text = If you use the winbind 'ad' backend on Unix domain members and you add a gidNumber attribute to the <code>Domain Admins</code> group in AD, you will break the mapping in <code>idmap.ldb</code>. <code>Domain Admins</code> is mapped as <code>ID_TYPE_BOTH</code> in <code>idmap.ldb</code>, this is to allow the group to own files in <code>Sysvol</code> on a Samba AD DC. It is suggested you create a new AD group (<code>Unix Admins</code> for instance), give this group a <code>gidNumber</code> attribute and add it to the <code>Administrators</code> group and then, on Unix, use the group wherever you would normally use <code>Domain Admins</code>. <br />
}}<br />
<br />
<br />
If you are using the 'ad' winbind idmap backend, then you should use the 'Unix Admins' group you were advised to create above. However, if you use any other winbind idmap backend (autorid or rid, for instance), then you can use the 'Domain Admins' group.<br />
<br />
<br />
To grant the privilege to the <code>Domain Admins</code> group, enter:<br />
<br />
# net rpc rights grant "SAMDOM\Domain Admins" SeDiskOperatorPrivilege -U "SAMDOM\administrator"<br />
Enter SAMDOM\administrator's password:<br />
Successfully granted rights.<br />
<br />
<br />
To grant the privilege to the <code>Unix Admins</code> group, enter:<br />
<br />
# net rpc rights grant "SAMDOM\Unix Admins" SeDiskOperatorPrivilege -U "SAMDOM\administrator"<br />
Enter SAMDOM\administrator's password:<br />
Successfully granted rights.<br />
<br />
<br />
{{Imbox<br />
| type = note<br />
| text = It is recommended to grant the privilege to a group instead of individual accounts. This enables you to add and revoke the privilege by updating the group membership.<br />
}}<br />
<br />
To list all users and groups having the <code>SeDiskOperatorPrivilege</code> privilege granted, enter:<br />
<br />
# net rpc rights list privileges SeDiskOperatorPrivilege -U "SAMDOM\administrator"<br />
Enter administrator's password:<br />
SeDiskOperatorPrivilege:<br />
BUILTIN\Administrators<br />
SAMDOM\Unix Admins<br />
<br />
{{Imbox<br />
| type = important<br />
| text = You need to grant the <code>SeDiskOperatorPrivilege</code> privilege on the Samba server that holds the share.<br />
}}<br />
<br />
<br />
<br />
<br />
<br />
= Adding a Share =<br />
<br />
To share the <code>/srv/samba/Demo/</code> directory using the <code>Demo</code> share name:<br />
<br />
* As the <code>root</code> user, create the directory:<br />
<br />
# mkdir -p /srv/samba/Demo/<br />
<br />
* To enable accounts other than the domain user <code>Administrator</code> to set permissions on Windows, grant <code>Full control</code> (<code>rwx</code>) to the user or group you granted the <code>SeDiskOperatorPrivilege</code> privilege. For example (if using the 'ad' backend):<br />
<br />
# chown root:"Unix Admins" /srv/samba/Demo/<br />
# chmod 0770 /srv/samba/Demo/<br />
<br />
* Otherwise for any other backend:<br />
<br />
# chown root:"Domain Admins" /srv/samba/Demo/<br />
# chmod 0770 /srv/samba/Demo/<br />
<br />
* Add the <code>[Demo]</code> share definition to your <code>smb.conf</code> file:<br />
<br />
[Demo]<br />
path = /srv/samba/Demo/<br />
read only = no<br />
<br />
: Further share-specific settings and file system permissions are set using the Windows utilities.<br />
<br />
<br />
:{{Imbox<br />
| type = important<br />
| text = Do not set <code>ANY</code> additional share parameters, such as <code>force user</code> or <code>valid users</code>. Adding them to the share definition can prevent you from configuring or using the share.<br />
}}<br />
<br />
<br />
If you are setting the shares permissions from Windows (recommended), you can add this line to your share:<br />
acl_xattr:ignore system acls = yes<br />
<br />
By adding this line, Samba will ignore the system ACL's (ugo). This means that when you run <code>setfacl</code> on the shares directory, it will not show any permission modifications you may have have done from Windows. You must not add this line until you have set up the share permissions from Windows, otherwise you may find that you are denied permission to change the permissions from Windows.<br />
<br />
<br />
* Reload the Samba configuration:<br />
<br />
# smbcontrol all reload-config<br />
<br />
= Setting Share Permissions and ACLs =<br />
<br />
When you configure a share with extended access control lists (ACL) support, you set the share permissions using Windows utilities instead of adding parameters to the share section in the <code>smb.conf</code> file.<br />
<br />
To set permissions and ACLs on the <code>Demo</code> share:<br />
<br />
* Log on to a Windows host using an account that has the <code>SeDiskOperatorPrivilege</code> privilege granted. e.g. <code>SAMDOM\Administrator</code> or <code>SAMDOM\john</code> where <code>john</code> is a member of <code>Unix Admins</code>.<br />
<br />
* Click <code>Start</code>, enter <code>Computer Management</code>, and start the application.<br />
<br />
* Select <code>Action</code> / <code>Connect to another computer</code>.<br />
<br />
* Enter the name of the Samba host and click <code>OK</code> to connect the console to the host.<br />
<br />
* Open the <code>System Tools</code> / <code>Shared Folders</code> / <code>Shares</code> menu entry.<br />
<br />
:[[Image:Computer_Management_Shares.png]]<br />
<br />
<br />
<br />
<br />
* Right-click to the share and select <code>Properties</code>.<br />
<br />
* Select the <code>Share Permissions</code> tab and check the share permissions, you need to see <code>Everyone</code>. For example:<br />
:[[Image:share.png]]<br />
<br />
{{Imbox<br />
| type = important<br />
| text = If the permissions are as above, you do not need to change anything, if not, change it to just allow <code>Everyone</code> : <code>Full Control, Change and Read</code>. You should only need to make changes to the <code>Security</code> tab.<br />
}}<br />
<br />
: Samba stores the share tab permissions in the <code>/usr/local/samba/var/locks/share_info.tdb</code> database.<br />
<br />
<br />
<br />
<br />
* Select the <code>Security</code> tab.<br />
<br />
* Click the <code>Edit</code> button and set the file system ACLs on the share's root directory. For example:<br />
<br />
:[[Image:Demo_Share_Security.png]]<br />
<br />
: For details about using the <code>SYSTEM</code> account on a Samba share see [[The SYSTEM Account]].<br />
<br />
: For details where the ACLs are stored, see [[#File_System_ACLs_in_the_Back_End|File System ACLs in the Back End]].<br />
<br />
* Click the <code>Add</code> button.<br />
<br />
* Click <code>Advanced</code> button<br />
<br />
* Click <code>Find Now</code><br />
<br />
* Select a user or group from the list, <code>Domain Users</code> for instance.<br />
<br />
* Click <code>OK</code><br />
<br />
* Click <code>OK</code><br />
<br />
* Select permissions to grant, <code>Full control</code> for instance.<br />
<br />
* A windows security box should open, asking if you want to continue, Click <code>Yes</code><br />
<br />
* If you check the list of <code>Group or user names</code>, you should find <code>Domain Users</code> listed<br />
<br />
* Click <code>OK</code> to close the <code>Permissions for Demo</code> window.<br />
<br />
* Click <code>OK</code> to store the updated settings.<br />
<br />
For further details about configuring share permissions and ACLs, see the Windows documentation.<br />
<br />
<br />
<br />
<br />
<br />
= Setting ACLs on a Folder =<br />
<br />
To set file system permissions on a folder located on a share that uses extended access control lists (ACL):<br />
<br />
* Log on to a Windows host using an account that has <code>Full control</code> on the folder you want to modify the file system ACLs.<br />
<br />
* Navigate to the folder.<br />
<br />
* Right-click to the folder and select <code>Properties</code>.<br />
<br />
* Select the <code>Security</code> tab and click the <code>Edit</code> button.<br />
<br />
* Set the permission. For example:<br />
<br />
:[[Image:Folder_Permissions.png]]<br />
<br />
: For details about using the <code>SYSTEM</code> account on a Samba share see [[The SYSTEM Account]].<br />
<br />
: For details where the ACLs are stored, see [[#File_System_ACLs_in_the_Back_End|File System ACLs in the Back End]].<br />
<br />
* Click <code>OK</code> to close the <code>Permissions for Folder</code> window.<br />
<br />
* Click <code>OK</code> to store the updated settings.<br />
<br />
For further details about setting ACLs, see the Windows documentation.<br />
<br />
<br />
<br />
<br />
<br />
= File System ACLs in the Back End =<br />
<br />
Samba stores the file system permissions in extended file system access control lists (ACL) and in an extended attribute. For example:<br />
<br />
* To list the extended ACLs of the <code>/srv/samba/Demo/</code> directory, enter:<br />
<br />
# getfacl /srv/samba/Demo/<br />
# file: srv/samba/Demo/<br />
# owner: root<br />
# group: root<br />
user::rwx<br />
user:root:rwx<br />
group::---<br />
group:root:---<br />
group:domain\040users:rwx<br />
group:unix\040admins:rwx<br />
mask::rwx<br />
other::---<br />
default:user::rwx<br />
default:user:root:rwx<br />
default:group::---<br />
default:group:root:---<br />
default:group:domain\040users:rwx<br />
default:group:unix\040admins:rwx<br />
default:mask::rwx<br />
default:other::---<br />
<br />
* To list the <code>security.NTACL</code> extended attribute of the <code>/srv/samba/Demo/</code> directory, enter:<br />
<br />
# getfattr -n security.NTACL -d /srv/samba/Demo/<br />
# file: srv/samba/Demo/<br />
security.NTACL=0sBAAEAAAAAgAEAAIAAQC4zK0lHchKFvwXwbPR/h8P8sXMj5dNIT5QQuWsYwO3RAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcG9zaXhfYWNsAEbGxuGu39MBuiZRk2pYxeL5ZWc4au0ikqRAk53MkjVd2b4quyk2WwcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEABJy0AAAA0AAAAAAAAADsAAAAAQUAAAAAAAUVAAAASSVmaZneO8cxOHk/9AEAAAEFAAAAAAAFFQAAAEklZmmZ3jvHMTh5P0oIAAACAMQABwAAAAALFACpABIAAQEAAAAAAAEAAAAAAAAUAAAAEAABAQAAAAAAAQAAAAAACxQA/wEfAAEBAAAAAAADAAAAAAALFACpABIAAQEAAAAAAAMBAAAAAAMkAP8BHwABBQAAAAAABRUAAABJJWZpmd47xzE4eT9KCAAAAAAkAP8BHwABBQAAAAAABRUAAABJJWZpmd47xzE4eT/0AQAAAAMkAL8BEwABBQAAAAAABRUAAABJJWZpmd47xzE4eT8BAgAA<br />
<br />
The previous example of file system ACLs and the extended attribute is mapped to the following Windows ACLs:<br />
<br />
{| class="wikitable"<br />
!Principal<br />
!Permissions<br />
!Applies to<br />
|-<br />
|Domain Users (SAMDOM\Domain Users)<br />
|Modify, Read & execute, List folder contents, Read, Write<br />
|(This folder, subfolders and files)<br />
|-<br />
|Unix Admins (SAMDOM\Unix Admins)<br />
|Full control<br />
|(This folder, subfolders and files)<br />
|}<br />
<br />
* To get the ACL in a more readable form, enter:<br />
<br />
# samba-tool ntacl get /usr/local/samba/var/locks/sysvol --as-sddl<br />
# O:BAG:SYD:PAI(A;OICIIO;WOWDGRGWGX;;;CO)(A;OICIIO;GRGX;;;AU)(A;;0x001200a9;;;AU)(A;OICIIO;GA;;;SY)(A;;0x001f01ff;;;SY)(A;OICIIO;WOWDGRGWGX;;;BA)(A;;0x001e01bf;;;BA)(A;OICIIO;GRGX;;;SO)(A;;0x001200a9;;;SO)<br />
<br />
<br />
<br />
<br />
= Troubleshooting = <br />
<br />
For troubleshooting, see:<br />
* [[Troubleshooting_Samba_Domain_Members|Troubleshooting Samba Domain Members]]<br />
* [[Samba_AD_DC_Troubleshooting|Samba AD DC Troubleshooting]]<br />
<br />
<br />
<br />
<br />
<br />
----<br />
[[Category:Active Directory]]<br />
[[Category:Domain Members]]<br />
[[Category:File Serving]]<br />
[[Category:NT4 Domains]]</div>Hortimechhttps://wiki.samba.org/index.php?title=Setting_up_RFC2307_in_AD&diff=19124Setting up RFC2307 in AD2023-11-26T15:17:17Z<p>Hortimech: /* Installing the RFC2307 NIS Extensions after AD DC Provisioning */</p>
<hr />
<div>= Introduction =<br />
<br />
The use of [https://www.rfc-editor.org/rfc/rfc2307.txt RFC 2307] attributes allows the storage of Unix user and group information in an LDAP directory. In an Active Directory (AD) with Linux integration, this has several advantages:<br />
* Central administration of IDs in AD.<br />
* Consistent IDs on all Linux domain members that use the Samba <code>idmap_ad</code> ID map back end.<br />
* Fast configuration of attributes.<br />
* No local ID mapping databases that can corrupt and lead to lose of file ownerships.<br />
* Enable the administrator to set individual login shells and home directory paths for users.<br />
* Login shell and home directory settings are the same on all domain members using Samba <code>idmap_ad</code> ID map back end and <code>winbind nss info = rfc2307</code> parameter.<br />
* Easy management from Windows clients using the Active Directory Users and Computers (ADUC) Microsoft management console (MMC). For details, see [[Maintaining_Unix_Attributes_in_AD_using_ADUC|Maintaining Unix Attributes in AD using ADUC]].<br />
<br />
<br />
<br />
<br />
<br />
== RFC2307 on AD Domain Controllers ==<br />
<br />
It is recommended to only have the sysvol and netlogon shares on an AD DC, so using RFC2307 id-mappings on the DC is not required. If you want to enable RFC2307 ID mappings on the DC for whatever reason e.g. you have other shares on the DC (not recommended) and are using the winbind 'ad' backend on Unix domain members, you need to ensure that the <code>idmap_ldb:use rfc2307</code> parameter exists in the <code>[global]</code> section of your <code>smb.conf</code> file on the Samba DC and is set to <code>yes</code> :<br />
<br />
idmap_ldb:use rfc2307 = yes<br />
<br />
{{Imbox<br />
| type = note<br />
| text = It is not recommended to use RFC2307 mappings on Samba AD DC's. The default idmap.ldb mechanism is fine for domain controllers and less error prone.<br />
}}<br />
<br />
<br />
<br />
<br />
<br />
== Verifying That the NIS Extensions Are Installed in Active Directory ==<br />
<br />
Verify if the <code>ypServ30</code> LDAP tree exists in your Active Directory (AD):<br />
<br />
# ldbsearch -H /usr/local/samba/private/sam.ldb -s base -b \<br />
CN=ypservers,CN=ypServ30,CN=RpcServices,CN=System,DC=samdom,DC=example,DC=com cn<br />
<br />
The output should be:<br />
<br />
# record 1<br />
dn: CN=ypservers,CN=ypServ30,CN=RpcServices,CN=System,DC=samdom,DC=example,DC=com<br />
cn: ypservers<br />
<br />
# returned 1 records<br />
# 1 entries<br />
# 0 referrals<br />
<br />
If the <code>ldbsearch</code> command returns 1 record, the NIS Extensions are installed and there is nothing else to do.<br />
<br />
{{Imbox<br />
| type = note<br />
| text = The NIS Extensions are only required if you are going to use the ADUC Unix Attributes tabs to manage your users and groups.<br />
}}<br />
<br />
== Provisioning a New Samba Active Directory with RFC2307 Enabled ==<br />
<br />
When you provision a new Samba AD forest, pass the <code>--use-rfc2307</code> to the <code>samba-tool domain provision</code> command to auto-install the NIS extensions. For example:<br />
<br />
# samba-tool domain provision --use-rfc2307 ...<br />
<br />
For details, see [[Setting_up_Samba_as_an_Active_Directory_Domain_Controller#Provisioning_a_Samba_Active_Directory|Provisioning a Samba Active Directory]].<br />
<br />
Additionally, enable the the Samba RFC2307 module. For details, see [[#Enabling_the_RFC2307_Configuration_Parameter|Enabling the RFC2307 Configuration Parameter]].<br />
<br />
<br />
<br />
== Installing the RFC2307 NIS Extensions after AD DC Provisioning ==<br />
<br />
Do not run this procedure until you have checked if it is required. For details, see [[#Verifying_That_the_NIS_Extensions_Are_Installed_in_Active_Directory|Verifying_That_the_NIS_Extensions_Are_Installed_in_Active_Directory]].<br />
<br />
<br />
{{Imbox<br />
| type = warning<br />
| text = Updating the Schema can break your AD. Verify you have a working backup before updating the schema.<br />
}}<br />
<br />
To install the NIS extensions:<br />
<br />
* Locate the domain controller (DC) with the <code>Schema Master</code> flexible single-master operations (FSMO) role:<br />
<br />
# samba-tool fsmo show | grep SchemaMasterRole<br />
SchemaMasterRole owner: CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=samdom,DC=example,DC=com<br />
<br />
: The output shows the name of the DC owning this role. Run all further steps on this DC.<br />
<br />
* Shut down the Samba service.<br />
<br />
* Create a copy of the <code>ypServ30.ldif</code> schema file. For example:<br />
<br />
# cp /usr/local/samba/share/setup/ypServ30.ldif /tmp/<br />
<br />
* Replace the variables in copied LDIF file with the domain distinguished name (DN), NetBIOS name, and the NIS domain of your setup. For example:<br />
:*${DOMAINDN}: <code>DC=samdom,DC=example,DC=com</code><br />
:*${NETBIOSNAME}: <code>DC1</code><br />
:*${NISDOMAIN}: <code>samdom</code><br />
<br />
# sed -i -e 's/\${DOMAINDN}/<u>DC=samdom,DC=example,DC=com</u>/g' \<br />
-e 's/\${NETBIOSNAME}/<u>DC1</u>/g' \<br />
-e 's/\${NISDOMAIN}/<u>samdom</u>/g' \<br />
/tmp/ypServ30.ldif<br />
<br />
* Import the modified LDIF file to the local <code>/usr/local/samba/private/sam.ldb</code> Samba AD database:<br />
<br />
# ldbmodify -H /usr/local/samba/private/sam.ldb /tmp/ypServ30.ldif --option="dsdb:schema update allowed"=true<br />
Modified 55 records successfully<br />
<br />
* Start the Samba service.<br />
<br />
The AD replicates the updated schema to all DCs in the forest.<br />
<br />
<br />
<br />
<br />
<br />
----<br />
[[Category:Active Directory]]</div>Hortimechhttps://wiki.samba.org/index.php?title=Setting_up_RFC2307_in_AD&diff=19123Setting up RFC2307 in AD2023-11-26T15:10:23Z<p>Hortimech: /* Verifying That the NIS Extensions Are Installed in Active Directory */</p>
<hr />
<div>= Introduction =<br />
<br />
The use of [https://www.rfc-editor.org/rfc/rfc2307.txt RFC 2307] attributes allows the storage of Unix user and group information in an LDAP directory. In an Active Directory (AD) with Linux integration, this has several advantages:<br />
* Central administration of IDs in AD.<br />
* Consistent IDs on all Linux domain members that use the Samba <code>idmap_ad</code> ID map back end.<br />
* Fast configuration of attributes.<br />
* No local ID mapping databases that can corrupt and lead to lose of file ownerships.<br />
* Enable the administrator to set individual login shells and home directory paths for users.<br />
* Login shell and home directory settings are the same on all domain members using Samba <code>idmap_ad</code> ID map back end and <code>winbind nss info = rfc2307</code> parameter.<br />
* Easy management from Windows clients using the Active Directory Users and Computers (ADUC) Microsoft management console (MMC). For details, see [[Maintaining_Unix_Attributes_in_AD_using_ADUC|Maintaining Unix Attributes in AD using ADUC]].<br />
<br />
<br />
<br />
<br />
<br />
== RFC2307 on AD Domain Controllers ==<br />
<br />
It is recommended to only have the sysvol and netlogon shares on an AD DC, so using RFC2307 id-mappings on the DC is not required. If you want to enable RFC2307 ID mappings on the DC for whatever reason e.g. you have other shares on the DC (not recommended) and are using the winbind 'ad' backend on Unix domain members, you need to ensure that the <code>idmap_ldb:use rfc2307</code> parameter exists in the <code>[global]</code> section of your <code>smb.conf</code> file on the Samba DC and is set to <code>yes</code> :<br />
<br />
idmap_ldb:use rfc2307 = yes<br />
<br />
{{Imbox<br />
| type = note<br />
| text = It is not recommended to use RFC2307 mappings on Samba AD DC's. The default idmap.ldb mechanism is fine for domain controllers and less error prone.<br />
}}<br />
<br />
<br />
<br />
<br />
<br />
== Verifying That the NIS Extensions Are Installed in Active Directory ==<br />
<br />
Verify if the <code>ypServ30</code> LDAP tree exists in your Active Directory (AD):<br />
<br />
# ldbsearch -H /usr/local/samba/private/sam.ldb -s base -b \<br />
CN=ypservers,CN=ypServ30,CN=RpcServices,CN=System,DC=samdom,DC=example,DC=com cn<br />
<br />
The output should be:<br />
<br />
# record 1<br />
dn: CN=ypservers,CN=ypServ30,CN=RpcServices,CN=System,DC=samdom,DC=example,DC=com<br />
cn: ypservers<br />
<br />
# returned 1 records<br />
# 1 entries<br />
# 0 referrals<br />
<br />
If the <code>ldbsearch</code> command returns 1 record, the NIS Extensions are installed and there is nothing else to do.<br />
<br />
{{Imbox<br />
| type = note<br />
| text = The NIS Extensions are only required if you are going to use the ADUC Unix Attributes tabs to manage your users and groups.<br />
}}<br />
<br />
== Provisioning a New Samba Active Directory with RFC2307 Enabled ==<br />
<br />
When you provision a new Samba AD forest, pass the <code>--use-rfc2307</code> to the <code>samba-tool domain provision</code> command to auto-install the NIS extensions. For example:<br />
<br />
# samba-tool domain provision --use-rfc2307 ...<br />
<br />
For details, see [[Setting_up_Samba_as_an_Active_Directory_Domain_Controller#Provisioning_a_Samba_Active_Directory|Provisioning a Samba Active Directory]].<br />
<br />
Additionally, enable the the Samba RFC2307 module. For details, see [[#Enabling_the_RFC2307_Configuration_Parameter|Enabling the RFC2307 Configuration Parameter]].<br />
<br />
<br />
<br />
== Installing the RFC2307 NIS Extensions after AD DC Provisioning ==<br />
<br />
Do not run this procedure if you provisioned your Active Directory (AD) with the <code>--use-rfc2307</code> parameter. For details, see [[#Provisioning_a_New_Samba_Active_Directory_with_RFC2307_Enabled|Provisioning a New Samba Active Directory with RFC2307 Enabled]].<br />
<br />
{{Imbox<br />
| type = warning<br />
| text = Updating the Schema can break your AD. Verify you have a working backup before updating the schema.<br />
}}<br />
<br />
To install the NIS extensions:<br />
<br />
* Locate the domain controller (DC) with the <code>Schema Master</code> flexible single-master operations (FSMO) role:<br />
<br />
# samba-tool fsmo show | grep SchemaMasterRole<br />
SchemaMasterRole owner: CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=samdom,DC=example,DC=com<br />
<br />
: The output shows the name of the DC owning this role. Run all further steps on this DC.<br />
<br />
* Shut down the Samba service.<br />
<br />
* Create a copy of the <code>ypServ30.ldif</code> schema file. For example:<br />
<br />
# cp /usr/local/samba/share/setup/ypServ30.ldif /tmp/<br />
<br />
* Replace the variables in copied LDIF file with the domain distinguished name (DN), NetBIOS name, and the NIS domain of your setup. For example:<br />
:*${DOMAINDN}: <code>DC=samdom,DC=example,DC=com</code><br />
:*${NETBIOSNAME}: <code>DC1</code><br />
:*${NISDOMAIN}: <code>samdom</code><br />
<br />
# sed -i -e 's/\${DOMAINDN}/<u>DC=samdom,DC=example,DC=com</u>/g' \<br />
-e 's/\${NETBIOSNAME}/<u>DC1</u>/g' \<br />
-e 's/\${NISDOMAIN}/<u>samdom</u>/g' \<br />
/tmp/ypServ30.ldif<br />
<br />
* Import the modified LDIF file to the local <code>/usr/local/samba/private/sam.ldb</code> Samba AD database:<br />
<br />
# ldbmodify -H /usr/local/samba/private/sam.ldb /tmp/ypServ30.ldif --option="dsdb:schema update allowed"=true<br />
Modified 55 records successfully<br />
<br />
* Start the Samba service.<br />
<br />
The AD replicates the updated schema to all DCs in the forest.<br />
<br />
<br />
<br />
<br />
<br />
----<br />
[[Category:Active Directory]]</div>Hortimechhttps://wiki.samba.org/index.php?title=Setting_up_Samba_as_a_Domain_Member&diff=19108Setting up Samba as a Domain Member2023-10-28T06:55:37Z<p>Hortimech: /*Updated a note */</p>
<hr />
<div>= Introduction =<br />
<br />
A Samba domain member is a Linux machine joined to a domain that is running Samba and does not provide domain services, such as an NT4 primary domain controller (PDC) or Active Directory (AD) domain controller (DC).<br />
<br />
On a Samba domain member, you can:<br />
<br />
* Use domain users and groups in local ACLs on files and directories.<br />
* Set up shares to act as a file server.<br />
* Set up printing services to act as a print server.<br />
* Configure PAM to enable domain users to log on locally or to authenticate to local installed services.<br />
<br />
For details about setting up a Samba NT4 domain or Samba AD, see [[Domain_Control|Domain Control]].<br />
<br />
<br />
{{Imbox<br />
| type = important<br />
| text = For versions of Samba earlier than 4.15.0, never use <code>samba-tool domain provision</code> to create a Unix domain member, it will not work, you must follow the procedure laid out on this page.<br />
}}<br />
<br />
{{Imbox<br />
| type = important<br />
| text = All AD Domain members must be in the same <code>DNS</code> domain and the Realm must be the <code>DNS</code> domain in uppercase. For example, the <code>DNS</code> domain could be <code>samdom.example.com</code> and the Realm would be <code>SAMDOM.EXAMPLE.COM</code>.<br />
}}<br />
<br />
<br />
<br />
= Preparing the Installation =<br />
<br />
== General Preparation ==<br />
<br />
* Verify that no Samba processes are running:<br />
# ps ax | egrep "samba|smbd|nmbd|winbindd"<br />
: If the output lists any <code>samba</code>, <code>smbd</code>, <code>nmbd</code>, or <code>winbindd</code> processes, shut down the processes.<br />
<br />
* If you previously run a Samba installation on this host:<br />
:* Backup the existing <code>smb.conf</code> file. To list the path to the file, enter:<br />
<br />
# smbd -b | grep "CONFIGFILE"<br />
CONFIGFILE: /usr/local/samba/etc/samba/smb.conf<br />
<br />
:* Remove all Samba database files, such as <code>*.tdb</code> and <code>*.ldb</code> files. To list the folders containing Samba databases:<br />
<br />
# smbd -b | egrep "LOCKDIR|STATEDIR|CACHEDIR|PRIVATE_DIR"<br />
LOCKDIR: /usr/local/samba/var/lock/<br />
STATEDIR: /usr/local/samba/var/locks/<br />
CACHEDIR: /usr/local/samba/var/cache/<br />
PRIVATE_DIR: /usr/local/samba/private/<br />
<br />
: Starting with a clean environment helps you to prevent confusion, and no files from your previous Samba installation are mixed with your new domain member installation.<br />
<br />
<br />
<br />
== Preparing a Domain Member to Join an Active Directory Domain ==<br />
<br />
=== Configuring DNS ===<br />
<br />
{{:Linux and Unix DNS Configuration}}<br />
<br />
<br />
<br />
<br />
<br />
=== Configuring Kerberos ===<br />
<br />
Samba supports Heimdal and MIT Kerberos back ends. To configure Kerberos on the domain member, set the following in your <code>/etc/krb5.conf</code> file:<br />
<br />
[libdefaults]<br />
default_realm = SAMDOM.EXAMPLE.COM<br />
dns_lookup_realm = false<br />
dns_lookup_kdc = true<br />
<br />
The previous example configures Kerberos for the <code>SAMDOM.EXAMPLE.COM</code> realm.<br />
<br />
The Samba teams recommends to not set any further parameters in the <code>/etc/krb5.conf</code> file.<br />
<br />
If your <code>/etc/krb5.conf</code> contains an <code>include</code> line it will not work, you '''Must''' remove this line.<br />
<br />
On some Linux distributions that use MIT Kerberos, it is necessary to add these lines for proper ID mapping:<br />
<br />
[plugins]<br />
localauth = {<br />
module = winbind:/usr/lib64/samba/krb5/winbind_krb5_localauth.so<br />
enable_only = winbind<br />
}<br />
<br />
These settings could also be necessary <code>/etc/security/pam_winbind.conf</code>:<br />
<br />
[global]<br />
krb5_auth = yes<br />
krb5_ccache_type = FILE<br />
<br />
With distributions with crypto-policies, this command must be issued to update the system policy support for Active Directory:<br />
<br />
<code>update-crypto-policies --set DEFAULT:AD-SUPPORT</code><br />
<br />
<br />
<br />
<br />
<br />
=== Configuring Time Synchronisation ===<br />
<br />
Kerberos requires a synchronised time on all domain members. Thus it is recommended to set up an NTP client. For further details, see [[Time_Synchronisation#Configuring_Time_Synchronisation_on_a_Unix_Domain_Member|Configuring Time Synchronisation on a Unix Domain Member]].<br />
<br />
<br />
<br />
<br />
<br />
=== Local Host Name Resolution ===<br />
<br />
When you join the host to the domain, Samba tries to register the host name in the AD DNS zone. For this, the <code>net</code> utility must be able to resolve the host name using DNS or using a correct entry in the <code>/etc/hosts</code> file.<br />
<br />
To verify that your host name resolves correctly, use the <code>getent hosts</code> command. For example:<br />
<br />
# getent hosts M1<br />
10.99.0.5 M1.samdom.example.com M1<br />
<br />
The host name and FQDN must not resolve to the <code>127.0.0.1</code> IP address or any other IP address other than the one used on the LAN interface of the domain member.<br />
<br />
If no output is displayed or the host is resolved to the wrong IP address and you are not using dhcp, set the correct entry in the <code>/etc/hosts</code> file. For example:<br />
<br />
127.0.0.1 localhost<br />
10.99.0.5 M1.samdom.example.com M1<br />
<br />
If you are using dhcp, check that <code>/etc/hosts</code> only contains the '127.0.0.1' line shown above. If you continue to have problems, contact the sysadmin who controls your DHCP server.<br />
<br />
if you need to add aliases to the machine hostname, add them to the end of the line that starts with the machines ipaddress, not the 127.0.0.1 line.<br />
<br />
<br />
<br />
<br />
== Preparing a Domain Member to Join an NT4 Domain ==<br />
<br />
For joining a host to an NT4 domain, no preparation is required.<br />
<br />
<br />
<br />
<br />
<br />
= Installing Samba =<br />
<br />
For details, see [[Installing_Samba|Installing Samba]].<br />
<br />
{{Imbox<br />
| type = note<br />
| text = Install a maintained Samba version. For details, see [[Samba_Release_Planning|Samba Release Planning]].<br />
}}<br />
<br />
<br />
<br />
<br />
<br />
= Configuring Samba =<br />
<br />
<br />
<br />
Samba can use various winbind idmap backends, The three main ones are:<br />
* ad<br />
* autorid<br />
* rid<br />
<br />
<br />
=== Choosing an idmap backend ===<br />
<br />
It can appear to be a complex decision choosing which winbind idmap backend to use, hopefully reading this can point you to the one to use.<br />
<br />
<br />
* If you require users and groups to have the same IDs everywhere, or have different login shells and Unix home directory paths, then you need to use the winbind idmap 'ad' backend and add RFC2307 attributes to AD.<br />
<br />
<br />
If you use the 'ad' backend, the RFC2307 attributes (uidNumber, gidNumber, etc) are not added automatically when users or groups are created, you must add them manually.<br />
<br />
The ID numbers found on a DC (numbers in the 3000000 range) are NOT rfc2307 attributes They cannot and will not be used on Unix Domain Members, you can add uidNumber & gidNumber attributes to AD and use the winbind 'ad' backend on Unix Domain Members. If you do decide to add uidNumber & gidNumber attributes to AD, you do not need to use numbers in the 3000000 range and it would definitely be a good idea to use a different range.<br />
<br />
<br />
* If you only need users and groups to have Unix IDs, you can use the 'rid' or 'autorid' idmap winbind backend.<br />
<br />
<br />
The 'rid' or 'autorid' idmap winbind backends calculate the user and group IDs from the Windows RID. If you use the 'rid' idmap backend and the same [global] section of the smb.conf on every Unix domain member, you will get the same IDs. Using these idmap backends, you do not add anything to AD and any added RFC2307 attributes will be ignored. When using these backends you can set the 'template shell' and 'template homedir' parameters in the smb.conf global section and everyone will get the login shell and Unix home directory path you set. If you do not set 'template shell' or 'template homedir', the defaults, '/bin/false' and '/home/%D/%U' , will be used.<br />
<br />
<br />
Once you Have decided which winbind idmap backend to use, you have to choose the ranges to use with 'idmap config' in smb.conf.<br />
<br />
By default on a Unix domain member, there are multiple blocks of users & groups:<br />
<br />
The local system users & groups: These will be from 0-999<br />
The local Unix users and groups: These start at 1000<br />
The SAMDOM domain users and groups: ADUC, by default, starts these at 10000<br />
The default domain '*' also known as the 'well Known SIDs': ????<br />
Trusted domains: ????<br />
Anything that isn't a 'well Known SID' or a member of SAMDOM or a trusted domain: ????<br />
<br />
<br />
As you can see from the above, if you are creating a new domain, you shouldn't set either the default domain '*' or the 'SAMDOM' ranges to start at 999 or less, as they would interfere with the local system users & groups. You also should leave a space for any local Unix users & groups, so starting the 'idmap config' ranges at 3000 seems to be a good compromise.<br />
<br />
Bearing the above information in mind, you could set the 'idmap config' ranges to the following:<br />
<br />
:{| class="wikitable"<br />
!Domain<br />
!Range<br />
|-<br />
|<code>*</code><br />
|'''3000-7999'''<br />
|-<br />
|<code>DOMAIN</code><br />
|'''10000-999999'''<br />
|}<br />
<br />
You could also have any trusted domains starting at:<br />
<br />
:{| class="wikitable"<br />
!Domain<br />
!Range<br />
|-<br />
|<code>TRUSTED</code><br />
|'''1000000-9999999'''<br />
|}<br />
<br />
If you set the default domain '*' range above the 'SAMDOM' domain range, the ranges will conflict if the domain grows to the point that the next ID would be the same as the default domain range start ID.<br />
<br />
With the above suggested ranges, no range will overlap or interfere with another.<br />
<br />
You may also have seen examples of the '*' range being used for everything, this should only be used with the 'autorid' idmap backend.<br />
<br />
<br />
== Setting up a Basic <code>smb.conf</code> File ==<br />
<br />
<br />
{{Imbox<br />
| type = warning<br />
| text = ID mapping back ends are not supported in the <code>smb.conf</code> file on a Samba Active Directory (AD) domain controller (DC).<br />Do not add any idmap config lines to a Samba Active Directory (AD) domain controller (DC) smb.conf<br />For details, see [[Updating_Samba#Updating_Samba#Failure_To_Access_Shares_on_Domain_Controllers_If_idmap_config_Parameters_Set_in_the_smb.conf_File|Failure to Access Shares on Domain Controllers If idmap config Parameters Set in the smb.conf File]].<br />
}}<br />
<br />
<br />
Before joining the domain, configure the domain member's <code>smb.conf</code> file:<br />
<br />
* To locate the file, enter:<br />
<br />
# smbd -b | grep CONFIGFILE<br />
CONFIGFILE: /etc/samba/smb.conf<br />
<br />
<br />
<br />
The following table lists the most important idmap backends with links to their documentation, click the relevant <code>Documentation</code> link for how to setup each idmap backend:<br />
<br />
:{| class="wikitable"<br />
!Back End<br />
!Documentation<br />
!Man Page<br />
|-<br />
|<code>rid</code><br />
|'''[[Idmap_config_rid|idmap config rid]]'''<br />
|<code>idmap_rid(8)</code><br />
|-<br />
|<code>autorid</code><br />
|'''[[Idmap_config_autorid|idmap config autorid]]'''<br />
|<code>idmap_autorid(8)</code><br />
|-<br />
|<code>ad</code><br />
|'''[[Idmap_config_ad|idmap config ad]]'''<br />
|<code>idmap_ad(8)</code><br />
|-<br />
|<code>hash</code><br />
|'''<Do not use>'''<br />
|<code>idmap_hash(8)</code><br />
|-<br />
|<code>ldap</code><br />
|<br />
|<code>idmap_ldap(8)</code><br />
|-<br />
|<code>nss</code><br />
|<br />
|<code>idmap_nss(8)</code><br />
|}<br />
<br />
:{{Imbox<br />
| type = important<br />
| text = Add an additional ID mapping configuration for every trusted domain, unless you use the <code>autorid</code> idmap backend (where this is optional). The ID ranges of the default (<code>*</code>) domain and other domains configured in the <code>smb.conf</code> file must not overlap.<br />
}}<br />
<br />
{{Imbox<br />
| type = note<br />
| text = After selecting an idmap backend and configuring the <code>smb.conf</code> file, following the relevant wiki page for your chosen idmap backend, you should have a basic <code>smb.conf</code> file that will allow the computer to join the Active Directory domain. There are a multitude of other parameters that you can add to the <code>smb.conf</code> file, some will be relevant to your domain, others will not, please read the <code>smb.conf</code> manpage for your Samba version to find the available parameters. If in doubt, post a question to the samba mailing list.<br />
}}<br />
<br />
== Mapping the Domain Administrator Account to the Local <code>root</code> User ==<br />
<br />
Samba enables you to map domain accounts to a local account. Use this feature to execute file operations on the domain member's file system as a different user than the account that requested the operation on the client.<br />
<br />
{{Imbox<br />
| type = note<br />
| text = You should map the domain Administrator account to the local <code>root</code> account on a Unix domain member. Configuring the mapping allows the domain Administrator to execute file operations as <code>root</code> on the Unix domain member. When you map Administrator to the <code>root</code> account, you should not attempt to log onto a Unix domain member as Administrator. Only follow the method below to map <code>Administrator</code> to <code>root</code>.<br />
}}<br />
{{Imbox<br />
| type = note<br />
| text = If, for any reason, you change the domain Administrator account name, you must use your new name for <code>Administrator</code> in the following instead of <code>Administrator</code>. <br />
}}<br />
<br />
<br />
To map the domain administrator to the local <code>root</code> account:<br />
<br />
* Add the following parameter to the <code>[global]</code> section of your <code>smb.conf</code> file:<br />
<br />
username map = /usr/local/samba/etc/user.map<br />
<br />
* Create the <code>/usr/local/samba/etc/user.map</code> file with the following content:<br />
<br />
!root = SAMDOM\Administrator<br />
<br />
:{{Imbox<br />
| type = important<br />
| text = When using the <code>ad</code> ID mapping back end, never set a <code>uidNumber</code> attribute for the domain Administrator account. If the account has the attribute set, the value will override the local UID <code>0</code> of the <code>root</code> user on Samba AD DC's and thus the mapping fails.<br />
}}<br />
<br />
For further details, see <code>username map</code> parameter in the <code>smb.conf(5)</code> man page.<br />
<br />
= Joining the Domain =<br />
<br />
* To join the host to an Active Directory (AD), enter:<br />
<br />
# net ads join -U administrator<br />
Enter administrator's password: Passw0rd<br />
Using short domain name -- SAMDOM<br />
Joined 'M1' to dns domain 'samdom.example.com'<br />
<br />
{{Imbox<br />
| type = note<br />
| text = When you join a computer to an AD domain with <code>net ads join</code>, the computers forward dns record should be created (if not already existing), but, if your computer has a fixed ipaddress, you will have to create the reverse PTR record yourself. <br />
}}<br />
<br />
<br />
* To join the host to an NT4 domain, enter:<br />
<br />
# net rpc join -U administrator<br />
Enter administrator's password: Passw0rd<br />
Joined domain SAMDOM.<br />
<br />
<br />
<br />
== Joining the Domain with samba-tool (>4.15.0 only) ==<br />
<br />
{{Imbox<br />
| type = important<br />
| text = Before Samba 4.15.0 , you could not join a Unix domain member using <code>samba-tool domain join</code>, this option was unsupported, did not work and would cause problems with your AD replication. You can only use <code>samba-tool domain join</code> if the Unix domain member has Samba >= 4.15.0 installed.<br />
}}<br />
<br />
* To join the host to an Active Directory (AD), enter:<br />
<br />
# samba-tool domain join samdom.example.com MEMBER -U administrator<br />
<br />
If you have problems joining the domain, check your configuration. For further help, see [[Troubleshooting_Samba_Domain_Members|Troubleshooting Samba Domain Members]].<br />
<br />
<br />
<br />
<br />
<br />
= Configuring the Name Service Switch =<br />
<br />
To enable the name service switch (NSS) library to make domain users and groups available to the local system:<br />
<br />
* Append the <code>winbind</code> entry to the following databases in the <code>/etc/nsswitch.conf</code> file:<br />
<br />
passwd: files <u>winbind</u><br />
group: files <u>winbind</u><br />
<br />
:* Keep the <code>files</code> entry as first source for both databases. This enables NSS to look up domain users and groups from the <code>/etc/passwd</code> and <code>/etc/group</code> files before querying the Winbind service.<br />
<br />
:* Do not add the <code>winbind</code> entry to the NSS <code>shadow</code> database. This can cause the <code>wbinfo</code> utility fail.<br />
<br />
:{{Imbox<br />
| type = note<br />
| text = If there's a line containing an <code>initgroups</code> directive, add <code> [success=continue] winbind</code>, otherwise the NSS library will not ask winbindd for a user's additional group memberships. Do not add the <code>initgroups</code> line if it does not exist.<br />
}}<br />
<br />
:{{Imbox<br />
| type = warning<br />
| text = Do not use the same user names in the local <code>/etc/passwd</code> file as in the domain.<br />
}}<br />
<br />
:{{Imbox<br />
| type = warning<br />
| text = Do not use local Unix names when changing file and directory ownership on Samba domain shares.<br />
}}<br />
<br />
:{{Imbox<br />
| type = note<br />
| text = If you compiled Samba, add symbolic links from the <code>libnss_winbind</code> library to the operating system's library path. For details, see [[Libnss_winbind_Links|libnss_winbind Links]]. If you used packages to install Samba, the link is usually created automatically.<br />
}}<br />
<br />
<br />
<br />
<br />
<br />
= Starting the Services =<br />
<br />
Start the following services to have a fully functioning Unix domain member:<br />
<br />
* The <code>smbd</code> service<br />
<br />
* The <code>nmbd</code> service<br />
<br />
* The <code>winbindd</code> service<br />
<br />
<br />
:{{Imbox<br />
| type = note<br />
| text = If you do not require Network Browsing, you do not need to start the <code>nmbd</code> service on a Unix domain member.<br />
}}<br />
<br />
<br />
:{{Imbox<br />
| type = important<br />
| text = The latest versions of Samba (from 4.11.0) now only use SMBv2 as the minimum client & server protocols. This means that anything that relies on SMBv1 will not work, unless you manually set <code>client min protocol = NT1</code> and <code>server min protocol = NT1</code> in <code>smb.conf</code>. Samba no longer recommends using SMBv1.<br />
}}<br />
<br />
<br />
:{{Imbox<br />
| type = note<br />
| text = You must not start the <code>samba</code> service on a domain member. This service is required only on Active Directory (AD) domain controllers (DC).<br />
}}<br />
<br />
<br />
Samba does not provide System V init scripts, <code>systemd</code>, <code>upstart</code>, or service files for other init services.<br />
* If you installed Samba using packages, use the script or service configuration file provided by the package to start Samba.<br />
* If you built Samba, see your distribution's documentation for how to create a script or configuration to start services.<br />
<br />
<br />
<br />
<br />
<br />
= Testing the Winbindd Connectivity =<br />
<br />
== Sending a Winbindd Ping ==<br />
<br />
To verify if the Winbindd service is able to connect to Active Directory (AD) Domain Controllers (DC) or a primary domain controller (PDC), enter:<br />
<br />
# wbinfo --ping-dc<br />
checking the NETLOGON for domain[SAMDOM] dc connection to "DC.SAMDOM.EXAMPLE.COM" succeeded<br />
<br />
If the previous command fails, verify:<br />
* That the <code>winbindd</code> service is running.<br />
* Your <code>smb.conf</code> file is set up correctly.<br />
<br />
<br />
<br />
== Using Domain Accounts and Groups in Operating System Commands ==<br />
<br />
=== Looking up Domain Users and Groups ===<br />
<br />
The <code>libnss_winbind</code> library enables you to look up domain users and groups. For example:<br />
<br />
* To look up the domain user <code>SAMDOM\demo01</code>:<br />
<br />
# getent passwd SAMDOM\\demo01<br />
SAMDOM\demo01:*:10000:10000:demo01:/home/demo01:/bin/bash<br />
<br />
* To look up the domain group <code>Domain Users</code>:<br />
<br />
# getent group "SAMDOM\\Domain Users"<br />
SAMDOM\domain users:x:10000:<br />
<br />
<br />
<br />
=== Assigning File Permissions to Domain Users and Groups ===<br />
<br />
The name service switch (NSS) library enables you to use domain user accounts and groups in commands. For example to set the owner of a file to the <code>demo01</code> domain user and the group to the <code>Domain Users</code> domain group, enter:<br />
<br />
# chown "SAMDOM\\demo01:SAMDOM\\domain users" file.txt<br />
<br />
<br />
<br />
<br />
<br />
= Setting up Additional Services on the Domain Member =<br />
<br />
On a Samba domain member, you can additionally set up:<br />
* File shares to act as a file server. For details, see [[Samba_File_Serving|Samba File Serving]].<br />
* Print services to act as a print server. For details, see [[Print_Server_Support|Print Server Support]].<br />
* PAM authentication of domain users for local services. For details, see [[Authenticating_Domain_Users_Using_PAM|Authenticating Domain Users Using PAM]].<br />
<br />
<br />
<br />
<br />
<br />
= Troubleshooting =<br />
<br />
For details, see [[Troubleshooting_Samba_Domain_Members|Troubleshooting Samba Domain Members]].<br />
<br />
<br />
<br />
<br />
<br />
----<br />
[[Category:Active Directory]]<br />
[[Category:Domain Members]]<br />
[[Category:NT4 Domains]]</div>Hortimechhttps://wiki.samba.org/index.php?title=Setting_up_Samba_as_a_Domain_Member&diff=19103Setting up Samba as a Domain Member2023-10-18T09:07:26Z<p>Hortimech: /* remove duplicate 'are'</p>
<hr />
<div>= Introduction =<br />
<br />
A Samba domain member is a Linux machine joined to a domain that is running Samba and does not provide domain services, such as an NT4 primary domain controller (PDC) or Active Directory (AD) domain controller (DC).<br />
<br />
On a Samba domain member, you can:<br />
<br />
* Use domain users and groups in local ACLs on files and directories.<br />
* Set up shares to act as a file server.<br />
* Set up printing services to act as a print server.<br />
* Configure PAM to enable domain users to log on locally or to authenticate to local installed services.<br />
<br />
For details about setting up a Samba NT4 domain or Samba AD, see [[Domain_Control|Domain Control]].<br />
<br />
<br />
{{Imbox<br />
| type = important<br />
| text = For versions of Samba earlier than 4.15.0, never use <code>samba-tool domain provision</code> to create a Unix domain member, it will not work, you must follow the procedure laid out on this page.<br />
}}<br />
<br />
{{Imbox<br />
| type = important<br />
| text = All AD Domain members must be in the same <code>DNS</code> domain and the Realm must be the <code>DNS</code> domain in uppercase. For example, the <code>DNS</code> domain could be <code>samdom.example.com</code> and the Realm would be <code>SAMDOM.EXAMPLE.COM</code>.<br />
}}<br />
<br />
<br />
<br />
= Preparing the Installation =<br />
<br />
== General Preparation ==<br />
<br />
* Verify that no Samba processes are running:<br />
# ps ax | egrep "samba|smbd|nmbd|winbindd"<br />
: If the output lists any <code>samba</code>, <code>smbd</code>, <code>nmbd</code>, or <code>winbindd</code> processes, shut down the processes.<br />
<br />
* If you previously run a Samba installation on this host:<br />
:* Backup the existing <code>smb.conf</code> file. To list the path to the file, enter:<br />
<br />
# smbd -b | grep "CONFIGFILE"<br />
CONFIGFILE: /usr/local/samba/etc/samba/smb.conf<br />
<br />
:* Remove all Samba database files, such as <code>*.tdb</code> and <code>*.ldb</code> files. To list the folders containing Samba databases:<br />
<br />
# smbd -b | egrep "LOCKDIR|STATEDIR|CACHEDIR|PRIVATE_DIR"<br />
LOCKDIR: /usr/local/samba/var/lock/<br />
STATEDIR: /usr/local/samba/var/locks/<br />
CACHEDIR: /usr/local/samba/var/cache/<br />
PRIVATE_DIR: /usr/local/samba/private/<br />
<br />
: Starting with a clean environment helps you to prevent confusion, and no files from your previous Samba installation are mixed with your new domain member installation.<br />
<br />
<br />
<br />
== Preparing a Domain Member to Join an Active Directory Domain ==<br />
<br />
=== Configuring DNS ===<br />
<br />
{{:Linux and Unix DNS Configuration}}<br />
<br />
<br />
<br />
<br />
<br />
=== Configuring Kerberos ===<br />
<br />
Samba supports Heimdal and MIT Kerberos back ends. To configure Kerberos on the domain member, set the following in your <code>/etc/krb5.conf</code> file:<br />
<br />
[libdefaults]<br />
default_realm = SAMDOM.EXAMPLE.COM<br />
dns_lookup_realm = false<br />
dns_lookup_kdc = true<br />
<br />
The previous example configures Kerberos for the <code>SAMDOM.EXAMPLE.COM</code> realm.<br />
<br />
The Samba teams recommends to not set any further parameters in the <code>/etc/krb5.conf</code> file.<br />
<br />
If your <code>/etc/krb5.conf</code> contains an <code>include</code> line it will not work, you '''Must''' remove this line.<br />
<br />
On some Linux distributions that use MIT Kerberos, it is necessary to add these lines for proper ID mapping:<br />
<br />
[plugins]<br />
localauth = {<br />
module = winbind:/usr/lib64/samba/krb5/winbind_krb5_localauth.so<br />
enable_only = winbind<br />
}<br />
<br />
These settings could also be necessary <code>/etc/security/pam_winbind.conf</code>:<br />
<br />
[global]<br />
krb5_auth = yes<br />
krb5_ccache_type = FILE<br />
<br />
With distributions with crypto-policies, this command must be issued to update the system policy support for Active Directory:<br />
<br />
<code>update-crypto-policies --set DEFAULT:AD-SUPPORT</code><br />
<br />
<br />
<br />
<br />
<br />
=== Configuring Time Synchronisation ===<br />
<br />
Kerberos requires a synchronised time on all domain members. Thus it is recommended to set up an NTP client. For further details, see [[Time_Synchronisation#Configuring_Time_Synchronisation_on_a_Unix_Domain_Member|Configuring Time Synchronisation on a Unix Domain Member]].<br />
<br />
<br />
<br />
<br />
<br />
=== Local Host Name Resolution ===<br />
<br />
When you join the host to the domain, Samba tries to register the host name in the AD DNS zone. For this, the <code>net</code> utility must be able to resolve the host name using DNS or using a correct entry in the <code>/etc/hosts</code> file.<br />
<br />
To verify that your host name resolves correctly, use the <code>getent hosts</code> command. For example:<br />
<br />
# getent hosts M1<br />
10.99.0.5 M1.samdom.example.com M1<br />
<br />
The host name and FQDN must not resolve to the <code>127.0.0.1</code> IP address or any other IP address other than the one used on the LAN interface of the domain member.<br />
<br />
If no output is displayed or the host is resolved to the wrong IP address and you are not using dhcp, set the correct entry in the <code>/etc/hosts</code> file. For example:<br />
<br />
127.0.0.1 localhost<br />
10.99.0.5 M1.samdom.example.com M1<br />
<br />
If you are using dhcp, check that <code>/etc/hosts</code> only contains the '127.0.0.1' line shown above. If you continue to have problems, contact the sysadmin who controls your DHCP server.<br />
<br />
if you need to add aliases to the machine hostname, add them to the end of the line that starts with the machines ipaddress, not the 127.0.0.1 line.<br />
<br />
<br />
<br />
<br />
== Preparing a Domain Member to Join an NT4 Domain ==<br />
<br />
For joining a host to an NT4 domain, no preparation is required.<br />
<br />
<br />
<br />
<br />
<br />
= Installing Samba =<br />
<br />
For details, see [[Installing_Samba|Installing Samba]].<br />
<br />
{{Imbox<br />
| type = note<br />
| text = Install a maintained Samba version. For details, see [[Samba_Release_Planning|Samba Release Planning]].<br />
}}<br />
<br />
<br />
<br />
<br />
<br />
= Configuring Samba =<br />
<br />
<br />
<br />
Samba can use various winbind idmap backends, The three main ones are:<br />
* ad<br />
* autorid<br />
* rid<br />
<br />
<br />
=== Choosing an idmap backend ===<br />
<br />
It can appear to be a complex decision choosing which winbind idmap backend to use, hopefully reading this can point you to the one to use.<br />
<br />
<br />
* If you require users and groups to have the same IDs everywhere, or have different login shells and Unix home directory paths, then you need to use the winbind idmap 'ad' backend and add RFC2307 attributes to AD.<br />
<br />
<br />
If you use the 'ad' backend, the RFC2307 attributes (uidNumber, gidNumber, etc) are not added automatically when users or groups are created, you must add them manually.<br />
<br />
The ID numbers found on a DC (numbers in the 3000000 range) are NOT rfc2307 attributes They cannot and will not be used on Unix Domain Members, you can add uidNumber & gidNumber attributes to AD and use the winbind 'ad' backend on Unix Domain Members. If you do decide to add uidNumber & gidNumber attributes to AD, you do not need to use numbers in the 3000000 range and it would definitely be a good idea to use a different range.<br />
<br />
<br />
* If you only need users and groups to have Unix IDs, you can use the 'rid' or 'autorid' idmap winbind backend.<br />
<br />
<br />
The 'rid' or 'autorid' idmap winbind backends calculate the user and group IDs from the Windows RID. If you use the 'rid' idmap backend and the same [global] section of the smb.conf on every Unix domain member, you will get the same IDs. Using these idmap backends, you do not add anything to AD and any added RFC2307 attributes will be ignored. When using these backends you can set the 'template shell' and 'template homedir' parameters in the smb.conf global section and everyone will get the login shell and Unix home directory path you set. If you do not set 'template shell' or 'template homedir', the defaults, '/bin/false' and '/home/%D/%U' , will be used.<br />
<br />
<br />
Once you Have decided which winbind idmap backend to use, you have to choose the ranges to use with 'idmap config' in smb.conf.<br />
<br />
By default on a Unix domain member, there are multiple blocks of users & groups:<br />
<br />
The local system users & groups: These will be from 0-999<br />
The local Unix users and groups: These start at 1000<br />
The SAMDOM domain users and groups: ADUC, by default, starts these at 10000<br />
The default domain '*' also known as the 'well Known SIDs': ????<br />
Trusted domains: ????<br />
Anything that isn't a 'well Known SID' or a member of SAMDOM or a trusted domain: ????<br />
<br />
<br />
As you can see from the above, if you are creating a new domain, you shouldn't set either the default domain '*' or the 'SAMDOM' ranges to start at 999 or less, as they would interfere with the local system users & groups. You also should leave a space for any local Unix users & groups, so starting the 'idmap config' ranges at 3000 seems to be a good compromise.<br />
<br />
Bearing the above information in mind, you could set the 'idmap config' ranges to the following:<br />
<br />
:{| class="wikitable"<br />
!Domain<br />
!Range<br />
|-<br />
|<code>*</code><br />
|'''3000-7999'''<br />
|-<br />
|<code>DOMAIN</code><br />
|'''10000-999999'''<br />
|}<br />
<br />
You could also have any trusted domains starting at:<br />
<br />
:{| class="wikitable"<br />
!Domain<br />
!Range<br />
|-<br />
|<code>TRUSTED</code><br />
|'''1000000-9999999'''<br />
|}<br />
<br />
If you set the default domain '*' range above the 'SAMDOM' domain range, the ranges will conflict if the domain grows to the point that the next ID would be the same as the default domain range start ID.<br />
<br />
With the above suggested ranges, no range will overlap or interfere with another.<br />
<br />
You may also have seen examples of the '*' range being used for everything, this should only be used with the 'autorid' idmap backend.<br />
<br />
<br />
== Setting up a Basic <code>smb.conf</code> File ==<br />
<br />
<br />
{{Imbox<br />
| type = warning<br />
| text = ID mapping back ends are not supported in the <code>smb.conf</code> file on a Samba Active Directory (AD) domain controller (DC).<br />Do not add any idmap config lines to a Samba Active Directory (AD) domain controller (DC) smb.conf<br />For details, see [[Updating_Samba#Updating_Samba#Failure_To_Access_Shares_on_Domain_Controllers_If_idmap_config_Parameters_Set_in_the_smb.conf_File|Failure to Access Shares on Domain Controllers If idmap config Parameters Set in the smb.conf File]].<br />
}}<br />
<br />
<br />
Before joining the domain, configure the domain member's <code>smb.conf</code> file:<br />
<br />
* To locate the file, enter:<br />
<br />
# smbd -b | grep CONFIGFILE<br />
CONFIGFILE: /etc/samba/smb.conf<br />
<br />
<br />
<br />
The following table lists the most important idmap backends with links to their documentation, click the relevant <code>Documentation</code> link for how to setup each idmap backend:<br />
<br />
:{| class="wikitable"<br />
!Back End<br />
!Documentation<br />
!Man Page<br />
|-<br />
|<code>rid</code><br />
|'''[[Idmap_config_rid|idmap config rid]]'''<br />
|<code>idmap_rid(8)</code><br />
|-<br />
|<code>autorid</code><br />
|'''[[Idmap_config_autorid|idmap config autorid]]'''<br />
|<code>idmap_autorid(8)</code><br />
|-<br />
|<code>ad</code><br />
|'''[[Idmap_config_ad|idmap config ad]]'''<br />
|<code>idmap_ad(8)</code><br />
|-<br />
|<code>hash</code><br />
|'''<Do not use>'''<br />
|<code>idmap_hash(8)</code><br />
|-<br />
|<code>ldap</code><br />
|<br />
|<code>idmap_ldap(8)</code><br />
|-<br />
|<code>nss</code><br />
|<br />
|<code>idmap_nss(8)</code><br />
|}<br />
<br />
:{{Imbox<br />
| type = important<br />
| text = Add an additional ID mapping configuration for every trusted domain, unless you use the <code>autorid</code> idmap backend (where this is optional). The ID ranges of the default (<code>*</code>) domain and other domains configured in the <code>smb.conf</code> file must not overlap.<br />
}}<br />
<br />
{{Imbox<br />
| type = note<br />
| text = After selecting an idmap backend and configuring the <code>smb.conf</code> file, following the relevant wiki page for your chosen idmap backend, you should have a basic <code>smb.conf</code> file that will allow the computer to join the Active Directory domain. There are a multitude of other parameters that you can add to the <code>smb.conf</code> file, some will be relevant to your domain, others will not, please read the <code>smb.conf</code> manpage for your Samba version to find the available parameters. If in doubt, post a question to the samba mailing list.<br />
}}<br />
<br />
== Mapping the Domain Administrator Account to the Local <code>root</code> User ==<br />
<br />
Samba enables you to map domain accounts to a local account. Use this feature to execute file operations on the domain member's file system as a different user than the account that requested the operation on the client.<br />
<br />
{{Imbox<br />
| type = note<br />
| text = You should map the domain Administrator account to the local <code>root</code> account on a Unix domain member. Configuring the mapping allows the domain Administrator to execute file operations as <code>root</code> on the Unix domain member. When you map Administrator to the <code>root</code> account, you should not attempt to log onto a Unix domain member as Administrator. Only follow the method below to map <code>Administrator</code> to <code>root</code>.<br />
}}<br />
{{Imbox<br />
| type = note<br />
| text = If you have changed the domain Administrator account name, use the new admin name in the following instead of <code>Administrator</code>. <br />
}}<br />
<br />
<br />
To map the domain administrator to the local <code>root</code> account:<br />
<br />
* Add the following parameter to the <code>[global]</code> section of your <code>smb.conf</code> file:<br />
<br />
username map = /usr/local/samba/etc/user.map<br />
<br />
* Create the <code>/usr/local/samba/etc/user.map</code> file with the following content:<br />
<br />
!root = SAMDOM\Administrator<br />
<br />
:{{Imbox<br />
| type = important<br />
| text = When using the <code>ad</code> ID mapping back end, never set a <code>uidNumber</code> attribute for the domain Administrator account. If the account has the attribute set, the value will override the local UID <code>0</code> of the <code>root</code> user on Samba AD DC's and thus the mapping fails.<br />
}}<br />
<br />
For further details, see <code>username map</code> parameter in the <code>smb.conf(5)</code> man page.<br />
<br />
<br />
<br />
<br />
<br />
= Joining the Domain =<br />
<br />
* To join the host to an Active Directory (AD), enter:<br />
<br />
# net ads join -U administrator<br />
Enter administrator's password: Passw0rd<br />
Using short domain name -- SAMDOM<br />
Joined 'M1' to dns domain 'samdom.example.com'<br />
<br />
{{Imbox<br />
| type = note<br />
| text = When you join a computer to an AD domain with <code>net ads join</code>, the computers forward dns record should be created (if not already existing), but, if your computer has a fixed ipaddress, you will have to create the reverse PTR record yourself. <br />
}}<br />
<br />
<br />
* To join the host to an NT4 domain, enter:<br />
<br />
# net rpc join -U administrator<br />
Enter administrator's password: Passw0rd<br />
Joined domain SAMDOM.<br />
<br />
<br />
<br />
== Joining the Domain with samba-tool (>4.15.0 only) ==<br />
<br />
{{Imbox<br />
| type = important<br />
| text = Before Samba 4.15.0 , you could not join a Unix domain member using <code>samba-tool domain join</code>, this option was unsupported, did not work and would cause problems with your AD replication. You can only use <code>samba-tool domain join</code> if the Unix domain member has Samba >= 4.15.0 installed.<br />
}}<br />
<br />
* To join the host to an Active Directory (AD), enter:<br />
<br />
# samba-tool domain join samdom.example.com MEMBER -U administrator<br />
<br />
If you have problems joining the domain, check your configuration. For further help, see [[Troubleshooting_Samba_Domain_Members|Troubleshooting Samba Domain Members]].<br />
<br />
<br />
<br />
<br />
<br />
= Configuring the Name Service Switch =<br />
<br />
To enable the name service switch (NSS) library to make domain users and groups available to the local system:<br />
<br />
* Append the <code>winbind</code> entry to the following databases in the <code>/etc/nsswitch.conf</code> file:<br />
<br />
passwd: files <u>winbind</u><br />
group: files <u>winbind</u><br />
<br />
:* Keep the <code>files</code> entry as first source for both databases. This enables NSS to look up domain users and groups from the <code>/etc/passwd</code> and <code>/etc/group</code> files before querying the Winbind service.<br />
<br />
:* Do not add the <code>winbind</code> entry to the NSS <code>shadow</code> database. This can cause the <code>wbinfo</code> utility fail.<br />
<br />
:{{Imbox<br />
| type = note<br />
| text = If there's a line containing an <code>initgroups</code> directive, add <code> [success=continue] winbind</code>, otherwise the NSS library will not ask winbindd for a user's additional group memberships. Do not add the <code>initgroups</code> line if it does not exist.<br />
}}<br />
<br />
:{{Imbox<br />
| type = warning<br />
| text = Do not use the same user names in the local <code>/etc/passwd</code> file as in the domain.<br />
}}<br />
<br />
:{{Imbox<br />
| type = warning<br />
| text = Do not use local Unix names when changing file and directory ownership on Samba domain shares.<br />
}}<br />
<br />
:{{Imbox<br />
| type = note<br />
| text = If you compiled Samba, add symbolic links from the <code>libnss_winbind</code> library to the operating system's library path. For details, see [[Libnss_winbind_Links|libnss_winbind Links]]. If you used packages to install Samba, the link is usually created automatically.<br />
}}<br />
<br />
<br />
<br />
<br />
<br />
= Starting the Services =<br />
<br />
Start the following services to have a fully functioning Unix domain member:<br />
<br />
* The <code>smbd</code> service<br />
<br />
* The <code>nmbd</code> service<br />
<br />
* The <code>winbindd</code> service<br />
<br />
<br />
:{{Imbox<br />
| type = note<br />
| text = If you do not require Network Browsing, you do not need to start the <code>nmbd</code> service on a Unix domain member.<br />
}}<br />
<br />
<br />
:{{Imbox<br />
| type = important<br />
| text = The latest versions of Samba (from 4.11.0) now only use SMBv2 as the minimum client & server protocols. This means that anything that relies on SMBv1 will not work, unless you manually set <code>client min protocol = NT1</code> and <code>server min protocol = NT1</code> in <code>smb.conf</code>. Samba no longer recommends using SMBv1.<br />
}}<br />
<br />
<br />
:{{Imbox<br />
| type = note<br />
| text = You must not start the <code>samba</code> service on a domain member. This service is required only on Active Directory (AD) domain controllers (DC).<br />
}}<br />
<br />
<br />
Samba does not provide System V init scripts, <code>systemd</code>, <code>upstart</code>, or service files for other init services.<br />
* If you installed Samba using packages, use the script or service configuration file provided by the package to start Samba.<br />
* If you built Samba, see your distribution's documentation for how to create a script or configuration to start services.<br />
<br />
<br />
<br />
<br />
<br />
= Testing the Winbindd Connectivity =<br />
<br />
== Sending a Winbindd Ping ==<br />
<br />
To verify if the Winbindd service is able to connect to Active Directory (AD) Domain Controllers (DC) or a primary domain controller (PDC), enter:<br />
<br />
# wbinfo --ping-dc<br />
checking the NETLOGON for domain[SAMDOM] dc connection to "DC.SAMDOM.EXAMPLE.COM" succeeded<br />
<br />
If the previous command fails, verify:<br />
* That the <code>winbindd</code> service is running.<br />
* Your <code>smb.conf</code> file is set up correctly.<br />
<br />
<br />
<br />
== Using Domain Accounts and Groups in Operating System Commands ==<br />
<br />
=== Looking up Domain Users and Groups ===<br />
<br />
The <code>libnss_winbind</code> library enables you to look up domain users and groups. For example:<br />
<br />
* To look up the domain user <code>SAMDOM\demo01</code>:<br />
<br />
# getent passwd SAMDOM\\demo01<br />
SAMDOM\demo01:*:10000:10000:demo01:/home/demo01:/bin/bash<br />
<br />
* To look up the domain group <code>Domain Users</code>:<br />
<br />
# getent group "SAMDOM\\Domain Users"<br />
SAMDOM\domain users:x:10000:<br />
<br />
<br />
<br />
=== Assigning File Permissions to Domain Users and Groups ===<br />
<br />
The name service switch (NSS) library enables you to use domain user accounts and groups in commands. For example to set the owner of a file to the <code>demo01</code> domain user and the group to the <code>Domain Users</code> domain group, enter:<br />
<br />
# chown "SAMDOM\\demo01:SAMDOM\\domain users" file.txt<br />
<br />
<br />
<br />
<br />
<br />
= Setting up Additional Services on the Domain Member =<br />
<br />
On a Samba domain member, you can additionally set up:<br />
* File shares to act as a file server. For details, see [[Samba_File_Serving|Samba File Serving]].<br />
* Print services to act as a print server. For details, see [[Print_Server_Support|Print Server Support]].<br />
* PAM authentication of domain users for local services. For details, see [[Authenticating_Domain_Users_Using_PAM|Authenticating Domain Users Using PAM]].<br />
<br />
<br />
<br />
<br />
<br />
= Troubleshooting =<br />
<br />
For details, see [[Troubleshooting_Samba_Domain_Members|Troubleshooting Samba Domain Members]].<br />
<br />
<br />
<br />
<br />
<br />
----<br />
[[Category:Active Directory]]<br />
[[Category:Domain Members]]<br />
[[Category:NT4 Domains]]</div>Hortimechhttps://wiki.samba.org/index.php?title=Linux_and_Unix_DNS_Configuration&diff=19086Linux and Unix DNS Configuration2023-10-09T17:38:43Z<p>Hortimech: </p>
<hr />
<div><noinclude><br />
__TOC__<br />
<br />
<br />
<br />
= Introduction =<br />
</noinclude><br />
Active Directory (AD) uses DNS in the background, to locate other DCs and services, such as Kerberos. Thus AD domain members and servers must be able to resolve the AD DNS zones.<br />
<br />
The following describes how to manually configure Linux clients to use DNS servers. If you are running a DHCP server providing DNS settings to your client computers, configure your DHCP server to send the IP addresses of your DNS servers.<br />
<br />
== Configuring the /etc/resolv.conf ==<br />
<br />
Set the DNS server IP and AD DNS domain in your <code>/etc/resolv.conf</code>. For example:<br />
<br />
nameserver 10.99.0.1<br />
search samdom.example.com<br />
<br />
Some utilities, such as NetworkManager can overwrite manual changes in that file. See your distribution's documentation for information about how to configure name resolution permanently.<br />
<br />
For NetworkManager, set the DNS server using either the graphical interface or nmcli and restart the NetworkManager service. The visible /etc/resolv.conf file:<br />
<br />
nameserver 127.0.0.53<br />
search samdom.example.com<br />
<br />
won't list the DNS server explicitly but nevertheless works correctly.<br />
<br />
<br />
<br />
{{Imbox<br />
| type = note<br />
| text = At this point, if you are joining a new AD DC, then its records will not exist, so there is no point in testing for them. Continue with joining your new AD DC and return here, if required, once the join has succeeded.<br />
}}<br />
<br />
<br />
<br />
<br />
<br />
== Testing DNS resolution ==<br />
<br />
{{:Testing_the_DNS_Name_Resolution}}<br />
<br />
<br />
<br />
<br />
----<br />
[[Category:Active Directory]]<br />
[[Category:Domain Members]]</div>Hortimechhttps://wiki.samba.org/index.php?title=Setting_up_Samba_as_a_Domain_Member&diff=19084Setting up Samba as a Domain Member2023-09-27T15:23:42Z<p>Hortimech: </p>
<hr />
<div>= Introduction =<br />
<br />
A Samba domain member is a Linux machine joined to a domain that is running Samba and does not provide domain services, such as an NT4 primary domain controller (PDC) or Active Directory (AD) domain controller (DC).<br />
<br />
On a Samba domain member, you can:<br />
<br />
* Use domain users and groups in local ACLs on files and directories.<br />
* Set up shares to act as a file server.<br />
* Set up printing services to act as a print server.<br />
* Configure PAM to enable domain users to log on locally or to authenticate to local installed services.<br />
<br />
For details about setting up a Samba NT4 domain or Samba AD, see [[Domain_Control|Domain Control]].<br />
<br />
<br />
{{Imbox<br />
| type = important<br />
| text = For versions of Samba earlier than 4.15.0, never use <code>samba-tool domain provision</code> to create a Unix domain member, it will not work, you must follow the procedure laid out on this page.<br />
}}<br />
<br />
{{Imbox<br />
| type = important<br />
| text = All AD Domain members must be in the same <code>DNS</code> domain and the Realm must be the <code>DNS</code> domain in uppercase. For example, the <code>DNS</code> domain could be <code>samdom.example.com</code> and the Realm would be <code>SAMDOM.EXAMPLE.COM</code>.<br />
}}<br />
<br />
<br />
<br />
= Preparing the Installation =<br />
<br />
== General Preparation ==<br />
<br />
* Verify that no Samba processes are running:<br />
# ps ax | egrep "samba|smbd|nmbd|winbindd"<br />
: If the output lists any <code>samba</code>, <code>smbd</code>, <code>nmbd</code>, or <code>winbindd</code> processes, shut down the processes.<br />
<br />
* If you previously run a Samba installation on this host:<br />
:* Backup the existing <code>smb.conf</code> file. To list the path to the file, enter:<br />
<br />
# smbd -b | grep "CONFIGFILE"<br />
CONFIGFILE: /usr/local/samba/etc/samba/smb.conf<br />
<br />
:* Remove all Samba database files, such as <code>*.tdb</code> and <code>*.ldb</code> files. To list the folders containing Samba databases:<br />
<br />
# smbd -b | egrep "LOCKDIR|STATEDIR|CACHEDIR|PRIVATE_DIR"<br />
LOCKDIR: /usr/local/samba/var/lock/<br />
STATEDIR: /usr/local/samba/var/locks/<br />
CACHEDIR: /usr/local/samba/var/cache/<br />
PRIVATE_DIR: /usr/local/samba/private/<br />
<br />
: Starting with a clean environment helps you to prevent confusion, and no files from your previous Samba installation are mixed with your new domain member installation.<br />
<br />
<br />
<br />
== Preparing a Domain Member to Join an Active Directory Domain ==<br />
<br />
=== Configuring DNS ===<br />
<br />
{{:Linux and Unix DNS Configuration}}<br />
<br />
<br />
<br />
<br />
<br />
=== Configuring Kerberos ===<br />
<br />
Samba supports Heimdal and MIT Kerberos back ends. To configure Kerberos on the domain member, set the following in your <code>/etc/krb5.conf</code> file:<br />
<br />
[libdefaults]<br />
default_realm = SAMDOM.EXAMPLE.COM<br />
dns_lookup_realm = false<br />
dns_lookup_kdc = true<br />
<br />
The previous example configures Kerberos for the <code>SAMDOM.EXAMPLE.COM</code> realm.<br />
<br />
The Samba teams recommends to not set any further parameters in the <code>/etc/krb5.conf</code> file.<br />
<br />
If your <code>/etc/krb5.conf</code> contains an <code>include</code> line it will not work, you '''Must''' remove this line.<br />
<br />
On some Linux distributions that use MIT Kerberos, it is necessary to add these lines for proper ID mapping:<br />
<br />
[plugins]<br />
localauth = {<br />
module = winbind:/usr/lib64/samba/krb5/winbind_krb5_localauth.so<br />
enable_only = winbind<br />
}<br />
<br />
These settings could also be necessary <code>/etc/security/pam_winbind.conf</code>:<br />
<br />
[global]<br />
krb5_auth = yes<br />
krb5_ccache_type = FILE<br />
<br />
With distributions with crypto-policies, this command must be issued to update the system policy support for Active Directory:<br />
<br />
<code>update-crypto-policies --set DEFAULT:AD-SUPPORT</code><br />
<br />
<br />
<br />
<br />
<br />
=== Configuring Time Synchronisation ===<br />
<br />
Kerberos requires a synchronised time on all domain members. Thus it is recommended to set up an NTP client. For further details, see [[Time_Synchronisation#Configuring_Time_Synchronisation_on_a_Unix_Domain_Member|Configuring Time Synchronisation on a Unix Domain Member]].<br />
<br />
<br />
<br />
<br />
<br />
=== Local Host Name Resolution ===<br />
<br />
When you join the host to the domain, Samba tries to register the host name in the AD DNS zone. For this, the <code>net</code> utility must be able to resolve the host name using DNS or using a correct entry in the <code>/etc/hosts</code> file.<br />
<br />
To verify that your host name resolves correctly, use the <code>getent hosts</code> command. For example:<br />
<br />
# getent hosts M1<br />
10.99.0.5 M1.samdom.example.com M1<br />
<br />
The host name and FQDN must not resolve to the <code>127.0.0.1</code> IP address or any other IP address other than the one used on the LAN interface of the domain member.<br />
<br />
If no output is displayed or the host is resolved to the wrong IP address and you are not using dhcp, set the correct entry in the <code>/etc/hosts</code> file. For example:<br />
<br />
127.0.0.1 localhost<br />
10.99.0.5 M1.samdom.example.com M1<br />
<br />
If you are using dhcp, check that <code>/etc/hosts</code> only contains the '127.0.0.1' line shown above. If you continue to have problems, contact the sysadmin who controls your DHCP server.<br />
<br />
if you need to add aliases to the machine hostname, add them to the end of the line that starts with the machines ipaddress, not the 127.0.0.1 line.<br />
<br />
<br />
<br />
<br />
== Preparing a Domain Member to Join an NT4 Domain ==<br />
<br />
For joining a host to an NT4 domain, no preparation is required.<br />
<br />
<br />
<br />
<br />
<br />
= Installing Samba =<br />
<br />
For details, see [[Installing_Samba|Installing Samba]].<br />
<br />
{{Imbox<br />
| type = note<br />
| text = Install a maintained Samba version. For details, see [[Samba_Release_Planning|Samba Release Planning]].<br />
}}<br />
<br />
<br />
<br />
<br />
<br />
= Configuring Samba =<br />
<br />
<br />
<br />
Samba can use various winbind idmap backends, The three main ones are:<br />
* ad<br />
* autorid<br />
* rid<br />
<br />
<br />
=== Choosing an idmap backend ===<br />
<br />
It can appear to be a complex decision choosing which winbind idmap backend to use, hopefully reading this can point you to the one to use.<br />
<br />
<br />
* If you require users and groups to have the same IDs everywhere, or have different login shells and Unix home directory paths, then you need to use the winbind idmap 'ad' backend and add RFC2307 attributes to AD.<br />
<br />
<br />
If you use the 'ad' backend, the RFC2307 attributes (uidNumber, gidNumber, etc) are not added automatically when users or groups are created, you must add them manually.<br />
<br />
The ID numbers found on a DC (numbers in the 3000000 range) are NOT rfc2307 attributes They cannot and will not be used on Unix Domain Members, you can add uidNumber & gidNumber attributes to AD and use the winbind 'ad' backend on Unix Domain Members. If you do decide to add uidNumber & gidNumber attributes to AD, you do not need to use numbers in the 3000000 range and it would definitely be a good idea to use a different range.<br />
<br />
<br />
* If you only need users and groups to have Unix IDs, you can use the 'rid' or 'autorid' idmap winbind backend.<br />
<br />
<br />
The 'rid' or 'autorid' idmap winbind backends calculate the user and group IDs from the Windows RID. If you use the 'rid' idmap backend and the same [global] section of the smb.conf on every Unix domain member, you will get the same IDs. Using these idmap backends, you do not add anything to AD and any added RFC2307 attributes will be ignored. When using these backends you can set the 'template shell' and 'template homedir' parameters in the smb.conf global section and everyone will get the login shell and Unix home directory path you set. If you do not set 'template shell' or 'template homedir', the defaults, '/bin/false' and '/home/%D/%U' , will be used.<br />
<br />
<br />
Once you Have decided which winbind idmap backend to use, you have to choose the ranges to use with 'idmap config' in smb.conf.<br />
<br />
By default on a Unix domain member, there are multiple blocks of users & groups:<br />
<br />
The local system users & groups: These will be from 0-999<br />
The local Unix users and groups: These start at 1000<br />
The SAMDOM domain users and groups: ADUC, by default, starts these at 10000<br />
The default domain '*' also known as the 'well Known SIDs': ????<br />
Trusted domains: ????<br />
Anything that isn't a 'well Known SID' or a member of SAMDOM or a trusted domain: ????<br />
<br />
<br />
As you can see from the above, if you are creating a new domain, you shouldn't set either the default domain '*' or the 'SAMDOM' ranges to start at 999 or less, as they would interfere with the local system users & groups. You also should leave a space for any local Unix users & groups, so starting the 'idmap config' ranges at 3000 seems to be a good compromise.<br />
<br />
Bearing the above information in mind, you could set the 'idmap config' ranges to the following:<br />
<br />
:{| class="wikitable"<br />
!Domain<br />
!Range<br />
|-<br />
|<code>*</code><br />
|'''3000-7999'''<br />
|-<br />
|<code>DOMAIN</code><br />
|'''10000-999999'''<br />
|}<br />
<br />
You could also have any trusted domains starting at:<br />
<br />
:{| class="wikitable"<br />
!Domain<br />
!Range<br />
|-<br />
|<code>TRUSTED</code><br />
|'''1000000-9999999'''<br />
|}<br />
<br />
If you set the default domain '*' range above the 'SAMDOM' domain range, the ranges will conflict if the domain grows to the point that the next ID would be the same as the default domain range start ID.<br />
<br />
With the above suggested ranges, no range will overlap or interfere with another.<br />
<br />
You may also have seen examples of the '*' range being used for everything, this should only be used with the 'autorid' idmap backend.<br />
<br />
<br />
== Setting up a Basic <code>smb.conf</code> File ==<br />
<br />
<br />
{{Imbox<br />
| type = warning<br />
| text = ID mapping back ends are not supported in the <code>smb.conf</code> file on a Samba Active Directory (AD) domain controller (DC).<br />Do not add any idmap config lines to a Samba Active Directory (AD) domain controller (DC) smb.conf<br />For details, see [[Updating_Samba#Updating_Samba#Failure_To_Access_Shares_on_Domain_Controllers_If_idmap_config_Parameters_Set_in_the_smb.conf_File|Failure to Access Shares on Domain Controllers If idmap config Parameters Set in the smb.conf File]].<br />
}}<br />
<br />
<br />
Before joining the domain, configure the domain member's <code>smb.conf</code> file:<br />
<br />
* To locate the file, enter:<br />
<br />
# smbd -b | grep CONFIGFILE<br />
CONFIGFILE: /etc/samba/smb.conf<br />
<br />
<br />
<br />
The following table lists the most important idmap backends with links to their documentation, click the relevant <code>Documentation</code> link for how to setup each idmap backend:<br />
<br />
:{| class="wikitable"<br />
!Back End<br />
!Documentation<br />
!Man Page<br />
|-<br />
|<code>rid</code><br />
|'''[[Idmap_config_rid|idmap config rid]]'''<br />
|<code>idmap_rid(8)</code><br />
|-<br />
|<code>autorid</code><br />
|'''[[Idmap_config_autorid|idmap config autorid]]'''<br />
|<code>idmap_autorid(8)</code><br />
|-<br />
|<code>ad</code><br />
|'''[[Idmap_config_ad|idmap config ad]]'''<br />
|<code>idmap_ad(8)</code><br />
|-<br />
|<code>hash</code><br />
|'''<Do not use>'''<br />
|<code>idmap_hash(8)</code><br />
|-<br />
|<code>ldap</code><br />
|<br />
|<code>idmap_ldap(8)</code><br />
|-<br />
|<code>nss</code><br />
|<br />
|<code>idmap_nss(8)</code><br />
|}<br />
<br />
:{{Imbox<br />
| type = important<br />
| text = Add an additional ID mapping configuration for every trusted domain, unless you use the <code>autorid</code> idmap backend (where this is optional). The ID ranges of the default (<code>*</code>) domain and other domains configured in the <code>smb.conf</code> file must not overlap.<br />
}}<br />
<br />
{{Imbox<br />
| type = note<br />
| text = After selecting an idmap backend and configuring the <code>smb.conf</code> file, following the relevant wiki page for your chosen idmap backend, you should have a basic <code>smb.conf</code> file that will allow the computer to join the Active Directory domain. There are are a multitude of other parameters that you can add to the <code>smb.conf</code> file, some will be relevant to your domain, others will not, please read the <code>smb.conf</code> manpage for your Samba version to find the available parameters. If in doubt, post a question to the samba mailing list.<br />
}}<br />
<br />
<br />
<br />
<br />
<br />
== Mapping the Domain Administrator Account to the Local <code>root</code> User ==<br />
<br />
Samba enables you to map domain accounts to a local account. Use this feature to execute file operations on the domain member's file system as a different user than the account that requested the operation on the client.<br />
<br />
{{Imbox<br />
| type = note<br />
| text = You should map the domain Administrator account to the local <code>root</code> account on a Unix domain member. Configuring the mapping allows the domain Administrator to execute file operations as <code>root</code> on the Unix domain member. When you map Administrator to the <code>root</code> account, you should not attempt to log onto a Unix domain member as Administrator. Only follow the method below to map <code>Administrator</code> to <code>root</code>.<br />
}}<br />
{{Imbox<br />
| type = note<br />
| text = If you have changed the domain Administrator account name, use the new admin name in the following instead of <code>Administrator</code>. <br />
}}<br />
<br />
<br />
To map the domain administrator to the local <code>root</code> account:<br />
<br />
* Add the following parameter to the <code>[global]</code> section of your <code>smb.conf</code> file:<br />
<br />
username map = /usr/local/samba/etc/user.map<br />
<br />
* Create the <code>/usr/local/samba/etc/user.map</code> file with the following content:<br />
<br />
!root = SAMDOM\Administrator<br />
<br />
:{{Imbox<br />
| type = important<br />
| text = When using the <code>ad</code> ID mapping back end, never set a <code>uidNumber</code> attribute for the domain Administrator account. If the account has the attribute set, the value will override the local UID <code>0</code> of the <code>root</code> user on Samba AD DC's and thus the mapping fails.<br />
}}<br />
<br />
For further details, see <code>username map</code> parameter in the <code>smb.conf(5)</code> man page.<br />
<br />
<br />
<br />
<br />
<br />
= Joining the Domain =<br />
<br />
* To join the host to an Active Directory (AD), enter:<br />
<br />
# net ads join -U administrator<br />
Enter administrator's password: Passw0rd<br />
Using short domain name -- SAMDOM<br />
Joined 'M1' to dns domain 'samdom.example.com'<br />
<br />
{{Imbox<br />
| type = note<br />
| text = When you join a computer to an AD domain with <code>net ads join</code>, the computers forward dns record should be created (if not already existing), but, if your computer has a fixed ipaddress, you will have to create the reverse PTR record yourself. <br />
}}<br />
<br />
<br />
* To join the host to an NT4 domain, enter:<br />
<br />
# net rpc join -U administrator<br />
Enter administrator's password: Passw0rd<br />
Joined domain SAMDOM.<br />
<br />
<br />
<br />
== Joining the Domain with samba-tool (>4.15.0 only) ==<br />
<br />
{{Imbox<br />
| type = important<br />
| text = Before Samba 4.15.0 , you could not join a Unix domain member using <code>samba-tool domain join</code>, this option was unsupported, did not work and would cause problems with your AD replication. You can only use <code>samba-tool domain join</code> if the Unix domain member has Samba >= 4.15.0 installed.<br />
}}<br />
<br />
* To join the host to an Active Directory (AD), enter:<br />
<br />
# samba-tool domain join samdom.example.com MEMBER -U administrator<br />
<br />
If you have problems joining the domain, check your configuration. For further help, see [[Troubleshooting_Samba_Domain_Members|Troubleshooting Samba Domain Members]].<br />
<br />
<br />
<br />
<br />
<br />
= Configuring the Name Service Switch =<br />
<br />
To enable the name service switch (NSS) library to make domain users and groups available to the local system:<br />
<br />
* Append the <code>winbind</code> entry to the following databases in the <code>/etc/nsswitch.conf</code> file:<br />
<br />
passwd: files <u>winbind</u><br />
group: files <u>winbind</u><br />
<br />
:* Keep the <code>files</code> entry as first source for both databases. This enables NSS to look up domain users and groups from the <code>/etc/passwd</code> and <code>/etc/group</code> files before querying the Winbind service.<br />
<br />
:* Do not add the <code>winbind</code> entry to the NSS <code>shadow</code> database. This can cause the <code>wbinfo</code> utility fail.<br />
<br />
:{{Imbox<br />
| type = note<br />
| text = If there's a line containing an <code>initgroups</code> directive, add <code> [success=continue] winbind</code>, otherwise the NSS library will not ask winbindd for a user's additional group memberships. Do not add the <code>initgroups</code> line if it does not exist.<br />
}}<br />
<br />
:{{Imbox<br />
| type = warning<br />
| text = Do not use the same user names in the local <code>/etc/passwd</code> file as in the domain.<br />
}}<br />
<br />
:{{Imbox<br />
| type = warning<br />
| text = Do not use local Unix names when changing file and directory ownership on Samba domain shares.<br />
}}<br />
<br />
:{{Imbox<br />
| type = note<br />
| text = If you compiled Samba, add symbolic links from the <code>libnss_winbind</code> library to the operating system's library path. For details, see [[Libnss_winbind_Links|libnss_winbind Links]]. If you used packages to install Samba, the link is usually created automatically.<br />
}}<br />
<br />
<br />
<br />
<br />
<br />
= Starting the Services =<br />
<br />
Start the following services to have a fully functioning Unix domain member:<br />
<br />
* The <code>smbd</code> service<br />
<br />
* The <code>nmbd</code> service<br />
<br />
* The <code>winbindd</code> service<br />
<br />
<br />
:{{Imbox<br />
| type = note<br />
| text = If you do not require Network Browsing, you do not need to start the <code>nmbd</code> service on a Unix domain member.<br />
}}<br />
<br />
<br />
:{{Imbox<br />
| type = important<br />
| text = The latest versions of Samba (from 4.11.0) now only use SMBv2 as the minimum client & server protocols. This means that anything that relies on SMBv1 will not work, unless you manually set <code>client min protocol = NT1</code> and <code>server min protocol = NT1</code> in <code>smb.conf</code>. Samba no longer recommends using SMBv1.<br />
}}<br />
<br />
<br />
:{{Imbox<br />
| type = note<br />
| text = You must not start the <code>samba</code> service on a domain member. This service is required only on Active Directory (AD) domain controllers (DC).<br />
}}<br />
<br />
<br />
Samba does not provide System V init scripts, <code>systemd</code>, <code>upstart</code>, or service files for other init services.<br />
* If you installed Samba using packages, use the script or service configuration file provided by the package to start Samba.<br />
* If you built Samba, see your distribution's documentation for how to create a script or configuration to start services.<br />
<br />
<br />
<br />
<br />
<br />
= Testing the Winbindd Connectivity =<br />
<br />
== Sending a Winbindd Ping ==<br />
<br />
To verify if the Winbindd service is able to connect to Active Directory (AD) Domain Controllers (DC) or a primary domain controller (PDC), enter:<br />
<br />
# wbinfo --ping-dc<br />
checking the NETLOGON for domain[SAMDOM] dc connection to "DC.SAMDOM.EXAMPLE.COM" succeeded<br />
<br />
If the previous command fails, verify:<br />
* That the <code>winbindd</code> service is running.<br />
* Your <code>smb.conf</code> file is set up correctly.<br />
<br />
<br />
<br />
== Using Domain Accounts and Groups in Operating System Commands ==<br />
<br />
=== Looking up Domain Users and Groups ===<br />
<br />
The <code>libnss_winbind</code> library enables you to look up domain users and groups. For example:<br />
<br />
* To look up the domain user <code>SAMDOM\demo01</code>:<br />
<br />
# getent passwd SAMDOM\\demo01<br />
SAMDOM\demo01:*:10000:10000:demo01:/home/demo01:/bin/bash<br />
<br />
* To look up the domain group <code>Domain Users</code>:<br />
<br />
# getent group "SAMDOM\\Domain Users"<br />
SAMDOM\domain users:x:10000:<br />
<br />
<br />
<br />
=== Assigning File Permissions to Domain Users and Groups ===<br />
<br />
The name service switch (NSS) library enables you to use domain user accounts and groups in commands. For example to set the owner of a file to the <code>demo01</code> domain user and the group to the <code>Domain Users</code> domain group, enter:<br />
<br />
# chown "SAMDOM\\demo01:SAMDOM\\domain users" file.txt<br />
<br />
<br />
<br />
<br />
<br />
= Setting up Additional Services on the Domain Member =<br />
<br />
On a Samba domain member, you can additionally set up:<br />
* File shares to act as a file server. For details, see [[Samba_File_Serving|Samba File Serving]].<br />
* Print services to act as a print server. For details, see [[Print_Server_Support|Print Server Support]].<br />
* PAM authentication of domain users for local services. For details, see [[Authenticating_Domain_Users_Using_PAM|Authenticating Domain Users Using PAM]].<br />
<br />
<br />
<br />
<br />
<br />
= Troubleshooting =<br />
<br />
For details, see [[Troubleshooting_Samba_Domain_Members|Troubleshooting Samba Domain Members]].<br />
<br />
<br />
<br />
<br />
<br />
----<br />
[[Category:Active Directory]]<br />
[[Category:Domain Members]]<br />
[[Category:NT4 Domains]]</div>Hortimechhttps://wiki.samba.org/index.php?title=Linux_and_Unix_DNS_Configuration&diff=19080Linux and Unix DNS Configuration2023-09-26T10:31:02Z<p>Hortimech: </p>
<hr />
<div><noinclude><br />
__TOC__<br />
<br />
<br />
<br />
= Introduction =<br />
</noinclude><br />
Active Directory (AD) uses DNS in the background, to locate other DCs and services, such as Kerberos. Thus AD domain members and servers must be able to resolve the AD DNS zones.<br />
<br />
The following describes how to manually configure Linux clients to use DNS servers. If you are running a DHCP server providing DNS settings to your client computers, configure your DHCP server to send the IP addresses of your DNS servers.<br />
<br />
== Configuring the /etc/resolv.conf ==<br />
<br />
Set the DNS server IP and AD DNS domain in your <code>/etc/resolv.conf</code>. For example:<br />
<br />
nameserver 10.99.0.1<br />
search samdom.example.com<br />
<br />
Some utilities, such as NetworkManager can overwrite manual changes in that file. See your distribution's documentation for information about how to configure name resolution permanently.<br />
<br />
For NetworkManager, set the DNS server using either the graphical interface or nmcli and restart the NetworkManager service. The visible /etc/resolv.conf file:<br />
<br />
nameserver 127.0.0.53<br />
search samdom.example.com<br />
<br />
won't list the DNS server explicitly but nevertheless works correctly.<br />
<br />
{{Imbox<br />
| type = note<br />
| text = At this point, if you are joining a new AD DC, then its records will not exist, so there is no point in testing for them.<br />
}}<br />
<br />
<br />
<br />
<br />
<br />
== Testing DNS resolution ==<br />
<br />
{{:Testing_the_DNS_Name_Resolution}}<br />
<br />
<br />
<br />
<br />
----<br />
[[Category:Active Directory]]<br />
[[Category:Domain Members]]</div>Hortimechhttps://wiki.samba.org/index.php?title=Joining_a_Samba_DC_to_an_Existing_Active_Directory&diff=19079Joining a Samba DC to an Existing Active Directory2023-09-26T10:26:17Z<p>Hortimech: </p>
<hr />
<div>= Introduction =<br />
<br />
Running one domain controller (DC) is sufficient for a working Active Directory (AD) forest. However, for redundancy and load balancing reasons, you should add further DCs to your AD forest. Joining an additional Samba DC to an existing AD differs from provisioning the first DC in a forest. If you set up a new AD forest, see [[Setting_up_Samba_as_an_Active_Directory_Domain_Controller|Setting up Samba as an Active Directory Domain Controller]].<br />
<br />
{{Imbox<br />
| type = warning<br />
| text = Do not provision a Computer as a Samba AD DC, then try to join it to an existing AD domain. This will not work, you only need to run the <code>samba-tool domain join</code> command to join a Computer to the existing AD domain. <br />
}}<br />
<br />
{{Imbox<br />
| type = warning<br />
| text = If you are joining a Samba as a DC to an existing Windows AD domain that was provisioned as a Windows 2003 (or earlier) DC, you must ensure that it is running a domain integrated DNS server. This dns server must be configured with 2008 behaviour. <br />
}}<br />
<br />
{{Imbox<br />
| type = note<br />
| text = An NT4 domain uses only one Primary Domain Controller (PDC) and optionally additional Backup Domain Controllers (BDC). In an AD forest, there is no difference between DCs, except for the [[Flexible_Single-Master_Operations_(FSMO)_Roles|FSMO roles]]. Use only the term "domain controller" or "DC" when you talk about AD to avoid any possibility of confusion.<br />
}}<br />
<br />
<br />
<br />
<br />
<br />
= Preparing the Installation =<br />
<br />
For details, see [[Setting_up_Samba_as_an_Active_Directory_Domain_Controller#Preparing_the_Installation|Preparing the Installation]] in the [[Setting_up_Samba_as_an_Active_Directory_Domain_Controller|Setting up Samba as an Active Directory Domain Controller]] documentation.<br />
<br />
<br />
<br />
<br />
<br />
= Installing Samba =<br />
<br />
For details, see [[Installing_Samba|Installing Samba]].<br />
<br />
{{Imbox<br />
| type = note<br />
| text = Install a maintained Samba version. For details, see [[Samba_Release_Planning|Samba Release Planning]].<br />
}}<br />
<br />
<br />
<br />
<br />
<br />
= Preparing the Host for Joining the Domain =<br />
<br />
== Local DNS server ==<br />
<br />
By default, the first Domain Controller (DC) in a forest runs a DNS server for Active Directory (AD)-based zones. For redundancy reasons it is recommended to run multiple DCs acting as a DNS server in a network. If you consider providing a DNS service on the new DC:<br />
<br />
* For the <code>BIND9_DLZ</code> back end, see [[BIND9_DLZ_DNS_Back_End|BIND9_DLZ DNS Back End]]. Finish this task before you start the Samba DC service.<br />
* For the internal DNS no further actions are required.<br />
<br />
<br />
<br />
== Configuring DNS ==<br />
<br />
{{Imbox<br />
| type = note<br />
| text = The 'nameserver' you set in '/etc/resolv.conf' should be another AD DC, otherwise the join could have difficulty finding a KDC.<br />
}}<br />
<br />
{{Imbox<br />
| type = note<br />
| text = If you are joining a new DC the 'nameserver' you set in '/etc/resolv.conf' must be another AD DC, otherwise the join will not be work. Once the new join has succeeded, you need to change the 'nameserver' to the new DCs ipaddress, do not use '127.0.0.1' or any other IP.<br />
}}<br />
<br />
<br />
For details, see [[Linux_and_Unix_DNS_Configuration|Linux and Unix DNS Configuration]].<br />
<br />
<br />
<br />
<br />
<br />
== Kerberos ==<br />
<br />
Set the following settings in your Kerberos client configuration file <code>/etc/krb5.conf</code>:<br />
<br />
[libdefaults]<br />
dns_lookup_realm = false<br />
dns_lookup_kdc = true<br />
default_realm = SAMDOM.EXAMPLE.COM<br />
<br />
To verify the settings use the <code>kinit</code> command to request a Kerberos ticket for the domain administrator:<br />
<br />
# kinit administrator<br />
Password for administrator@SAMDOM.EXAMPLE.COM:<br />
<br />
To list Kerberos tickets:<br />
<br />
# klist<br />
Ticket cache: FILE:/tmp/krb5cc_0<br />
Default principal: administrator@SAMDOM.EXAMPLE.COM<br />
<br />
Valid starting Expires Service principal<br />
24.09.2015 19:56:55 25.09.2015 05:56:55 krbtgt/SAMDOM.EXAMPLE.COM@SAMDOM.EXAMPLE.COM<br />
renew until 25.09.2015 19:56:53<br />
<br />
<br />
<br />
<br />
<br />
= Configuring Time Synchronisation =<br />
<br />
Kerberos requires a synchronised time on all domain members. For further details and how to set up the <code>ntpd</code> service, see [[Time_Synchronisation|Time Synchronisation]].<br />
<br />
<br />
<br />
<br />
<br />
= Joining the Active Directory as a Domain Controller =<br />
<br />
To join the domain <code>samdom.example.com</code> as a domain controller (DC) that additionally acts as a DNS server using the Samba internal DNS:<br />
<br />
There are three authentication methods you can use, Username & Password or two kerberos methods (the kerberos methods depend on running <code>kinit</code> as an admin user).<br />
<br />
Username & Password:<br />
# samba-tool domain join samdom.example.com DC -U"SAMDOM\administrator"<br />
<br />
Or:<br />
# samba-tool domain join samdom.example.com DC -k yes<br />
<br />
Or:<br />
# samba-tool domain join samdom.example.com DC --use-krb5-ccache=/tmp/krb5cc_0<br />
<br />
Using any of the above, should result in output similar to this:<br />
<br />
Finding a writeable DC for domain 'samdom.example.com'<br />
Found DC dc1.samdom.example.com<br />
Password for [SAMDOM\administrator]:<br />
workgroup is SAMDOM<br />
realm is samdom.example.com<br />
Adding CN=DC2,OU=Domain Controllers,DC=samdom,DC=example,DC=com<br />
Adding CN=DC2,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=samdom,DC=example,DC=com<br />
Adding CN=NTDS Settings,CN=DC2,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=samdom,DC=example,DC=com<br />
Adding SPNs to CN=DC2,OU=Domain Controllers,DC=samdom,DC=example,DC=com<br />
Setting account password for DC2$<br />
Enabling account<br />
Calling bare provision<br />
Looking up IPv4 addresses<br />
Looking up IPv6 addresses<br />
No IPv6 address will be assigned<br />
Setting up share.ldb<br />
Setting up secrets.ldb<br />
Setting up the registry<br />
Setting up the privileges database<br />
Setting up idmap db<br />
Setting up SAM db<br />
Setting up sam.ldb partitions and settings<br />
Setting up sam.ldb rootDSE<br />
Pre-loading the Samba 4 and AD schema<br />
A Kerberos configuration suitable for Samba 4 has been generated at /usr/local/samba/private/krb5.conf<br />
Provision OK for domain DN DC=samdom,DC=example,DC=com<br />
Starting replication<br />
Schema-DN[CN=Schema,CN=Configuration,DC=samdom,DC=example,DC=com] objects[402/1550] linked_values[0/0]<br />
Schema-DN[CN=Schema,CN=Configuration,DC=samdom,DC=example,DC=com] objects[804/1550] linked_values[0/0]<br />
Schema-DN[CN=Schema,CN=Configuration,DC=samdom,DC=example,DC=com] objects[1206/1550] linked_values[0/0]<br />
Schema-DN[CN=Schema,CN=Configuration,DC=samdom,DC=example,DC=com] objects[1550/1550] linked_values[0/0]<br />
Analyze and apply schema objects<br />
Partition[CN=Configuration,DC=samdom,DC=example,DC=com] objects[402/1618] linked_values[0/0]<br />
Partition[CN=Configuration,DC=samdom,DC=example,DC=com] objects[804/1618] linked_values[0/0]<br />
Partition[CN=Configuration,DC=samdom,DC=example,DC=com] objects[1206/1618] linked_values[0/0]<br />
Partition[CN=Configuration,DC=samdom,DC=example,DC=com] objects[1608/1618] linked_values[0/0]<br />
Partition[CN=Configuration,DC=samdom,DC=example,DC=com] objects[1618/1618] linked_values[42/0]<br />
Replicating critical objects from the base DN of the domain<br />
Partition[DC=samdom,DC=example,DC=com] objects[100/100] linked_values[23/0]<br />
Partition[DC=samdom,DC=example,DC=com] objects[386/286] linked_values[23/0]<br />
Done with always replicated NC (base, config, schema)<br />
Replicating DC=DomainDnsZones,DC=samdom,DC=example,DC=com<br />
Partition[DC=DomainDnsZones,DC=samdom,DC=example,DC=com] objects[44/44] linked_values[0/0]<br />
Replicating DC=ForestDnsZones,DC=samdom,DC=example,DC=com<br />
Partition[DC=ForestDnsZones,DC=samdom,DC=example,DC=com] objects[19/19] linked_values[0/0]<br />
Committing SAM database<br />
Sending DsReplicaUpdateRefs for all the replicated partitions<br />
Setting isSynchronized and dsServiceName<br />
Setting up secrets database<br />
Joined domain SAMDOM (SID S-1-5-21-469703510-2364959079-1506205053) as a DC<br />
<br />
See the <code>samba-tool domain join --help</code> command's output for further information.<br />
<br />
Other parameters frequently used with the <code>samba-tool domain join</code> command:<br />
<br />
* <code>--dns-backend=NAMESERVER-BACKEND</code>: Use the supplied DNS server backend. Valid options are <code>SAMBA_INTERNAL</code> or <code>BIND9_DLZ</code>, unless you want to use Bind9, there is no need to supply this option.<br />
:: If you use the internal DNS server, you will not be asked for a forwarder and the one in /etc/resolv.conf will not be obtained automatically. You must supply one with <code>--option="dns forwarder=forwarder_ipaddress"</code>.<br />
<br />
* <code>--site=SITE</code>: Directly join the host as DC to a specific [[Active_Directory_Sites|Active Directory Site]].<br />
<br />
* <code>--option="interfaces=lo eth0" --option="bind interfaces only=yes"</code>: If your server has multiple network interfaces, use these options to bind Samba to the specified interfaces. This enables the <code>samba-tool</code> command to register the correct LAN IP address in the directory during the join.<br />
<br />
{{Imbox<br />
| type = note<br />
| text = If the other DCs are Samba DCs and were provisioned with <code>--use-rfc2307</code>, you Should add <code>--option='idmap_ldb:use rfc2307 = yes'</code> to the join command<br />
}}<br />
<br />
<br />
<br />
<br />
<br />
= Starting the Samba Service =<br />
<br />
To start the <code>samba</code> Samba Active Directory (AD) domain controller (DC) service manually, enter:<br />
<br />
# samba<br />
<br />
Samba does not provide System V init scripts, <code>systemd</code>, <code>upstart</code>, or other services configuration files.<br />
* If you installed Samba using packages, use the script or service configuration file included in the package to start Samba.<br />
* If you built Samba, see [[Managing_the_Samba_AD_DC_Service|Managing the Samba AD DC Service]].<br />
<br />
<br />
<br />
<br />
<br />
= Verifying the DNS Entries =<br />
<br />
{{Imbox<br />
| type = note<br />
| text = Once the join has succeeded You should change the first nameserver in /etc/resolv.conf to the new DC's ipaddress. This will aid in the creation of the required dns records not created by the join.<br />
}}<br />
<br />
If you join a Samba DC that runs Samba 4.7.0 and later, <code>samba-tool</code> will create the required initial DNS entries automatically. To manually create these records on an earlier version, see [[Verifying_and_Creating_a_DC_DNS_Record|Verifying and Creating a DC DNS Record]]. Once Samba starts, the <code>samba_dnsupdate</code> script should create all the other required DNS entries.<br />
<br />
<br />
<br />
<br />
<br />
= Configuring the BIND9_DLZ DNS Back End =<br />
<br />
If you selected the <code>BIND9_DLZ</code> DNS back end during the domain join, set up the BIND configuration. For details, see [[BIND9_DLZ_DNS_Back_End|BIND9_DLZ DNS Back End]].<br />
<br />
<br />
<br />
<br />
<br />
= Built-in User & Group ID Mappings =<br />
{{:SysVol replication (DFS-R)}}<br />
<br />
<br />
To use a Sysvol Replication workaround, all domain controllers (DC) must use the same ID mappings for built-in users and groups.<br />
<br />
By default, a Samba DC stores the user & group IDs in 'xidNumber' attributes in 'idmap.ldb'. Because of the way 'idmap.ldb' works, you cannot guarantee that each DC will use the same ID for a given user or group. To ensure that you do use the same IDs, you must: <br />
<br />
* Create a hot-backup of the <code>/usr/local/samba/private/idmap.ldb</code> file on the existing DC:<br />
<br />
# tdbbackup -s .bak /usr/local/samba/private/idmap.ldb<br />
<br />
: This creates a backup file <code>/usr/local/samba/private/idmap.ldb.bak</code>.<br />
<br />
* Move the backup file to the <code>/usr/local/samba/private/</code> folder on the new joined DC and remove the <code>.bak</code> suffix to replace the existing file.<br />
<br />
* Run <code>net cache flush</code> on the new DC.<br />
<br />
* You will now need to sync Sysvol to the new DC.<br />
<br />
* Reset the Sysvol folder's file system access control lists (ACL) on the new DC:<br />
<br />
# samba-tool ntacl sysvolreset<br />
<br />
<br />
<br />
<br />
<br />
= Verifying Directory Replication =<br />
<br />
After the domain controller (DC) has been started, the knowledge consistency checker (KCC) on the Samba DC creates replication agreements to other DCs in the Active Directory (AD) forest. It can take up to 15 minutes until the KCC creates the auto-generated replication connections.<br />
<br />
For details about how to verify that the directory replication works correctly, see [[Verifying the Directory Replication Statuses]].<br />
<br />
{{Imbox<br />
| type = note<br />
| text = To optimize replication latency and cost, the KCC in Samba 4.5 and later no longer creates a fully-meshed replication topology between all DCs. For further details, see [[The Samba KCC]].<br />
}}<br />
<br />
<br />
<br />
<br />
<br />
= Starting BIND =<br />
<br />
Before you start the BIND daemon, verify that the DNS directory partitions have been successfully replicated:<br />
<br />
# samba-tool drs showrepl<br />
...<br />
==== INBOUND NEIGHBORS ====<br />
...<br />
DC=DomainDnsZones,DC=samdom,DC=example,DC=com<br />
Default-First-Site-Name\DC1 via RPC<br />
DSA object GUID: 4a6bd92a-6612-4b15-aa8c-9ec371e8994f<br />
Last attempt @ Thu Sep 24 20:08:45 2015 CEST was successful<br />
0 consecutive failure(s).<br />
Last success @ Thu Sep 24 20:08:45 2015 CEST<br />
...<br />
DC=ForestDnsZones,DC=samdom,DC=example,DC=com<br />
Default-First-Site-Name\DC1 via RPC<br />
DSA object GUID: 4a6bd92a-6612-4b15-aa8c-9ec371e8994f<br />
Last attempt @ Thu Sep 24 20:08:45 2015 CEST was successful<br />
0 consecutive failure(s).<br />
Last success @ Thu Sep 24 20:08:45 2015 CEST<br />
<br />
If the replication works correctly, start the BIND service. See your distribution's documentation for information how to start a service.<br />
<br />
<br />
<br />
<br />
<br />
= Testing your Samba AD DC =<br />
<br />
== Verifying the File Server ==<br />
<br />
For details, see [[Setting_up_Samba_as_an_Active_Directory_Domain_Controller#Verifying_the_File_Server|Verifying the File Server]] in the [[Setting_up_Samba_as_an_Active_Directory_Domain_Controller|Setting up Samba as an Active Directory Domain Controller]] documentation.<br />
<br />
<br />
<br />
== Testing the Local DNS Server ==<br />
<br />
Skip this step if you selected <code>--dns-backend=NONE</code> during the join.<br />
<br />
Query the local DNS server to resolve the domain name <code>samdom.example.com</code>:<br />
<br />
# host -t A samdom.example.com localhost<br />
Using domain server:<br />
Name: localhost<br />
Address: 127.0.0.1#53<br />
Aliases:<br />
<br />
samdom.example.com has address 10.99.0.1<br />
samdom.example.com has address 10.99.0.2<br />
<br />
The local DNS resolves the domain name to the IP addresses of all domain controllers (DC).<br />
<br />
In case you receive no or a different result, review this documentation and check:<br />
* the system log files,<br />
* the Samba log files,<br />
* the BIND log files, if the <code>BIND9_DLZ</code> is used.<br />
<br />
<br />
<br />
== Verifying Kerberos ==<br />
<br />
For details, see [[Setting_up_Samba_as_an_Active_Directory_Domain_Controller#Verifying_Kerberos|Verifying Kerberos]] in the [[Setting_up_Samba_as_an_Active_Directory_Domain_Controller|Setting up Samba as an Active Directory Domain Controller]] documentation.<br />
<br />
<br />
<br />
<br />
<br />
= DNS Configuration on Domain Controllers =<br />
<br />
The DNS configuration on domain controllers (DC) is important, because if it is unable to locate other DCs the replication will fail.<br />
<br />
Set the local IP of the DC as the primary name server. For example:<br />
<br />
On the new joined DC, use the local <code>10.99.0.2</code> IP as primary <code>nameserver</code> entry:<br />
<br />
nameserver 10.99.0.2<br />
search samdom.example.com<br />
<br />
<br />
<br />
<br />
<br />
= Configuring Winbindd on a Samba AD DC =<br />
<br />
''Optional''. For details, see [[Configuring_Winbindd_on_a_Samba_AD_DC|Configuring Winbindd on a Samba AD DC]].<br />
<br />
<br />
<br />
<br />
<br />
= Using the Domain Controller as a File Server =<br />
<br />
For details, see [[Setting_up_Samba_as_an_Active_Directory_Domain_Controller#Using_the_Domain_Controller_as_a_File_Server|Using the Domain Controller as a File Server]].<br />
<br />
<br />
<br />
<br />
<br />
= Sysvol Replication =<br />
<br />
Samba currently does not automatically replicate Sysvol, you must use some other form of replication. For community supported workarounds, see [[SysVol_replication_(DFS-R)|Sysvol Replication]].<br />
<br />
{{Imbox<br />
| type = note<br />
| text = If there are more than the default GPOs in Sysvol on the other DC(s), you must sync Sysvol to the new DC, <code>samba-tool ntacl sysvolreset</code> will throw an error if you do not.<br />
}}<br />
<br />
<br />
<br />
<br />
<br />
= Testing the Directory Replication =<br />
<br />
To test that the directory replication works correctly, add for example a user on an existing DC and verify that it shows up automatically on the newly joined DC.<br />
<br />
Optionally use the <code>ldapcmp</code> utility to compare two directories. For details, see [[Samba-tool_ldapcmp|samba-tool ldapcmp]].<br />
<br />
<br />
<br />
<br />
<br />
= Troubleshooting =<br />
<br />
For further details, see [[Samba_AD_DC_Troubleshooting|Samba AD DC Troubleshooting]].<br />
<br />
<br />
<br />
<br />
<br />
----<br />
[[Category:Active Directory]]<br />
[[Category:Domain Control]]</div>Hortimechhttps://wiki.samba.org/index.php?title=SysVol_replication_(DFS-R)&diff=19071SysVol replication (DFS-R)2023-09-13T15:45:51Z<p>Hortimech: </p>
<hr />
<div>Samba in its current state doesn't support SysVol replication via DFS-R (Distributed File System Replication) or the older FRS (File Replication Service) used in Windows Server 2000/2003 for Sysvol replication.<br />
<br />
We Currently advise administrators to use one of the following workarounds:<br />
<br />
* [[Rsync based SysVol replication workaround|Rsync based SysVol replication workaround]] (Samba DCs only): Quick setup, easy to configure.<br />
* [[Bidirectional Rsync/Unison based SysVol replication workaround|Bidirectional Rsync/Unison based SysVol replication workaround]] (Samba DCs only): More complex, requires third party script, each DC requires a cron job against each other DC<br />
* [[Bidirectional Rsync/osync based SysVol replication workaround|Bidirectional Rsync/osync based SysVol replication workaround]] (Samba DCs only): More complex, requires third party script, each DC requires a cron job against each other DC<br />
* [[Robocopy_based_SysVol_replication_workaround|Robocopy based SysVol replication workaround]] (Samba DCs -> Windows DCs): Quick set, easy to configure, uses MS robocopy<br />
<br />
<br />
{{Imbox<br />
| type = warning<br />
| text = You need to sync <code>idmap.ldb</code> from the DC holding the PDC_Emulator FSMO role to all other DCS. This ensures that all DCs will use the same IDs. If you do not sync <code>idmap.ldb</code>, you can and will get different IDs on each DC. You need to sync <code>idmap.ldb</code> when you first join a new DC and then regularly, to ensure the IDs remain constant, you do not need to sync <code>idmap.ldb</code> every time you sync SysVol.<br />
}}<br />
<br />
<br />
<br />
<br />
<br />
[[Category:Active Directory]]</div>Hortimechhttps://wiki.samba.org/index.php?title=Time_Synchronisation&diff=19034Time Synchronisation2023-08-09T17:49:52Z<p>Hortimech: </p>
<hr />
<div>= Introduction =<br />
<br />
In an Active Directory (AD) you must have an accurate time synchronisation. For example, Kerberos requires correct time stamps to prevent replay attacks and the AD uses the time to resolve replication conflicts. The default maximum allowed time deviation in an AD is 5 minutes. If a domain member or domain controller (DC) has a higher or lower time difference, the access is denied. As a result, a user cannot access shares or query the directory.<br />
<br />
Samba supports the <code>ntpd</code> from http://ntp.org and <code>chrony</code> from https://chrony.tuxfamily.org/ . The daemon synchronises the time with external sources and enables clients to retrieve the time from the server running the daemon.<br />
<br />
<br />
'''Recommended best practise'''<br />
<br />
internet time server<br />
^<br />
|<br />
|<br />
PDC Emulator DC<br />
^ ^<br />
| |<br />
| | <br />
Other DC <----Workstation <br />
<br />
From the above, you can see that only the PDC emulator DC gets its time from external time servers, all other DC's get their time from the PDC emulator, all other workstations get their time from any DC.<br />
There is however a problem with this, Windows clients ultimately get their time from the PDC emulator DC via the DCs and if the PDC emulator DC goes offline, the other DC's will be continue to look for it and time could drift.<br />
As a workaround for this, set the same external time servers on all DC's, then if the PDC emulator goes offline and cannot easily be restarted, transfer or seize the PDC emulator role to another DC. <br />
<br />
By default domain joined Windows clients synchronize their clock via NT5DS with AD-DC's.<br />
The NT5DS protocol uses digital signatures. These can be provided by Samba if the time server runs on the same server, and is configured as described on this page (with options mssntp and ntpsigndsocket).<br />
Alternatively you could configure all machines to do standard ntp, but NT5DS is recommended.<br />
<br />
Note that authenticated time synchronisation with Windows 2000 clients is not supported.<br />
<br />
Before deciding which time server software to install, You can see a comparison of ntp and chrony here https://chrony.tuxfamily.org/comparison.html<br />
<br />
For example, the NTP modes table. (last date checked 7 June 2018.)<br />
<br />
:{| class="wikitable"<br />
!<br />
!chrony<br />
!ntp<br />
!openntpd<br />
|-<br />
|Broadcast server<br />
|Yes<br />
|Yes<br />
|No<br />
|-<br />
|Broadcast client<br />
|No<br />
|Yes<br />
|No<br />
|-<br />
|Multicast server<br />
|No<br />
|Yes<br />
|No<br />
|-<br />
|Multicast client<br />
|No<br />
|Yes<br />
|No<br />
|-<br />
|Manycast server<br />
|No<br />
|Yes<br />
|No<br />
|-<br />
|Manycast client<br />
|No<br />
|Yes<br />
|No<br />
|}<br />
<br />
<br />
{{Imbox<br />
| type = note<br />
| text = You must set up a time server on all Samba AD DC's<br />
}}<br />
<br />
<br />
= Configuring Time Synchronisation on a DC =<br />
<br />
== Requirements ==<br />
<br />
* ntpd >= 4.2.6 from http://www.ntp.org, compiled with enabled signed ntp support (<code>--enable-ntp-signd</code> when building NTP)<br />
<br />
Or<br />
<br />
* chrony >= 3.0 from https://chrony.tuxfamily.org, compiled with enabled signed ntp support (<code>--enable-ntp-signd</code> when building chrony)<br />
<br />
== With ntpd ==<br />
<br />
{{Imbox<br />
| type = note<br />
| text = It has been reported that <code>ntpsec</code> will not work with Samba. There is Debian bug report here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033088 and the corresponding NTPsec issue here: https://gitlab.com/NTPsec/ntpsec/-/issues/785 . Until this note has been removed, it is recommended that only <code>Chrony</code> is used.<br />
}}<br />
<br />
* Verify the socket permissions on your domain controller (DC). The time daemon must have read permissions in the <code>ntp_signed</code> directory. To list the permissions, enter:<br />
<br />
# ls -ld /usr/local/samba/var/lib/ntp_signd/<br />
drwxr-x--- 2 root ntp 4096 1. May 09:30 /usr/local/samba/var/lib/ntp_signd/<br />
<br />
: Note: Depending on your linux distribution, the path might be different, e.g <code>/var/lib/samba/ntp_signd/</code>. The path of course then needs to be changed in the <code>chrony.conf</code> below as well.<br />
<br />
: To set the permissions, run:<br />
# chown root:ntp /usr/local/samba/var/lib/ntp_signd/<br />
# chmod 750 /usr/local/samba/var/lib/ntp_signd/<br />
<br />
Typically, the <code>ntpd</code> daemon read its configuration from the <code>/etc/ntpd.conf</code> file.<br />
<br />
The following is a minimum <code>ntpd.conf</code> file that synchronises the time with three external NTP server and enables clients to query the time using signed NTP requests:<br />
<br />
# Local clock. Note that is not the "localhost" address!<br />
server 127.127.1.0<br />
fudge 127.127.1.0 stratum 10<br />
<br />
# Where to retrieve the time from<br />
server 0.pool.ntp.org iburst prefer<br />
server 1.pool.ntp.org iburst prefer<br />
server 2.pool.ntp.org iburst prefer<br />
<br />
driftfile /var/lib/ntp/ntp.drift<br />
logfile /var/log/ntp<br />
ntpsigndsocket /usr/local/samba/var/lib/ntp_signd/<br />
<br />
# Access control<br />
# Default restriction: Allow clients only to query the time<br />
restrict default kod nomodify notrap nopeer limited mssntp<br />
<br />
# No restrictions for "localhost"<br />
restrict 127.0.0.1<br />
<br />
# Enable the time sources to only provide time to this host<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 />
restrict 2.pool.ntp.org mask 255.255.255.255 nomodify notrap nopeer noquery<br />
<br />
If you are running the DC in a VM, you should consider adding <code>tinker panic 0</code> to the end of the <code>ntp.conf</code>. This tells NTP not to panic and exit, no matter what the time offset is. This is recommended because <br />
virtual machines have no physical clock and can be paused at anytime and started back up hours later.<br />
For further information see: https://www.redhat.com/en/blog/avoiding-clock-drift-vms <br />
<br />
For further information about the <code>ntpd</code> access control, see http://support.ntp.org/bin/view/Support/AccessRestrictions.<br />
<br />
If you have SELinux enabled on your server, see [[Time_Synchronisation_-_SELinux_Labeling_and_Policy|Time Synchronisation - SELinux Labeling and Policy]].<br />
<br />
== With chrony ==<br />
<br />
* Verify the socket permissions on your domain controller (DC). The time daemon must have read permissions in the <code>ntp_signed</code> directory. To list the permissions, enter:<br />
<br />
# ls -ld /usr/local/samba/var/lib/ntp_signd/<br />
drwxr-x--- 2 root _chrony 4096 1. May 09:30 /usr/local/samba/var/lib/ntp_signd/<br />
<br />
: Note: Depending on your linux distribution, the path might be different, e.g <code>/var/lib/samba/ntp_signd/</code>. The path of course then needs to be changed in the <code>chrony.conf</code> below as well.<br />
<br />
: To set the permissions, run:<br />
# chown root:_chrony /usr/local/samba/var/lib/ntp_signd/<br />
# chmod 750 /usr/local/samba/var/lib/ntp_signd/<br />
<br />
Typically, the <code>chrony</code> daemon read its configuration from the <code>/etc/chrony/chrony.conf</code> file.<br />
<br />
The following is a minimum <code>chrony.conf</code> file that synchronises the time with three external NTP servers and enables clients to query the time using signed NTP requests:<br />
<br />
# Welcome to the chrony configuration file. See chrony.conf(5) for more<br />
# information about usuable directives.<br />
<br />
# This directive specify the location of the file containing ID/key pairs for<br />
# NTP authentication.<br />
keyfile /etc/chrony/chrony.keys<br />
<br />
# This directive specify the file into which chronyd will store the rate<br />
# information.<br />
driftfile /var/lib/chrony/chrony.drift<br />
<br />
# Uncomment the following line to turn logging on.<br />
#log tracking measurements statistics<br />
<br />
# Log files location.<br />
logdir /var/log/chrony<br />
<br />
# Stop bad estimates upsetting machine clock.<br />
maxupdateskew 100.0<br />
<br />
# This directive tells 'chronyd' to parse the 'adjtime' file to find out if the<br />
# real-time clock keeps local time or UTC. It overrides the 'rtconutc' directive.<br />
hwclockfile /etc/adjtime<br />
<br />
# This directive enables kernel synchronisation (every 11 minutes) of the<br />
# real-time clock. Note that it can’t be used along with the 'rtcfile' directive.<br />
rtcsync<br />
<br />
# Step the system clock instead of slewing it if the adjustment is larger than<br />
# one second, but only in the first three clock updates.<br />
makestep 1 3<br />
<br />
bindcmdaddress 192.168.0.2 # ipaddress of this DC<br />
<br />
# The source, where we are receiving the time from<br />
server 0.pool.ntp.org iburst<br />
server 1.pool.ntp.org iburst<br />
server 2.pool.ntp.org iburst<br />
<br />
allow 192.168.0.0/24 # dns netmask<br />
<br />
ntpsigndsocket /usr/local/samba/var/lib/ntp_signd<br />
<br />
= Configuring Time Synchronisation on a Unix Domain Member =<br />
<br />
== Requirements ==<br />
<br />
* ntpd from http://www.ntp.org.<br />
<br />
Or<br />
<br />
* chrony >= 3.0 from https://chrony.tuxfamily.org<br />
<br />
Or<br />
<br />
* systemd-timesyncd >= a recent linux distro that supports and runs with systemd.<br />
<br />
<br />
<br />
<br />
<br />
== With ntpd ==<br />
<br />
<br />
Typically, the <code>ntpd</code> daemon read its configuration from the <code>/etc/ntpd.conf</code> file.<br />
<br />
The following is a minimum conf file that synchronises the time with the Samba Active Directory (AD) domain controllers (DC) <code>DC1</code> and <code>DC2</code> and does not provide time services for other hosts.<br />
<br />
# Local clock. Note that is not the "localhost" address!<br />
server 127.127.1.0<br />
fudge 127.127.1.0 stratum 10<br />
<br />
# Where to retrieve the time from<br />
server DC1.samdom.example.com iburst prefer<br />
server DC2.samdom.example.com iburst<br />
<br />
driftfile /var/lib/ntp/ntp.drift<br />
logfile /var/log/ntp<br />
<br />
# Access control<br />
# Default restriction: Disallow everything<br />
restrict default ignore<br />
<br />
# No restrictions for "localhost"<br />
restrict 127.0.0.1<br />
<br />
# Enable the time sources only to only provide time to this host<br />
restrict DC1.samdom.example.com mask 255.255.255.255 nomodify notrap nopeer noquery<br />
restrict DC2.samdom.example.com mask 255.255.255.255 nomodify notrap nopeer noquery<br />
<br />
If you are running the Unix Domain Member in a VM, you should consider adding <code>tinker panic 0</code> to the end of the <code>ntp.conf</code>. This tells NTP not to panic and exit, no matter what the time offset is. This is recommended because virtual machines have no physical clock and can be paused at any time and started back up hours later.<br />
For further information see: https://www.redhat.com/en/blog/avoiding-clock-drift-vms<br />
<br />
For further information about the <code>ntpd</code> access control, see http://support.ntp.org/bin/view/Support/AccessRestrictions.<br />
<br />
<br />
<br />
<br />
<br />
== With chrony ==<br />
<br />
Typically, the <code>chrony</code> daemon read its configuration from the <code>/etc/chrony/chrony.conf</code> file.<br />
<br />
The following is a minimum conf file that synchronises the time with the Samba Active Directory (AD) domain controllers (DC) <code>DC1</code> and <code>DC2</code> and does not provide time services for other hosts.<br />
<br />
# Welcome to the chrony configuration file. See chrony.conf(5) for more<br />
# information about usuable directives.<br />
<br />
# This directive specify the location of the file containing ID/key pairs for<br />
# NTP authentication.<br />
keyfile /etc/chrony/chrony.keys<br />
<br />
# This directive specify the file into which chronyd will store the rate<br />
# information.<br />
driftfile /var/lib/chrony/chrony.drift<br />
<br />
# Uncomment the following line to turn logging on.<br />
#log tracking measurements statistics<br />
<br />
# Log files location.<br />
logdir /var/log/chrony<br />
<br />
# Stop bad estimates upsetting machine clock.<br />
maxupdateskew 100.0<br />
<br />
# This directive tells 'chronyd' to parse the 'adjtime' file to find out if the<br />
# real-time clock keeps local time or UTC. It overrides the 'rtconutc' directive.<br />
hwclockfile /etc/adjtime<br />
<br />
# This directive enables kernel synchronisation (every 11 minutes) of the<br />
# real-time clock. Note that it can’t be used along with the 'rtcfile' directive.<br />
rtcsync<br />
<br />
# Step the system clock instead of slewing it if the adjustment is larger than<br />
# one second, but only in the first three clock updates.<br />
makestep 1 3<br />
<br />
bindcmdaddress 192.168.0.6 # ipaddress of this Unix domain member<br />
<br />
# The source, where we are receiving the time from<br />
server DC1.samdom.example.com iburst<br />
server DC2.samdom.example.com iburst<br />
<br />
<br />
<br />
<br />
<br />
== With systemd-timesyncd ==<br />
<br />
There are a few ways to setup systemd-timesyncd.<br />
<br />
The <code>systemd-timesynced</code> daemon reads its configuration from the <code>/etc/systemd/timesyncd.conf</code> file,<br />
or from your network configuration defined in systemd's .network file <code>/etc/systemd/network/your.network</code>,<br />
or by dhcp settings. <br />
<br />
Option 1: Using the <code>/etc/systemd/timesyncd.conf</code> file.<br />
Enable the following. <br />
[Time]<br />
NTP=DC1.samdom.example.com DC2.samdom.example.com<br />
FallbackNTP=the.same.ntp-server.as.your.dc.points.to one-extra.ntp-server.as.your.dc.points.to<br />
<br />
In this example the fallback NTP servers are also used, this is not mandatory. <br />
<br />
<br />
Option 2: set your time servers in your network configuration (for example: <code>/etc/systemd/network/20-wired-dev1.network</code>).<br />
#/etc/systemd/network/20-wired-dev1.network<br />
[Network]<br />
NTP=dc1.samdom.example.com<br />
NTP=dc2.samdom.example.com<br />
<br />
[Address]<br />
Address=192.168.0.200/24<br />
<br />
[Route]<br />
Destination=0.0.0.0/0<br />
Gateway=192.168.0.1<br />
<br />
After the changes enable and start the time daemon.<br />
systemctl enable systemd-timesyncd<br />
systemctl start systemd-timesyncd<br />
<br />
Check the service status with: <br />
systemctl status systemd-timesyncd<br />
<br />
Check the journaling logs with: <br />
journalctl -u systemd-timesyncd<br />
<br />
Check the time daemon with:<br />
timedatectl status<br />
<br />
If required, get the list of timezones: <br />
timedatectl list-timezones<br />
and apply the new time-zone. <br />
timedatectl set-timezones Europe/Amsterdam<br />
<br />
Why use the systemd time daemon? It works fine for a member server and doesn't require the installation of any extra software.<br />
<br />
<br />
{{Imbox<br />
| type = note<br />
| text = You can find the documentation for <code>systemd-timesynced</code> here: https://www.freedesktop.org/software/systemd/man/systemd-timesyncd.service.html<br />
}}<br />
<br />
<br />
<br />
<br />
<br />
= Configuring Time Synchronisation on a Windows Domain Member =<br />
<br />
The following describes the basics of how to configure time synchronisation on a Windows domain member. For further details, see your Microsoft Windows documentation.<br />
<br />
<br />
<br />
== Default Time Source ==<br />
<br />
Windows AD domain members will use any DC as their default time source. If you have set up ntp on the DC as described on this page, you usually do not need to reconfigure the clients. Alternative configuration options for the clients are described below.<br />
<br />
For more information about the time synchronisation and hierarchy in an AD, see http://technet.microsoft.com/en-us/library/cc773013%28v=ws.10%29.aspx#w2k3tr_times_how_izcr.<br />
<br />
== Setting User Defined Time Sources and Options ==<br />
<br />
To create a group policy object (GPO) to for setting a user defined NTP time source and options:<br />
<br />
* Log in to a computer using an account that is allowed you to edit group policies, such as the AD domain <code>Administrator</code> account.<br />
<br />
* Open the <code>Group Policy Management Console</code>. If you are not having the Remote Server Administration Tools (RSAT) installed on this computer, see [[Installing RSAT|Installing RSAT]].<br />
<br />
* Right-click to your AD domain and select <code>Create a GPO in this domain, and Link it here</code>.<br />
<br />
* Enter a name for the GPO, such as <code>Time Sources</code>. The new GPO is shown below the domain entry.<br />
<br />
* Right-click to the newly-created GPO and select <code>Edit</code> to open the <code>Group Policy Management Editor</code>.<br />
<br />
* Navigate to the <code>Computer Configuration</code> &rarr; <code>Policies</code> &rarr; <code>Administrative Templates</code> &rarr; <code>System</code> &rarr; <code>Windows Time Service</code> &rarr; <code>Time Providers</code> entry, and double-click <code>Configure Windows NTP Client</code> to configure the policy:<br />
:* Enable the policy and set the following options:<br />
::* Enter the fully-quallified domain name (FQDN) of the NTP server to the <code>NtpServer</code> field and and append the <code>0x9</code> flag. For example:<br />
:::[[Image:GPO_Windows_NTP_Client_Options.png]]<br />
::: To enter multiple server, separate the individual entries using a space.<br />
::* Keep the <code>NT5DS</code> type setting.<br />
::* Update the additional parameters, if necessary.<br />
:* Click <code>OK</code> to save the settings.<br />
<br />
* Navigate to the <code>Computer Configuration</code> &rarr; <code>Policies</code> &rarr; <code>Administrative Templates</code> &rarr; <code>System</code> &rarr; <code>Windows Time Service</code> &rarr; <code>Time Providers</code> entry, and double-click <code>Enable Windows NTP Client</code> to configure the policy:<br />
:* Enable the policy.<br />
:* Click <code>OK</code> to save the settings.<br />
<br />
* Close the <code>Group Policy Management Editor</code>.<br />
<br />
* Close the <code>Group Policy Management Console</code>.<br />
<br />
<br />
Notes:<br />
<br />
* The default Type NT5DS ignores the parameter NtpServer, and syncs with the DC.<br />
<br />
* If ntpd on your DC is not configured for mssntp with ntpsigndsocket, use Type NTP.<br />
<br />
* If a client will not be able to connect to the DC for a long time (for example a laptop), use Type AllSync and set NtpServer to "time.windows.com,0x9". This will cause the client to try both NT5DS to your DC, and NTP to NtpServer.</div>Hortimechhttps://wiki.samba.org/index.php?title=Time_Synchronisation&diff=19033Time Synchronisation2023-08-09T09:00:53Z<p>Hortimech: </p>
<hr />
<div>= Introduction =<br />
<br />
In an Active Directory (AD) you must have an accurate time synchronisation. For example, Kerberos requires correct time stamps to prevent replay attacks and the AD uses the time to resolve replication conflicts. The default maximum allowed time deviation in an AD is 5 minutes. If a domain member or domain controller (DC) has a higher or lower time difference, the access is denied. As a result, a user cannot access shares or query the directory.<br />
<br />
Samba supports the <code>ntpd</code> from http://ntp.org and <code>chrony</code> from https://chrony.tuxfamily.org/ . The daemon synchronises the time with external sources and enables clients to retrieve the time from the server running the daemon.<br />
<br />
<br />
'''Recommended best practise'''<br />
<br />
internet time server<br />
^<br />
|<br />
|<br />
PDC Emulator DC<br />
^ ^<br />
| |<br />
| | <br />
Other DC <----Workstation <br />
<br />
From the above, you can see that only the PDC emulator DC gets its time from external time servers, all other DC's get their time from the PDC emulator, all other workstations get their time from any DC.<br />
There is however a problem with this, Windows clients ultimately get their time from the PDC emulator DC via the DCs and if the PDC emulator DC goes offline, the other DC's will be continue to look for it and time could drift.<br />
As a workaround for this, set the same external time servers on all DC's, then if the PDC emulator goes offline and cannot easily be restarted, transfer or seize the PDC emulator role to another DC. <br />
<br />
By default domain joined Windows clients synchronize their clock via NT5DS with AD-DC's.<br />
The NT5DS protocol uses digital signatures. These can be provided by Samba if the time server runs on the same server, and is configured as described on this page (with options mssntp and ntpsigndsocket).<br />
Alternatively you could configure all machines to do standard ntp, but NT5DS is recommended.<br />
<br />
Note that authenticated time synchronisation with Windows 2000 clients is not supported.<br />
<br />
Before deciding which time server software to install, You can see a comparison of ntp and chrony here https://chrony.tuxfamily.org/comparison.html<br />
<br />
For example, the NTP modes table. (last date checked 7 June 2018.)<br />
<br />
:{| class="wikitable"<br />
!<br />
!chrony<br />
!ntp<br />
!openntpd<br />
|-<br />
|Broadcast server<br />
|Yes<br />
|Yes<br />
|No<br />
|-<br />
|Broadcast client<br />
|No<br />
|Yes<br />
|No<br />
|-<br />
|Multicast server<br />
|No<br />
|Yes<br />
|No<br />
|-<br />
|Multicast client<br />
|No<br />
|Yes<br />
|No<br />
|-<br />
|Manycast server<br />
|No<br />
|Yes<br />
|No<br />
|-<br />
|Manycast client<br />
|No<br />
|Yes<br />
|No<br />
|}<br />
<br />
<br />
{{Imbox<br />
| type = note<br />
| text = You must set up a time server on all Samba AD DC's<br />
}}<br />
<br />
<br />
= Configuring Time Synchronisation on a DC =<br />
<br />
== Requirements ==<br />
<br />
* ntpd >= 4.2.6 from http://www.ntp.org, compiled with enabled signed ntp support (<code>--enable-ntp-signd</code> when building NTP)<br />
<br />
Or<br />
<br />
* chrony >= 3.0 from https://chrony.tuxfamily.org, compiled with enabled signed ntp support (<code>--enable-ntp-signd</code> when building chrony)<br />
<br />
== With ntpd ==<br />
<br />
* Verify the socket permissions on your domain controller (DC). The time daemon must have read permissions in the <code>ntp_signed</code> directory. To list the permissions, enter:<br />
<br />
# ls -ld /usr/local/samba/var/lib/ntp_signd/<br />
drwxr-x--- 2 root ntp 4096 1. May 09:30 /usr/local/samba/var/lib/ntp_signd/<br />
<br />
: Note: Depending on your linux distribution, the path might be different, e.g <code>/var/lib/samba/ntp_signd/</code>. The path of course then needs to be changed in the <code>chrony.conf</code> below as well.<br />
<br />
: To set the permissions, run:<br />
# chown root:ntp /usr/local/samba/var/lib/ntp_signd/<br />
# chmod 750 /usr/local/samba/var/lib/ntp_signd/<br />
<br />
Typically, the <code>ntpd</code> daemon read its configuration from the <code>/etc/ntpd.conf</code> file.<br />
<br />
The following is a minimum <code>ntpd.conf</code> file that synchronises the time with three external NTP server and enables clients to query the time using signed NTP requests:<br />
<br />
# Local clock. Note that is not the "localhost" address!<br />
server 127.127.1.0<br />
fudge 127.127.1.0 stratum 10<br />
<br />
# Where to retrieve the time from<br />
server 0.pool.ntp.org iburst prefer<br />
server 1.pool.ntp.org iburst prefer<br />
server 2.pool.ntp.org iburst prefer<br />
<br />
driftfile /var/lib/ntp/ntp.drift<br />
logfile /var/log/ntp<br />
ntpsigndsocket /usr/local/samba/var/lib/ntp_signd/<br />
<br />
# Access control<br />
# Default restriction: Allow clients only to query the time<br />
restrict default kod nomodify notrap nopeer limited mssntp<br />
<br />
# No restrictions for "localhost"<br />
restrict 127.0.0.1<br />
<br />
# Enable the time sources to only provide time to this host<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 />
restrict 2.pool.ntp.org mask 255.255.255.255 nomodify notrap nopeer noquery<br />
<br />
If you are running the DC in a VM, you should consider adding <code>tinker panic 0</code> to the end of the <code>ntp.conf</code>. This tells NTP not to panic and exit, no matter what the time offset is. This is recommended because <br />
virtual machines have no physical clock and can be paused at anytime and started back up hours later.<br />
For further information see: https://www.redhat.com/en/blog/avoiding-clock-drift-vms <br />
<br />
For further information about the <code>ntpd</code> access control, see http://support.ntp.org/bin/view/Support/AccessRestrictions.<br />
<br />
If you have SELinux enabled on your server, see [[Time_Synchronisation_-_SELinux_Labeling_and_Policy|Time Synchronisation - SELinux Labeling and Policy]].<br />
<br />
== With chrony ==<br />
<br />
* Verify the socket permissions on your domain controller (DC). The time daemon must have read permissions in the <code>ntp_signed</code> directory. To list the permissions, enter:<br />
<br />
# ls -ld /usr/local/samba/var/lib/ntp_signd/<br />
drwxr-x--- 2 root _chrony 4096 1. May 09:30 /usr/local/samba/var/lib/ntp_signd/<br />
<br />
: Note: Depending on your linux distribution, the path might be different, e.g <code>/var/lib/samba/ntp_signd/</code>. The path of course then needs to be changed in the <code>chrony.conf</code> below as well.<br />
<br />
: To set the permissions, run:<br />
# chown root:_chrony /usr/local/samba/var/lib/ntp_signd/<br />
# chmod 750 /usr/local/samba/var/lib/ntp_signd/<br />
<br />
Typically, the <code>chrony</code> daemon read its configuration from the <code>/etc/chrony/chrony.conf</code> file.<br />
<br />
The following is a minimum <code>chrony.conf</code> file that synchronises the time with three external NTP servers and enables clients to query the time using signed NTP requests:<br />
<br />
# Welcome to the chrony configuration file. See chrony.conf(5) for more<br />
# information about usuable directives.<br />
<br />
# This directive specify the location of the file containing ID/key pairs for<br />
# NTP authentication.<br />
keyfile /etc/chrony/chrony.keys<br />
<br />
# This directive specify the file into which chronyd will store the rate<br />
# information.<br />
driftfile /var/lib/chrony/chrony.drift<br />
<br />
# Uncomment the following line to turn logging on.<br />
#log tracking measurements statistics<br />
<br />
# Log files location.<br />
logdir /var/log/chrony<br />
<br />
# Stop bad estimates upsetting machine clock.<br />
maxupdateskew 100.0<br />
<br />
# This directive tells 'chronyd' to parse the 'adjtime' file to find out if the<br />
# real-time clock keeps local time or UTC. It overrides the 'rtconutc' directive.<br />
hwclockfile /etc/adjtime<br />
<br />
# This directive enables kernel synchronisation (every 11 minutes) of the<br />
# real-time clock. Note that it can’t be used along with the 'rtcfile' directive.<br />
rtcsync<br />
<br />
# Step the system clock instead of slewing it if the adjustment is larger than<br />
# one second, but only in the first three clock updates.<br />
makestep 1 3<br />
<br />
bindcmdaddress 192.168.0.2 # ipaddress of this DC<br />
<br />
# The source, where we are receiving the time from<br />
server 0.pool.ntp.org iburst<br />
server 1.pool.ntp.org iburst<br />
server 2.pool.ntp.org iburst<br />
<br />
allow 192.168.0.0/24 # dns netmask<br />
<br />
ntpsigndsocket /usr/local/samba/var/lib/ntp_signd<br />
<br />
= Configuring Time Synchronisation on a Unix Domain Member =<br />
<br />
== Requirements ==<br />
<br />
* ntpd from http://www.ntp.org.<br />
<br />
Or<br />
<br />
* chrony >= 3.0 from https://chrony.tuxfamily.org<br />
<br />
Or<br />
<br />
* systemd-timesyncd >= a recent linux distro that supports and runs with systemd.<br />
<br />
<br />
<br />
<br />
<br />
== With ntpd ==<br />
<br />
Typically, the <code>ntpd</code> daemon read its configuration from the <code>/etc/ntpd.conf</code> file.<br />
<br />
The following is a minimum conf file that synchronises the time with the Samba Active Directory (AD) domain controllers (DC) <code>DC1</code> and <code>DC2</code> and does not provide time services for other hosts.<br />
<br />
# Local clock. Note that is not the "localhost" address!<br />
server 127.127.1.0<br />
fudge 127.127.1.0 stratum 10<br />
<br />
# Where to retrieve the time from<br />
server DC1.samdom.example.com iburst prefer<br />
server DC2.samdom.example.com iburst<br />
<br />
driftfile /var/lib/ntp/ntp.drift<br />
logfile /var/log/ntp<br />
<br />
# Access control<br />
# Default restriction: Disallow everything<br />
restrict default ignore<br />
<br />
# No restrictions for "localhost"<br />
restrict 127.0.0.1<br />
<br />
# Enable the time sources only to only provide time to this host<br />
restrict DC1.samdom.example.com mask 255.255.255.255 nomodify notrap nopeer noquery<br />
restrict DC2.samdom.example.com mask 255.255.255.255 nomodify notrap nopeer noquery<br />
<br />
If you are running the Unix Domain Member in a VM, you should consider adding <code>tinker panic 0</code> to the end of the <code>ntp.conf</code>. This tells NTP not to panic and exit, no matter what the time offset is. This is recommended because virtual machines have no physical clock and can be paused at any time and started back up hours later.<br />
For further information see: https://www.redhat.com/en/blog/avoiding-clock-drift-vms<br />
<br />
For further information about the <code>ntpd</code> access control, see http://support.ntp.org/bin/view/Support/AccessRestrictions.<br />
<br />
<br />
<br />
<br />
<br />
== With chrony ==<br />
<br />
Typically, the <code>chrony</code> daemon read its configuration from the <code>/etc/chrony/chrony.conf</code> file.<br />
<br />
The following is a minimum conf file that synchronises the time with the Samba Active Directory (AD) domain controllers (DC) <code>DC1</code> and <code>DC2</code> and does not provide time services for other hosts.<br />
<br />
# Welcome to the chrony configuration file. See chrony.conf(5) for more<br />
# information about usuable directives.<br />
<br />
# This directive specify the location of the file containing ID/key pairs for<br />
# NTP authentication.<br />
keyfile /etc/chrony/chrony.keys<br />
<br />
# This directive specify the file into which chronyd will store the rate<br />
# information.<br />
driftfile /var/lib/chrony/chrony.drift<br />
<br />
# Uncomment the following line to turn logging on.<br />
#log tracking measurements statistics<br />
<br />
# Log files location.<br />
logdir /var/log/chrony<br />
<br />
# Stop bad estimates upsetting machine clock.<br />
maxupdateskew 100.0<br />
<br />
# This directive tells 'chronyd' to parse the 'adjtime' file to find out if the<br />
# real-time clock keeps local time or UTC. It overrides the 'rtconutc' directive.<br />
hwclockfile /etc/adjtime<br />
<br />
# This directive enables kernel synchronisation (every 11 minutes) of the<br />
# real-time clock. Note that it can’t be used along with the 'rtcfile' directive.<br />
rtcsync<br />
<br />
# Step the system clock instead of slewing it if the adjustment is larger than<br />
# one second, but only in the first three clock updates.<br />
makestep 1 3<br />
<br />
bindcmdaddress 192.168.0.6 # ipaddress of this Unix domain member<br />
<br />
# The source, where we are receiving the time from<br />
server DC1.samdom.example.com iburst<br />
server DC2.samdom.example.com iburst<br />
<br />
<br />
<br />
<br />
<br />
== With systemd-timesyncd ==<br />
<br />
There are a few ways to setup systemd-timesyncd.<br />
<br />
The <code>systemd-timesynced</code> daemon reads its configuration from the <code>/etc/systemd/timesyncd.conf</code> file,<br />
or from your network configuration defined in systemd's .network file <code>/etc/systemd/network/your.network</code>,<br />
or by dhcp settings. <br />
<br />
Option 1: Using the <code>/etc/systemd/timesyncd.conf</code> file.<br />
Enable the following. <br />
[Time]<br />
NTP=DC1.samdom.example.com DC2.samdom.example.com<br />
FallbackNTP=the.same.ntp-server.as.your.dc.points.to one-extra.ntp-server.as.your.dc.points.to<br />
<br />
In this example the fallback NTP servers are also used, this is not mandatory. <br />
<br />
<br />
Option 2: set your time servers in your network configuration (for example: <code>/etc/systemd/network/20-wired-dev1.network</code>).<br />
#/etc/systemd/network/20-wired-dev1.network<br />
[Network]<br />
NTP=dc1.samdom.example.com<br />
NTP=dc2.samdom.example.com<br />
<br />
[Address]<br />
Address=192.168.0.200/24<br />
<br />
[Route]<br />
Destination=0.0.0.0/0<br />
Gateway=192.168.0.1<br />
<br />
After the changes enable and start the time daemon.<br />
systemctl enable systemd-timesyncd<br />
systemctl start systemd-timesyncd<br />
<br />
Check the service status with: <br />
systemctl status systemd-timesyncd<br />
<br />
Check the journaling logs with: <br />
journalctl -u systemd-timesyncd<br />
<br />
Check the time daemon with:<br />
timedatectl status<br />
<br />
If required, get the list of timezones: <br />
timedatectl list-timezones<br />
and apply the new time-zone. <br />
timedatectl set-timezones Europe/Amsterdam<br />
<br />
Why use the systemd time daemon? It works fine for a member server and doesn't require the installation of any extra software.<br />
<br />
<br />
{{Imbox<br />
| type = note<br />
| text = You can find the documentation for <code>systemd-timesynced</code> here: https://www.freedesktop.org/software/systemd/man/systemd-timesyncd.service.html<br />
}}<br />
<br />
<br />
<br />
<br />
<br />
= Configuring Time Synchronisation on a Windows Domain Member =<br />
<br />
The following describes the basics of how to configure time synchronisation on a Windows domain member. For further details, see your Microsoft Windows documentation.<br />
<br />
<br />
<br />
== Default Time Source ==<br />
<br />
Windows AD domain members will use any DC as their default time source. If you have set up ntp on the DC as described on this page, you usually do not need to reconfigure the clients. Alternative configuration options for the clients are described below.<br />
<br />
For more information about the time synchronisation and hierarchy in an AD, see http://technet.microsoft.com/en-us/library/cc773013%28v=ws.10%29.aspx#w2k3tr_times_how_izcr.<br />
<br />
== Setting User Defined Time Sources and Options ==<br />
<br />
To create a group policy object (GPO) to for setting a user defined NTP time source and options:<br />
<br />
* Log in to a computer using an account that is allowed you to edit group policies, such as the AD domain <code>Administrator</code> account.<br />
<br />
* Open the <code>Group Policy Management Console</code>. If you are not having the Remote Server Administration Tools (RSAT) installed on this computer, see [[Installing RSAT|Installing RSAT]].<br />
<br />
* Right-click to your AD domain and select <code>Create a GPO in this domain, and Link it here</code>.<br />
<br />
* Enter a name for the GPO, such as <code>Time Sources</code>. The new GPO is shown below the domain entry.<br />
<br />
* Right-click to the newly-created GPO and select <code>Edit</code> to open the <code>Group Policy Management Editor</code>.<br />
<br />
* Navigate to the <code>Computer Configuration</code> &rarr; <code>Policies</code> &rarr; <code>Administrative Templates</code> &rarr; <code>System</code> &rarr; <code>Windows Time Service</code> &rarr; <code>Time Providers</code> entry, and double-click <code>Configure Windows NTP Client</code> to configure the policy:<br />
:* Enable the policy and set the following options:<br />
::* Enter the fully-quallified domain name (FQDN) of the NTP server to the <code>NtpServer</code> field and and append the <code>0x9</code> flag. For example:<br />
:::[[Image:GPO_Windows_NTP_Client_Options.png]]<br />
::: To enter multiple server, separate the individual entries using a space.<br />
::* Keep the <code>NT5DS</code> type setting.<br />
::* Update the additional parameters, if necessary.<br />
:* Click <code>OK</code> to save the settings.<br />
<br />
* Navigate to the <code>Computer Configuration</code> &rarr; <code>Policies</code> &rarr; <code>Administrative Templates</code> &rarr; <code>System</code> &rarr; <code>Windows Time Service</code> &rarr; <code>Time Providers</code> entry, and double-click <code>Enable Windows NTP Client</code> to configure the policy:<br />
:* Enable the policy.<br />
:* Click <code>OK</code> to save the settings.<br />
<br />
* Close the <code>Group Policy Management Editor</code>.<br />
<br />
* Close the <code>Group Policy Management Console</code>.<br />
<br />
<br />
Notes:<br />
<br />
* The default Type NT5DS ignores the parameter NtpServer, and syncs with the DC.<br />
<br />
* If ntpd on your DC is not configured for mssntp with ntpsigndsocket, use Type NTP.<br />
<br />
* If a client will not be able to connect to the DC for a long time (for example a laptop), use Type AllSync and set NtpServer to "time.windows.com,0x9". This will cause the client to try both NT5DS to your DC, and NTP to NtpServer.</div>Hortimechhttps://wiki.samba.org/index.php?title=Active_Directory_Naming_FAQ&diff=19032Active Directory Naming FAQ2023-08-08T08:31:21Z<p>Hortimech: </p>
<hr />
<div>= Introduction =<br />
<br />
Picking an Active Directory domain name is one of the most important steps in setting up a domain. And one that is important to get right the first time, as changing it later is a non-trivial task. There have been religious debates on this issue, and MS recommendations have changed over time.<br />
<br />
<br />
<br />
<br />
<br />
= What is an Active Directory domain? =<br />
<br />
An [[Terms_and_Abbreviations#Active_Directory_.28AD.29|Active Directory (AD)]] domain is basically the same as an internet [[Terms_and_Abbreviations#Domain|domain]]. It "defines a realm of administrative autonomy, authority, and control" for a group of computers. Active Directory Domain names are controlled by the same set of rules and principles, that govern traditional [[Terms_and_Abbreviations#Domain_Name_System_.28DNS.29|Domain Name Systems (DNS)]]. Thus in order to understand Active Directory domain naming it is important to understand DNS.<br />
<br />
<br />
<br />
<br />
<br />
= How DNS Works =<br />
<br />
DNS is the system, used to translate names into other types of data for computer consumption, such as an IP address (an A record) or any of a number of other record types. An often used analogy is that of a phone book. A DNS server serves as a sort of computer phone book that can be used to rapidly translate computer names to IPs (or other sorts of data). However this phone book is of gigantic size (there are ~4 billion IPv4 address alone) and constantly changing so DNS uses a hierarchical system to determine which phone book, or name server, is responsible for which sets of addresses.<br />
<br />
Virtually every time a domain name is resolved, be it by a web-browser or some other source, a DNS inquiry is made. Actual name resolution in Windows is a somewhat complex topic, but in general a Windows PC checks its local name, then its hosts file, then makes a DNS request (unless the name is in its cache). The DNS name servers then looks up the address and returns a response or forwards the request on to another server for resolution if it is a recursive DNS server. Active Directory DNS servers are typically recursive and serve all DNS requests for PCs within the domain. DNS names do not necessarily resolve to only a single address either, they can correspond to multiple other records and can even refer to other records recursively using records like a CNAME.<br />
<br />
DNS requests go out primarily over UDP. With UDP there is no guarantee of message or response delivery, and since users expect name resolution to be fast and seamless, timeout for a DNS reply is short (3 seconds is the Windows, 5 seconds the Linux default). For the most part, DNS is fast and reliable, but it is important to remember that a lookup failure from time to time is not-unexpected.<br />
<br />
<br />
<br />
== DNS Hierarchy ==<br />
<br />
A DNS name is segmented into different parts by dots. Each segment represent a different parts of the hierarchy, called a domain. The first segment from the right (the .com, .net, etc.) is known as the top-level domain (TLD), every domain beneath that level is known as a subdomain. These subdomains can themselves contain subdomains, up to 127 layers deep. So "example.com" is a subdomain of the .com domain, and can itself contain multiple subdomains like "samdom.example.com". A DNS name that resolves to a specific device or piece of data is known as a [[Terms_and_Abbreviations#Fully_qualified_Domain_Name_.28FQDN.29|full qualified domain name (FQDN)]]. Technically a FQDN should also specify the root zone which is a blank domain name specified by a dot at the end of the domain name, such as "www.samdom.example.com.", but in practice the root zone is often omitted.<br />
<br />
Each DNS name server is responsible for different parts of this hierarchy, known as a zone. A zone comprises a DNS name, such as "samdom.example.com", and all the names beneath that level, such as www.samdom.example.com", "ftp.samdom.example.com", or "server.samdom.example.com". DNS servers give authoritative, or final, answers to request with the zones they are configured to be responsible for. More details on the process can be found on the [http://en.wikipedia.org/wiki/DNS#Address_resolution_mechanism Wikipedia DNS page].<br />
<br />
<br />
<br />
== Why This Matters ==<br />
<br />
The domain name, you select for your Active Directory domain, is also going to be the primary domain, that the AD DNS server is authoritative for. All of your PCs in Active Directory are going to have a name within this domain. For Active Directory to work properly computers that are a part of it need all of these names to resolve correctly. This means it must serve as the DNS server for all the PCs that exists within your domain. Problems can arise when there is a DNS conflict, where two DNS servers resolve the same name to two different addresses. A DNS conflict is not the same as say an IP address conflict, it does not prevent network traffic from flowing, but when one happens you can often have the problem where traffic is flowing to addresses you don't intend, or names that you want resolved aren't resolving at all.<br />
<br />
For example, if you named your AD domain "samdom.example.com", your AD DNS server would naturally be authoritative for all requests at or below the "samdom.example.com" level of the hierarchy. It would directly respond to all requests for names within that domain such as "workstation.samdom.example.com" or "server.samdom.example.com", or any other name configured within the DNS server. If you requested www.samba.org, that would pose no problem either, it would see that it is not authoritative for the samba.org domain and forward the request to the server that is responsible for the name, then return the answer to you.<br />
<br />
But what if you also have an external website such as "www.samdom.example.com", probably handled by a different external DNS server? Well, when you request that name, the DNS server is going to see that it is responsible for the "samdom.example.com" domain, and look up a response for you. If it doesn't have one, it is not going to forward the request to any other server for resolution, because it believes it is the final authority for this domain. And so it will return you a "no such name exists response", or NXDOMAIN.<br />
<br />
== Security Implications ==<br />
<br />
While technically not an aspect of domain naming per-se, the security implications of DNS are very important to consider. Your AD DNS server will contain a list of all PCs within your network, and while most DNS servers do not allow just anyone to request a full listing of domain names (also known as a zone transfer), allowing devices outside your domain to resolve names from this list still represents an unnecessary exposure of internal information and a possible security risk. In addition most AD DNS servers are recursive, and running a recursive DNS server on the internet has important security implications beyond the scope of this documentation.<br />
<br />
Similarly, you should not send DNS requests for internal names outside of the internal network. Even if you trust the DNS server you are sending them to, DNS is not encrypted, and so potential for intercept exists along every router that passes the traffic, this represents a serious security risk. As an attacker who controls this traffic could direct your PCs traffic to whatever location he desired.<br />
<br />
For these reasons, a secure AD DNS server should only listen to requests that come from within your network, and a different DNS server should handle DNS requests external to your network. In addition all of your workstations should be configured to only look to your AD DNS server for DNS, and not to any external DNS servers. This is known as [https://en.wikipedia.org/wiki/Split-horizon_DNS split-horizon DNS].<br />
<br />
<br />
<br />
<br />
<br />
= NetBIOS Names =<br />
<br />
Before Windows utilized DNS, it relied upon another naming system, [[Terms_and_Abbreviations#NetBios|NetBIOS]] (technically NetBIOS-NS), and the [[Terms_and_Abbreviations#Windows_Internet_Naming_Service_.28WINS.29|Windows Internet Name Service (WINS)]]. NetBIOS is similar to DNS in that it can serve as a directory service, but more limited as it has no provisions for a name hierarchy and names were limited to 15 characters. However NetBIOS does provide a means for peer-to-peer name resolution over the layer 2 broadcast domain (all PCs within the same subnet). Microsoft extended this with WINS to provide name resolution across layer 3 (routed) networks. If you have name resolution working in a network without DNS service, it is probably being handled by NetBIOS.<br />
<br />
While the days of those systems are mostly behind us now, traces of this legacy system still linger all throughout Windows. For example some aspects of Windows networking, such as networking neighborhood and its descendants, are still reliant upon this service. In particular every AD Domain also has a NetBIOS name along with its traditional DNS name. And every computer in your domain will also have a NetBIOS name (even if you turn the NetBIOS names service off). Most of the time, this defaults to the first 15 characters of the PCs name. <br />
<br />
<br />
<br />
== Why This Matters ==<br />
<br />
Just as DNS names can conflict, NetBIOS names can also conflict. Most of the time this will not pose an issue. Windows queries NetBIOS as a last resort for name resolution, and without a WINS server in your network, NetBIOS names cannot cross layer 2 (the subnet). However, while Active Directory already prevents you from having PCs with duplicate names, it does not prevent you from having duplicate NetBIOS names, which generally would only happen if the first 15 digits of your computer name were identical. Such name conflicts should be avoided.<br />
<br />
<br />
<br />
== NetBIOS Domain Naming ==<br />
<br />
Since NetBIOS has [https://support.microsoft.com/en-us/kb/188997 very few possibilities] in what domain names are acceptable, there is less you can do to avoid potential naming conflicts. Typically and recommended is, to pick the first part off your domain name for the NetBIOS domain (note: this another name for 'workgroup'). For example if your domain name is "samdom.example.com", you might pick the NetBIOS name "SAMDOM". Whatever you use for your NetBIOS name, ensure it is just one word, no longer than 15 characters and without any punctuation, this includes periods '.' . This appears to be especially important with Windows 10 clients, there have been reports that they cannot join the domain if the NetBIOS domain name contains a period. <br />
<br />
<br />
<br />
<br />
<br />
= How Should I Name My Domain? =<br />
<br />
Before we look at your options, let's look at some desirable features our domain name should have:<br />
<br />
* The domain name should be globally unique. This ensures that no matter what the computer is configured to use for DNS resolution, the name will either resolve properly or will not return a domain (NXDOMAIN). There should never be a domain name conflict!<br />
<br />
* The domain should be associative to your organization. The domain name should ideally be related to your organization, making it easy to remember.<br />
<br />
* The domain should be in your control. A domain name that you control (by being the registered owner of it) helps to prevent malicious use. Domain name registration is cheap and desirable for any enterprise anyway.<br />
<br />
* The domain name should still be a valid domain name, that way you can get 3rd party SSL certificates for it, if you desire.<br />
<br />
* The FQDN for an Active Directory domain name is limited to 64 bytes, including the dots, an Active directory server name example : s4ad01.office.example.tld<br />
<br />
* Whatever domain name you use, it should not be resolvable from the internet, it is not a good idea to have any AD domain computer connected directly to the internet. <br />
<br />
So with those criteria in mind, lets look at some of your options:<br />
<br />
<br />
<br />
<br />
<br />
= Subdomain of a Domain You Own =<br />
<br />
In this scenario you would name your domain in the fashion of "subdomain.domainyouown.tld" such as "samdom.example.com". '''This is typically the best option you can select!''' It also aligns with Microsoft's current [https://technet.microsoft.com/en-us/library/cc738121%28WS.10%29.aspx best practices]. While the subdomain name can be anything you desire, keeping it short and simple is probably a good idea (e. g. "ad."). This style of name fulfills all the above criteria we laid out in a desirable domain name, most importantly:<br />
<br />
* It will be globally unique. Since you control the domains registration on the net (and presumably its DNS entries), you can ensure that the domain you use internally does not resolve to anything externally.<br />
<br />
* It will be a valid domain name for retrieving 3rd party SSL certificates.<br />
<br />
<br />
<br />
== Important Note ==<br />
<br />
When naming your domain, Windows and samba-tool also generate a [https://technet.microsoft.com/en-us/library/cc961556.aspx suggestion] legacy NetBIOS domain name. By default this is the first 15 characters of the leftmost domain name. So if your domain is named "ad.example.com", then the default suggestion would be simply "AD". Selecting such a NetBIOS domain name would be a bad idea, as it would be quite likely to conflict with any other domains that had the same NetBIOS name. This would pose an issue if you ever had to set up a trust relationship between these two domains. Instead select a custom name based upon your domain name, for example you might select "EXAMPLE" for a domain named "ad.example.com".<br />
<br />
<br />
<br />
== Common Objections ==<br />
<br />
=== My User Logins Does Not Match My Email ===<br />
<br />
You are correct, that the part of the user name that follows the @ sign, the User Principle Name Suffix (UPN Suffix), defaults to the domain name, and so would be "subdomain.domain.tld" by default under this scheme. However, the UPN Suffix is arbitrary and configurable. You can [https://technet.microsoft.com/en-us/library/cc772007.aspx configure] it to be whatever you like, including your users email. It must be unique among all security principal objects within a directory forest. This means the prefix of a UPN can be reused, just not with the same suffix.<br />
<br />
It has the following restrictions:<br />
<br />
It must be the DNS name of a domain, but does not need to be the name of the domain that contains the user.<br />
It must be the name of a domain in the current domain forest (which in Samba AD means the same thing), or an alternate name listed in the upnSuffixes attribute of the Partitions container within the Configuration container.<br />
<br />
<br />
<br />
=== The Style of the Domain Name Is to Long ===<br />
<br />
The addition of the suffix can be as short as you like it (using just "ad" or "ds" is very common). However, typing the domain name can be avoided entirely by setting the DNS Suffix and DNS suffix search list. When these variables are set, clients will attempt to resolve single label domain names like just "server" as "server.dnssuffix.tld". This is even valid with certificates, so you can issue a certificate for an internal server that would be good for "<nowiki>https://server/</nowiki>" instead of "<nowiki>https://server.samdom.example.com/</nowiki>" if you like. And if at some point you need to avoid the use of the DNS search suffix on a DNS inquiry, you can do that by specifying the FQDN remembering to include the final '.' for the root zone.<br />
<br />
<br />
<br />
=== This Does Not Work Right with My External Domain ===<br />
<br />
This assumption is incorrect. The AD DNS server will only be authoritative for this single subdomain and the names beneath it. It is not responsible for any other domain names. Thus if your AD Domain Name is "samdom.example.com", and you ask it to resolve the name "www.example.com", it will recognize that is not authoritative for "www.example.com" and so will forward the request on to the external server that is authoritative for that domain.<br />
<br />
<br />
<br />
=== My NetBIOS Name Can Conflict ===<br />
<br />
A valid concern. However the name suggested by samba-tool and in the Windows DC Promo wizard is only a suggestion. You can select any NetBIOS name you wish. Picking one based off of your domain name might be a good alternative, or pick any other associative but unique name for the NetBIOS domain name.<br />
<br />
<br />
<br />
=== I have to Use Different Names to Resolve Host Names Internally and Externally ===<br />
<br />
Yes, since under this scheme no DNS service outside your network can resolve names within it, a different DNS name is necessary to resolve the same computer within your network as you might use to resolve it outside your network. For the most part this is a good thing, the internal and external address of computers generally are fundamentally different, and will have different IP address.<br />
<br />
However in some situations you might find it inadvisable to add this extra complication into your configurations. For example, if you distribute mail settings for users to configure, the added complexity of having to use a different mail scheme externally and internally might be too much for them. On mobile devices this scheme might not even be workable. Thankfully there are a couple solutions to this problem:<br />
<br />
* '''Allow traffic for the external name to route out and back into your network.'''<br />
: Often no extra configuration is necessary for this setup, traffic bound for external IP addresses generally can be treated the same as any other internet bound traffic, even if its eventual destination is back inside your network.<br />
<br />
* '''Create a DNS zone that only resolves the name want.'''<br />
: There is a clever trick you can do in AD DNS to only resolve a single host within a zone, and still have the rest of the hosts resolved normally by the external server. Create a DNS zone named "host.domain.tld", for example "mail.example.com". Inside the zone create a single A or CNAME record (CNAME is probably preferred) leaving the name of the record blank. As the dialog tells you, this name will be used to resolve the parent domain, in this case, "host.domain.tld".<br />
<br />
: This will do exactly what you want. "host.domain.tld" will be resolved as you specify by your DNS server, while requests to other hosts under "domain.tld" will be resolved externally, since "host.domain.tld" and "domain.tld" correspond to different zones. If you use a CNAME as your parent record you can point this back to the record in your internal domain name.<br />
<br />
<br />
<br />
<br />
<br />
= Using an Invalid TLD =<br />
<br />
In this scenario you would name your domain in the format of "domain.invalid.tld" such as "SAMDOM.local". Using an invalid top-level domain (TLD) such as .local or .internal used to be a very common practice. In fact all versions of Microsoft's Small Business Servers were configured to use a domain in the form of "domain.local". Since the .local TLD is officially reserved by ICANN, you can also be assured that no external DNS server will resolve this domain. However this style of name has a few major issues:<br />
<br />
* The .local TLD is used by some zeroconf systems, most importantly Apple's Bonjour service. Using them together will not work correctly.<br />
<br />
* Invalid TLDs, such as .local or .internal, will soon be unable to get SSL certificates from any of the major certificate providers. The CA/Browser Forum has [https://www.digicert.com/internal-names.htm?SSAID=314743 decided] that no certificates should be issued for these invalid domains starting November 1, 2015. In fact, you are now unable to purchase a certificate for these names if they expire after this date. This includes Subject Alternative Names (SAN) used within otherwise valid certificates (this is a very common configuration for Microsoft Exchange). While internal certificate authorities have no such restriction, having this option open to you is always a good thing.<br />
<br />
* It is possible that the invalid TLD you are now using, could become a valid TLD in the future. While .local is reserved by ICANN, the TLD system is currently scheduled to undergo a vast [http://www.gtld.com/ expansion] of the generic TLD (gTLD) it supports, from 22 to over a thousand new names. This trend is likely to continue.<br />
<br />
For the same reason, names with other invalid TLDs should be avoided, including .internal and .lan.<br />
<br />
There is however a TLD that can be used instead of things like .local , if you read RFC3875, you will find that <code>home.arpa</code><br />
has been created just for this purpose.<br />
<br />
<br />
<br />
<br />
<br />
= Using Your external Domain Name =<br />
<br />
In this scenario, you simply reuse internally, your external domain name, in the format "domain.tld", for example "example.com". This is not a valid option, it will add unnecessary complication to your DNS system. As explained earlier, such a system introduces the potential for a domain name conflict, typically between a name that is either not present internally, or a name that resolves differently externally to internally. This will lead to duplication of entries you have on the external server, on your internal server, but this will be impracticable if you have a lot of external DNS entries or if they change frequently. You should pick an internal naming scheme that never conflicts with your external naming scheme, never use your external dns domain 'as-is' for your AD domain name, at the very least, use a subdomain. For instance, if your external domain is "example.com", you could use something like "ad.example.com".<br />
<br />
<br />
= Using a Generic Domain Name =<br />
<br />
It has been suggested, for organisations that are subject to a lot of mergers and acquisitions, using a generic domain name such as "corp.local" might be a valid option. Since domain renaming and migration is often a difficult and costly operation, there may be some validity to this, but there is no guarantee that the selected domain name might not be chosen by another admin thinking along the same lines as yourself. This would make a domain merger much more difficult. In addition, while the generic name can be hidden from the users by use of custom UPN suffixes and DNS search suffixes, an old domain name with guaranteed uniqueness could also be hidden in the same fashion.<br />
<br />
<br />
<br />
<br />
<br />
= Using a Different Domain Name =<br />
<br />
In this scenario you use a different, unused domain name from your primary internet domain name. For example you might use a different TLD ("example.net" as opposed to "example.com") or an entirely different domain name together, but still registered normally with ICANN. The purported advantage of this scheme is the ability to resolve some domain names (for example, "mail.domain.tld") via the same name internally and externally.<br />
<br />
While this is true as far as it goes, the same effect can be achieved in other schemes by doing some clever DNS tricks (described above). Furthermore, any time you resolve names differently externally to internally, there is the potential for an unwanted DNS naming conflict, so it is questionable if it is ever desirable to do this across the whole domain. This scheme also leaks a minor amount of sensitive information (the domain name) onto the net, and represents a minor additional cost (the cost of the domain registration), while offering only marginal advantages. It may however be a valid option for some organizations, such a scheme is often used by ISPs and other internet focused organizations.<br />
<br />
<br />
<br />
<br />
<br />
= The Realm name =<br />
<br />
This is quite simple, once you have selected the DNS domain, you must use this for the realm name, but in most cases it is expressed in uppercase. For example, the DNS domain <code>samdom.example.com</code> would be the Realm name <code>SAMDOM.EXAMPLE.COM</code>.<br />
<br />
<br />
----<br />
[[Category:Active Directory]]</div>Hortimechhttps://wiki.samba.org/index.php?title=Package_Dependencies_Required_to_Build_Samba&diff=19028Package Dependencies Required to Build Samba2023-08-04T08:30:06Z<p>Hortimech: /* updated instructions to install required dependencies</p>
<hr />
<div>= Operating System-independent Overview =<br />
<br />
The following is an operating system-independent list of libraries and utilities <u>required to build</u> and install Samba. Depending on your distribution, the name of packages can differ. Usually library packages are named <code>lib*-devel</code> or <code>lib*-dev</code>. For a list of distribution specific package installation commands, see [[#Distribution-specific_Packages_Required_to_Build_Samba|Distribution-specific Packages Required to Build Samba]].<br />
<br />
{{Imbox<br />
| type = note<br />
| text = If you do not want to build Samba yourself, see [[Distribution-specific_Package_Installation|Distribution-specific Package Installation]].<br />
}}<br />
<br />
<br />
<br />
== Mandatory ==<br />
<br />
{| class="wikitable"<br />
!Libraries and utilities<br />
!Required for<br />
|-<br />
|python3<br />
|Several utilities, such as <code>samba-tool</code> and the build system ([[Waf|Waf]]), are written in Python 3.x.<br />
|-<br />
|perl<br />
|<br />
|-<br />
|Parse::Yapp<br />
|Used in PIDL, our IDL compiler.<br />
|-<br />
|acl<br />
|Required only on [[Active_Directory_Domain_Controller|Samba Active Directory domain controllers]] and member servers using [[Setting_up_a_Share_Using_Windows_ACLs|Windows ACLs]].<br />
|-<br />
|xattr<br />
|Required only on [[Active_Directory_Domain_Controller|Samba Active Directory domain controllers]] and member servers using [[Setting_up_a_Share_Using_Windows_ACLs|Windows ACLs]].<br />
|-<br />
|gnutls >= 3.4.7<br />
|Required for cryptography<br />
|-<br />
|zlib<br />
|Provides the crc32 checksum across Samba and compression for DRSUAPI (AD replication)<br />
|}<br />
<br />
== Optional ==<br />
<br />
{| class="wikitable"<br />
!Libraries and utilities<br />
!Required for<br />
|-<br />
|krb5-devel<br />
|MIT Kerberos support (except a very bare-bones file server and if not using internal Heimdal). Requires MIT Kerberos 1.15.1 or later.<br />
|-<br />
|krb5-server<br />
|MIT Kerberos support (Samba as an AD DC if not using the internal Heimdal). Requires MIT Kerberos 1.15.1 or later.<br />
|-<br />
|blkid<br />
|<br />
|-<br />
|dbus<br />
|vfs_snapper<br />
|-<br />
|jansson-devel<br />
|Audit logging (Samba 4.7 and later), Samba AD DC<br />
|-<br />
|readline<br />
|<br />
|-<br />
|bsd or setproctitle<br />
|Process title updating support.<br />
|-<br />
|xsltproc or docbook<br />
|Man pages and other documentation.<br />
|-<br />
|pam-devel<br />
|PAM support. For example, to [[Authenticating_Domain_Users_Using_PAM|authenticate domain users using PAM]].<br />
|-<br />
|cups<br />
|[[Setting_up_Samba_as_a_Print_Server#CUPS|CUPS printer sharing support]].<br />
|-<br />
|openldap<br />
|[[NT4_Domains|NT4 Domains]] support, including the [[Migrating_a_Samba_NT4_Domain_to_Samba_AD_(Classic_Upgrade)|Samba NT4 to AD migration (Classic Upgrade)]].<br />
|-<br />
|python3-markdown<br />
|For samba-tool domain schemaupgrade<br />
|-<br />
|patch<br />
|For samba-tool domain schemaupgrade<br />
|-<br />
|gpgme-devel<br />
|For reading passwords in samba-tool user passwordsync from encrypted cleartext<br />
|-<br />
|python3-gpg or python3-gpgme<br />
|For storing passwords for samba-tool user passwordsync in encrypted cleartext<br />
|-<br />
|flex<br />
|Generates C source from the .l lexical analyzer files in our source tree. Used when building the embedded Heimdal or spotlight support<br />
|}<br />
<br />
== Selftest ==<br />
<br />
The following additional packages / utilities are required only for running some tests.<br />
<br />
{| class="wikitable"<br />
!Libraries and utilities<br />
!Required for<br />
|-<br />
|bash<br />
|Some blackbox tests are bash-specific<br />
|-<br />
|python3-iso8601<br />
|Used by our selftest and required from the system in samba 4.14 and later.<br />
|-<br />
|python3-cryptography<br />
|Used by our selftest to test Kerberos<br />
|-<br />
|python3-asn1<br />
|Used by our selftest to test ASN.1 protocols like LDAP and Kerberos<br />
|}<br />
<br />
=Packages Required to Build Samba=<br />
<br />
If you download a version of Samba >= 4.11.0 (either by <code>git</code> or by using <code>wget</code> to obtain a tarball), you will find in the base of the code a directory named <code>bootstrap</code>. Inside this directory there is another directory named <code>generated-dists</code>. Inside that directory there are further directories named after distros, inside of each of those directories there is a bash script named <code>bootstrap.sh</code>, running this script will install the required dependencies to build the downloaded version of Samba on your distro.<br />
<br />
For example, the latest version of Samba is 4.18.5 (This is at the beginning of August 2023), which you can download with:<br />
$ wget https://download.samba.org/pub/samba/stable/samba-4.18.5.tar.gz<br />
<br />
After the download, you should find a tarball named <code>samba-4.18.5.tar.gz</code><br />
<br />
You can unpack this tarball with:<br />
<br />
$ tar xf samba-4.18.5.tar.gz<br />
<br />
After the tarball is unpacked, you should now find that you have a directory named <code>samba-4.18.5</code>.<br />
You can now <code>cd</code> directly into the directory that holds the distro directories with:<br />
<br />
$ cd samba-4.18.5/bootstrap/generated-dists<br />
<br />
Checking the contents of the directory with <code>ls</code> should produce output like this:<br />
<br />
$ ls<br />
centos7 centos8s debian11 f37mit120 fedora37 opensuse154 ubuntu1804 ubuntu1804-32bit ubuntu2004 ubuntu2204 Vagrantfile<br />
<br />
<br />
{{Imbox<br />
| type = note<br />
| text = This list may differ by the version of Samba you are attempting to build.<br />
}}<br />
<br />
<br />
If your distro is amongst the listed directories, then <code>cd</code> into the relevant directory and run the <code>bootstrap.sh</code> script you will find there. This will install all the required dependencies.<br />
<br />
If your distro isn't mentioned then you will have to attempt to identify the required dependencies from the information below.<br />
<br />
<br />
==Manually maintained Distribution-specific Package lists==<br />
'''This list is for older Samba versions (4.10 and earlier) and distributions not included in the table above'''<br />
<br />
{{Imbox<br />
| type = warning<br />
| text = The following list of commands is neither provided nor actively verified by the Samba team. Additionally, it might be possible that you require additional or less packages than shown in the later commands - depending on the purpose you install Samba. Do not depend on the lists below, they are just a guide, use the <code>bootstrap.sh</code> scripts supplied above.<br />
}}<br />
<br />
<br />
<br />
=== Samba Active Directory Domain Controller ===<br />
<br />
The following installation commands include the BIND DNS server. If you are using the Samba internal DNS server, omit the BIND package(s). However, you require the package containing the <code>nsupdate</code> utility to enable dynamic DNS support.<br />
<br />
<br />
<br />
==== Debian / Ubuntu ====<br />
<br />
# apt-get install acl attr autoconf bind9utils bison build-essential \<br />
debhelper dnsutils docbook-xml docbook-xsl flex gdb libjansson-dev krb5-user \<br />
libacl1-dev libaio-dev libarchive-dev libattr1-dev libblkid-dev libbsd-dev \<br />
libcap-dev libcups2-dev libgnutls28-dev libgpgme-dev libjson-perl \<br />
libldap2-dev libncurses5-dev libpam0g-dev libparse-yapp-perl \<br />
libpopt-dev libreadline-dev nettle-dev perl perl-modules pkg-config \<br />
python-all-dev python-crypto python-dbg python-dev python-dnspython \<br />
python3-dnspython python-gpgme python3-gpgme python-markdown python3-markdown \<br />
python3-dev xsltproc zlib1g-dev liblmdb-dev lmdb-utils<br />
<br />
Notes:<br />
* Before Debian 8 and Ubuntu 14.04, <code>libgnutls28-dev</code> was known as <code>libgnutls-dev</code>.<br />
* perl-modules was replace by perl-modules-5.24 on Debian 9<br />
* perl-modules was replace by perl-modules-5.26 on Ubuntu 17.10<br />
* python-gpgme and python3-gpgme were replaced by python-gpg and python3-gpg on Debian 9 and Ubuntu 17.10<br />
* If you are building Samba on a system that uses systemd, you will also require the libsystemd-dev package<br />
* To use a [[Running a Samba AD DC with MIT Kerberos KDC | MIT Kerberos KDC]], you will need <code>libkrb5-dev</code> and <code>krb5-kdc</code>, version 1.15.1 or greater.<br />
<br />
<br />
==== Red Hat Enterprise Linux 8 / CentOS 8 ====<br />
<br />
Install the following packages to build Samba as an Active Directory (AD) domain controller (DC) on a minimal Red Hat Enterprise Linux (RHEL) 8 or CentOS 8 installation:<br />
<br />
# yum install docbook-style-xsl gcc gdb gnutls-devel gpgme-devel jansson-devel \<br />
keyutils-libs-devel krb5-workstation libacl-devel libaio-devel \<br />
libarchive-devel libattr-devel libblkid-devel libtasn1 libtasn1-tools \<br />
libxml2-devel libxslt lmdb-devel openldap-devel pam-devel perl \<br />
perl-ExtUtils-MakeMaker perl-Parse-Yapp popt-devel python3-cryptography \<br />
python3-dns python3-gpg python36-devel readline-devel rpcgen systemd-devel \<br />
tar zlib-devel<br />
<br />
To install all required packages, you must enable the following repositories:<br />
{| class="wikitable"<br />
!RHEL 8<br />
!CentOS 8<br />
|-<br />
|<code>Base</code><br />
|<code>Base</code><br />
|-<br />
|<code>AppStream</code><br />
|<code>AppStream</code><br />
|-<br />
|<code>CodeReady Linux Builder</code>*<br />
|<code>PowerTools</code><br />
|-<br />
|<code>EPEL</code>**<br />
|<code>EPEL</code>**<br />
|}<br />
<nowiki>*</nowiki> For further details about the CodeReady Linux Builder repository, see https://access.redhat.com/articles/4348511.<br />
<br />
<nowiki>**</nowiki> The Extra Packages for Enterprise Linux (EPEL) repository is not part of the distribution. For further details about EPEL, see https://fedoraproject.org/wiki/EPEL.<br />
<br />
For enabling PowerTools repository on CentOS 8, please use following commands:<br />
<br />
# yum -y install dnf-plugins-core<br />
# yum config-manager --set-enabled PowerTools<br />
<br />
If the DC should act as a print server with CUPS back end, additionally install the following package<br />
<br />
# yum install cups-devel<br />
<br />
==== Red Hat Enterprise Linux 7 / CentOS 7 / Scientific Linux 7 ====<br />
<br />
Install the following packages to build Samba as an Active Directory (AD) domain controller (DC) on a minimal Red Hat Enterprise Linux 7, CentOS 7, or Scientific Linux 7 installation:<br />
<br />
# yum install attr bind-utils docbook-style-xsl gcc gdb krb5-workstation \<br />
libsemanage-python libxslt perl perl-ExtUtils-MakeMaker \<br />
perl-Parse-Yapp perl-Test-Base pkgconfig policycoreutils-python \<br />
python2-crypto gnutls-devel libattr-devel keyutils-libs-devel \<br />
libacl-devel libaio-devel libblkid-devel libxml2-devel openldap-devel \<br />
pam-devel popt-devel python-devel readline-devel zlib-devel systemd-devel \<br />
lmdb-devel jansson-devel gpgme-devel pygpgme libarchive-devel<br />
<br />
<br />
{{Imbox<br />
| type = note<br />
| text = Red Hat Enterprise Linux 7 does not include all required packages to build a Samba AD DC. Enable the external Extra Packages for Enterprise Linux (EPEL) repository before you install the packages. For details, see https://fedoraproject.org/wiki/EPEL. Enabling the EPEL repository is not requied on CentOS 7 and Scientific Linux 7.<br />
}}<br />
<br />
{{Imbox<br />
| type = note<br />
| text = Red Hat Enterprise Linux 7 and deritivites do not provide a GnuTLS version >= 3.4.7, even when EPEL is used. Users building Samba 4.12 will need to obtain GnuTLS from outside RHEL7 / CentOS7 / EPEL to use Samba 4.12.<br />
}}<br />
<br />
<br />
If the DC should act as print server (not recommended) with CUPS back end, additionally install:<br />
<br />
# yum install cups-devel<br />
<br />
==== Fedora ====<br />
<br />
To install the build dependencies for Samba on Fedora, run the following command:<br />
<br />
# dnf builddep libldb samba<br />
<br />
==== openSUSE ====<br />
<br />
# zypper source-install --build-deps-only libldb1 samba<br />
<br />
==== Gentoo ====<br />
<br />
See [[Package_Dependencies_Required_to_Build_Samba/Building Samba on Gentoo|Building Samba on Gentoo]] <br />
<br />
=== Samba Domain Member ===<br />
<br />
==== Red Hat Enterprise Linux 8 / CentOS 8 ====<br />
<br />
Install the following packages to build Samba as a domain member on a minimal Red Hat Enterprise Linux (RHEL) 8 or CentOS 8 installation:<br />
<br />
# yum install autoconf automake docbook-style-xsl gcc gdb jansson-devel \<br />
krb5-devel krb5-workstation libacl-devel libarchive-devel \ <br />
libattr-devel libtasn1-tools libxslt lmdb-devel make openldap-devel \<br />
pam-devel python36-devel rpcgen<br />
<br />
To install all required packages, you must enable the following repositories:<br />
{| class="wikitable"<br />
!RHEL 8<br />
!CentOS 8<br />
|-<br />
|<code>Base</code><br />
|<code>Base</code><br />
|-<br />
|<code>AppStream</code><br />
|<code>AppStream</code><br />
|-<br />
|<code>CodeReady Linux Builder</code>*<br />
|<code>PowerTools</code><br />
|-<br />
|<code>EPEL</code>**<br />
|<code>EPEL</code>**<br />
|}<br />
<nowiki>*</nowiki> For further details about the CodeReady Linux Builder repository, see https://access.redhat.com/articles/4348511.<br />
<br />
<nowiki>**</nowiki> The Extra Packages for Enterprise Linux (EPEL) repository is not part of the distribution. For further details about EPEL, see https://fedoraproject.org/wiki/EPEL.<br />
<br />
For enabling PowerTools repository on CentOS 8, please use following commands:<br />
<br />
# yum -y install dnf-plugins-core<br />
# yum config-manager --set-enabled PowerTools<br />
<br />
If the domain member should act as a print server with CUPS back end, additionally install the following package:<br />
<br />
# yum install cups-devel<br />
<br />
==== Red Hat Enterprise Linux 7 / CentOS 7 / Scientific Linux 7 ====<br />
<br />
# yum install autoconf automake gcc gdb krb5-devel krb5-workstation \<br />
openldap-devel make pam-devel python-devel docbook-style-xsl \<br />
libacl-devel libattr-devel libxslt <br />
<br />
<br />
<br />
=== Samba NT4 PDC ===<br />
<br />
To be added.</div>Hortimechhttps://wiki.samba.org/index.php?title=Setting_up_Samba_as_an_Active_Directory_Domain_Controller&diff=19027Setting up Samba as an Active Directory Domain Controller2023-08-02T14:30:38Z<p>Hortimech: /* updated as suggested by Pedro Bezunartea López</p>
<hr />
<div>= Introduction =<br />
<br />
Starting from version 4.0 (released in 2012,) Samba is able to serve as an Active Directory (AD) domain controller (DC). Samba operates at the forest functional level of '''Windows Server 2008 R2''' which is more than sufficient to manage sophisticated enterprises that use Windows 10/11 with strict compliance requirements (including NIST 800-171.)<br />
<br />
If you are installing Samba in a production environment, it is recommended to run two or more DCs for failover reasons, more detail on the provisioning of a failover DC can be found elsewhere on the wiki. This documentation describes how to set up Samba as the first DC to build a new AD forest. Additionally, use this documentation if you are migrating a Samba NT4 domain to Samba AD. To join Samba as an additional DC to an existing AD forest, see [[Joining_a_Samba_DC_to_an_Existing_Active_Directory|Joining a Samba DC to an Existing Active Directory]]. <br />
<br />
Samba as an AD DC only supports:<br />
* The integrated LDAP server as AD back end. For details, see the frequently asked question (FAQ) [[FAQ#Does_Samba_AD_DCs_Support_OpenLDAP_or_Other_LDAP_Servers_as_Back_End.3F|Does Samba AD DCs Support OpenLDAP or Other LDAP Servers as Back End?]]<br />
* The [http://www.h5l.se/ Heimdal] Kerberos Key Distribution Center (KDC).<br />
: Samba provides experimental support for the [https://web.mit.edu/kerberos/ MIT Kerberos] KDC provided by your operating system if you run Samba 4.7 or later and has been built using the <code>--with-system-mitkrb5</code> option. In other cases Samba uses the Heimdal KDC included in Samba. For further details about Samba using the MIT KDC, and why it is experimental see [[Running a Samba AD DC with MIT Kerberos KDC]].<br />
* Hosting and Administering of Group Policy Objects to be used for enterprise fleet management<br />
: {{Imbox<br />
| type = important<br />
| text = Installation of Samba and associated provisioning of a domain controller does not automatically translate into Group Policy functionality. Please keep this in mind, and expect to update this flag in the <code>smb.conf</code> post provisioning<br />
}}<br />
<br />
This tutorial assumes that this is a fresh installation of Samba on a fresh operating system installation. It is important to note that there is a distinction between installing of Samba and Provisioning of Samba. In general, the entire process of setting up a Samba domain controller consists of 5 steps which are relatively straight forward. These steps are as follows:<br />
<br />
# Installation of Samba and associated packages<br />
# Deletion of pre-configured Samba and Kerberos placeholder configuration files<br />
# Provisioning of Samba using the automatic provisioning tool<br />
# Editing of the <code>smb.conf</code> as needed (enabling of Group Policy and/or other features as needed) see [[Group_Policy|Group Policy]] for more information<br />
# Any environmental configuration based on Unix/Linux Distribution<br />
<br />
This page covers a lot of ground for Samba installations on both Unix and Linux systems. The installation process varies slightly based on environment, so expect to follow the linked web pages in multiple tabs throughout this read. For the remainder of this tutorial the following example information is used:<br />
<br />
* Hostname = <code>DC1</code><br />
* DC local IP Address = <code>10.99.0.1</code><br />
* Authentication Domain = <code>SAMDOM.EXAMPLE.COM</code><br />
* Top level Domain = <code>EXAMPLE.COM</code><br />
<br />
= Preparing the Installation =<br />
<br />
==== Fresh Installation ====<br />
<br />
<br />
* Select a DNS domain for your AD forest. It is not recommended to use the top level domain for your organization. This is because the domain used during the installation of Samba will resolve to the domain controller. For Example: If your organization used <code>EXAMPLE.COM</code> as their domain and this was used during the Samba installation process, then the public facing website would no longer be acceptable (assuming the publicly accessible website was not running on the DC, which it shouldn't!) It would be wise to define a subdomain for your Domain Controller to reside in. In this tutorial <code>SAMDOM.EXAMPLE.COM</code> is used, however in a lab environment it is not necessary to own a publicly accessible domain and <code>.INTERNAL</code> could hypothetically be used. The name will also be used as the AD Kerberos realm.<br />
: {{Imbox<br />
| type = important<br />
| text = Make sure that you provision the AD using a DNS domain that will not need to be changed. Samba does not support renaming the AD DNS zone and Kerberos realm. Do not use <code>.local</code> for the TLD, this is used by Avahi.<br />
}}<br />
: For additional information, see [[Active_Directory_Naming_FAQ|Active Directory Naming FAQ]].<br />
<br />
* Select a host name for your AD DC which consists of less than 15 characters (netbios limitation.) A fantastic hostname is <code>DC1</code><br />
: Do not use NT4-only terms as host name, such as <code>PDC</code> or <code>BDC</code>. These modes do not exist in an AD and cause confusion.<br />
<br />
* Set a static IP address on the DC and make the associated reservation on your router. '''Important:''' The Samba domain controller will become your DNS resolver for all domain-joined workstations. As a result it may be required to assign this IP address outside of your DHCP pool<br />
<br />
* Disable tools, such as <code>resolvconf</code>, that automatically update your <code>/etc/resolv.conf</code> DNS resolver configuration file. AD DCs and domain members must use an DNS server that is able to resolve the AD DNS zones. (More information on this on the [[Distribution-specific_Package_Installation| Distribution Specific Package Installation]] page)<br />
<br />
* Verify that the <code>/etc/hosts</code> file on the DC correctly resolves the fully-qualified domain name (FQDN) and short host name to the LAN IP address of the DC. For example:<br />
127.0.0.1 localhost<br />
10.99.0.1 DC1.samdom.example.com DC1<br />
:The host name and FQDN must not resolve to the <code>127.0.0.1</code> IP address or any other IP address than the one used on the LAN interface of the DC.<br />
<br />
* Remove any existing <code>smb.conf</code> file. To list the path to the file:<br />
<br />
# smbd -b | grep "CONFIGFILE"<br />
CONFIGFILE: /usr/local/samba/etc/samba/smb.conf<br />
<br />
==== Only Applicable if Samba was Previously Installed ====<br />
* If you previously ran a Samba installation on this host:<br />
:<br />
<br />
:* Remove all Samba database files, such as <code>*.tdb</code> and <code>*.ldb</code> files. To list the folders containing Samba databases:<br />
<br />
# smbd -b | egrep "LOCKDIR|STATEDIR|CACHEDIR|PRIVATE_DIR"<br />
LOCKDIR: /usr/local/samba/var/lock/<br />
STATEDIR: /usr/local/samba/var/locks/<br />
CACHEDIR: /usr/local/samba/var/cache/<br />
PRIVATE_DIR: /usr/local/samba/private/<br />
<br />
: Starting with a clean environment helps to prevent confusion and ensures that no files from any previous Samba installation will be mixed with your new domain DC installation.<br />
<br />
<br />
= Installing Samba =<br />
<br />
<br />
{{:Installing_Samba}}<br />
<br />
<br />
<br />
= Provisioning a Samba Active Directory =<br />
<br />
{{Imbox<br />
| type = note<br />
| text = The AD provisioning requires root permissions to create files and set permissions.<br />
}}<br />
<br />
The Samba AD provisioning process creates the AD databases and adds initial records, such as the domain administrator account and required DNS entries. Samba comes with a built in command lined tool called <code>samba-tool</code> which can be used to automatically configure your <code>smb.conf</code> when ran in interactive mode. <br />
<br />
If you are migrating a Samba NT4 domain to AD, skip this step and run the Samba classic upgrade. For details, see [[Migrating_a_Samba_NT4_Domain_to_Samba_AD_(Classic_Upgrade)|Migrating a Samba NT4 Domain to Samba AD (Classic Upgrade)]].<br />
<br />
<br />
The <code>samba-tool domain provision</code> command provides several parameters to use with the interactive and non-interactive setup. For details, see:<br />
<br />
# samba-tool domain provision --help<br />
<br />
<br />
{{Imbox<br />
| type = note<br />
| text = When provisioning a new AD, it is recommended to enable the NIS extensions by passing the <code>--use-rfc2307</code> parameter to the <code>samba-tool domain provision</code> command. There are no disadvantages to enabling the NIS extensions, but enabling them in an existing domain requires manually extending the AD schema. For further details about Unix attributes in AD, see:<br />
* [[Setting_up_RFC2307_in_AD|Setting up RFC2307 in AD]]<br />
* [[Idmap_config_ad|idmap config = ad]]<br />
}}<br />
<br />
<br />
<br />
==== Parameter Reference ====<br />
<br />
Set the following parameters during the provisioning:<br />
<br />
{| class="wikitable"<br />
!Interactive Mode Setting<br />
!Non-interactive Mode Parameter<br />
!Explanation<br />
|-<br />
|<code>--use-rfc2307</code><br />
|<code>--use-rfc2307</code><br />
|Enables the NIS extensions required for the ADUC Unix Attributes tab.<br />
|-<br />
|<code>Realm</code><br />
|<code>--realm</code><br />
|Kerberos realm. The uppercase version of the AD DNS domain. For example: <code>SAMDOM.EXAMPLE.COM</code>.<br />
|-<br />
|<code>Domain</code><br />
|<code>--domain</code><br />
|NetBIOS domain name (Workgroup). This can be anything, but it must be one word, not longer than 15 characters and not containing a dot. It is recommended to use the first part of the AD DNS domain. For example: <code>samdom</code>. Do not use the computers short hostname.<br />
|-<br />
|<code>Server Role</code><br />
|<code>--server-role</code><br />
|Installs the domain controller <code>DC</code> role.<br />
|-<br />
|<code>DNS backend</code><br />
|<code>--dns-backend</code><br />
|Sets the DNS back end. The first DC in an AD must be installed using a DNS back end. Note that the <code>BIND9_FLATFILE</code> is not supported and will be removed in a future Samba version.<br />
|-<br />
|<code>DNS forwarder IP address</code><br />
|not available<br />
|This setting is only available when using the <code>SAMBA_INTERNAL</code> DNS back end. For details, see [[Samba_Internal_DNS_Back_End#Setting_up_a_DNS_Forwarder|Setting up a DNS Forwarder]].<br />
|-<br />
|<code>Administrator password</code><br />
|<code>--adminpass</code><br />
|Sets the domain administrator password. If the password does not match the complexity requirements, the provisioning fails. For details, see [https://technet.microsoft.com/en-us/library/cc786468%28v=ws.10%29.aspx Microsoft TechNet: Passwords must meet complexity requirements].<br />
|}<br />
<br />
Other parameters frequently used with the <code>samba-tool domain provision</code> command:<br />
* <code>--option="interfaces=lo eth0" --option="bind interfaces only=yes"</code>: If your server has multiple network interfaces, use these options to bind Samba to the specified interfaces. This enables the <code>samba-tool</code> command to register the correct LAN IP address in the directory during the join.<br />
<br />
<br />
{{Imbox<br />
| type = important<br />
| text = do NOT use <code>NONE</code> as the DNS backend, it is not supported and will be removed in a future Samba version.<br />
}}<br />
<br />
{{Imbox<br />
| type = important<br />
| text = If using Bind as the DNS backend, do NOT use <code>BIND9_FLATFILE</code>, it is not supported and will be removed in a future Samba version.<br />
}}<br />
<br />
{{Imbox<br />
| type = important<br />
| text = Once you have provisioned the first DC in an AD domain, do not provision any further DCs in the same domain, [[Joining_a_Samba_DC_to_an_Existing_Active_Directory|Join]] any further DCs.<br />
}}<br />
<br />
<br />
<br />
== Provisioning Samba AD in Interactive Mode ==<br />
<br />
As mentioned above, when run as root, <code>samba-tool</code> will automatically configure your <code>smb.conf</code> to build a domain controller. Interactive Mode will not automatically enable Group Policy support. However this can be added in afterwards by manually editing <code>smb.conf</code>.<br />
<br />
{{Imbox<br />
| type = note<br />
| text = When following the instructions below, it may be helpful to have the [[Group_Policy#Winbind|Group Policy]] page open in a separate browser tab or window.<br />
}}<br />
<br />
{{Imbox<br />
| type = warning<br />
| text = The installation of Samba will create a <code>smb.conf</code> file that must be discarded prior to running the Provisioning Tool in Interactive mode, or else it will fail. On most Linux distributions this can be done by running:<br />
# mv /etc/samba/smb.conf /etc/samba/smb.conf.initial<br />
}}<br />
<br />
With the existing <code>smb.conf</code> file removed, provision a Samba AD interactively by running:<br />
<br />
# samba-tool domain provision --use-rfc2307 --interactive<br />
Realm [SAMDOM.EXAMPLE.COM]: SAMDOM.EXAMPLE.COM<br />
Domain [SAMDOM]: SAMDOM<br />
Server Role (dc, member, standalone) [dc]: dc<br />
DNS backend (SAMBA_INTERNAL, BIND9_FLATFILE, BIND9_DLZ, NONE) [SAMBA_INTERNAL]: SAMBA_INTERNAL<br />
DNS forwarder IP address (write 'none' to disable forwarding) [10.99.0.1]: 8.8.8.8<br />
Administrator password: Passw0rd<br />
Retype password: Passw0rd<br />
Looking up IPv4 addresses<br />
Looking up IPv6 addresses<br />
No IPv6 address will be assigned<br />
Setting up share.ldb<br />
Setting up secrets.ldb<br />
Setting up the registry<br />
Setting up the privileges database<br />
Setting up idmap db<br />
Setting up SAM db<br />
Setting up sam.ldb partitions and settings<br />
Setting up sam.ldb rootDSE<br />
Pre-loading the Samba 4 and AD schema<br />
Adding DomainDN: DC=samdom,DC=example,DC=com<br />
Adding configuration container<br />
Setting up sam.ldb schema<br />
Setting up sam.ldb configuration data<br />
Setting up display specifiers<br />
Modifying display specifiers<br />
Adding users container <br />
Modifying users container <br />
Adding computers container <br />
Modifying computers container <br />
Setting up sam.ldb data <br />
Setting up well known security principals <br />
Setting up sam.ldb users and groups <br />
Setting up self join <br />
Adding DNS accounts <br />
Creating CN=MicrosoftDNS,CN=System,DC=samdom,DC=example,DC=com <br />
Creating DomainDnsZones and ForestDnsZones partitions <br />
Populating DomainDnsZones and ForestDnsZones partitions <br />
Setting up sam.ldb rootDSE marking as synchronized <br />
Fixing provision GUIDs <br />
A Kerberos configuration suitable for Samba 4 has been generated at /usr/local/samba/private/krb5.conf <br />
Setting up fake yp server settings <br />
Once the above files are installed, your Samba4 server will be ready to use <br />
Server Role: active directory domain controller <br />
Hostname: DC1 <br />
NetBIOS Domain: SAMDOM <br />
DNS Domain: samdom.example.com <br />
DOMAIN SID: S-1-5-21-2614513918-2685075268-614796884<br />
<br />
{{Imbox<br />
| type = note<br />
| text = The interactive provisioning mode supports passing further parameters to the <code>samba-tool domain provision</code> command. This enables you to modify parameters that are not part of the interactive setup.<br />
}}<br />
<br />
== Provisioning Samba AD in Non-interactive Mode ==<br />
<br />
For example, to provision a Samba AD non-interactively with the following settings:<br />
* Server role: <code>dc</code><br />
* NIS extensions enabled<br />
* Internal DNS back end<br />
* Kerberos realm and AD DNS zone: <code>samdom.example.com</code><br />
* NetBIOS domain name: <code>SAMDOM</code><br />
* Domain administrator password: <code>Passw0rd</code><br />
<br />
# samba-tool domain provision --server-role=dc --use-rfc2307 --dns-backend=SAMBA_INTERNAL --realm=SAMDOM.EXAMPLE.COM --domain=SAMDOM --adminpass=Passw0rd<br />
<br />
<br />
<br />
<br />
<br />
= Setting up the AD DNS back end =<br />
<br />
Skip this step if you provisioned the DC using the <code>SAMBA_INTERNAL</code> DNS back end.<br />
<br />
* Set up the BIND DNS server and the <code>BIND9_DLZ</code> module. For details, see [[Setting_up_a_BIND_DNS_Server|Setting up a BIND DNS Server]].<br />
<br />
* Start the BIND DNS server. For example:<br />
# systemctl start named<br />
: For details how to start services, see you distribution's documentation.<br />
<br />
<br />
<br />
<br />
= Configuring the DNS Resolver =<br />
<br />
Domain members in an AD use DNS to locate services, such as LDAP and Kerberos. For that, they need to use a DNS server that is able to resolve the AD DNS zone.<br />
<br />
On your DC, set the AD DNS domain in the <code>search</code> and the IP of your DC in the <code>nameserver</code> parameter of the <code>/etc/resolv.conf</code> file. For example:<br />
<br />
search samdom.example.com<br />
nameserver 10.99.0.1<br />
<br />
<br />
<br />
<br />
<br />
= Create a reverse zone =<br />
<br />
You can optionally add a reverse lookup zone.<br />
<br />
# samba-tool dns zonecreate <Your-AD-DNS-Server-IP-or-hostname> 0.99.10.in-addr.arpa -U Administrator<br />
Password for [administrator@SAMDOM.EXAMPLE.COM]:<br />
Zone 0.99.10.in-addr.arpa created successfully<br />
<br />
If you need more than one reverse zone (multiple subnets), just run the above command again but with the data for the other subnet.<br />
<br />
The reverse zone is directly live without restarting Samba or BIND.<br />
<br />
{{Imbox<br />
| type = note<br />
| text = You must start the Samba AD DC before you can add a reverse zone.<br />
}}<br />
<br />
<br />
Now that you have created a reversezone, it would be a good time to create the <code>PTR</code> (reverse) dns record for the new DC.<br />
<br />
For a DC with the FQDN of <code>dc1.samdom.example.com</code> and the ipaddress of <code>10.99.0.1</code>, to add a record to the <code>0.99.10.in-addr.arpa</code>, you would run a command like this:<br />
<br />
# samba-tool dns add <Your-AD-DNS-Server-IP-or-hostname> 0.99.10.in-addr.arpa 1 PTR dc1.samdom.example.com -U Administrator<br />
Password for [administrator@SAMDOM.EXAMPLE.COM]:<br />
Record added successfully<br />
<br />
{{Imbox<br />
| type = note<br />
| text = The reverse records are not added automatically, you must add them manually, or set Windows computers to add them when updating their dns records.<br />
}}<br />
<br />
<br />
<br />
<br />
<br />
= Configuring Kerberos =<br />
<br />
In an AD, Kerberos is used to authenticate users, machines, and services.<br />
<br />
During the provisioning, Samba created a Kerberos configuration file for your DC. Copy this file to your operating system's Kerberos configuration. For example:<br />
<br />
# cp /usr/local/samba/private/krb5.conf /etc/krb5.conf<br />
<br />
{{Imbox<br />
| type = important<br />
| text = Do not create a symbolic link to the the generated <code>krb5.conf</code> file. In Samba 4.7 and later, the <code>/usr/local/samba/private/</code> directory is no longer accessible by other users than the <code>root</code> user. If the file is a symbolic link, other users are not able to read the file and, for example, dynamic DNS updates fail if you use the <code>BIND_DLZ</code> DNS back end.<br />
}}<br />
<br />
The pre-created Kerberos configuration uses DNS service (SRV) resource records to locate the KDC.<br />
<br />
<br />
<br />
<br />
<br />
= Testing your Samba AD DC =<br />
<br />
To start the <code>samba</code> service manually, enter:<br />
<br />
# samba<br />
<br />
Samba does not provide System V init scripts, <code>systemd</code>, <code>upstart</code>, or other services configuration files.<br />
* If you installed Samba using packages, use the script or service configuration file included in the package to start Samba.<br />
* If you built Samba, see [[Managing_the_Samba_AD_DC_Service|Managing the Samba AD DC Service]].<br />
<br />
<br />
<br />
== Verifying the File Server (Optional)==<br />
<br />
To list all shares provided by the DC:<br />
<br />
Before Samba 4.11.0:<br />
<br />
$ smbclient -L localhost -N<br />
Anonymous login successful<br />
Domain=[SAMDOM] OS=[Unix] Server=[Samba x.y.z]<br />
<br />
Sharename Type Comment<br />
--------- ---- -------<br />
netlogon Disk <br />
sysvol Disk <br />
IPC$ IPC IPC Service (Samba x.y.z)<br />
Domain=[SAMDOM] OS=[Unix] Server=[Samba x.y.z]<br />
<br />
Server Comment<br />
--------- -------<br />
<br />
Workgroup Master<br />
--------- -------<br />
<br />
From Samba 4.11.0:<br />
<br />
smbclient -L localhost -N<br />
Anonymous login successful<br />
<br />
Sharename Type Comment<br />
--------- ---- -------<br />
sysvol Disk <br />
netlogon Disk <br />
IPC$ IPC IPC Service (Samba 4.12.6-Debian)<br />
SMB1 disabled -- no workgroup available<br />
<br />
<br />
{{Imbox<br />
| type = note<br />
| text = The <code>netlogon</code> and <code>sysvol</code> shares were auto-created during the provisioning and must exist on a DC.<br />
}}<br />
<br />
To verify authentication, connect to the <code>netlogon</code> share using the domain administrator account:<br />
<br />
$ smbclient //localhost/netlogon -UAdministrator -c 'ls'<br />
Enter Administrator's password: <br />
Domain=[SAMDOM] OS=[Unix] Server=[Samba x.y.z]<br />
. D 0 Tue Nov 1 08:40:00 2016<br />
.. D 0 Tue Nov 1 08:40:00 2016<br />
<br />
49386 blocks of size 524288. 42093 blocks available<br />
<br />
If one or more tests fail, see [[#Troubleshooting|Troubleshooting]].<br />
<br />
<br />
<br />
== Verifying DNS (Optional)==<br />
<br />
To verify that your AD DNS configuration works correctly, query some DNS records:<br />
<br />
* The tcp-based <code>_ldap</code> SRV record in the domain:<br />
<br />
$ host -t SRV _ldap._tcp.samdom.example.com.<br />
_ldap._tcp.samdom.example.com has SRV record 0 100 389 dc1.samdom.example.com.<br />
<br />
* The udp-based <code>_kerberos</code> SRV resource record in the domain:<br />
<br />
$ host -t SRV _kerberos._udp.samdom.example.com.<br />
_kerberos._udp.samdom.example.com has SRV record 0 100 88 dc1.samdom.example.com.<br />
<br />
* The A record of the domain controller:<br />
<br />
$ host -t A dc1.samdom.example.com.<br />
dc1.samdom.example.com has address 10.99.0.1<br />
<br />
* If you have created a reverse zone, the PTR record of the domain controller:<br />
<br />
$ host -t PTR 10.99.0.1<br />
1.0.99.10.in-addr.arpa domain name pointer dc1.samdom.example.com.<br />
<br />
If one or more tests fail, see [[#Troubleshooting|Troubleshooting]].<br />
<br />
<br />
<br />
== Verifying Kerberos (Optional) ==<br />
<br />
This is not explicitly required, but it is a good idea to verify that your Domain Controller's authentication mechanisms are operating as intended. To test this, login by requesting a Kerberos ticket for the Domain Administrator account:<br />
<br />
$ kinit administrator<br />
Password for administrator@SAMDOM.EXAMPLE.COM:<br />
<br />
: {{Imbox<br />
| type = note<br />
| text = If you do not pass the principal in the <code>user@REALM</code> format to the <code>kinit</code> command, the Kerberos realm is automatically appended.<br />Always enter the Kerberos realm in uppercase.<br />
}}<br />
<br />
* List the cached Kerberos tickets:<br />
<br />
$ klist<br />
Ticket cache: FILE:/tmp/krb5cc_0<br />
Default principal: administrator@SAMDOM.EXAMPLE.COM<br />
<br />
Valid starting Expires Service principal<br />
01.11.2016 08:45:00 12.11.2016 18:45:00 krbtgt/SAMDOM.EXAMPLE.COM@SAMDOM.EXAMPLE.COM<br />
renew until 02.11.2016 08:44:59<br />
<br />
If one or more tests fail, see [[#Troubleshooting|Troubleshooting]].<br />
<br />
<br />
<br />
<br />
<br />
= Configuring Time Synchronization (Optional Depending on Use-Case)=<br />
<br />
Kerberos requires synchronized time on all domain members. For further details and how to set up the <code>ntpd</code> or <code>chrony</code> service, see [[Time_Synchronisation|Time Synchronization]]. However if Samba is being used as a domain controller to administer Group Policy, it is possible to define a Group Policy Object that synchronizes workstations with <code>time.windows.com</code> post installation which simplifies this<br />
<br />
<br />
<br />
= Using the Domain Controller as a File Server (Optional) =<br />
<br />
{{Imbox<br />
| type = warning<br />
| text = Do not use an AD DC as a fileserver if you have multiple DC's. You should only use a DC as a fileserver, if it is the only Samba instance running in a domain. If you have multiple DC's, you should also set up Unix domain members and use them as fileservers. You should be aware that it is problematic to use a DC as a fileserver and can cause strange errors.<br />
}}<br />
<br />
<br />
While the Samba AD DC is able to provide file shares like all other installation modes, the Samba team does not recommend using a DC as a file server for the following reasons:<br />
<br />
* For anything but the smallest organizations, having more than one DC is a really good backup measure, and makes upgrades safer<br />
* It encourages upgrades of the DC to also be upgrades of the host OS every year or two, because there isn't complex data to transition or other services involved. <br />
* This means upgrades can be done by installing fresh, and replicating in the changes, which is better tested in Samba, gains new features and avoids a number of lingering data corruption risks. <br />
* The DC and file-server have different points at which an organization would wish to upgrade. The needs for new features on the DC and file server come at different times. Currently the AD DC is evolving rapidly to gain features, whereas the fileserver, after over 20 years, is quite rightly more conservative.<br />
* mandatory smb signing is enforced on the DC.<br />
<br />
<br />
If you do decide to use the Samba DC as a fileserver, please consider running a VM, on the DC, containing a separate Samba Unix domain member and use this instead.<br />
<br />
If you must use the Samba DC as a fileserver, you should be aware that the auto-enabled <code>acl_xattr</code> virtual file system (VFS) object enables you to only configure shares with Windows access control lists (ACL). Using POSIX ACLs with shares on a Samba DC does not work. <br />
<br />
You should be aware that if wish to use a vfs object on a DC share e.g. recycle, you must not just set <code>vfs objects = recycle</code> in the share. Doing this will turn off the default vfs objects <code>dfs_samba4</code> and <code>acl_xattr</code>. You must set <code>vfs objects = dfs_samba4 acl_xattr recycle</code>. <br />
<br />
To provide network shares with the full capabilities of Samba, set up a Samba domain member with file shares. For details, see:<br />
* [[Setting_up_Samba_as_a_Domain_Member|Setting up Samba as a Domain Member]]<br />
* [[Samba_File_Serving|Samba File Serving]]<br />
<br />
<br />
If you only have a small domain (small office, home network) and do not want to follow the Samba team's recommendation and use the DC additionally as a file server, configure Winbindd before you start setting up shares. For details, see [[Configuring_Winbindd_on_a_Samba_AD_DC|Configuring Winbindd on a Samba AD DC]].<br />
<br />
<br />
{{Imbox<br />
| type = warning<br />
| text = If you do use an AD DC as a fileserver, you must be aware that it can be problematic and can cause strange errors.<br />
}}<br />
<br />
{{Imbox<br />
| type = warning<br />
| text = If you do use an AD DC as a fileserver, do not add any of the 'idmap config' lines used on a Unix domain member. They will not work and will cause problems.<br />
}}<br />
<br />
{{Imbox<br />
| type = warning<br />
| text = If you do use an AD DC as a fileserver, You must set the permissions from Windows, do not attempt to use any of the old methods (force user etc) . They will not work correctly and will cause problems.<br />
}}<br />
<br />
= Troubleshooting =<br />
<br />
For further details, see [[Samba_AD_DC_Troubleshooting|Samba AD DC Troubleshooting]].<br />
<br />
<br />
<br />
<br />
<br />
= Further Samba-related Documentation =<br />
<br />
See [[User_Documentation|User Documentation]].<br />
<br />
<br />
<br />
<br />
<br />
----<br />
[[Category:Domain Control]]<br />
[[Category:Active Directory]]</div>Hortimechhttps://wiki.samba.org/index.php?title=Joining_a_Samba_DC_to_an_Existing_Active_Directory&diff=19026Joining a Samba DC to an Existing Active Directory2023-08-02T08:24:19Z<p>Hortimech: /* Move Samba start instructions</p>
<hr />
<div>= Introduction =<br />
<br />
Running one domain controller (DC) is sufficient for a working Active Directory (AD) forest. However, for redundancy and load balancing reasons, you should add further DCs to your AD forest. Joining an additional Samba DC to an existing AD differs from provisioning the first DC in a forest. If you set up a new AD forest, see [[Setting_up_Samba_as_an_Active_Directory_Domain_Controller|Setting up Samba as an Active Directory Domain Controller]].<br />
<br />
{{Imbox<br />
| type = warning<br />
| text = Do not provision a Computer as a Samba AD DC, then try to join it to an existing AD domain. This will not work, you only need to run the <code>samba-tool domain join</code> command to join a Computer to the existing AD domain. <br />
}}<br />
<br />
{{Imbox<br />
| type = warning<br />
| text = If you are joining a Samba as a DC to an existing Windows AD domain that was provisioned as a Windows 2003 (or earlier) DC, you must ensure that it is running a domain integrated DNS server. This dns server must be configured with 2008 behaviour. <br />
}}<br />
<br />
{{Imbox<br />
| type = note<br />
| text = An NT4 domain uses only one Primary Domain Controller (PDC) and optionally additional Backup Domain Controllers (BDC). In an AD forest, there is no difference between DCs, except for the [[Flexible_Single-Master_Operations_(FSMO)_Roles|FSMO roles]]. Use only the term "domain controller" or "DC" when you talk about AD to avoid any possibility of confusion.<br />
}}<br />
<br />
<br />
<br />
<br />
<br />
= Preparing the Installation =<br />
<br />
For details, see [[Setting_up_Samba_as_an_Active_Directory_Domain_Controller#Preparing_the_Installation|Preparing the Installation]] in the [[Setting_up_Samba_as_an_Active_Directory_Domain_Controller|Setting up Samba as an Active Directory Domain Controller]] documentation.<br />
<br />
<br />
<br />
<br />
<br />
= Installing Samba =<br />
<br />
For details, see [[Installing_Samba|Installing Samba]].<br />
<br />
{{Imbox<br />
| type = note<br />
| text = Install a maintained Samba version. For details, see [[Samba_Release_Planning|Samba Release Planning]].<br />
}}<br />
<br />
<br />
<br />
<br />
<br />
= Preparing the Host for Joining the Domain =<br />
<br />
== Local DNS server ==<br />
<br />
By default, the first Domain Controller (DC) in a forest runs a DNS server for Active Directory (AD)-based zones. For redundancy reasons it is recommended to run multiple DCs acting as a DNS server in a network. If you consider providing a DNS service on the new DC:<br />
<br />
* For the <code>BIND9_DLZ</code> back end, see [[BIND9_DLZ_DNS_Back_End|BIND9_DLZ DNS Back End]]. Finish this task before you start the Samba DC service.<br />
* For the internal DNS no further actions are required.<br />
<br />
<br />
<br />
== Configuring DNS ==<br />
<br />
For details, see [[Linux_and_Unix_DNS_Configuration|Linux and Unix DNS Configuration]].<br />
<br />
{{Imbox<br />
| type = note<br />
| text = The 'nameserver' you set in '/etc/resolv.conf' should be an AD DC, otherwise the join could have difficulty finding a KDC.<br />
}}<br />
<br />
{{Imbox<br />
| type = note<br />
| text = If you are joining a new DC the 'nameserver' you set in '/etc/resolv.conf' must be another AD DC, otherwise the join will not be work. Once the new join has succeeded, you need to change the 'nameserver' to the new DCs ipaddress, do not use '127.0.0.1' or any other IP.<br />
}}<br />
<br />
<br />
<br />
<br />
<br />
== Kerberos ==<br />
<br />
Set the following settings in your Kerberos client configuration file <code>/etc/krb5.conf</code>:<br />
<br />
[libdefaults]<br />
dns_lookup_realm = false<br />
dns_lookup_kdc = true<br />
default_realm = SAMDOM.EXAMPLE.COM<br />
<br />
To verify the settings use the <code>kinit</code> command to request a Kerberos ticket for the domain administrator:<br />
<br />
# kinit administrator<br />
Password for administrator@SAMDOM.EXAMPLE.COM:<br />
<br />
To list Kerberos tickets:<br />
<br />
# klist<br />
Ticket cache: FILE:/tmp/krb5cc_0<br />
Default principal: administrator@SAMDOM.EXAMPLE.COM<br />
<br />
Valid starting Expires Service principal<br />
24.09.2015 19:56:55 25.09.2015 05:56:55 krbtgt/SAMDOM.EXAMPLE.COM@SAMDOM.EXAMPLE.COM<br />
renew until 25.09.2015 19:56:53<br />
<br />
<br />
<br />
<br />
<br />
= Configuring Time Synchronisation =<br />
<br />
Kerberos requires a synchronised time on all domain members. For further details and how to set up the <code>ntpd</code> service, see [[Time_Synchronisation|Time Synchronisation]].<br />
<br />
<br />
<br />
<br />
<br />
= Joining the Active Directory as a Domain Controller =<br />
<br />
To join the domain <code>samdom.example.com</code> as a domain controller (DC) that additionally acts as a DNS server using the Samba internal DNS:<br />
<br />
There are three authentication methods you can use, Username & Password or two kerberos methods (the kerberos methods depend on running <code>kinit</code> as an admin user).<br />
<br />
Username & Password:<br />
# samba-tool domain join samdom.example.com DC -U"SAMDOM\administrator"<br />
<br />
Or:<br />
# samba-tool domain join samdom.example.com DC -k yes<br />
<br />
Or:<br />
# samba-tool domain join samdom.example.com DC --use-krb5-ccache=/tmp/krb5cc_0<br />
<br />
Using any of the above, should result in output similar to this:<br />
<br />
Finding a writeable DC for domain 'samdom.example.com'<br />
Found DC dc1.samdom.example.com<br />
Password for [SAMDOM\administrator]:<br />
workgroup is SAMDOM<br />
realm is samdom.example.com<br />
Adding CN=DC2,OU=Domain Controllers,DC=samdom,DC=example,DC=com<br />
Adding CN=DC2,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=samdom,DC=example,DC=com<br />
Adding CN=NTDS Settings,CN=DC2,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=samdom,DC=example,DC=com<br />
Adding SPNs to CN=DC2,OU=Domain Controllers,DC=samdom,DC=example,DC=com<br />
Setting account password for DC2$<br />
Enabling account<br />
Calling bare provision<br />
Looking up IPv4 addresses<br />
Looking up IPv6 addresses<br />
No IPv6 address will be assigned<br />
Setting up share.ldb<br />
Setting up secrets.ldb<br />
Setting up the registry<br />
Setting up the privileges database<br />
Setting up idmap db<br />
Setting up SAM db<br />
Setting up sam.ldb partitions and settings<br />
Setting up sam.ldb rootDSE<br />
Pre-loading the Samba 4 and AD schema<br />
A Kerberos configuration suitable for Samba 4 has been generated at /usr/local/samba/private/krb5.conf<br />
Provision OK for domain DN DC=samdom,DC=example,DC=com<br />
Starting replication<br />
Schema-DN[CN=Schema,CN=Configuration,DC=samdom,DC=example,DC=com] objects[402/1550] linked_values[0/0]<br />
Schema-DN[CN=Schema,CN=Configuration,DC=samdom,DC=example,DC=com] objects[804/1550] linked_values[0/0]<br />
Schema-DN[CN=Schema,CN=Configuration,DC=samdom,DC=example,DC=com] objects[1206/1550] linked_values[0/0]<br />
Schema-DN[CN=Schema,CN=Configuration,DC=samdom,DC=example,DC=com] objects[1550/1550] linked_values[0/0]<br />
Analyze and apply schema objects<br />
Partition[CN=Configuration,DC=samdom,DC=example,DC=com] objects[402/1618] linked_values[0/0]<br />
Partition[CN=Configuration,DC=samdom,DC=example,DC=com] objects[804/1618] linked_values[0/0]<br />
Partition[CN=Configuration,DC=samdom,DC=example,DC=com] objects[1206/1618] linked_values[0/0]<br />
Partition[CN=Configuration,DC=samdom,DC=example,DC=com] objects[1608/1618] linked_values[0/0]<br />
Partition[CN=Configuration,DC=samdom,DC=example,DC=com] objects[1618/1618] linked_values[42/0]<br />
Replicating critical objects from the base DN of the domain<br />
Partition[DC=samdom,DC=example,DC=com] objects[100/100] linked_values[23/0]<br />
Partition[DC=samdom,DC=example,DC=com] objects[386/286] linked_values[23/0]<br />
Done with always replicated NC (base, config, schema)<br />
Replicating DC=DomainDnsZones,DC=samdom,DC=example,DC=com<br />
Partition[DC=DomainDnsZones,DC=samdom,DC=example,DC=com] objects[44/44] linked_values[0/0]<br />
Replicating DC=ForestDnsZones,DC=samdom,DC=example,DC=com<br />
Partition[DC=ForestDnsZones,DC=samdom,DC=example,DC=com] objects[19/19] linked_values[0/0]<br />
Committing SAM database<br />
Sending DsReplicaUpdateRefs for all the replicated partitions<br />
Setting isSynchronized and dsServiceName<br />
Setting up secrets database<br />
Joined domain SAMDOM (SID S-1-5-21-469703510-2364959079-1506205053) as a DC<br />
<br />
See the <code>samba-tool domain join --help</code> command's output for further information.<br />
<br />
Other parameters frequently used with the <code>samba-tool domain join</code> command:<br />
<br />
* <code>--dns-backend=NAMESERVER-BACKEND</code>: Use the supplied DNS server backend. Valid options are <code>SAMBA_INTERNAL</code> or <code>BIND9_DLZ</code>, unless you want to use Bind9, there is no need to supply this option.<br />
:: If you use the internal DNS server, you will not be asked for a forwarder and the one in /etc/resolv.conf will not be obtained automatically. You must supply one with <code>--option="dns forwarder=forwarder_ipaddress"</code>.<br />
<br />
* <code>--site=SITE</code>: Directly join the host as DC to a specific [[Active_Directory_Sites|Active Directory Site]].<br />
<br />
* <code>--option="interfaces=lo eth0" --option="bind interfaces only=yes"</code>: If your server has multiple network interfaces, use these options to bind Samba to the specified interfaces. This enables the <code>samba-tool</code> command to register the correct LAN IP address in the directory during the join.<br />
<br />
{{Imbox<br />
| type = note<br />
| text = If the other DCs are Samba DCs and were provisioned with <code>--use-rfc2307</code>, you Should add <code>--option='idmap_ldb:use rfc2307 = yes'</code> to the join command<br />
}}<br />
<br />
<br />
<br />
<br />
<br />
= Starting the Samba Service =<br />
<br />
To start the <code>samba</code> Samba Active Directory (AD) domain controller (DC) service manually, enter:<br />
<br />
# samba<br />
<br />
Samba does not provide System V init scripts, <code>systemd</code>, <code>upstart</code>, or other services configuration files.<br />
* If you installed Samba using packages, use the script or service configuration file included in the package to start Samba.<br />
* If you built Samba, see [[Managing_the_Samba_AD_DC_Service|Managing the Samba AD DC Service]].<br />
<br />
<br />
<br />
<br />
<br />
= Verifying the DNS Entries =<br />
<br />
{{Imbox<br />
| type = note<br />
| text = Once the join has succeeded You should change the first nameserver in /etc/resolv.conf to the new DC's ipaddress. This will aid in the creation of the required dns records not created by the join.<br />
}}<br />
<br />
If you join a Samba DC that runs Samba 4.7.0 and later, <code>samba-tool</code> will create the required initial DNS entries automatically. To manually create these records on an earlier version, see [[Verifying_and_Creating_a_DC_DNS_Record|Verifying and Creating a DC DNS Record]]. Once Samba starts, the <code>samba_dnsupdate</code> script should create all the other required DNS entries.<br />
<br />
<br />
<br />
<br />
<br />
= Configuring the BIND9_DLZ DNS Back End =<br />
<br />
If you selected the <code>BIND9_DLZ</code> DNS back end during the domain join, set up the BIND configuration. For details, see [[BIND9_DLZ_DNS_Back_End|BIND9_DLZ DNS Back End]].<br />
<br />
<br />
<br />
<br />
<br />
= Built-in User & Group ID Mappings =<br />
{{:SysVol replication (DFS-R)}}<br />
<br />
<br />
To use a Sysvol Replication workaround, all domain controllers (DC) must use the same ID mappings for built-in users and groups.<br />
<br />
By default, a Samba DC stores the user & group IDs in 'xidNumber' attributes in 'idmap.ldb'. Because of the way 'idmap.ldb' works, you cannot guarantee that each DC will use the same ID for a given user or group. To ensure that you do use the same IDs, you must: <br />
<br />
* Create a hot-backup of the <code>/usr/local/samba/private/idmap.ldb</code> file on the existing DC:<br />
<br />
# tdbbackup -s .bak /usr/local/samba/private/idmap.ldb<br />
<br />
: This creates a backup file <code>/usr/local/samba/private/idmap.ldb.bak</code>.<br />
<br />
* Move the backup file to the <code>/usr/local/samba/private/</code> folder on the new joined DC and remove the <code>.bak</code> suffix to replace the existing file.<br />
<br />
* Run <code>net cache flush</code> on the new DC.<br />
<br />
* You will now need to sync Sysvol to the new DC.<br />
<br />
* Reset the Sysvol folder's file system access control lists (ACL) on the new DC:<br />
<br />
# samba-tool ntacl sysvolreset<br />
<br />
<br />
<br />
<br />
<br />
= Verifying Directory Replication =<br />
<br />
After the domain controller (DC) has been started, the knowledge consistency checker (KCC) on the Samba DC creates replication agreements to other DCs in the Active Directory (AD) forest. It can take up to 15 minutes until the KCC creates the auto-generated replication connections.<br />
<br />
For details about how to verify that the directory replication works correctly, see [[Verifying the Directory Replication Statuses]].<br />
<br />
{{Imbox<br />
| type = note<br />
| text = To optimize replication latency and cost, the KCC in Samba 4.5 and later no longer creates a fully-meshed replication topology between all DCs. For further details, see [[The Samba KCC]].<br />
}}<br />
<br />
<br />
<br />
<br />
<br />
= Starting BIND =<br />
<br />
Before you start the BIND daemon, verify that the DNS directory partitions have been successfully replicated:<br />
<br />
# samba-tool drs showrepl<br />
...<br />
==== INBOUND NEIGHBORS ====<br />
...<br />
DC=DomainDnsZones,DC=samdom,DC=example,DC=com<br />
Default-First-Site-Name\DC1 via RPC<br />
DSA object GUID: 4a6bd92a-6612-4b15-aa8c-9ec371e8994f<br />
Last attempt @ Thu Sep 24 20:08:45 2015 CEST was successful<br />
0 consecutive failure(s).<br />
Last success @ Thu Sep 24 20:08:45 2015 CEST<br />
...<br />
DC=ForestDnsZones,DC=samdom,DC=example,DC=com<br />
Default-First-Site-Name\DC1 via RPC<br />
DSA object GUID: 4a6bd92a-6612-4b15-aa8c-9ec371e8994f<br />
Last attempt @ Thu Sep 24 20:08:45 2015 CEST was successful<br />
0 consecutive failure(s).<br />
Last success @ Thu Sep 24 20:08:45 2015 CEST<br />
<br />
If the replication works correctly, start the BIND service. See your distribution's documentation for information how to start a service.<br />
<br />
<br />
<br />
<br />
<br />
= Testing your Samba AD DC =<br />
<br />
== Verifying the File Server ==<br />
<br />
For details, see [[Setting_up_Samba_as_an_Active_Directory_Domain_Controller#Verifying_the_File_Server|Verifying the File Server]] in the [[Setting_up_Samba_as_an_Active_Directory_Domain_Controller|Setting up Samba as an Active Directory Domain Controller]] documentation.<br />
<br />
<br />
<br />
== Testing the Local DNS Server ==<br />
<br />
Skip this step if you selected <code>--dns-backend=NONE</code> during the join.<br />
<br />
Query the local DNS server to resolve the domain name <code>samdom.example.com</code>:<br />
<br />
# host -t A samdom.example.com localhost<br />
Using domain server:<br />
Name: localhost<br />
Address: 127.0.0.1#53<br />
Aliases:<br />
<br />
samdom.example.com has address 10.99.0.1<br />
samdom.example.com has address 10.99.0.2<br />
<br />
The local DNS resolves the domain name to the IP addresses of all domain controllers (DC).<br />
<br />
In case you receive no or a different result, review this documentation and check:<br />
* the system log files,<br />
* the Samba log files,<br />
* the BIND log files, if the <code>BIND9_DLZ</code> is used.<br />
<br />
<br />
<br />
== Verifying Kerberos ==<br />
<br />
For details, see [[Setting_up_Samba_as_an_Active_Directory_Domain_Controller#Verifying_Kerberos|Verifying Kerberos]] in the [[Setting_up_Samba_as_an_Active_Directory_Domain_Controller|Setting up Samba as an Active Directory Domain Controller]] documentation.<br />
<br />
<br />
<br />
<br />
<br />
= DNS Configuration on Domain Controllers =<br />
<br />
The DNS configuration on domain controllers (DC) is important, because if it is unable to locate other DCs the replication will fail.<br />
<br />
Set the local IP of the DC as the primary name server. For example:<br />
<br />
On the new joined DC, use the local <code>10.99.0.2</code> IP as primary <code>nameserver</code> entry:<br />
<br />
nameserver 10.99.0.2<br />
search samdom.example.com<br />
<br />
<br />
<br />
<br />
<br />
= Configuring Winbindd on a Samba AD DC =<br />
<br />
''Optional''. For details, see [[Configuring_Winbindd_on_a_Samba_AD_DC|Configuring Winbindd on a Samba AD DC]].<br />
<br />
<br />
<br />
<br />
<br />
= Using the Domain Controller as a File Server =<br />
<br />
For details, see [[Setting_up_Samba_as_an_Active_Directory_Domain_Controller#Using_the_Domain_Controller_as_a_File_Server|Using the Domain Controller as a File Server]].<br />
<br />
<br />
<br />
<br />
<br />
= Sysvol Replication =<br />
<br />
Samba currently does not automatically replicate Sysvol, you must use some other form of replication. For community supported workarounds, see [[SysVol_replication_(DFS-R)|Sysvol Replication]].<br />
<br />
{{Imbox<br />
| type = note<br />
| text = If there are more than the default GPOs in Sysvol on the other DC(s), you must sync Sysvol to the new DC, <code>samba-tool ntacl sysvolreset</code> will throw an error if you do not.<br />
}}<br />
<br />
<br />
<br />
<br />
<br />
= Testing the Directory Replication =<br />
<br />
To test that the directory replication works correctly, add for example a user on an existing DC and verify that it shows up automatically on the newly joined DC.<br />
<br />
Optionally use the <code>ldapcmp</code> utility to compare two directories. For details, see [[Samba-tool_ldapcmp|samba-tool ldapcmp]].<br />
<br />
<br />
<br />
<br />
<br />
= Troubleshooting =<br />
<br />
For further details, see [[Samba_AD_DC_Troubleshooting|Samba AD DC Troubleshooting]].<br />
<br />
<br />
<br />
<br />
<br />
----<br />
[[Category:Active Directory]]<br />
[[Category:Domain Control]]</div>Hortimechhttps://wiki.samba.org/index.php?title=Joining_a_Samba_DC_to_an_Existing_Active_Directory&diff=19011Joining a Samba DC to an Existing Active Directory2023-07-23T19:53:40Z<p>Hortimech: </p>
<hr />
<div>= Introduction =<br />
<br />
Running one domain controller (DC) is sufficient for a working Active Directory (AD) forest. However, for redundancy and load balancing reasons, you should add further DCs to your AD forest. Joining an additional Samba DC to an existing AD differs from provisioning the first DC in a forest. If you set up a new AD forest, see [[Setting_up_Samba_as_an_Active_Directory_Domain_Controller|Setting up Samba as an Active Directory Domain Controller]].<br />
<br />
{{Imbox<br />
| type = warning<br />
| text = Do not provision a Computer as a Samba AD DC, then try to join it to an existing AD domain. This will not work, you only need to run the <code>samba-tool domain join</code> command to join a Computer to the existing AD domain. <br />
}}<br />
<br />
{{Imbox<br />
| type = warning<br />
| text = If you are joining a Samba as a DC to an existing Windows AD domain that was provisioned as a Windows 2003 (or earlier) DC, you must ensure that it is running a domain integrated DNS server. This dns server must be configured with 2008 behaviour. <br />
}}<br />
<br />
{{Imbox<br />
| type = note<br />
| text = An NT4 domain uses only one Primary Domain Controller (PDC) and optionally additional Backup Domain Controllers (BDC). In an AD forest, there is no difference between DCs, except for the [[Flexible_Single-Master_Operations_(FSMO)_Roles|FSMO roles]]. Use only the term "domain controller" or "DC" when you talk about AD to avoid any possibility of confusion.<br />
}}<br />
<br />
<br />
<br />
<br />
<br />
= Preparing the Installation =<br />
<br />
For details, see [[Setting_up_Samba_as_an_Active_Directory_Domain_Controller#Preparing_the_Installation|Preparing the Installation]] in the [[Setting_up_Samba_as_an_Active_Directory_Domain_Controller|Setting up Samba as an Active Directory Domain Controller]] documentation.<br />
<br />
<br />
<br />
<br />
<br />
= Installing Samba =<br />
<br />
For details, see [[Installing_Samba|Installing Samba]].<br />
<br />
{{Imbox<br />
| type = note<br />
| text = Install a maintained Samba version. For details, see [[Samba_Release_Planning|Samba Release Planning]].<br />
}}<br />
<br />
<br />
<br />
<br />
<br />
= Preparing the Host for Joining the Domain =<br />
<br />
== Local DNS server ==<br />
<br />
By default, the first Domain Controller (DC) in a forest runs a DNS server for Active Directory (AD)-based zones. For redundancy reasons it is recommended to run multiple DCs acting as a DNS server in a network. If you consider providing a DNS service on the new DC:<br />
<br />
* For the <code>BIND9_DLZ</code> back end, see [[BIND9_DLZ_DNS_Back_End|BIND9_DLZ DNS Back End]]. Finish this task before you start the Samba DC service.<br />
* For the internal DNS no further actions are required.<br />
<br />
<br />
<br />
== Configuring DNS ==<br />
<br />
For details, see [[Linux_and_Unix_DNS_Configuration|Linux and Unix DNS Configuration]].<br />
<br />
{{Imbox<br />
| type = note<br />
| text = The 'nameserver' you set in '/etc/resolv.conf' should be an AD DC, otherwise the join could have difficulty finding a KDC.<br />
}}<br />
<br />
{{Imbox<br />
| type = note<br />
| text = If you are joining a new DC the 'nameserver' you set in '/etc/resolv.conf' must be another AD DC, otherwise the join will not be work. Once the new join has succeeded, you need to change the 'nameserver' to the new DCs ipaddress, do not use '127.0.0.1' or any other IP.<br />
}}<br />
<br />
<br />
<br />
<br />
<br />
== Kerberos ==<br />
<br />
Set the following settings in your Kerberos client configuration file <code>/etc/krb5.conf</code>:<br />
<br />
[libdefaults]<br />
dns_lookup_realm = false<br />
dns_lookup_kdc = true<br />
default_realm = SAMDOM.EXAMPLE.COM<br />
<br />
To verify the settings use the <code>kinit</code> command to request a Kerberos ticket for the domain administrator:<br />
<br />
# kinit administrator<br />
Password for administrator@SAMDOM.EXAMPLE.COM:<br />
<br />
To list Kerberos tickets:<br />
<br />
# klist<br />
Ticket cache: FILE:/tmp/krb5cc_0<br />
Default principal: administrator@SAMDOM.EXAMPLE.COM<br />
<br />
Valid starting Expires Service principal<br />
24.09.2015 19:56:55 25.09.2015 05:56:55 krbtgt/SAMDOM.EXAMPLE.COM@SAMDOM.EXAMPLE.COM<br />
renew until 25.09.2015 19:56:53<br />
<br />
<br />
<br />
<br />
<br />
= Configuring Time Synchronisation =<br />
<br />
Kerberos requires a synchronised time on all domain members. For further details and how to set up the <code>ntpd</code> service, see [[Time_Synchronisation|Time Synchronisation]].<br />
<br />
<br />
<br />
<br />
<br />
= Joining the Active Directory as a Domain Controller =<br />
<br />
To join the domain <code>samdom.example.com</code> as a domain controller (DC) that additionally acts as a DNS server using the Samba internal DNS:<br />
<br />
There are three authentication methods you can use, Username & Password or two kerberos methods (the kerberos methods depend on running <code>kinit</code> as an admin user).<br />
<br />
Username & Password:<br />
# samba-tool domain join samdom.example.com DC -U"SAMDOM\administrator"<br />
<br />
Or:<br />
# samba-tool domain join samdom.example.com DC -k yes<br />
<br />
Or:<br />
# samba-tool domain join samdom.example.com DC --use-krb5-ccache=/tmp/krb5cc_0<br />
<br />
Using any of the above, should result in output similar to this:<br />
<br />
Finding a writeable DC for domain 'samdom.example.com'<br />
Found DC dc1.samdom.example.com<br />
Password for [SAMDOM\administrator]:<br />
workgroup is SAMDOM<br />
realm is samdom.example.com<br />
Adding CN=DC2,OU=Domain Controllers,DC=samdom,DC=example,DC=com<br />
Adding CN=DC2,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=samdom,DC=example,DC=com<br />
Adding CN=NTDS Settings,CN=DC2,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=samdom,DC=example,DC=com<br />
Adding SPNs to CN=DC2,OU=Domain Controllers,DC=samdom,DC=example,DC=com<br />
Setting account password for DC2$<br />
Enabling account<br />
Calling bare provision<br />
Looking up IPv4 addresses<br />
Looking up IPv6 addresses<br />
No IPv6 address will be assigned<br />
Setting up share.ldb<br />
Setting up secrets.ldb<br />
Setting up the registry<br />
Setting up the privileges database<br />
Setting up idmap db<br />
Setting up SAM db<br />
Setting up sam.ldb partitions and settings<br />
Setting up sam.ldb rootDSE<br />
Pre-loading the Samba 4 and AD schema<br />
A Kerberos configuration suitable for Samba 4 has been generated at /usr/local/samba/private/krb5.conf<br />
Provision OK for domain DN DC=samdom,DC=example,DC=com<br />
Starting replication<br />
Schema-DN[CN=Schema,CN=Configuration,DC=samdom,DC=example,DC=com] objects[402/1550] linked_values[0/0]<br />
Schema-DN[CN=Schema,CN=Configuration,DC=samdom,DC=example,DC=com] objects[804/1550] linked_values[0/0]<br />
Schema-DN[CN=Schema,CN=Configuration,DC=samdom,DC=example,DC=com] objects[1206/1550] linked_values[0/0]<br />
Schema-DN[CN=Schema,CN=Configuration,DC=samdom,DC=example,DC=com] objects[1550/1550] linked_values[0/0]<br />
Analyze and apply schema objects<br />
Partition[CN=Configuration,DC=samdom,DC=example,DC=com] objects[402/1618] linked_values[0/0]<br />
Partition[CN=Configuration,DC=samdom,DC=example,DC=com] objects[804/1618] linked_values[0/0]<br />
Partition[CN=Configuration,DC=samdom,DC=example,DC=com] objects[1206/1618] linked_values[0/0]<br />
Partition[CN=Configuration,DC=samdom,DC=example,DC=com] objects[1608/1618] linked_values[0/0]<br />
Partition[CN=Configuration,DC=samdom,DC=example,DC=com] objects[1618/1618] linked_values[42/0]<br />
Replicating critical objects from the base DN of the domain<br />
Partition[DC=samdom,DC=example,DC=com] objects[100/100] linked_values[23/0]<br />
Partition[DC=samdom,DC=example,DC=com] objects[386/286] linked_values[23/0]<br />
Done with always replicated NC (base, config, schema)<br />
Replicating DC=DomainDnsZones,DC=samdom,DC=example,DC=com<br />
Partition[DC=DomainDnsZones,DC=samdom,DC=example,DC=com] objects[44/44] linked_values[0/0]<br />
Replicating DC=ForestDnsZones,DC=samdom,DC=example,DC=com<br />
Partition[DC=ForestDnsZones,DC=samdom,DC=example,DC=com] objects[19/19] linked_values[0/0]<br />
Committing SAM database<br />
Sending DsReplicaUpdateRefs for all the replicated partitions<br />
Setting isSynchronized and dsServiceName<br />
Setting up secrets database<br />
Joined domain SAMDOM (SID S-1-5-21-469703510-2364959079-1506205053) as a DC<br />
<br />
See the <code>samba-tool domain join --help</code> command's output for further information.<br />
<br />
Other parameters frequently used with the <code>samba-tool domain join</code> command:<br />
<br />
* <code>--dns-backend=NAMESERVER-BACKEND</code>: Use the supplied DNS server backend. Valid options are <code>SAMBA_INTERNAL</code> or <code>BIND9_DLZ</code>, unless you want to use Bind9, there is no need to supply this option.<br />
:: If you use the internal DNS server, you will not be asked for a forwarder and the one in /etc/resolv.conf will not be obtained automatically. You must supply one with <code>--option="dns forwarder=forwarder_ipaddress"</code>.<br />
<br />
* <code>--site=SITE</code>: Directly join the host as DC to a specific [[Active_Directory_Sites|Active Directory Site]].<br />
<br />
* <code>--option="interfaces=lo eth0" --option="bind interfaces only=yes"</code>: If your server has multiple network interfaces, use these options to bind Samba to the specified interfaces. This enables the <code>samba-tool</code> command to register the correct LAN IP address in the directory during the join.<br />
<br />
{{Imbox<br />
| type = note<br />
| text = If the other DCs are Samba DCs and were provisioned with <code>--use-rfc2307</code>, you Should add <code>--option='idmap_ldb:use rfc2307 = yes'</code> to the join command<br />
}}<br />
<br />
<br />
<br />
<br />
<br />
= Verifying the DNS Entries =<br />
<br />
{{Imbox<br />
| type = note<br />
| text = Once the join has succeeded You should change the first nameserver in /etc/resolv.conf to the new DC's ipaddress. This will aid in the creation of the required dns records not created by the join.<br />
}}<br />
<br />
If you join a Samba DC that runs Samba 4.7 and later, <code>samba-tool</code> created all required DNS entries automatically. To manually create the records on an earlier version, see [[Verifying_and_Creating_a_DC_DNS_Record|Verifying and Creating a DC DNS Record]].<br />
<br />
<br />
<br />
<br />
<br />
= Configuring the BIND9_DLZ DNS Back End =<br />
<br />
If you selected the <code>BIND9_DLZ</code> DNS back end during the domain join, set up the BIND configuration. For details, see [[BIND9_DLZ_DNS_Back_End|BIND9_DLZ DNS Back End]].<br />
<br />
<br />
<br />
<br />
<br />
= Built-in User & Group ID Mappings =<br />
{{:SysVol replication (DFS-R)}}<br />
<br />
<br />
To use a Sysvol Replication workaround, all domain controllers (DC) must use the same ID mappings for built-in users and groups.<br />
<br />
By default, a Samba DC stores the user & group IDs in 'xidNumber' attributes in 'idmap.ldb'. Because of the way 'idmap.ldb' works, you cannot guarantee that each DC will use the same ID for a given user or group. To ensure that you do use the same IDs, you must: <br />
<br />
* Create a hot-backup of the <code>/usr/local/samba/private/idmap.ldb</code> file on the existing DC:<br />
<br />
# tdbbackup -s .bak /usr/local/samba/private/idmap.ldb<br />
<br />
: This creates a backup file <code>/usr/local/samba/private/idmap.ldb.bak</code>.<br />
<br />
* Move the backup file to the <code>/usr/local/samba/private/</code> folder on the new joined DC and remove the <code>.bak</code> suffix to replace the existing file.<br />
<br />
* Run <code>net cache flush</code> on the new DC.<br />
<br />
* You will now need to sync Sysvol to the new DC.<br />
<br />
* Reset the Sysvol folder's file system access control lists (ACL) on the new DC:<br />
<br />
# samba-tool ntacl sysvolreset<br />
<br />
<br />
<br />
<br />
<br />
= Starting the Samba Service =<br />
<br />
To start the <code>samba</code> Samba Active Directory (AD) domain controller (DC) service manually, enter:<br />
<br />
# samba<br />
<br />
Samba does not provide System V init scripts, <code>systemd</code>, <code>upstart</code>, or other services configuration files.<br />
* If you installed Samba using packages, use the script or service configuration file included in the package to start Samba.<br />
* If you built Samba, see [[Managing_the_Samba_AD_DC_Service|Managing the Samba AD DC Service]].<br />
<br />
<br />
<br />
<br />
<br />
= Verifying Directory Replication =<br />
<br />
After the domain controller (DC) has been started, the knowledge consistency checker (KCC) on the Samba DC creates replication agreements to other DCs in the Active Directory (AD) forest. It can take up to 15 minutes until the KCC creates the auto-generated replication connections.<br />
<br />
For details about how to verify that the directory replication works correctly, see [[Verifying the Directory Replication Statuses]].<br />
<br />
{{Imbox<br />
| type = note<br />
| text = To optimize replication latency and cost, the KCC in Samba 4.5 and later no longer creates a fully-meshed replication topology between all DCs. For further details, see [[The Samba KCC]].<br />
}}<br />
<br />
<br />
<br />
<br />
<br />
= Starting BIND =<br />
<br />
Before you start the BIND daemon, verify that the DNS directory partitions have been successfully replicated:<br />
<br />
# samba-tool drs showrepl<br />
...<br />
==== INBOUND NEIGHBORS ====<br />
...<br />
DC=DomainDnsZones,DC=samdom,DC=example,DC=com<br />
Default-First-Site-Name\DC1 via RPC<br />
DSA object GUID: 4a6bd92a-6612-4b15-aa8c-9ec371e8994f<br />
Last attempt @ Thu Sep 24 20:08:45 2015 CEST was successful<br />
0 consecutive failure(s).<br />
Last success @ Thu Sep 24 20:08:45 2015 CEST<br />
...<br />
DC=ForestDnsZones,DC=samdom,DC=example,DC=com<br />
Default-First-Site-Name\DC1 via RPC<br />
DSA object GUID: 4a6bd92a-6612-4b15-aa8c-9ec371e8994f<br />
Last attempt @ Thu Sep 24 20:08:45 2015 CEST was successful<br />
0 consecutive failure(s).<br />
Last success @ Thu Sep 24 20:08:45 2015 CEST<br />
<br />
If the replication works correctly, start the BIND service. See your distribution's documentation for information how to start a service.<br />
<br />
<br />
<br />
<br />
<br />
= Testing your Samba AD DC =<br />
<br />
== Verifying the File Server ==<br />
<br />
For details, see [[Setting_up_Samba_as_an_Active_Directory_Domain_Controller#Verifying_the_File_Server|Verifying the File Server]] in the [[Setting_up_Samba_as_an_Active_Directory_Domain_Controller|Setting up Samba as an Active Directory Domain Controller]] documentation.<br />
<br />
<br />
<br />
== Testing the Local DNS Server ==<br />
<br />
Skip this step if you selected <code>--dns-backend=NONE</code> during the join.<br />
<br />
Query the local DNS server to resolve the domain name <code>samdom.example.com</code>:<br />
<br />
# host -t A samdom.example.com localhost<br />
Using domain server:<br />
Name: localhost<br />
Address: 127.0.0.1#53<br />
Aliases:<br />
<br />
samdom.example.com has address 10.99.0.1<br />
samdom.example.com has address 10.99.0.2<br />
<br />
The local DNS resolves the domain name to the IP addresses of all domain controllers (DC).<br />
<br />
In case you receive no or a different result, review this documentation and check:<br />
* the system log files,<br />
* the Samba log files,<br />
* the BIND log files, if the <code>BIND9_DLZ</code> is used.<br />
<br />
<br />
<br />
== Verifying Kerberos ==<br />
<br />
For details, see [[Setting_up_Samba_as_an_Active_Directory_Domain_Controller#Verifying_Kerberos|Verifying Kerberos]] in the [[Setting_up_Samba_as_an_Active_Directory_Domain_Controller|Setting up Samba as an Active Directory Domain Controller]] documentation.<br />
<br />
<br />
<br />
<br />
<br />
= DNS Configuration on Domain Controllers =<br />
<br />
The DNS configuration on domain controllers (DC) is important, because if it is unable to locate other DCs the replication will fail.<br />
<br />
Set the local IP of the DC as the primary name server. For example:<br />
<br />
On the new joined DC, use the local <code>10.99.0.2</code> IP as primary <code>nameserver</code> entry:<br />
<br />
nameserver 10.99.0.2<br />
search samdom.example.com<br />
<br />
<br />
<br />
<br />
<br />
= Configuring Winbindd on a Samba AD DC =<br />
<br />
''Optional''. For details, see [[Configuring_Winbindd_on_a_Samba_AD_DC|Configuring Winbindd on a Samba AD DC]].<br />
<br />
<br />
<br />
<br />
<br />
= Using the Domain Controller as a File Server =<br />
<br />
For details, see [[Setting_up_Samba_as_an_Active_Directory_Domain_Controller#Using_the_Domain_Controller_as_a_File_Server|Using the Domain Controller as a File Server]].<br />
<br />
<br />
<br />
<br />
<br />
= Sysvol Replication =<br />
<br />
Samba currently does not automatically replicate Sysvol, you must use some other form of replication. For community supported workarounds, see [[SysVol_replication_(DFS-R)|Sysvol Replication]].<br />
<br />
{{Imbox<br />
| type = note<br />
| text = If there are more than the default GPOs in Sysvol on the other DC(s), you must sync Sysvol to the new DC, <code>samba-tool ntacl sysvolreset</code> will throw an error if you do not.<br />
}}<br />
<br />
<br />
<br />
<br />
<br />
= Testing the Directory Replication =<br />
<br />
To test that the directory replication works correctly, add for example a user on an existing DC and verify that it shows up automatically on the newly joined DC.<br />
<br />
Optionally use the <code>ldapcmp</code> utility to compare two directories. For details, see [[Samba-tool_ldapcmp|samba-tool ldapcmp]].<br />
<br />
<br />
<br />
<br />
<br />
= Troubleshooting =<br />
<br />
For further details, see [[Samba_AD_DC_Troubleshooting|Samba AD DC Troubleshooting]].<br />
<br />
<br />
<br />
<br />
<br />
----<br />
[[Category:Active Directory]]<br />
[[Category:Domain Control]]</div>Hortimechhttps://wiki.samba.org/index.php?title=Joining_a_Windows_Server_2012_/_2012_R2_DC_to_a_Samba_AD&diff=19005Joining a Windows Server 2012 / 2012 R2 DC to a Samba AD2023-07-19T08:27:17Z<p>Hortimech: */ Remove fixed bug from warning</p>
<hr />
<div>= Warning =<br />
<br />
{{Imbox<br />
| type = warning<br />
| text = There be dragons! Joining a Windows Server as DC to a Samba AD domain is generally not recommended.<br />
}}<br />
<br />
= Introduction =<br />
<br />
Samba supports Active Directory (AD) schema version 47, 56 and 69. This enables you to join Windows Server 2012 and 2012 R2 to your Samba AD. <br />
<br />
{{Imbox<br />
| type = important<br />
| text = For samba 4.11 and later, schema 69 support is no longer experimental, but support for Windows Server 2012 and 2012 R2 DCs possibly still is. Please report bugs and incompatibilites. For details, see [[Bug Reporting]].<br />
}}<br />
<br />
= Warning =<br />
<br />
{{Imbox<br />
| type = warning<br />
| text = Joining a Windows Server 2012 or 2012 R2 DC to a Samba AD with 2012R2 functional level breaks the AD replication! Do not use this documentation until the problem is fixed!<br />For more details, see [https://bugzilla.samba.org/show_bug.cgi?id=13618 Bug #13618]. Thankfully Windows 2012 can join a down-level (2008/2008R2) domain, just not at Functional Level 2012/2012R2, provided the schema is updated, which samba can do.<br />
}}<br />
<br />
= Requirements and Known Limitations =<br />
<br />
* All Samba DCs must run 4.6 or later. For details about updating Samba, see [[Updating_Samba|Updating Samba]].<br />
<br />
* The Windows Server 2008 or 2008 R2 host used for the initial replication must provide a <code>Sysvol</code> share. For details, see [[Enabling the Sysvol Share on a Windows DC]].<br />
: If the <code>Sysvol</code> share is missing, joining a Windows Server 2012 or 2012 R2 DC fails.<br />
<br />
= Network Configuration =<br />
<br />
* Click the <code>Start</code> button, search for <code>View network connections</code>, and open the search entry.<br />
<br />
* Right-click to your network adapter and select <code>Properties</code>.<br />
<br />
* Configure the IP settings:<br />
:* Assign a static IP address, enter the subnet mask, and default gateway.<br />
:* Enter the IP of a DNS server that is able to resolve the Active Directory (AD) DNS zone.<br />
<br />
* Click <code>OK</code> to save the settings.<br />
<br />
<br />
<br />
<br />
<br />
= Date and Time Settings =<br />
<br />
Active Directory uses Kerberos for authentication. Kerberos requires that the domain member and the domain controllers (DC) are having a synchronous time. If the difference exceeds [http://technet.microsoft.com/en-us/library/cc779260%28v=ws.10%29.aspx 5 minutes] (default), the client is not able to access domain resources for security reasons.<br />
<br />
Before you join the domain, check the time configuration:<br />
<br />
* Open the <code>Control Panel</code>.<br />
<br />
* Navigate to <code>Clock, Language and Region</code>.<br />
<br />
* Click <code>Date and Time</code>.<br />
<br />
* Verify the date, time, and time zone settings. Adjust the settings, if necessary.<br />
<br />
* Click <code>OK</code> to save the changes.<br />
<br />
<br />
<br />
<br />
<br />
= FSMO Roles =<br />
<br />
When you join the first Windows Server 2012 or 2012 R2 host as a domain controller (DC) to an Active Directory (AD), the directory schema of the forest and domain is updated. You must run this process on an existing Windows 2008 or 2008 R2 domain controller (DC) that owns the following flexible single master operation (FSMO) roles:<br />
<br />
* Schema Master<br />
* Infrastructure Master<br />
* PDC Emulator<br />
<br />
For details about transfering FSMO roles, see [[Transferring_and_Seizing_FSMO_Roles#Windows_FSMO_Role_Management|Transferring and Seizing FSMO Roles]].<br />
<br />
After the forest and domain schema was updated, you can optionally transfer the FSMO roles back to a Samba DC.<br />
<br />
{{Imbox<br />
| type = important<br />
| text = Forest and domain preparation fails if a Samba DC holds one to three of the previous mentioned roles when you join the first Windows Server 2012 or 2012 R2 DC.<br />
}}<br />
<br />
<br />
<br />
<br />
<br />
= Installing the Active Directory Domain Services =<br />
<br />
* Start the <code>Server Manager</code>.<br />
<br />
* Click <code>Add roles and features</code>.<br />
<br />
* Select <code>Role-based or feature-based installation</code> and click <code>Next</code>.<br />
<br />
* Click <code>Select a server from the server pool</code> and select the local Windows Server from the list. Click <code>Next</code>.<br />
<br />
* Select <code>Active Directory Domain Services</code>, including all dependencies. Click <code>Next</code>.<br />
<br />
* You do not need to select any additional features. Click <code>Next</code>.<br />
<br />
* Start the installation.<br />
<br />
* Click <code>Close</code>.<br />
<br />
<br />
<br />
<br />
<br />
= Joining the Windows Server to the Domain =<br />
<br />
* Log in to your Windows Server 2012 or 2012 installation using the local administrator account.<br />
<br />
* Start the <code>Server Manager</code>.<br />
<br />
* Click the notifier icon on the top navigation bar and click <code>Promote this server to a domain controller</code>.<br />
<br />
:[[Image:Join_Win2012R2_Server_Manager_Post_Deployment.png]]<br />
<br />
* Select <code>Add a domain controller to an existing domain</code>, enter the Samba Active Directory (AD) domain name and credentials that are enabled to join a domain controller (DC) to the domain, like the domain administrator account. Click <code>Next</code>.<br />
<br />
* Select the options to enable on the new DC and enter the directory services restore mode (DSRM) password. It is required to boot the Windows DC in safe-mode to restore or repair the AD in case of problems. Click <code>Next</code>. <br />
<br />
:[[Image:Join_Win2012R2_DS_Wizzard_Page2.png]]<br />
<br />
* If you enabled the <code>DNS server</code> option in the previous step, you may see a note, that a delegation for this DNS server cannot be created. Click <code>Next</code>.<br />
<br />
* Samba currently does not support schema replication using the Windows management instrumentation (WMI) protocol. For this reason, select an existing Windows Domain Controller in the domain as replication source and click <code>Next</code>.<br />
<br />
:[[Image:Join_Win2012R2_DS_Wizzard_Page3.png]]<br />
<br />
* Set the folders for the AD database, log files and the Sysvol folder. Click <code>Next</code>.<br />
<br />
* Click <code>Next</code> to confirm the operations, Windows is going to perform.<br />
<br />
* Verify your settings and click <code>Next</code> to start the prerequisite check.<br />
<br />
* Windows runs some prerequisites checks. If errors are displayed, fix them before you continue. Click <code>Install</code>.<br />
<br />
* Windows promotes the server to a DC. If it is the first Windows Server 2012 or 2012 R2 DC, the forest and domain schema is automatically updated.<br />
: {{Imbox<br />
| type = warning<br />
| text = This step breaks the AD directory replication! For details, see [[#Warning|Warning]].<br />
}}<br />
<br />
* If the wizard completes successfully, the Windows server is restarted automatically.<br />
<br />
* Verify that all DC related DNS records have been created during the promotion. See [[Verifying and Creating a DC DNS Record|Verifying and Creating a DC DNS Record]].<br />
:{{Imbox<br />
| type = important<br />
| text = Do not continue without checking the DNS records. They must exist for a working directory replication!<br />
}}<br />
<br />
<br />
<br />
<br />
<br />
= Verifying Directory Replication =<br />
<br />
See [[Verifying_the_Directory_Replication_Statuses#Displaying_the_Replication_Statuses_on_a_Windows_DC|Displaying the Replication Statuses on a Windows DC]].<br />
<br />
{{Imbox<br />
| type = note<br />
| text = To optimize replication latency and cost, the knowledge consistency checker (KCC) on Windows DCs do not create a fully-meshed replication topology between all DCs. For further details, see [[The Samba KCC]].<br />
}}<br />
<br />
<br />
<br />
<br />
<br />
= The Sysvol Share =<br />
<br />
== Enabling the Sysvol Share ==<br />
<br />
If you used a Samba domain controller (DC) as replication partner, the <code>Sysvol</code> share is not enabled. For details how to verify and enable the share, see [[Enabling the Sysvol Share on a Windows DC]].<br />
<br />
<br />
<br />
== Sysvol Replication ==<br />
<br />
Samba currently does not support the DFS-R protocol required for Sysvol replication. Please manually synchronise the content between domain controllers (DC) or use a workaround such as [[Robocopy_based_SysVol_replication_workaround|Robocopy-based Sysvol Replication]].<br />
<br />
<br />
<br />
<br />
<br />
= Troubleshooting =<br />
<br />
== Error: <code>This operation is only allowed for the Primary Domain Controller of the domain</code> ==<br />
<br />
Windows displays this error if it fails to access the <code>Sysvol</code> on the Windows Server 2008 or 2008 R2 replication partner. For details, see [[Enabling the Sysvol Share on a Windows DC]].<br />
<br />
<br />
<br />
<br />
<br />
----<br />
[[Category:Active Directory]]<br />
[[Category:Domain Control]]</div>Hortimechhttps://wiki.samba.org/index.php?title=PAM_Offline_Authentication&diff=18981PAM Offline Authentication2023-06-24T08:33:28Z<p>Hortimech: </p>
<hr />
<div>== Offline Authentication using winbindd ==<br />
<br />
In order to enable offline authentication, you must configure the <code>passwd</code> line in <code>/etc/nsswitch.conf</code> to use winbind and use PAM ([[Authenticating Domain Users Using PAM]])<br />
<br />
The <code>[global]</code> section of your <code>smb.conf</code> must contain:<br />
<br />
winbind offline logon = yes<br />
winbind request timeout = 10<br />
<br />
<br />
{{Imbox<br />
<br />
| type = warning<br />
<br />
| text = If you are using a distro that locates the lock directory in <code>/run/samba</code>, there is a bug report regarding this. This directory is removed at reboot and there appears to be something in that directory that is required for winbind offline logon to work. Until [https://bugzilla.samba.org/show_bug.cgi?id=14618 Bug #14618] is fixed, the workaround is to place <code>lock directory = /var/cache/samba</code> in your <code>smb.conf</code>.<br />
<br />
}}<br />
<br />
<br />
<br />
<br />
<br />
== Enabling offline authentication in pam_winbind ==<br />
<br />
First, ensure that you can login using PAM and your windows credentials, e.g. using ssh:<br />
ssh YOURDOM\\youruser@localhost<br />
<br />
You cannot continue until login via PAM (pam_winbind) is working.<br />
<br />
<br />
Now, pam_winbind needs to set the offline flag as well, you can do so by either<br />
<br />
<br />
* adding "cached_login = yes" to /etc/security/pam_winbind.conf. That file should look like this:<br />
<br />
#<br />
# pam_winbind configuration file<br />
#<br />
# /etc/security/pam_winbind.conf<br />
#<br />
[global]<br />
# request a cached login if possible<br />
# (needs "winbind offline logon = yes" in smb.conf)<br />
cached_login = yes<br />
<br />
This will enable offline ability globally for all applications using PAM.<br />
<br />
<br />
* adding the "cached_login" option into individual pam-configuration files (usualy below /etc/pam.d/$SERVICE), this will give you a more fine grained control over services that use pam_winbind's offline mode.<br />
<br />
<br />
* Your distro may be able to set up PAM for you. For instance, if you install the libpam-winbind and libnss-winbind packages on a Debian based distro, you are highly likely to find a line similar to this in <code>/etc/pam.d/common-auth</code>:<br />
auth [success=1 default=ignore] pam_winbind.so krb5_auth krb5_ccache_type=FILE cached_login try_first_pass<br />
<br />
The latest version even sets the <code>winbind</code> lines in <code>/etc/nsswitch</code> for you. <br />
<br />
<br />
<br />
<br />
<br />
== Testing offline authentication ==<br />
<br />
Start winbindd, authenticate successfully at least once while winbind is online<br />
<br />
systemctl start winbind<br />
<br />
wbinfo -K YOURDOM\\youruser%password<br />
plaintext kerberos password authentication for [YOURDOM\youruser] succeeded (requesting cctype: FILE)<br />
credentials were put in: FILE:/tmp/krb5cc_1000<br />
<br />
Now you can switch winbindd to offline mode by hand (for testing) with the smbcontrol command.<br />
<br />
smbcontrol winbind offline<br />
<br />
Ensure that the computer is offline, unplug the network if required. You can check if the computer is offline with this command:<br />
<br />
wbinfo --ping-dc<br />
<br />
You should get a reply similar to this:<br />
<br />
checking the NETLOGON for domain[SAMDOM] dc connection to "" failed<br />
<br />
Now repeat the command<br />
<br />
wbinfo -K YOURDOM\\youruser%password<br />
<br />
You should get<br />
user_flgs: NETLOGON_CACHED_ACCOUNT<br />
in the output.<br />
<br />
Your system is now prepared to use pam_winbind while offline. Please try to login to your localhost, e.g. using ssh<br />
ssh YOURDOM\\youruser@localhost<br />
<br />
<br />
<br />
<br />
<br />
----<br />
[[Category:Active Directory]]<br />
[[Category:Domain Members]]<br />
[[Category:NT4 Domains]]</div>Hortimechhttps://wiki.samba.org/index.php?title=Setting_up_a_Share_Using_POSIX_ACLs&diff=18977Setting up a Share Using POSIX ACLs2023-06-16T16:01:27Z<p>Hortimech: </p>
<hr />
<div>= Introduction =<br />
<br />
Samba supports shares with filesystem access control lists (ACLs) on Unix domain members, they enable you to manage permissions locally on the Samba host using UNIX utilities. The Unix file system must support extended attributes, this will enable you to use NFS4 ACLs; on Linux you are limited to using the withdrawn but still used POSIX draft ACLs to set multiple users and groups in ACLs. For details, see [[#Setting_Extended_ACLs|Setting Extended ACLs]].<br />
<br />
{{Imbox<br />
| type = note<br />
| text = You are advised that a better option than POSIX draft ACLs is to use Windows ACLs, this will allow you to set up fine-granular ACLs. For details, see [[Setting_up_a_Share_Using_Windows_ACLs|Setting up a Share Using Windows ACLs]].<br />
}}<br />
<br />
<br />
Samba supports shares with POSIX draft ACLs on:<br />
* Domain members<br />
* NT4 PDC and BDCs<br />
* Standalone hosts<br />
<br />
<br />
{{Imbox<br />
| type = important<br />
| text = On a Samba Active Directory (AD) domain controller (DC), Windows ACL support is enabled globally, and therefore shares with POSIX ACLs are not supported. You must use Windows ACLs.<br />
}}<br />
<br />
= Preparing the Host =<br />
<br />
Before you are able to create a share, set up Samba. For details, see:<br />
* [[Setting_up_Samba_as_a_Domain_Member|Setting up Samba as a Domain Member]]<br />
* [[Setting_up_Samba_as_an_NT4_PDC_(Quick_Start)|Setting up Samba as an NT4 PDC (Quick Start)]]<br />
* [[Setting_up_Samba_as_an_NT4_BDC|Setting up Samba as an NT4 BDC]]<br />
* [[Setting_up_Samba_as_a_Standalone_Server|Setting up Samba as a Standalone Server]]<br />
<br />
<br />
<br />
<br />
<br />
= Making Files Executable =<br />
<br />
Using the default setting, users are only able to execute files, such as <code>*.exe</code> and <code>*.bat</code>, on a Samba share if they have the POSIX x-bit set. For example, the following file is executable for the <code>root</code> user and members of the <code>Domain Users</code> group:<br />
<br />
-rw<u>x</u>r-<u>x</u>--- 1 root "Domain Users" 133160 1. Jan 00:00 /srv/samba/Demo/example.exe<br />
<br />
In some scenarios it is necessary to enable users to execute all files on a share, regardless if the x-bit is set. To enable, set in the <code>[global]</code> or in a specific share section of your <code>smb.conf</code>:<br />
<br />
acl allow execute always = yes<br />
<br />
= Adding a Share =<br />
<br />
To share the <code>/srv/samba/Demo/</code> directory using the <code>Demo</code> share name:<br />
<br />
* Create the directory:<br />
<br />
# mkdir -p /srv/samba/Demo/<br />
<br />
* Add the <code>[Demo]</code> share definition to your <code>smb.conf</code> file:<br />
<br />
[Demo]<br />
path = /srv/samba/Demo/<br />
read only = no<br />
<br />
: These are the minimum parameters required to set up a writeable share. Optionally, you can set share permissions. For details, see [[#Setting_Share_Permissions|Setting Share Permissions]].<br />
<br />
* Reload the Samba configuration:<br />
<br />
# smbcontrol all reload-config<br />
<br />
<br />
<br />
<br />
<br />
= Setting ACLs =<br />
<br />
== Setting Standard UNIX permissions ==<br />
<br />
The classic UNIX rights support setting permissions for one owner, one group, and everyone else (other). If you need to set multiple ACLs on a directory, see [[#Setting_Extended_ACLs|Setting Extended ACLs]].<br />
<br />
For example, to set the owner of the <code>/srv/samba/Demo/</code> directory to <code>root</code>, grant read and write permissions to the owner and the <code>Domain Users</code> group, and deny access to all other users, enter:<br />
<br />
# chmod 2770 /srv/samba/Demo/<br />
# chown root:"Domain Users" /srv/samba/Demo/<br />
<br />
{{Imbox<br />
| type = note<br />
| text = Setting the SGID bit (<code><u>2</u>770</code>) automatically inherits the directory's group to all new files and directories created, instead setting it to the user's primary group.<br />
}}<br />
<br />
For further details about the permissions, see the <code>chmod(1)</code> and <code>chown(1)</code> man page.<br />
<br />
<br />
<br />
== Setting Extended ACLs ==<br />
<br />
If your file system supports extended access control lists (ACL), you can use [[NFS4_ACL_overview|NFS4 ACLs]], which allows to store the same permissions bits as Windows ACLs. On Linux however, [[NFS4_ACL_overview|NFS4 ACLs]] are not supported usually; here only deprecated POSIX draft ACLs exist. They also enable you to set permissions for multiple users and groups on a file or directory - similar to Windows ro NFS4 ACLs but less precise. We'll look a bit closer at those here, even if we recommend to run a Samba fileserver on a system that implements [[NFS4_ACL_overview|NFS4 ACLs]]. Linux' POSIX draft ACLs are limited to the following general permissions modes:<br />
* None<br />
* Read<br />
* Write<br />
* Full control<br />
<br />
For example, to set read, write, and execute permissions for the <code>Domain Admins</code> group, read and execute permissions for the <code>Domain Users</code> group, and deny access to everyone else on the <code>/srv/samba/Demo/</code> directory:<br />
<br />
* Add the <code>inherit acls = yes</code> and <code>map acl inherit = yes</code> parameters to the share's configuration. For example:<br />
[Demo]<br />
path = /srv/samba/Demo/<br />
read only = no<br />
map acl inherit = yes<br />
inherit acls = yes<br />
: The parameters influence the ACL inheritance of extended ACLs. For further details, see the parameter descriptions in the <code>smb.conf</code> man page.<br />
<br />
* Reload Samba:<br />
<br />
# smbcontrol all reload-config<br />
<br />
* Verify that the directory is stored on a file system that supports extended ACLs. For details, see [[File System Support]].<br />
<br />
* Disable auto-granting permissions for the primary group of user accounts:<br />
# setfacl -m group::--- /srv/samba/Demo/<br />
# setfacl -m default:group::--- /srv/samba/Demo/<br />
: The primary group of the directory is additionally mapped to the dynamical <code>CREATOR GROUP</code> principal. If you use POSIX draft ACLs on a Samba share, this principal is automatically added and you cannot remove it. For further details about the <code>CREATOR GROUP</code> principal, see [https://support.microsoft.com/de-at/help/243330/well-known-security-identifiers-in-windows-operating-systems Well-known security identifiers in Windows operating systems].<br />
<br />
* Set the permissions on the directory:<br />
<br />
:* Grant read, write, and execute permissions to the <code>Domain Admins</code> group:<br />
# setfacl -m group:"SAMDOM\Domain Admins":rwx /srv/samba/Demo/<br />
<br />
:* Grant read and execute permissions to the <code>Domain Users</code> group:<br />
# setfacl -m group:"SAMDOM\Domain Users":r-x /srv/samba/Demo/<br />
<br />
:* Set permissions for the <code>other</code> ACL entry to deny access to users that do not match other ACL entries:<br />
# setfacl -R -m other::--- /srv/samba/Demo/<br />
<br />
: These settings are only applied to the directory itself. In Windows, this is converted to <code>This folder only</code>.<br />
<br />
* To configure that the same permissions set in the previous step are inherited to new file system objects created in this directory, enter:<br />
<br />
# setfacl -m default:group:"SAMDOM\Domain Admins":rwx /srv/samba/Demo/<br />
# setfacl -m default:group:"SAMDOM\Domain Users":r-x /srv/samba/Demo/<br />
# setfacl -m default:other::--- /srv/samba/Demo/<br />
<br />
: With this settings, the <code>This folder only</code> mode for the principals now changed to <code>This folder, subfolders, and files</code>.<br />
<br />
The ACLs set in the previous steps are mapped to the following Windows ACLs:<br />
<br />
{| class="wikitable"<br />
!Principal<br />
!Access<br />
!Applies to<br />
!Comments<br />
|-<br />
|SAMDOM\Domain Admins<br />
|Full control<br />
|This folder, subfolders, and files<br />
|<br />
|-<br />
|SAMDOM\Domain Users<br />
|Read & execute<br />
||This folder, subfolders, and files<br />
|<br />
|-<br />
|Everyone<br />
|None<br />
|This folder, subfolders, and files<br />
|Samba maps the permissions for this principal from the UNIX <code>other</code> ACL entry.<br />
|-<br />
|''directory_owner'' (Unix User\''directory_owner'') *<br />
|Full control<br />
|This folder only<br />
|Samba maps the owner of the directory to this entry.<br />
|-<br />
|''directory_primary_group'' (Unix User\''directory_primary_group'') *<br />
|None<br />
|This folder only<br />
|Samba maps the primary group of the directory to this entry.<br />
|-<br />
|CREATOR OWNER *<br />
|Full control<br />
|Subfolders and files only<br />
|On new file system objects, the creator inherits automatically the permissions of this principal.<br />
|-<br />
|CREATOR GROUP *<br />
|None<br />
|Subfolders and files only<br />
|On new file system objects, the creator's primary group inherits automatically the permissions of this principal.<br />
|}<br />
<br />
<nowiki>*</nowiki> Configuring or removing these principals from the ACLs is only supported when using Windows ACLs. For details, see [[Setting up a Share Using Windows ACLs]].<br />
<br />
For further details, see the <code>setfacl</code> man page.<br />
<br />
= Setting Share Permissions =<br />
<br />
''Optional'': Samba enables you to set permissions on each share which are validated when a user connects.<br />
<br />
Access to the content on a share, is controlled using file system access control lists (ACL). For details, see [[#Setting_POSIX_ACLs_on_a_Samba_Share|Setting POSIX ACLs on a Samba Share]]<br />
<br />
<br />
<br />
== Configuring User and Group-based Share Access ==<br />
<br />
Share-based access control enables you to grant or deny access to a share for certain users and groups. For example, to enable all members of the <code>Domain Users</code> group to access a share while access is denied for the <code>example_user</code> account, add the following parameters to the share's configuration:<br />
<br />
valid users = +SAMDOM\"Domain Users"<br />
invalid users = SAMDOM\example_user<br />
<br />
The <code>invalid users</code> parameter has a higher priority than the <code>valid users</code> parameter. For example, if the <code>example_user</code> account is a member of the <code>Domain Users</code> group, access is denied for this account in the previous example.<br />
<br />
For further details, see the parameter descriptions in the <code>smb.conf(5)</code> man page.<br />
<br />
<br />
<br />
== Configuring Host-based Share Access ==<br />
<br />
Host-based access control enables you to grant or deny access to a share based on host names, IP addresses, or IP ranges. For example, to enable the 127.0.0.1 IP address, the 10.99.0.0/24 IP range, and the <code>GoodHost</code> host name to access a share, and additionally deny access for the <code>BadHost</code> host name, add the following parameters to the share's configuration:<br />
<br />
hosts allow = 127.0.0.1 10.99.0.0/24 GoodHost<br />
hosts deny = BadHost<br />
<br />
The <code>hosts deny</code> parameter has a higher priority than the <code>hosts allow</code> parameter. For example, if <code>BadHost</code> resolves to an IP address that is listed in the <code>hosts allow</code> parameter, access to this host is denied.<br />
<br />
For further details, see the parameter descriptions in the <code>smb.conf(5)</code> man page.<br />
<br />
<br />
<br />
<br />
<br />
----<br />
[[Category:Active Directory]]<br />
[[Category:Domain Members]]<br />
[[Category:File Serving]]<br />
[[Category:NT4 Domains]]</div>Hortimechhttps://wiki.samba.org/index.php?title=Demoting_a_Samba_AD_DC&diff=18972Demoting a Samba AD DC2023-06-11T15:27:30Z<p>Hortimech: </p>
<hr />
<div>= Introduction =<br />
<br />
Sometimes, you may find it necessary to permanently remove a domain controller (DC) from Active Directory (AD). Removing a regular domain member only requires the deletion of the machine account entry, but, to remove a DC from AD, you have to demote it.<br />
<br />
If a DC is not demoted correctly, your AD can get unstable. For example:<br />
* replication failures can occur.<br />
* the remaining DCs can slow down due to time outs and failed replication attempts.<br />
* log ins on domain members can fail or take longer.<br />
<br />
<br />
<br />
<br />
<br />
= Demoting an Online Domain Controller =<br />
<br />
If the domain controller (DC) to demote is still working correctly:<br />
<br />
* Log in locally to the DC you wish to demote.<br />
<br />
* Ensure the <code>samba</code> service is running.<br />
<br />
* Check if the DC owns any flexible single master operations (FSMO) roles. See [[Transferring_and_Seizing_FSMO_Roles#Displaying_the_Current_FSMO_Role_Owners|Displaying the Current FSMO Role Owners]].<br />
<br />
: If the DC does own any FSMO roles, transfer them to a different DC. See [[Transferring_and_Seizing_FSMO_Roles#Transferring_an_FSMO_Role|Transferring an FSMO Role]].<br />
<br />
* Optionally, display the objectGUID of the DC. For example, for the <code>DC2</code> host:<br />
<br />
# ldbsearch -H /usr/local/samba/private/sam.ldb '(invocationId=*)' --cross-ncs objectguid | grep -A1 DC2<br />
dn: CN=NTDS Settings,CN=DC2,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=samdom,DC=example,DC=com<br />
objectGUID: c14a774f-9732-4ec2-b9fa-2156c95c4e48<br />
<br />
: If you want to verify that all DNS entries were deleted after you demoted the DC, you need to know the host name, IP address, and the objectGUID of the DC.<br />
<br />
* Demote the DC:<br />
<br />
# samba-tool domain demote -Uadministrator<br />
Using DC1.samdom.example.com as partner server for the demotion<br />
Password for [SAMDOM\administrator]:<br />
Deactivating inbound replication<br />
Asking partner server DC1.samdom.example.com to synchronize from us<br />
Changing userControl and container<br />
Removing Sysvol reference: CN=DC2,CN=Enterprise,CN=Microsoft System Volumes,CN=System,CN=Configuration,DC=samdom,DC=example,DC=com<br />
Removing Sysvol reference: CN=DC2,CN=samdom.example.com,CN=Microsoft System Volumes,CN=System,CN=Configuration,DC=samdom,DC=example,DC=com<br />
Removing Sysvol reference: CN=DC2,CN=Domain System Volumes (SYSVOL share),CN=File Replication Service,CN=System,DC=samdom,DC=example,DC=com<br />
Removing Sysvol reference: CN=DC2,CN=Topology,CN=Domain System Volume,CN=DFSR-GlobalSettings,CN=System,DC=samdom,DC=example,DC=com<br />
Demote successful<br />
<br />
* Stop the <code>samba</code> service.<br />
<br />
* If the DC used the <code>BIND9_DLZ</code> DNS back end for the Active Directory (AD) zones:<br />
:* stop the Bind9 DNS service.<br />
:* verify that no members of the domain use this host to resolve the AD DNS zones.<br />
<br />
<br />
<br />
<br />
<br />
= Demoting an Offline Domain Controller =<br />
<br />
In certain situations, such as hardware failures, it is necessary to remove a non accessible domain controller (DC) from the domain. In this case, you must demote the DC using a remaining working Samba DC.<br />
<br />
{{Imbox<br />
| type = important<br />
| text = Only run this procedure if the DC to demote is no longer connected to the AD and you cannot demote it as described in [[#Demoting_an_Online_Domain_Controller|Demoting an Online Domain Controller]]. This ensures that all changes, like password changes, are replicated onto another DC. Otherwise such changes will be lost. You can get a list of changes by using [[Samba-tool ldapcmp]].<br />
}}<br />
<br />
To remotely demote an offline DC:<br />
<br />
* Log in to a working Samba DC in the Active Directory (AD) forest.<br />
<br />
* Verify that Samba 4.4 or later is installed:<br />
<br />
# samba --version<br />
<br />
{{Imbox<br />
| type = important<br />
| text = You cannot demote an offline remote DC from a DC that runs Samba 4.4 or earlier. Update to Samba 4.4.0 or later before you continue. For details, see [[Updating Samba]].<br />
}}<br />
<br />
* Check that the remote DC being demoted does not own any flexible single master operations (FSMO) role. See [[Transferring_and_Seizing_FSMO_Roles#Displaying_the_Current_FSMO_Role_Owners|Displaying the Current FSMO Role Owners]].<br />
<br />
:* If the DC being demoted owns any FSMO roles, seize them to the local DC. See [[Transferring_and_Seizing_FSMO_Roles#Transferring_and_Seizing_FSMO_Roles#Seizing_a_FSMO_Role|Seizing an FSMO Role]].<br />
<br />
* Verify that the DC being demoted is turned off.<br />
<br />
* Optionally, display the objectGUID of the DC. For example, for the <code>DC2</code> host:<br />
<br />
# ldbsearch -H /usr/local/samba/private/sam.ldb '(invocationId=*)' --cross-ncs objectguid | grep -A1 DC2<br />
dn: CN=NTDS Settings,CN=DC2,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=samdom,DC=example,DC=com<br />
objectGUID: c14a774f-9732-4ec2-b9fa-2156c95c4e48<br />
<br />
: If you want to verify that all DNS entries were deleted after you demoted the DC, you need to know the host name, IP address, and the objectGUID of the DC.<br />
<br />
* Demote the remote DC. For example, to demote <code>DC2</code>:<br />
<br />
# samba-tool domain demote --remove-other-dead-server=DC2<br />
Removing nTDSConnection: CN=04baf417-eb41-4f31-a5f1-c739f0e92b1b,CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=samdom,DC=example,DC=com<br />
Removing nTDSDSA: CN=NTDS Settings,CN=DC2,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=samdom,DC=example,DC=com (and any children)<br />
Removing RID Set: CN=RID Set,CN=DC2,OU=Domain Controllers,DC=samdom,DC=example,DC=com<br />
Removing computer account: CN=DC2,OU=Domain Controllers,DC=samdom,DC=example,DC=com (and any child objects)<br />
Removing Samba-specific DNS service account: CN=dns-DC2,CN=Users,DC=samdom,DC=example,DC=com<br />
updating samdom.example.com keeping 3 values, removing 1 values<br />
updating DC=_kerberos._tcp.Default-First-Site-Name._sites,DC=samdom.example.com,CN=MicrosoftDNS,DC=DomainDnsZones,DC=samdom,DC=example,DC=com keeping 1 values, removing 1 values<br />
updating DC=_ldap._tcp.Default-First-Site-Name._sites,DC=samdom.example.com,CN=MicrosoftDNS,DC=DomainDnsZones,DC=samdom,DC=example,DC=com keeping 1 values, removing 1 values<br />
updating DC=_gc._tcp.Default-First-Site-Name._sites,DC=samdom.example.com,CN=MicrosoftDNS,DC=DomainDnsZones,DC=samdom,DC=example,DC=com keeping 1 values, removing 1 values<br />
updating DC=_kerberos._tcp,DC=samdom.example.com,CN=MicrosoftDNS,DC=DomainDnsZones,DC=samdom,DC=example,DC=com keeping 1 values, removing 1 values<br />
updating DC=_kerberos._udp,DC=samdom.example.com,CN=MicrosoftDNS,DC=DomainDnsZones,DC=samdom,DC=example,DC=com keeping 1 values, removing 1 values<br />
updating DC=_kpasswd._tcp,DC=samdom.example.com,CN=MicrosoftDNS,DC=DomainDnsZones,DC=samdom,DC=example,DC=com keeping 1 values, removing 1 values<br />
updating DC=_kpasswd._udp,DC=samdom.example.com,CN=MicrosoftDNS,DC=DomainDnsZones,DC=samdom,DC=example,DC=com keeping 1 values, removing 1 values<br />
updating DC=_ldap._tcp,DC=samdom.example.com,CN=MicrosoftDNS,DC=DomainDnsZones,DC=samdom,DC=example,DC=com keeping 1 values, removing 1 values<br />
updating DC=_gc._tcp,DC=samdom.example.com,CN=MicrosoftDNS,DC=DomainDnsZones,DC=samdom,DC=example,DC=com keeping 1 values, removing 1 values<br />
updating DC=_ldap._tcp.4d5258b9-0cd7-4d78-bdd7-99ebe6b19751.domains,DC=_msdcs.samdom.example.com,CN=MicrosoftDNS,DC=ForestDnsZones,DC=samdom,DC=example,DC=com keeping 1 values, removing 1 values<br />
updating DC=_kerberos._tcp.Default-First-Site-Name._sites.dc,DC=_msdcs.samdom.example.com,CN=MicrosoftDNS,DC=ForestDnsZones,DC=samdom,DC=example,DC=com keeping 1 values, removing 1 values<br />
updating DC=_ldap._tcp.Default-First-Site-Name._sites.dc,DC=_msdcs.samdom.example.com,CN=MicrosoftDNS,DC=ForestDnsZones,DC=samdom,DC=example,DC=com keeping 1 values, removing 1 values<br />
updating DC=_ldap._tcp.Default-First-Site-Name._sites.gc,DC=_msdcs.samdom.example.com,CN=MicrosoftDNS,DC=ForestDnsZones,DC=samdom,DC=example,DC=com keeping 1 values, removing 1 values<br />
updating DC=c14a774f-9732-4ec2-b9fa-2156c95c4e48,DC=_msdcs.samdom.example.com,CN=MicrosoftDNS,DC=ForestDnsZones,DC=samdom,DC=example,DC=com keeping 0 values, removing 1 values<br />
updating DC=_kerberos._tcp.dc,DC=_msdcs.samdom.example.com,CN=MicrosoftDNS,DC=ForestDnsZones,DC=samdom,DC=example,DC=com keeping 1 values, removing 1 values<br />
updating DC=_ldap._tcp.dc,DC=_msdcs.samdom.example.com,CN=MicrosoftDNS,DC=ForestDnsZones,DC=samdom,DC=example,DC=com keeping 1 values, removing 1 values<br />
updating DC=_ldap._tcp.gc,DC=_msdcs.samdom.example.com,CN=MicrosoftDNS,DC=ForestDnsZones,DC=samdom,DC=example,DC=com keeping 1 values, removing 1 values<br />
Removing Sysvol reference: CN=DC2,CN=Enterprise,CN=Microsoft System Volumes,CN=System,CN=Configuration,DC=samdom,DC=example,DC=com<br />
Removing Sysvol reference: CN=DC2,CN=samdom.example.com,CN=Microsoft System Volumes,CN=System,CN=Configuration,DC=samdom,DC=example,DC=com<br />
Removing Sysvol reference: CN=DC2,CN=Domain System Volumes (SYSVOL share),CN=File Replication Service,CN=System,DC=samdom,DC=example,DC=com<br />
Removing Sysvol reference: CN=DC2,CN=Topology,CN=Domain System Volume,CN=DFSR-GlobalSettings,CN=System,DC=samdom,DC=example,DC=com<br />
<br />
:{{Imbox<br />
| type = warning<br />
| text = You must never reconnect a remotely demoted DC to the network. Your AD can get inconsistent.<br />
}}<br />
<br />
* If the demoted DC ran a DNS service for the Active Directory (AD) zones, verify that domain members and DCs no longer use this host to resolve the AD DNS zones.<br />
<br />
<br />
<br />
<br />
<br />
= Verifying the Demotion =<br />
<br />
To manually verify that the domain controller (DC) was successfully demoted:<br />
<br />
{{Imbox<br />
| type = important<br />
| text = The steps described in this section, do not replace the official demote procedures described in the previous sections. The steps in this section are only to verify and to manually remove remaining entries, if the official demote process failed.<br />
}}<br />
<br />
* Log in to a Windows domain member using an account that is member of the <code>Domain Admins</code> group, such as the AD domain Administrator account.<br />
<br />
* Install the Remote Server Administration Tools (RSAT). For details, see [[Installing RSAT]].<br />
<br />
* Open the <code>Active Directory Users and Computers</code> application.<br />
<br />
:* Navigate to the <code>Domain Controllers</code> entry and verify that the demoted DC was removed. For example:<br />
:[[Image:ADUC_Domain_Controllers.png]]<br />
:* If the entry is still listed, you can manually remove it:<br />
::* Right-click to the DC entry and select <code>Delete</code><br />
::* Click <code>Yes</code> to confirm.<br />
::* Select <code>Delete this Domain Controller anyway. It is permanently offline and can no longer be removed using the removal wizard.</code> and click <code>OK</code>.<br />
::* If the DC is a global catalog server, click <code>Yes</code> to confirm.<br />
<br />
* Open the <code>Active Directory Sites and Services</code> application and verify that the demoted DC is no longer listed in any Active Directory (AD) site entry. For example:<br />
:[[Image:ADSS_Domain_Controllers.png]]<br />
:* If the entry is still listed, you can manually remove it:<br />
::* Right-click to the DC entry and select <code>Delete</code><br />
::* Click <code>Yes</code> to confirm.<br />
<br />
* Open the <code>DNS</code> application and verify that the DC's host name, IP address, and objectGUID is no longer used in any DNS entry in any AD DNS zone. For example:<br />
:[[Image:DNS_Domain_Controllers.png]]<br />
:* If entries are still listed, you can manually remove them:<br />
::* Right-click to the entry and select <code>Delete</code><br />
::* Click <code>Yes</code> to confirm.<br />
<br />
<br />
<br />
<br />
<br />
----<br />
[[Category:Active Directory]]</div>Hortimechhttps://wiki.samba.org/index.php?title=PAM_Offline_Authentication&diff=18970PAM Offline Authentication2023-06-08T08:59:06Z<p>Hortimech: </p>
<hr />
<div>== Offline Authentication using winbindd ==<br />
<br />
In order to enable offline authentication, you must configure the <code>passwd</code> line in <code>/etc/nsswitch.conf</code> to use winbind and use PAM ([[Authenticating Domain Users Using PAM]])<br />
<br />
The <code>[global]</code> section of your <code>smb.conf</code> must contain:<br />
<br />
winbind offline logon = yes<br />
winbind request timeout = 10<br />
<br />
<br />
<br />
<br />
<br />
== Enabling offline authentication in pam_winbind ==<br />
<br />
First, ensure that you can login using PAM and your windows credentials, e.g. using ssh:<br />
ssh YOURDOM\\youruser@localhost<br />
<br />
You cannot continue until login via PAM (pam_winbind) is working.<br />
<br />
<br />
Now, pam_winbind needs to set the offline flag as well, you can do so by either<br />
<br />
<br />
* adding "cached_login = yes" to /etc/security/pam_winbind.conf. That file should look like this:<br />
<br />
#<br />
# pam_winbind configuration file<br />
#<br />
# /etc/security/pam_winbind.conf<br />
#<br />
[global]<br />
# request a cached login if possible<br />
# (needs "winbind offline logon = yes" in smb.conf)<br />
cached_login = yes<br />
<br />
This will enable offline ability globally for all applications using PAM.<br />
<br />
<br />
* adding the "cached_login" option into individual pam-configuration files (usualy below /etc/pam.d/$SERVICE), this will give you a more fine grained control over services that use pam_winbind's offline mode.<br />
<br />
<br />
* Your distro may be able to set up PAM for you. For instance, if you install the libpam-winbind and libnss-winbind packages on a Debian based distro, you are highly likely to find a line similar to this in <code>/etc/pam.d/common-auth</code>:<br />
auth [success=1 default=ignore] pam_winbind.so krb5_auth krb5_ccache_type=FILE cached_login try_first_pass<br />
<br />
The latest version even sets the <code>winbind</code> lines in <code>/etc/nsswitch</code> for you. <br />
<br />
<br />
<br />
<br />
<br />
== Testing offline authentication ==<br />
<br />
Start winbindd, authenticate successfully at least once while winbind is online<br />
<br />
systemctl start winbind<br />
<br />
wbinfo -K YOURDOM\\youruser%password<br />
plaintext kerberos password authentication for [YOURDOM\youruser] succeeded (requesting cctype: FILE)<br />
credentials were put in: FILE:/tmp/krb5cc_1000<br />
<br />
Now you can switch winbindd to offline mode by hand (for testing) with the smbcontrol command.<br />
<br />
smbcontrol winbind offline<br />
<br />
Ensure that the computer is offline, unplug the network if required. You can check if the computer is offline with this command:<br />
<br />
wbinfo --ping-dc<br />
<br />
You should get a reply similar to this:<br />
<br />
checking the NETLOGON for domain[SAMDOM] dc connection to "" failed<br />
<br />
Now repeat the command<br />
<br />
wbinfo -K YOURDOM\\youruser%password<br />
<br />
You should get<br />
user_flgs: NETLOGON_CACHED_ACCOUNT<br />
in the output.<br />
<br />
Your system is now prepared to use pam_winbind while offline. Please try to login to your localhost, e.g. using ssh<br />
ssh YOURDOM\\youruser@localhost<br />
<br />
<br />
<br />
<br />
<br />
----<br />
[[Category:Active Directory]]<br />
[[Category:Domain Members]]<br />
[[Category:NT4 Domains]]</div>Hortimechhttps://wiki.samba.org/index.php?title=PAM_Offline_Authentication&diff=18969PAM Offline Authentication2023-06-06T15:48:46Z<p>Hortimech: </p>
<hr />
<div>== Offline Authentication using winbindd ==<br />
<br />
In order to enable offline authentication, you must configure the <code>passwd</code> line in <code>/etc/nsswitch.conf</code> to use winbind and use PAM ([[Authenticating Domain Users Using PAM]])<br />
<br />
The <code>[global]</code> section of your <code>smb.conf</code> must contain:<br />
<br />
winbind offline logon = yes<br />
winbind request timeout = 10<br />
<br />
<br />
<br />
<br />
<br />
== Enabling offline authentication in pam_winbind ==<br />
<br />
First, ensure that you can login using PAM and your windows credentials, e.g. using ssh:<br />
ssh YOURDOM\\youruser@localhost<br />
<br />
You cannot continue until login via PAM (pam_winbind) is working.<br />
<br />
<br />
Now, pam_winbind needs to set the offline flag as well, you can do so by either<br />
<br />
<br />
* adding "cached_login = yes" to /etc/security/pam_winbind.conf. That file should look like this:<br />
<br />
#<br />
# pam_winbind configuration file<br />
#<br />
# /etc/security/pam_winbind.conf<br />
#<br />
[global]<br />
# request a cached login if possible<br />
# (needs "winbind offline logon = yes" in smb.conf)<br />
cached_login = yes<br />
<br />
This will enable offline ability globally for all applications using PAM.<br />
<br />
<br />
* adding the "cached_login" option into individual pam-configuration files (usualy below /etc/pam.d/$SERVICE), this will give you a more fine grained control over services that use pam_winbind's offline mode.<br />
<br />
<br />
* Your distro may be able to set up PAM for you. For instance, if you install the libpam-winbind and libnss-winbind packages on a Debian based distro, you are highly likely to find a line similar to this in <code>/etc/pam.d/common-auth</code>:<br />
auth [success=1 default=ignore] pam_winbind.so krb5_auth krb5_ccache_type=FILE cached_login try_first_pass<br />
<br />
The latest version even sets the <code>winbind</code> lines in <code>/etc/nsswitch</code> for you. <br />
<br />
<br />
<br />
<br />
<br />
== Testing offline authentication ==<br />
<br />
Start winbindd, authenticate successfully at least once while winbind is online<br />
<br />
systemctl start winbind<br />
<br />
wbinfo -K YOURDOM\\youruser%password<br />
plaintext kerberos password authentication for [YOURDOM\youruser] succeeded (requesting cctype: FILE)<br />
credentials were put in: FILE:/tmp/krb5cc_1000<br />
<br />
Now you can switch winbindd to offline mode by hand (for testing) with the smbcontrol command.<br />
<br />
smbcontrol winbind offline<br />
<br />
Ensure that the computer is offline, unplug the network if required.<br />
<br />
Now repeat the command<br />
<br />
wbinfo -K YOURDOM\\youruser%password<br />
<br />
You should get<br />
user_flgs: NETLOGON_CACHED_ACCOUNT<br />
in the output.<br />
<br />
Your system is now prepared to use pam_winbind while offline. Please try to login to your localhost, e.g. using ssh<br />
ssh YOURDOM\\youruser@localhost<br />
<br />
<br />
<br />
<br />
<br />
----<br />
[[Category:Active Directory]]<br />
[[Category:Domain Members]]<br />
[[Category:NT4 Domains]]</div>Hortimechhttps://wiki.samba.org/index.php?title=Samba_AD_Smart_Card_Login_for_macOS_clients&diff=18921Samba AD Smart Card Login for macOS clients2023-05-22T17:27:23Z<p>Hortimech: Created page with "Put your data here"</p>
<hr />
<div>Put your data here</div>Hortimechhttps://wiki.samba.org/index.php?title=User_Documentation&diff=18920User Documentation2023-05-22T17:26:57Z<p>Hortimech: </p>
<hr />
<div>* [[FAQ|Frequently Asked Questions (FAQ)]]<br />
* [[Samba Release Planning]]<br />
* [[Samba_Features_added/changed_(by_release)|Samba Release Notes]]<br />
* [[Obtaining Samba]]<br />
* [[Installing Samba]]<br />
:* [[Operating System Requirements]]<br />
::* [[Package Dependencies Required to Build Samba]]<br />
::* [[File System Support]]<br />
:* [[Build Samba from Source]]<br />
:* [[Distribution-specific Package Installation]]<br />
* [[Updating Samba]]<br />
<br />
<br />
<br />
<br />
* [[Domain Control]]<br />
:* [[Active Directory Domain Controller]]<br />
::* [[Active Directory Naming FAQ]]<br />
::* [[Setting up Samba as an Active Directory Domain Controller]]<br />
::* [[Joining a Samba DC to an Existing Active Directory]]<br />
::* [[Joining a Windows Server 2008 / 2008 R2 DC to a Samba AD]]<br />
::* [[Joining a Windows Server 2012 / 2012 R2 DC to a Samba AD]]<br />
::* [[Migrating a Samba NT4 Domain to Samba AD (Classic Upgrade)]]<br />
::* [[Demoting a Samba AD DC]]<br />
::* [[The Samba AD DNS Back Ends]]<br />
:::* [[Samba Internal DNS Back End]]<br />
:::* [[BIND9_DLZ DNS Back End]]<br />
::::* [[Setting up a BIND DNS Server]]<br />
::::* [[Configure DHCP to update DNS records]]<br />
:::* [[Testing Dynamic DNS Updates]]<br />
::* [[Managing the Samba AD DC Service]]<br />
::* [[Configuring Winbindd on a Samba AD DC]]<br />
::* [[Time Synchronisation]]<br />
::* [[Verifying the Directory Replication Statuses]]<br />
::* [[Manually Replicating Directory Partitions]]<br />
::* [[Running a Samba AD DC with MIT Kerberos KDC]]<br />
::* [[Migrating the ntvfs File Server Back End to s3fs]]<br />
::* [[Samba AD DC Port Usage]]<br />
::* [[Samba AD DC Troubleshooting]]<br />
::* [[Password Settings Objects]]<br />
::* [[Running Samba AD Domain Controllers in large domains]]<br />
::* [[Using the lmdb database backend]]<br />
<br />
<br />
<br />
:* [[NT4 Domains]]<br />
::* [[Setting up Samba as an NT4 PDC (Quick Start)]]<br />
:::* [[Samba NT4 PDC Port Usage]]<br />
::* [[Setting up Samba as an NT4 BDC]]<br />
::* [[Required Settings for Samba NT4 Domains]]<br />
<br />
<br />
* [[Domain Membership]]<br />
:* [[Joining a Windows Client or Server to a Domain]]<br />
::* [[Windows DNS Configuration]]<br />
:* [[Joining a Linux or Unix Host to a Domain]]<br />
::* [[Linux and Unix DNS Configuration]]<br />
::* [[Setting up Samba as a Domain Member]]<br />
:::* [[Identity Mapping Back Ends]]<br />
::::* [[idmap config ad]] (RFC2307)<br />
::::* [[idmap config rid]]<br />
::::* [[idmap config autorid]]<br />
::::* [[Local accounts]]<br />
:::* [[Authenticating Domain Users Using PAM]]<br />
:::* [[PAM Offline Authentication]]<br />
::* [[Samba Domain Member Port Usage]]<br />
:* [[Joining a macOS Client to a Domain]]<br />
::* [[macOS DNS Configuration]]<br />
:* [[Configuring FreeDOS to Access a Samba Share]]<br />
:* [[Troubleshooting Samba Domain Members]]<br />
<br />
<br />
* [[Setting_up_Samba_as_a_Standalone_Server|Standalone Server]]<br />
:* [[Setting up Samba as a Standalone Server]]<br />
<br />
<br />
* [[CTDB and Clustered Samba]]<br />
<br />
<br />
* [[Advanced Configuration]]<br />
:* [[Configuring Logging on a Samba Server]]<br />
::* [[Setting up Audit Logging]]<br />
:* [[DNS Administration]]<br />
::* [[Changing the DNS Back End of a Samba AD DC]]<br />
::* [[DNS administration]]<br />
::* [[DNS troubleshooting]]<br />
:::* [[Dns_tkey_negotiategss: TKEY is unacceptable]]<br />
:::* [[Deleted AD zone]]<br />
:* [[Setting up RFC2307 in AD]]<br />
:* [[Print Server Support]]<br />
::* [[Setting up Samba as a Print Server]]<br />
::* [[Setting up Automatic Printer Driver Downloads for Windows Clients]]<br />
::* [[Creating Custom Paper Sizes]]<br />
::* [[Setting up Network Printer Ports]]<br />
::* [[Virtual PDF Printer]]<br />
::* [[Virtual PDF Printer with CUPS Back End for Windows Clients without roaming user profile]]<br />
::* [[Connect printer with session logon script for non admins users]]<br />
:* [[Active Directory Sites]]<br />
:* [[Samba AD Schema]]<br />
::* [[AD Schema Version Support]]<br />
::* [[Samba AD schema extensions]]<br />
:* [[Virtual File System Modules]]<br />
:* [[Generating Keytabs]]<br />
<br />
<br />
<br />
<br />
<br />
* [[Replication]]<br />
:* [[Distributed File System (DFS)]]<br />
::* [[SysVol replication (DFS-R)]]<br />
:::* [[Rsync based SysVol replication workaround]] (Samba DCs only)<br />
:::* [[Bidirectional Rsync/Unison based SysVol replication workaround]] (Samba DCs only)<br />
:::* [[Bidirectional Rsync/osync based SysVol replication workaround]] (Samba DCs only)<br />
:::* [[Robocopy based SysVol replication workaround]] (Samba DCs -> Windows DCs)<br />
:* [[Directory Replication Service (DRS)]]<br />
<br />
<br />
<br />
<br />
<br />
* [[Common Administration Tasks]]<br />
:* [[The Windows remote server administration tools (RSAT)]]<br />
::* [[Installing RSAT]]<br />
:* [[Remote and local management of Samba]]<br />
::* [[User and group management]]<br />
:::* [[Maintaining Unix Attributes in AD using ADUC]]<br />
:::* [[Administer Unix Attributes in AD using samba-tool and ldb-tools]]<br />
:* [[Backup and restore]]<br />
::* [[Back up and Restoring a Samba AD DC]]<br />
::* [[Back up and Restoring a Samba Domain Member]]<br />
:* [[Samba File Serving]]<br />
::* [[Setting up a Share Using Windows ACLs]]<br />
::* [[Setting up a Share Using POSIX ACLs]]<br />
::* [[Special file shares]]<br />
:::* [[User Home Folders]]<br />
:::* [[Roaming Windows User Profiles]]<br />
::::* [[Configuring Windows Profile Folder Redirections]]<br />
:::* [[Setting up a Share Without Authentication]]<br />
:* [[Flexible Single-Master Operations (FSMO) Roles]]<br />
::* [[Transferring and Seizing FSMO Roles]]<br />
:* [[The AD functional levels]]<br />
::* [[Raising the Functional Levels]]<br />
:* [[Changing the IP Address of a Samba AD DC]]<br />
:* [[Configuring LDAP over SSL (LDAPS) on a Samba AD DC]]<br />
:* [[Delegating administrative permissions to non-administrators]]<br />
::* [[Delegation/Joining_Machines_to_a_Domain|Joining Machines to a Domain]]<br />
::* [[Delegation/Account_management|Account management]]<br />
:* [[Administer workstations]]<br />
::* [[Managing local groups on domain members via GPO restricted groups]]<br />
:* [[Working with Active Directory encoded LDAP values]]<br />
:* [[Performance Tuning]]<br />
:* [[Configure Samba to Bind to Specific Interfaces]]<br />
:* [[Server-Side_Copy|Improving performance with server-side copy]]<br />
:* [[Samba AD Smart Card Login]]<br />
:* [[Samba AD Smart Card Login for macOS clients]]<br />
:* [[VPN Single SignOn with Samba AD]]<br />
:* [[Authenticating other services against Samba AD]]<br />
::* [[Authenticating Apache against Active Directory]]<br />
::* [[OpenSSH Single sign-on]]<br />
::* [[Authenticating Dovecot against Active Directory]]<br />
:* [[openLDAP as proxy to AD]]<br />
:* [[Client specific logging]]<br />
:* [[Configure Samba to Work Better with Mac OS X]]<br />
:* [[Interpreting JSON Audit Logs]]<br />
<br />
<br />
<br />
* Security<br />
:* [[Samba_Security_Documentation|Samba Security Documentation]]<br />
<br />
<br />
<br />
<br />
* [[Terms and Abbreviations]]<br />
<br />
<br />
<br />
<br />
<br />
* [[Getting Help]]<br />
:* [https://lists.samba.org/mailman/listinfo/samba Samba Mailing List]<br />
:* [https://www.samba.org/samba/support/ Commercial Support]<br />
<br />
<br />
<br />
<br />
<br />
* [[Contribute]]<br />
:* [[Bug Reporting]]<br />
:* [[How To Write Samba Documentation]]</div>Hortimechhttps://wiki.samba.org/index.php?title=MacOS_DNS_Configuration&diff=18919MacOS DNS Configuration2023-05-22T17:19:41Z<p>Hortimech: Created page with "Put data here"</p>
<hr />
<div>Put data here</div>Hortimechhttps://wiki.samba.org/index.php?title=User_Documentation&diff=18918User Documentation2023-05-22T17:19:14Z<p>Hortimech: </p>
<hr />
<div>* [[FAQ|Frequently Asked Questions (FAQ)]]<br />
* [[Samba Release Planning]]<br />
* [[Samba_Features_added/changed_(by_release)|Samba Release Notes]]<br />
* [[Obtaining Samba]]<br />
* [[Installing Samba]]<br />
:* [[Operating System Requirements]]<br />
::* [[Package Dependencies Required to Build Samba]]<br />
::* [[File System Support]]<br />
:* [[Build Samba from Source]]<br />
:* [[Distribution-specific Package Installation]]<br />
* [[Updating Samba]]<br />
<br />
<br />
<br />
<br />
* [[Domain Control]]<br />
:* [[Active Directory Domain Controller]]<br />
::* [[Active Directory Naming FAQ]]<br />
::* [[Setting up Samba as an Active Directory Domain Controller]]<br />
::* [[Joining a Samba DC to an Existing Active Directory]]<br />
::* [[Joining a Windows Server 2008 / 2008 R2 DC to a Samba AD]]<br />
::* [[Joining a Windows Server 2012 / 2012 R2 DC to a Samba AD]]<br />
::* [[Migrating a Samba NT4 Domain to Samba AD (Classic Upgrade)]]<br />
::* [[Demoting a Samba AD DC]]<br />
::* [[The Samba AD DNS Back Ends]]<br />
:::* [[Samba Internal DNS Back End]]<br />
:::* [[BIND9_DLZ DNS Back End]]<br />
::::* [[Setting up a BIND DNS Server]]<br />
::::* [[Configure DHCP to update DNS records]]<br />
:::* [[Testing Dynamic DNS Updates]]<br />
::* [[Managing the Samba AD DC Service]]<br />
::* [[Configuring Winbindd on a Samba AD DC]]<br />
::* [[Time Synchronisation]]<br />
::* [[Verifying the Directory Replication Statuses]]<br />
::* [[Manually Replicating Directory Partitions]]<br />
::* [[Running a Samba AD DC with MIT Kerberos KDC]]<br />
::* [[Migrating the ntvfs File Server Back End to s3fs]]<br />
::* [[Samba AD DC Port Usage]]<br />
::* [[Samba AD DC Troubleshooting]]<br />
::* [[Password Settings Objects]]<br />
::* [[Running Samba AD Domain Controllers in large domains]]<br />
::* [[Using the lmdb database backend]]<br />
<br />
<br />
<br />
:* [[NT4 Domains]]<br />
::* [[Setting up Samba as an NT4 PDC (Quick Start)]]<br />
:::* [[Samba NT4 PDC Port Usage]]<br />
::* [[Setting up Samba as an NT4 BDC]]<br />
::* [[Required Settings for Samba NT4 Domains]]<br />
<br />
<br />
* [[Domain Membership]]<br />
:* [[Joining a Windows Client or Server to a Domain]]<br />
::* [[Windows DNS Configuration]]<br />
:* [[Joining a Linux or Unix Host to a Domain]]<br />
::* [[Linux and Unix DNS Configuration]]<br />
::* [[Setting up Samba as a Domain Member]]<br />
:::* [[Identity Mapping Back Ends]]<br />
::::* [[idmap config ad]] (RFC2307)<br />
::::* [[idmap config rid]]<br />
::::* [[idmap config autorid]]<br />
::::* [[Local accounts]]<br />
:::* [[Authenticating Domain Users Using PAM]]<br />
:::* [[PAM Offline Authentication]]<br />
::* [[Samba Domain Member Port Usage]]<br />
:* [[Joining a macOS Client to a Domain]]<br />
::* [[macOS DNS Configuration]]<br />
:* [[Configuring FreeDOS to Access a Samba Share]]<br />
:* [[Troubleshooting Samba Domain Members]]<br />
<br />
<br />
* [[Setting_up_Samba_as_a_Standalone_Server|Standalone Server]]<br />
:* [[Setting up Samba as a Standalone Server]]<br />
<br />
<br />
* [[CTDB and Clustered Samba]]<br />
<br />
<br />
* [[Advanced Configuration]]<br />
:* [[Configuring Logging on a Samba Server]]<br />
::* [[Setting up Audit Logging]]<br />
:* [[DNS Administration]]<br />
::* [[Changing the DNS Back End of a Samba AD DC]]<br />
::* [[DNS administration]]<br />
::* [[DNS troubleshooting]]<br />
:::* [[Dns_tkey_negotiategss: TKEY is unacceptable]]<br />
:::* [[Deleted AD zone]]<br />
:* [[Setting up RFC2307 in AD]]<br />
:* [[Print Server Support]]<br />
::* [[Setting up Samba as a Print Server]]<br />
::* [[Setting up Automatic Printer Driver Downloads for Windows Clients]]<br />
::* [[Creating Custom Paper Sizes]]<br />
::* [[Setting up Network Printer Ports]]<br />
::* [[Virtual PDF Printer]]<br />
::* [[Virtual PDF Printer with CUPS Back End for Windows Clients without roaming user profile]]<br />
::* [[Connect printer with session logon script for non admins users]]<br />
:* [[Active Directory Sites]]<br />
:* [[Samba AD Schema]]<br />
::* [[AD Schema Version Support]]<br />
::* [[Samba AD schema extensions]]<br />
:* [[Virtual File System Modules]]<br />
:* [[Generating Keytabs]]<br />
<br />
<br />
<br />
<br />
<br />
* [[Replication]]<br />
:* [[Distributed File System (DFS)]]<br />
::* [[SysVol replication (DFS-R)]]<br />
:::* [[Rsync based SysVol replication workaround]] (Samba DCs only)<br />
:::* [[Bidirectional Rsync/Unison based SysVol replication workaround]] (Samba DCs only)<br />
:::* [[Bidirectional Rsync/osync based SysVol replication workaround]] (Samba DCs only)<br />
:::* [[Robocopy based SysVol replication workaround]] (Samba DCs -> Windows DCs)<br />
:* [[Directory Replication Service (DRS)]]<br />
<br />
<br />
<br />
<br />
<br />
* [[Common Administration Tasks]]<br />
:* [[The Windows remote server administration tools (RSAT)]]<br />
::* [[Installing RSAT]]<br />
:* [[Remote and local management of Samba]]<br />
::* [[User and group management]]<br />
:::* [[Maintaining Unix Attributes in AD using ADUC]]<br />
:::* [[Administer Unix Attributes in AD using samba-tool and ldb-tools]]<br />
:* [[Backup and restore]]<br />
::* [[Back up and Restoring a Samba AD DC]]<br />
::* [[Back up and Restoring a Samba Domain Member]]<br />
:* [[Samba File Serving]]<br />
::* [[Setting up a Share Using Windows ACLs]]<br />
::* [[Setting up a Share Using POSIX ACLs]]<br />
::* [[Special file shares]]<br />
:::* [[User Home Folders]]<br />
:::* [[Roaming Windows User Profiles]]<br />
::::* [[Configuring Windows Profile Folder Redirections]]<br />
:::* [[Setting up a Share Without Authentication]]<br />
:* [[Flexible Single-Master Operations (FSMO) Roles]]<br />
::* [[Transferring and Seizing FSMO Roles]]<br />
:* [[The AD functional levels]]<br />
::* [[Raising the Functional Levels]]<br />
:* [[Changing the IP Address of a Samba AD DC]]<br />
:* [[Configuring LDAP over SSL (LDAPS) on a Samba AD DC]]<br />
:* [[Delegating administrative permissions to non-administrators]]<br />
::* [[Delegation/Joining_Machines_to_a_Domain|Joining Machines to a Domain]]<br />
::* [[Delegation/Account_management|Account management]]<br />
:* [[Administer workstations]]<br />
::* [[Managing local groups on domain members via GPO restricted groups]]<br />
:* [[Working with Active Directory encoded LDAP values]]<br />
:* [[Performance Tuning]]<br />
:* [[Configure Samba to Bind to Specific Interfaces]]<br />
:* [[Server-Side_Copy|Improving performance with server-side copy]]<br />
:* [[Samba AD Smart Card Login]]<br />
:* [[VPN Single SignOn with Samba AD]]<br />
:* [[Authenticating other services against Samba AD]]<br />
::* [[Authenticating Apache against Active Directory]]<br />
::* [[OpenSSH Single sign-on]]<br />
::* [[Authenticating Dovecot against Active Directory]]<br />
:* [[openLDAP as proxy to AD]]<br />
:* [[Client specific logging]]<br />
:* [[Configure Samba to Work Better with Mac OS X]]<br />
:* [[Interpreting JSON Audit Logs]]<br />
<br />
<br />
<br />
* Security<br />
:* [[Samba_Security_Documentation|Samba Security Documentation]]<br />
<br />
<br />
<br />
<br />
* [[Terms and Abbreviations]]<br />
<br />
<br />
<br />
<br />
<br />
* [[Getting Help]]<br />
:* [https://lists.samba.org/mailman/listinfo/samba Samba Mailing List]<br />
:* [https://www.samba.org/samba/support/ Commercial Support]<br />
<br />
<br />
<br />
<br />
<br />
* [[Contribute]]<br />
:* [[Bug Reporting]]<br />
:* [[How To Write Samba Documentation]]</div>Hortimechhttps://wiki.samba.org/index.php?title=Joining_a_Mac_OS_X_Client_to_a_Domain&diff=18917Joining a Mac OS X Client to a Domain2023-05-22T17:18:09Z<p>Hortimech: Hortimech moved page Joining a Mac OS X Client to a Domain to Joining a macOS Client to a Domain: New Apples naming</p>
<hr />
<div>#REDIRECT [[Joining a macOS Client to a Domain]]</div>Hortimechhttps://wiki.samba.org/index.php?title=Joining_a_macOS_Client_to_a_Domain&diff=18916Joining a macOS Client to a Domain2023-05-22T17:18:09Z<p>Hortimech: Hortimech moved page Joining a Mac OS X Client to a Domain to Joining a macOS Client to a Domain: New Apples naming</p>
<hr />
<div>Put your data here</div>Hortimechhttps://wiki.samba.org/index.php?title=Joining_a_macOS_Client_to_a_Domain&diff=18915Joining a macOS Client to a Domain2023-05-22T17:16:57Z<p>Hortimech: Created page with "Put your data here"</p>
<hr />
<div>Put your data here</div>Hortimechhttps://wiki.samba.org/index.php?title=PAM_Offline_Authentication&diff=18914PAM Offline Authentication2023-05-20T13:24:06Z<p>Hortimech: </p>
<hr />
<div>== Offline Authentication using winbindd ==<br />
<br />
In order to enable offline authentication, you must configure the <code>passwd</code> line in <code>/etc/nsswitch.conf</code> to use winbind and use PAM ([[Authenticating Domain Users Using PAM]])<br />
<br />
The <code>[global]</code> section of your <code>smb.conf</code> must contain:<br />
<br />
winbind offline logon = yes<br />
<br />
<br />
<br />
<br />
<br />
== Enabling offline authentication in pam_winbind ==<br />
<br />
First, ensure that you can login using PAM and your windows credentials, e.g. using ssh:<br />
ssh YOURDOM\\youruser@localhost<br />
<br />
You cannot continue until login via PAM (pam_winbind) is working.<br />
<br />
<br />
Now, pam_winbind needs to set the offline flag as well, you can do so by either<br />
<br />
<br />
* adding "cached_login = yes" to /etc/security/pam_winbind.conf. That file should look like this:<br />
<br />
#<br />
# pam_winbind configuration file<br />
#<br />
# /etc/security/pam_winbind.conf<br />
#<br />
[global]<br />
# request a cached login if possible<br />
# (needs "winbind offline logon = yes" in smb.conf)<br />
cached_login = yes<br />
<br />
This will enable offline ability globally for all applications using PAM.<br />
<br />
<br />
* adding the "cached_login" option into individual pam-configuration files (usualy below /etc/pam.d/$SERVICE), this will give you a more fine grained control over services that use pam_winbind's offline mode.<br />
<br />
<br />
* Your distro may be able to set up PAM for you. For instance, if you install the libpam-winbind and libnss-winbind packages on a Debian based distro, you are highly likely to find a line similar to this in <code>/etc/pam.d/common-auth</code>:<br />
auth [success=1 default=ignore] pam_winbind.so krb5_auth krb5_ccache_type=FILE cached_login try_first_pass<br />
<br />
The latest version even sets the <code>winbind</code> lines in <code>/etc/nsswitch</code> for you. <br />
<br />
<br />
<br />
<br />
<br />
== Testing offline authentication ==<br />
<br />
Start winbindd, authenticate successfully at least once while winbind is online<br />
<br />
systemctl start winbind<br />
<br />
wbinfo -K YOURDOM\\youruser%password<br />
plaintext kerberos password authentication for [YOURDOM\youruser] succeeded (requesting cctype: FILE)<br />
credentials were put in: FILE:/tmp/krb5cc_1000<br />
<br />
Now you can switch winbindd to offline mode by hand (for testing) with the smbcontrol command.<br />
<br />
smbcontrol winbind offline<br />
<br />
Ensure that the computer is offline, unplug the network if required.<br />
<br />
Now repeat the command<br />
<br />
wbinfo -K YOURDOM\\youruser%password<br />
<br />
You should get<br />
user_flgs: NETLOGON_CACHED_ACCOUNT<br />
in the output.<br />
<br />
Your system is now prepared to use pam_winbind while offline. Please try to login to your localhost, e.g. using ssh<br />
ssh YOURDOM\\youruser@localhost<br />
<br />
<br />
<br />
<br />
<br />
----<br />
[[Category:Active Directory]]<br />
[[Category:Domain Members]]<br />
[[Category:NT4 Domains]]</div>Hortimechhttps://wiki.samba.org/index.php?title=PAM_Offline_Authentication&diff=18913PAM Offline Authentication2023-05-20T13:22:21Z<p>Hortimech: </p>
<hr />
<div>== Offline Authentication using winbindd ==<br />
<br />
In order to enable offline authentication, you must configure the <code>passwd</code> line in <code>/etc/nsswitch.conf</code> to use winbind and use PAM (Authenticating Domain Users Using PAM)<br />
<br />
The <code>[global]</code> section of your <code>smb.conf</code> must contain:<br />
<br />
winbind offline logon = yes<br />
<br />
<br />
<br />
<br />
<br />
== Enabling offline authentication in pam_winbind ==<br />
<br />
First, ensure that you can login using PAM and your windows credentials, e.g. using ssh:<br />
ssh YOURDOM\\youruser@localhost<br />
<br />
You cannot continue until login via PAM (pam_winbind) is working.<br />
<br />
<br />
Now, pam_winbind needs to set the offline flag as well, you can do so by either<br />
<br />
<br />
* adding "cached_login = yes" to /etc/security/pam_winbind.conf. That file should look like this:<br />
<br />
#<br />
# pam_winbind configuration file<br />
#<br />
# /etc/security/pam_winbind.conf<br />
#<br />
[global]<br />
# request a cached login if possible<br />
# (needs "winbind offline logon = yes" in smb.conf)<br />
cached_login = yes<br />
<br />
This will enable offline ability globally for all applications using PAM.<br />
<br />
<br />
* adding the "cached_login" option into individual pam-configuration files (usualy below /etc/pam.d/$SERVICE), this will give you a more fine grained control over services that use pam_winbind's offline mode.<br />
<br />
<br />
* Your distro may be able to set up PAM for you. For instance, if you install the libpam-winbind and libnss-winbind packages on a Debian based distro, you are highly likely to find a line similar to this in <code>/etc/pam.d/common-auth</code>:<br />
auth [success=1 default=ignore] pam_winbind.so krb5_auth krb5_ccache_type=FILE cached_login try_first_pass<br />
<br />
The latest version even sets the <code>winbind</code> lines in <code>/etc/nsswitch</code> for you. <br />
<br />
<br />
<br />
<br />
<br />
== Testing offline authentication ==<br />
<br />
Start winbindd, authenticate successfully at least once while winbind is online<br />
<br />
systemctl start winbind<br />
<br />
wbinfo -K YOURDOM\\youruser%password<br />
plaintext kerberos password authentication for [YOURDOM\youruser] succeeded (requesting cctype: FILE)<br />
credentials were put in: FILE:/tmp/krb5cc_1000<br />
<br />
Now you can switch winbindd to offline mode by hand (for testing) with the smbcontrol command.<br />
<br />
smbcontrol winbind offline<br />
<br />
Ensure that the computer is offline, unplug the network if required.<br />
<br />
Now repeat the command<br />
<br />
wbinfo -K YOURDOM\\youruser%password<br />
<br />
You should get<br />
user_flgs: NETLOGON_CACHED_ACCOUNT<br />
in the output.<br />
<br />
Your system is now prepared to use pam_winbind while offline. Please try to login to your localhost, e.g. using ssh<br />
ssh YOURDOM\\youruser@localhost<br />
<br />
<br />
<br />
<br />
<br />
----<br />
[[Category:Active Directory]]<br />
[[Category:Domain Members]]<br />
[[Category:NT4 Domains]]</div>Hortimechhttps://wiki.samba.org/index.php?title=Administer_Unix_Attributes_in_AD_using_samba-tool_and_ldb-tools&diff=18883Administer Unix Attributes in AD using samba-tool and ldb-tools2023-04-27T12:06:51Z<p>Hortimech: </p>
<hr />
<div><br />
= Introduction =<br />
<br />
The following describes how to set/edit the RFC2307 attributes used by [[Idmap_config_ad|idmap_ad]]. This requires to have [[Setting_up_RFC2307_in_AD#Verifying_the_Domain_Controller_and_Active_Directory_Setup|NIS extensions]] installed in your AD. To administer the UNIX attributes via the Command line you should install ldb-tools <code>ldbsearch, ldbmodify etc</code>, if not already installed. Modifications on user and group objects will be done by the Domain Administrator, if you haven't set any [[Delegation/Account_management|delegations]].<br />
<br />
<br />
<br />
<br />
<br />
= Names and Addresses used on this page =<br />
<br />
* username : sambauser<br />
* groupname : sambagroup<br />
* Computer name : sambacomputer<br />
* domain naming context : DC=samdom,DC=example,DC=com<br />
* Netbios domain name : samdom (aka workgroup)<br />
* ID range : 10000-999999<br />
* Domain Users gidNumber : 10000<br />
* login shell : /bin/bash<br />
<br />
{{Imbox<br />
| type = note<br />
| text = Ensure that you use unique values for new users and groups.<br />
}}<br />
<br />
<br />
<br />
<br />
<br />
= Creating a Unix user with samba-tool =<br />
<br />
* Open a terminal on a DC and enter the following command:<br />
<br />
samba-tool user create sambauser passw5rd* --nis-domain=samdom --unix-home=/home/sambauser --uid-number=10005 --login-shell=/bin/bash --gid-number=10000<br />
<br />
<br />
<br />
<br />
<br />
= Adding Unix attributes to an existing user account =<br />
<br />
== Direct command-line way using samba-tool ==<br />
<br />
samba-tool user addunixattrs sambauser uid --gid-number=gid --login-shell=/bin/bash --unix-home=/home/sambauser<br />
<br />
== Interactive way with samba-tool ==<br />
<br />
samba-tool user edit sambauser<br />
<br />
This will open up an interactive editor (or use --editor=nano).<br />
Add the uidNumber, gidNumber, gecos, loginShell, unixHomeDirectory attributes.<br />
<br />
== Non-interactive way with ldb-modify ==<br />
<br />
This will manipulate the underlying database directly.<br />
<br />
Create an ldif (/tmp/user.ldif) containing something similar to the following information.<br />
<br />
dn: CN=sambauser,CN=Users,DC=samdom,DC=example,DC=com<br />
changetype: modify<br />
add: uid<br />
uid: sambauser<br />
-<br />
add: msSFU30Name<br />
msSFU30Name: sambauser<br />
-<br />
add: msSFU30NisDomain<br />
msSFU30NisDomain: samdom<br />
-<br />
add: uidNumber<br />
uidNumber: 10001<br />
-<br />
add: gidNumber<br />
gidNumber: 10000<br />
-<br />
add: loginShell<br />
loginShell: /bin/bash<br />
-<br />
add: unixHomeDirectory<br />
unixHomeDirectory: /home/sambauser<br />
<br />
Add the data with the following command<br />
<br />
ldbmodify -H /usr/local/samba/private/sam.ldb /tmp/user.ldif -U Administrator<br />
<br />
= Creating a Unix group with samba-tool =<br />
<br />
* Open a terminal on a DC and enter the following command:<br />
<br />
samba-tool group add sambagroup --nis-domain=samdom --gid-number=12345<br />
<br />
<br />
<br />
<br />
<br />
= Adding Unix attributes to an existing group =<br />
<br />
== Direct command-line way using samba-tool ==<br />
<br />
Usage: samba-tool group addunixattrs <groupname> <gidnumber><br />
<br />
To add the GID 10000 to Domain Users, you would do this (as root)<br />
<br />
samba-tool group addunixattrs 'Domain Users' 10000<br />
<br />
<br />
== Using ldbmodify and an ldif ==<br />
<br />
* Create an ldif (/tmp/group.ldif) containing something similar to the following information.<br />
<br />
dn: CN=sambagroup,CN=Users,DC=samdom,DC=example,DC=com<br />
changetype: modify<br />
add: msSFU30NisDomain<br />
msSFU30NisDomain: samdom<br />
-<br />
add: msSFU30Name<br />
msSFU30Name: sambagroup<br />
-<br />
add: gidNumber<br />
gidNumber: 10001<br />
<br />
<br />
* Close and save the ldif.<br />
<br />
* Add the data with the following command<br />
<br />
ldbmodify -H /usr/local/samba/private/sam.ldb /tmp/group.ldif -U Administrator<br />
<br />
<br />
<br />
<br />
<br />
= Adding Unix attributes to an existing computer account =<br />
<br />
You need to set the uidNumber attribute to access samba shares on a domain with the Windows machine network account. <br />
<br />
* Create an ldif (/tmp/computer.ldif) containing something similar to the following information.<br />
<br />
dn: CN=sambacomputer,CN=Computers,DC=samdom,DC=example,DC=com<br />
changetype: modify<br />
add: uidNumber<br />
uidNumber: 10001<br />
<br />
* Close and save the ldif.<br />
<br />
* Add the data with the following command<br />
<br />
ldbmodify -H /usr/local/samba/private/sam.ldb /tmp/computer.ldif -U Administrator</div>Hortimechhttps://wiki.samba.org/index.php?title=DNS_Administration&diff=18882DNS Administration2023-04-25T15:19:49Z<p>Hortimech: </p>
<hr />
<div>= Introduction =<br />
<br />
If you're running Samba as Active Directory Domain Controller, you also have to administer a DNS server.<br />
<br />
You will already find general [[The_Samba_AD_DNS_Back_Ends|information on the internal DNS and the BIND DLZ module]] and documentation about [[BIND9_DLZ_DNS_Back_End|Bind as DNS Backend]] in the Wiki.<br />
<br />
<br />
<br />
<br />
<br />
= General =<br />
<br />
By default, Samba creates two forward zones during provisioning/upgrading, this wiki will use the imaginary dns domain of <code>samdom.example.com</code> (you should of course use your own domain name).<br />
This will lead to these two forward zones:<br />
<br />
* '''samdom.example.com''': Zone for your domain.<br />
* '''_msdcs.samdom.example.com''': This is the ForestDNSZone, that contains several service records for the entire directory.<br />
<br />
The default DC name will be <code>dc1</code> <br />
<br />
<br />
<br />
<br />
<br />
= Features =<br />
<br />
The Samba internal DNS is a new implementation. Although BIND is a grown up DNS and long in production on millions of servers, the Samba BIND DLZ module is still new. That's why both backends don't yet cover all the features that you can setup with the Microsoft DNS tools. If you discover problems or missing features, please open a bug report/feature request at [https://bugzilla.samba.org/ https://bugzilla.samba.org/].<br />
<br />
Even though the internal DNS and the BIND DLZ modules are new, they both support all basic requirements for Active Directory and more.<br />
<br />
<br />
<br />
== Known/issues missing features ==<br />
<br />
* Managing zone transfers is not implemented yet. [https://bugzilla.samba.org/show_bug.cgi?id=9951 Bug report #9951:DNS MMC: Enabling DNS zone transfers in MMC fails]<br />
<br />
<br />
<br />
<br />
<br />
= Importance of DNS for Active Directory =<br />
<br />
A working Active Directory is heavily based on a working DNS. It's not just for resolving IP addresses into names and vice versa. Clients find their Domain Controller/s and other important AD services by DNS queries, this means that your clients must use your Domain Controller/s as their nameservers. Do not use anything else between your clients and Domain Controller/s.<br />
<br />
<br />
<br />
<br />
<br />
= Administering DNS on Linux/Unix with samba-tool =<br />
<br />
== Creating a new zone ==<br />
<br />
As an example we'll add a reverse lookup zone.<br />
<br />
It is suggested that you use, wherever possible, one of the RFC 1918 zones, these are:<br />
<br />
10.0.0.0/8<br />
172.16.0.0/12<br />
192.168.0.0/16<br />
<br />
Using the first one: 10.0.0.0/8 will allow you to have a maximum of 16,777,214 ipaddresses.<br />
The second: 172.16.0.0/12 will allow you to have a maximum of 1,048,574 ipaddresses.<br />
The third: 192.168.0.0/16 will allow you to have a maximum of 65,534 ipaddresses.<br />
<br />
You can, if you so wish, use different Subnet masks/CIDRs to split up the RFC1918 zones. For instance, using 192.168.0.0/24 (netmask 255.255.255.0) will you allow you to have a maximum of 254 ipaddresses.<br />
<br />
== To create a /24 reverse zone ==<br />
<br />
$ samba-tool dns zonecreate dc1.samdom.example.com 0.168.192.in-addr.arpa -U administrator<br />
Password for [administrator@SAMDOM.EXAMPLE.COM]:<br />
Zone 0.168.192.in-addr.arpa created successfully<br />
<br />
== To create a /16 reverse zone ==<br />
<br />
$ samba-tool dns zonecreate dc1.samdom.example.com 168.192.in-addr.arpa -U administrator<br />
Password for [administrator@SAMDOM.EXAMPLE.COM]:<br />
Zone 168.192.in-addr.arpa created successfully<br />
<br />
Your new zone will be directly live without restarting Samba or BIND.<br />
<br />
<br />
<br />
== Adding new records ==<br />
<br />
* Example: Adding an A record<br />
<br />
$ samba-tool dns add dc1.samdom.example.com samdom.example.com demo A 192.168.0.55 -U administrator<br />
Password for [administrator@SAMDOM.EXAMPLE.COM]:<br />
Record added successfully<br />
<br />
* Example: Adding a PTR record to the 192.168.0.0/24 reverse zone<br />
<br />
$ samba-tool dns add dc1.samdom.example.com 0.168.192.in-addr.arpa 55 PTR demo.samdom.example.com -U administrator<br />
Password for [administrator@SAMDOM.EXAMPLE.COM]:<br />
Record added successfully<br />
<br />
* Example: Adding a PTR record to the 192.168.0.0/16 reverse zone<br />
<br />
$ samba-tool dns add dc1.samdom.example.com 168.192.in-addr.arpa 55.0 PTR demo.samdom.example.com -U administrator<br />
Password for [administrator@SAMDOM.EXAMPLE.COM]:<br />
Record added successfully<br />
<br />
* Example: Adding a SRV record to _tcp.samdom.example.com<br />
<br />
$ samba-tool dns add dc1.samdom.example.com samdom.example.com _demo._tcp SRV 'demo.samdom.example.com 8080 0 100' -U administrator<br />
Password for [administrator@SAMDOM.EXAMPLE.COM]:<br />
Record added successfully<br />
<br />
:A note on SRV records: The order of the four parameters in the last field ("data") are 'hostname port priority weight' and have to be between ' '.<br />
<br />
* Example: Adding a NS record to samdom.example.com zone<br />
<br />
$ samba-tool dns add dc1.samdom.example.com samdom.example.com @ NS newdc.sambdom.example.com -U administrator<br />
Password for [administrator@SAMDOM.EXAMPLE.COM]:<br />
Record added successfully<br />
<br />
<br />
<br />
== Updating existing records ==<br />
<br />
* Example: Changing an A record<br />
<br />
$ samba-tool dns update dc1.samdom.example.com samdom.example.com demo A 192.168.0.55 192.168.0.66 -U administrator<br />
Password for [administrator@SAMDOM.EXAMPLE.COM]:<br />
Record updated succefully<br />
<br />
* Example: Changing a SOA Resource Record<br />
: The data part of the SOA record consists of 7 space ('&#32;') separated elements in the following order:<br />
: ''nameserver, email, serial, refresh, retry, expire, minimum-ttl''<br />
: &nbsp;<br />
: The following example changes the host masters mail address:<br />
$ samba-tool dns update <Your-AD-DNS-Server-IP-or-hostname> samdom.example.com @ SOA \<br />
"dc1.samdom.example.com hostmaster.example.com 63 900 600 86400 3600" \<br />
"dc1.samdom.example.com admin.example.com 64 900 600 86400 3600" -U administrator<br />
Password for [administrator@SAMDOM.EXAMPLE.COM]:<br />
Record updated successfully<br />
<br />
<br />
<br />
== Delete a record ==<br />
<br />
* Example: Deleting an A record<br />
$ samba-tool dns delete dc1.samdom.example.com samdom.example.com demo A 192.168.0.55 -U administrator<br />
Password for [administrator@SAMDOM.EXAMPLE.COM]:<br />
Record deleted succefully<br />
<br />
* Example: Deleting a NS record from samdom.example.com zone<br />
<br />
$ samba-tool dns delete dc1.samdom.example.com samdom.example.com @ NS olddc.sambdom.example.com -U administrator<br />
Password for [administrator@SAMDOM.EXAMPLE.COM]:<br />
Record deleted successfully<br />
<br />
<br />
<br />
== Deleting a zone ==<br />
<br />
* Example: Deleting a reverse zone:<br />
<br />
$ samba-tool dns zonedelete dc1.samdom.example.com 0.168.192.in-addr.arpa -U administrator<br />
Password for [administrator@SAMDOM.EXAMPLE.COM]:<br />
Zone 0.168.192.in-addr.arpa delete successfully<br />
<br />
<br />
<br />
== Listing existing zones ==<br />
<br />
* Example: listing secondary zones<br />
$ samba-tool dns zonelist dc1.samdom.example.com --secondary -U administrator<br />
<br />
<br />
<br />
== Listing zone information ==<br />
<br />
* Example: showing information about a zone<br />
$ samba-tool dns zoneinfo dc1.samdom.example.com <zone-name> -U administrator<br />
<br />
<br />
<br />
== Listing zone records ==<br />
<br />
* Example: listing records from a zone<br />
$ samba-tool dns query dc1.samdom.example.com <zone-name> @ ALL -U administrator<br />
<br />
<br />
<br />
<br />
<br />
= Administering DNS on Windows =<br />
<br />
To administer DNS from a Windows client, you have to install the DNS MMC Snap-In. See [[Installing RSAT|Installing RSAT on Windows for AD Management]] for more details.<br />
<br />
If you use the internal DNS server, there are the following known problems:<br />
<br />
* Scavenging is not implemented yet. The error message "This function is not supported on this system" is returned.<br />
* Conditional forwarders are not implemented yet. The same error message as above is returned.<br />
* The DNS forwarder can only be changed in the smb.conf, not via the MMC Snap-In.<br />
* Creating static records. When a static record is created it has a timestamp and the option "Delete this record when it becomes stale". In Windows Active Directory, static records have a "static" timestamp and cannot be incidently deleted.<br />
<br />
<br />
<br />
<br />
== Adding new records ==<br />
<br />
* Navigate to the zone, where you want to to add a new record.<br />
<br />
* Right-click to it and choose the kind of record to add.<br />
<br />
: [[Image:DNS_Manager_Add_records.png]]<br />
<br />
* Fill the fields and save the new entry.<br />
<br />
<br />
<br />
== Updating existing records ==<br />
<br />
* Navigate to the zone that contains the record you want to edit.<br />
<br />
* Right-click the record and choose „Properties“.<br />
<br />
: [[Image:DNS_Manager_Change_record.png]]<br />
<br />
* Edit the entry and save the changes.<br />
<br />
<br />
<br />
== Delete a record ==<br />
<br />
* Navigate to the zone that contains the record you want to remove.<br />
<br />
* Right-click to the record and choose „Delete“.<br />
<br />
<br />
<br />
== Changing zone properties ==<br />
<br />
* Right-click to a zone of which you you want to do changes.<br />
<br />
* Choose „Properties“.<br />
<br />
'''Note''': Currently both DNS backends don't support all features that can be setup in the dialogues. If you discover problems or missing features, please open a bug report/feature request at [https://bugzilla.samba.org/ https://bugzilla.samba.org/].<br />
<br />
<br />
<br />
== Creating a new zone ==<br />
<br />
As example we'll add a reverse lookup zone.<br />
<br />
* Right-click to „Reverse Lookup Zones“ and choose „New Zone“.<br />
<br />
* The „New Zone Wizard“ appears.<br />
<br />
* Zone Type: Select „Primary zone“ and „Store the zone in Active Directory“.<br />
<br />
: [[Image:DNS_Add_Zone_Wizzard_1.png]]<br />
<br />
* Zone Replication Scope: Depends on your needs.<br />
<br />
: [[Image:DNS_Add_Zone_Wizzard_2.png]]<br />
<br />
* Reverse Lookup Zone Name: Depends on your needs.<br />
<br />
: [[Image:DNS_Add_Zone_Wizzard_3.png]]<br />
<br />
: Dynamic Update: Depends on your needs.<br />
<br />
: [[Image:DNS_Add_Zone_Wizzard_4.png]]<br />
<br />
* Finish the wizard.<br />
<br />
Your new zone is directly live without restarting Samba or BIND.<br />
<br />
<br />
<br />
<br />
== Deleting a zone ==<br />
<br />
* Right-click to a zone and choose „Delete“.<br />
<br />
: [[Image:DNS_Delete_Zone.png]]<br />
<br />
= Administering DNS on Linux with admin-tools =<br />
<br />
You can administer DNS from a Linux client using the admin-tools DNS module. The admin-tools DNS module uses samba-tool as a backend. You can download an [https://appimage.github.io/admin-tools/ AppImage here].<br />
<br />
== Adding new records ==<br />
<br />
* Navigate to the zone where you want to to add a new record.<br />
<br />
* Select the Action menu and choose the kind of record to add.<br />
<br />
: [[Image:Admin_tools_DNS_Manager_Add_records.png]]<br />
<br />
* Fill the fields and save the new entry.<br />
<br />
<br />
<br />
== Updating existing records == -U Administrator<br />
<br />
* Navigate to the zone that contains the record you want to edit.<br />
<br />
* Highlight the record, then select the Action menu and choose „Properties“.<br />
<br />
: [[Image:Admin_tools_DNS_Manager_Change_record.png]]<br />
<br />
* Edit the entry and save the changes.<br />
<br />
<br />
<br />
== Delete a record ==<br />
<br />
* Navigate to the zone that contains the record you want to remove.<br />
<br />
* Highlight the record, then select the Action menu and choose „Delete“.<br />
<br />
<br />
<br />
== Creating a new zone ==<br />
<br />
As example we'll add a reverse lookup zone.<br />
<br />
* Highlight „Reverse Lookup Zones“, then select the Action menu and choose „New Zone“.<br />
<br />
* The „New Zone Wizard“ appears.<br />
<br />
* Choose IPv4 or IPv6: Depends on your needs.<br />
<br />
: [[Image:Admin_tools_DNS_Add_Zone_Wizard_1.png]]<br />
<br />
* Reverse Lookup Zone Name: Depends on your needs.<br />
<br />
: [[Image:Admin_tools_DNS_Add_Zone_Wizard_2.png]]<br />
<br />
* Finish the wizard.<br />
<br />
Your new zone is directly live without restarting Samba or BIND.<br />
<br />
<br />
<br />
<br />
== Deleting a zone ==<br />
<br />
* Highlight a zone, then select the Action menu and choose „Delete“.<br />
<br />
: [[Image:Admin_tools_DNS_Delete_Zone.png]]<br />
<br />
<br />
<br />
<br />
<br />
= Configuring clients to use your AD DNS server =<br />
<br />
* [[Windows_DNS_Configuration|Windows]]<br />
* [[Linux_and_Unix_DNS_Configuration|Linux/Unix]]<br />
* [[MacOSX_DNS_Configuration|MacOSX]]<br />
<br />
<br />
<br />
<br />
<br />
= Testing your DNS Server =<br />
<br />
See [[Testing_the_DNS_Name_Resolution|Testing the DNS Name Resolution]].<br />
<br />
<br />
<br />
<br />
<br />
----<br />
[[Category:Active Directory]]<br />
[[Category:DNS]]</div>Hortimechhttps://wiki.samba.org/index.php?title=Setting_up_Samba_as_an_Active_Directory_Domain_Controller&diff=18881Setting up Samba as an Active Directory Domain Controller2023-04-25T08:44:40Z<p>Hortimech: </p>
<hr />
<div>= Introduction =<br />
<br />
Starting from version 4.0 (released in 2012,) Samba is able to serve as an Active Directory (AD) domain controller (DC). Samba can operates at a forest functional level of '''Windows Server 2008 R2''' which is more that sufficient to manage sophisticated enterprises that use Windows 10/11 with strict compliance requirements (including NIST 800-171.)<br />
<br />
If you are installing Samba in a production environment, it is recommended to run two or more DCs for failover reasons, more detail on the provisioning of a failover DC can be found elsewhere on the wiki. This documentation describes how to set up Samba as the first DC to build a new AD forest. Additionally, use this documentation if you are migrating a Samba NT4 domain to Samba AD. To join Samba as an additional DC to an existing AD forest, see [[Joining_a_Samba_DC_to_an_Existing_Active_Directory|Joining a Samba DC to an Existing Active Directory]]. <br />
<br />
Samba as an AD DC only supports:<br />
* The integrated LDAP server as AD back end. For details, see the frequently asked question (FAQ) [[FAQ#Does_Samba_AD_DCs_Support_OpenLDAP_or_Other_LDAP_Servers_as_Back_End.3F|Does Samba AD DCs Support OpenLDAP or Other LDAP Servers as Back End?]]<br />
* The [http://www.h5l.se/ Heimdal] Kerberos Key Distribution Center (KDC).<br />
: Samba provides experimental support for the [https://web.mit.edu/kerberos/ MIT Kerberos] KDC provided by your operating system if you run Samba 4.7 or later and has been built using the <code>--with-system-mitkrb5</code> option. In other cases Samba uses the Heimdal KDC included in Samba. For further details about Samba using the MIT KDC, and why it is experimental see [[Running a Samba AD DC with MIT Kerberos KDC]].<br />
* Hosting and Administering of Group Policy Objects to be used for enterprise fleet management<br />
: {{Imbox<br />
| type = important<br />
| text = Installation of Samba and associated provisioning of a domain controller does not automatically translate into Group Policy functionality. Please keep this in mind, and expect to update this flag in the <code>smb.conf</code> post provisioning<br />
}}<br />
<br />
This tutorial assumes that this is a fresh installation of Samba on a fresh operating system installation. It is important to note that there is a distinction between installing of Samba and Provisioning of Samba. In general, the entire process of setting up a Samba domain controller consists of 5 steps which are relatively straight forward. These steps are as follows:<br />
<br />
# Installation of Samba and associated packages<br />
# Deletion of per-configured Samba and Kerberos placeholder configuration files<br />
# Provisioning of Samba using the automatic provisioning tool<br />
# Editing of the <code>smb.conf</code> as needed (enabling of Group Policy and/or other features as needed) see [[Group_Policy|Group Policy]] for more information<br />
# Any environmental configuration based on Unix/Linux Distribution<br />
<br />
This page covers a lot of ground for Samba installations on both Unix and Linux systems. The installation process varies slightly based on environment, so expect to follow the linked web pages in multiple tabs throughout this read. For the remainder of this tutorial the following example information is used:<br />
<br />
* Hostname = <code>DC1</code><br />
* DC local IP Address = <code>10.99.0.1</code><br />
* Authentication Domain = <code>SAMDOM.EXAMPLE.COM</code><br />
* Top level Domain = <code>EXAMPLE.COM</code><br />
<br />
<br />
<br />
= Preparing the Installation =<br />
<br />
==== Fresh Installation ====<br />
<br />
<br />
* Select a DNS domain for your AD forest. It is not recommended to use the top level domain for your organization. This is because the domain used during the installation of Samba will resolve to the domain controller. For Example: If your organization used <code>EXAMPLE.COM</code> as their domain and this was used during the Samba installation process, then the public facing website would no longer be acceptable (assuming the publicly accessible website was not running on the DC, which it shouldn't!) It would be wise to define a subdomain for your Domain Controller to reside in. In this tutorial <code>SAMDOM.EXAMPLE.COM</code> is used, however in a lab environment it is not necessary to own a publicly accessible domain and <code>.INTERNAL</code> could hypothetically be used. The name will also be used as the AD Kerberos realm.<br />
: {{Imbox<br />
| type = important<br />
| text = Make sure that you provision the AD using a DNS domain that will not need to be changed. Samba does not support renaming the AD DNS zone and Kerberos realm. Do not use <code>.local</code> for the TLD, this is used by Avahi.<br />
}}<br />
: For additional information, see [[Active_Directory_Naming_FAQ|Active Directory Naming FAQ]].<br />
<br />
* Select a host name for your AD DC which consists of less than 15 characters (netbios limitation.) A fantastic hostname is <code>DC1</code><br />
: Do not use NT4-only terms as host name, such as <code>PDC</code> or <code>BDC</code>. These modes do not exist in an AD and cause confusion.<br />
<br />
* A static IP address on the DC and make the associated reservation on your router. '''Important:''' The Samba domain controller will become your DNS resolver for all domain-joined workstations. As a result it may be required to assign this IP address outside of your DHCP pool<br />
<br />
* Disable tools, such as <code>resolvconf</code>, that automatically update your <code>/etc/resolv.conf</code> DNS resolver configuration file. AD DCs and domain members must use an DNS server that is able to resolve the AD DNS zones. (More information on this on the [[Distribution-specific_Package_Installation| Distribution Specific Package Installation]] page)<br />
<br />
* Verify that the <code>/etc/hosts</code> file on the DC correctly resolves the fully-qualified domain name (FQDN) and short host name to the LAN IP address of the DC. For example:<br />
127.0.0.1 localhost<br />
10.99.0.1 DC1.samdom.example.com DC1<br />
:The host name and FQDN must not resolve to the <code>127.0.0.1</code> IP address or any other IP address than the one used on the LAN interface of the DC.<br />
<br />
* Remove any existing <code>smb.conf</code> file. To list the path to the file:<br />
<br />
# smbd -b | grep "CONFIGFILE"<br />
CONFIGFILE: /usr/local/samba/etc/samba/smb.conf<br />
<br />
<br />
==== Only Applicable if Samba was Previously Installed ====<br />
* If you previously ran a Samba installation on this host:<br />
:<br />
<br />
:* Remove all Samba database files, such as <code>*.tdb</code> and <code>*.ldb</code> files. To list the folders containing Samba databases:<br />
<br />
# smbd -b | egrep "LOCKDIR|STATEDIR|CACHEDIR|PRIVATE_DIR"<br />
LOCKDIR: /usr/local/samba/var/lock/<br />
STATEDIR: /usr/local/samba/var/locks/<br />
CACHEDIR: /usr/local/samba/var/cache/<br />
PRIVATE_DIR: /usr/local/samba/private/<br />
<br />
: Starting with a clean environment helps to prevent confusion and ensures that no files from any previous Samba installation will be mixed with your new domain DC installation.<br />
<br />
<br />
= Installing Samba =<br />
<br />
<br />
{{:Installing_Samba}}<br />
<br />
<br />
<br />
= Provisioning a Samba Active Directory =<br />
<br />
{{Imbox<br />
| type = note<br />
| text = The AD provisioning requires root permissions to create files and set permissions.<br />
}}<br />
<br />
The Samba AD provisioning process creates the AD databases and adds initial records, such as the domain administrator account and required DNS entries. Samba comes with a built in command lined tool called <code>samba-tool</code> which can be used to automatically configure your <code>smb.conf</code> when ran in interactive mode. <br />
<br />
If you are migrating a Samba NT4 domain to AD, skip this step and run the Samba classic upgrade. For details, see [[Migrating_a_Samba_NT4_Domain_to_Samba_AD_(Classic_Upgrade)|Migrating a Samba NT4 Domain to Samba AD (Classic Upgrade)]].<br />
<br />
<br />
The <code>samba-tool domain provision</code> command provides several parameters to use with the interactive and non-interactive setup. For details, see:<br />
<br />
# samba-tool domain provision --help<br />
<br />
<br />
{{Imbox<br />
| type = note<br />
| text = When provisioning a new AD, it is recommended to enable the NIS extensions by passing the <code>--use-rfc2307</code> parameter to the <code>samba-tool domain provision</code> command. There are no disadvantages to enabling the NIS extensions, but enabling them in an existing domain requires manually extending the AD schema. For further details about Unix attributes in AD, see:<br />
* [[Setting_up_RFC2307_in_AD|Setting up RFC2307 in AD]]<br />
* [[Idmap_config_ad|idmap config = ad]]<br />
}}<br />
<br />
<br />
<br />
==== Parameter Reference ====<br />
<br />
Set the following parameters during the provisioning:<br />
<br />
{| class="wikitable"<br />
!Interactive Mode Setting<br />
!Non-interactive Mode Parameter<br />
!Explanation<br />
|-<br />
|<code>--use-rfc2307</code><br />
|<code>--use-rfc2307</code><br />
|Enables the NIS extensions required for the ADUC Unix Attributes tab.<br />
|-<br />
|<code>Realm</code><br />
|<code>--realm</code><br />
|Kerberos realm. The uppercase version of the AD DNS domain. For example: <code>SAMDOM.EXAMPLE.COM</code>.<br />
|-<br />
|<code>Domain</code><br />
|<code>--domain</code><br />
|NetBIOS domain name (Workgroup). This can be anything, but it must be one word, not longer than 15 characters and not containing a dot. It is recommended to use the first part of the AD DNS domain. For example: <code>samdom</code>. Do not use the computers short hostname.<br />
|-<br />
|<code>Server Role</code><br />
|<code>--server-role</code><br />
|Installs the domain controller <code>DC</code> role.<br />
|-<br />
|<code>DNS backend</code><br />
|<code>--dns-backend</code><br />
|Sets the DNS back end. The first DC in an AD must be installed using a DNS back end. Note that the <code>BIND9_FLATFILE</code> is not supported and will be removed in a future Samba version.<br />
|-<br />
|<code>DNS forwarder IP address</code><br />
|not available<br />
|This setting is only available when using the <code>SAMBA_INTERNAL</code> DNS back end. For details, see [[Samba_Internal_DNS_Back_End#Setting_up_a_DNS_Forwarder|Setting up a DNS Forwarder]].<br />
|-<br />
|<code>Administrator password</code><br />
|<code>--adminpass</code><br />
|Sets the domain administrator password. If the password does not match the complexity requirements, the provisioning fails. For details, see [https://technet.microsoft.com/en-us/library/cc786468%28v=ws.10%29.aspx Microsoft TechNet: Passwords must meet complexity requirements].<br />
|}<br />
<br />
Other parameters frequently used with the <code>samba-tool domain provision</code> command:<br />
* <code>--option="interfaces=lo eth0" --option="bind interfaces only=yes"</code>: If your server has multiple network interfaces, use these options to bind Samba to the specified interfaces. This enables the <code>samba-tool</code> command to register the correct LAN IP address in the directory during the join.<br />
<br />
<br />
{{Imbox<br />
| type = important<br />
| text = do NOT use <code>NONE</code> as the DNS backend, it is not supported and will be removed in a future Samba version.<br />
}}<br />
<br />
{{Imbox<br />
| type = important<br />
| text = If using Bind as the DNS backend, do NOT use <code>BIND9_FLATFILE</code>, it is not supported and will be removed in a future Samba version.<br />
}}<br />
<br />
{{Imbox<br />
| type = important<br />
| text = Once you have provisioned the first DC in an AD domain, do not provision any further DCs in the same domain, [[Joining_a_Samba_DC_to_an_Existing_Active_Directory|Join]] any further DCs.<br />
}}<br />
<br />
<br />
<br />
== Provisioning Samba AD in Interactive Mode ==<br />
<br />
As mentioned above, <code>samba-tool</code> when ran as route will automatically configure your <code>smb.conf</code> to build a domain controller. Interactive Mode will not automatically enable Group Policy support. However this can be added in afterwards by manually editing the <code>smb.conf</code> to add it in later. Open the [[Group_Policy#Winbind|Group Policy]] page in a new tab for later reading<br />
{{Imbox<br />
| type = warning<br />
| text = The installation of Samba will create a <code>smb.conf</code> file that must be discarded prior to running the Provisioning Tool in Interactive mode, or else it will fail. On most Linux distributions this can be done by running:<br />
# mv /etc/samba/smb.conf /etc/samba/smb.conf.initial<br />
}}<br />
<br />
With the existing <code>smb.conf</code> file removed, provision a Samba AD interactively by running run:<br />
<br />
# samba-tool domain provision --use-rfc2307 --interactive<br />
Realm [SAMDOM.EXAMPLE.COM]: SAMDOM.EXAMPLE.COM<br />
Domain [SAMDOM]: SAMDOM<br />
Server Role (dc, member, standalone) [dc]: dc<br />
DNS backend (SAMBA_INTERNAL, BIND9_FLATFILE, BIND9_DLZ, NONE) [SAMBA_INTERNAL]: SAMBA_INTERNAL<br />
DNS forwarder IP address (write 'none' to disable forwarding) [10.99.0.1]: 8.8.8.8<br />
Administrator password: Passw0rd<br />
Retype password: Passw0rd<br />
Looking up IPv4 addresses<br />
Looking up IPv6 addresses<br />
No IPv6 address will be assigned<br />
Setting up share.ldb<br />
Setting up secrets.ldb<br />
Setting up the registry<br />
Setting up the privileges database<br />
Setting up idmap db<br />
Setting up SAM db<br />
Setting up sam.ldb partitions and settings<br />
Setting up sam.ldb rootDSE<br />
Pre-loading the Samba 4 and AD schema<br />
Adding DomainDN: DC=samdom,DC=example,DC=com<br />
Adding configuration container<br />
Setting up sam.ldb schema<br />
Setting up sam.ldb configuration data<br />
Setting up display specifiers<br />
Modifying display specifiers<br />
Adding users container <br />
Modifying users container <br />
Adding computers container <br />
Modifying computers container <br />
Setting up sam.ldb data <br />
Setting up well known security principals <br />
Setting up sam.ldb users and groups <br />
Setting up self join <br />
Adding DNS accounts <br />
Creating CN=MicrosoftDNS,CN=System,DC=samdom,DC=example,DC=com <br />
Creating DomainDnsZones and ForestDnsZones partitions <br />
Populating DomainDnsZones and ForestDnsZones partitions <br />
Setting up sam.ldb rootDSE marking as synchronized <br />
Fixing provision GUIDs <br />
A Kerberos configuration suitable for Samba 4 has been generated at /usr/local/samba/private/krb5.conf <br />
Setting up fake yp server settings <br />
Once the above files are installed, your Samba4 server will be ready to use <br />
Server Role: active directory domain controller <br />
Hostname: DC1 <br />
NetBIOS Domain: SAMDOM <br />
DNS Domain: samdom.example.com <br />
DOMAIN SID: S-1-5-21-2614513918-2685075268-614796884<br />
<br />
{{Imbox<br />
| type = note<br />
| text = The interactive provisioning mode supports passing further parameters to the <code>samba-tool domain provision</code> command. This enables you to modify parameters that are not part of the interactive setup.<br />
}}<br />
<br />
<br />
<br />
== Provisioning Samba AD in Non-interactive Mode ==<br />
<br />
For example, to provision a Samba AD non-interactively with the following settings:<br />
* Server role: <code>dc</code><br />
* NIS extensions enabled<br />
* Internal DNS back end<br />
* Kerberos realm and AD DNS zone: <code>samdom.example.com</code><br />
* NetBIOS domain name: <code>SAMDOM</code><br />
* Domain administrator password: <code>Passw0rd</code><br />
<br />
# samba-tool domain provision --server-role=dc --use-rfc2307 --dns-backend=SAMBA_INTERNAL --realm=SAMDOM.EXAMPLE.COM --domain=SAMDOM --adminpass=Passw0rd<br />
<br />
<br />
<br />
<br />
<br />
= Setting up the AD DNS back end =<br />
<br />
Skip this step if you provisioned the DC using the <code>SAMBA_INTERNAL</code> DNS back end.<br />
<br />
* Set up the BIND DNS server and the <code>BIND9_DLZ</code> module. For details, see [[Setting_up_a_BIND_DNS_Server|Setting up a BIND DNS Server]].<br />
<br />
* Start the BIND DNS server. For example:<br />
# systemctl start named<br />
: For details how to start services, see you distribution's documentation.<br />
<br />
<br />
<br />
<br />
= Configuring the DNS Resolver =<br />
<br />
Domain members in an AD use DNS to locate services, such as LDAP and Kerberos. For that, they need to use a DNS server that is able to resolve the AD DNS zone.<br />
<br />
On your DC, set the AD DNS domain in the <code>search</code> and the IP of your DC in the <code>nameserver</code> parameter of the <code>/etc/resolv.conf</code> file. For example:<br />
<br />
search samdom.example.com<br />
nameserver 10.99.0.1<br />
<br />
<br />
<br />
<br />
<br />
= Create a reverse zone =<br />
<br />
You can optionally add a reverse lookup zone.<br />
<br />
# samba-tool dns zonecreate <Your-AD-DNS-Server-IP-or-hostname> 0.99.10.in-addr.arpa -U Administrator<br />
Password for [administrator@SAMDOM.EXAMPLE.COM]:<br />
Zone 0.99.10.in-addr.arpa created successfully<br />
<br />
If you need more than one reverse zone (multiple subnets), just run the above command again but with the data for the other subnet.<br />
<br />
The reverse zone is directly live without restarting Samba or BIND.<br />
<br />
{{Imbox<br />
| type = note<br />
| text = You must start the Samba AD DC before you can add a reverse zone.<br />
}}<br />
<br />
<br />
Now that you have created a reversezone, it would be a good time to create the <code>PTR</code> (reverse) dns record for the new DC.<br />
<br />
For a DC with the FQDN of <code>dc1.samdom.example.com</code> and the ipaddress of <code>10.99.0.1</code>, to add a record to the <code>0.99.10.in-addr.arpa</code>, you would run a command like this:<br />
<br />
# samba-tool dns add <Your-AD-DNS-Server-IP-or-hostname> 0.99.10.in-addr.arpa 1 PTR dc1.samdom.example.com -U Administrator<br />
Password for [administrator@SAMDOM.EXAMPLE.COM]:<br />
Record added successfully<br />
<br />
{{Imbox<br />
| type = note<br />
| text = The reverse records are not added automatically, you must add them manually, or set Windows computers to add them when updating their dns records.<br />
}}<br />
<br />
<br />
<br />
<br />
<br />
= Configuring Kerberos =<br />
<br />
In an AD, Kerberos is used to authenticate users, machines, and services.<br />
<br />
During the provisioning, Samba created a Kerberos configuration file for your DC. Copy this file to your operating system's Kerberos configuration. For example:<br />
<br />
# cp /usr/local/samba/private/krb5.conf /etc/krb5.conf<br />
<br />
{{Imbox<br />
| type = important<br />
| text = Do not create a symbolic link to the the generated <code>krb5.conf</code> file. In Samba 4.7 and later, the <code>/usr/local/samba/private/</code> directory is no longer accessible by other users than the <code>root</code> user. If the file is a symbolic link, other users are not able to read the file and, for example, dynamic DNS updates fail if you use the <code>BIND_DLZ</code> DNS back end.<br />
}}<br />
<br />
The pre-created Kerberos configuration uses DNS service (SRV) resource records to locate the KDC.<br />
<br />
<br />
<br />
<br />
<br />
= Testing your Samba AD DC =<br />
<br />
To start the <code>samba</code> service manually, enter:<br />
<br />
# samba<br />
<br />
Samba does not provide System V init scripts, <code>systemd</code>, <code>upstart</code>, or other services configuration files.<br />
* If you installed Samba using packages, use the script or service configuration file included in the package to start Samba.<br />
* If you built Samba, see [[Managing_the_Samba_AD_DC_Service|Managing the Samba AD DC Service]].<br />
<br />
<br />
<br />
== Verifying the File Server (Optional)==<br />
<br />
To list all shares provided by the DC:<br />
<br />
Before Samba 4.11.0:<br />
<br />
$ smbclient -L localhost -N<br />
Anonymous login successful<br />
Domain=[SAMDOM] OS=[Unix] Server=[Samba x.y.z]<br />
<br />
Sharename Type Comment<br />
--------- ---- -------<br />
netlogon Disk <br />
sysvol Disk <br />
IPC$ IPC IPC Service (Samba x.y.z)<br />
Domain=[SAMDOM] OS=[Unix] Server=[Samba x.y.z]<br />
<br />
Server Comment<br />
--------- -------<br />
<br />
Workgroup Master<br />
--------- -------<br />
<br />
From Samba 4.11.0:<br />
<br />
smbclient -L localhost -N<br />
Anonymous login successful<br />
<br />
Sharename Type Comment<br />
--------- ---- -------<br />
sysvol Disk <br />
netlogon Disk <br />
IPC$ IPC IPC Service (Samba 4.12.6-Debian)<br />
SMB1 disabled -- no workgroup available<br />
<br />
<br />
{{Imbox<br />
| type = note<br />
| text = The <code>netlogon</code> and <code>sysvol</code> shares were auto-created during the provisioning and must exist on a DC.<br />
}}<br />
<br />
To verify authentication, connect to the <code>netlogon</code> share using the domain administrator account:<br />
<br />
$ smbclient //localhost/netlogon -UAdministrator -c 'ls'<br />
Enter Administrator's password: <br />
Domain=[SAMDOM] OS=[Unix] Server=[Samba x.y.z]<br />
. D 0 Tue Nov 1 08:40:00 2016<br />
.. D 0 Tue Nov 1 08:40:00 2016<br />
<br />
49386 blocks of size 524288. 42093 blocks available<br />
<br />
If one or more tests fail, see [[#Troubleshooting|Troubleshooting]].<br />
<br />
<br />
<br />
== Verifying DNS (Optional)==<br />
<br />
To verify that your AD DNS configuration works correctly, query some DNS records:<br />
<br />
* The tcp-based <code>_ldap</code> SRV record in the domain:<br />
<br />
$ host -t SRV _ldap._tcp.samdom.example.com.<br />
_ldap._tcp.samdom.example.com has SRV record 0 100 389 dc1.samdom.example.com.<br />
<br />
* The udp-based <code>_kerberos</code> SRV resource record in the domain:<br />
<br />
$ host -t SRV _kerberos._udp.samdom.example.com.<br />
_kerberos._udp.samdom.example.com has SRV record 0 100 88 dc1.samdom.example.com.<br />
<br />
* The A record of the domain controller:<br />
<br />
$ host -t A dc1.samdom.example.com.<br />
dc1.samdom.example.com has address 10.99.0.1<br />
<br />
* If you have created a reverse zone, the PTR record of the domain controller:<br />
<br />
$ host -t PTR 10.99.0.1<br />
1.0.99.10.in-addr.arpa domain name pointer dc1.samdom.example.com.<br />
<br />
If one or more tests fail, see [[#Troubleshooting|Troubleshooting]].<br />
<br />
<br />
<br />
== Verifying Kerberos (Optional) ==<br />
<br />
This is not explicitly required, but it is a good idea to verify that your Domain Controller's authentication mechanisms are operating as intended. To test this, login by requesting a Kerberos ticket for the Domain Administrator account:<br />
<br />
$ kinit administrator<br />
Password for administrator@SAMDOM.EXAMPLE.COM:<br />
<br />
: {{Imbox<br />
| type = note<br />
| text = If you do not pass the principal in the <code>user@REALM</code> format to the <code>kinit</code> command, the Kerberos realm is automatically appended.<br />Always enter the Kerberos realm in uppercase.<br />
}}<br />
<br />
* List the cached Kerberos tickets:<br />
<br />
$ klist<br />
Ticket cache: FILE:/tmp/krb5cc_0<br />
Default principal: administrator@SAMDOM.EXAMPLE.COM<br />
<br />
Valid starting Expires Service principal<br />
01.11.2016 08:45:00 12.11.2016 18:45:00 krbtgt/SAMDOM.EXAMPLE.COM@SAMDOM.EXAMPLE.COM<br />
renew until 02.11.2016 08:44:59<br />
<br />
If one or more tests fail, see [[#Troubleshooting|Troubleshooting]].<br />
<br />
<br />
<br />
<br />
<br />
= Configuring Time Synchronization (Optional Depending on Use-Case)=<br />
<br />
Kerberos requires synchronized time on all domain members. For further details and how to set up the <code>ntpd</code> or <code>chrony</code> service, see [[Time_Synchronisation|Time Synchronization]]. However if Samba is being used as a domain controller to administer Group Policy, it is possible to define a Group Policy Object that synchronizes workstations with <code>time.windows.com</code> post installation which simplifies this<br />
<br />
<br />
<br />
= Using the Domain Controller as a File Server (Optional) =<br />
<br />
{{Imbox<br />
| type = warning<br />
| text = Do not use an AD DC as a fileserver if you have multiple DC's. You should only use a DC as a fileserver, if it is the only Samba instance running in a domain. If you have multiple DC's, you should also set up Unix domain members and use them as fileservers. You should be aware that it is problematic to use a DC as a fileserver and can cause strange errors.<br />
}}<br />
<br />
<br />
Whilst the Samba AD DC is able to provide file shares, just like all other installation modes, the Samba team does not recommend using a DC as a file server for the following reasons:<br />
<br />
* For anything but the smallest organizations, having more than one DC is a really good backup measure, and makes upgrades safer<br />
* It encourages upgrades of the DC to also be upgrades of the host OS every year or two, because there isn't complex data to transition or other services involved. <br />
* This means upgrades can be done by installing fresh, and replicating in the changes, which is better tested in Samba, gains new features and avoids a number of lingering data corruption risks. <br />
* The DC and file-server have different points at which an organization would wish to upgrade. The needs for new features on the DC and file server come at different times. Currently the AD DC is evolving rapidly to gain features, whereas the fileserver, after over 20 years, is quite rightly more conservative.<br />
* mandatory smb signing is enforced on the DC.<br />
<br />
<br />
If you do decide to use the Samba DC as a fileserver, please consider running a VM, on the DC, containing a separate Samba Unix domain member and use this instead.<br />
<br />
If you must use the Samba DC as a fileserver, you should be aware that the auto-enabled <code>acl_xattr</code> virtual file system (VFS) object enables you to only configure shares with Windows access control lists (ACL). Using POSIX ACLs with shares on a Samba DC does not work. <br />
<br />
You should be aware that if wish to use a vfs object on a DC share e.g. recycle, you must not just set <code>vfs objects = recycle</code> in the share. Doing this will turn off the default vfs objects <code>dfs_samba4</code> and <code>acl_xattr</code>. You must set <code>vfs objects = dfs_samba4 acl_xattr recycle</code>. <br />
<br />
To provide network shares with the full capabilities of Samba, set up a Samba domain member with file shares. For details, see:<br />
* [[Setting_up_Samba_as_a_Domain_Member|Setting up Samba as a Domain Member]]<br />
* [[Samba_File_Serving|Samba File Serving]]<br />
<br />
<br />
If you only have a small domain (small office, home network) and do not want to follow the Samba team's recommendation and use the DC additionally as a file server, configure Winbindd before you start setting up shares. For details, see [[Configuring_Winbindd_on_a_Samba_AD_DC|Configuring Winbindd on a Samba AD DC]].<br />
<br />
<br />
{{Imbox<br />
| type = warning<br />
| text = If you do use an AD DC as a fileserver, you must be aware that it can be problematic and can cause strange errors.<br />
}}<br />
<br />
{{Imbox<br />
| type = warning<br />
| text = If you do use an AD DC as a fileserver, do not add any of the 'idmap config' lines used on a Unix domain member. They will not work and will cause problems.<br />
}}<br />
<br />
{{Imbox<br />
| type = warning<br />
| text = If you do use an AD DC as a fileserver, You must set the permissions from Windows, do not attempt to use any of the old methods (force user etc) . They will not work correctly and will cause problems.<br />
}}<br />
<br />
<br />
<br />
<br />
<br />
= Troubleshooting =<br />
<br />
For further details, see [[Samba_AD_DC_Troubleshooting|Samba AD DC Troubleshooting]].<br />
<br />
<br />
<br />
<br />
<br />
= Further Samba-related Documentation =<br />
<br />
See [[User_Documentation|User Documentation]].<br />
<br />
<br />
<br />
<br />
<br />
----<br />
[[Category:Domain Control]]<br />
[[Category:Active Directory]]</div>Hortimechhttps://wiki.samba.org/index.php?title=Setting_up_Samba_as_an_Active_Directory_Domain_Controller&diff=18880Setting up Samba as an Active Directory Domain Controller2023-04-25T08:38:17Z<p>Hortimech: </p>
<hr />
<div>= Introduction =<br />
<br />
Starting from version 4.0 (released in 2012,) Samba is able to serve as an Active Directory (AD) domain controller (DC). Samba can operates at a forest functional level of '''Windows Server 2008 R2''' which is more that sufficient to manage sophisticated enterprises that use Windows 10/11 with strict compliance requirements (including NIST 800-171.)<br />
<br />
If you are installing Samba in a production environment, it is recommended to run two or more DCs for failover reasons, more detail on the provisioning of a failover DC can be found elsewhere on the wiki. This documentation describes how to set up Samba as the first DC to build a new AD forest. Additionally, use this documentation if you are migrating a Samba NT4 domain to Samba AD. To join Samba as an additional DC to an existing AD forest, see [[Joining_a_Samba_DC_to_an_Existing_Active_Directory|Joining a Samba DC to an Existing Active Directory]]. <br />
<br />
Samba as an AD DC only supports:<br />
* The integrated LDAP server as AD back end. For details, see the frequently asked question (FAQ) [[FAQ#Does_Samba_AD_DCs_Support_OpenLDAP_or_Other_LDAP_Servers_as_Back_End.3F|Does Samba AD DCs Support OpenLDAP or Other LDAP Servers as Back End?]]<br />
* The [http://www.h5l.se/ Heimdal] Kerberos Key Distribution Center (KDC).<br />
: Samba provides experimental support for the [https://web.mit.edu/kerberos/ MIT Kerberos] KDC provided by your operating system if you run Samba 4.7 or later and has been built using the <code>--with-system-mitkrb5</code> option. In other cases Samba uses the Heimdal KDC included in Samba. For further details about Samba using the MIT KDC, and why it is experimental see [[Running a Samba AD DC with MIT Kerberos KDC]].<br />
* Hosting and Administering of Group Policy Objects to be used for enterprise fleet management<br />
: {{Imbox<br />
| type = important<br />
| text = Installation of Samba and associated provisioning of a domain controller does not automatically translate into Group Policy functionality. Please keep this in mind, and expect to update this flag in the <code>smb.conf</code> post provisioning<br />
}}<br />
<br />
This tutorial assumes that this is a fresh installation of Samba on a fresh operating system installation. It is important to note that there is a distinction between installing of Samba and Provisioning of Samba. In general, the entire process of setting up a Samba domain controller consists of 5 steps which are relatively straight forward. These steps are as follows:<br />
<br />
# Installation of Samba and associated packages<br />
# Deletion of per-configured Samba and Kerberos placeholder configuration files<br />
# Provisioning of Samba using the automatic provisioning tool<br />
# Editing of the <code>smb.conf</code> as needed (enabling of Group Policy and/or other features as needed) see [[Group_Policy|Group Policy]] for more information<br />
# Any environmental configuration based on Unix/Linux Distribution<br />
<br />
This page covers a lot of ground for Samba installations on both Unix and Linux systems. The installation process varies slightly based on environment, so expect to follow the linked web pages in multiple tabs throughout this read. For the remainder of this tutorial the following example information is used:<br />
<br />
* Hostname = <code>DC1</code><br />
* DC local IP Address = <code>10.99.0.1</code><br />
* Authentication Domain = <code>SAMDOM.EXAMPLE.COM</code><br />
* Top level Domain = <code>EXAMPLE.COM</code><br />
<br />
<br />
<br />
= Preparing the Installation =<br />
<br />
==== Fresh Installation ====<br />
<br />
<br />
* Select a DNS domain for your AD forest. It is not recommended to use the top level domain for your organization. This is because the domain used during the installation of Samba will resolve to the domain controller. For Example: If your organization used <code>EXAMPLE.COM</code> as their domain and this was used during the Samba installation process, then the public facing website would no longer be acceptable (assuming the publicly accessible website was not running on the DC, which it shouldn't!) It would be wise to define a subdomain for your Domain Controller to reside in. In this tutorial <code>SAMDOM.EXAMPLE.COM</code> is used, however in a lab environment it is not necessary to own a publicly accessible domain and <code>.INTERNAL</code> could hypothetically be used. The name will also be used as the AD Kerberos realm.<br />
: {{Imbox<br />
| type = important<br />
| text = Make sure that you provision the AD using a DNS domain that will not need to be changed. Samba does not support renaming the AD DNS zone and Kerberos realm. Do not use <code>.local</code> for the TLD, this is used by Avahi.<br />
}}<br />
: For additional information, see [[Active_Directory_Naming_FAQ|Active Directory Naming FAQ]].<br />
<br />
* Select a host name for your AD DC which consists of less than 15 characters (netbios limitation.) A fantastic hostname is <code>DC1</code><br />
: Do not use NT4-only terms as host name, such as <code>PDC</code> or <code>BDC</code>. These modes do not exist in an AD and cause confusion.<br />
<br />
* A static IP address on the DC and make the associated reservation on your router. '''Important:''' The Samba domain controller will become your DNS resolver for all domain-joined workstations. As a result it may be required to assign this IP address outside of your DHCP pool<br />
<br />
* Disable tools, such as <code>resolvconf</code>, that automatically update your <code>/etc/resolv.conf</code> DNS resolver configuration file. AD DCs and domain members must use an DNS server that is able to resolve the AD DNS zones. (More information on this on the [[Distribution-specific_Package_Installation| Distribution Specific Package Installation]] page)<br />
<br />
* Verify that the <code>/etc/hosts</code> file on the DC correctly resolves the fully-qualified domain name (FQDN) and short host name to the LAN IP address of the DC. For example:<br />
127.0.0.1 localhost<br />
10.99.0.1 DC1.samdom.example.com DC1<br />
:The host name and FQDN must not resolve to the <code>127.0.0.1</code> IP address or any other IP address than the one used on the LAN interface of the DC.<br />
<br />
* Remove any existing <code>smb.conf</code> file. To list the path to the file:<br />
<br />
# smbd -b | grep "CONFIGFILE"<br />
CONFIGFILE: /usr/local/samba/etc/samba/smb.conf<br />
<br />
<br />
==== Only Applicable if Samba was Previously Installed ====<br />
* If you previously ran a Samba installation on this host:<br />
:<br />
<br />
:* Remove all Samba database files, such as <code>*.tdb</code> and <code>*.ldb</code> files. To list the folders containing Samba databases:<br />
<br />
# smbd -b | egrep "LOCKDIR|STATEDIR|CACHEDIR|PRIVATE_DIR"<br />
LOCKDIR: /usr/local/samba/var/lock/<br />
STATEDIR: /usr/local/samba/var/locks/<br />
CACHEDIR: /usr/local/samba/var/cache/<br />
PRIVATE_DIR: /usr/local/samba/private/<br />
<br />
: Starting with a clean environment helps to prevent confusion and ensures that no files from any previous Samba installation will be mixed with your new domain DC installation.<br />
<br />
<br />
= Installing Samba =<br />
<br />
<br />
{{:Installing_Samba}}<br />
<br />
<br />
<br />
= Provisioning a Samba Active Directory =<br />
<br />
{{Imbox<br />
| type = note<br />
| text = The AD provisioning requires root permissions to create files and set permissions.<br />
}}<br />
<br />
The Samba AD provisioning process creates the AD databases and adds initial records, such as the domain administrator account and required DNS entries. Samba comes with a built in command lined tool called <code>samba-tool</code> which can be used to automatically configure your <code>smb.conf</code> when ran in interactive mode. <br />
<br />
If you are migrating a Samba NT4 domain to AD, skip this step and run the Samba classic upgrade. For details, see [[Migrating_a_Samba_NT4_Domain_to_Samba_AD_(Classic_Upgrade)|Migrating a Samba NT4 Domain to Samba AD (Classic Upgrade)]].<br />
<br />
<br />
The <code>samba-tool domain provision</code> command provides several parameters to use with the interactive and non-interactive setup. For details, see:<br />
<br />
# samba-tool domain provision --help<br />
<br />
<br />
{{Imbox<br />
| type = note<br />
| text = When provisioning a new AD, it is recommended to enable the NIS extensions by passing the <code>--use-rfc2307</code> parameter to the <code>samba-tool domain provision</code> command. There are no disadvantages to enabling the NIS extensions, but enabling them in an existing domain requires manually extending the AD schema. For further details about Unix attributes in AD, see:<br />
* [[Setting_up_RFC2307_in_AD|Setting up RFC2307 in AD]]<br />
* [[Idmap_config_ad|idmap config = ad]]<br />
}}<br />
<br />
<br />
<br />
==== Parameter Reference ====<br />
<br />
Set the following parameters during the provisioning:<br />
<br />
{| class="wikitable"<br />
!Interactive Mode Setting<br />
!Non-interactive Mode Parameter<br />
!Explanation<br />
|-<br />
|<code>--use-rfc2307</code><br />
|<code>--use-rfc2307</code><br />
|Enables the NIS extensions required for the ADUC Unix Attributes tab.<br />
|-<br />
|<code>Realm</code><br />
|<code>--realm</code><br />
|Kerberos realm. The uppercase version of the AD DNS domain. For example: <code>SAMDOM.EXAMPLE.COM</code>.<br />
|-<br />
|<code>Domain</code><br />
|<code>--domain</code><br />
|NetBIOS domain name (Workgroup). This can be anything, but it must be one word, not longer than 15 characters and not containing a dot. It is recommended to use the first part of the AD DNS domain. For example: <code>samdom</code>. Do not use the computers short hostname.<br />
|-<br />
|<code>Server Role</code><br />
|<code>--server-role</code><br />
|Installs the domain controller <code>DC</code> role.<br />
|-<br />
|<code>DNS backend</code><br />
|<code>--dns-backend</code><br />
|Sets the DNS back end. The first DC in an AD must be installed using a DNS back end. Note that the <code>BIND9_FLATFILE</code> is not supported and will be removed in a future Samba version.<br />
|-<br />
|<code>DNS forwarder IP address</code><br />
|not available<br />
|This setting is only available when using the <code>SAMBA_INTERNAL</code> DNS back end. For details, see [[Samba_Internal_DNS_Back_End#Setting_up_a_DNS_Forwarder|Setting up a DNS Forwarder]].<br />
|-<br />
|<code>Administrator password</code><br />
|<code>--adminpass</code><br />
|Sets the domain administrator password. If the password does not match the complexity requirements, the provisioning fails. For details, see [https://technet.microsoft.com/en-us/library/cc786468%28v=ws.10%29.aspx Microsoft TechNet: Passwords must meet complexity requirements].<br />
|}<br />
<br />
Other parameters frequently used with the <code>samba-tool domain provision</code> command:<br />
* <code>--option="interfaces=lo eth0" --option="bind interfaces only=yes"</code>: If your server has multiple network interfaces, use these options to bind Samba to the specified interfaces. This enables the <code>samba-tool</code> command to register the correct LAN IP address in the directory during the join.<br />
<br />
<br />
{{Imbox<br />
| type = important<br />
| text = do NOT use <code>NONE</code> as the DNS backend, it is not supported and will be removed in a future Samba version.<br />
}}<br />
<br />
{{Imbox<br />
| type = important<br />
| text = If using Bind as the DNS backend, do NOT use <code>BIND9_FLATFILE</code>, it is not supported and will be removed in a future Samba version.<br />
}}<br />
<br />
{{Imbox<br />
| type = important<br />
| text = Once you have provisioned the first DC in an AD domain, do not provision any further DCs in the same domain, [[Joining_a_Samba_DC_to_an_Existing_Active_Directory|Join]] any further DCs.<br />
}}<br />
<br />
<br />
<br />
== Provisioning Samba AD in Interactive Mode ==<br />
<br />
As mentioned above, <code>samba-tool</code> when ran as route will automatically configure your <code>smb.conf</code> to build a domain controller. Interactive Mode will not automatically enable Group Policy support. However this can be added in afterwards by manually editing the <code>smb.conf</code> to add it in later. Open the [[Group_Policy#Winbind|Group Policy]] page in a new tab for later reading<br />
{{Imbox<br />
| type = warning<br />
| text = The installation of Samba will create a <code>smb.conf</code> file that must be discarded prior to running the Provisioning Tool in Interactive mode, or else it will fail. On most Linux distributions this can be done by running:<br />
# mv /etc/samba/smb.conf /etc/samba/smb.conf.initial<br />
}}<br />
<br />
With the existing <code>smb.conf</code> file removed, provision a Samba AD interactively by running run:<br />
<br />
# samba-tool domain provision --use-rfc2307 --interactive<br />
Realm [SAMDOM.EXAMPLE.COM]: SAMDOM.EXAMPLE.COM<br />
Domain [SAMDOM]: SAMDOM<br />
Server Role (dc, member, standalone) [dc]: dc<br />
DNS backend (SAMBA_INTERNAL, BIND9_FLATFILE, BIND9_DLZ, NONE) [SAMBA_INTERNAL]: SAMBA_INTERNAL<br />
DNS forwarder IP address (write 'none' to disable forwarding) [10.99.0.1]: 8.8.8.8<br />
Administrator password: Passw0rd<br />
Retype password: Passw0rd<br />
Looking up IPv4 addresses<br />
Looking up IPv6 addresses<br />
No IPv6 address will be assigned<br />
Setting up share.ldb<br />
Setting up secrets.ldb<br />
Setting up the registry<br />
Setting up the privileges database<br />
Setting up idmap db<br />
Setting up SAM db<br />
Setting up sam.ldb partitions and settings<br />
Setting up sam.ldb rootDSE<br />
Pre-loading the Samba 4 and AD schema<br />
Adding DomainDN: DC=samdom,DC=example,DC=com<br />
Adding configuration container<br />
Setting up sam.ldb schema<br />
Setting up sam.ldb configuration data<br />
Setting up display specifiers<br />
Modifying display specifiers<br />
Adding users container <br />
Modifying users container <br />
Adding computers container <br />
Modifying computers container <br />
Setting up sam.ldb data <br />
Setting up well known security principals <br />
Setting up sam.ldb users and groups <br />
Setting up self join <br />
Adding DNS accounts <br />
Creating CN=MicrosoftDNS,CN=System,DC=samdom,DC=example,DC=com <br />
Creating DomainDnsZones and ForestDnsZones partitions <br />
Populating DomainDnsZones and ForestDnsZones partitions <br />
Setting up sam.ldb rootDSE marking as synchronized <br />
Fixing provision GUIDs <br />
A Kerberos configuration suitable for Samba 4 has been generated at /usr/local/samba/private/krb5.conf <br />
Setting up fake yp server settings <br />
Once the above files are installed, your Samba4 server will be ready to use <br />
Server Role: active directory domain controller <br />
Hostname: DC1 <br />
NetBIOS Domain: SAMDOM <br />
DNS Domain: samdom.example.com <br />
DOMAIN SID: S-1-5-21-2614513918-2685075268-614796884<br />
<br />
{{Imbox<br />
| type = note<br />
| text = The interactive provisioning mode supports passing further parameters to the <code>samba-tool domain provision</code> command. This enables you to modify parameters that are not part of the interactive setup.<br />
}}<br />
<br />
<br />
<br />
== Provisioning Samba AD in Non-interactive Mode ==<br />
<br />
For example, to provision a Samba AD non-interactively with the following settings:<br />
* Server role: <code>dc</code><br />
* NIS extensions enabled<br />
* Internal DNS back end<br />
* Kerberos realm and AD DNS zone: <code>samdom.example.com</code><br />
* NetBIOS domain name: <code>SAMDOM</code><br />
* Domain administrator password: <code>Passw0rd</code><br />
<br />
# samba-tool domain provision --server-role=dc --use-rfc2307 --dns-backend=SAMBA_INTERNAL --realm=SAMDOM.EXAMPLE.COM --domain=SAMDOM --adminpass=Passw0rd<br />
<br />
<br />
<br />
<br />
<br />
= Setting up the AD DNS back end =<br />
<br />
Skip this step if you provisioned the DC using the <code>SAMBA_INTERNAL</code> DNS back end.<br />
<br />
* Set up the BIND DNS server and the <code>BIND9_DLZ</code> module. For details, see [[Setting_up_a_BIND_DNS_Server|Setting up a BIND DNS Server]].<br />
<br />
* Start the BIND DNS server. For example:<br />
# systemctl start named<br />
: For details how to start services, see you distribution's documentation.<br />
<br />
<br />
<br />
<br />
= Configuring the DNS Resolver =<br />
<br />
Domain members in an AD use DNS to locate services, such as LDAP and Kerberos. For that, they need to use a DNS server that is able to resolve the AD DNS zone.<br />
<br />
On your DC, set the AD DNS domain in the <code>search</code> and the IP of your DC in the <code>nameserver</code> parameter of the <code>/etc/resolv.conf</code> file. For example:<br />
<br />
search samdom.example.com<br />
nameserver 10.99.0.1<br />
<br />
<br />
<br />
<br />
<br />
= Create a reverse zone =<br />
<br />
You can optionally add a reverse lookup zone.<br />
<br />
# samba-tool dns zonecreate <Your-AD-DNS-Server-IP-or-hostname> 0.99.10.in-addr.arpa -U Administrator<br />
Password for [administrator@SAMDOM.EXAMPLE.COM]:<br />
Zone 0.99.10.in-addr.arpa created successfully<br />
<br />
If you need more than one reverse zone (multiple subnets), just run the above command again but with the data for the other subnet.<br />
<br />
The reverse zone is directly live without restarting Samba or BIND.<br />
<br />
{{Imbox<br />
| type = note<br />
| text = You must start the Samba AD DC before you can add a reverse zone.<br />
}}<br />
<br />
<br />
Now that you have created a reversezone, it would be a good time to create the <code>PTR</code> (reverse) dns record for the new DC.<br />
<br />
For a DC with the FQDN of <code>dc1.samdom.example.com</code> and the ipaddress of <code>10.99.0.1</code>, to add a record to the <code>0.99.10.in-addr.arpa</code>, you would run a command like this:<br />
<br />
# samba-tool dns add <Your-AD-DNS-Server-IP-or-hostname> 0.99.10.in-addr.arpa 1 PTR dc1.samdom.example.com -U Administrator<br />
Password for [administrator@SAMDOM.EXAMPLE.COM]:<br />
Record added successfully<br />
<br />
<br />
<br />
<br />
<br />
= Configuring Kerberos =<br />
<br />
In an AD, Kerberos is used to authenticate users, machines, and services.<br />
<br />
During the provisioning, Samba created a Kerberos configuration file for your DC. Copy this file to your operating system's Kerberos configuration. For example:<br />
<br />
# cp /usr/local/samba/private/krb5.conf /etc/krb5.conf<br />
<br />
{{Imbox<br />
| type = important<br />
| text = Do not create a symbolic link to the the generated <code>krb5.conf</code> file. In Samba 4.7 and later, the <code>/usr/local/samba/private/</code> directory is no longer accessible by other users than the <code>root</code> user. If the file is a symbolic link, other users are not able to read the file and, for example, dynamic DNS updates fail if you use the <code>BIND_DLZ</code> DNS back end.<br />
}}<br />
<br />
The pre-created Kerberos configuration uses DNS service (SRV) resource records to locate the KDC.<br />
<br />
<br />
<br />
<br />
<br />
= Testing your Samba AD DC =<br />
<br />
To start the <code>samba</code> service manually, enter:<br />
<br />
# samba<br />
<br />
Samba does not provide System V init scripts, <code>systemd</code>, <code>upstart</code>, or other services configuration files.<br />
* If you installed Samba using packages, use the script or service configuration file included in the package to start Samba.<br />
* If you built Samba, see [[Managing_the_Samba_AD_DC_Service|Managing the Samba AD DC Service]].<br />
<br />
<br />
<br />
== Verifying the File Server (Optional)==<br />
<br />
To list all shares provided by the DC:<br />
<br />
Before Samba 4.11.0:<br />
<br />
$ smbclient -L localhost -N<br />
Anonymous login successful<br />
Domain=[SAMDOM] OS=[Unix] Server=[Samba x.y.z]<br />
<br />
Sharename Type Comment<br />
--------- ---- -------<br />
netlogon Disk <br />
sysvol Disk <br />
IPC$ IPC IPC Service (Samba x.y.z)<br />
Domain=[SAMDOM] OS=[Unix] Server=[Samba x.y.z]<br />
<br />
Server Comment<br />
--------- -------<br />
<br />
Workgroup Master<br />
--------- -------<br />
<br />
From Samba 4.11.0:<br />
<br />
smbclient -L localhost -N<br />
Anonymous login successful<br />
<br />
Sharename Type Comment<br />
--------- ---- -------<br />
sysvol Disk <br />
netlogon Disk <br />
IPC$ IPC IPC Service (Samba 4.12.6-Debian)<br />
SMB1 disabled -- no workgroup available<br />
<br />
<br />
{{Imbox<br />
| type = note<br />
| text = The <code>netlogon</code> and <code>sysvol</code> shares were auto-created during the provisioning and must exist on a DC.<br />
}}<br />
<br />
To verify authentication, connect to the <code>netlogon</code> share using the domain administrator account:<br />
<br />
$ smbclient //localhost/netlogon -UAdministrator -c 'ls'<br />
Enter Administrator's password: <br />
Domain=[SAMDOM] OS=[Unix] Server=[Samba x.y.z]<br />
. D 0 Tue Nov 1 08:40:00 2016<br />
.. D 0 Tue Nov 1 08:40:00 2016<br />
<br />
49386 blocks of size 524288. 42093 blocks available<br />
<br />
If one or more tests fail, see [[#Troubleshooting|Troubleshooting]].<br />
<br />
<br />
<br />
== Verifying DNS (Optional)==<br />
<br />
To verify that your AD DNS configuration works correctly, query some DNS records:<br />
<br />
* The tcp-based <code>_ldap</code> SRV record in the domain:<br />
<br />
$ host -t SRV _ldap._tcp.samdom.example.com.<br />
_ldap._tcp.samdom.example.com has SRV record 0 100 389 dc1.samdom.example.com.<br />
<br />
* The udp-based <code>_kerberos</code> SRV resource record in the domain:<br />
<br />
$ host -t SRV _kerberos._udp.samdom.example.com.<br />
_kerberos._udp.samdom.example.com has SRV record 0 100 88 dc1.samdom.example.com.<br />
<br />
* The A record of the domain controller:<br />
<br />
$ host -t A dc1.samdom.example.com.<br />
dc1.samdom.example.com has address 10.99.0.1<br />
<br />
* If you have created a reverse zone, the PTR record of the domain controller:<br />
<br />
$ host -t PTR 10.99.0.1<br />
1.0.99.10.in-addr.arpa domain name pointer dc1.samdom.example.com.<br />
<br />
If one or more tests fail, see [[#Troubleshooting|Troubleshooting]].<br />
<br />
<br />
<br />
== Verifying Kerberos (Optional) ==<br />
<br />
This is not explicitly required, but it is a good idea to verify that your Domain Controller's authentication mechanisms are operating as intended. To test this, login by requesting a Kerberos ticket for the Domain Administrator account:<br />
<br />
$ kinit administrator<br />
Password for administrator@SAMDOM.EXAMPLE.COM:<br />
<br />
: {{Imbox<br />
| type = note<br />
| text = If you do not pass the principal in the <code>user@REALM</code> format to the <code>kinit</code> command, the Kerberos realm is automatically appended.<br />Always enter the Kerberos realm in uppercase.<br />
}}<br />
<br />
* List the cached Kerberos tickets:<br />
<br />
$ klist<br />
Ticket cache: FILE:/tmp/krb5cc_0<br />
Default principal: administrator@SAMDOM.EXAMPLE.COM<br />
<br />
Valid starting Expires Service principal<br />
01.11.2016 08:45:00 12.11.2016 18:45:00 krbtgt/SAMDOM.EXAMPLE.COM@SAMDOM.EXAMPLE.COM<br />
renew until 02.11.2016 08:44:59<br />
<br />
If one or more tests fail, see [[#Troubleshooting|Troubleshooting]].<br />
<br />
<br />
<br />
<br />
<br />
= Configuring Time Synchronization (Optional Depending on Use-Case)=<br />
<br />
Kerberos requires synchronized time on all domain members. For further details and how to set up the <code>ntpd</code> or <code>chrony</code> service, see [[Time_Synchronisation|Time Synchronization]]. However if Samba is being used as a domain controller to administer Group Policy, it is possible to define a Group Policy Object that synchronizes workstations with <code>time.windows.com</code> post installation which simplifies this<br />
<br />
<br />
<br />
= Using the Domain Controller as a File Server (Optional) =<br />
<br />
{{Imbox<br />
| type = warning<br />
| text = Do not use an AD DC as a fileserver if you have multiple DC's. You should only use a DC as a fileserver, if it is the only Samba instance running in a domain. If you have multiple DC's, you should also set up Unix domain members and use them as fileservers. You should be aware that it is problematic to use a DC as a fileserver and can cause strange errors.<br />
}}<br />
<br />
<br />
Whilst the Samba AD DC is able to provide file shares, just like all other installation modes, the Samba team does not recommend using a DC as a file server for the following reasons:<br />
<br />
* For anything but the smallest organizations, having more than one DC is a really good backup measure, and makes upgrades safer<br />
* It encourages upgrades of the DC to also be upgrades of the host OS every year or two, because there isn't complex data to transition or other services involved. <br />
* This means upgrades can be done by installing fresh, and replicating in the changes, which is better tested in Samba, gains new features and avoids a number of lingering data corruption risks. <br />
* The DC and file-server have different points at which an organization would wish to upgrade. The needs for new features on the DC and file server come at different times. Currently the AD DC is evolving rapidly to gain features, whereas the fileserver, after over 20 years, is quite rightly more conservative.<br />
* mandatory smb signing is enforced on the DC.<br />
<br />
<br />
If you do decide to use the Samba DC as a fileserver, please consider running a VM, on the DC, containing a separate Samba Unix domain member and use this instead.<br />
<br />
If you must use the Samba DC as a fileserver, you should be aware that the auto-enabled <code>acl_xattr</code> virtual file system (VFS) object enables you to only configure shares with Windows access control lists (ACL). Using POSIX ACLs with shares on a Samba DC does not work. <br />
<br />
You should be aware that if wish to use a vfs object on a DC share e.g. recycle, you must not just set <code>vfs objects = recycle</code> in the share. Doing this will turn off the default vfs objects <code>dfs_samba4</code> and <code>acl_xattr</code>. You must set <code>vfs objects = dfs_samba4 acl_xattr recycle</code>. <br />
<br />
To provide network shares with the full capabilities of Samba, set up a Samba domain member with file shares. For details, see:<br />
* [[Setting_up_Samba_as_a_Domain_Member|Setting up Samba as a Domain Member]]<br />
* [[Samba_File_Serving|Samba File Serving]]<br />
<br />
<br />
If you only have a small domain (small office, home network) and do not want to follow the Samba team's recommendation and use the DC additionally as a file server, configure Winbindd before you start setting up shares. For details, see [[Configuring_Winbindd_on_a_Samba_AD_DC|Configuring Winbindd on a Samba AD DC]].<br />
<br />
<br />
{{Imbox<br />
| type = warning<br />
| text = If you do use an AD DC as a fileserver, you must be aware that it can be problematic and can cause strange errors.<br />
}}<br />
<br />
{{Imbox<br />
| type = warning<br />
| text = If you do use an AD DC as a fileserver, do not add any of the 'idmap config' lines used on a Unix domain member. They will not work and will cause problems.<br />
}}<br />
<br />
{{Imbox<br />
| type = warning<br />
| text = If you do use an AD DC as a fileserver, You must set the permissions from Windows, do not attempt to use any of the old methods (force user etc) . They will not work correctly and will cause problems.<br />
}}<br />
<br />
<br />
<br />
<br />
<br />
= Troubleshooting =<br />
<br />
For further details, see [[Samba_AD_DC_Troubleshooting|Samba AD DC Troubleshooting]].<br />
<br />
<br />
<br />
<br />
<br />
= Further Samba-related Documentation =<br />
<br />
See [[User_Documentation|User Documentation]].<br />
<br />
<br />
<br />
<br />
<br />
----<br />
[[Category:Domain Control]]<br />
[[Category:Active Directory]]</div>Hortimechhttps://wiki.samba.org/index.php?title=Setting_up_Samba_as_an_Active_Directory_Domain_Controller&diff=18877Setting up Samba as an Active Directory Domain Controller2023-04-21T17:24:04Z<p>Hortimech: </p>
<hr />
<div>= Introduction =<br />
<br />
Starting from version 4.0 (released in 2012,) Samba is able to serve as an Active Directory (AD) domain controller (DC). Samba can operates at a forest functional level of '''Windows Server 2008 R2''' which is more that sufficient to manage sophisticated enterprises that use Windows 10/11 with strict compliance requirements (including NIST 800-171.)<br />
<br />
If you are installing Samba in a production environment, it is recommended to run two or more DCs for failover reasons, more detail on the provisioning of a failover DC can be found elsewhere on the wiki. This documentation describes how to set up Samba as the first DC to build a new AD forest. Additionally, use this documentation if you are migrating a Samba NT4 domain to Samba AD. To join Samba as an additional DC to an existing AD forest, see [[Joining_a_Samba_DC_to_an_Existing_Active_Directory|Joining a Samba DC to an Existing Active Directory]]. <br />
<br />
Samba as an AD DC only supports:<br />
* The integrated LDAP server as AD back end. For details, see the frequently asked question (FAQ) [[FAQ#Does_Samba_AD_DCs_Support_OpenLDAP_or_Other_LDAP_Servers_as_Back_End.3F|Does Samba AD DCs Support OpenLDAP or Other LDAP Servers as Back End?]]<br />
* The [http://www.h5l.se/ Heimdal] Kerberos Key Distribution Center (KDC).<br />
: Samba provides experimental support for the [https://web.mit.edu/kerberos/ MIT Kerberos] KDC provided by your operating system if you run Samba 4.7 or later and has been built using the <code>--with-system-mitkrb5</code> option. In other cases Samba uses the Heimdal KDC included in Samba. For further details about Samba using the MIT KDC, and why it is experimental see [[Running a Samba AD DC with MIT Kerberos KDC]].<br />
* Hosting and Administering of Group Policy Objects to be used for enterprise fleet management<br />
: {{Imbox<br />
| type = important<br />
| text = Installation of Samba and associated provisioning of a domain controller does not automatically translate into Group Policy functionality. Please keep this in mind, and expect to update this flag in the <code>smb.conf</code> post provisioning<br />
}}<br />
<br />
This tutorial assumes that this is a fresh installation of Samba on a fresh operating system installation. It is important to note that there is a distinction between installing of Samba and Provisioning of Samba. In general, the entire process of setting up a Samba domain controller consists of 5 steps which are relatively straight forward. These steps are as follows:<br />
<br />
# Installation of Samba and associated packages<br />
# Deletion of per-configured Samba and Kerberos placeholder configuration files<br />
# Provisioning of Samba using the automatic provisioning tool<br />
# Editing of the <code>smb.conf</code> as needed (enabling of Group Policy and/or other features as needed) see [[Group_Policy|Group Policy]] for more information<br />
# Any environmental configuration based on Unix/Linux Distribution<br />
<br />
This page covers a lot of ground for Samba installations on both Unix and Linux systems. The installation process varies slightly based on environment, so expect to follow the linked web pages in multiple tabs throughout this read. For the remainder of this tutorial the following example information is used:<br />
<br />
* Hostname = <code>DC1</code><br />
* DC local IP Address = <code>10.99.0.1</code><br />
* Authentication Domain = <code>SAMDOM.EXAMPLE.COM</code><br />
* Top level Domain = <code>EXAMPLE.COM</code><br />
<br />
<br />
<br />
= Preparing the Installation =<br />
<br />
==== Fresh Installation ====<br />
<br />
<br />
* Select a DNS domain for your AD forest. It is not recommended to use the top level domain for your organization. This is because the domain used during the installation of Samba will resolve to the domain controller. For Example: If your organization used <code>EXAMPLE.COM</code> as their domain and this was used during the Samba installation process, then the public facing website would no longer be acceptable (assuming the publicly accessible website was not running on the DC, which it shouldn't!) It would be wise to define a subdomain for your Domain Controller to reside in. In this tutorial <code>SAMDOM.EXAMPLE.COM</code> is used, however in a lab environment it is not necessary to own a publicly accessible domain and <code>.INTERNAL</code> could hypothetically be used. The name will also be used as the AD Kerberos realm.<br />
: {{Imbox<br />
| type = important<br />
| text = Make sure that you provision the AD using a DNS domain that will not need to be changed. Samba does not support renaming the AD DNS zone and Kerberos realm. Do not use <code>.local</code> for the TLD, this is used by Avahi.<br />
}}<br />
: For additional information, see [[Active_Directory_Naming_FAQ|Active Directory Naming FAQ]].<br />
<br />
* Select a host name for your AD DC which consists of less than 15 characters (netbios limitation.) A fantastic hostname is <code>DC1</code><br />
: Do not use NT4-only terms as host name, such as <code>PDC</code> or <code>BDC</code>. These modes do not exist in an AD and cause confusion.<br />
<br />
* A static IP address on the DC and make the associated reservation on your router. '''Important:''' The Samba domain controller will become your DNS resolver for all domain-joined workstations. As a result it may be required to assign this IP address outside of your DHCP pool<br />
<br />
* Disable tools, such as <code>resolvconf</code>, that automatically update your <code>/etc/resolv.conf</code> DNS resolver configuration file. AD DCs and domain members must use an DNS server that is able to resolve the AD DNS zones. (More information on this on the [[Distribution-specific_Package_Installation| Distribution Specific Package Installation]] page)<br />
<br />
* Verify that the <code>/etc/hosts</code> file on the DC correctly resolves the fully-qualified domain name (FQDN) and short host name to the LAN IP address of the DC. For example:<br />
127.0.0.1 localhost<br />
10.99.0.1 DC1.samdom.example.com DC1<br />
:The host name and FQDN must not resolve to the <code>127.0.0.1</code> IP address or any other IP address than the one used on the LAN interface of the DC.<br />
<br />
* Remove any existing <code>smb.conf</code> file. To list the path to the file:<br />
<br />
# smbd -b | grep "CONFIGFILE"<br />
CONFIGFILE: /usr/local/samba/etc/samba/smb.conf<br />
<br />
<br />
==== Only Applicable if Samba was Previously Installed ====<br />
* If you previously ran a Samba installation on this host:<br />
:<br />
<br />
:* Remove all Samba database files, such as <code>*.tdb</code> and <code>*.ldb</code> files. To list the folders containing Samba databases:<br />
<br />
# smbd -b | egrep "LOCKDIR|STATEDIR|CACHEDIR|PRIVATE_DIR"<br />
LOCKDIR: /usr/local/samba/var/lock/<br />
STATEDIR: /usr/local/samba/var/locks/<br />
CACHEDIR: /usr/local/samba/var/cache/<br />
PRIVATE_DIR: /usr/local/samba/private/<br />
<br />
: Starting with a clean environment helps to prevent confusion and ensures that no files from any previous Samba installation will be mixed with your new domain DC installation.<br />
<br />
<br />
= Installing Samba =<br />
<br />
<br />
{{:Installing_Samba}}<br />
<br />
<br />
<br />
= Provisioning a Samba Active Directory =<br />
<br />
{{Imbox<br />
| type = note<br />
| text = The AD provisioning requires root permissions to create files and set permissions.<br />
}}<br />
<br />
The Samba AD provisioning process creates the AD databases and adds initial records, such as the domain administrator account and required DNS entries. Samba comes with a built in command lined tool called <code>samba-tool</code> which can be used to automatically configure your <code>smb.conf</code> when ran in interactive mode. <br />
<br />
If you are migrating a Samba NT4 domain to AD, skip this step and run the Samba classic upgrade. For details, see [[Migrating_a_Samba_NT4_Domain_to_Samba_AD_(Classic_Upgrade)|Migrating a Samba NT4 Domain to Samba AD (Classic Upgrade)]].<br />
<br />
<br />
The <code>samba-tool domain provision</code> command provides several parameters to use with the interactive and non-interactive setup. For details, see:<br />
<br />
# samba-tool domain provision --help<br />
<br />
<br />
{{Imbox<br />
| type = note<br />
| text = When provisioning a new AD, it is recommended to enable the NIS extensions by passing the <code>--use-rfc2307</code> parameter to the <code>samba-tool domain provision</code> command. There are no disadvantages to enabling the NIS extensions, but enabling them in an existing domain requires manually extending the AD schema. For further details about Unix attributes in AD, see:<br />
* [[Setting_up_RFC2307_in_AD|Setting up RFC2307 in AD]]<br />
* [[Idmap_config_ad|idmap config = ad]]<br />
}}<br />
<br />
<br />
<br />
==== Parameter Reference ====<br />
<br />
Set the following parameters during the provisioning:<br />
<br />
{| class="wikitable"<br />
!Interactive Mode Setting<br />
!Non-interactive Mode Parameter<br />
!Explanation<br />
|-<br />
|<code>--use-rfc2307</code><br />
|<code>--use-rfc2307</code><br />
|Enables the NIS extensions required for the ADUC Unix Attributes tab.<br />
|-<br />
|<code>Realm</code><br />
|<code>--realm</code><br />
|Kerberos realm. The uppercase version of the AD DNS domain. For example: <code>SAMDOM.EXAMPLE.COM</code>.<br />
|-<br />
|<code>Domain</code><br />
|<code>--domain</code><br />
|NetBIOS domain name (Workgroup). This can be anything, but it must be one word, not longer than 15 characters and not containing a dot. It is recommended to use the first part of the AD DNS domain. For example: <code>samdom</code>. Do not use the computers short hostname.<br />
|-<br />
|<code>Server Role</code><br />
|<code>--server-role</code><br />
|Installs the domain controller <code>DC</code> role.<br />
|-<br />
|<code>DNS backend</code><br />
|<code>--dns-backend</code><br />
|Sets the DNS back end. The first DC in an AD must be installed using a DNS back end. Note that the <code>BIND9_FLATFILE</code> is not supported and will be removed in a future Samba version.<br />
|-<br />
|<code>DNS forwarder IP address</code><br />
|not available<br />
|This setting is only available when using the <code>SAMBA_INTERNAL</code> DNS back end. For details, see [[Samba_Internal_DNS_Back_End#Setting_up_a_DNS_Forwarder|Setting up a DNS Forwarder]].<br />
|-<br />
|<code>Administrator password</code><br />
|<code>--adminpass</code><br />
|Sets the domain administrator password. If the password does not match the complexity requirements, the provisioning fails. For details, see [https://technet.microsoft.com/en-us/library/cc786468%28v=ws.10%29.aspx Microsoft TechNet: Passwords must meet complexity requirements].<br />
|}<br />
<br />
Other parameters frequently used with the <code>samba-tool domain provision</code> command:<br />
* <code>--option="interfaces=lo eth0" --option="bind interfaces only=yes"</code>: If your server has multiple network interfaces, use these options to bind Samba to the specified interfaces. This enables the <code>samba-tool</code> command to register the correct LAN IP address in the directory during the join.<br />
<br />
<br />
{{Imbox<br />
| type = important<br />
| text = do NOT use <code>NONE</code> as the DNS backend, it is not supported and will be removed in a future Samba version.<br />
}}<br />
<br />
{{Imbox<br />
| type = important<br />
| text = If using Bind as the DNS backend, do NOT use <code>BIND9_FLATFILE</code>, it is not supported and will be removed in a future Samba version.<br />
}}<br />
<br />
{{Imbox<br />
| type = important<br />
| text = Once you have provisioned the first DC in an AD domain, do not provision any further DCs in the same domain, [[Joining_a_Samba_DC_to_an_Existing_Active_Directory|Join]] any further DCs.<br />
}}<br />
<br />
<br />
<br />
== Provisioning Samba AD in Interactive Mode ==<br />
<br />
As mentioned above, <code>samba-tool</code> when ran as route will automatically configure your <code>smb.conf</code> to build a domain controller. Interactive Mode will not automatically enable Group Policy support. However this can be added in afterwards by manually editing the <code>smb.conf</code> to add it in later. Open the [[Group_Policy#Winbind|Group Policy]] page in a new tab for later reading<br />
{{Imbox<br />
| type = warning<br />
| text = The installation of Samba will create a <code>smb.conf</code> file that must be discarded prior to running the Provisioning Tool in Interactive mode, or else it will fail. On most Linux distributions this can be done by running:<br />
# mv /etc/samba/smb.conf /etc/samba/smb.conf.initial<br />
}}<br />
<br />
With the existing <code>smb.conf</code> file removed, provision a Samba AD interactively by running run:<br />
<br />
# samba-tool domain provision --use-rfc2307 --interactive<br />
Realm [SAMDOM.EXAMPLE.COM]: SAMDOM.EXAMPLE.COM<br />
Domain [SAMDOM]: SAMDOM<br />
Server Role (dc, member, standalone) [dc]: dc<br />
DNS backend (SAMBA_INTERNAL, BIND9_FLATFILE, BIND9_DLZ, NONE) [SAMBA_INTERNAL]: SAMBA_INTERNAL<br />
DNS forwarder IP address (write 'none' to disable forwarding) [10.99.0.1]: 8.8.8.8<br />
Administrator password: Passw0rd<br />
Retype password: Passw0rd<br />
Looking up IPv4 addresses<br />
Looking up IPv6 addresses<br />
No IPv6 address will be assigned<br />
Setting up share.ldb<br />
Setting up secrets.ldb<br />
Setting up the registry<br />
Setting up the privileges database<br />
Setting up idmap db<br />
Setting up SAM db<br />
Setting up sam.ldb partitions and settings<br />
Setting up sam.ldb rootDSE<br />
Pre-loading the Samba 4 and AD schema<br />
Adding DomainDN: DC=samdom,DC=example,DC=com<br />
Adding configuration container<br />
Setting up sam.ldb schema<br />
Setting up sam.ldb configuration data<br />
Setting up display specifiers<br />
Modifying display specifiers<br />
Adding users container <br />
Modifying users container <br />
Adding computers container <br />
Modifying computers container <br />
Setting up sam.ldb data <br />
Setting up well known security principals <br />
Setting up sam.ldb users and groups <br />
Setting up self join <br />
Adding DNS accounts <br />
Creating CN=MicrosoftDNS,CN=System,DC=samdom,DC=example,DC=com <br />
Creating DomainDnsZones and ForestDnsZones partitions <br />
Populating DomainDnsZones and ForestDnsZones partitions <br />
Setting up sam.ldb rootDSE marking as synchronized <br />
Fixing provision GUIDs <br />
A Kerberos configuration suitable for Samba 4 has been generated at /usr/local/samba/private/krb5.conf <br />
Setting up fake yp server settings <br />
Once the above files are installed, your Samba4 server will be ready to use <br />
Server Role: active directory domain controller <br />
Hostname: DC1 <br />
NetBIOS Domain: SAMDOM <br />
DNS Domain: samdom.example.com <br />
DOMAIN SID: S-1-5-21-2614513918-2685075268-614796884<br />
<br />
{{Imbox<br />
| type = note<br />
| text = The interactive provisioning mode supports passing further parameters to the <code>samba-tool domain provision</code> command. This enables you to modify parameters that are not part of the interactive setup.<br />
}}<br />
<br />
<br />
<br />
== Provisioning Samba AD in Non-interactive Mode ==<br />
<br />
For example, to provision a Samba AD non-interactively with the following settings:<br />
* Server role: <code>dc</code><br />
* NIS extensions enabled<br />
* Internal DNS back end<br />
* Kerberos realm and AD DNS zone: <code>samdom.example.com</code><br />
* NetBIOS domain name: <code>SAMDOM</code><br />
* Domain administrator password: <code>Passw0rd</code><br />
<br />
# samba-tool domain provision --server-role=dc --use-rfc2307 --dns-backend=SAMBA_INTERNAL --realm=SAMDOM.EXAMPLE.COM --domain=SAMDOM --adminpass=Passw0rd<br />
<br />
<br />
<br />
<br />
<br />
= Setting up the AD DNS back end =<br />
<br />
Skip this step if you provisioned the DC using the <code>SAMBA_INTERNAL</code> DNS back end.<br />
<br />
* Set up the BIND DNS server and the <code>BIND9_DLZ</code> module. For details, see [[Setting_up_a_BIND_DNS_Server|Setting up a BIND DNS Server]].<br />
<br />
* Start the BIND DNS server. For example:<br />
# systemctl start named<br />
: For details how to start services, see you distribution's documentation.<br />
<br />
<br />
<br />
<br />
= Configuring the DNS Resolver =<br />
<br />
Domain members in an AD use DNS to locate services, such as LDAP and Kerberos. For that, they need to use a DNS server that is able to resolve the AD DNS zone.<br />
<br />
On your DC, set the AD DNS domain in the <code>search</code> and the IP of your DC in the <code>nameserver</code> parameter of the <code>/etc/resolv.conf</code> file. For example:<br />
<br />
search samdom.example.com<br />
nameserver 10.99.0.1<br />
<br />
<br />
<br />
<br />
<br />
= Create a reverse zone =<br />
<br />
You can optionally add a reverse lookup zone.<br />
<br />
# samba-tool dns zonecreate <Your-AD-DNS-Server-IP-or-hostname> 0.99.10.in-addr.arpa -U Administrator<br />
Password for [administrator@SAMDOM.EXAMPLE.COM]:<br />
Zone 0.99.10.in-addr.arpa created successfully<br />
<br />
If you need more than one reverse zone (multiple subnets), just run the above command again but with the data for the other subnet.<br />
<br />
The reverse zone is directly live without restarting Samba or BIND.<br />
<br />
{{Imbox<br />
| type = note<br />
| text = You must start the Samba AD DC before you can add a reverse zone.<br />
}}<br />
<br />
<br />
Now that you have created a reversezone, it would be a good time to create the <code>PTR</code> (reverse) dns record for the new DC.<br />
<br />
For a DC with the FQDN of <code>dc1.samdom.example.com</code> and the ipaddress of <code>10.99.0.1</code>, to add a record to the <code>0.99.10.in-addr.arpa</code>, you would run a command like this:<br />
<br />
# samba-tool dns add <Your-AD-DNS-Server-IP-or-hostname> 0.99.10.in-addr.arpa 1 PTR dc1.samdom.example.com -U Administrator<br />
Password for [administrator@SAMDOM.EXAMPLE.COM]:<br />
Record added successfully<br />
<br />
<br />
<br />
<br />
<br />
= Configuring Kerberos =<br />
<br />
In an AD, Kerberos is used to authenticate users, machines, and services.<br />
<br />
During the provisioning, Samba created a Kerberos configuration file for your DC. Copy this file to your operating system's Kerberos configuration. For example:<br />
<br />
# cp /usr/local/samba/private/krb5.conf /etc/krb5.conf<br />
<br />
{{Imbox<br />
| type = important<br />
| text = Do not create a symbolic link to the the generated <code>krb5.conf</code> file. In Samba 4.7 and later, the <code>/usr/local/samba/private/</code> directory is no longer accessible by other users than the <code>root</code> user. If the file is a symbolic link, other users are not able to read the file and, for example, dynamic DNS updates fail if you use the <code>BIND_DLZ</code> DNS back end.<br />
}}<br />
<br />
The pre-created Kerberos configuration uses DNS service (SRV) resource records to locate the KDC.<br />
<br />
<br />
<br />
<br />
<br />
= Testing your Samba AD DC =<br />
<br />
To start the <code>samba</code> service manually, enter:<br />
<br />
# samba<br />
<br />
Samba does not provide System V init scripts, <code>systemd</code>, <code>upstart</code>, or other services configuration files.<br />
* If you installed Samba using packages, use the script or service configuration file included in the package to start Samba.<br />
* If you built Samba, see [[Managing_the_Samba_AD_DC_Service|Managing the Samba AD DC Service]].<br />
<br />
<br />
<br />
== Verifying the File Server (Optional)==<br />
<br />
To list all shares provided by the DC:<br />
<br />
Before Samba 4.11.0:<br />
<br />
$ smbclient -L localhost -N<br />
Anonymous login successful<br />
Domain=[SAMDOM] OS=[Unix] Server=[Samba x.y.z]<br />
<br />
Sharename Type Comment<br />
--------- ---- -------<br />
netlogon Disk <br />
sysvol Disk <br />
IPC$ IPC IPC Service (Samba x.y.z)<br />
Domain=[SAMDOM] OS=[Unix] Server=[Samba x.y.z]<br />
<br />
Server Comment<br />
--------- -------<br />
<br />
Workgroup Master<br />
--------- -------<br />
<br />
From Samba 4.11.0:<br />
<br />
smbclient -L localhost -N<br />
Anonymous login successful<br />
<br />
Sharename Type Comment<br />
--------- ---- -------<br />
sysvol Disk <br />
netlogon Disk <br />
IPC$ IPC IPC Service (Samba 4.12.6-Debian)<br />
SMB1 disabled -- no workgroup available<br />
<br />
<br />
{{Imbox<br />
| type = note<br />
| text = The <code>netlogon</code> and <code>sysvol</code> shares were auto-created during the provisioning and must exist on a DC.<br />
}}<br />
<br />
To verify authentication, connect to the <code>netlogon</code> share using the domain administrator account:<br />
<br />
$ smbclient //localhost/netlogon -UAdministrator -c 'ls'<br />
Enter Administrator's password: <br />
Domain=[SAMDOM] OS=[Unix] Server=[Samba x.y.z]<br />
. D 0 Tue Nov 1 08:40:00 2016<br />
.. D 0 Tue Nov 1 08:40:00 2016<br />
<br />
49386 blocks of size 524288. 42093 blocks available<br />
<br />
If one or more tests fail, see [[#Troubleshooting|Troubleshooting]].<br />
<br />
<br />
<br />
== Verifying DNS (Optional)==<br />
<br />
To verify that your AD DNS configuration works correctly, query some DNS records:<br />
<br />
* The tcp-based <code>_ldap</code> SRV record in the domain:<br />
<br />
$ host -t SRV _ldap._tcp.samdom.example.com.<br />
_ldap._tcp.samdom.example.com has SRV record 0 100 389 dc1.samdom.example.com.<br />
<br />
* The udp-based <code>_kerberos</code> SRV resource record in the domain:<br />
<br />
$ host -t SRV _kerberos._udp.samdom.example.com.<br />
_kerberos._udp.samdom.example.com has SRV record 0 100 88 dc1.samdom.example.com.<br />
<br />
* The A record of the domain controller:<br />
<br />
$ host -t A dc1.samdom.example.com.<br />
dc1.samdom.example.com has address 10.99.0.1<br />
<br />
If one or more tests fail, see [[#Troubleshooting|Troubleshooting]].<br />
<br />
<br />
<br />
== Verifying Kerberos (Optional) ==<br />
<br />
This is not explicitly required, but it is a good idea to verify that your Domain Controller's authentication mechanisms are operating as intended. To test this, login by requesting a Kerberos ticket for the Domain Administrator account:<br />
<br />
$ kinit administrator<br />
Password for administrator@SAMDOM.EXAMPLE.COM:<br />
<br />
: {{Imbox<br />
| type = note<br />
| text = If you do not pass the principal in the <code>user@REALM</code> format to the <code>kinit</code> command, the Kerberos realm is automatically appended.<br />Always enter the Kerberos realm in uppercase.<br />
}}<br />
<br />
* List the cached Kerberos tickets:<br />
<br />
$ klist<br />
Ticket cache: FILE:/tmp/krb5cc_0<br />
Default principal: administrator@SAMDOM.EXAMPLE.COM<br />
<br />
Valid starting Expires Service principal<br />
01.11.2016 08:45:00 12.11.2016 18:45:00 krbtgt/SAMDOM.EXAMPLE.COM@SAMDOM.EXAMPLE.COM<br />
renew until 02.11.2016 08:44:59<br />
<br />
If one or more tests fail, see [[#Troubleshooting|Troubleshooting]].<br />
<br />
<br />
<br />
<br />
<br />
= Configuring Time Synchronization (Optional Depending on Use-Case)=<br />
<br />
Kerberos requires synchronized time on all domain members. For further details and how to set up the <code>ntpd</code> or <code>chrony</code> service, see [[Time_Synchronisation|Time Synchronization]]. However if Samba is being used as a domain controller to administer Group Policy, it is possible to define a Group Policy Object that synchronizes workstations with <code>time.windows.com</code> post installation which simplifies this<br />
<br />
<br />
<br />
= Using the Domain Controller as a File Server (Optional) =<br />
<br />
{{Imbox<br />
| type = warning<br />
| text = Do not use an AD DC as a fileserver if you have multiple DC's. You should only use a DC as a fileserver, if it is the only Samba instance running in a domain. If you have multiple DC's, you should also set up Unix domain members and use them as fileservers. You should be aware that it is problematic to use a DC as a fileserver and can cause strange errors.<br />
}}<br />
<br />
<br />
Whilst the Samba AD DC is able to provide file shares, just like all other installation modes, the Samba team does not recommend using a DC as a file server for the following reasons:<br />
<br />
* For anything but the smallest organizations, having more than one DC is a really good backup measure, and makes upgrades safer<br />
* It encourages upgrades of the DC to also be upgrades of the host OS every year or two, because there isn't complex data to transition or other services involved. <br />
* This means upgrades can be done by installing fresh, and replicating in the changes, which is better tested in Samba, gains new features and avoids a number of lingering data corruption risks. <br />
* The DC and file-server have different points at which an organization would wish to upgrade. The needs for new features on the DC and file server come at different times. Currently the AD DC is evolving rapidly to gain features, whereas the fileserver, after over 20 years, is quite rightly more conservative.<br />
* mandatory smb signing is enforced on the DC.<br />
<br />
<br />
If you do decide to use the Samba DC as a fileserver, please consider running a VM, on the DC, containing a separate Samba Unix domain member and use this instead.<br />
<br />
If you must use the Samba DC as a fileserver, you should be aware that the auto-enabled <code>acl_xattr</code> virtual file system (VFS) object enables you to only configure shares with Windows access control lists (ACL). Using POSIX ACLs with shares on a Samba DC does not work. <br />
<br />
You should be aware that if wish to use a vfs object on a DC share e.g. recycle, you must not just set <code>vfs objects = recycle</code> in the share. Doing this will turn off the default vfs objects <code>dfs_samba4</code> and <code>acl_xattr</code>. You must set <code>vfs objects = dfs_samba4 acl_xattr recycle</code>. <br />
<br />
To provide network shares with the full capabilities of Samba, set up a Samba domain member with file shares. For details, see:<br />
* [[Setting_up_Samba_as_a_Domain_Member|Setting up Samba as a Domain Member]]<br />
* [[Samba_File_Serving|Samba File Serving]]<br />
<br />
<br />
If you only have a small domain (small office, home network) and do not want to follow the Samba team's recommendation and use the DC additionally as a file server, configure Winbindd before you start setting up shares. For details, see [[Configuring_Winbindd_on_a_Samba_AD_DC|Configuring Winbindd on a Samba AD DC]].<br />
<br />
<br />
{{Imbox<br />
| type = warning<br />
| text = If you do use an AD DC as a fileserver, you must be aware that it can be problematic and can cause strange errors.<br />
}}<br />
<br />
{{Imbox<br />
| type = warning<br />
| text = If you do use an AD DC as a fileserver, do not add any of the 'idmap config' lines used on a Unix domain member. They will not work and will cause problems.<br />
}}<br />
<br />
{{Imbox<br />
| type = warning<br />
| text = If you do use an AD DC as a fileserver, You must set the permissions from Windows, do not attempt to use any of the old methods (force user etc) . They will not work correctly and will cause problems.<br />
}}<br />
<br />
<br />
<br />
<br />
<br />
= Troubleshooting =<br />
<br />
For further details, see [[Samba_AD_DC_Troubleshooting|Samba AD DC Troubleshooting]].<br />
<br />
<br />
<br />
<br />
<br />
= Further Samba-related Documentation =<br />
<br />
See [[User_Documentation|User Documentation]].<br />
<br />
<br />
<br />
<br />
<br />
----<br />
[[Category:Domain Control]]<br />
[[Category:Active Directory]]</div>Hortimechhttps://wiki.samba.org/index.php?title=Setting_up_Samba_as_a_Domain_Member&diff=18875Setting up Samba as a Domain Member2023-04-20T11:30:29Z<p>Hortimech: </p>
<hr />
<div>= Introduction =<br />
<br />
A Samba domain member is a Linux machine joined to a domain that is running Samba and does not provide domain services, such as an NT4 primary domain controller (PDC) or Active Directory (AD) domain controller (DC).<br />
<br />
On a Samba domain member, you can:<br />
<br />
* Use domain users and groups in local ACLs on files and directories.<br />
* Set up shares to act as a file server.<br />
* Set up printing services to act as a print server.<br />
* Configure PAM to enable domain users to log on locally or to authenticate to local installed services.<br />
<br />
For details about setting up a Samba NT4 domain or Samba AD, see [[Domain_Control|Domain Control]].<br />
<br />
<br />
{{Imbox<br />
| type = important<br />
| text = For versions of Samba earlier than 4.15.0, never use <code>samba-tool domain provision</code> to create a Unix domain member, it will not work, you must follow the procedure laid out on this page.<br />
}}<br />
<br />
{{Imbox<br />
| type = important<br />
| text = All AD Domain members must be in the same <code>DNS</code> domain and the Realm must be the <code>DNS</code> domain in uppercase. For example, the <code>DNS</code> domain could be <code>samdom.example.com</code> and the Realm would be <code>SAMDOM.EXAMPLE.COM</code>.<br />
}}<br />
<br />
<br />
<br />
= Preparing the Installation =<br />
<br />
== General Preparation ==<br />
<br />
* Verify that no Samba processes are running:<br />
# ps ax | egrep "samba|smbd|nmbd|winbindd"<br />
: If the output lists any <code>samba</code>, <code>smbd</code>, <code>nmbd</code>, or <code>winbindd</code> processes, shut down the processes.<br />
<br />
* If you previously run a Samba installation on this host:<br />
:* Backup the existing <code>smb.conf</code> file. To list the path to the file, enter:<br />
<br />
# smbd -b | grep "CONFIGFILE"<br />
CONFIGFILE: /usr/local/samba/etc/samba/smb.conf<br />
<br />
:* Remove all Samba database files, such as <code>*.tdb</code> and <code>*.ldb</code> files. To list the folders containing Samba databases:<br />
<br />
# smbd -b | egrep "LOCKDIR|STATEDIR|CACHEDIR|PRIVATE_DIR"<br />
LOCKDIR: /usr/local/samba/var/lock/<br />
STATEDIR: /usr/local/samba/var/locks/<br />
CACHEDIR: /usr/local/samba/var/cache/<br />
PRIVATE_DIR: /usr/local/samba/private/<br />
<br />
: Starting with a clean environment helps you to prevent confusion, and no files from your previous Samba installation are mixed with your new domain member installation.<br />
<br />
<br />
<br />
== Preparing a Domain Member to Join an Active Directory Domain ==<br />
<br />
=== Configuring DNS ===<br />
<br />
{{:Linux and Unix DNS Configuration}}<br />
<br />
<br />
<br />
<br />
<br />
=== Configuring Kerberos ===<br />
<br />
Samba supports Heimdal and MIT Kerberos back ends. To configure Kerberos on the domain member, set the following in your <code>/etc/krb5.conf</code> file:<br />
<br />
[libdefaults]<br />
default_realm = SAMDOM.EXAMPLE.COM<br />
dns_lookup_realm = false<br />
dns_lookup_kdc = true<br />
<br />
The previous example configures Kerberos for the <code>SAMDOM.EXAMPLE.COM</code> realm.<br />
<br />
The Samba teams recommends to no set any further parameters in the <code>/etc/krb5.conf</code> file.<br />
<br />
If your <code>/etc/krb5.conf</code> contains an <code>include</code> line it will not work, you '''Must''' remove this line.<br />
<br />
On some Linux distributions that use MIT Kerberos, it is necessary to add these lines for proper ID mapping:<br />
<br />
[plugins]<br />
localauth = {<br />
module = winbind:/usr/lib64/samba/krb5/winbind_krb5_localauth.so<br />
enable_only = winbind<br />
}<br />
<br />
These settings could also be necessary <code>/etc/security/pam_winbind.conf</code>:<br />
<br />
[global]<br />
krb5_auth = yes<br />
krb5_ccache_type = FILE<br />
<br />
With distributions with crypto-policies, this command must be issued to update the system policy support for Active Directory:<br />
<br />
<code>update-crypto-policies --set DEFAULT:AD-SUPPORT</code><br />
<br />
<br />
<br />
<br />
<br />
=== Configuring Time Synchronisation ===<br />
<br />
Kerberos requires a synchronised time on all domain members. Thus it is recommended to set up an NTP client. For further details, see [[Time_Synchronisation#Configuring_Time_Synchronisation_on_a_Unix_Domain_Member|Configuring Time Synchronisation on a Unix Domain Member]].<br />
<br />
<br />
<br />
<br />
<br />
=== Local Host Name Resolution ===<br />
<br />
When you join the host to the domain, Samba tries to register the host name in the AD DNS zone. For this, the <code>net</code> utility must be able to resolve the host name using DNS or using a correct entry in the <code>/etc/hosts</code> file.<br />
<br />
To verify that your host name resolves correctly, use the <code>getent hosts</code> command. For example:<br />
<br />
# getent hosts M1<br />
10.99.0.5 M1.samdom.example.com M1<br />
<br />
The host name and FQDN must not resolve to the <code>127.0.0.1</code> IP address or any other IP address other than the one used on the LAN interface of the domain member.<br />
<br />
If no output is displayed or the host is resolved to the wrong IP address and you are not using dhcp, set the correct entry in the <code>/etc/hosts</code> file. For example:<br />
<br />
127.0.0.1 localhost<br />
10.99.0.5 M1.samdom.example.com M1<br />
<br />
If you are using dhcp, check that <code>/etc/hosts</code> only contains the '127.0.0.1' line shown above. If you continue to have problems, contact the sysadmin who controls your DHCP server.<br />
<br />
if you need to add aliases to the machine hostname, add them to the end of the line that starts with the machines ipaddress, not the 127.0.0.1 line.<br />
<br />
<br />
<br />
<br />
== Preparing a Domain Member to Join an NT4 Domain ==<br />
<br />
For joining a host to an NT4 domain, no preparation is required.<br />
<br />
<br />
<br />
<br />
<br />
= Installing Samba =<br />
<br />
For details, see [[Installing_Samba|Installing Samba]].<br />
<br />
{{Imbox<br />
| type = note<br />
| text = Install a maintained Samba version. For details, see [[Samba_Release_Planning|Samba Release Planning]].<br />
}}<br />
<br />
<br />
<br />
<br />
<br />
= Configuring Samba =<br />
<br />
<br />
<br />
Samba can use various winbind idmap backends, The three main ones are:<br />
* ad<br />
* autorid<br />
* rid<br />
<br />
<br />
=== Choosing an idmap backend ===<br />
<br />
It can appear to be a complex decision choosing which winbind idmap backend to use, hopefully reading this can point you to the one to use.<br />
<br />
<br />
* If you require users and groups to have the same IDs everywhere, or have different login shells and Unix home directory paths, then you need to use the winbind idmap 'ad' backend and add RFC2307 attributes to AD.<br />
<br />
<br />
If you use the 'ad' backend, the RFC2307 attributes (uidNumber, gidNumber, etc) are not added automatically when users or groups are created, you must add them manually.<br />
<br />
The ID numbers found on a DC (numbers in the 3000000 range) are NOT rfc2307 attributes They cannot and will not be used on Unix Domain Members, you can add uidNumber & gidNumber attributes to AD and use the winbind 'ad' backend on Unix Domain Members. If you do decide to add uidNumber & gidNumber attributes to AD, you do not need to use numbers in the 3000000 range and it would definitely be a good idea to use a different range.<br />
<br />
<br />
* If you only need users and groups to have Unix IDs, you can use the 'rid' or 'autorid' idmap winbind backend.<br />
<br />
<br />
The 'rid' or 'autorid' idmap winbind backends calculate the user and group IDs from the Windows RID. If you use the 'rid' idmap backend and the same [global] section of the smb.conf on every Unix domain member, you will get the same IDs. Using these idmap backends, you do not add anything to AD and any added RFC2307 attributes will be ignored. When using these backends you can set the 'template shell' and 'template homedir' parameters in the smb.conf global section and everyone will get the login shell and Unix home directory path you set. If you do not set 'template shell' or 'template homedir', the defaults, '/bin/false' and '/home/%D/%U' , will be used.<br />
<br />
<br />
Once you Have decided which winbind idmap backend to use, you have to choose the ranges to use with 'idmap config' in smb.conf.<br />
<br />
By default on a Unix domain member, there are multiple blocks of users & groups:<br />
<br />
The local system users & groups: These will be from 0-999<br />
The local Unix users and groups: These start at 1000<br />
The SAMDOM domain users and groups: ADUC, by default, starts these at 10000<br />
The default domain '*' also known as the 'well Known SIDs': ????<br />
Trusted domains: ????<br />
Anything that isn't a 'well Known SID' or a member of SAMDOM or a trusted domain: ????<br />
<br />
<br />
As you can see from the above, if you are creating a new domain, you shouldn't set either the default domain '*' or the 'SAMDOM' ranges to start at 999 or less, as they would interfere with the local system users & groups. You also should leave a space for any local Unix users & groups, so starting the 'idmap config' ranges at 3000 seems to be a good compromise.<br />
<br />
Bearing the above information in mind, you could set the 'idmap config' ranges to the following:<br />
<br />
:{| class="wikitable"<br />
!Domain<br />
!Range<br />
|-<br />
|<code>*</code><br />
|'''3000-7999'''<br />
|-<br />
|<code>DOMAIN</code><br />
|'''10000-999999'''<br />
|}<br />
<br />
You could also have any trusted domains starting at:<br />
<br />
:{| class="wikitable"<br />
!Domain<br />
!Range<br />
|-<br />
|<code>TRUSTED</code><br />
|'''1000000-9999999'''<br />
|}<br />
<br />
If you set the default domain '*' range above the 'SAMDOM' domain range, the ranges will conflict if the domain grows to the point that the next ID would be the same as the default domain range start ID.<br />
<br />
With the above suggested ranges, no range will overlap or interfere with another.<br />
<br />
You may also have seen examples of the '*' range being used for everything, this should only be used with the 'autorid' idmap backend.<br />
<br />
<br />
== Setting up a Basic <code>smb.conf</code> File ==<br />
<br />
<br />
{{Imbox<br />
| type = warning<br />
| text = ID mapping back ends are not supported in the <code>smb.conf</code> file on a Samba Active Directory (AD) domain controller (DC).<br />Do not add any idmap config lines to a Samba Active Directory (AD) domain controller (DC) smb.conf<br />For details, see [[Updating_Samba#Updating_Samba#Failure_To_Access_Shares_on_Domain_Controllers_If_idmap_config_Parameters_Set_in_the_smb.conf_File|Failure to Access Shares on Domain Controllers If idmap config Parameters Set in the smb.conf File]].<br />
}}<br />
<br />
<br />
Before joining the domain, configure the domain member's <code>smb.conf</code> file:<br />
<br />
* To locate the file, enter:<br />
<br />
# smbd -b | grep CONFIGFILE<br />
CONFIGFILE: /etc/samba/smb.conf<br />
<br />
<br />
<br />
The following table lists the most important idmap backends with links to their documentation, click the relevant <code>Documentation</code> link for how to setup each idmap backend:<br />
<br />
:{| class="wikitable"<br />
!Back End<br />
!Documentation<br />
!Man Page<br />
|-<br />
|<code>rid</code><br />
|'''[[Idmap_config_rid|idmap config rid]]'''<br />
|<code>idmap_rid(8)</code><br />
|-<br />
|<code>autorid</code><br />
|'''[[Idmap_config_autorid|idmap config autorid]]'''<br />
|<code>idmap_autorid(8)</code><br />
|-<br />
|<code>ad</code><br />
|'''[[Idmap_config_ad|idmap config ad]]'''<br />
|<code>idmap_ad(8)</code><br />
|-<br />
|<code>hash</code><br />
|'''<Do not use>'''<br />
|<code>idmap_hash(8)</code><br />
|-<br />
|<code>ldap</code><br />
|<br />
|<code>idmap_ldap(8)</code><br />
|-<br />
|<code>nss</code><br />
|<br />
|<code>idmap_nss(8)</code><br />
|}<br />
<br />
:{{Imbox<br />
| type = important<br />
| text = Add an additional ID mapping configuration for every trusted domain, unless you use the <code>autorid</code> idmap backend (where this is optional). The ID ranges of the default (<code>*</code>) domain and other domains configured in the <code>smb.conf</code> file must not overlap.<br />
}}<br />
<br />
<br />
<br />
<br />
== Mapping the Domain Administrator Account to the Local <code>root</code> User ==<br />
<br />
Samba enables you to map domain accounts to a local account. Use this feature to execute file operations on the domain member's file system as a different user than the account that requested the operation on the client.<br />
<br />
{{Imbox<br />
| type = note<br />
| text = You should map the domain Administrator account to the local <code>root</code> account on a Unix domain member. Configuring the mapping allows the domain Administrator to execute file operations as <code>root</code> on the Unix domain member. When you map Administrator to the <code>root</code> account, you should not attempt to log onto a Unix domain member as Administrator. Only follow the method below to map <code>Administrator</code> to <code>root</code>.<br />
}}<br />
{{Imbox<br />
| type = note<br />
| text = If you have changed the domain Administrator account name, use the new admin name in the following instead of <code>Administrator</code>. <br />
}}<br />
<br />
<br />
To map the domain administrator to the local <code>root</code> account:<br />
<br />
* Add the following parameter to the <code>[global]</code> section of your <code>smb.conf</code> file:<br />
<br />
username map = /usr/local/samba/etc/user.map<br />
<br />
* Create the <code>/usr/local/samba/etc/user.map</code> file with the following content:<br />
<br />
!root = SAMDOM\Administrator<br />
<br />
:{{Imbox<br />
| type = important<br />
| text = When using the <code>ad</code> ID mapping back end, never set a <code>uidNumber</code> attribute for the domain Administrator account. If the account has the attribute set, the value will override the local UID <code>0</code> of the <code>root</code> user on Samba AD DC's and thus the mapping fails.<br />
}}<br />
<br />
For further details, see <code>username map</code> parameter in the <code>smb.conf(5)</code> man page.<br />
<br />
<br />
<br />
<br />
<br />
= Joining the Domain =<br />
<br />
* To join the host to an Active Directory (AD), enter:<br />
<br />
# net ads join -U administrator<br />
Enter administrator's password: Passw0rd<br />
Using short domain name -- SAMDOM<br />
Joined 'M1' to dns domain 'samdom.example.com'<br />
<br />
{{Imbox<br />
| type = note<br />
| text = When you join a computer to an AD domain with <code>net ads join</code>, the computers forward dns record should be created (if not already existing), but, if your computer has a fixed ipaddress, you will have to create the reverse PTR record yourself. <br />
}}<br />
<br />
<br />
* To join the host to an NT4 domain, enter:<br />
<br />
# net rpc join -U administrator<br />
Enter administrator's password: Passw0rd<br />
Joined domain SAMDOM.<br />
<br />
<br />
<br />
== Joining the Domain with samba-tool (>4.15.0 only) ==<br />
<br />
{{Imbox<br />
| type = important<br />
| text = Before Samba 4.15.0 , you could not join a Unix domain member using <code>samba-tool domain join</code>, this option was unsupported, did not work and would cause problems with your AD replication. You can only use <code>samba-tool domain join</code> if the Unix domain member has Samba >= 4.15.0 installed.<br />
}}<br />
<br />
* To join the host to an Active Directory (AD), enter:<br />
<br />
# samba-tool domain join samdom.example.com MEMBER -U administrator<br />
<br />
If you have problems joining the domain, check your configuration. For further help, see [[Troubleshooting_Samba_Domain_Members|Troubleshooting Samba Domain Members]].<br />
<br />
<br />
<br />
<br />
<br />
= Configuring the Name Service Switch =<br />
<br />
To enable the name service switch (NSS) library to make domain users and groups available to the local system:<br />
<br />
* Append the <code>winbind</code> entry to the following databases in the <code>/etc/nsswitch.conf</code> file:<br />
<br />
passwd: files <u>winbind</u><br />
group: files <u>winbind</u><br />
<br />
:* Keep the <code>files</code> entry as first source for both databases. This enables NSS to look up domain users and groups from the <code>/etc/passwd</code> and <code>/etc/group</code> files before querying the Winbind service.<br />
<br />
:* Do not add the <code>winbind</code> entry to the NSS <code>shadow</code> database. This can cause the <code>wbinfo</code> utility fail.<br />
<br />
:{{Imbox<br />
| type = note<br />
| text = If there's a line containing an <code>initgroups</code> directive, add <code> [success=continue] winbind</code>, otherwise the NSS library will not ask winbindd for a user's additional group memberships. Do not add the <code>initgroups</code> line if it does not exist.<br />
}}<br />
<br />
:{{Imbox<br />
| type = warning<br />
| text = Do not use the same user names in the local <code>/etc/passwd</code> file as in the domain.<br />
}}<br />
<br />
:{{Imbox<br />
| type = warning<br />
| text = Do not use local Unix names when changing file and directory ownership on Samba domain shares.<br />
}}<br />
<br />
:{{Imbox<br />
| type = note<br />
| text = If you compiled Samba, add symbolic links from the <code>libnss_winbind</code> library to the operating system's library path. For details, see [[Libnss_winbind_Links|libnss_winbind Links]]. If you used packages to install Samba, the link is usually created automatically.<br />
}}<br />
<br />
<br />
<br />
<br />
<br />
= Starting the Services =<br />
<br />
Start the following services to have a fully functioning Unix domain member:<br />
<br />
* The <code>smbd</code> service<br />
<br />
* The <code>nmbd</code> service<br />
<br />
* The <code>winbindd</code> service<br />
<br />
<br />
:{{Imbox<br />
| type = note<br />
| text = If you do not require Network Browsing, you do not need to start the <code>nmbd</code> service on a Unix domain member.<br />
}}<br />
<br />
<br />
:{{Imbox<br />
| type = important<br />
| text = The latest versions of Samba (from 4.11.0) now only use SMBv2 as the minimum client & server protocols. This means that anything that relies on SMBv1 will not work, unless you manually set <code>client min protocol = NT1</code> and <code>server min protocol = NT1</code> in <code>smb.conf</code>. Samba no longer recommends using SMBv1.<br />
}}<br />
<br />
<br />
:{{Imbox<br />
| type = note<br />
| text = You must not start the <code>samba</code> service on a domain member. This service is required only on Active Directory (AD) domain controllers (DC).<br />
}}<br />
<br />
<br />
Samba does not provide System V init scripts, <code>systemd</code>, <code>upstart</code>, or service files for other init services.<br />
* If you installed Samba using packages, use the script or service configuration file provided by the package to start Samba.<br />
* If you built Samba, see your distribution's documentation for how to create a script or configuration to start services.<br />
<br />
<br />
<br />
<br />
<br />
= Testing the Winbindd Connectivity =<br />
<br />
== Sending a Winbindd Ping ==<br />
<br />
To verify if the Winbindd service is able to connect to Active Directory (AD) Domain Controllers (DC) or a primary domain controller (PDC), enter:<br />
<br />
# wbinfo --ping-dc<br />
checking the NETLOGON for domain[SAMDOM] dc connection to "DC.SAMDOM.EXAMPLE.COM" succeeded<br />
<br />
If the previous command fails, verify:<br />
* That the <code>winbindd</code> service is running.<br />
* Your <code>smb.conf</code> file is set up correctly.<br />
<br />
<br />
<br />
== Using Domain Accounts and Groups in Operating System Commands ==<br />
<br />
=== Looking up Domain Users and Groups ===<br />
<br />
The <code>libnss_winbind</code> library enables you to look up domain users and groups. For example:<br />
<br />
* To look up the domain user <code>SAMDOM\demo01</code>:<br />
<br />
# getent passwd SAMDOM\\demo01<br />
SAMDOM\demo01:*:10000:10000:demo01:/home/demo01:/bin/bash<br />
<br />
* To look up the domain group <code>Domain Users</code>:<br />
<br />
# getent group "SAMDOM\\Domain Users"<br />
SAMDOM\domain users:x:10000:<br />
<br />
<br />
<br />
=== Assigning File Permissions to Domain Users and Groups ===<br />
<br />
The name service switch (NSS) library enables you to use domain user accounts and groups in commands. For example to set the owner of a file to the <code>demo01</code> domain user and the group to the <code>Domain Users</code> domain group, enter:<br />
<br />
# chown "SAMDOM\\demo01:SAMDOM\\domain users" file.txt<br />
<br />
<br />
<br />
<br />
<br />
= Setting up Additional Services on the Domain Member =<br />
<br />
On a Samba domain member, you can additionally set up:<br />
* File shares to act as a file server. For details, see [[Samba_File_Serving|Samba File Serving]].<br />
* Print services to act as a print server. For details, see [[Print_Server_Support|Print Server Support]].<br />
* PAM authentication of domain users for local services. For details, see [[Authenticating_Domain_Users_Using_PAM|Authenticating Domain Users Using PAM]].<br />
<br />
<br />
<br />
<br />
<br />
= Troubleshooting =<br />
<br />
For details, see [[Troubleshooting_Samba_Domain_Members|Troubleshooting Samba Domain Members]].<br />
<br />
<br />
<br />
<br />
<br />
----<br />
[[Category:Active Directory]]<br />
[[Category:Domain Members]]<br />
[[Category:NT4 Domains]]</div>Hortimechhttps://wiki.samba.org/index.php?title=Idmap_config_autorid&diff=18874Idmap config autorid2023-04-20T11:11:49Z<p>Hortimech: </p>
<hr />
<div>= Introduction =<br />
<br />
The <code>autorid</code> back end works similar to the <code>rid</code> ID mapping back end, but can automatically assign IDs for different domains. This enables you to use the autorid back end:<br />
<br />
* For the <code>*</code> default domain and additional domains, without the need to create ID mapping configurations for each of the additional domains.<br />
* Only for specific domains. <br />
<br />
For alternatives, see [[Identity_Mapping_Back_Ends|Identity Mapping Back Ends]].<br />
<br />
{{Imbox<br />
| type = warning<br />
| text = ID mapping back ends are not supported in the <code>smb.conf</code> file on a Samba Active Directory (AD) domain controller (DC).<br />Do not add any idmap config lines to a Samba Active Directory (AD) domain controller (DC) smb.conf<br />For details, see [[Updating_Samba#Updating_Samba#Failure_To_Access_Shares_on_Domain_Controllers_If_idmap_config_Parameters_Set_in_the_smb.conf_File|Failure to Access Shares on Domain Controllers If idmap config Parameters Set in the smb.conf File]].<br />
}}<br />
<br />
<br />
<br />
<br />
<br />
= Benefits and Drawbacks =<br />
<br />
Benefits:<br />
* All domain users and groups whose calculated UID and GID is within the configured range are automatically available on the domain member.<br />
* You do not need to manually assign IDs, home directories, and login shells.<br />
* No duplicate IDs, even if multiple objects in a multi-domain environment have the same RID. <br />
<br />
Drawbacks:<br />
* User and group IDs will not be the same across Samba domain members.<br />
* All domain users get the same login shell and home directory assigned. However, you can use variables.<br />
* You cannot exclude individual users or groups from being available on the domain member. Only users and groups whose calculated UID or GID is outside of the configured range are excluded.<br />
* You cannot and must not use <code>winbind use default domain = yes</code> in <code>smb.conf</code>, users are always in the form 'DOMAIN\username.<br />
<br />
<br />
<br />
= Configuring the <code>autorid</code> Back End =<br />
<br />
To configure a Samba domain member to use the <code>autorid</code> ID mapping back end for the <code>*</code> domain:<br />
<br />
* Edit the <code>[global]</code> section in your <code>smb.conf</code> file<br />
:{{Imbox<br />
| type = note<br />
| text = If you use <code>autorid</code> for the default domain, you can use other winbind backends for other domains, but the ranges must not overlap. See the <code>idmap_autorid(8)</code> man page. <br />
}}<br />
<br />
:* Enable the <code>autorid</code> ID mapping back end for the <code>*</code> default domain: <br />
<br />
idmap config * : backend = autorid<br />
<br />
:* Set a range that is big enough to assign IDs for all existing and future objects. For example:<br />
<br />
idmap config * : range = 10000-24999999<br />
<br />
::Samba ignores users and groups whose calculated IDs in this domain are not within the range. For details about how the back end calculated IDs, see the <code>THE MAPPING FORMULAS</code> in the <code>idmap_autorid(8)</code> man page. <br />
<br />
<br />
::{{Imbox<br />
| type = warning<br />
| text = After you set the range and Samba started using it, you can only increase the top end of the range. Any other change on the range can result in new ID assignments, and thus in loosing file ownerships. <br />
}}<br />
<br />
:* Optionally, set a range size. For example: <br />
<br />
idmap config * : rangesize = 200000<br />
<br />
::Samba assigns this number of continuous IDs for each domain's object until all IDs from the range set in the <code>idmap config * : range</code> parameter are taken. For further details, see the <code>rangesize</code>parameter description in the <code>idmap_autorid(8)</code> man page. <br />
<br />
<br />
<br />
A basic smb.conf using the 'autorid' idmap backend, will look something like this:<br />
<br />
[global]<br />
security = ADS<br />
workgroup = SAMDOM<br />
realm = SAMDOM.EXAMPLE.COM<br />
<br />
log file = /var/log/samba/%m.log<br />
log level = 1<br />
<br />
# Default ID mapping configuration using the autorid<br />
# idmap backend. This will work out of the box for simple setups<br />
# as well as complex setups with trusted domains.<br />
# NOTE: You cannot and must not use 'winbind use default domain = yes'<br />
# with the autorid idmap backend. This means that your users<br />
# will need to login using the format 'DOMAIN\username'.<br />
# If you want your users to login just using 'username' then<br />
# you cannot use the 'autorid' idmap backend.<br />
idmap config * : backend = autorid<br />
idmap config * : range = 10000-24999999<br />
<br />
For information on the parameters, see the <code>smb.conf(5)</code> man page.<br />
<br />
<br />
<br />
:* Set a shell and home directory path that will be assigned to all mapped users. For example: <br />
<br />
template shell = /bin/bash<br />
template homedir = /home/%U<br />
<br />
::For details about variable substitution, see the <code>VARIABLE SUBSTITUTIONS</code> section in the <code>smb.conf(5)</code> man page. <br />
<br />
:* Optionally, add additional ID mapping configurations for domains. If no configuration for an individual domain is available, Samba calculates the ID using the <code>autorid</code> back end settings in the previously configured <code>*</code> default domain.<br />
<br />
::{{Imbox<br />
| type = important<br />
| text = If you configure additional back ends for individual domain, the ranges for all ID mapping configurations must not overlap.<br />
}}<br />
<br />
* Reload the Samba configuration: <br />
<br />
# smbcontrol all reload-config<br />
<br />
<br />
<br />
<br />
<br />
= Additional Resources =<br />
<br />
* <code>idmap_autorid(8)</code> man page<br />
<br />
<br />
<br />
<br />
<br />
----<br />
[[Category:Active Directory]]<br />
[[Category:Domain Members]]<br />
[[Category:NT4 Domains]]</div>Hortimechhttps://wiki.samba.org/index.php?title=Idmap_config_rid&diff=18873Idmap config rid2023-04-20T11:01:35Z<p>Hortimech: </p>
<hr />
<div>= Introduction =<br />
<br />
The <code>rid</code> ID mapping back end implements a read-only API to retrieve account and group information from an Active Directory (AD) Domain Controller (DC) or NT4 primary domain controller (PDC). The back end assigns IDs from an individual per-domain range set in the <code>smb.conf</code> file and stores them in them in a local database. For details, how the local ID and the relative identifier (RID) are calculated, see the <code>idmap_rid(8)</code> man page. Because the <code>rid</code> back end is read-only, it is unable to assign new ID, such as for <code>BUILTIN</code> groups. Thus this back end cannot be set as <code>idmap config *</code> default ID mapping back end.<br />
<br />
For alternatives, see [[Identity_Mapping_Back_Ends|Identity Mapping Back Ends]].<br />
<br />
{{Imbox<br />
| type = warning<br />
| text = ID mapping back ends are not supported in the <code>smb.conf</code> file on a Samba Active Directory (AD) domain controller (DC).<br />Do not add any idmap config lines to a Samba Active Directory (AD) domain controller (DC) smb.conf<br />For details, see [[Updating_Samba#Updating_Samba#Failure_To_Access_Shares_on_Domain_Controllers_If_idmap_config_Parameters_Set_in_the_smb.conf_File|Failure to Access Shares on Domain Controllers If idmap config Parameters Set in the smb.conf File]].<br />
}}<br />
<br />
<br />
<br />
<br />
<br />
= Advantages and Disadvantages of the <code>rid</code> Back End =<br />
<br />
Advantages:<br />
* Easy to set up.<br />
* Used IDs are tracked automatically.<br />
* Requires only read access to domain controllers.<br />
* All domain user accounts and groups are automatically available on the domain member.<br />
* No attributes need to be set for domain users and groups.<br />
* If you use the the same basic <code>smb.conf</code> file on all Samba domain members, then user and group IDs will always be the same.<br />
* You can use the setting: <code>winbind use default domain = yes</code> and users will be in the form <code>username</code> instead of <code>DOMAIN\username</code>.<br />
<br />
Disadvantages:<br />
* All users on the domain member get the same login shell and home directory base path assigned.<br />
* All accounts and groups are automatically available on the domain member and individual entries cannot be excluded.<br />
* You must add <code>idmap config</code> lines for all trusted domains.<br />
<br />
<br />
<br />
<br />
<br />
= Planning the ID Ranges =<br />
<br />
Before configuring the <code>rid</code> back end in the <code>smb.conf</code> file, select unique ID ranges Samba can use for each domain. The ranges must be continuous and big enough to enable Samba to assign an ID for every future user and group created in the domain.<br />
<br />
{{Imbox<br />
| type = important<br />
| text = The ID ranges of the <code>*</code> default domain and all other domains configured in the <code>smb.conf</code> file must not overlap. <br />
}}<br />
<br />
<br />
<br />
<br />
<br />
= Configuring the <code>rid</code> Back End =<br />
<br />
* To configure the <code>rid</code> back end using the <code>10000-999999</code> ID range for the <code>SAMDOM</code> domain, set the following in the <code>[global]</code> section of your <code>smb.conf</code> file:<br />
<br />
security = ADS<br />
workgroup = SAMDOM<br />
realm = SAMDOM.EXAMPLE.COM<br />
<br />
log file = /var/log/samba/%m.log<br />
log level = 1<br />
<br />
# Default ID mapping configuration for local BUILTIN accounts<br />
# and groups on a domain member. The default (*) domain:<br />
# - must not overlap with any domain ID mapping configuration!<br />
# - must use a read-write-enabled back end, such as tdb.<br />
idmap config * : backend = tdb<br />
idmap config * : range = 3000-7999<br />
# - You must set a DOMAIN backend configuration<br />
# idmap config for the SAMDOM domain<br />
idmap config SAMDOM : backend = rid<br />
idmap config SAMDOM : range = 10000-999999<br />
<br />
{{Imbox<br />
| type = important<br />
| text = Setting the default back end is mandatory.<br />
}}<br />
<br />
{{Imbox<br />
| type = important<br />
| text = For every domain, set these parameters individually. The ID ranges of the <code>*</code> default domain and all other domains configured in the <code>smb.conf</code> file must not overlap.<br />
}}<br />
<br />
<br />
* Configure the template settings. For example, to set <code>/bin/bash</code> as shell and <code>/home/%U</code> as home directory path, add:<br />
<br />
# Template settings for login shell and home directory<br />
template shell = /bin/bash<br />
template homedir = /home/%U<br />
<br />
The values are applied to all users in all domains. Samba resolves the <code>%U</code> variable to the session user name. For details, see the <code>VARIABLE SUBSTITUTIONS</code> section in the <code>smb.conf(5)</code> man page.<br />
<br />
<br />
* Reload Samba:<br />
<br />
# smbcontrol all reload-config<br />
<br />
For further details, see the <code>smb.conf(5)</code> and <code>idmap_rid(8)</code> man page.<br />
<br />
<br />
<br />
<br />
<br />
----<br />
[[Category:Active Directory]]<br />
[[Category:Domain Members]]<br />
[[Category:NT4 Domains]]</div>Hortimechhttps://wiki.samba.org/index.php?title=Setting_up_Samba_as_a_Domain_Member&diff=18871Setting up Samba as a Domain Member2023-04-12T07:08:14Z<p>Hortimech: </p>
<hr />
<div>= Introduction =<br />
<br />
A Samba domain member is a Linux machine joined to a domain that is running Samba and does not provide domain services, such as an NT4 primary domain controller (PDC) or Active Directory (AD) domain controller (DC).<br />
<br />
On a Samba domain member, you can:<br />
<br />
* Use domain users and groups in local ACLs on files and directories.<br />
* Set up shares to act as a file server.<br />
* Set up printing services to act as a print server.<br />
* Configure PAM to enable domain users to log on locally or to authenticate to local installed services.<br />
<br />
For details about setting up a Samba NT4 domain or Samba AD, see [[Domain_Control|Domain Control]].<br />
<br />
<br />
{{Imbox<br />
| type = important<br />
| text = For versions of Samba earlier than 4.15.0, never use <code>samba-tool domain provision</code> to create a Unix domain member, it will not work, you must follow the procedure laid out on this page.<br />
}}<br />
<br />
{{Imbox<br />
| type = important<br />
| text = All AD Domain members must be in the same <code>DNS</code> domain and the Realm must be the <code>DNS</code> domain in uppercase. For example, the <code>DNS</code> domain could be <code>samdom.example.com</code> and the Realm would be <code>SAMDOM.EXAMPLE.COM</code>.<br />
}}<br />
<br />
<br />
<br />
= Preparing the Installation =<br />
<br />
== General Preparation ==<br />
<br />
* Verify that no Samba processes are running:<br />
# ps ax | egrep "samba|smbd|nmbd|winbindd"<br />
: If the output lists any <code>samba</code>, <code>smbd</code>, <code>nmbd</code>, or <code>winbindd</code> processes, shut down the processes.<br />
<br />
* If you previously run a Samba installation on this host:<br />
:* Backup the existing <code>smb.conf</code> file. To list the path to the file, enter:<br />
<br />
# smbd -b | grep "CONFIGFILE"<br />
CONFIGFILE: /usr/local/samba/etc/samba/smb.conf<br />
<br />
:* Remove all Samba database files, such as <code>*.tdb</code> and <code>*.ldb</code> files. To list the folders containing Samba databases:<br />
<br />
# smbd -b | egrep "LOCKDIR|STATEDIR|CACHEDIR|PRIVATE_DIR"<br />
LOCKDIR: /usr/local/samba/var/lock/<br />
STATEDIR: /usr/local/samba/var/locks/<br />
CACHEDIR: /usr/local/samba/var/cache/<br />
PRIVATE_DIR: /usr/local/samba/private/<br />
<br />
: Starting with a clean environment helps you to prevent confusion, and no files from your previous Samba installation are mixed with your new domain member installation.<br />
<br />
<br />
<br />
== Preparing a Domain Member to Join an Active Directory Domain ==<br />
<br />
=== Configuring DNS ===<br />
<br />
{{:Linux and Unix DNS Configuration}}<br />
<br />
<br />
<br />
<br />
<br />
=== Configuring Kerberos ===<br />
<br />
Samba supports Heimdal and MIT Kerberos back ends. To configure Kerberos on the domain member, set the following in your <code>/etc/krb5.conf</code> file:<br />
<br />
[libdefaults]<br />
default_realm = SAMDOM.EXAMPLE.COM<br />
dns_lookup_realm = false<br />
dns_lookup_kdc = true<br />
<br />
The previous example configures Kerberos for the <code>SAMDOM.EXAMPLE.COM</code> realm.<br />
<br />
The Samba teams recommends to no set any further parameters in the <code>/etc/krb5.conf</code> file.<br />
<br />
If your <code>/etc/krb5.conf</code> contains an <code>include</code> line it will not work, you '''Must''' remove this line.<br />
<br />
On some Linux distributions that use MIT Kerberos, it is necessary to add these lines for proper ID mapping:<br />
<br />
[plugins]<br />
localauth = {<br />
module = winbind:/usr/lib64/samba/krb5/winbind_krb5_localauth.so<br />
enable_only = winbind<br />
}<br />
<br />
These settings could also be necessary <code>/etc/security/pam_winbind.conf</code>:<br />
<br />
[global]<br />
krb5_auth = yes<br />
krb5_ccache_type = FILE<br />
<br />
With distributions with crypto-policies, this command must be issued to update the system policy support for Active Directory:<br />
<br />
<code>update-crypto-policies --set DEFAULT:AD-SUPPORT</code><br />
<br />
<br />
<br />
<br />
<br />
=== Configuring Time Synchronisation ===<br />
<br />
Kerberos requires a synchronised time on all domain members. Thus it is recommended to set up an NTP client. For further details, see [[Time_Synchronisation#Configuring_Time_Synchronisation_on_a_Unix_Domain_Member|Configuring Time Synchronisation on a Unix Domain Member]].<br />
<br />
<br />
<br />
<br />
<br />
=== Local Host Name Resolution ===<br />
<br />
When you join the host to the domain, Samba tries to register the host name in the AD DNS zone. For this, the <code>net</code> utility must be able to resolve the host name using DNS or using a correct entry in the <code>/etc/hosts</code> file.<br />
<br />
To verify that your host name resolves correctly, use the <code>getent hosts</code> command. For example:<br />
<br />
# getent hosts M1<br />
10.99.0.5 M1.samdom.example.com M1<br />
<br />
The host name and FQDN must not resolve to the <code>127.0.0.1</code> IP address or any other IP address other than the one used on the LAN interface of the domain member.<br />
<br />
If no output is displayed or the host is resolved to the wrong IP address and you are not using dhcp, set the correct entry in the <code>/etc/hosts</code> file. For example:<br />
<br />
127.0.0.1 localhost<br />
10.99.0.5 M1.samdom.example.com M1<br />
<br />
If you are using dhcp, check that <code>/etc/hosts</code> only contains the '127.0.0.1' line shown above. If you continue to have problems, contact the sysadmin who controls your DHCP server.<br />
<br />
if you need to add aliases to the machine hostname, add them to the end of the line that starts with the machines ipaddress, not the 127.0.0.1 line.<br />
<br />
<br />
<br />
<br />
== Preparing a Domain Member to Join an NT4 Domain ==<br />
<br />
For joining a host to an NT4 domain, no preparation is required.<br />
<br />
<br />
<br />
<br />
<br />
= Installing Samba =<br />
<br />
For details, see [[Installing_Samba|Installing Samba]].<br />
<br />
{{Imbox<br />
| type = note<br />
| text = Install a maintained Samba version. For details, see [[Samba_Release_Planning|Samba Release Planning]].<br />
}}<br />
<br />
<br />
<br />
<br />
<br />
= Configuring Samba =<br />
<br />
<br />
<br />
Samba can use various winbind idmap backends, The three main ones are:<br />
* ad<br />
* autorid<br />
* rid<br />
<br />
<br />
=== Choosing an idmap backend ===<br />
<br />
It can appear to be a complex decision choosing which winbind idmap backend to use, hopefully reading this can point you to the one to use.<br />
<br />
<br />
* If you require users and groups to have the same IDs everywhere, or have different login shells and Unix home directory paths, then you need to use the winbind idmap 'ad' backend and add RFC2307 attributes to AD.<br />
<br />
<br />
If you use the 'ad' backend, the RFC2307 attributes (uidNumber, gidNumber, etc) are not added automatically when users or groups are created, you must add them manually.<br />
<br />
The ID numbers found on a DC (numbers in the 3000000 range) are NOT rfc2307 attributes They cannot and will not be used on Unix Domain Members, you can add uidNumber & gidNumber attributes to AD and use the winbind 'ad' backend on Unix Domain Members. If you do decide to add uidNumber & gidNumber attributes to AD, you do not need to use numbers in the 3000000 range and it would definitely be a good idea to use a different range.<br />
<br />
<br />
* If you only need users and groups to have Unix IDs, you can use the 'autorid' or 'rid' idmap winbind backend.<br />
<br />
<br />
The 'autorid' or 'rid' idmap winbind backends calculate the user and group IDs from the Windows RID. If you use the same [global] section of the smb.conf on every Unix domain member, you will get the same IDs. Using these idmap backends, you do not add anything to AD and any added RFC2307 attributes will be ignored. When using these backends you can set the 'template shell' and 'template homedir' parameters in the smb.conf global section and everyone will get the login shell and Unix home directory path you set. If you do not set 'template shell' or 'template homedir', the defaults, '/bin/false' and '/home/%D/%U' , will be used.<br />
<br />
<br />
Once you Have decided which winbind idmap backend to use, you have to choose the ranges to use with 'idmap config' in smb.conf.<br />
<br />
By default on a Unix domain member, there are multiple blocks of users & groups:<br />
<br />
The local system users & groups: These will be from 0-999<br />
The local Unix users and groups: These start at 1000<br />
The SAMDOM domain users and groups: ADUC, by default, starts these at 10000<br />
The default domain '*' also known as the 'well Known SIDs': ????<br />
Trusted domains: ????<br />
Anything that isn't a 'well Known SID' or a member of SAMDOM or a trusted domain: ????<br />
<br />
<br />
As you can see from the above, if you are creating a new domain, you shouldn't set either the default domain '*' or the 'SAMDOM' ranges to start at 999 or less, as they would interfere with the local system users & groups. You also should leave a space for any local Unix users & groups, so starting the 'idmap config' ranges at 3000 seems to be a good compromise.<br />
<br />
Bearing the above information in mind, you could set the 'idmap config' ranges to the following:<br />
<br />
:{| class="wikitable"<br />
!Domain<br />
!Range<br />
|-<br />
|<code>*</code><br />
|'''3000-7999'''<br />
|-<br />
|<code>DOMAIN</code><br />
|'''10000-999999'''<br />
|}<br />
<br />
You could also have any trusted domains starting at:<br />
<br />
:{| class="wikitable"<br />
!Domain<br />
!Range<br />
|-<br />
|<code>TRUSTED</code><br />
|'''1000000-9999999'''<br />
|}<br />
<br />
If you set the default domain '*' range above the 'SAMDOM' domain range, the ranges will conflict if the domain grows to the point that the next ID would be the same as the default domain range start ID.<br />
<br />
With the above suggested ranges, no range will overlap or interfere with another.<br />
<br />
You may also have seen examples of the '*' range being used for everything, this should only be used with the 'autorid' idmap backend.<br />
<br />
<br />
== Setting up a Basic <code>smb.conf</code> File ==<br />
<br />
Before joining the domain, configure the domain member's <code>smb.conf</code> file:<br />
<br />
* To locate the file, enter:<br />
<br />
# smbd -b | grep CONFIGFILE<br />
CONFIGFILE: /etc/samba/smb.conf<br />
<br />
To create a basic smb.conf using the 'autorid' idmap backend, you will need something like this:<br />
<br />
[global]<br />
security = ADS<br />
workgroup = SAMDOM<br />
realm = SAMDOM.EXAMPLE.COM<br />
<br />
log file = /var/log/samba/%m.log<br />
log level = 1<br />
<br />
# Default ID mapping configuration using the autorid<br />
# idmap backend. This will work out of the box for simple setups<br />
# as well as complex setups with trusted domains.<br />
# NOTE: You cannot and must not use 'winbind use default domain = yes'<br />
# with the autorid idmap backend. This means that your users<br />
# will need to login using the format 'DOMAIN\username'.<br />
# If you want your users to login just using 'username' then<br />
# you cannot use the 'autorid' idmap backend.<br />
idmap config * : backend = autorid<br />
idmap config * : range = 10000-9999999<br />
<br />
For information on the parameters, see the <code>smb.conf(5)</code> man page.<br />
<br />
The following table lists the most important idmap backends with links to their documentation, click the relevant <code>Documentation</code> link for how to setup each idmap backend:<br />
<br />
:{| class="wikitable"<br />
!Back End<br />
!Documentation<br />
!Man Page<br />
|-<br />
|<code>ad</code><br />
|'''[[Idmap_config_ad|idmap config ad]]'''<br />
|<code>idmap_ad(8)</code><br />
|-<br />
|<code>rid</code><br />
|'''[[Idmap_config_rid|idmap config rid]]'''<br />
|<code>idmap_rid(8)</code><br />
|-<br />
|<code>autorid</code><br />
|'''[[Idmap_config_autorid|idmap config autorid]]'''<br />
|<code>idmap_autorid(8)</code><br />
|-<br />
|<code>hash</code><br />
|<br />
|<code>idmap_hash(8)</code><br />
|-<br />
|<code>ldap</code><br />
|<br />
|<code>idmap_ldap(8)</code><br />
|-<br />
|<code>nss</code><br />
|<br />
|<code>idmap_nss(8)</code><br />
|}<br />
<br />
:{{Imbox<br />
| type = important<br />
| text = Add an additional ID mapping configuration for every domain, unless you use the <code>autorid</code> idmap backend. The ID ranges of the default (<code>*</code>) domain and other domains configured in the <code>smb.conf</code> file must not overlap.<br />
}}<br />
<br />
<br />
<br />
<br />
== Mapping the Domain Administrator Account to the Local <code>root</code> User ==<br />
<br />
Samba enables you to map domain accounts to a local account. Use this feature to execute file operations on the domain member's file system as a different user than the account that requested the operation on the client.<br />
<br />
{{Imbox<br />
| type = note<br />
| text = You should map the domain Administrator account to the local <code>root</code> account on a Unix domain member. Configuring the mapping allows the domain Administrator to execute file operations as <code>root</code> on the Unix domain member. When you map Administrator to the <code>root</code> account, you should not attempt to log onto a Unix domain member as Administrator. Only follow the method below to map <code>Administrator</code> to <code>root</code>.<br />
}}<br />
{{Imbox<br />
| type = note<br />
| text = If you have changed the domain Administrator account name, use the new admin name in the following instead of <code>Administrator</code>. <br />
}}<br />
<br />
<br />
To map the domain administrator to the local <code>root</code> account:<br />
<br />
* Add the following parameter to the <code>[global]</code> section of your <code>smb.conf</code> file:<br />
<br />
username map = /usr/local/samba/etc/user.map<br />
<br />
* Create the <code>/usr/local/samba/etc/user.map</code> file with the following content:<br />
<br />
!root = SAMDOM\Administrator<br />
<br />
:{{Imbox<br />
| type = important<br />
| text = When using the <code>ad</code> ID mapping back end, never set a <code>uidNumber</code> attribute for the domain Administrator account. If the account has the attribute set, the value will override the local UID <code>0</code> of the <code>root</code> user on Samba AD DC's and thus the mapping fails.<br />
}}<br />
<br />
For further details, see <code>username map</code> parameter in the <code>smb.conf(5)</code> man page.<br />
<br />
<br />
<br />
<br />
<br />
= Joining the Domain =<br />
<br />
* To join the host to an Active Directory (AD), enter:<br />
<br />
# net ads join -U administrator<br />
Enter administrator's password: Passw0rd<br />
Using short domain name -- SAMDOM<br />
Joined 'M1' to dns domain 'samdom.example.com'<br />
<br />
{{Imbox<br />
| type = note<br />
| text = When you join a computer to an AD domain with <code>net ads join</code>, the computers forward dns record should be created (if not already existing), but, if your computer has a fixed ipaddress, you will have to create the reverse PTR record yourself. <br />
}}<br />
<br />
<br />
* To join the host to an NT4 domain, enter:<br />
<br />
# net rpc join -U administrator<br />
Enter administrator's password: Passw0rd<br />
Joined domain SAMDOM.<br />
<br />
<br />
<br />
== Joining the Domain with samba-tool (>4.15.0 only) ==<br />
<br />
{{Imbox<br />
| type = important<br />
| text = Before Samba 4.15.0 , you could not join a Unix domain member using <code>samba-tool domain join</code>, this option was unsupported, did not work and would cause problems with your AD replication. You can only use <code>samba-tool domain join</code> if the Unix domain member has Samba >= 4.15.0 installed.<br />
}}<br />
<br />
* To join the host to an Active Directory (AD), enter:<br />
<br />
# samba-tool domain join samdom.example.com MEMBER -U administrator<br />
<br />
If you have problems joining the domain, check your configuration. For further help, see [[Troubleshooting_Samba_Domain_Members|Troubleshooting Samba Domain Members]].<br />
<br />
<br />
<br />
<br />
<br />
= Configuring the Name Service Switch =<br />
<br />
To enable the name service switch (NSS) library to make domain users and groups available to the local system:<br />
<br />
* Append the <code>winbind</code> entry to the following databases in the <code>/etc/nsswitch.conf</code> file:<br />
<br />
passwd: files <u>winbind</u><br />
group: files <u>winbind</u><br />
<br />
:* Keep the <code>files</code> entry as first source for both databases. This enables NSS to look up domain users and groups from the <code>/etc/passwd</code> and <code>/etc/group</code> files before querying the Winbind service.<br />
<br />
:* Do not add the <code>winbind</code> entry to the NSS <code>shadow</code> database. This can cause the <code>wbinfo</code> utility fail.<br />
<br />
:{{Imbox<br />
| type = note<br />
| text = If there's a line containing an <code>initgroups</code> directive, add <code> [success=continue] winbind</code>, otherwise the NSS library will not ask winbindd for a user's additional group memberships. Do not add the <code>initgroups</code> line if it does not exist.<br />
}}<br />
<br />
:{{Imbox<br />
| type = warning<br />
| text = Do not use the same user names in the local <code>/etc/passwd</code> file as in the domain.<br />
}}<br />
<br />
:{{Imbox<br />
| type = warning<br />
| text = Do not use local Unix names when changing file and directory ownership on Samba domain shares.<br />
}}<br />
<br />
:{{Imbox<br />
| type = note<br />
| text = If you compiled Samba, add symbolic links from the <code>libnss_winbind</code> library to the operating system's library path. For details, see [[Libnss_winbind_Links|libnss_winbind Links]]. If you used packages to install Samba, the link is usually created automatically.<br />
}}<br />
<br />
<br />
<br />
<br />
<br />
= Starting the Services =<br />
<br />
Start the following services to have a fully functioning Unix domain member:<br />
<br />
* The <code>smbd</code> service<br />
<br />
* The <code>nmbd</code> service<br />
<br />
* The <code>winbindd</code> service<br />
<br />
<br />
:{{Imbox<br />
| type = note<br />
| text = If you do not require Network Browsing, you do not need to start the <code>nmbd</code> service on a Unix domain member.<br />
}}<br />
<br />
<br />
:{{Imbox<br />
| type = important<br />
| text = The latest versions of Samba (from 4.11.0) now only use SMBv2 as the minimum client & server protocols. This means that anything that relies on SMBv1 will not work, unless you manually set <code>client min protocol = NT1</code> and <code>server min protocol = NT1</code> in <code>smb.conf</code>. Samba no longer recommends using SMBv1.<br />
}}<br />
<br />
<br />
:{{Imbox<br />
| type = note<br />
| text = You must not start the <code>samba</code> service on a domain member. This service is required only on Active Directory (AD) domain controllers (DC).<br />
}}<br />
<br />
<br />
Samba does not provide System V init scripts, <code>systemd</code>, <code>upstart</code>, or service files for other init services.<br />
* If you installed Samba using packages, use the script or service configuration file provided by the package to start Samba.<br />
* If you built Samba, see your distribution's documentation for how to create a script or configuration to start services.<br />
<br />
<br />
<br />
<br />
<br />
= Testing the Winbindd Connectivity =<br />
<br />
== Sending a Winbindd Ping ==<br />
<br />
To verify if the Winbindd service is able to connect to Active Directory (AD) Domain Controllers (DC) or a primary domain controller (PDC), enter:<br />
<br />
# wbinfo --ping-dc<br />
checking the NETLOGON for domain[SAMDOM] dc connection to "DC.SAMDOM.EXAMPLE.COM" succeeded<br />
<br />
If the previous command fails, verify:<br />
* That the <code>winbindd</code> service is running.<br />
* Your <code>smb.conf</code> file is set up correctly.<br />
<br />
<br />
<br />
== Using Domain Accounts and Groups in Operating System Commands ==<br />
<br />
=== Looking up Domain Users and Groups ===<br />
<br />
The <code>libnss_winbind</code> library enables you to look up domain users and groups. For example:<br />
<br />
* To look up the domain user <code>SAMDOM\demo01</code>:<br />
<br />
# getent passwd SAMDOM\\demo01<br />
SAMDOM\demo01:*:10000:10000:demo01:/home/demo01:/bin/bash<br />
<br />
* To look up the domain group <code>Domain Users</code>:<br />
<br />
# getent group "SAMDOM\\Domain Users"<br />
SAMDOM\domain users:x:10000:<br />
<br />
<br />
<br />
=== Assigning File Permissions to Domain Users and Groups ===<br />
<br />
The name service switch (NSS) library enables you to use domain user accounts and groups in commands. For example to set the owner of a file to the <code>demo01</code> domain user and the group to the <code>Domain Users</code> domain group, enter:<br />
<br />
# chown "SAMDOM\\demo01:SAMDOM\\domain users" file.txt<br />
<br />
<br />
<br />
<br />
<br />
= Setting up Additional Services on the Domain Member =<br />
<br />
On a Samba domain member, you can additionally set up:<br />
* File shares to act as a file server. For details, see [[Samba_File_Serving|Samba File Serving]].<br />
* Print services to act as a print server. For details, see [[Print_Server_Support|Print Server Support]].<br />
* PAM authentication of domain users for local services. For details, see [[Authenticating_Domain_Users_Using_PAM|Authenticating Domain Users Using PAM]].<br />
<br />
<br />
<br />
<br />
<br />
= Troubleshooting =<br />
<br />
For details, see [[Troubleshooting_Samba_Domain_Members|Troubleshooting Samba Domain Members]].<br />
<br />
<br />
<br />
<br />
<br />
----<br />
[[Category:Active Directory]]<br />
[[Category:Domain Members]]<br />
[[Category:NT4 Domains]]</div>Hortimechhttps://wiki.samba.org/index.php?title=Setting_up_Samba_as_an_Active_Directory_Domain_Controller&diff=18870Setting up Samba as an Active Directory Domain Controller2023-04-12T06:58:56Z<p>Hortimech: </p>
<hr />
<div>= Introduction =<br />
<br />
Starting from version 4.0 (released in 2012,) Samba is able to serve as an Active Directory (AD) domain controller (DC). Samba can operates at a forest functional level of '''Windows Server 2008 R2''' which is more that sufficient to manage sophisticated enterprises that use Windows 10/11 with strict compliance requirements (including NIST 800-171.)<br />
<br />
If you are installing Samba in a production environment, it is recommended to run two or more DCs for failover reasons, more detail on the provisioning of a failover DC can be found elsewhere on the wiki. This documentation describes how to set up Samba as the first DC to build a new AD forest. Additionally, use this documentation if you are migrating a Samba NT4 domain to Samba AD. To join Samba as an additional DC to an existing AD forest, see [[Joining_a_Samba_DC_to_an_Existing_Active_Directory|Joining a Samba DC to an Existing Active Directory]]. <br />
<br />
Samba as an AD DC only supports:<br />
* The integrated LDAP server as AD back end. For details, see the frequently asked question (FAQ) [[FAQ#Does_Samba_AD_DCs_Support_OpenLDAP_or_Other_LDAP_Servers_as_Back_End.3F|Does Samba AD DCs Support OpenLDAP or Other LDAP Servers as Back End?]]<br />
* The [http://www.h5l.se/ Heimdal] Kerberos Key Distribution Center (KDC).<br />
: Samba provides experimental support for the [https://web.mit.edu/kerberos/ MIT Kerberos] KDC provided by your operating system if you run Samba 4.7 or later and has been built using the <code>--with-system-mitkrb5</code> option. In other cases Samba uses the Heimdal KDC included in Samba. For further details about Samba using the MIT KDC, and why it is experimental see [[Running a Samba AD DC with MIT Kerberos KDC]].<br />
* Hosting and Administering of Group Policy Objects to be used for enterprise fleet management<br />
: {{Imbox<br />
| type = important<br />
| text = Installation of Samba and associated provisioning of a domain controller does not automatically translate into Group Policy functionality. Please keep this in mind, and expect to update this flag in the <code>smb.conf</code> post provisioning<br />
}}<br />
<br />
This tutorial assumes that this is a fresh installation of Samba on a fresh operating system installation. It is important to note that there is a distinction between installing of Samba and Provisioning of Samba. In general, the entire process of setting up a Samba domain controller consists of 5 steps which are relatively straight forward. These steps are as follows:<br />
<br />
# Installation of Samba and associated packages<br />
# Deletion of per-configured Samba and Kerberos placeholder configuration files<br />
# Provisioning of Samba using the automatic provisioning tool<br />
# Editing of the <code>smb.conf</code> as needed (enabling of Group Policy and/or other features as needed) see [[Group_Policy|Group Policy]] for more information<br />
# Any environmental configuration based on Unix/Linux Distribution<br />
<br />
This page covers a lot of ground for Samba installations on both Unix and Linux systems. The installation process varies slightly based on environment, so expect to follow the linked web pages in multiple tabs throughout this read. For the remainder of this tutorial the following example information is used:<br />
<br />
* Hostname = <code>DC1</code><br />
* DC local IP Address = <code>10.99.0.1</code><br />
* Authentication Domain = <code>SAMDOM.EXAMPLE.COM</code><br />
* Top level Domain = <code>EXAMPLE.COM</code><br />
<br />
<br />
<br />
= Preparing the Installation =<br />
<br />
==== Fresh Installation ====<br />
<br />
<br />
* Select a DNS domain for your AD forest. It is not recommended to use the top level domain for your organization. This is because the domain used during the installation of Samba will resolve to the domain controller. For Example: If your organization used <code>EXAMPLE.COM</code> as their domain and this was used during the Samba installation process, then the public facing website would no longer be acceptable (assuming the publicly accessible website was not running on the DC, which it shouldn't!) It would be wise to define a subdomain for your Domain Controller to reside in. In this tutorial <code>SAMDOM.EXAMPLE.COM</code> is used, however in a lab environment it is not necessary to own a publicly accessible domain and <code>.INTERNAL</code> could hypothetically be used. The name will also be used as the AD Kerberos realm.<br />
: {{Imbox<br />
| type = important<br />
| text = Make sure that you provision the AD using a DNS domain that will not need to be changed. Samba does not support renaming the AD DNS zone and Kerberos realm. Do not use <code>.local</code> for the TLD, this is used by Avahi.<br />
}}<br />
: For additional information, see [[Active_Directory_Naming_FAQ|Active Directory Naming FAQ]].<br />
<br />
* Select a host name for your AD DC which consists of less than 15 characters (netbios limitation.) A fantastic hostname is <code>DC1</code><br />
: Do not use NT4-only terms as host name, such as <code>PDC</code> or <code>BDC</code>. These modes do not exist in an AD and cause confusion.<br />
<br />
* A static IP address on the DC and make the associated reservation on your router. '''Important:''' The Samba domain controller will become your DNS resolver for all domain-joined workstations. As a result it may be required to assign this IP address outside of your DHCP pool<br />
<br />
* Disable tools, such as <code>resolvconf</code>, that automatically update your <code>/etc/resolv.conf</code> DNS resolver configuration file. AD DCs and domain members must use an DNS server that is able to resolve the AD DNS zones. (More information on this on the [[Distribution-specific_Package_Installation| Distribution Specific Package Installation]] page)<br />
<br />
* Verify that the <code>/etc/hosts</code> file on the DC correctly resolves the fully-qualified domain name (FQDN) and short host name to the LAN IP address of the DC. For example:<br />
127.0.0.1 localhost<br />
10.99.0.1 DC1.samdom.example.com DC1<br />
:The host name and FQDN must not resolve to the <code>127.0.0.1</code> IP address or any other IP address than the one used on the LAN interface of the DC.<br />
<br />
* Remove any existing <code>smb.conf</code> file. To list the path to the file:<br />
<br />
# smbd -b | grep "CONFIGFILE"<br />
CONFIGFILE: /usr/local/samba/etc/samba/smb.conf<br />
<br />
<br />
==== Only Applicable if Samba was Previously Installed ====<br />
* If you previously ran a Samba installation on this host:<br />
:<br />
<br />
:* Remove all Samba database files, such as <code>*.tdb</code> and <code>*.ldb</code> files. To list the folders containing Samba databases:<br />
<br />
# smbd -b | egrep "LOCKDIR|STATEDIR|CACHEDIR|PRIVATE_DIR"<br />
LOCKDIR: /usr/local/samba/var/lock/<br />
STATEDIR: /usr/local/samba/var/locks/<br />
CACHEDIR: /usr/local/samba/var/cache/<br />
PRIVATE_DIR: /usr/local/samba/private/<br />
<br />
: Starting with a clean environment helps to prevent confusion and ensures that no files from any previous Samba installation will be mixed with your new domain DC installation.<br />
<br />
<br />
= Installing Samba =<br />
<br />
<br />
{{:Installing_Samba}}<br />
<br />
<br />
<br />
= Provisioning a Samba Active Directory =<br />
<br />
{{Imbox<br />
| type = note<br />
| text = The AD provisioning requires root permissions to create files and set permissions.<br />
}}<br />
<br />
The Samba AD provisioning process creates the AD databases and adds initial records, such as the domain administrator account and required DNS entries. Samba comes with a built in command lined tool called <code>samba-tool</code> which can be used to automatically configure your <code>smb.conf</code> when ran in interactive mode. <br />
<br />
If you are migrating a Samba NT4 domain to AD, skip this step and run the Samba classic upgrade. For details, see [[Migrating_a_Samba_NT4_Domain_to_Samba_AD_(Classic_Upgrade)|Migrating a Samba NT4 Domain to Samba AD (Classic Upgrade)]].<br />
<br />
<br />
The <code>samba-tool domain provision</code> command provides several parameters to use with the interactive and non-interactive setup. For details, see:<br />
<br />
# samba-tool domain provision --help<br />
<br />
<br />
{{Imbox<br />
| type = note<br />
| text = When provisioning a new AD, it is recommended to enable the NIS extensions by passing the <code>--use-rfc2307</code> parameter to the <code>samba-tool domain provision</code> command. There are no disadvantages to enabling the NIS extensions, but enabling them in an existing domain requires manually extending the AD schema. For further details about Unix attributes in AD, see:<br />
* [[Setting_up_RFC2307_in_AD|Setting up RFC2307 in AD]]<br />
* [[Idmap_config_ad|idmap config = ad]]<br />
}}<br />
<br />
<br />
<br />
==== Parameter Reference ====<br />
<br />
Set the following parameters during the provisioning:<br />
<br />
{| class="wikitable"<br />
!Interactive Mode Setting<br />
!Non-interactive Mode Parameter<br />
!Explanation<br />
|-<br />
|<code>--use-rfc2307</code><br />
|<code>--use-rfc2307</code><br />
|Enables the NIS extensions required for the ADUC Unix Attributes tab.<br />
|-<br />
|<code>Realm</code><br />
|<code>--realm</code><br />
|Kerberos realm. The uppercase version of the AD DNS domain. For example: <code>SAMDOM.EXAMPLE.COM</code>.<br />
|-<br />
|<code>Domain</code><br />
|<code>--domain</code><br />
|NetBIOS domain name (Workgroup). This can be anything, but it must be one word, not longer than 15 characters and not containing a dot. It is recommended to use the first part of the AD DNS domain. For example: <code>samdom</code>. Do not use the computers short hostname.<br />
|-<br />
|<code>Server Role</code><br />
|<code>--server-role</code><br />
|Installs the domain controller <code>DC</code> role.<br />
|-<br />
|<code>DNS backend</code><br />
|<code>--dns-backend</code><br />
|Sets the DNS back end. The first DC in an AD must be installed using a DNS back end. Note that the <code>BIND9_FLATFILE</code> is not supported and will be removed in a future Samba version.<br />
|-<br />
|<code>DNS forwarder IP address</code><br />
|not available<br />
|This setting is only available when using the <code>SAMBA_INTERNAL</code> DNS back end. For details, see [[Samba_Internal_DNS_Back_End#Setting_up_a_DNS_Forwarder|Setting up a DNS Forwarder]].<br />
|-<br />
|<code>Administrator password</code><br />
|<code>--adminpass</code><br />
|Sets the domain administrator password. If the password does not match the complexity requirements, the provisioning fails. For details, see [https://technet.microsoft.com/en-us/library/cc786468%28v=ws.10%29.aspx Microsoft TechNet: Passwords must meet complexity requirements].<br />
|}<br />
<br />
Other parameters frequently used with the <code>samba-tool domain provision</code> command:<br />
* <code>--option="interfaces=lo eth0" --option="bind interfaces only=yes"</code>: If your server has multiple network interfaces, use these options to bind Samba to the specified interfaces. This enables the <code>samba-tool</code> command to register the correct LAN IP address in the directory during the join.<br />
<br />
<br />
{{Imbox<br />
| type = important<br />
| text = do NOT use <code>NONE</code> as the DNS backend, it is not supported and will be removed in a future Samba version.<br />
}}<br />
<br />
{{Imbox<br />
| type = important<br />
| text = If using Bind as the DNS backend, do NOT use <code>BIND9_FLATFILE</code>, it is not supported and will be removed in a future Samba version.<br />
}}<br />
<br />
{{Imbox<br />
| type = important<br />
| text = Once you have provisioned the first DC in an AD domain, do not provision any further DCs in the same domain, [[Joining_a_Samba_DC_to_an_Existing_Active_Directory|Join]] any further DCs.<br />
}}<br />
<br />
<br />
<br />
== Provisioning Samba AD in Interactive Mode ==<br />
<br />
As mentioned above, <code>samba-tool</code> when ran as route will automatically configure your <code>smb.conf</code> to build a domain controller. Interactive Mode will not automatically enable Group Policy support. However this can be added in afterwards by manually editing the <code>smb.conf</code> to add it in later. Open the [[Group_Policy#Winbind|Group Policy]] page in a new tab for later reading<br />
{{Imbox<br />
| type = warning<br />
| text = The installation of Samba will create a <code>smb.conf</code> file that must be discarded prior to running the Provisioning Tool in Interactive mode, or else it will fail. On most Linux distributions this can be done by running:<br />
# mv /etc/samba/smb.conf /etc/samba/smb.conf.initial<br />
}}<br />
<br />
With the existing <code>smb.conf</code> file removed, provision a Samba AD interactively by running run:<br />
<br />
# samba-tool domain provision --use-rfc2307 --interactive<br />
Realm [SAMDOM.EXAMPLE.COM]: SAMDOM.EXAMPLE.COM<br />
Domain [SAMDOM]: SAMDOM<br />
Server Role (dc, member, standalone) [dc]: dc<br />
DNS backend (SAMBA_INTERNAL, BIND9_FLATFILE, BIND9_DLZ, NONE) [SAMBA_INTERNAL]: SAMBA_INTERNAL<br />
DNS forwarder IP address (write 'none' to disable forwarding) [10.99.0.1]: 8.8.8.8<br />
Administrator password: Passw0rd<br />
Retype password: Passw0rd<br />
Looking up IPv4 addresses<br />
Looking up IPv6 addresses<br />
No IPv6 address will be assigned<br />
Setting up share.ldb<br />
Setting up secrets.ldb<br />
Setting up the registry<br />
Setting up the privileges database<br />
Setting up idmap db<br />
Setting up SAM db<br />
Setting up sam.ldb partitions and settings<br />
Setting up sam.ldb rootDSE<br />
Pre-loading the Samba 4 and AD schema<br />
Adding DomainDN: DC=samdom,DC=example,DC=com<br />
Adding configuration container<br />
Setting up sam.ldb schema<br />
Setting up sam.ldb configuration data<br />
Setting up display specifiers<br />
Modifying display specifiers<br />
Adding users container <br />
Modifying users container <br />
Adding computers container <br />
Modifying computers container <br />
Setting up sam.ldb data <br />
Setting up well known security principals <br />
Setting up sam.ldb users and groups <br />
Setting up self join <br />
Adding DNS accounts <br />
Creating CN=MicrosoftDNS,CN=System,DC=samdom,DC=example,DC=com <br />
Creating DomainDnsZones and ForestDnsZones partitions <br />
Populating DomainDnsZones and ForestDnsZones partitions <br />
Setting up sam.ldb rootDSE marking as synchronized <br />
Fixing provision GUIDs <br />
A Kerberos configuration suitable for Samba 4 has been generated at /usr/local/samba/private/krb5.conf <br />
Setting up fake yp server settings <br />
Once the above files are installed, your Samba4 server will be ready to use <br />
Server Role: active directory domain controller <br />
Hostname: DC1 <br />
NetBIOS Domain: SAMDOM <br />
DNS Domain: samdom.example.com <br />
DOMAIN SID: S-1-5-21-2614513918-2685075268-614796884<br />
<br />
{{Imbox<br />
| type = note<br />
| text = The interactive provisioning mode supports passing further parameters to the <code>samba-tool domain provision</code> command. This enables you to modify parameters that are not part of the interactive setup.<br />
}}<br />
<br />
<br />
<br />
== Provisioning Samba AD in Non-interactive Mode ==<br />
<br />
For example, to provision a Samba AD non-interactively with the following settings:<br />
* Server role: <code>dc</code><br />
* NIS extensions enabled<br />
* Internal DNS back end<br />
* Kerberos realm and AD DNS zone: <code>samdom.example.com</code><br />
* NetBIOS domain name: <code>SAMDOM</code><br />
* Domain administrator password: <code>Passw0rd</code><br />
<br />
# samba-tool domain provision --server-role=dc --use-rfc2307 --dns-backend=SAMBA_INTERNAL --realm=SAMDOM.EXAMPLE.COM --domain=SAMDOM --adminpass=Passw0rd<br />
<br />
<br />
<br />
<br />
<br />
= Setting up the AD DNS back end =<br />
<br />
Skip this step if you provisioned the DC using the <code>SAMBA_INTERNAL</code> DNS back end.<br />
<br />
* Set up the BIND DNS server and the <code>BIND9_DLZ</code> module. For details, see [[Setting_up_a_BIND_DNS_Server|Setting up a BIND DNS Server]].<br />
<br />
* Start the BIND DNS server. For example:<br />
# systemctl start named<br />
: For details how to start services, see you distribution's documentation.<br />
<br />
<br />
<br />
<br />
= Configuring the DNS Resolver =<br />
<br />
Domain members in an AD use DNS to locate services, such as LDAP and Kerberos. For that, they need to use a DNS server that is able to resolve the AD DNS zone.<br />
<br />
On your DC, set the AD DNS domain in the <code>search</code> and the IP of your DC in the <code>nameserver</code> parameter of the <code>/etc/resolv.conf</code> file. For example:<br />
<br />
search samdom.example.com<br />
nameserver 10.99.0.1<br />
<br />
<br />
<br />
<br />
<br />
= Create a reverse zone =<br />
<br />
You can optionally add a reverse lookup zone.<br />
<br />
# samba-tool dns zonecreate <Your-AD-DNS-Server-IP-or-hostname> 0.99.10.in-addr.arpa -U Administrator<br />
Password for [administrator@SAMDOM.EXAMPLE.COM]:<br />
Zone 0.99.10.in-addr.arpa created successfully<br />
<br />
If you need more than one reverse zone (multiple subnets), just run the above command again but with the data for the other subnet.<br />
<br />
The reverse zone is directly live without restarting Samba or BIND.<br />
<br />
{{Imbox<br />
| type = note<br />
| text = You must start the Samba AD DC before you can add a reverse zone.<br />
}}<br />
<br />
<br />
<br />
<br />
<br />
= Configuring Kerberos =<br />
<br />
In an AD, Kerberos is used to authenticate users, machines, and services.<br />
<br />
During the provisioning, Samba created a Kerberos configuration file for your DC. Copy this file to your operating system's Kerberos configuration. For example:<br />
<br />
# cp /usr/local/samba/private/krb5.conf /etc/krb5.conf<br />
<br />
{{Imbox<br />
| type = important<br />
| text = Do not create a symbolic link to the the generated <code>krb5.conf</code> file. In Samba 4.7 and later, the <code>/usr/local/samba/private/</code> directory is no longer accessible by other users than the <code>root</code> user. If the file is a symbolic link, other users are not able to read the file and, for example, dynamic DNS updates fail if you use the <code>BIND_DLZ</code> DNS back end.<br />
}}<br />
<br />
The pre-created Kerberos configuration uses DNS service (SRV) resource records to locate the KDC.<br />
<br />
<br />
<br />
<br />
<br />
= Testing your Samba AD DC =<br />
<br />
To start the <code>samba</code> service manually, enter:<br />
<br />
# samba<br />
<br />
Samba does not provide System V init scripts, <code>systemd</code>, <code>upstart</code>, or other services configuration files.<br />
* If you installed Samba using packages, use the script or service configuration file included in the package to start Samba.<br />
* If you built Samba, see [[Managing_the_Samba_AD_DC_Service|Managing the Samba AD DC Service]].<br />
<br />
<br />
<br />
== Verifying the File Server (Optional)==<br />
<br />
To list all shares provided by the DC:<br />
<br />
Before Samba 4.11.0:<br />
<br />
$ smbclient -L localhost -N<br />
Anonymous login successful<br />
Domain=[SAMDOM] OS=[Unix] Server=[Samba x.y.z]<br />
<br />
Sharename Type Comment<br />
--------- ---- -------<br />
netlogon Disk <br />
sysvol Disk <br />
IPC$ IPC IPC Service (Samba x.y.z)<br />
Domain=[SAMDOM] OS=[Unix] Server=[Samba x.y.z]<br />
<br />
Server Comment<br />
--------- -------<br />
<br />
Workgroup Master<br />
--------- -------<br />
<br />
From Samba 4.11.0:<br />
<br />
smbclient -L localhost -N<br />
Anonymous login successful<br />
<br />
Sharename Type Comment<br />
--------- ---- -------<br />
sysvol Disk <br />
netlogon Disk <br />
IPC$ IPC IPC Service (Samba 4.12.6-Debian)<br />
SMB1 disabled -- no workgroup available<br />
<br />
<br />
{{Imbox<br />
| type = note<br />
| text = The <code>netlogon</code> and <code>sysvol</code> shares were auto-created during the provisioning and must exist on a DC.<br />
}}<br />
<br />
To verify authentication, connect to the <code>netlogon</code> share using the domain administrator account:<br />
<br />
$ smbclient //localhost/netlogon -UAdministrator -c 'ls'<br />
Enter Administrator's password: <br />
Domain=[SAMDOM] OS=[Unix] Server=[Samba x.y.z]<br />
. D 0 Tue Nov 1 08:40:00 2016<br />
.. D 0 Tue Nov 1 08:40:00 2016<br />
<br />
49386 blocks of size 524288. 42093 blocks available<br />
<br />
If one or more tests fail, see [[#Troubleshooting|Troubleshooting]].<br />
<br />
<br />
<br />
== Verifying DNS (Optional)==<br />
<br />
To verify that your AD DNS configuration works correctly, query some DNS records:<br />
<br />
* The tcp-based <code>_ldap</code> SRV record in the domain:<br />
<br />
$ host -t SRV _ldap._tcp.samdom.example.com.<br />
_ldap._tcp.samdom.example.com has SRV record 0 100 389 dc1.samdom.example.com.<br />
<br />
* The udp-based <code>_kerberos</code> SRV resource record in the domain:<br />
<br />
$ host -t SRV _kerberos._udp.samdom.example.com.<br />
_kerberos._udp.samdom.example.com has SRV record 0 100 88 dc1.samdom.example.com.<br />
<br />
* The A record of the domain controller:<br />
<br />
$ host -t A dc1.samdom.example.com.<br />
dc1.samdom.example.com has address 10.99.0.1<br />
<br />
If one or more tests fail, see [[#Troubleshooting|Troubleshooting]].<br />
<br />
<br />
<br />
== Verifying Kerberos (Optional) ==<br />
<br />
This is not explicitly required, but it is a good idea to verify that your Domain Controller's authentication mechanisms are operating as intended. To test this, login by requesting a Kerberos ticket for the Domain Administrator account:<br />
<br />
$ kinit administrator<br />
Password for administrator@SAMDOM.EXAMPLE.COM:<br />
<br />
: {{Imbox<br />
| type = note<br />
| text = If you do not pass the principal in the <code>user@REALM</code> format to the <code>kinit</code> command, the Kerberos realm is automatically appended.<br />Always enter the Kerberos realm in uppercase.<br />
}}<br />
<br />
* List the cached Kerberos tickets:<br />
<br />
$ klist<br />
Ticket cache: FILE:/tmp/krb5cc_0<br />
Default principal: administrator@SAMDOM.EXAMPLE.COM<br />
<br />
Valid starting Expires Service principal<br />
01.11.2016 08:45:00 12.11.2016 18:45:00 krbtgt/SAMDOM.EXAMPLE.COM@SAMDOM.EXAMPLE.COM<br />
renew until 02.11.2016 08:44:59<br />
<br />
If one or more tests fail, see [[#Troubleshooting|Troubleshooting]].<br />
<br />
<br />
<br />
<br />
<br />
= Configuring Time Synchronization (Optional Depending on Use-Case)=<br />
<br />
Kerberos requires synchronized time on all domain members. For further details and how to set up the <code>ntpd</code> or <code>chrony</code> service, see [[Time_Synchronisation|Time Synchronization]]. However if Samba is being used as a domain controller to administer Group Policy, it is possible to define a Group Policy Object that synchronizes workstations with <code>time.windows.com</code> post installation which simplifies this<br />
<br />
<br />
<br />
= Using the Domain Controller as a File Server (Optional) =<br />
<br />
{{Imbox<br />
| type = warning<br />
| text = Do not use an AD DC as a fileserver if you have multiple DC's. You should only use a DC as a fileserver, if it is the only Samba instance running in a domain. If you have multiple DC's, you should also set up Unix domain members and use them as fileservers. You should be aware that it is problematic to use a DC as a fileserver and can cause strange errors.<br />
}}<br />
<br />
<br />
Whilst the Samba AD DC is able to provide file shares, just like all other installation modes, the Samba team does not recommend using a DC as a file server for the following reasons:<br />
<br />
* For anything but the smallest organizations, having more than one DC is a really good backup measure, and makes upgrades safer<br />
* It encourages upgrades of the DC to also be upgrades of the host OS every year or two, because there isn't complex data to transition or other services involved. <br />
* This means upgrades can be done by installing fresh, and replicating in the changes, which is better tested in Samba, gains new features and avoids a number of lingering data corruption risks. <br />
* The DC and file-server have different points at which an organization would wish to upgrade. The needs for new features on the DC and file server come at different times. Currently the AD DC is evolving rapidly to gain features, whereas the fileserver, after over 20 years, is quite rightly more conservative.<br />
* mandatory smb signing is enforced on the DC.<br />
<br />
<br />
If you do decide to use the Samba DC as a fileserver, please consider running a VM, on the DC, containing a separate Samba Unix domain member and use this instead.<br />
<br />
If you must use the Samba DC as a fileserver, you should be aware that the auto-enabled <code>acl_xattr</code> virtual file system (VFS) object enables you to only configure shares with Windows access control lists (ACL). Using POSIX ACLs with shares on a Samba DC does not work. <br />
<br />
You should be aware that if wish to use a vfs object on a DC share e.g. recycle, you must not just set <code>vfs objects = recycle</code> in the share. Doing this will turn off the default vfs objects <code>dfs_samba4</code> and <code>acl_xattr</code>. You must set <code>vfs objects = dfs_samba4 acl_xattr recycle</code>. <br />
<br />
To provide network shares with the full capabilities of Samba, set up a Samba domain member with file shares. For details, see:<br />
* [[Setting_up_Samba_as_a_Domain_Member|Setting up Samba as a Domain Member]]<br />
* [[Samba_File_Serving|Samba File Serving]]<br />
<br />
<br />
If you only have a small domain (small office, home network) and do not want to follow the Samba team's recommendation and use the DC additionally as a file server, configure Winbindd before you start setting up shares. For details, see [[Configuring_Winbindd_on_a_Samba_AD_DC|Configuring Winbindd on a Samba AD DC]].<br />
<br />
<br />
{{Imbox<br />
| type = warning<br />
| text = If you do use an AD DC as a fileserver, you must be aware that it can be problematic and can cause strange errors.<br />
}}<br />
<br />
{{Imbox<br />
| type = warning<br />
| text = If you do use an AD DC as a fileserver, do not add any of the 'idmap config' lines used on a Unix domain member. They will not work and will cause problems.<br />
}}<br />
<br />
{{Imbox<br />
| type = warning<br />
| text = If you do use an AD DC as a fileserver, You must set the permissions from Windows, do not attempt to use any of the old methods (force user etc) . They will not work correctly and will cause problems.<br />
}}<br />
<br />
<br />
<br />
<br />
<br />
= Troubleshooting =<br />
<br />
For further details, see [[Samba_AD_DC_Troubleshooting|Samba AD DC Troubleshooting]].<br />
<br />
<br />
<br />
<br />
<br />
= Further Samba-related Documentation =<br />
<br />
See [[User_Documentation|User Documentation]].<br />
<br />
<br />
<br />
<br />
<br />
----<br />
[[Category:Domain Control]]<br />
[[Category:Active Directory]]</div>Hortimechhttps://wiki.samba.org/index.php?title=Package_Dependencies_Required_to_Build_Samba&diff=18869Package Dependencies Required to Build Samba2023-04-10T15:38:34Z<p>Hortimech: </p>
<hr />
<div>= Operating System-independent Overview =<br />
<br />
The following is an operating system-independent list of libraries and utilities <u>required to build</u> and install Samba. Depending on your distribution, the name of packages can differ. Usually library packages are named <code>lib*-devel</code> or <code>lib*-dev</code>. For a list of distribution specific package installation commands, see [[#Distribution-specific_Packages_Required_to_Build_Samba|Distribution-specific Packages Required to Build Samba]].<br />
<br />
{{Imbox<br />
| type = note<br />
| text = If you do not want to build Samba yourself, see [[Distribution-specific_Package_Installation|Distribution-specific Package Installation]].<br />
}}<br />
<br />
<br />
<br />
== Mandatory ==<br />
<br />
{| class="wikitable"<br />
!Libraries and utilities<br />
!Required for<br />
|-<br />
|python3<br />
|Several utilities, such as <code>samba-tool</code> and the build system ([[Waf|Waf]]), are written in Python 3.x.<br />
|-<br />
|perl<br />
|<br />
|-<br />
|Parse::Yapp<br />
|Used in PIDL, our IDL compiler.<br />
|-<br />
|acl<br />
|Required only on [[Active_Directory_Domain_Controller|Samba Active Directory domain controllers]] and member servers using [[Setting_up_a_Share_Using_Windows_ACLs|Windows ACLs]].<br />
|-<br />
|xattr<br />
|Required only on [[Active_Directory_Domain_Controller|Samba Active Directory domain controllers]] and member servers using [[Setting_up_a_Share_Using_Windows_ACLs|Windows ACLs]].<br />
|-<br />
|gnutls >= 3.4.7<br />
|Required for cryptography<br />
|-<br />
|zlib<br />
|Provides the crc32 checksum across Samba and compression for DRSUAPI (AD replication)<br />
|}<br />
<br />
== Optional ==<br />
<br />
{| class="wikitable"<br />
!Libraries and utilities<br />
!Required for<br />
|-<br />
|krb5-devel<br />
|MIT Kerberos support (except a very bare-bones file server and if not using internal Heimdal). Requires MIT Kerberos 1.15.1 or later.<br />
|-<br />
|krb5-server<br />
|MIT Kerberos support (Samba as an AD DC if not using the internal Heimdal). Requires MIT Kerberos 1.15.1 or later.<br />
|-<br />
|blkid<br />
|<br />
|-<br />
|dbus<br />
|vfs_snapper<br />
|-<br />
|jansson-devel<br />
|Audit logging (Samba 4.7 and later), Samba AD DC<br />
|-<br />
|readline<br />
|<br />
|-<br />
|bsd or setproctitle<br />
|Process title updating support.<br />
|-<br />
|xsltproc or docbook<br />
|Man pages and other documentation.<br />
|-<br />
|pam-devel<br />
|PAM support. For example, to [[Authenticating_Domain_Users_Using_PAM|authenticate domain users using PAM]].<br />
|-<br />
|cups<br />
|[[Setting_up_Samba_as_a_Print_Server#CUPS|CUPS printer sharing support]].<br />
|-<br />
|openldap<br />
|[[NT4_Domains|NT4 Domains]] support, including the [[Migrating_a_Samba_NT4_Domain_to_Samba_AD_(Classic_Upgrade)|Samba NT4 to AD migration (Classic Upgrade)]].<br />
|-<br />
|python3-markdown<br />
|For samba-tool domain schemaupgrade<br />
|-<br />
|patch<br />
|For samba-tool domain schemaupgrade<br />
|-<br />
|gpgme-devel<br />
|For reading passwords in samba-tool user passwordsync from encrypted cleartext<br />
|-<br />
|python3-gpg or python3-gpgme<br />
|For storing passwords for samba-tool user passwordsync in encrypted cleartext<br />
|-<br />
|flex<br />
|Generates C source from the .l lexical analyzer files in our source tree. Used when building the embedded Heimdal or spotlight support<br />
|}<br />
<br />
== Selftest ==<br />
<br />
The following additional packages / utilities are required only for running some tests.<br />
<br />
{| class="wikitable"<br />
!Libraries and utilities<br />
!Required for<br />
|-<br />
|bash<br />
|Some blackbox tests are bash-specific<br />
|-<br />
|python3-iso8601<br />
|Used by our selftest and required from the system in samba 4.14 and later.<br />
|-<br />
|python3-cryptography<br />
|Used by our selftest to test Kerberos<br />
|-<br />
|python3-asn1<br />
|Used by our selftest to test ASN.1 protocols like LDAP and Kerberos<br />
|}<br />
<br />
=Packages Required to Build Samba=<br />
<br />
{{:Verified Package Dependencies}}<br />
<br />
==Manually maintained Distribution-specific Package lists==<br />
'''This list is for older Samba versions (4.10 and earlier) and distributions not included in the table above'''<br />
<br />
{{Imbox<br />
| type = warning<br />
| text = The following list of commands is neither provided nor actively verified by the Samba team. Additionally, it might be possible that you require additional or less packages than shown in the later commands - depending on the purpose you install Samba. Do not depend on the lists below, they are just a guide, use the <code>bootstrap.sh</code> scripts supplied above.<br />
}}<br />
<br />
<br />
<br />
=== Samba Active Directory Domain Controller ===<br />
<br />
The following installation commands include the BIND DNS server. If you are using the Samba internal DNS server, omit the BIND package(s). However, you require the package containing the <code>nsupdate</code> utility to enable dynamic DNS support.<br />
<br />
<br />
<br />
==== Debian / Ubuntu ====<br />
<br />
# apt-get install acl attr autoconf bind9utils bison build-essential \<br />
debhelper dnsutils docbook-xml docbook-xsl flex gdb libjansson-dev krb5-user \<br />
libacl1-dev libaio-dev libarchive-dev libattr1-dev libblkid-dev libbsd-dev \<br />
libcap-dev libcups2-dev libgnutls28-dev libgpgme-dev libjson-perl \<br />
libldap2-dev libncurses5-dev libpam0g-dev libparse-yapp-perl \<br />
libpopt-dev libreadline-dev nettle-dev perl perl-modules pkg-config \<br />
python-all-dev python-crypto python-dbg python-dev python-dnspython \<br />
python3-dnspython python-gpgme python3-gpgme python-markdown python3-markdown \<br />
python3-dev xsltproc zlib1g-dev liblmdb-dev lmdb-utils<br />
<br />
Notes:<br />
* Before Debian 8 and Ubuntu 14.04, <code>libgnutls28-dev</code> was known as <code>libgnutls-dev</code>.<br />
* perl-modules was replace by perl-modules-5.24 on Debian 9<br />
* perl-modules was replace by perl-modules-5.26 on Ubuntu 17.10<br />
* python-gpgme and python3-gpgme were replaced by python-gpg and python3-gpg on Debian 9 and Ubuntu 17.10<br />
* If you are building Samba on a system that uses systemd, you will also require the libsystemd-dev package<br />
* To use a [[Running a Samba AD DC with MIT Kerberos KDC | MIT Kerberos KDC]], you will need <code>libkrb5-dev</code> and <code>krb5-kdc</code>, version 1.15.1 or greater.<br />
<br />
<br />
==== Red Hat Enterprise Linux 8 / CentOS 8 ====<br />
<br />
Install the following packages to build Samba as an Active Directory (AD) domain controller (DC) on a minimal Red Hat Enterprise Linux (RHEL) 8 or CentOS 8 installation:<br />
<br />
# yum install docbook-style-xsl gcc gdb gnutls-devel gpgme-devel jansson-devel \<br />
keyutils-libs-devel krb5-workstation libacl-devel libaio-devel \<br />
libarchive-devel libattr-devel libblkid-devel libtasn1 libtasn1-tools \<br />
libxml2-devel libxslt lmdb-devel openldap-devel pam-devel perl \<br />
perl-ExtUtils-MakeMaker perl-Parse-Yapp popt-devel python3-cryptography \<br />
python3-dns python3-gpg python36-devel readline-devel rpcgen systemd-devel \<br />
tar zlib-devel<br />
<br />
To install all required packages, you must enable the following repositories:<br />
{| class="wikitable"<br />
!RHEL 8<br />
!CentOS 8<br />
|-<br />
|<code>Base</code><br />
|<code>Base</code><br />
|-<br />
|<code>AppStream</code><br />
|<code>AppStream</code><br />
|-<br />
|<code>CodeReady Linux Builder</code>*<br />
|<code>PowerTools</code><br />
|-<br />
|<code>EPEL</code>**<br />
|<code>EPEL</code>**<br />
|}<br />
<nowiki>*</nowiki> For further details about the CodeReady Linux Builder repository, see https://access.redhat.com/articles/4348511.<br />
<br />
<nowiki>**</nowiki> The Extra Packages for Enterprise Linux (EPEL) repository is not part of the distribution. For further details about EPEL, see https://fedoraproject.org/wiki/EPEL.<br />
<br />
For enabling PowerTools repository on CentOS 8, please use following commands:<br />
<br />
# yum -y install dnf-plugins-core<br />
# yum config-manager --set-enabled PowerTools<br />
<br />
If the DC should act as a print server with CUPS back end, additionally install the following package<br />
<br />
# yum install cups-devel<br />
<br />
==== Red Hat Enterprise Linux 7 / CentOS 7 / Scientific Linux 7 ====<br />
<br />
Install the following packages to build Samba as an Active Directory (AD) domain controller (DC) on a minimal Red Hat Enterprise Linux 7, CentOS 7, or Scientific Linux 7 installation:<br />
<br />
# yum install attr bind-utils docbook-style-xsl gcc gdb krb5-workstation \<br />
libsemanage-python libxslt perl perl-ExtUtils-MakeMaker \<br />
perl-Parse-Yapp perl-Test-Base pkgconfig policycoreutils-python \<br />
python2-crypto gnutls-devel libattr-devel keyutils-libs-devel \<br />
libacl-devel libaio-devel libblkid-devel libxml2-devel openldap-devel \<br />
pam-devel popt-devel python-devel readline-devel zlib-devel systemd-devel \<br />
lmdb-devel jansson-devel gpgme-devel pygpgme libarchive-devel<br />
<br />
<br />
{{Imbox<br />
| type = note<br />
| text = Red Hat Enterprise Linux 7 does not include all required packages to build a Samba AD DC. Enable the external Extra Packages for Enterprise Linux (EPEL) repository before you install the packages. For details, see https://fedoraproject.org/wiki/EPEL. Enabling the EPEL repository is not requied on CentOS 7 and Scientific Linux 7.<br />
}}<br />
<br />
{{Imbox<br />
| type = note<br />
| text = Red Hat Enterprise Linux 7 and deritivites do not provide a GnuTLS version >= 3.4.7, even when EPEL is used. Users building Samba 4.12 will need to obtain GnuTLS from outside RHEL7 / CentOS7 / EPEL to use Samba 4.12.<br />
}}<br />
<br />
<br />
If the DC should act as print server (not recommended) with CUPS back end, additionally install:<br />
<br />
# yum install cups-devel<br />
<br />
==== Fedora ====<br />
<br />
To install the build dependencies for Samba on Fedora, run the following command:<br />
<br />
# dnf builddep libldb samba<br />
<br />
==== openSUSE ====<br />
<br />
# zypper source-install --build-deps-only libldb1 samba<br />
<br />
==== Gentoo ====<br />
<br />
See [[Package_Dependencies_Required_to_Build_Samba/Building Samba on Gentoo|Building Samba on Gentoo]] <br />
<br />
=== Samba Domain Member ===<br />
<br />
==== Red Hat Enterprise Linux 8 / CentOS 8 ====<br />
<br />
Install the following packages to build Samba as a domain member on a minimal Red Hat Enterprise Linux (RHEL) 8 or CentOS 8 installation:<br />
<br />
# yum install autoconf automake docbook-style-xsl gcc gdb jansson-devel \<br />
krb5-devel krb5-workstation libacl-devel libarchive-devel \ <br />
libattr-devel libtasn1-tools libxslt lmdb-devel make openldap-devel \<br />
pam-devel python36-devel rpcgen<br />
<br />
To install all required packages, you must enable the following repositories:<br />
{| class="wikitable"<br />
!RHEL 8<br />
!CentOS 8<br />
|-<br />
|<code>Base</code><br />
|<code>Base</code><br />
|-<br />
|<code>AppStream</code><br />
|<code>AppStream</code><br />
|-<br />
|<code>CodeReady Linux Builder</code>*<br />
|<code>PowerTools</code><br />
|-<br />
|<code>EPEL</code>**<br />
|<code>EPEL</code>**<br />
|}<br />
<nowiki>*</nowiki> For further details about the CodeReady Linux Builder repository, see https://access.redhat.com/articles/4348511.<br />
<br />
<nowiki>**</nowiki> The Extra Packages for Enterprise Linux (EPEL) repository is not part of the distribution. For further details about EPEL, see https://fedoraproject.org/wiki/EPEL.<br />
<br />
For enabling PowerTools repository on CentOS 8, please use following commands:<br />
<br />
# yum -y install dnf-plugins-core<br />
# yum config-manager --set-enabled PowerTools<br />
<br />
If the domain member should act as a print server with CUPS back end, additionally install the following package:<br />
<br />
# yum install cups-devel<br />
<br />
==== Red Hat Enterprise Linux 7 / CentOS 7 / Scientific Linux 7 ====<br />
<br />
# yum install autoconf automake gcc gdb krb5-devel krb5-workstation \<br />
openldap-devel make pam-devel python-devel docbook-style-xsl \<br />
libacl-devel libattr-devel libxslt <br />
<br />
<br />
<br />
=== Samba NT4 PDC ===<br />
<br />
To be added.</div>Hortimech