TOSHARG-ServerType.xml

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE chapter PUBLIC "-//Samba-Team//DTD DocBook V4.2-Based Variant V1.0//EN" "http://www.samba.org/samba/DTD/samba-doc">
<chapter id="ServerType">
<chapterinfo>
	&author.tridge;
	&author.jelmer;
	&author.jht;
</chapterinfo>

<title>Типы серверов и режимы безопасности</title>

<para><indexterm><primary>переход</primary></indexterm><indexterm><primary>режим безопасности</primary></indexterm> Эта глава содержит информацию, касающуюся типов сервера, которыми - при соответствующей настройке - может быть Samba. Администратор сетей Microsoft, желающий использовать или перейти на Samba, захочет узнать значение знакомых администраторам MS Windows терминов в контексте Samba. Это значит, что также важно определить, как функционируют критические режимы безопасности до того, как мы начнем вдаваться в детали или настраивать собственно сервер.</para>

<para>Эта глава содержит обзор режимов безопасности, которые поддерживает Samba, и их отношения с клиентами и сервервами MS Windows.</para>

<para>Нам часто задают вопрос: <quote>Почему мне стоит хотеть использовать Samba?</quote> Большая часть глав содержит разделы, которые описывают особенности и преимущества. Мы надеемся, что представленная информация поможет ответить на этот вопрос. Однако предупреждаем Вас, что мы хотим быть честными и объективным, так что не все особенности Samba хороши. Сильная сторона может быть в том, что мы участвем в соревновании.</para>

<sect1>
<title>Особенности и сильные стороны</title>

<para>Два человека прогуливались по пыльной дороге, и внезапно один пнул ногой маленький красный камень. При этом он ударил свой палец, а камень попал в сандалию. Человек вытащил камень и проклял его с гневной страстью и злобой. Второй  посмотрел на него и сказал: <quote>Это гранат. Я могу превратить его в красивый самоцвет, и когда-нибудь он сделает какую-нибудь принцессу очень счастливой!</quote></para>

<para>Мораль этой истории: два человека, две разные точки зрения, касающиеся одного и того же камня. Нравится Вам это или нет, но Samba- как тот камень. Обращайтесь с ней правильно, и она принесет Вам огромное удовольствие, но если Вам необходимо  использовать ее, а времени на освоение ее секретов у Вас нет, она будет только источником дискомфорта.</para>

<para><indexterm><primary>UNIX</primary><secondary>сервер</secondary></indexterm><indexterm><primary>взаимодействие</primary></indexterm> Samba началась как проект, задачей которого было обеспечить взаимодействие клиентов MS Windows 3.x с сервером UNIX. Она сильно выросла по сравнению с началом, и сейчас предоставляет функциональность, подходящую для крупномасштабных развертываний. У нее также есть некоторые недостатки. В разделах, похожих на этот, мы расскажем и о том, и о другом.</para>

<para>Итак, каковы достоинства особенностей, упомянутых в этой главе?</para>

<itemizedlist>
	<listitem><para><indexterm><primary>домен</primary><secondary>контроллер</secondary></indexterm> Samba-3 может заменить контроллер домена MS Windows NT4.</para></listitem>

	<listitem><para><indexterm><primary>active directory</primary></indexterm> Samba-3 предлашает отличное взаимодействие с доменами MS Windows NT4, так же, как и с доменами Microsoft Active Directory.</para></listitem>

	<listitem><para><indexterm><primary>междоменное</primary><secondary>доверие</secondary></indexterm> Samba-3 полностью поддерживает междоменные доверительные отношения в стиле NT4.</para></listitem>

	<listitem><para><indexterm><primary>аутентификация</primary></indexterm><indexterm><primary>безопасность</primary><secondary>режимы</secondary></indexterm> У Samba есть режимы безопасности, которые позволяют иметь более гибкую аутентификацию, чем возможна с контроллерами домена MS Windows NT4.</para></listitem>

	<listitem><para><indexterm><primary>учетная запись</primary><secondary>база данных</secondary><tertiary>база</tertiary></indexterm><indexterm><primary>зашифрованный</primary></indexterm> Samba-3 позволяет одновременно использовать множество парольных баз.  (Зашифрованные пароли хранятся в базах в форматах, уникальных для сетей Windows).</para></listitem>

	<listitem><para><indexterm><primary>реплицированные</primary></indexterm> Парольные базы могут распределяться и реплицироваться различными методами. Это дает Samba-3 большую, чем у MS Windows NT4, гибкость, и во многих случаях слегка большую полезность, чем домены Active Directory под MS Windows 200x.</para></listitem>
</itemizedlist>

</sect1>

<sect1>
<title>Типы сервера</title>


<para><indexterm><primary>Тип сервера</primary></indexterm> Администраторы сетей Microsoft часто ссылаются на три типа серверов:</para>

