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

Настройка Windows 7/8/10 для подключения
к домену управляемому Samba 4 в качестве PDC на примере Fedora 21

  Это краткое руководство по подключению к Samba 4 (в качестве контроллера домена (PDC)) Windows 7/8/10.
Настройка производилась на операционной системе Fedora 21, samba 4 + ldap для хранения учетных записей пользователей.
Подробная настройка

ldap+samba описана здесь.

.
В заметке же все приближено к боевым условиям, когда предыдущая настройка сделана, осталость только срочно подключить Windows 7/8/10.

  Если вы подключаете новоиспеченную Windows 10, то для начала необходимо поправить файл конфигурации samba.conf.

 [global]
   . . .
   max protocol = SMB3
   . . .

 

Для более ранних систем рекомендую

 [global]
   . . .
  max protocol = SMB2
   . . .

 

  Для нормальной работы необходимо сделать несколько исправлений в реестре Windows 7/8/10.

1. [HKEY_LOCAL_MACHINESYSTEMCurrentControlSetservicesLanmanWorkstationParameters]
   
   «EnableSecuritySignature»=dword:00000000
   
   «DomainCompatibilityMode»=dword:00000001
   
   «DNSNameResolutionRequired»=dword:00000000

2. [HKEY_LOCAL_MACHINESYSTEMCurrentControlSetservicesNetlogonParameters]
   
   «RequireSignOrSeal»=dword:00000001
   
   «RequireStrongKey»=dword:00000001
   
   «SealSecureChannel»=dword:00000001
   
   «SignSecureChannel»=dword:00000001

3. [HKEY_LOCAL_MACHINESYSTEMCurrentControlSetservicesTcpipParameters]
   
   «QualifyingDestinationThreshold»=dword:00000003
   
   «NV Domain»=»EXAMPLE»
   
   «NameServer»=»EXAMPLE»

4. [HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftSystemDNSClient]
   
   «NV PrimaryDnsSuffix»=»EXAMPLE»

5. [HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsa]
   
   «LMCompatibilityLevel»=dword:00000002

Где

EXAMPLE

— это имя домена вашей сети.
Перезагружаемся и производим регистрацию в домене.

 
Для особо ленивых предлагаю забрать готовый reg-файл с настройками

In this part of the Samba4 AD DC infrastructure series we will talk on how join a Windows 10 machine into a Samba4 realm and how to administer the domain from a Windows 10 workstation.

Once a Windows 10 system has been joined to Samba4 AD DC we can create, remove or disable domain users and groups, we can create new Organizational Units, we can create, edit and manage domain policy or we can manage Samba4 domain DNS service.

All of the above functions and other complex tasks concerning domain administration can be achieved via any modern Windows platform with the help of RSAT – Microsoft Remote Server Administration Tools.

Requirements

1. Create an AD Infrastructure with Samba4 on Ubuntu 16.04 – Part 1
2. Manage Samba4 AD Infrastructure from Linux Command Line – Part 2
3. Manage Samba4 AD Domain Controller DNS and Group Policy from Windows – Part 4

Step 1: Configure Domain Time Synchronization

1. Before starting to administer Samba4 ADDC from Windows 10 with the help of RSAT tools, we need to know and take care of a crucial piece of service required for an Active Directory and this service refers to accurate time synchronization.

Time synchronization can be offered by NTP daemon in most of the Linux distributions. The default maximum time period discrepancy an AD can support is about 5 minutes.

If the divergence time period is greater than 5 minutes you should start experience various errors, most important concerning AD users, joined machines or share access.

To install Network Time Protocol daemon and NTP client utility in Ubuntu, execute the below command.

$ sudo apt-get install ntp ntpdate

2. Next, open and edit NTP configuration file and replace the default NTP pool server list with a new list of NTP servers which are geographically located near your current physical equipment location.

The list of NTP servers can be obtained by visiting official NTP Pool Project webpage http://www.pool.ntp.org/en/.

$ sudo nano /etc/ntp.conf

Comment the default server list by adding a # in front of each pool line and add the below pool lines with your proper NTP servers as illustrated on the below screenshot.

pool 0.ro.pool.ntp.org iburst
pool 1.ro.pool.ntp.org iburst
pool 2.ro.pool.ntp.org iburst

# Use Ubuntu's ntp server as a fallback.
pool 3.ro.pool.ntp.org

3. Now, don’t close the file yet. Move to the top at the file and add the below line after the driftfile statement. This setup allows the clients to query the server using AD signed NTP requests.

ntpsigndsocket /var/lib/samba/ntp_signd/

