Ввод windows в домен samba

Introduction

After setting up a Samba Active Directory (AD) or an Samba NT4 domain, you have to join machines to the domain. Only machines joined to the domain are enabled to use domain resources. During the join, a machine account is created in the domain to authenticate the computer as a member.

In case, you are joining a Windows Server as a domain controller (DC) to an AD, see:

• Joining a Windows Server 2008 / 2008 R2 DC to a Samba AD
• Joining a Windows Server 2012 / 2012 R2 DC to a Samba AD

Use this documentation for joining a Windows client or server operating system to a Samba AD or Samba NT4 domain as a domain member.

System Requirements

Supported Windows Versions

To join a domain, the Windows edition requires the corresponding capabilities. You can join the following Windows operating systems as a domain member:

Workstation editions:

• Windows 10: Pro, Enterprise, and Education
• Windows 8 and 8.1: Pro and Enterprise
• Windows 7: Professional, Ultimate, and Enterprise
• Windows Vista: Business, Ultimate, and Enterprise
• Windows XP: Professional
• Windows 2000: Professional
• Windows NT4 (only NT4 domain support)

Server (all editions):

• Windows Server 2019
• Windows Server 2016
• Windows Server 2012 and 2012R2
• Windows Server 2008 and 2008R2
• Windows Server 2003 and 2003R2
• Windows Server 2000

Permissions

To join a machine to a domain you require:

• local administrator permissions on the computer you want to join
• credentials of a domain account that is enabled to join machines to the domain. For example:
  • the domain administrator account
  • an account with delegated permissions (AD only)

Note, that in an AD authenticated user accounts are enabled to join up to 10 machines to the domain, if the administrator has not disabled the feature. See https://support.microsoft.com/kb/243327/en

Required Settings for NT4 Domains

If you are joining the host to a Samba NT4 domain, some Windows operating systems require modifications. See Required Settings for Samba NT4 domain.

DNS Settings (AD only)

In an Active Directory (AD), a working DNS configuration is indispensable. AD uses DNS to locate domain controllers (DC), resolve host names, and for many other tasks. Ensure that the client has at least one DNS server configured, that is able to resolve the AD DNS zone. For further information, see DNS Configuration on Windows Hosts.

Date and Time Settings (AD only)

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 5 minutes (default), the client is not able to access domain resources for security reasons.

Before you join the domain, check the time configuration:

• Open the Control Panel.

• Navigate to Clock, Language and Region.

• Click Date and Time.

• Verify the date, time, and time zone settings. Adjust the settings, if necessary.

• Click OK to save the changes.

Joining a Windows Client or Server to a Domain

• Open the Control Panel.

• Navigate to System and Security / System.

• Click Change settings, next to the computer name.

• On the Computer Name tab, click the Change button.

• Verify the computer name. If you rename the computer, reboot before joining the domain.

• Select Domain, enter the name of your domain, and click OK.

Active Directory (AD) only: You can enter the NetBIOS name of the domain, if your client is able to resolve it. For example: samdom instead of samdom.example.com.

• Enter the credentials of an account that is able to join a computer to the domain. For example, the domain administrator account. Click OK to continue.

• Reboot the computer after the computer successfully joined the domain.

It is recommended that you have the following actions completed on your network before adding workstations to your domain:

• Server Name

• Certificates

• Time and Date

• DNS

• WINS

You will need to decide on the convention of the server name before setting things up. Most of this is done already in the wizard and so this consideration should happen even before you do the initial wizard. Here is a list of names that you will be asked for for your server:

• Domain Name

• Hostname

• Internet Hostname

• Domain

• Server Name

During the Wizard, in the section entitled ‘Internet Domain’, you will be asked for your Internet Domain. While you can use a domain name that employs a bogus top level domain like ‘.local’ or ‘.lan’, you can just as easily use your valid domain that you purchased from ClearCenter or some other registrar. The advantage of using a valid domain that is purchased from ClearCenter is that your boxes can tie in nicely to Dynamic DNS for ease of management and resiliency during network changes.

There is some debate about whether it is best practice or not to have a bogus domain on your LAN while employing valid domains on the internet or whether using a valid domain across the board is best.

The typical arguments for the bogus domains on LAN is that if you have a bogus domain names then you can address internal resources without revealing the IP addresses used internally to the outside. This is requires that you use a DNS server on the inside of your network. ClearOS can perform the function of this DNS server if needed.

The typical arguments for using a valid domain name on the LAN is that since you are using DNS on the inside of your LAN anyways, you can just use split-horizon DNS type topologies so that DNS inquiries on the LAN reveal the LAN servers in addition to external servers while external DNS queries only reveal externally configured server. ClearOS can perform the function of a caching split-horizon DNS server if needed. We recommend this method because it simplifies the environment.