<itemizedlist>
	<listitem><para>Контроллер домена</para>
		<itemizedlist>
			<listitem><para>Основной контроллер домена (PDC)</para></listitem>
			<listitem><para>Резервный контроллер домена (BDC)</para></listitem>
			<listitem><para>Контроллер домена с Active Directory Services</para></listitem>
		</itemizedlist>
	</listitem>
	<listitem><para>Сервер-участник домена</para>
		<itemizedlist>
			<listitem><para>Сервер домена с Active Directory</para></listitem>
			<listitem><para>Сервер домена NT4</para></listitem>
		</itemizedlist>
	</listitem>
	<listitem><para>Одиночный сервер</para></listitem>
</itemizedlist>

<para><indexterm><primary>домен</primary><secondary>управление</secondary></indexterm><indexterm><primary>домен</primary><secondary>участник</secondary></indexterm><indexterm><primary>управление доменом</primary><secondary>первичный</secondary></indexterm><indexterm><primary>управление доменом</primary><secondary>резерв</secondary></indexterm> Главы, раскрывающие управление доменом (<link linkend="samba-pdc">Управление доменом</link>), резервное управление доменом (<link linkend="samba-bdc">Резервное управление доменом</link>) и участие в домене (<link linkend="domain-member">Участие в домене</link>), обеспечивают достаточную информацию, касающуюся настройки Samba для каждой из этих ролей сервера. Настойчиво рекомендуем Вам близко познакомиться с этими главам, потому что они  закладывают фундамент для развертывания безопасности домена Samba.</para>

<para><indexterm><primary>одиночный</primary></indexterm> Одиночный сервер автономен в смысле источника его базы учетных записей. Обратитесь к <link linkend="StandAloneServer">Одиночные серверы</link>, чтобы получить более широкое понятие значения того, что имеется в виду под <emphasis>одиночным</emphasis> сервером.</para>

</sect1>

<sect1>
<title>Режимы безопасности Samba</title>


<para><indexterm><primary>Режим безопасности</primary></indexterm><indexterm><primary>безопасность</primary></indexterm> В этом разделе описаны функции и назначение режимов безопасности Samba's. Аккуратное понимание того, как Samba работает в каждом режиме безопасности, так же, как и настройки клиентов MS Windows для каждого режима, значительно уменьшит число жалоб пользователей и головную боль администратора.</para>

<para><indexterm><primary>Server Message Block</primary><see>SMB</see></indexterm><indexterm><primary>Common Internet Filesystem</primary><see>CIFS</see></indexterm> Сети Microsoft Windows используют протокол, который изначально назывался Server Message Block (SMB) (блоки серверных сообщнени). Примерно с 1996 года протокол стал больше известен как Common Internet Filesystem (CIFS) (общая файловая система Интернета).</para>

<para><indexterm><primary>уровни безопасности</primary></indexterm><indexterm><primary>режимы безопасности</primary></indexterm><indexterm><primary>пользовательский уровень</primary></indexterm><indexterm><primary>уровень ресурсов</primary></indexterm> В мире сетей SMB/CIFS существуют только два типа безопасности: <emphasis>пользовательского уровня</emphasis> и  <emphasis>уровня ресурсов</emphasis>. Мы собирательно называем это  <emphasis>уровни безопасности</emphasis>. В выполнении этих двух уровней безопасности Samba обеспечивает гибкость, которая недостижима с серверами MS Windows NT4/200x. На самом деле Samba выполняет безопасность <emphasis>уровня ресурсов</emphasis> только одним способом, но зато имеет четыре способа выполнения безопасности <emphasis>уровня пользователя</emphasis>. Собирательно мы называем  Samba-исполнение уровней безопасности <emphasis>режимами безопасности</emphasis>. Эти режимы известны как <emphasis>share</emphasis> (на уровне ресурсов), <emphasis>user</emphasis> (на уровне пользователя), <emphasis>domain</emphasis> (доменная), <emphasis>ADS</emphasis> (домен с ADS), и <emphasis>server</emphasis> (проверка учетной записи на другом сервере). Все они описаны в этой главе.</para>

<para>Сервер SMB во время инициирования сессии информирует клиента об уровне безопасности, на котором работает сервер. Существует два варианта: уровень ресурсов и уровень пользователя. От того, что клиент получит, зависит способ, которым он будет пытаться аутентифицироваться. От этого практически не зависит (в сколько-нибудь значимом объеме) тот способ, которым Samba обрабатывает безопасность. Это может звучать странно, но вполне в рамках клиент/серверного подхода SMB. В SMB все инициируется и контролируется клиентом, и сервер может сказать клиенту, что доступно, и допустимо ли действие.</para>

<para>Термин <literal>клиент</literal> относится ко всем агентам, являются ли они рабочей станцией Windows, сервером Windows, другим сервером Samba  или любым клиентским приложением SMB или CIFS (например, <command>smbclient</command>), которое использует сервисы. предоставляемые сервером SMB/CIFS.</para>

<sect2>
<title>Безопасность уровня пользователя</title>