4. Finally, move to the bottom of the file and add the below line, as illustrated on the below screenshot, which will allow network clients only to query the time on the server.

restrict default kod nomodify notrap nopeer mssntp

5. When finished, save and close the NTP configuration file and grant NTP service with the proper permissions in order to read the ntp_signed directory.

This is the system path where Samba NTP socket is located. Afterwards, restart NTP daemon to apply changes and verify if NTP has open sockets in your system network table using netstat command combined with grep filter.

$ sudo chown root:ntp /var/lib/samba/ntp_signd/
$ sudo chmod 750 /var/lib/samba/ntp_signd/
$ sudo systemctl restart ntp
$ sudo netstat –tulpn | grep ntp

Use the ntpq command line utility to monitor NTP daemon along with the -p flag in order to print a summary of peers state.

$ ntpq -p

Step 2: Troubleshoot NTP Time Issues

6. Sometimes the NTP daemon gets stuck in calculations while trying to synchronize time with an upstream ntp server peer, resulting the following error messages when manually trying to force time synchronization by running ntpdate utility on a client side:

# ntpdate -qu adc1
ntpdate[4472]: no server suitable for synchronization found

when using ntpdate command with -d flag.

# ntpdate -d adc1.tecmint.lan
Server dropped: Leap not in sync

7. To circumvent this issue, use the following trick to solve the problem: On the server, stop the NTP service and use the ntpdate client utility to manually force time synchronization with an external peer using the -b flag as shown below:

# systemctl stop ntp.service
# ntpdate -b 2.ro.pool.ntp.org  [your_ntp_peer]
# systemctl start ntp.service
# systemctl status ntp.service

8. After the time has been accurately synchronized, start the NTP daemon on the server and verify from the client side if the service is ready to serve time for local clients by issuing the following command:

# ntpdate -du adc1.tecmint.lan    [your_adc_server]

By now, NTP server should work as expected.

Step 3: Join Windows 10 into Realm

9. As we saw in our previous tutorial, Samba4 Active Directory can be managed from command line using samba-tool utility interface which can be accessed directly from server’s VTY console or remotely connected through SSH.

Other, more intuitively and flexible alternative, would be to manage our Samba4 AD Domain Controller via Microsoft Remote Server Administration Tools (RSAT) from a Windows workstation integrated into the domain. These tools are available in almost all modern Windows systems.

The process of joining Windows 10 or older versions of Microsoft OS into Samba4 AD DC is very simple. First, make sure that your Windows 10 workstation has the correct Samba4 DNS IP address configured in order to query the proper realm resolver.

Open Control panel -> Network and Internet -> Network and Sharing Center -> Ethernet card -> Properties -> IPv4 -> Properties -> Use the following DNS server addresses and manually place Samba4 AD IP Address to the network interface as illustrated in the below screenshots.

Here, 192.168.1.254 is the IP Address of Samba4 AD Domain Controller responsible for DNS resolution. Replace the IP Address accordingly.

10. Next, apply the network settings by hitting on OK button, open a Command Prompt and issue a ping against the generic domain name and Samba4 host FQDN in order to test if the realm is reachable through DNS resolution.

ping tecmint.lan
ping adc1.tecmint.lan

11. If the resolver correctly responds to Windows client DNS queries, then, you need to assure that the time is accurately synchronized with the realm.

Open Control Panel -> Clock, Language and Region -> Set Time and Date -> Internet Time tab -> Change Settings and write your domain name on Synchronize with and Internet time server field.

Hit on Update Now button to force time synchronization with the realm and hit OK to close the window.

12. Finally, join the domain by opening System Properties -> Change -> Member of Domain, write your domain name, hit OK, enter your domain administrative account credentials and hit OK again.

A new pop-up window should open informing you’re a member of the domain. Hit OK to close the pop-up window and reboot the machine in order to apply domain changes.

The below screenshot will illustrate these steps.

13. After restart, hit on Other user and logon to Windows with a Samba4 domain account with administrative privileges and you should be ready to move to the next step.

Step 4: Administer Samba4 AD DC with RSAT

14. Microsoft Remote Server Administration Tools (RSAT), which will be further used to administer Samba4 Active Directory, can be downloaded from the following links, depending on your Windows version:

1. Windows 10: https://www.microsoft.com/en-us/download/details.aspx?id=45520
2. Windows 8.1: http://www.microsoft.com/en-us/download/details.aspx?id=39296
3. Windows 8: http://www.microsoft.com/en-us/download/details.aspx?id=28972
4. Windows 7: http://www.microsoft.com/en-us/download/details.aspx?id=7887

