From SambaWiki
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 theChange
button.
- Verify the computer name. If you rename the computer, reboot before joining the domain.
- Select
Domain
, enter the name of your domain, and clickOK
.
- 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 ofsamdom.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.
Время на прочтение
9 мин
Количество просмотров 73K
Мы продолжаем серию статей про взаимодействие Linux и Windows.
Теперь мы рассмотрим задачу введения в домен Windows 2008R2 сервера с операционной системой CentOS Linux (версия 6.3). Как и в последних статьях, будем пользоваться штатными средствами, поставляемыми в составе дистрибутива операционной системы. Но, в отличие от наших предыдущих статей, мы расширим задачу. Требуется организовать не только файловое хранилище на сервере под управлением CentOS Linux, но и обеспечить доступ доменных пользователей к командной и графической оболочке.
На сайте проекта CentOS можно найти информацию о настройке Samba, но эта информация касается, в основном, старых версий (CentOS 5) и охватывает небольшое количество примеров конфигурации.
Есть и другие материалы, посвященные настройке Samba для дистрибутива CentOS. В процессе написания статьи и тестирования очень пригодилось подборка статей, опубликованных на сайте. Особенно полезными оказались следующие статьи (несмотря на то, что они опубликованы в марте–апреле 2007 года):
- Active Directory Integration with Samba for RHEL/CentOS 5
- Troubleshooting Active Directory and Winbind
- Active Directory Single Sign On
Для организации тестовой сети мы будем использовать виртуальную среду VMware VSphere 5, реализованную на базе архитектуры гипервизора ESXi. Эта среда активно используется в информационно-вычислительной сети МЭИ для размещения серверов и исследовательских работ. Однако можно было бы воспользоваться и хорошо себя зарекомендовавшим Microsoft Hyper-V, а также любым другим аналогичным решением, в том числе и на основе свободного ПО, такого как гипервизор Xen или KVM.
Тестовая среда представляет собой доменную сеть на базе Active Directory (Active Directory Domain Services — AD DS), которая состоит из двух серверов инфраструктуры, работающих под управлением MS Windows Server2008 R2 EE, и одной клиентской машины — MS Windows 7 Professional. Используются IP-адреса из подсети 192.168.7.0/24.
- Наименование домена — LAB.LOCAL
- Сервер ForefrontThreat Management Gateway (TMG) 2010 — LAB-TMG.lab.local
- Клиент — LAB-CL1.lab.local
На контроллере домена LAB-DC1 установлены роли:
- cлужбы сертификации Active Directory (Active Directory Certificate Services — AD CS);
- доменные службы Active Directory (Active Directory Domain Services — AD DS);
- DHCP-сервер (Scope name: LAB.LOCAL; Address pool: 192.168.7.20–192.168.7.70);
- DNS-сервер (Type: AD-Integrated; Dynamic updates: Secure only);
- веб-службы (IIS).
Тестовая сеть и описания протоколов взаимодействия описаны в статье.
1.Требуемые пакеты
Мы устанавливаем минимально необходимый набор пакетов: рабочий стол Gnome (или другой оконный менеджер по выбору), базовый сервер и Samba. Нам потребуются:
- пакет krb5-workstation (версия не ниже 1.9), содержащий необходимые клиентские приложения для аутентификации на основе Kerberos;
- пакет oddjobmkhomedir (версия не ниже 0.30-5), предназначенный для автоматического создания каталогов пользователя при первом входе в систему;
- сам пакет Samba (версия не ниже 3.5-10), содержащий основные программы и пакет samba-winbind, отвечающий за соединение нашего сервера с контроллером домена.
2.Настройка DNS
Сначала необходимо настроить службу DNS. Это весьма важно, поскольку от корректного разрешения имен в сети зависит надежная работа нашей сети и сервисов Samba. Наш контроллер домена одновременно является и сервером DNS. Поэтому выберем в разделе Administrative Tools программу управления DNS и вручную введем имя и адрес нового сервера. На рис. 1 уже представлен результат.
Рис. 1. Задание имени и адреса в DNS.
Наш сервер DNS интегрирован с Active Directory. Можно проверить корректность прямого и обратного разрешения имен с использованием утилиты nslookup или host. Уточним: это нужно сделать обязательно, даже несмотря на то, что необходимая запись уже появилась на сервере DNS. Нужно это сделать потому, что такая проверка — лишний тест работоспособности сети и корректности настроек. Проверка с помощью утилиты host выглядит так:
host 192.168.7.10 — определение имени по адресу, и
host test-centos.lab.local — определение адреса по имени.
В результате мы должны получить корректное разрешение имен в обоих случаях.
3.Настройка сетевого адаптера
Теперь этот IP-адрес (192.168.7.10) необходимо присвоить сетевому адаптеру вновь установленного сервера CentOS Linux. Воспользуемся пунктом меню System на рабочем столе и выберем пункт Network Connections (рис. 2).
Рис. 2. Настройка сетевого соединения.
В появившемся окне настроек зададим нужный IP-адрес. В результате мы должны получить следующее — см. рис. 3.
Рис. 3. Настройка сетевого соединения. Задание IP-адреса.
Наш сервер настроен с использованием менеджера соединений (Network Manager). Поэтому нужно обязательно отметить несколько опций:
- Connect automatically, что позволяет автоматически подключать сетевой адаптер.
- Available to all users, что разрешает пользоваться этим адаптером всем пользователям.
Можно настроить сетевое соединение вручную, отредактировав файл /etc/sysconfig/networking/devices/ifcfg-eth0,
приведя его к виду, показанному на рис. 4.
Рис. 4. Настройка сетевого соединения. Файл настроек.
Ключевое слово NM_CONTROLLED разрешает или запрещает управлять соединением с использованием Network Manager.
При любом способе настроек, следует установить IP-адрес сервера DNS. Это наш контроллер домена с IP-адресом 192.168.7.2.
Для применения настроек сетевого адаптера следует выполнить команду перезапуска:
/etc/init.d/network restart
4.Настройка времени
Как уже говорилось в предыдущих статьях, корректная настройка времени очень важна для работы Active Directory. Настроить время можно с использованием штатных средств системы (см. рис. 5).
Рис. 5. Настройка времени.
Но для того, чтобы полностью избежать проблем с рассинхронизацией часов, следует настроить службу времени (демон ntpd) на синхронизацию времени с контроллером домена (см. рис. 6).
Рис. 6. Настройка службы времени.
Для этого нужно отредактировать файл /etc/ntp.conf
, указав в качестве сервера времени контроллер домена. Не забудьте настроить запуск демона ntpd с помощью команды chkconfig ntpd on
и перезапустить его командой /etc/init.d/ntpd restart
.
5.Проверка настроек
Произведя указанные настройки, следует проверить их корректность. Нужно протестировать соединение с контроллером домена, настройку времени, правильность прямого и обратного разрешения имен (см. рис. 7).
Рис. 7. Проверка настроек.
6.Настройка авторизации в домене
Теперь настала пора настроить членство нашего сервера в домене Windows. В отличие от предыдущих примеров, не будем отдельно настраивать LDAP и Kerberos. Постараемся настроить все сразу, используя утилиту командной строки authconfig, поставляемую в составе дистрибутива CentOS.
Authconfig позволяет настроить сразу все требуемые службы. При этом настраивать можно не только авторизацию в домене Windows 2008, но и использование LDAP, NIS и других способов аутентификации.
Более подробную информацию об утилите authconfig можно получить из встроенного руководства (man authconfig, онлайн-версия), либо из встроенного руководства, набрав в командной строке authconfig -help. Достаточно будет сказать, что authconfig имеет около 50 опций настройки — представляете его возможности и, одновременно, сложности в настройке? Проще воспользоваться графическим интерфейсом к authconfig — утилитой system-config-authentication (рис. 8). Эту утилиту можно вызвать из интерфейса администрирования системы, а можно и командной строкой. Причем второй вариант представляется предпочтительным, поскольку вывод диагностических сообщений будет происходить в окно терминала, что упростит поиск неисправностей.
Рис. 8. Вызов system-config-authentication.
В меню User Account Database можно выбрать место хранения списков пользователей и паролей. Возможными вариантами являются:
- локальная база данных паролей (файлы /etc/passwd и /etc/shadow);
- подключение к серверу LDAP;
- подключение к серверу NIS;
- использование Winbind — подключение к контроллеру домена Windows;
- использование IPAv2 — интегрированное решение, объединяющее LDAP, Kerberos, NTP, DNS и службу сертификатов.
IPAv2 позволяет авторизовать пользователей, рабочие станции, группы и вести политику управления сетевым доступом. IPAv2 позиционируется как решение, заменяющее NSSWITCH и PAM. Более подробная информация представлена на http://www.freeipa.org/page/Main_Page.
Поскольку нашей задачей является авторизация в домене Windows, то в качестве User Account Database мы выбираем Winbind (рис. 9).
Рис. 9. Выбор User Account Database.
Необходимо указать основные параметры для authconfig. Windows Domain — это краткое наименование домена Windows 2008R2, то, которое используется в параметре workgroup файла конфигурации Samba (/etc/samba/smb.conf). О файле конфигурации Samba мы уже рассказывали в предыдущих статьях.
Security model устанавливается в ads, что соответствует значению параметра security в файле конфигурации Samba /etc/samba/smb.conf
). Выбор security model = ads означает, что используются протоколы, совместимые со службами ADS Windows 2008R2. Другие возможные значения security model:
- Domain — централизованная авторизация с использованием домена Windows 2000/2003;
- Server — используется в тех случаях, когда Samba не является членом домена, но использует централизованное хранение пользовательских аккаунтов и паролей на сервере;
- User — используется локальная база аккаунтов и паролей пользователей. При этом требуется не только пользовательский аккаунт, но и аккаунт рабочей станции.
Параметр Winbind ADS Realm аналогичен параметру REALM в файле конфигурации Samba и относится к настройкам безопасности Kerberos. Аналогичный параметр REALM указывается в файле настроек /etc/krb5.conf
.
Поле Winbind Domain Controllers можно оставить пустым — имя контроллера домена определится из DNS. Заполнять это поле следует, если по каким-то причинам служба DNS не может определить имя и IP-адрес контроллера домена.
Весьма интересен параметр Template Shell, указывающий, какая командная оболочка будет использована при регистрации доменного пользователя на нашем сервере CentOS Linux. Возможные значения командных оболочек перечислены в файле /etc/shells
. К этим значениям утилита system-config-authentication добавляет еще /bin/false, которое используется как значение по умолчанию. Если в качестве командной оболочки указать /bin/false
, то доменным пользователям будет запрещен вход в систему. Параметр Template Shell аналогичен полю shell файла /etc/passwd
в Linux. Чтобы разрешить пользователям интерактивную работу в системе с использованием командной строки, этот параметр нужно установить в /bin/sh
или /bin/bash
.
Параметр Allow Offline Login позволяет нашему серверу CentOS Linux кэшировать пароли и, соответственно, авторизовать пользователей в случае недоступности контроллера домена.
Перейдем на вкладку Advanced Options, поскольку там есть некоторые интересующие нас параметры (см. рис. 10).
Рис. 10. Вкладка Advanced Options system-config-authentication.
На этой вкладке нас интересуют два параметра: Create home directories on the first login и Enable local access control.
Enable local access control позволяет нам указать правила регистрации пользователей на нашем сервере. Можно разрешить или запретить определенным пользователям регистрироваться с использованием терминалов или удаленных рабочих столов. Это весьма удобно, если мы хотим, например, запретить пользователям подключаться через консольный терминал. Правила регистрации и их краткое описание содержатся в файле /etc/security/access.conf
.
Параметр Create home directories on the first login позволяет снять с администратора обязанность создавать домашние каталоги для пользователей. При указании этого параметра домашний каталог создается автоматически при первом входе пользователя в систему. Но необходимо проверить корректность наличия этой опции. В CentOS Linux за это отвечает модуль pam_oddjob_mkhomedir.so, который должен быть упомянут в файле /etc/pam.d/system-auth
в строке session required pam_oddjob_mkhomedir.so skel=/etc/skel/ umask=0022
. Кроме того, домашний каталог для регистрации доменных пользователей на сервере Samba по умолчанию задается как /home/%D/%U
. Это указывается параметром template homedir в файле настроек Samba. Если использовать значение по умолчанию, то администратору необходимо создать каталог /home/, где является кратким именем домена. В нашем случае необходим каталог /home/LAB
, в котором будут автоматически создаваться домашние директории пользователей.
Теперь вернемся на вкладку Identity & Authentication утилиты system-config-authentication и включим наш сервер в домен Windows 2008 R2.
Для этого нужно выбрать действие Join Domain и ввести имя администратора домена и пароль (рис. 11). По нажатию кнопки OK, мы должны включить наш сервер в домен LAB.
Рис. 11. Указание имени и пароля администратора при вводе в домен.
Как видим, наш сервер Samba успешно включен в домен (рис. 12). Сообщение об этом появилось в окне терминала. Собственно, для этого сообщения мы и запускали system-config-authentication через командную строку в окне терминала. Если запускать через вкладку System, то сообщение о включении или невключении сервера в домен придется искать в файлах системных журналов.
Рис. 12. Включение в домен LAB.
После включения в домен в окне Authentication Configuration нажимаем кнопку Apply, и в окне терминала появляются сообщения о перезапуске Winbind и oddjobd.
Проверим включение нашего сервера в домен на контроллере (см. рис. 13).
Рис. 13. Проверка наличия в домене.
Мы видим, что наш сервер включен в домен под именем test-centos.
Теперь проверим возможность регистрации доменных пользователей на нашем сервере. Укажем доменного пользователя в ответ на приглашение о вводе имени на консоли сервера (рис. 14).
Рис. 14. Ввод имени доменного пользователя.
Как видно, имя пользователя указывается вместе с именем домена. По умолчанию разделителем является обратная косая «\». Это значение можно изменить параметром winbind separator в файле настроек Samba. Выбрав кнопку Log In, получим приглашение ввести пароль. После ввода пароля получаем рабочий стол пользователя usertest (рис. 15).
Рис. 15. Рабочий стол доменного пользователя в CentOS Linux.
Таким образом, мы успешно решили задачу включения сервера CentOS Linux в домен Windows 2008 R2 и даже разрешили доменным пользователям обращаться к рабочему столу и командной строке Linux. Это дает пользователям домена дополнительные возможности использования различных операционных систем в сети предприятия.
7.Заключение
Данная работа выполнена на базе Информационно-вычислительного центра МЭИ.
Мы будем рады вашим замечаниям и предложениям. У нас есть возможности собрать тестовую сеть и отладить на ней различные варианты и конфигурации систем для обеспечения их взаимодействия.
This howto covers adding Window workstations to an NT4 style domain and adding workstations to AD capable domains. This is typically a straight-forward process but there can be some issues if you don’t have things configured properly on your server and network or if your workstation OS version doesn’t play nice for various reasons (which is more and more common).
Preparation
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
Server Name
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
Domain 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.
Hostname
This is the fully qualified domain name that your server will be known. Primarily this is a LAN perspective. If you are using a bogus domain name for the LAN it should be based on that bogus domain name. For example, ‘server1.system.lan’. If you are using split horizon DNS then it would follow your valid fully qualified doamin name. For example, ‘server1.example.com’.
Internet Hostname
This is the hostname that would work for a valid DNS name from the outside world even if you are using bogus domain names on the inside. If you do not have a valid external name (because you having registered a domain), you can use the ‘poweredbyclear.com’ name which is designated to this box in your portal. The Internet Hostname parameter is used by programs like apache to designate your name space for your box as a distinct object from virtual names or other items. If you are using a valid domain name for your hostname (like ‘server1.example.com’ for example under split-horizon DNS), then you can simply set the value to be the exact same as the hostname.
Domain
Not to be confused with ‘Domain Name’, this is the windows NT4 style short domain name that complies with NetBIOS. You will input this information in the Windows Networking module or the Active Directory Connector module. It follows the specification for LANManager domain names instead of Internet domain names. The domain is restricted to a 15 character, caseless name without special characters. The most common practice is to use the primary element of the Domain Name as the Domain if it comports with the requirements. For example, if the Hostname is ‘server1.example.com’ then you would set the Domain to be ‘EXAMPLE’. The character limit for this value is 15 characters.
Server Name
This is the short servername used in Windows environments and complies with NetBIOS standards. It is not the full DNS name but in best practices would equal the name of the first part of the fully qualified domain name. For example, if your Hostname was ‘server1.example.com’, this name would be ‘SERVER1’.
Certificates
While this isn’t a strict requirement it is best practice to have the certificate authority of the servers set up and configured before proceeding. This should use ‘Hostname’ or ‘Internet Hostname’ configured previously for your certificate so that the names match. This will remove the certificate error if you happen to trust this CA with your workstation (which is also a best practice.)
Time and Date
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.
DNS
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.)
Split referrals to other DNS providers
In some cases it may be useful to refer ClearOS to different DNS provider for the implicit purpose of resolving a specific or several specific domains. This is recommended for Active Directory Connector and you can use this guide to assist you.
DNS includes
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.)
Hosts file
DNS lookup external
Windows 7 and later Registry Changes to join a domain
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.
Windows 10 Registry Changes to run logon scripts
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.
Microsoft seem to be pushing changes to Windows requiring the use of FQDN’ rather than NetBIOS or server names so you may have to change the above registry entries to:
[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"
where internal.domain.tld is your Default Domain from the IP Settings screen.
Enabling the SMB1.0 Protocol in Windows 10
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.
If you feel you really need to force the SMB1 protocol to be used, you can edit /etc/samba/smb.conf and add the line:
server max protocol = NT1
It is worth pointing out that it was a vulnerability in the SMB1 protocol which enabled the WannaCry virus to spread.
Outlook Authentication and Other Cryprographic Issues
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
Доброго времени, читатели и гости! Сегодня на своем блоге хочу рассмотреть сервер SAMBA, как член домена Active Directory на Windows 200x. Хочу сказать, что изначально статья планировалась с темой «дополнительный контроллер домена Active Directory Windows 200x на Linux«, но к сожалению, SAMBA может работать не более чем в режиме контроллера домена NT4 (по крайней мере, версия samba 3.х). В 4 версии SAMBA планируется режим работы в качестве полноценного контроллера домена Active Directory, но данная версия только разрабатывается и даже не вышел альфа-релиз, поэтому ставить эксперименты с сырым продуктом пока не хочется. Итак, давайте остановимся на работе SAMBA, как члена доменной структуры Active Directory. Большинство дистрибутивов Linux поддерживают интеграцию с AD «из коробки», но тру-админ должен понимать и разбираться, как все это работает. Поэтому в данной статье я рассмотрю интеграцию Linux и Windows.
Введение (теория)
Как мы знаем из прошлой статьи, основным протоколом SAMBA является SMB/CIFS. Основные задачи данного протокола — обеспечение доступа к файлам и каталогам на удаленной машине и сетевая печать. C годами данный протокол совершенствовался и с каждой новой версией поддерживал более защищенные методы аутентификации. Поддержку различных уровней аутентификации можно увидеть на приведенной иллюстрации слева, взятой с wiki журнала Linuxformat.
Итак, существует четыре основных метода аутентификации SMB/CIFS:
Открытым текстом. Использование данного метода крайне не рекомендуется, т.к. пароль передается не зашифрованым. Данный вид в современных системах по умолчанию — отключен. В SAMBA шифрование можно отключить глобальным параметром encrypted password = no в файле smb.conf.
LM (LAN Manager). Использовался в Windows до WinXP. В Samba включен по умолчанию.
NTLM/NTLMv2. Используется для аутентификации в рабочих группах. Samba совместима с NTLMv2. При аутентификации используются легко подбираемые хэши паролей.
Kerberos. В настоящее время, Kerberos является самой защищенной системой, используется криптография с секретным ключом. Применяется в доменах Active Directory (AD). Samba, начиная с версии 3 полноценно поддерживает данный протокол в виде клиента.
kerberos
Остановлюсь на протоколе kerberos поподробней, ибо с ним мы и будем работать в AD. В сети, использующей Kerberos существуют три основных элемента: клиент, центр выдачи ключей-квитанций (KDC – Key Distribution Center) и сервер авторизации. Два последние чаще всего являются одной машиной. По своей сути, Kerberos обеспечивает доверительное обслуживание третьей стороной — сервером Kerberos. Данный сервер является доверенным для всех объектов сети (пользователи, сервисы, машины и т.п.). Объекты сети, доверяющие другим объектам сделать какую-то операцию, в терминологии Kerberos называются — принципалами. У всех принципалов в доверенной сети имеется секретный пароль (он же ключ, он же билет, он же тикет) с сервером kerberos, который позволяет принципалам проверить, что информация от сервера kerberos и других объектов сети — действительна и тем самым принципалы и сервер Kerberos друг-друга аутентифицируют.
Коротко, работа Kerberos заключается в следующем: клиент, предоставляя свои логин/пароль обращается к KDC, если данный клиент существует и введенные данные верны, сервер ключей выдает клиенту тикет на доступ к серверу авторизации. Сервер авторизации проверяет, разрешен ли клиенту доступ клиента к сервису и если разрешен, то выдает клиенту билет на доступ к ресурсу. При этом, расхождение часов клиента и серверов не должно быть более 5 минут. На самом деле, все гораздо сложнее. О кербкрос более подробно можно почитать в приведенных ссылках в конце статьи.
До определенного времени Kerberos являлся технологией, которую разрабатывал MIT (Massachusetts Institute of Technology) для целей США и имелся запрет на экспорт данной технологии. Но вскоре в Королевском Технологическом Институте (Royal Institute of Technology — KTH) в Европе была создана свободная реализация Kerberos, известная как проект Heimdal Kerberos. В итоге, обе разработки имеют свободные реализации, как MIT Kerberos, так и Heimdal Kerberos.
Протокол Kerberos в среде Active Directory работает в купе со следующими компонентами операционной системы:
- Служба доменных имен DNS
- Служба каталога LDAP
- Протокол SMB
- Служба Kerberos
Каждая из них выполняет свою работу, но если хотя бы один из этих компонентов будет функционировать неправильно, то ввод клиента в домен будет невозможен.
Linux в домене Active Directory
Для реализации взаимодействия пользователей Windows (с их SID) и локальных пользователей UNIX (имеющих идентификаторы UID и GID) существует несколько подходов:
Каталог LDAP AD как источник проверки подлинности. Active Directory и является типичным LDAPv3-каталогом, при этом, при проверке подлинности силами LDAP имя пользователя и пароль передаются без шифрования — открытым текстом. Это, естественно, небезопасно. Для решения данной проблемы возможно использовать шифрование SSL, но добавляет определенный объем танцев с бубном при дополнительной настройке AD, а так же лишнюю нагрузку на контроллер домена. При этом Name Service Switch (NSS) работает напрямую с LDAP. Данный вид хранения информации о соответствии пользователей Windows и Linux удобен при использовании NT4 PDC организованном на SAMBA с хранением информации в базе LDAP.
Демон Winbind. При данном способе, NSS настраивается на работу с Winbind, а Winbind в свою очередь занимается «разрешением» имен пользователей (точнее идентификаторов SID) в UID и GID с помощью LDAP, RPC и/или Kerberos — вызовов и создается (кэшируется) запись о пользователе в файлах демона winbindd: winbindd_idmap.tdb и winbindd_cache.tdb. Данный способ мы и будем рассматривать.
Если для получения информации о пользователях не используется LDAP Active Directory, каждый сервер SAMBA — член Active Directory поддерживает свою уникальную базу данных присоединений пользователей. Это значит, что почти бесспорным является тот факт, что пользователь, имеющий доступ к двум серверам — членам домена не имеет того же самого UID/GID на обоих серверах, в тоже время это прозрачно для пользователя сети Windows, потому что мы разграничиваем доступ к ресурсам на основании имен пользователей и групп, а не на основании UID и GID. Данные о пользователях хранятся (кэшируются) в файлах winbindd_idmap.tdb и winbindd_cache.tdb.
Введение Linux в домен Active Directory
Исходные данные
NetBIOS имя домена — AD
Полное имя домена — AD.local
Имена контроллеров домена — dc.AD.local и dc2.AD.local
IP контроллеров домена — 10.0.0.2 и 10.0.0.1 соответственно
Адресация локальной сети — 10.0.0.1/24 (он же 10.0.0.1/255.255.255.0)
IP SAMBA-сервера — 10.0.0.11
Имя SAMBA-сервера — files.AD.local
Подготовка системы
Пример включения в домен буду рассматривать на Debian 6. Все нижеуказанные шаги можно вполне применить к другому дистрибутиву. Samba предоставляет собой три демона: smbd, nmbd и winbindd. smbd — отвечает за общий доступ к файлам и принтерам, nmbd – за разрешение имен по протоколу SMB/CIFS, регистрацию компьютера в сети и некоторые другие задачи, которые на текущий момент нам не интересны, winbindd обеспечивает связь с контроллером домена Active Directory и аутентификацию пользователей домена. В Debian, демоны smbd и nmbd содержатся в пакете samba, а winbindd – в пакете winbind. Кроме демона winbind в последнем пакете содержится утилита net (кстати, очень похожа на одноименную утилиту от Win), позволяющую выполнять множество административных задач, в том числе присоединение машины к домену AD.
1. Установим пакеты samba и winbind (мне так же понадобилось установить пакет smbclient для использования rpcclient для управления принтерами и tdb-tools для tdbackup для управления базами tdb, в которых SAMBA хранит свои настройки при подключении к домену).
2. Настроим файл hosts, задав полное доменное имя (FQDN) для сервера и проверим сделанные настройки командой hostname:
root@files:~# cat /etc/hosts 127.0.0.1 localhost 127.0.1.1 files.AD.local files root@files:~# hostname -f files.AD.local
3. Настроим файл /etc/resolv.conf, задав полное имя домена для автоматической подстановки к именам хостов и адреса DNS серверов локальной сети (более подробно об этом файле в статье Настройка сети в Linux):
root@files:~# cat /etc/resolv.conf domain AD.local search AD.local nameserver 10.0.0.2 nameserver 10.0.0.1
4. Настроим файл Name Service Switch — /etc/nsswitch.conf для указания в каком порядке NSS осуществляет поиск имен пользователей, паролей, хостов, сетей и т. д. (указаны только модифицированные строки):
root@files:~# cat /etc/nsswitch.conf passwd: compat winbind group: compat winbind shadow: compat winbind hosts: files dns wins ..............
Согласно приведенных настроек, при поиске имен пользователей, групп и паролей Linux будет последовательно обращаться к встроенной базе данных (файлам /etc/passwd, /etc/group, /etc/shadow), затем – к демону winbind. При разрешении имени хоста сначала будет использоваться файл /etc/hosts, затем DNS и, в последнюю очередь, служба имен NetBIOS. Это может пригодиться, если в вашей сети есть хосты, не зарегистрированные в DNS, но имеющие имена NetBIOS, к примеру, компьютеры под управлением Windows в составе рабочей группы.
Настройка SAMBA
1. Проверим, поддерживает ли установленный пакет работу с протоколом Kerberos и каталогом LDAP:
root@files:~# smbd -b | grep KRB HAVE_KRB5_H HAVE_KRB5_LOCATE_PLUGIN_H HAVE_ADDRTYPE_IN_KRB5_ADDRESS HAVE_DECL_KRB5_AUTH_CON_SET_REQ_CKSUMTYPE HAVE_DECL_KRB5_GET_CREDENTIALS_FOR_USER HAVE_INITIALIZE_KRB5_ERROR_TABLE HAVE_KRB5 HAVE_KRB5_AUTH_CON_SETUSERUSERKEY HAVE_KRB5_AUTH_CON_SET_REQ_CKSUMTYPE HAVE_KRB5_C_ENCTYPE_COMPARE HAVE_KRB5_C_VERIFY_CHECKSUM HAVE_KRB5_DEPRECATED_WITH_IDENTIFIER HAVE_KRB5_ENCRYPT_BLOCK HAVE_KRB5_ENCRYPT_DATA HAVE_KRB5_ENCTYPE_TO_STRING HAVE_KRB5_ENCTYPE_TO_STRING_WITH_SIZE_T_ARG HAVE_KRB5_FREE_DATA_CONTENTS HAVE_KRB5_FREE_HOST_REALM HAVE_KRB5_FREE_KEYTAB_ENTRY_CONTENTS HAVE_KRB5_FREE_UNPARSED_NAME HAVE_KRB5_FWD_TGT_CREDS HAVE_KRB5_GET_CREDENTIALS_FOR_USER HAVE_KRB5_GET_HOST_REALM HAVE_KRB5_GET_INIT_CREDS_OPT_ALLOC HAVE_KRB5_GET_INIT_CREDS_OPT_FREE HAVE_KRB5_GET_PERMITTED_ENCTYPES HAVE_KRB5_GET_RENEWED_CREDS HAVE_KRB5_KEYBLOCK_IN_CREDS HAVE_KRB5_KEYTAB_ENTRY_KEY HAVE_KRB5_KEYUADE_APP_DATA_CKSUM HAVE_KRB5_KT_FREE_ENTRY HAVE_KRB5_LOCATE_KDC HAVE_KRB5_MK_REQ_EXTENDED HAVE_KRB5_PRINCIPAL2SALT HAVE_KRB5_PRINCIPAL_COMPARE_ANY_REALM HAVE_KRB5_PRINC_COMPONENT HAVE_KRB5_PRINC_REALM HAVE_KRB5_SET_DEFAULT_TGS_ENCTYPES HAVE_KRB5_SET_DEFAULT_TGS_KTYPES HAVE_KRB5_SET_REAL_TIME HAVE_KRB5_STRING_TO_KEY HAVE_KRB5_TKT_ENC_PART2 HAVE_KRB5_USE_ENCTYPE HAVE_KRB5_VERIFY_CHECKSUM HAVE_LIBGSSAPI_KRB5 HAVE_LIBKRB5 HAVE_MAGIC_IN_KRB5_ADDRESS HAVE_SHORT_KRB5_MK_ERROR_INTERFACE HAVE_TICKET_POINTER_IN_KRB5_AP_REQ KRB5_CREDS_OPT_FREE_REQUIRES_CONTEXT KRB5_TICKET_HAS_KEYINFO KRB5_VERIFY_CHECKSUM_ARGS root@files:~# smbd -b | grep LDAP HAVE_LDAP_H HAVE_LDAP HAVE_LDAP_ADD_RESULT_ENTRY HAVE_LDAP_INIT HAVE_LDAP_INITIALIZE HAVE_LDAP_SASL_WRAPPING HAVE_LDAP_SET_REBIND_PROC HAVE_LIBLDAP LDAP_SET_REBIND_PROC_ARGS
Если у вас вывод похож на указанный значит все ок. Если вывод не содержит строчек с надписями KRB5 и LDAP, значит нужно скачать исходники и собрать демон с поддержкой Kerberos. Как собирать ПО из исходников — я писал в статье Управление программным обеспечением в Linux.
2. Настроим САМБА для ввода в домен
root@files:~# # переместим оригинальный файл для ознакомления в будущем root@files:~# mv /etc/samba/smb.conf /etc/samba/smb.conf.orig root@files:~# root@files:~# # создадим файл, следующего содержания, root@files:~# # в котором будут содержаться комментарии: root@files:~# root@files:~# cat /etc/samba/smb.conf.comment [global] # NetBIOS-имя хоста (должно совпадать с значением в hosts) netbios name = FILES # уровень безопасности (ads - член домена AD) security = ads # NetBIOS имя домена workgroup = AD # область работы kerberos \ # (совпадает с именем домена и записывается прописными буквами) realm = AD.LOCAL # метод аутентификации smbd (с помощью winbind) auth methods = winbind # имена сервера паролей - КД password server = dc.ad.local dc2.ad.local # настройки демона winbind: # мапить пользователей на следующий диапазон ЮИД idmap uid = 10000-20000 # мапить группы на следующий диапазон ГИД idmap gid = 10000-20000 # разделитель домена и объекта winbind separator = ^ # разрешить приложениям (например passwd) перечислять пользователей # и группы из домена AD (необязательно) winbind enum users = Yes winbind enum groups = Yes # разрешить сторонним приложениям ссылаться на пользователей AD # как на локальных, не указывая имя домена и символ-разделитель winbind use default domain = yes # разрешить кэширование авторизованных пользователей # (на случай, если КД станет недоступен) - на время настройки лучше отключить #winbind offline logon = yes # НЕ заставлять nmbd-сервер быть мастер-сервером Wins preferred master = No # оприеделить лог-файл (по умолчанию - сислог) log file = /var/log/samba/log.new # уровень логирования (можно менять от 0-минимальный до 9 - максимальный) log level = 3 # действие при крушении демона panic action = /usr/share/samba/panic-action %d # принтеры нам не нужны #load printers = no #show add printer wizard = no #disable spoolss = yes # принтеры нам нужны printing = CUPS cups options = raw show add printer wizard = yes # использовать только порт 139 # (немного ускоряет обращения и избавляет от некоторых ошибок в логе) smb ports = 139 # файл ручного мапинга пользователей username map = /etc/samba/smbusers # ускорим работу самба socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192 root@files:~# # проверим корректность файла и сформируем итоговый конфигурационный файл root@files:~# testparm -s /etc/samba/smb.conf.comment > /etc/samba/smb.conf Load smb config files from /etc/samba/smb.conf.comment rlimit_max: rlimit_max (1024) below minimum Windows limit (16384) Loaded services file OK. Server role: ROLE_DOMAIN_MEMBER
В документации Samba указывается, что параметр password server не обязателен, поскольку Samba умеет находить сервер паролей, используя SRV-записи DNS. Однако автоопределение сервера паролей срабатывает не всегда, особенно в старых версиях Samba. В Windows 200x для отделения имени домена от имени пользователя используется обратная косая черта. В Linux это может привести к проблемам, поскольку данный символ трактуется как служебный, для решения данной проблемы введен параметр winbind separator, заменяющий \ на указанный символ.
После проведенных тестов, можно однозначно утвердить, что указанный параметр socket options однозначно в разы ускоряет работу samba.
3. Удаляем если есть (или переносим в резервные копии) файлы из /var/lib/samba/*.tdb. Данное действие актуально, если самба ранее была подключена к домену, т.к. в данных файлах хранятся кэш настроек SAMBA. Описание каждого файла можно почитать по ссылкам в конце статьи.
4. Синхронизируем время
Для корректной работы SAMBA, как клиента домена Active Directory, расхождение часов не должно превышать 5 минут. Точнее сказать — этого требует протокол Kerberos. Для решения вопроса синхронизации времени я предлагаю использовать демона ntpd. Как его установить я описывал в статье Сервер точного времени на Linux, поэтому ограничусь приведением рабочего конфига для клиента сети Windows:
root@files:~# cat /etc/ntp.conf server dc.ad.local server dc2.ad.local restrict default ignore restrict dc.ad.local noquery notrap restrict dc2.ad.local noquery notrap restrict 127.0.0.1 nomodify notrap
Для синхронизации времени можно использовать, так же команду net time set в cron.
На данном этапе можно перегрузить машину для применения всего выше сделанного.
Ввод SAMBA в домен Active Directory
После загрузки машины — убеждаемся, что время не отстаёт от доменного и выполняем команду:
root@files:~# net ads join -U domain_admin Enter domain_admin's password: Using short domain name -- AD Joined 'FILES' to realm 'ad.local'
Вместо учетной записи «domain_admin» необходимо использовать имя пользователя с правом присоединения компьютера к домену. Стоит обратить внимание, что если в конфиге «самба» не указан параметр winbind use default domain, то имя пользователя необходимо вводить в формате [email protected]. Сообщения выводимые после выполнения команды обозначают следующее: Using short domain name — AD и Joined ‘FILES’ to realm ‘ad.local’ указывают на удачный ввод в домен. Если после выполнения команды не было ошибки Join to domain is not valid, значит скорее всего, ввод в домен произведен успешно.
У меня при первой попытке вывалилось сообщение
[2011/07/31 01:52:14.769838, 0] libads/kerberos.c:333(ads_kinit_password) kerberos_kinit_password [email protected] failed: Preauthentication failed
но тем не менее сервер был включен в домен. В списках рассылки видел, что эта ошибка связана с некорректной работой библиотек отвечающих за Kerberos. Как избавиться от ошибки — решения не нашел.
Далее, для корректной работы SAMBA с доменной аутентификацией Active Directory, необходимо перезапустить демонов samba и winbind, после чего можно просмотреть список доменных учетных записей:
root@files:~# # попытка получить список пользователей до перезапуска служб root@files:~# wbinfo -u Error looking up domain users root@files:~# # перезапуск служб root@files:~# service samba restart Stopping Samba daemons: nmbd smbd. Starting Samba daemons: nmbd smbd. files ~ # service winbind restart Stopping the Winbind daemon: winbind. Starting the Winbind daemon: winbind. root@files:~# # попытка получить список пользователей после перезапуска служб root@files:~# wbinfo -u FILES^nobody guest administrator krbtgt domain_user1 domain_user2 ... root@files:~# # попытка получить информацию о пользователе после перезапуска служб root@files:~# id domain_user13 uid=10002(domain_user13) gid=10002(domain users) группы=10002(domain users),10007(it),10010(акцизный склад),10011(sql_ts),10006(it-dep),10007(it),10001(BUILTIN^users) root@samba:~# getent passwd domain_user11 domain_user11:*:10002:10009::/home/AD/domain_user11:/bin/false
Все. После данных манипуляций наш Linux — в домене AD. И через сетевое окружение можно на него зайти без ввода пароля, только там не будет расшаренных ресурсов, их мы создадим позднее.
Диагностика SAMBA при включении в домен AD
Если включение в домен завершилось ошибкой, необходимо:
- Проверить настройки DNS на Linux и убедиться, что команда hostname -f выводит корректное FQDN-имя хоста.
- Проверить, в состоянии ли утилиты nslookup или dig разрешить имя КД Active Directory в IP.
- Проверить, поддерживает ли установленный пакет samba работу с Kerberos и LDAP.
- Если вышеуказанные шаги не помогли, можно выполнить тестовое подключение к домену с увеличенным значением log level(параметр -d увеличивает уровень журналирования), тем самым выявив ошибку подключения:
- net ads testjoin -d 10 -Udomain_admin
Для большего понимания взаимодействия SAMBA с инфраструктурой Active Directory приведу (справа) иллюстрацию (взято с Linuxformat).
Существует распространенное заблуждение, что Linux (samba) при входе в домен не в состоянии самостоятельно получить первую квитанцию от центра ключей Kerberos. Это заблуждение возникло потому что в официальном руководстве по SAMBA в одном из подготовительных шагов при введении SAMBA в AD приводится настройка файла /etc/krb5.conf и вызовов команды kinit. Данный файл содержит параметры автономного клиента Kerberos в локальной Linux и утилита linit использует именно настройки из файла /etc/krb5.conf.
Соответственно, настройка krb5.conf и выполнение kinit необходимо исключительно для тестирования связи с сервером Kerberos и выполнять эти настройки совсем не обязательно. Samba может самостоятельно выполнять весь цикл взаимодействия KDC, включая обновление квитанций по истечению срока их действия без применения сторонних утилит. Чтобы библиотеки Kerberos, которые использует самба для взаимодействия с KDC корректно были настроены и работали, SAMBA создает на базе информации из файла smb.conf файл /var/run/samba/smb_krb5/krb5.conf.AD, который и заменяет стандартный /etc/krb5.conf.
Создание разделяемых ресурсов SAMBA в домене Active Directory
Введение
Чтобы сразу избавить от ошибок в будущем при организации разделяемых ресурсов, хочу сказать, что при описании ресурсов в SAMBA конечный доступ к файлам и папкам определяется двумя параметрами. Первое — это параметры доступа, указанные в параметрах разделяемого ресурса, второе — права доступа к файловой системе. При этом, по-умолчанию, все пользователи самба обращаются к файловой системе с правами группы «остальные», если в samba не указано иное (например подключившийся пользователь не мапится в локального пользователя UNIX). То есть, кроме того, что самба определяет права доступа к разделяемому ресурсу, она может подключающемуся пользователю назначить соответствие системному локальному пользователю Linux, так, что подключившийся пользователь будет получать доступ к файловой системе с правами какого-либо примапленного (читай — назначенного, образовано от англ. mapping присоединение) локального пользователя Linux.
Это чем-то похоже на организацию доступа к файлам в Windows, в которой тек же есть права доступа к файловой системе (вкладка «Безопасность») и права доступа к разделяемому ресурсу (вкладка «Доступ»).
Права файловой системы я рассматривал в статье Права доступа в Linux, т.к. эта тема очень актуальна для текущей статьи, напомню в двух словах о правах… Итак, права в Linux определяются тремя возможностями (чтение, запись и исполнение) для трёх групп пользователей (владелец, группа, все остальные). При этом семантика, применения прав к файлам и каталогам несколько расходится. Приведу небольшую таблицу с описанием прав доступа по отношению к файлам/каталогам:
Право | Для файла | Для каталога |
Чтение (r или 4) | Чтение содержимого файла. | Просмотр содержимого каталога. Чтение списка файлов и подкаталогов. |
Запись (w или 2) | Изменение содержимого файла или удаление файла. | Изменение списка файлов и подкаталогов. В том числе удаление, переименование файлов и подкаталогов. |
Исполнение (x или 1) | Исполнение содержимого файла, как соответствующего набора команд. | Вход в каталог и вход в подкаталоги каталога. |
Файловый сервер
Общий ресурс только на чтение
Для создания ресурса на чтение, достаточно добавить в smb.conf строки:
[root@files ~]# # определим общий ресурс [root@files ~]# grep бмен -A4 /etc/samba/smb.conf.comment [Обменник] # путь к каталогу path = /shares/obmen # комментарий к ресурсу comment = Общий ресурс на чтение на сервере Samba [root@files ~]# # создадим каталог с правами: [root@files ~]# ls -ld /shares/obmen/ drwxr-xr-x 2 root root 4096 Июл 31 20:07 /shares/obmen/
из листинга видно, что владелец и группа каталога — root и права каталога — rwxr-xr-x. Соответственно, полные права имеет только владелец (rwx) — root, группа же и «остальные» имеют право только на чтение и выполнение (r-xr-x). А т.к., согласно глобальных настроек SAMBA, пользователи у нас мапяться с ID в диапазоне от 10000 до 20000, соответственно, при доступе к файловой системе — пользователь обращается как «остальные», соответственно имеет права r-x. Скажу даже больше, даже если мы зададим полные права на каталог для всех (chmod a+rwx /shares/obmen), то пользователи не смогут писать в каталог, пока мы в параметрах ресурса SAMBA не зададим данное разрешение.
Общий ресурс на чтение и запись для всех (файлопомойка)
Для организации абсолютной файлопомойки мы можем пойти следующим путем:
[root@files ~]# # зададим полные права "остальным" (rwx) [root@files ~]# chmod o+rwx /shares/obmen [root@files ~]# ls -ld /shares/obmen/ drwxr-xrwx 2 root root 4096 Июл 31 20:07 /shares/obmen/ [root@files ~]# # определим возможность записи в каталог в настройках ресурса [root@files ~]# grep бмен -A6 /etc/samba/smb.conf.comment [Обменник] # путь к каталогу path = /shares/obmen # комментарий comment = Общий ресурс на сервере Samba # включает возможность записи read only = no [root@files ~]# testparm -s /etc/samba/smb.conf.comment > /etc/samba/smb.conf Load smb config files from /etc/samba/smb.conf.comment rlimit_max: rlimit_max (1024) below minimum Windows limit (16384) Processing section "[Обменник]" Loaded services file OK. WARNING: You have some share names that are longer than 12 characters. These may not be accessible to some older clients. (Eg. Windows9x, WindowsMe, and smbclient prior to Samba 3.0.) Server role: ROLE_DOMAIN_MEMBER [root@files ~]# service samba restart Stopping Samba daemons: nmbd smbd. Starting Samba daemons: nmbd smbd.
Создав указанный конфиг, при создании каталогов и файлов в разделяемом ресурсе, они будут созданы с владельцем и основной группой, к которой принадлежит создавший объекты владелец, а так же с маской по-умолчанию:
[root@files ~]# testparm -v -s /etc/samba/smb.conf.comment | grep mask ...... create mask = 0744 ....... directory mask = 0755 ......
Для файлов — 0744, для каталогов — 755, то есть, при создании файлов — у группы и остальных будут отрезаны биты записи и исполнения, а при создании каталогов — биты записи:
[root@files ~]# ls -laR /shares/obmen/ /shares/obmen/: итого 12 drwxr-xrwx 3 root root 4096 Июл 31 20:39 . drwxr-xr-x 4 root root 4096 Июл 31 20:07 .. drwxr-xr-x 3 user1 domain users 4096 Июл 31 20:39 Новая папка /shares/obmen/Новая папка: итого 12 drwxr-xr-x 3 user1 domain users 4096 Июл 31 20:39 . drwxr-xrwx 3 root root 4096 Июл 31 20:39 .. drwxr-xr-x 2 user1 domain users 4096 Июл 31 20:39 Новая папка /shares/obmen/Новая папка/Новая папка: итого 12 drwxr-xr-x 2 user1 domain users 4096 Июл 31 20:39 . drwxr-xr-x 3 user1 domain users 4096 Июл 31 20:39 .. -rwxr--r-- 1 user1 domain users 3 Июл 31 20:39 Новый текстовый документ.txt -rwxr--r-- 1 user1 domain users 0 Июл 31 20:39 Новый точечный рисунок.bmp
Соответственно, удалить или изменить файл смогут либо сами владельцы файлов, либо root. Чтобы избежать этой проблемы и чтобы все пользователи могли ч/liитать и писать во все файлы, необходимо добавить следующие параметры в описание ресурса:
[root@files ~]# grep бмен -A10 /etc/samba/smb.conf.comment [Обменник] # путь к каталогу path = /shares/obmen # комментарий comment = Общий ресурс на сервере Samba # включает возможность записи read only = no # доступ всем на все create mask = 0666 directory mask = 0777 [root@files ~]# testparm -s /etc/samba/smb.conf.comment > /etc/samba/smb.conf Load smb config files from /etc/samba/smb.conf.comment rlimit_max: rlimit_max (1024) below minimum Windows limit (16384) Processing section "[Обменник]" Loaded serv5 минутices file OK. WARNING: You have some share names that are longer than 12 characters. These may not be accessible to some older clients. (Eg. Windows9x, WindowsMe, and smbclient prior to Samba 3.0.) Server role: ROLE_DOMAIN_MEMBER [root@files ~]# service samba restart Stopping Samba daemons: nmbd smbd. Starting Samba daemons: nmbd smbd.
В результате — все могут читать и все могут писать и удалять не зависимо от хозяина файла или каталога.
Общий ресурс только на чтение для определенной группы пользователей
Для создания ресурса на чтение для определенной группы пользователей, необходимо добавить в smb.conf строки:
[root@files ~]# # определим общий ресурс [root@files ~]# grep Бух -A7 /etc/samba/smb.conf.comment [Бухгалтерия] # путь к каталогу path = /shares/buh # комментарий comment = Каталог отдела Бухгалтерия # определим доступ для отдельной группы пользователей valid users = @"AD^Бухгалтерия", AD^domain_user [root@files ~]# # создадим каталог с правами (у группы "остальные должны быть права r-x"): [root@files ~]# ls -ld /shares/buh/ drwxr-xr-x 2 root root 4096 Июл 31 20:07 /shares/buh/
Параметр valid users определяет какой/им группе/ам пользователей или просто каким пользователям разрешен доступ к данному каталогу. Обратите внимание, что даже когда определен параметр winbind use default domain, требуется указание полного, определенного в домене имени пользователя, например valid users = @»DOMAIN\Domain Group». Обратите внимание так же на использование двойных кавычек. Символ ^ — возможно у вас будет другой, в зависимости от указанного в глобальном параметре winbind separator. Так же, обращаю ваше внимание, что на каталог, указанный в параметре path разделенного ресурса должны быть права не менее r-x для группы «остальные», чтобы подключенные пользователи могли читать файлы и просматривать содержимое каталога.
Общий ресурс только на чтение и запись для определенной группы пользователей
Для создания ресурса на чтение и запись для определенной группы пользователей, необходимо добавить в smb.conf строки:
[root@files ~]# # определим общий ресурс [root@files ~]# grep Бух -A7 /etc/samba/smb.conf.comment [Бухгалтерия] # путь к каталогу path = /shares/buh # комментарий comment = Каталог отдела Бухгалтерия # Определим доступ для записи read only = no # определим доступ для отдельной группы пользователей valid users = @"AD^Бухгалтерия", AD^domain_user # включить наследование прав доступа inherit permissions = Yes [root@files ~]# # создадим каталог с правами (у группы "остальные должны быть права rwx"): [root@files ~]# ls -ld /shares/buh/ drwxr-xrwx 2 root root 4096 Июл 31 20:07 /shares/buh/
Как видно, добавился неизвестный нам параметр inherit permissions = Yes, который задает наследовать права доступа к создаваемым файлам и каталогам от родительского. Это сделано опять же по причине того, что каталоги и файлы создаются с маской по-умолчанию.
Дополнительно
Указанные выше способы — это не единственное решение для ресурсов общего доступа для пользователей домена. Можно пойти другими путями, например назначить в файловой системе — группу-владельца каталога, поставить на каталог бит SGID для наследования владельца группы и в описании ресурса ограничиться двумя параметрами: path и read only =no.
Я, например, стараюсь использовать такую схему предоставления доступа к общим ресурсам: я стараюсь ставить права файловой системы на максимум и ограничивать доступ на уровне smb.conf и описания ресурса. То есть, права доступа на файлы у меня rw-rw-rw-, а на каталоги rwxrwxrwx и в описании ресурса я устанавливаю параметр inherit permissions для наследования указанных прав доступа. Либо можно указать параметры create mask = 0666 и directory mask = 0777, чтобы права задавались при создании файлов и каталогов. Ограничение на доступ к ресурсу через smb.conf устанавливаются параметрами valid users, write users и admin users. У этого способа так же есть дополнительный плюс. При необходимости переноса сервера на другую машину. достаточно будет сделать 3 вещи: 1. Перенести содержимое расшаренных ресурсов, 2. Назначить права 666 для файлов и 777 для каталогов и 3. Перенести Файл smb.conf. Без необходимости переноса всех баз SAMBA — tdb и отслеживания соответствия SID и локальных UID/GID.
Так же есть такой финт: в разделе [global] в smb.conf был указан параметр username map = /etc/samba/smbusers. Данный параметр очень удобен, т.к. позволяет присоединить пользователей Windows к локальным пользователям UNIX. Например, можно назначить root’ом Вашего пользователя в домене и управлять всеми общими ресурсами с полными правами:
root@samba:~# cat /etc/samba/smbusers root = AD^domain_admin
При внесении доменных пользователей в данный файл необходимо указывать полное имя в независимости от параметра winbind use default domain. Так же, возможно указать несколько пользователей или доменную группу разделенные пробелами.
Для сопоставления доменных групп по-умолчанию (т.е. таких как Domain Admins, Domain Users и др, которые создаются в SAMBA автоматом, их еще можно просмотреть командой net groupmap list или getent group) и групп UNIX, необходимо выполнить:
$ net groupmap modify ntgroup="Domain_Group" unixgroup=namegroup
Для сопоставления новых доменных групп и групп UNIX, необходимо выполнить:
$ # добавление новой группы $ net rpc group add "NewGroup" $ # сопоставление групп $ net groupmap modify ntgroup="NewGroup" unixgroup=newunixG
При этом, сопоставление сохраняется в одном из tdb файлов SAMBA.
Но! username map не работает, если в конфиге SAMBA на ресурс задан параметр valid users и пользователь, указанный в файле username map не входит в членов параметра valiud users. Чтобы обойти эту проблему, необходимо указать параметр admin users, который синтаксически аналогичен valid users, и определяет указанному пользователю работать с ресурсом в качестве пользователя root.
Кроме того, можно скрыть ресурс от общих глаз, если поставить параметр browseable = no, то ресурс не будет отображаться в проводнике, когда заходишь на сервер, но по полному пути доступ к нему будет.
Кроме стандартных прав (которых, кстати, вполне достаточно для решения основных задач по организации файлового сервера) функциональность можно расширить с помощью т.н. POSIX ACL, которые позволяют назначить права доступа нескольким владельцам или нескольким группам пользователей на уровне файловой системы. POSIX ACL ограничены всё теми же правами rwx. Полноценно редактировать права доступа аналогично Windows, например, назначать пользователю право изменения прав безопасности там возможности нет. Про данную технологию я постараюсь написать отдельную статью, а так же дам ссылки в конце — почитать о POSIX ACL.
Сервер печати в домене Active Directory
Для запуска сервера печати на нашем сервере SAMBA в домене Active Directory, необходимо проделать следующие шаги:
- Установить пакет cups (мне так же необходимо было установить пакет hplip, т.к. используются преимущественно принтеры от HP и пакет smbclient) и настроить сервер печати по вашим нуждам. Как настраивать сервер печати, я писал в статьях Сервер печати на Linux и Как работает SAMBA ч.2. Поэтому обойдусь только указанием настроек из smb.conf.
- Добавить нужные принтеры через веб-интерфейс CUPS.
- Раскомментировать в smb.confпараметры
# принтеры нам нужны printing = CUPS cups options = raw show add printer wizard = yes
- Закомментировать параметры в smb.conf:
# принтеры нам не нужны #load printers = no #show add printer wizard = no #disable spoolss = yes
- Добавить 2 дополнительных раздела:
[root@files ~]# grep "\[printers" -A15 /etc/samba/smb.conf.comment [printers] # опишем принтеры: comment = Очередь печати SMB # включаем возможность печати printable = yes # путь к спулеру path = /var/spool/samba [print$] # опишем каталог драйверов comment = Драйверы принтера # каталог драйверов path = /var/lib/samba/printers # можно писать read only = No
- Перезапустить демонов cups, samba и winbind.
- Добавить драйверы принтеров, как было описано в статье Как работает SAMBA ч.2 (автоматическая загрузка драйверов). Естественно, загружать драйвер нужно от доменного пользователя, указанного в /etc/samba/smbusers, как root.
- По вкусу настроить параметры по умолчанию для принтера через каталог «Принтеры и Факсы» на сервере самба, ибо у меня почему-то по-умолчанию устанавливался размер бумаги — Letter.
- Пользоваться сетевой печатью.
На моем сервере пришлось устанавливать единый драйвер для всех принтеров сети. Это привело к некоторым проблемам при установке драйверов. При этом, 7 шаг у меня немного растянулся и пришлось пользоваться шеллом для назначения драйвера принтеру. Меня спасла команда rpcclient. Об использовании данной команды можно почитать по ссылкам, приведенным в конце статьи. Итого, 7 шаг принял следующую последовательность:
7.1. Добавить драйвер принтера через каталог «Принтеры и факсы на севере files»: ПКМ по пустому месту — Свойства сервера. Вкладка «Драйверы — Добавить»
7.2. Назначение каждому принтеру необходимого драйвера с помощью команды rpcclient, согласно инструкции: http://samba.org/samba/docs/man/Samba-HOWTO-Collection/CUPS-printing.html#id2644219. Необходимо выполнить шаги 2,3,7-15, т.к. принтеры уже у нас установлены, драйвер тоже уже добавлен на сервер. Основная команда привязки принтера к драйверу выглядела так:
rpcclient localhost -Udomain_admin%password -c / 'setdriver printer_name "HP Universal Printing PS"'
Полезные команды управления SAMBA в домене AD
$ # отобразить (-L) список расшаренных ресурсов на хосте 10.0.0.11 анонимно (-N) $ smbclient -N -L 10.0.0.11 $ # подключиться к ресурсу share хоста 10.0.0.11 с логином username и паролем passwd $ smbclient //10.0.0.11/share -Uusername%passwd $ # просмотреть содержимое tdb-базы (необходим пакет tdb-tool) $ tdbdump /var/lib/samba/secrets.tdb $ # список доменов в сети $ wbinfo --all-domains $ # информация о домене DOMAIN $ wbinfo -D DOMAIN $ # проверить связь с доменом $ wbinfo -t
Что почитать
Протокол керберос:
в оригинале: http://web.mit.edu/kerberos/
дополнительно: http://www.oszone.net/4188/Kerberos
Описание файлов TDB SAMBA
http://samba.org/samba/docs/man/Samba-HOWTO-Collection/install.html#tdbdocs
Установка драйверов принтера с помощью утилиты rpcclient в 15 шагов
http://samba.org/samba/docs/man/Samba-HOWTO-Collection/CUPS-printing.html#id2644219
Отдельное спасибо http://wiki.linuxformat.ru/ за некоторую информацию
Главнейший документ о SAMBA: http://samba.org/samba/docs/man/Samba3-HOWTO/
Самба на русском: http://www.samba-doc.ru/
POSIX ACL в оригинале: http://www.suse.de/~agruen/acl/linux-acls/online/
Резюме
Хочу подвести маленький итог сегодняшней статье. Сегодня мы удачно (или неудачно ) интегрировали наш Linux в доменную структуру Active Directory. При этом, организовали файловое хранилище и сервер печати с автоматической загрузкой драйверов для клиентов Windows. В файловом сервере было организовано несколько типовых примеров каталогов общего доступа. Буду очень рад вашим комментариям и дополнениям.
Upd 2011.08.11: добавил параметр socket oprions
С Уважением, Mc.Sim!
Теги: Active Directory, CUPS, Debian, kerberos, Linux, Microsoft Windows, network, SAMBA
In this tutorial we will create a new Windows Server 2012 VM and add it to EXAMPLE.COM domain which we created in our previous article using Samba4 AD DC. We can use samba-tool to manage the Active Directory organization but with Windows it is always easier with GUI. Moreover it will feel friendly to anyone who is coming from a Windows background managing Windows Active Directory.
Install Windows Server 2012
Bringing up of Windows Server 2012 VM is not covered as part of this tutorial so I hope you already have your Windows VM or server.
Add Windows to Samba AD DC
Once your Windows Server is up and running, open the run prompt using Ctrl+r
and enter ncpa.cpl
This will open Network Connections window
Choose your Ethernet Card, right click and select Properties
Select «Internet Protocol Version» based on the version you are using. Since I am using IPv4 network, I will choose V4, click on Properties
Provide the IP of your DNS server in the Preferred DNS server. Since we do not have Alternate DNS Server at the moment so we will leave it to only one DNS value.
Next open the Properties of This PC and click on Change settings
Select the Computer Name TAB and click on Change
Now here we need to provide the Realm Name of our Active Directory which in this case is EXAMPLE.COM
As soon as you click on OK you will get a login prompt to authenticate to your Samba Active Directory Domain Controller
If the authentication was successful then you should get a confirmation prompt
Next the server must be rebooted to complete the process of adding Windows Server to Samba Active Directory DC.
ALSO READ: Install Oh My Zsh on Linux [Step-by-Step]
Install Remote Server Administration Tools (RSAT)
We have samba-tool command which can be used to manage Samba Active Directory DC from the Linux command line but it is more friendly to use the native Windows administrative tools instead. To do so we need to install the Remote Server Administration Tools (RSAT).
- To install RSAT feature, start Server Manager
- From the Manage menu, select Add Roles and Features.
- Click Next to the Before you begin screen.
- For Select installation type, select Role-based or Feature-based installation, and click Next.
- Select the server and click Next.
- Click Next to Server Roles as this does not require any additional role to be added.
- On the Features screen, scroll down to Remote Server Administration Tools,then expand the Feature and Role Administration Tools, select the tools you want installed, then click Next.
- Click Next to the Confirmation.
Click Install to complete the installation, then click Close once complete.
Check Domain Controllers
Now we will use our Windows Server to manage Samba Active Directory Domain Controller.
Open the run prompt on your windows workstation, and enter «dsa.msc
» which is the shortcut for «Active Directory Users and Computers«
Check the available Domain Controllers. It shows the hostname of our samba-ad.example.com
active directory
Create AD Users and Groups
Next to create users and groups in the Active Directory, click on the user icon
This will open a new pop up window where you can fill in the user details
Now you can follow the on-screen instructions to complete the process. Similarly you can create groups, add computers to the domain and much more.
Conclusion
In this tutorial we added Windows Server 2012 to our Samba Active Directory Domain Controller. Similarly you can also add any WIndows Workstation to the Samba AD and then install RSAT to manage your Domain Controller.
ALSO READ: Install & Configure FreeIPA Server in RHEL/CentOS 8
Lastly I hope the steps from the article to add Windows Workstation using Samba Domain was helpful. So, let me know your suggestions and feedback using the comment section.
Can’t find what you’re searching for? Let us assist you.
Enter your query below, and we’ll provide instant results tailored to your needs.