<para><indexterm><primary>уровень пользователя</primary></indexterm> Мы опишем безопасность уровня пользователя в первую очередь, как наиболее простую. При безопасности уровня пользователя клиент посылает запрос установления сессии сразу за согласованием протокола. Этот запрос содержит имя пользователя и пароль. Сервер может либо принять, либо отвергнуть эту комбинацию имя/пароль. На этом ээтапе у сервера нет идей по поводу ресурса, к которому, в конце концов, клиент попытается подключиться, поэтому он не может основывать свой ответ <emphasis>отклонить/принять</emphasis>на чем-то еще, кроме:</para>

<orderedlist>
<listitem><para>имя пользователя/пароль</para></listitem>
<listitem><para>имя машины-клиента.</para></listitem>
</orderedlist>

<para><indexterm><primary>атрибуты учетной записи</primary></indexterm> Если сервер принимает пару имя ользователя/пароль, клиент считает, что способен монтировать общие ресурсы (используя <emphasis>присоединение к дереву</emphasis>) без дальнейшего указания пароля. Он ожидает, что все права доступа будут установлены согласно пользователя/пароля, указанных в первоначальной <emphasis>установке сессии</emphasis>.</para>

<para><indexterm><primary>установка сессии</primary></indexterm> Кроме того, клиенту можно посылать множественные запросы на <emphasis>установку сессии</emphasis>. Когда сервер отвечает, он выдает клиенту <emphasis>идентификатор</emphasis>, для использования в качестве пометки об аутентификации с этой парой имя пользователя/пароль. Таким образом, клиент может работать с несколькими контекстами аутентификации (примером приложения, делающего так, является WinDD).</para>

<para><indexterm><primary>LanManager</primary></indexterm><indexterm><primary>сохраняющий-регистр</primary></indexterm><indexterm><primary>нечувствительный-к-регистру</primary></indexterm><indexterm><primary>верхний-регистр</primary></indexterm><indexterm><primary>нижний-регистр</primary></indexterm> Имена пользовательских учетных записей сетей Windows являются нечувствительными к регистру- это значит, что символы как верхнего, так и нижнего  регистров считаются эквивалентными. Про это говорят, что регистр сохраняется, но не имеет значения. Системы Windows и LanManager до Windows NT версии 3.10 имеют пароли, нечувствительные к регистру пароли, которые не обязательно сохраняли регистр. Все системы семейства Windows NT рассматривают пароль как чувствительный к регистру, и этот регистр сохраняют.</para>

<sect3>
<title>Пример конфигурации</title>

<para>Параметр &smb.conf;, устанавливающий безопасность уровня пользователя:</para>

<para><smbconfblock>
<smbconfoption name="security">пользователь</smbconfoption>
</smbconfblock></para>

<para>Это является настройкой по умолчанию с Samba-2.2.x.</para>

</sect3>

</sect2>
<sect2>
<title>Безопасность уровня ресурса</title>

<para><indexterm><primary>уровень ресурсов</primary></indexterm><indexterm><primary>подключение</primary></indexterm> В режиме безопасности уровня ресурсов клиент отдельно аутентифицирует себя для каждого ресурса. Он посылает пароль вместе с каждым запросом на подключение к дереву (монтирование общего ресурса), но в явном виде имя пользователя не указывается. Клиент предполагает, что с каждым ресурсом связан пароль, независимо от пользователя. Это значит, что Samba должна выяснить, какое имя пользователя клиент, вероятнее всего, хочет использовать, SMB-серверу не присылают имя пользователя в явном виде. Некоторые коммерческие серверы SMB, такие, как NT, действительно связывают пароли прямо с ресурсами в режиме безопасности уровня ресурсов, но Samba всегда использует схемы  аутентификацию UNIX, в которой проверяется именно пара имя_пользователя/пароль, а не пара ресурс/пароль.</para>

<para>Чтобы понять параллели с сетями MS Windows, думайте в терминах  networking MS Windows 9x/Me, где возможно создать общую папку, которая предоставляет доступ либо полный, либо только для чтения, с паролем или без.</para>

<para>Многие клиенты посылают запрос на инициирование сессии даже в том случае, если сервер работает в режиме безопасности на уровне ресурса. Обычно они присылают существующее имя пользователя без пароля. Samba записывает это имя пользователя в список возможных имен пользователей. Когда клиент посылает запрос присоединения к дереву, Samba также добавляет в этот список имя ресурса, к которому подключаются, и все имена пользователей, перечисленные в параметре <smbconfoption name="user"/> в файле &smb.conf;. Пароль, в свой очередь, проверяется на соответствие этим возможным именам пользователей. Если найдено соответствие, клиент аутентифицируется как этот пользователь.</para>