Once the update standalone installer package for Windows 10 has been downloaded on your system, run the installer, wait for the installation to finish and restart the machine to apply all updates.

After reboot, open Control Panel -> Programs (Uninstall a Program) -> Turn Windows features on or off and check all Remote Server Administration Tools.

Click OK to start the installation and after the installation process finishes, restart the system.

15. To access RSAT tools go to Control Panel -> System and Security -> Administrative Tools.

The tools can also be found in the Administrative tools menu from start menu. Alternatively, you can open Windows MMC and add Snap-ins using the File -> Add/Remove Snap-in menu.

The most used tools, such as AD UC, DNS and Group Policy Management can be launched directly from Desktop by creating shortcuts using Send to feature from menu.

16. You can verify RSAT functionality by opening AD UC and list domain Computers (newly joined windows machine should appear in the list), create a new Organizational Unit or a new user or group.

Verify if the users or groups had been properly created by issuing wbinfo command from Samba4 server side.

That’s it! On the next part of this topic we will cover other important aspects of a Samba4 Active Directory which can be administered via RSAT, such as, how to manage DNS server, add DNS records and create a reverse DNS lookup zone, how to manage and apply domain policy and how to create an interactive logon banner for your domain users.

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

Server Name

Domain Name

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

DNS

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

Hosts file

DNS lookup external

Windows 7 and later Registry Changes to join a domain

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINESystemCurrentControlSetServicesLanManWorkstationParameters]

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

Windows 10 Registry Changes to run logon scripts

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionPoliciesSystem]
"EnableLinkedConnections"=dword:00000001

[HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsNetworkProviderHardenedPaths]
"\\*\NETLOGON"="RequireMutualAuthentication=0, RequireIntegrity=0,RequirePrivacy=0"
"\\*\SYSVOL"="RequireMutualAuthentication=0, RequireIntegrity=0,RequirePrivacy=0"
"\\{MyWindowsDomainName}\netlogon"="RequireMutualAuthentication=0, RequireIntegrity=0,RequirePrivacy=0"

[HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsNetworkProviderHardenedPaths]
"\\*.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"

Enabling the SMB1.0 Protocol in Windows 10

server max protocol = NT1

Outlook Authentication and Other Cryprographic Issues

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINESOFTWAREMicrosoftCryptographyProtectProvidersdf9d8cd0-1501-11d1-8c7a-00c04fc297eb]
"ProtectionPolicy"=dword:00000001

- <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>

- <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>

- <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:WorkShopSuperSocketv1.6SocketEngineAsyncStreamSocketSession.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>

Once unpublished, all posts by aciklab will become hidden and only accessible to themselves.

If aciklab is not suspended, they can still re-publish their posts from their dashboard.

Note:

Once unpublished, this post will become invisible to the public and only accessible to Duygu Ölmez.

They can still re-publish the post if they are not suspended.

Thanks for keeping DEV Community 👩‍💻👨‍💻 safe. Here is what you can do to flag aciklab:

Make all posts by aciklab less visible

aciklab consistently posts content that violates DEV Community 👩‍💻👨‍💻’s
code of conduct because it is harassing, offensive or spammy.

Мы продолжаем серию статей про взаимодействие Linux и Windows.
Теперь мы рассмотрим задачу введения в домен Windows 2008R2 сервера с операционной системой CentOS Linux (версия 6.3). Как и в последних статьях, будем пользоваться штатными средствами, поставляемыми в составе дистрибутива операционной системы. Но, в отличие от наших предыдущих статей, мы расширим задачу. Требуется организовать не только файловое хранилище на сервере под управлением CentOS Linux, но и обеспечить доступ доменных пользователей к командной и графической оболочке.
На сайте проекта CentOS можно найти информацию о настройке Samba, но эта информация касается, в основном, старых версий (CentOS 5) и охватывает небольшое количество примеров конфигурации.
Есть и другие материалы, посвященные настройке Samba для дистрибутива CentOS. В процессе написания статьи и тестирования очень пригодилось подборка статей, опубликованных на сайте. Особенно полезными оказались следующие статьи (несмотря на то, что они опубликованы в марте–апреле 2007 года):

1. Active Directory Integration with Samba for RHEL/CentOS 5
2. Troubleshooting Active Directory and Winbind
3. 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.

1. Наименование домена — LAB.LOCAL
2. Сервер ForefrontThreat Management Gateway (TMG) 2010 — LAB-TMG.lab.local
3. Клиент — LAB-CL1.lab.local