It is essential that the time and date on your network is consistent throughout. Part of the security model for CIFS (Common Internet File System, the protocol used by Windows Networking) relies on the time being accurate between the workstation and the server (and also the server and other servers which is especially important when using the Active Directory Connector).

One approach is to point all the workstations and servers to an external time server. This is by far the easiest configuration.

Another approach is to set up ClearOS or an AD server as a network time (NTP) server and point all of the time sync for workstations and servers to this central server. Then you can point just this central server to an external time sync device. The reason why this approach is more scalable is that it works even when your external connectivity to the Internet is down. Even if the central server is not able to get an accurate time from the world-view of things, it is able to keep all the nodes close by accurate. It is ok for it to even be wrong so long as everything else is wrong together! Another advantage to this approach is that you don’t have increased usage of your internet pipe for updates to network time.

It is important to have a solid DNS strategy for your LAN infrastructure. ClearOS is capable of acting as a Caching DNS server. DNS queries to ClearOS are handled in the following order:

• Split referrals to other DNS providers

• DNS includes

• Hosts file

• DNS lookup external

ClearOS can reference other servers on your network and be used only for its own purposes, or ClearOS can be used as a primary location for DNS queries. Generally speaking, ClearOS is very fast at providing DNS resolution. In situations where there is an AD server present, it is recommended that the workstations on the network use AD for their DNS (This include deployments with Microsoft running as an AD domain controller and also situations where ClearOS is the AD domain controller, ie. Samba Directory.)

While this is not required for anything related to this specific topic, it is useful to mention. You can include DNS statements within the DNS server to override other lookups. This can be useful in poisoning a specific DNS host or redirecting it for other purposes. For example, if on the local domain is web server that has a public IP address that is forwarded into your domain, you will not be able to use the external address to get to it. But by using a DNS include you can override the external lookup and provide the internal hostname to IP address designation.

This process works for DNS names that you want to work (split horizon DNS) and for DNS names that you don’t want to work (poison DNS.)

For Windows 7 and later you will need to make changes to the workstation. You can manually make the changes using ‘regedit’ or create this as a file in notepad and save it with the ‘.reg’ extension. Then, double-click to add it to the registry. Here is the code:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanManWorkstation\Parameters]

"DomainCompatibilityMode"=dword:00000001
"DNSNameResolutionRequired"=dword:00000000

“DomainCompatibilityMode”=dword:00000001“

By setting this parameter, you tell your workstation that you want it to use NT4 style domains. There is no security risk here other than the kerberos-layer differences intrinsic between NT4 and 2000 and it does not prohibit the workstation from joining an Windows 2000 domain or later domain.

“DNSNameResolutionRequired”=dword:00000000

As part of the domain join process, Windows 2000 and later domains not only make a computer account for the domain but also create a DNS entry. The workstation then validates that the DNS entry resolves before allowing the workstation to join the domain. There is no integration point in NT4 domains to DNS so this doesn’t occur and as a result, the workstation will not join the domain. In our opinion, this was added to Windows 2000 domains and later in order to make management of DNS for workstations smoother. It doesn’t enhance security but since it is required by default and doesn’t work this way under NT4-style domains, we must disable it for the time being.

Microsoft have decided for security reasons to disable logon scripts from running in Windows 10, now preferring to use Group Policies. You cannot apply Group Policies automatically to the NT4 style of domains which ClearOS is using. To re-enable logon scripts in Windows 10 you need to make some registry changes before you join the domain. The easiest way is to create a file, say logon.reg with the following contents:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System]
"EnableLinkedConnections"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\NetworkProvider\HardenedPaths]
"\\\\*\\NETLOGON"="RequireMutualAuthentication=0, RequireIntegrity=0,RequirePrivacy=0"
"\\\\*\\SYSVOL"="RequireMutualAuthentication=0, RequireIntegrity=0,RequirePrivacy=0"
"\\\\{MyWindowsDomainName}\\netlogon"="RequireMutualAuthentication=0, RequireIntegrity=0,RequirePrivacy=0"

Change {MyWindowsDomainName} to your domain name (default is CLEARSYSTEM) then import the file by double-clicking on it before you join the domain.

If you do not enable “Windows 10 Domain Logons” in Windows Networking, you can set “RequirePrivacy=1” and the more secure SMB3 protocol will be used.