<para><indexterm><primary>переключатель служб имен</primary><see>NSS</see></indexterm><indexterm><primary>/etc/passwd</primary></indexterm><indexterm><primary>nsswitch.conf</primary></indexterm> Там, где список возможных имен пользователей не предоставлен, Samba делает системный вызов UNIX, чтобы найти пользователя, чей пароль соответствует стандартной базе учетных записей. На системах, не имеющих возможности переключения служб имен (NSS), эти поиски будут идти по файлу <filename>/etc/passwd</filename>. На системах с включенным NSS поиск будет вестись библиотеками, указанными в файле  <filename>nsswitch.conf</filename>. Элементы в файле, в котором указываются библиотеки, таковы: <screen>
passwd: files nis ldap
shadow: files nis ldap
group: files nis ldap
</screen><indexterm><primary>/etc/passwd</primary></indexterm><indexterm><primary>/etc/group</primary></indexterm><indexterm><primary>NIS</primary></indexterm> В примере, который показан здесь (навряд ли употребимом в практике), поиск проверит файлы <filename>/etc/passwd</filename> и <filename>/etc/group</filename>, если ничего не найдет - проверит NIS, затем LDAP.</para>

<sect3>
<title>Пример конфигурации</title>

<para>Параметр в &smb.conf;, который устанавливает безопасность уровня ресурса:</para>

<para><smbconfblock>
<smbconfoption name="security">общий ресурс</smbconfoption>
</smbconfblock></para>

</sect3>
</sect2>

<sect2>
<title>Режим безопасности домена (безопасность уровня пользователя)</title>

<para><indexterm><primary>домен</primary><secondary>контроллеры</secondary></indexterm><indexterm><primary>безопасность</primary><secondary>контроллеры</secondary></indexterm><indexterm><primary>PDC</primary></indexterm><indexterm><primary>BDC</primary></indexterm><indexterm><primary>вход</primary></indexterm><indexterm><primary>аутентификация</primary></indexterm> Безопасность домена обеспечивает механизм хранения всех учетных записей пользователей и групп в централизованном разделяемом  хранилище. Централизованное хранилище учетных записей разделяется между контроллеров домена (безопасности). Серверы, выступающие контроллерами домена, обеспечивают работу служб аутентификации и проверки для всех машин, участвующих в контексте безопасности домена. Первичный контроллер домена (PDC) является сервером, ответственным за поддержание целостности базы учетных записей. Резервные контроллеры домена обеспечивают только службы (BDC) входа в домен и аутентификации. Обычно BDC отвечают на запросы входа в сеть быстрее, чем PDC.</para>

<para><indexterm><primary>участие в домене</primary></indexterm><indexterm><primary>учетная запись доверия</primary></indexterm><indexterm><primary>доверие</primary><secondary>учетная запись</secondary></indexterm><indexterm><primary>домен</primary><secondary>безопасность</secondary></indexterm><indexterm><primary>домен</primary><secondary>контроллер</secondary></indexterm> Когда Samba работает в режиме безопасности <smbconfoption name="security">domain</smbconfoption>, у сервера Samba имеется учетная запись доверия домена (учетная запись компьютера), и поэтому все запросы на аутентификацию передаются контроллерам домена. Другими словами, эта конфигурация делает из сервера Samba сервер-участник домена, даже если он выступает в роли контроллера домена. Все машины, которые участвуют в безопасности домена, должны иметь учетную запись компьютера в базе учетных записей безопасности.</para>

<para><indexterm><primary>учетная запись</primary><secondary>база данных</secondary></indexterm><indexterm><primary>машина</primary><secondary>учетная запись</secondary></indexterm><indexterm><primary>NetBIOS</primary><secondary>имя</secondary></indexterm><indexterm><primary>NetBIOS</primary></indexterm> Внутри безопасного окружения домена нижележащая архитектура безопасности использует безопасность уровня пользователя. Даже компьютеры, являющиеся  участниками домена, должны аутентифицироваться при запуске. Учетная запись машины состоит из соответствующего элемента в базе учетных записей, имя которого -NetBIOS-имя машины, а пароль генерируется случайным образом, и является известным как контроллеру домена, так и машине. Если учетная запись машины не может быть проверена при загрузке, пользователи не смогут входить в домен, используя эту машину, поскольку ей нельзя доверять. Учетная запись машины также известна под названием "учетная запись доверия к машине".</para>

<para>Есть три варианта настройки участника домена:</para>

<orderedlist>
	<listitem><para>Первичный контроллер домена (PDC) - один на домен.</para></listitem>
	<listitem><para>Резервный контроллер домена (BDC) - их может быть любое количество.</para></listitem>
	<listitem><para>Сервер-участник домена (DMS) - может быть любое число на домен.</para></listitem>
</orderedlist>

<para><indexterm><primary>DMS</primary></indexterm> Каждый из них мы обсудим в отдельных главах. А сейчас нас больше всего интересуют основы настройки DMS.</para>

<sect3>
<title>Пример конфигурации</title>
<para><emphasis>Samba как сервер-участник домена</emphasis></para>