На контроллере домена LAB-DC1 установлены роли:

1. cлужбы сертификации Active Directory (Active Directory Certificate Services — AD CS);
2. доменные службы Active Directory (Active Directory Domain Services — AD DS);
3. DHCP-сервер (Scope name: LAB.LOCAL; Address pool: 192.168.7.20–192.168.7.70);
4. DNS-сервер (Type: AD-Integrated; Dynamic updates: Secure only);
5. веб-службы (IIS).

Тестовая сеть и описания протоколов взаимодействия описаны в статье.

1.Требуемые пакеты

Мы устанавливаем минимально необходимый набор пакетов: рабочий стол Gnome (или другой оконный менеджер по выбору), базовый сервер и Samba. Нам потребуются:

1. пакет krb5-workstation (версия не ниже 1.9), содержащий необходимые клиентские приложения для аутентификации на основе Kerberos;
2. пакет oddjobmkhomedir (версия не ниже 0.30-5), предназначенный для автоматического создания каталогов пользователя при первом входе в систему;
3. сам пакет 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). Поэтому нужно обязательно отметить несколько опций:

1. Connect automatically, что позволяет автоматически подключать сетевой адаптер.
2. 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 можно выбрать место хранения списков пользователей и паролей. Возможными вариантами являются:

1. локальная база данных паролей (файлы /etc/passwd и /etc/shadow);
2. подключение к серверу LDAP;
3. подключение к серверу NIS;
4. использование Winbind — подключение к контроллеру домена Windows;
5. использование 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:

1. Domain — централизованная авторизация с использованием домена Windows 2000/2003;
2. Server — используется в тех случаях, когда Samba не является членом домена, но использует централизованное хранение пользовательских аккаунтов и паролей на сервере;
3. 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.

Данная работа выполнена на базе Информационно-вычислительного центра МЭИ.
Мы будем рады вашим замечаниям и предложениям. У нас есть возможности собрать тестовую сеть и отладить на ней различные варианты и конфигурации систем для обеспечения их взаимодействия.

Функционал обычного файлового сервера неизменно остается одним из самых популярных и востребованных в работе среднестатистического офиса. Сегодня я расскажу как установить и настроить файловый сервер Samba с авторизацией в AD и управлением доступом с помощью доменных учетных записей. Сразу скажу, что тема это достаточно трудная и хрупкая, очень часто что-то идет не так, нужно неплохо ориентироваться в теме, чтобы решать возникающие проблемы.

Прежде чем начинать настройку файлового сервера samba, прочитайте полностью материал, чтобы решить, каким способом будете настраивать. По ходу написания статьи у меня получились 2 принципиально разных решения.

Введение

Ранее я рассказывал как сделать очень простую и быструю настройку самбы, когда доступ ограничивается либо внутренними пользователями самбы, либо с помощью ip. Если вас такой формат эксплуатации файлового сервера устраивает, то читать дальше не обязательно. Используйте приведенную статью, и у вас все получится очень быстро.

Для более сложной настройки самбы с авторизацией в Active Directory будем разбираться дальше. Существует как минимум 2 способа добавления linux сервера в домен Windows Server:

• Использовать известное и универсальное средство winbind.
• Либо воспользоваться менее популярным, но как мне кажется, более удобным и простым в настройке — sssd.

Если у вас еще нет готового сервера, то можете воспользоваться моими материалами на эту тему — установка и настройка centos 7. Так же рекомендую настроить iptables для корректной работы сервера с доменом windows. Далее я не буду касаться этого вопроса, мы просто отключим фаерволл, потому что его настройка не тема этой статьи.

Настраивать файловую шару samba будем на сервере под управлением CentOS 7 следующей версии:

Вводные слова я все сказал. Начнем настройку самбы с ввода сервера в домен.

Добавляем сервер к домену через realm

Я не буду придумывать ничего нового, а полностью воспользуюсь инструкцией из приведенной выше статьи по настройке авторизации доменных учеток на сервере, но при этом не буду настраивать саму авторизацию. В данном случае мне это не нужно.

Итак, отключаем firewall и SELinux, если не сделали это раньше. Если не хотите отключать, то настройте сами. Данная настройка выходит за рамки статьи.

# mcedit /etc/sysconfig/selinux

меняем значение

SELINUX=disabled

Выполняем команду, чтобы не ждать перезагрузки для применения изменений.

setenforce 0

Выключаем firewalld.

# systemctl stop firewalld
# systemctl disable firewalld