You can create a single file with both sets of registry changes. The logon script registry changes have no effect on versions of Windows prior to Windows 10.

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\NetworkProvider\HardenedPaths]
"\\\\*.internal.domain.tld\\NETLOGON"="RequireMutualAuthentication=0, RequireIntegrity=0,RequirePrivacy=0"
"\\\\*.internal.domain.tld\\SYSVOL"="RequireMutualAuthentication=0, RequireIntegrity=0,RequirePrivacy=0"
"\\\\internal.domain.tld\\netlogon"="RequireMutualAuthentication=0, RequireIntegrity=0,RequirePrivacy=0"

Windows 10, since the Fall Creators Update (1709), is no longer shipping with SMB1.0 support enabled. This means that if you enable “Windows 10 Domain Logons”, Windows 10 machines can no longer access Windows Networking (Samba) Domains. If you try to join a ClearOS Domain you may get the following popup:

The cause is that SMB1.0 support is now disabled by default in Windows 10. The link takes you to this Microsoft document. To enable SMB1.0 support see this Microsoft document or just go Control Panel > Programs and Features > “Turn Windows Features on and off” then scroll down to SMB 1.0/CIFS File Sharing Support and enable it. You will need to reboot afterwards. There is also a PowerShell method in the document.

With ClearOS7 up to date, including samba-4.7.1 and later, there is no need to enable what was formerly named “Windows 10 Domain Logons” and is now named “Force SMB1 Protocol” if enabled. If disabled, the parameter won’t show. Then you won’t need to enable SMB1.0 in your Windows 10 clients.

server max protocol = NT1

Once you have joined a domain, Outlook 2016 (and probably other versions) may no longer authenticate with the mail server if you are logged in with a domain account, but will authenticate if you are logged in with a local user account. In that case, run regedit to edit the Windows registry, navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Protect\Providers\df9d8cd0-1501-11d1-8c7a-00c04fc297eb and add a registry dword “ProtectionPolicy” if it does not exist. Then change its value to 1.

You can create a registry file, called, for example, outlook.reg and in it put:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Protect\Providers\df9d8cd0-1501-11d1-8c7a-00c04fc297eb]
"ProtectionPolicy"=dword:00000001

You can then double-click on the file to import it to the registry. You can also combine it into a single file with any of the other tweaks in this document.

The same fix will work for other cryptographic issues such as the following Security event log:

- <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
- <System>
<Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-a5ba-3e3b0328c30d}" />
<EventID>5061</EventID>
<Version>0</Version>
<Level>0</Level>
<Task>12290</Task>
<Opcode>0</Opcode>
<Keywords>0x8010000000000000</Keywords>
<TimeCreated SystemTime="2021-03-15T15:55:31.9826620Z" />
<EventRecordID>59773</EventRecordID>
<Correlation ActivityID="{298d4885-19b3-0002-c048-8d29b319d701}" />
<Execution ProcessID="712" ThreadID="3508" />
<Channel>Security</Channel>
<Computer>win10vbox.BCHC</Computer>
<Security />
</System>
- <EventData>
<Data Name="SubjectUserSid">S-1-5-21-3520332428-963461979-760293181-1000</Data>
<Data Name="SubjectUserName">aaron</Data>
<Data Name="SubjectDomainName">BCHC</Data>
<Data Name="SubjectLogonId">0x37354</Data>
<Data Name="ProviderName">Microsoft Software Key Storage Provider</Data>
<Data Name="AlgorithmName">UNKNOWN</Data>
<Data Name="KeyName">{A6AFA0E7-4B31-4028-9FFA-6813724D0BD3}</Data>
<Data Name="KeyType">%%2500</Data>
<Data Name="Operation">%%2480</Data>
<Data Name="ReturnCode">0x80090016</Data>
</EventData>
</Event>

The following System Log:

- <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
- <System>
<Provider Name="Schannel" Guid="{1f678132-5938-4686-9fdc-c8ff68f15c85}" />
<EventID>36870</EventID>
<Version>0</Version>
<Level>2</Level>
<Task>0</Task>
<Opcode>0</Opcode>
<Keywords>0x8000000000000000</Keywords>
<TimeCreated SystemTime="2021-03-15T15:55:32.5636483Z" />
<EventRecordID>5996</EventRecordID>
<Correlation ActivityID="{298d4885-19b3-0002-c048-8d29b319d701}" />
<Execution ProcessID="712" ThreadID="1020" />
<Channel>System</Channel>
<Computer>win10vbox.BCHC</Computer>
<Security UserID="S-1-5-18" />
</System>
- <EventData>
<Data Name="Type">server</Data>
<Data Name="ErrorCode">0x8009030d</Data>
<Data Name="ErrorStatus">10001</Data>
</EventData>
</Event>

And the following Application and services log (Dexcom in this case):