<para><indexterm><primary>тип сервера</primary><secondary>участник домена</secondary></indexterm> Этот метод предполагает добавление следующих параметров в файл &smb.conf;: <smbconfblock><smbconfoption name="security">domain</smbconfoption><smbconfoption name="workgroup">&example.workgroup;</smbconfoption></smbconfblock></para>

<para>Чтобы этот метод работал, сервер Samab необходимо присоединить к домену MS Windows NT. Это делается так: <indexterm><primary>net</primary><secondary>rpc</secondary></indexterm><indexterm><primary>Участник домена</primary><secondary>присоединение</secondary></indexterm></para>


<procedure>
        <step><para>На контроллере домена MS Windows NT, используя Server Manager, добавьте учетную запись машины для Samba-сервера.</para></step>

        <step><para>На системе UNIX/Linux исполните:</para>
	
			<para><screen>&rootprompt;<userinput>net rpc join -U administrator%password</userinput></screen></para>
		</step>
</procedure>

<note><para><indexterm><primary>smbpasswd</primary></indexterm> Samba-2.2.4 и более поздние релизы серии Samba 2.2.x могут автоматически присоединяться к домену Windows NT4 простым исполнением: <screen>
&rootprompt;<userinput>smbpasswd -j <replaceable>ИМЯ_ДОМЕНА</replaceable> -r <replaceable>ИМЯ_PDC</replaceable> \
	 -U Administrator%<replaceable>пароль</replaceable></userinput>
</screen><indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>join</tertiary></indexterm> Samba-3 может делать то же самое при выполнении: <screen>
&rootprompt;<userinput>net rpc join -U Administrator%<replaceable>пароль</replaceable></userinput>
</screen> С Samba-3 нет необходимости указывать <replaceable>ИМЯ_ДОМЕНА</replaceable> или <replaceable>ИМЯ_PDC</replaceable>, поскольку она узнает их из настроек в файле &smb.conf;.</para></note>

<para><indexterm><primary>неправильная оболочка</primary></indexterm><indexterm><primary>/etc/passwd</primary></indexterm><indexterm><primary>/bin/false</primary></indexterm> Использование этого режима аутентификации требует для каждого пользователя стандартную учетную запись UNIX с тем, чтобы назначить UID после аутентификации учетной записи контроллером домена Windows. Эта учетная запись может быть заблокирована, чтобы предотвратить входы клиентов, отличных от MS Windows, такими средствами, как назначение неправильной оболочки в файле <filename>/etc/passwd</filename>. Лучший способ назначить неверную оболочку пользовательской учетной записи - установить оболочку равной файлу <filename>/bin/false</filename>.</para>

<para><indexterm><primary>PDC</primary></indexterm><indexterm><primary>BDC</primary></indexterm> Domain controllers can be located anywhere that is convenient. The best advice is to have a BDC on every physical network segment, and if the PDC is on a remote network segment the use of WINS (see <link linkend="NetworkBrowsing">Network Browsing</link> for more information) is almost essential.</para>

<para>Альтернатива назначению UID'ов пользователям Windows на Samba-сервере-участнике домена представлена в <link linkend="winbind">Winbind</link>, <link linkend="winbi nd">Winbind: Использование учетных записей домена</link>.</para>

<para>За дополнительной информацией, касающейся участия в домене, смотрите <link linkend="domain-member">Участие в домене</link>.</para>

</sect3>
</sect2>

<sect2>
<title>Режим безопасности ADS (безопасность уровня пользователя)</title>

<para><indexterm><primary>ADS</primary></indexterm><indexterm><primary>native mode</primary></indexterm> И Samba-2.2, и Samba-3 могут присоединяться к домену Active Directory с использованием безопасности, основанной на RPC, в стиле NT4. Это возможно, если домен работает в "родном" режиме. Active Directory в "родном" режиме замечательно работает с участниками домена в стиле NT4. Это противоречит популярному поверью.</para>

<para>Если Вы используете Active Directory, то, начиная с Samba-3, Вы можете присоединяться к домену как полноценный участник AD. Зачем Вам это надо? Ваши политики безопасности могут запрещать использование NT-совместимых протоколов аутентификации. Все Ваши машины, работающие под Windows 2000 и выше используют Kerberos. В этом случае Samba в роли домена NT4, нуждалась бы в NT-совместимых данных для аутентификации.  Samba в режиме участника AD может принимать билеты Kerberos.</para>

<para><indexterm><primary>реальность</primary></indexterm><indexterm><primary>смешанный режим</primary></indexterm>Площадки, которые используют Active Directory Services (ADS) для Microsoft Windows, должны быть осторожны со значениями терминов: <literal>"родной" режим</literal> и <literal>смешанный режим</literal> работы ADS. Выражение <literal>реальность</literal> используется, чтобы описать архитектуру безопасности, основанную на Kerberos (такую, как использует Microsoft ADS).</para>

<sect3>
<title>Пример конфигурации</title>