Перед дальнейшей настройкой, убедитесь, что с вашего сервера centos вы без проблем пингуете и резолвите контроллер домена по полному имени. Если есть какие-то проблемы, исправьте это либо указанием нужного dns сервера, либо правкой файла hosts.

Настроим синхронизацию времени с контроллером домена. Это важно, у вас должно быть одинаковое время с контроллером домена. Проверьте его и убедитесь, что стоят одинаковые часовые пояса.

Устанавливаем утилиту для синхронизации времени chrony:

# yum install chrony

Добавляем в конфиг /etc/chrony.conf адрес контроллера домена. И делаем его единственным сервером для синхронизации, остальные удаляем.

server xs-winsrv.xs.local iburst

Сохраняем конфиг, запускаем chrony и добавляем в автозагрузку.

# systemctl start chronyd && systemctl enable chronyd

Проверим, что с синхронизацией.

Устанавливаем софт, который понадобится для дальнейшей работы.

# yum install realmd sssd sssd-libwbclient oddjob oddjob-mkhomedir adcli samba-common samba-common-tools

Делаем проверку перед вводом в домен.

# realm discover XS.LOCAL
xs.local
 type: kerberos
 realm-name: XS.LOCAL
 domain-name: xs.local
 configured: no
 server-software: active-directory
 client-software: sssd
 required-package: oddjob
 required-package: oddjob-mkhomedir
 required-package: sssd
 required-package: adcli
 required-package: samba-common-tools

Заводим в домен.

# realm join -U admin51 XS.LOCAL
Password for admin51:

Если не получили никакой ошибки, значит все прошло нормально. Можно зайти на контроллер домена и проверить, появился ли наш linux сервер в домене.

Проверьте на самом сервере, что он нормально обращается к домену и получает информацию об учетных записях. Показываю на примере доменной учетной записи control.

# id control@xs.local
uid=185001305(control@xs.local) gid=185000513(пользователи домена@xs.local) groups=185000513(пользователи домена@xs.local),185001329(gr_y@xs.local),185001651(gr_sams2@xs.local),185001327(gr_z@xs.local)

Еще несколько проверок.

# realm list

# adcli info xs.local

Сервер завели в домен. Приступаем к основному — настройке samba с интеграцией в AD.

Настройка Samba с интеграцией в AD через sssd

Устанавливаем сам файловый сервер самба.

# yum install samba

Рисуем ему примерно такой конфиг.

# cat /etc/samba/smb.conf

[global]
workgroup = XS
server string = Samba Server Version %v
log file = /var/log/samba/log.%m
log level =3
max log size = 500
security = ads
encrypt passwords = yes
passdb backend = tdbsam
realm = XS.LOCAL
load printers = no
cups options = raw
printcap name = /dev/null

[shara]
comment = My shared folder
path = /mnt/shara
public = no
writable = yes
guest ok = no
valid users = @"gr_it@xs.local"

Запускаем службу smb.service и добавляем в автозагрузку.

# systemctl start smb.service
# systemctl enable smb.service

Теперь идем проверять подключение к сетевому диску с какой-нибудь виндовой машины. Здесь меня ждало полное разочарование. Ничего не работало. Я бился над решение проблемы примерно 2 дня, но не смог победить. Перелопатил весь гугл по запросу «sssd samba», но не смог заставить работать эту связку.

Через поиск нашел как людей, которые бились над решением проблемы с теми же ошибками, что и у меня, так и тех у кого все работало нормально. Я проверил все гайды и конфиги, где люди говорили, что такая связка работает, но у меня она все равно не работала. Видел сообщения людей, которые так же как я, не смогли победить ошибки. Думаю, проблема кроется в различных версиях софта.

Мне стало жаль тратить время на поиски готового решения с sssd, хотя мне очень хотелось получить рабочий вариант, так как с winbind достаточно часто возникают проблемы. Я надеялся от них избавиться переходом на sssd, но не получилось. Статью не стал переделывать, сохранив то, что уже настроил. Может быть у вас заработает.

Попутно узнал, что sssd не поддерживает NTLM авторизацию, только kerberos. Я не знаю, по какой причине, но у меня самба, судя по логам, упорно пыталась авторизовать пользователя по ntlm. В итоге, я прекратил попытки и вернулся к старому проверенному варианту с winbind. Далее расскажу, как настроить файловый сервер samba для работы в домене windows с помощью winbind.

Вводим CentOS 7 в домен с помощью winbind

Если у вас виртуальная машина, проще установить ее с нуля. Если не хочется по какой-то причине, можно просто удалить все установленные ранее пакеты через команду yum remove. Я поступил именно так.