- <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
- <System>
<Provider Name="Dexcom Uploader" />
<EventID Qualifiers="0">0</EventID>
<Version>0</Version>
<Level>2</Level>
<Task>0</Task>
<Opcode>0</Opcode>
<Keywords>0x80000000000000</Keywords>
<TimeCreated SystemTime="2021-03-15T17:46:53.6859209Z" />
<EventRecordID>278</EventRecordID>
<Correlation />
<Execution ProcessID="0" ThreadID="0" />
<Channel>Dexcom</Channel>
<Computer>win10vbox.BCHC</Computer>
<Security />
</System>
- <EventData>
<Data>Error: SuperSocket - Error: Session: 21a7c61b-b266-4036-ac3d-1890e86ea423/127.0.0.1:50298 Unexpected error Caller: OnBeginInitStream, file path: d:\WorkShop\SuperSocket\v1.6\SocketEngine\AsyncStreamSocketSession.cs, line number: 255 Exception: System.ComponentModel.Win32Exception (0x80004005): The credentials supplied to the package were not recognized at System.Net.Security.SslState.InternalEndProcessAuthentication(LazyAsyncResult lazyResult) at System.Net.Security.SslState.EndProcessAuthentication(IAsyncResult result) at System.Net.Security.SslStream.EndAuthenticateAsServer(IAsyncResult asyncResult) at SuperSocket.SocketEngine.AsyncStreamSocketSession.OnBeginInitStream(IAsyncResult result, Boolean connect)</Data>
</EventData>
</Event>

search?q=clearos%2C%20clearos%20content%2C%20kb%2C%20bestpractices%2C%20Windows%20Networking%2C%20app-windows-networking%2C%20clearos6%2C%20clearos7%2C%20categoryserver%2C%20subcategoryfile%2C%20maintainer_dloper&btnI=lucky

# RedHat8 and derived distributions
yum install python3-markdown
# Debian
apt install python3-markdown

samba-tool domain schemaupgrade
samba-tool domain functionalprep --function-level=2012_R2 --forest-prep --domain-prep

priv=$(smbd -b | grep -i private_dir | cut -d : -f 2 | xargs)
defaultNamingContext=$(ldbsearch -H ldap://127.0.0.1 -s base -b "" defaultNamingContext | grep defaultNamingContext | cut -d : -f 2 | xargs)
schemaNamingContext=$(ldbsearch -H ldap://127.0.0.1 -s base -b "" schemaNamingContext | grep schema | cut -d : -f 2 | xargs)
ldbedit -e "sed -i 's/objectVersion:.*/objectVersion: 88/g'" -H $priv/sam.ldb '(objectClass=dMD)' -b $schemaNamingContext

samba-tool dbcheck --cross-ncs --fix --yes  --reset-well-known-acls 

if grep -q "dsdb:schema update allowed" /etc/samba/smb.conf; then     
    sed -i '/dsdb:schema update allowed=true/d' /etc/samba/smb.conf
fi
sed -i '/global/a dsdb:schema update allowed=true' /etc/samba/smb.conf
systemctl restart samba-ad-dc

  Set-ItemProperty -Path "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters"  -Name "SysVolReady" -Value  0
  Restart-Computer

Install-WindowsFeature AD-Domain-Services
Add-WindowsFeature RSAT-ADLDS
Add-WindowsFeature RSAT-ADDS-Tools
Add-WindowsFeature RSAT-DNS-Server
Add-WindowsFeature RSAT-DFS-Mgmt-Con
Add-WindowsFeature GPMC

w32tm /config /syncfromflags:manual /manualpeerlist:”NTP Server” /reliable:yes /update
w32tm /resync /force

Install-ADDSDomainController  `
   -Credential (Get-Credential "MIGRATE\Administrator") `
   -DomainName 'migrate.lab' `
   -SiteName 'Default-First-Site-Name' `
   -ReplicationSourceDC smb-adds01.migrate.lab `
   -CreateDnsDelegation:$false  `
   -DatabasePath 'C:\Windows\NTDS' `
   -InstallDns:$true  `
   -LogPath 'C:\Windows\NTDS' `
   -NoGlobalCatalog:$false `
   -SysvolPath 'C:\Windows\SYSVOL'  `
   -NoRebootOnCompletion:$true  `
   -Force:$true
Restart-Computer

  Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters" -Name "SysvolReady" -Value "1"

  shutdown -r -t 0

  Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\W32Time\Parameters" -Name "Type" -Value  "NTP"

  net stop w32time
  net start w32time

samba-tool dbcheck --cross-ncs --fix --yes  --reset-well-known-acls