<para><smbconfblock>
<smbconfoption name="realm">ваша.реальность.Kerberos</smbconfoption>
<smbconfoption name="security">ADS</smbconfoption>
</smbconfblock></para>

<para>Могут потребоваться следующие параметры:</para>

<para><smbconfblock>
<smbconfoption name="password server">ваш.сервер.Kerberos</smbconfoption>
</smbconfblock></para>

<para>Пожалуйста, обратитесь к <link linkend="domain-member">Участие в домене</link>, and <link linkend="ads-member">Участие Samba в домене ADS</link> за дальнейшей информацией, касающейся этих настроек конфигурации.</para>

</sect3>
</sect2>

<sect2>
<title>Режим безопасности "сервер" (безопасность уровня пользователя)</title>

<para>Режим безопасности "сервер" остался со времен, когда Samba не могла быть сервером-участником домена. Настойчиво рекомендуем не использовать эту функцию. Режим безопасности "сервер" имеет множество недостатков, среди которых:</para>

<itemizedlist>
	<listitem><para>Потенциальная блокировка учетной записи на серверах MS Windows NT4/200x, проверяющих пароль.</para></listitem>
	<listitem><para>Нехватка уверенности в том, что сервер, проверяющий пароли - именно тот, который указан. </para></listitem>
	<listitem><para>Не работает с Winbind, что, в частности, необходимо для хранения перемещаемых профилей.</para></listitem>
	<listitem><para>Этот режим открывает много соединений с сервером, проверяющим пароли, и держит их открытыми долгое время.</para></listitem>
	<listitem><para>Безопасность на сервере Samba ломается самым плохим образом, когда удаленный сервер, проверяющий пароли, внезапно перестает работать.</para></listitem>
	<listitem><para>В этом режиме для Samba-сервера НЕТ учетной записи в домене, к которому принадлежит сервер, проверяющий пароли.</para></listitem>
</itemizedlist>

<para><indexterm><primary>устанвока сессии</primary></indexterm><indexterm><primary>SMB</primary></indexterm> В режиме безопасности "сервер" сервер Samba сообщает клиенту, что он находится в режиме безопасности уровня пользователя. Затем клиент делает установку сессии, как было описано ранее. Сервер Samba берет имя пользователя и пароль, присланные клиентом, и пытается подключиться к smbconfoption name="password server"/&gt;, посылая точно те же имя пользователя/пароль, что получены от клиента. Если тот сервер находится в режиме безопасности уровня пользователя и принимает пароль, то и Samba принимает соединение от клиента. Этот параметр позволяет серверу Samba использовать другой сервер SMB как <smbconfoption name="password server"/>.</para>

<para><indexterm><primary>уровень безопасности</primary></indexterm><indexterm><primary>шифрование</primary></indexterm> Вам следует заметить, что в начале всего этого, когда сервер сообщает клиенту, на каком уровне безопасности он сейчас работает, он также сообщает, поддерживается ли шифрование. Если да, то клинту передается случайный шифроключ. В этом случае клиент будет посылать все свои пароли в зашифрованном виде. Samba поддерживает этот тип шифрования по умолчанию.</para>

<para>Параметр <smbconfoption name="security">server</smbconfoption> заставляет Samba сообщать клиенту, что она работает в режиме безопасности <emphasis>уровня пользователя</emphasis>, но на самом деле все запросы на аутентификацию будут передаваться другому серверу с безопасностью уровня пользователя. Это требует дополнительного параметра <smbconfoption name="password server"/>, который указывает на настоящий сервер аутентификации. Настоящий сервер аутентификации может быть другим сервером Samba, или он может быть сервером Windows NT, который по умолчанию поддерживает зашифрованные пароли.</para>

<note><para><indexterm><primary>сервер паролей</primary></indexterm><indexterm><primary>рабочая группа</primary></indexterm> Когда Samba работает в <emphasis>режиме безопасности "сервер"</emphasis>, важно, чтобы параметр <emphasis>сервер паролей</emphasis> был установлен в точное NetBIOS-имя машины конечного сервера аутентификации. Samba не может определить это из поисков имен NetBIOS, потому что выбор конечного сервера аутентификации является произвольным и не может быть определен по имени домена. В сущности, режим работы Samba-сервера, находящегося в <emphasis>режиме безопасности "сервер"</emphasis>, называется режимом рабочей группы.</para></note>

<sect3>
<title>Пример конфигурации</title>
<para><emphasis>Использование MS Windows NT в качестве сервера аутентификации</emphasis></para>

<para>Этот метод вовлекает добавление следующих параметров в файл &smb.conf;:</para>

<para><smbconfblock>
<smbconfoption name="encrypt passwords">Да</smbconfoption>
<smbconfoption name="security">сервер</smbconfoption>
<smbconfoption name="password server">"NetBIOS_имя_контроллера_домена"</smbconfoption>
</smbconfblock></para>


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