Устанавливаем недостающие пакеты:

# yum install samba-winbind samba-winbind-clients samba pam_krb5 krb5-workstation chrony

Не забудьте о настройке синхронизации времени, которую мы делали на предыдущих шагах. Надо это проделать, если вы сразу начали настройку с данного пункта. Так же убедитесь, что все в порядке с dns, и контроллеры домена пингуются по именам.

Формируем конфиг для kerberos.

# authconfig --enablekrb5 --krb5kdc=xs-winsrv.xs.local --krb5adminserver=xs-winsrv.xs.local --krb5realm=XS-WINSRV.XS.LOCAL --enablewinbind --enablewinbindauth --smbsecurity=ads --smbrealm=XS.LOCAL --smbservers=xs-winsrv.xs.local --smbworkgroup=XS --winbindtemplatehomedir=/home/%U --winbindtemplateshell=/bin/bash --enablemkhomedir --enablewinbindusedefaultdomain --update

Для удобства дублирую таблицу с информацией, чтобы не пришлось скролить страницу вверх.

Вывод после работы команды у меня такой:

Job for winbind.service failed because the control process exited with error code. See "systemctl status winbind.service" and "journalctl -xe" for details.

Это не страшно, продолжаем настройку. Заводим сервер с CentOS в домен:

# net ads join -U admin51

На выходе получил:

Enter admin51's password:
Using short domain name -- XS
Joined 'XS-DESIGN' to dns domain 'xs.local'
No DNS domain configured for xs-design. Unable to perform DNS Update.
DNS update failed: NT_STATUS_INVALID_PARAMETER

В принципе, ничего страшного. Нам придется самим создать A запись на DNS сервере. Я не понимаю, почему иногда она не создается автоматически. Во время написания статьи, я использовал один сервер, у него не было этой ошибки при вводе в домен. Когда проверял статью на втором сервере, получил эту ошибку. Проверяем на контроллере домена в списке компьютеров наш сервер и создаем руками А запись, соответствующую имени сервера и его IP адресу.

Теперь рисуем конфиг для самбы примерно такой.

# mcedit /etc/samba/smb.conf

[global]
   workgroup = XS
   password server = xs-winsrv.xs.local
   realm = XS.LOCAL
   security = ads
   idmap config * : range = 16777216-33554431
   template homedir = /home/%U
   template shell = /bin/bash
   kerberos method = secrets only
   winbind use default domain = true
   winbind offline logon = false

   passdb backend = tdbsam

   load printers = no
   show add printer wizard = no
   printcap name = /dev/null
   disable spoolss = yes

   domain master = no
   local master = no
   preferred master = no
   os level = 1

   log level = 3
   log file = /var/log/samba/log.%m

[shara]
   path = /mnt/shara
   writeable = yes
   browsable = yes
   valid users = "@XSПользователи домена"
   admin users = "@XSАдминистраторы домена"
   create mask = 0600
   directory mask = 0700

У меня русский язык на контроллере домена, поэтому и имена групп на русском. Проблем с этим не возникает. Не забудьте создать директорию /mnt/shara.

Запускаем samba и winbind и добавляем в автозагрузку.

# systemctl start winbind
# systemctl start smb.service
# systemctl enable winbind
# systemctl enable smb.service

Выполняем ряд проверок, чтобы убедиться, что все в порядке, winbind работает и samba будет получать актуальную информацию о пользователях и группах домена.

# wbinfo -t
checking the trust secret for domain XS via RPC calls succeeded

# wbinfo -u
# wbinfo -g

Последние две команды должны вывести список всех пользователей и групп домена.

Проверим теперь авторизацию в домене.

# wbinfo -a XS\control%'pass'
plaintext password authentication succeeded
challenge/response password authentication succeeded

В данном случае control — имя пользователя домена, pass — его пароль. Успешная проверка выглядит так, как у меня. В завершении проверок посмотрим, корректно ли система сопоставляет доменные учетные записи локальным.

# id control
uid=16777216(control) gid=16777220(пользователи домена) groups=16777220(пользователи домена),16777221(gr_z),16777222(gr_sams2),16777223(gr_y),16777217(BUILTINusers)

Все в порядке. Теперь все готово для корректной работы файлового сервера на основе Samba с доменными учетными записями. В завершении настроек, сделаем администратора домена владельцем нашей шары.

# chown admin51:'пользователи домена' /mnt/shara

Проверяем, что получилось.

# ll /mnt
total 0
drwxr-xr-x 2 admin51 пользователи домена 6 Sep 27 17:15 shara

Уберем доступ на чтение у всех остальных, оставим полные права для пользователя admin51 и на чтение у пользователей домена.

# chmod 0750 /mnt/shara

Идем на любую виндовую машину и пробуем зайти на шару по адресу \ip-адрес-сервера. Попадаем на нашу шару.Если не получилось зайти, проверьте настройки iptables. На время отладки можно их отключить. Так же убедитесь, что у вас запущена служба smb.service.

Смотрим расширенные параметры безопасности:

Получилось то, что хотели. Управлять правами доступа можно через windows acl с любой машины windows, где учетная запись пользователя домена будет обладать необходимыми правами. Если по какой-то причине это не получится (а я с такими ситуациями сталкивался достаточно часто), на помощь придут консольные утилиты getfacl для проверки прав и setfacl для изменения прав. Документация по этим командам есть в сети и легко ищется. Я рекомендую всегда использовать эти команды, когда вы выполняете изменение прав по большому дереву каталогов. Через консоль выставление прав будет выполнено раз в 5-10 быстрее, чем через windows acl. На больших файловых архивах разница может быть в десятки минут или даже часы.

Сделаю небольшое пояснение по правам доступа в файловом сервере samba. Вопрос этот сложный и объемный. Ему можно посвятить и отдельную статью. Но для полноты картины по настройке самбы, расскажу самое основное.

Как я уже ранее сказал, изменять права доступа к каталогам на файловом сервере можно с помощью команды setfacl. Давайте сейчас посмотрим на права доступа, которые установлены:

# getfacl /mnt/samba

# file: mnt/shara
# owner: admin51
# group: пользователи40домена
user::rwx
group::r-x
other::---

С такими правами что-то создавать в папке сможет только пользователь admin51, а пользователи домена смогут только просматривать файлы и каталоги. Сделаем более прикладной вариант. Добавим права доступа на чтение и запись еще одной доменной группе — gr_it.

# setfacl -m g:gr_it:rwx /mnt/shara

Обращаю внимание, что иногда при копировании команд setfacl они не отрабатывают, выдавая не очень понятную ошибку:

setfacl: Option -m: Invalid argument near character 1

Наберите команду с клавиатуры, либо просто удалите и наберите снова ключ -m, он почему-то при копировании часто дает эту ошибку.

Смотрим, что получилось:

# getfacl /mnt/shara

# file: mnt/shara
# owner: admin51
# group: пользователи40домена
user::rwx
group::r-x
group:gr_it:rwx
mask::rwx
other::---

То, что надо. Теперь пользователи группы gr_it имеют полные права на шару. Создадим одним таким пользователем папку test1 на нашей шаре и посмотрим, какие права она получит.

# getfacl /mnt/shara/test1

# file: mnt/shara/test1
# owner: user1
# group: пользователи40домена
user::rwx
group::---
other::---

Права на папку имеет только ее создатель и больше никто. Для того, чтобы наследовались права с вышестоящего каталога, необходимо на этот вышестоящий каталог добавить дефолтные права доступа. Примерно вот так.

# setfacl -m d:g:gr_it:rwx,d:g:'пользователи домена':rx /mnt/shara

Смотрим, что получилось:

# getfacl /mnt/shara

# file: mnt/shara
# owner: admin51
# group: пользователи40домена
user::rwx
group::r-x
group:gr_it:rwx
mask::rwx
other::---
default:user::rwx
default:group::r-x
default:group:пользователи40домена:r-x
default:group:gr_it:rwx
default:mask::rwx
default:other::---

Создадим теперь тем же пользователем еще одну папку test2 и проверим ее права.

# getfacl /mnt/shara/test2

# file: mnt/shara/test2
# owner: user
# group: пользователи40домена
user::rwx
group::---
group:пользователи40домена:r-x
group:gr_it:rwx
mask::rwx
other::---
default:user::rwx
default:group::r-x
default:group:пользователи40домена:r-x
default:group:gr_it:rwx
default:mask::rwx
default:other::---

Применилось наследование с вышестоящих папок. Не забывайте про дефолтные права и учитывайте их при настройке прав доступа на файловом сервере.

Для удобной и корректной работы с правами доступа я обычно для крупных, корневых директорий выставляю права аккуратно через setfacl в консоли. Какие-то мелкие изменения по пользователям и группам в более низших иерархиях директорий делаю через windows acl с какой-нибудь виндовой машины.