<para><indexterm><primary>неправильный</primary></indexterm><indexterm><primary>блокировка</primary></indexterm> Недостаток этого режима работы в том, что по причинам безопасности Samba будет посылать серверу паролей неверное имя и пароль, и если удаленный сервер откажется отвергнуть пару из неверных имени и пароля, то используется альтернативный режим идентификации или проверки. Если сеть использует блокировку, это после некоторого числа неудавшихся попыток аутентификации приведет к блокировкам пользователей.</para>

<para>Использование этого режима аутентификации требует стандартную учетную запись UNIX для каждого пользователя. Эта учетная запись может быть заблокирована, чтобы предотвратить любые подключения, кроме клиентов SMB/CIFS.</para>

</sect3>
</sect2>

</sect1>

<sect1>
<title>Проверка пароля</title>

<para>Клиенты MS Windows могут использовать зашифрованные пароли как часть модели аутентификации "запрос-ответ" (также известной, как NTLMv1 and NTLMv2) или сами по себе, или строки незашифрованного текста для простой аутентификации по паролю.  Необходимо осознавать, что в протоколе SMB пароль по сети передается либо в незашифрованном виде, либо в зашифрованном - но не оба варианта в одном запросе аутентификации.</para>

<para><indexterm><primary>зашифрованные пароли</primary></indexterm><indexterm><primary>зашифрованные</primary></indexterm> Когда используются зашифрованные пароли, пароль, введенный пользователем, шифруется двумя способами:</para>

<itemizedlist>
        <listitem><para>Хэш MD4 Unicode-представления строки пароля. Так же известен под именем хэш NT.</para></listitem>

        <listitem><para>Пароль преобразуется в верхний регистр, обрезается или дополняется до 14 байт. Затем к этой строке добавлется 5 нулевых байт, и она делится на две, чтобы получилось два 56-битных ключа DES, чтобы зашифровать "волшебное" 8-байтовое значение. Полученные 16 байт составляют хэш LanMan.</para></listitem>
</itemizedlist>

<para><indexterm><primary>незашифрованный текст</primary><secondary>passwords</secondary></indexterm> MS Windows 95 до sp1 и MS Windows NT версий 3.x и версий 4.0 до service pack 3 могут использовать любой из режимов аутентификации по паролю. Все более поздние версии MS Windows не поддерживают незашифрованные пароли по умолчанию.</para>

<para><indexterm><primary>кэшированный</primary><secondary>пароль</secondary></indexterm> Клиенты MS Windows имеют привычку разрывать сетевые отображения, которые бездействовали 10 минут или более. Когда пользователь пытается использовать подключенный сетевой диск, который отключен, клиент повторно устанавливает соединение, используя кэшированную копию пароля.</para>

<para>Когда Micorsoft изменила режим паролей по умолчанию, была убрана поддержка кэширования паролей в незашифрованном виде. Соответственно когда изменяется параметр реестра для разрешения использования незашированных паролей, кажется, что это работает, но когда соединение к отключенному ресурсу пытается установиться вновь, ничго не получится в том случае. если удаленный сервер не поддерживает зашифрованные пароли. Определенно плохая идея - вновь включать пожддержку незашифрованных паролей в таких клиентах.</para>

<para>Следующие параметры помогут обойти проблему с клиентами Windows 9x/Me, которые переводят имя пользователя и пароль в верхний регистр до передачи на SMB-сервер при аутентификации открытым текстом:</para>


<?latex \newpage ?>
<smbconfblock>
<smbconfoption name="password level"><replaceable>целое число</replaceable></smbconfoption>
<smbconfoption name="username level"><replaceable>целое число</replaceable></smbconfoption>
</smbconfblock>

<para>По умолчанию Samba преобразует в нижний регистр имя пользователя до попытки поиска пользователя в системной базе локальных учетных записей. Поскольку имена пользователей UNIX по соглашениям содержат только символы нижнего регистра, опция <smbconfoption name="username-level"/> необходима редко.</para>

<para><indexterm><primary>clear-text</primary></indexterm> Однако пароли на системах UNIX часто используют как символы нижнего регистра, так и верхнего. Следовательно, чтобы пользователь с клиентом Windows 9x/Me мог подключиться к серверу Samba, используя аутентификацию открытым текстом, опция <smbconfoption name="password level"/> должна быть устанвлена в максимальное число букв верхнего регистра, которые <emphasis>могли</emphasis> появиться в пароле. Заметьте, что если ОС сервера использует традиционную DES-версию crypt(), значение <smbconfoption name="password level"/>, равное 8, приведет к регистронезависимому паролю - с точки зрения пользователей Windows. Это также приведет к увеличению задержек при входе, потому что Samba должна вычислить все перестановки и изменения строки пароля, и испробовать их раз за разом до тех пор, пока не будет найдено соответствие (или все комбинации будут исчерпаны).</para>

<para>Лучший выбор для внедрения - разрешить поддержку зашифрованных паролей везде, где бы Samba не использовалась. Большая часть попыток применить изменения реестра для повторного включения нешифрованных паролей ведет к жалобам и несчастьям пользователей.</para>

</sect1>

<sect1>
<title>Общие ошибки</title>

<para>Все мы делаем ошибки. Это нормально - делать ошибки, но только до тех пор, пока они делаются в нужное время и в нужном месте. Ошибка, приводящая к потере производительности, редко переносится спокойно; однако ошибка, сделанная в тестовой лаборатории разработчика, ожидается.</para>

<para>Здесь мы рассмотрим общие ошибки и непонятности, которые были темами обсуждения в списке рассылки Samba. Многих из них можно избежать, сделав домашнее задание перед развертыванем Samba. Некоторые из них являются результатом непонимания английского языка, в котором есть множество фраз, потенциально двусмысленных, и они могут сильно озадачить тех, для кого английский - неродной язык.</para>

<sect2>
<title>Что делает Samba сервером?</title>

<para>Для некоторых суть безопасности Samba является очевидной, но, в общем-то, все равно неправильной. Предполагается, что <smbconfoption name="security">server</smbconfoption> заставит Samba быть сервером. Ничего подобного! Эта настройка значит, что Samba <emphasis>попытается</emphasis> использовать другой сервер SMB как единственный источник аутентификации пользователей.</para>

<para>Samba является сервером независимо от того, какой режим безопасности выбран. Когда Samba используется вне доменного контекста безопасности, лучше всего оставить режим безопасности по умолчанию. По умолчанию Samba-3 использует безопасность режима пользователя.</para>

</sect2>

<sect2>
<title>Что делает Samba контроллером домена?</title>

<para><indexterm><primary>режим сервера</primary></indexterm> Параметр &smb.conf; <smbconfoption name="security">domain</smbconfoption> не заставляет Samba вести себя как контроллер домена. Эта настройка указывает Samba быть участником домена. За дальнейшей информацией обратитесь к <link linkend="samba-pdc">Samba в роли PDC</link>.</para>

</sect2>

<sect2>
<title>Что делает Sambа участником домена?</title>

<para>Угадайте! Так делают многие. Но как бы Вы не решили, не думайте, что <smbconfoption name="security">user</smbconfoption> делает Samba участником домена. Прочитайте руководство от производителя до истечения гарантии. Для большей информации смотрите <link linkend="domain-member">Domain Membership</link>.</para>

</sect2>


<sect2>
<title>Постоянно теряется соединение с сервером паролей.</title>

<para><quote>Почему server_validate() просто возвращает ошибку, вместо того, чтобы восстановить свое соединение с сервером паролей? Несмотря на то, что я не являюсь знатоком протокола SMB, скорее всего, процесс кластерного сервера передает своему клиенту - рабочей станции - сессионный ключ, который получает от сервера паролей, что, в свою очередь, значит, что хэши паролей, переданные клиентом, не будут работать при последующих соединениях, чей сессионный ключ должен быть другим. Поэтому server_validate() должно возвращать ошибку.</quote></para>

<para>В самом деле. Вот почему <smbconfoption name="security">server</smbconfoption> в лучшем случае грязный хак. Пожалуйста, используйте <smbconfoption name="security">domain</smbconfoption>; режим <smbconfoption name="security">server</smbconfoption> так же изввестен как "сквозная аутентификация".</para>

</sect2>

<sect2>
<title>Одиночный сервер преобразован в контроллер домена smbmdash; Теперь учетные записи пользователей не работают</title>

<para><quote>Когда я пытаюсь войти в домен, в журнале событий появляется запись вида<emphasis>испробованные реквизиты ДОМЕН/имя_пользователя; эффективные реквизиты СЕРВЕР/имя_пользователя</emphasis></quote></para>

<para>Обычно это из-за того, что учетная запись пользователя или машины была создана до того, как Samba была настроена как  контроллер домена. Учетные записи, созданные до того, как сервер стал контроллером домена, будут являться  <emphasis>локальными</emphasis> учетными записями, и будут аутентифицироваться как участники домена СЕРВЕР, примерно как локальные учетные записи в Windows 2000 (и более поздних версиях). Учетные записи, созданные после того, как сервер с Samba стал контроллером домена, будут <emphasis>глобальными</emphasis> учетными записями, и будут аутентифицироваться как участники домена ДОМЕН.</para>

<para>Это может быть проверено выполнением команды <command>pdbedit -L -v имя_пользователя</command>. Если ответ будет DOMAIN, то учетная запись принадлежит домену, если ответ SERVER - это локальная учетная запись сервера.</para>

<para>Простейший путь решения этой проблемы - удалить и снова создать учетную запись; однако это может повлечь проблемы с существующими профилями пользователя. Вы также можете применить <command>pdbedit -u имя_пользователя -I ДОМЕН</command>. Также Вам может понадобиться изменить SID пользователя и SID основной группы в соответствии с доменом.</para>

</sect2>

</sect1>

</chapter>