Еще важно знать одну особенность выставления прав доступа в linux. В моей практике часто требуется дать какому-нибудь пользователю доступ в одну директорию, которая располагается там, где у пользователя нет вообще никаких прав. В windows эта проблема решается просто — даются права на конкретную папку, а пользователю кладется ярлык на эту папку. В итоге он имеет доступ к нужной директории и больше никуда.

В linux так сделать не получится. Для того, чтобы дать таким образом доступ на отдельную директорию пользователю, необходимо, чтобы по всем вышестоящим директориям у него были права на исполнение, то есть X. Их придется выставлять вручную по всем вышестоящим папкам. Результат будет такой же, как и в винде — пользователь получит доступ на чтение только в указанную папку, но для этого придется выполнить больше действий. Если не знаешь этот нюанс, можно потратить много времени, прежде чем поймешь, в чем проблема.

Заключение

Скажу откровенно — мне не нравится, как работают файловые сервера samba с интеграцией в виндовом домене. Но настраивать их приходится часто, так как востребованный функционал. Востребован в первую очередь потому, что не требует вообще никаких денег за лицензии, и работает на минимальной конфигурации железа. Вот список типичных проблем при работе самбы в домене:

• Иногда через windows acl права перестают выставляться, возникают неинформативные ошибки, по которым невозможно понять, что не так.
• Я достаточно регулярно наблюдаю ситуацию, когда слетают соответствия доменных учеток линуксовым UID. В итоге права доступа превращаются в ничего не значащий набор цифр и перестают работать.
• При переносе данных с одного сервера на другой трудно сохранить права доступа. Можно поступить вот так для копирования прав доступа, либо как-то заморочиться, чтобы на всех серверах у вас были одинаковые UID доменных учетных записей. Я не разбирал этот вопрос подробно.

Если у вас есть возможность настроить файловый сервер на windows, либо обойтись линуксом без домена, то сделайте так. Существенно упростите настройку и дальнейшую эксплуатацию.

Доброго времени, читатели и гости! Сегодня на своем блоге хочу рассмотреть сервер 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, то имя пользователя необходимо вводить в формате domain_admin@AD.LOCAL. Сообщения выводимые после выполнения команды обозначают следующее: 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 FILES$@AD.LOCAL 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

Если включение в домен завершилось ошибкой, необходимо:

1. Проверить настройки DNS на Linux и убедиться, что команда hostname -f  выводит корректное FQDN-имя хоста.
2. Проверить, в состоянии ли утилиты nslookup или dig разрешить имя КД Active Directory в IP.
3. Проверить, поддерживает ли установленный пакет samba работу с Kerberos и LDAP.
4. Если вышеуказанные шаги не помогли, можно выполнить тестовое подключение к домену с увеличенным значением 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 определяются тремя возможностями (чтение, запись и исполнение) для трёх групп пользователей (владелец, группа, все остальные). При этом семантика, применения прав к файлам и каталогам несколько расходится. Приведу небольшую таблицу с описанием прав доступа по отношению к файлам/каталогам:

Файловый сервер

Общий ресурс только на чтение

Для создания ресурса на чтение, достаточно добавить в 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 = @»DOMAINDomain 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, необходимо проделать следующие шаги:

1. Установить пакет cups (мне так же необходимо было установить пакет hplip, т.к. используются преимущественно принтеры от HP и пакет smbclient) и настроить сервер печати по вашим нуждам. Как настраивать сервер печати, я писал в статьях Сервер печати на Linux  и Как работает SAMBA ч.2. Поэтому обойдусь только указанием настроек из smb.conf.
2. Добавить нужные принтеры через веб-интерфейс CUPS.
3. Раскомментировать в smb.confпараметры

           # принтеры нам нужны
           printing = CUPS
           cups options = raw
           show add printer wizard = yes

4. Закомментировать параметры в smb.conf:

           # принтеры нам не нужны
           #load printers = no
           #show add printer wizard = no
           #disable spoolss = yes

5. Добавить 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

6. Перезапустить демонов cups, samba и winbind.
7. Добавить драйверы принтеров, как было описано в статье Как работает SAMBA ч.2 (автоматическая загрузка драйверов). Естественно, загружать драйвер нужно от доменного пользователя, указанного в /etc/samba/smbusers, как root.
8. По вкусу настроить параметры по умолчанию для принтера через каталог «Принтеры и Факсы» на сервере самба, ибо у меня почему-то по-умолчанию устанавливался размер бумаги — Letter.
9. Пользоваться сетевой печатью.

На моем сервере пришлось устанавливать единый драйвер для всех принтеров сети. Это привело к некоторым проблемам при установке драйверов. При этом, 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