Лекция № 7 Контроль доступа. Бюджеты пользователей. Подсчёт времени репликации. Организация безопасности и уровень защиты C2. Соглашение об именах. Устранение неисправностей

1.1        Контроль доступа

         ОС обеспечивает контроль действий пользователей в сети, определяя для каждого пользователя разрешённые и запрещённые действия. Кроме того, она предоставляет пользователям доступ к запрашиваемым ими ресурсам сети. Администратор может позволить некоторым пользователям устанавливать соединения с ресурсами (например, принтерами) и/или производить определённые действия (например, модифицировать файлы), в то время как другим пользователям это будет запрещено. Доступ можно ограничить с помощью следующих средств:

Ø    Бюджет пользователя

Ø    Права пользователя

Ø    Группы пользователей

Ø    Субъекты и имперсонация (impersonation)

Ø    Информация по безопасности объектов (права доступа)

Реализация системы безопасности в сети включает использование доменов и доменных контроллеров.

1.2        Бюджеты пользователей

Человек, который принимает участие в работе домена, должен иметь бюджет пользователя (user account) для входа в сеть и получения доступа к её ресурсам (файлам, каталогам, принтерам).

Администратор должен создать бюджет пользователя, указав пользовательское имя бюджета и другие идентификационные данные пользователя и определив права пользователя в системе. Идентификаторы включают информацию о пользователе, его членстве в группах, и информацию политики безопасности. После того, как эта информация для вновь созданного бюджета пользователя будет введена, сервер определяет для пользователя уникальный идентификатор безопасности (Unique Security Identifier, SID). Каждый SID всегда является уникальным.

Когда пользователь регистрируется, сервер создаёт маркер безопасного доступа (security-access token). Он включает SID пользователя, идентификаторы безопасности групп, к которым он принадлежит, и другую информацию, в том числе имя пользователя и имена групп, к которым он принадлежит.

1.3        Права пользователя

Права пользователя (User rights) – это правила, определяющие действия пользователя, которые он может произвести. Если ПК не является контроллером домена, эти права относятся только к локальному ПК. Если это – контроллер домена, то эти права распространяются на все контроллеры в домене.

Права могут быть определены индивидуальному пользователю, но обычно (и более эффективно) они определяются для групп. Заранее определенные (встроенные) группы уже имеют набор пользовательских прав, определен­ный для них при установке системы. Администраторы обычно предостав­ляют права пользователям путем занесения их имен в список членов одной  или  нескольких заранее определенных групп.   При  необходимости можно создать новую группу и наделить ее специфическими  правами. Пользователи,   которые   добавлены   в   группу,   автоматически   получают пользовательские права, определенные для этой группы. Существует набор прав пользователей, которые администраторы сетей с повышенными требованиями к безопасности должны подвергать аудиту. Такие виды доступа, как Log on Locally (Локальная регистрация в системе) и Shut down the system (Останов системы) должны быть строго ограниче­ны, а назначения этих прав, сделанные по умолчанию, должны быть из­менены.

Таблица 6.1. Пользовательские права, устанавливаемые по умолчанию,

которые могут быть изменены

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

Таблица 6.2. Пользовательские права, установленные по умолчанию

1.4        Формирование групп пользователей с одинаковыми потребностями

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

Существует два типа групп:

Ø    Глобальная  группа   (global  group)   состоит   из   различных   бюджетов пользователей  одного домена,   группируемых   под одним   именем
Глобальная группа может содержать имена пользователей только одного домена, в котором она создана. Слово «глобальная» говорит о
том, что группа может быть наделена правами доступа для использо­вания ресурсов в множестве глобальных доменов. Глобальная группа
может содержать только бюджеты  пользователей  (но не может содержать бюджеты других групп). Глобальная группа не может быть
создана на компьютере, работающем под управлением Windows NT, или на компьютере, выполняющем в домене роль сервера (member server).

Ø    Локальная группа (local group) может включать сгруппированные вместе под одним именем пользовательские бюджеты и глобальные группы одного или нескольких доменов. В локальные группы могут быть добавлены пользователи и глобальные группы, принадлежащие к внешним доменам, если внешний домен является доверяемым по отношению к локальному домену. Слово «локальная» означает, что группе могут быть выделены права доступа на использование ресур­сов, находящихся только в одном локальном домене. Локальные группы могут содержать пользователей и глобальные группы, но не могут содержать других локальных групп

При работе с группами рекомендуется использовать следующие правила:

Ø    Лучше назначать права доступа локальным группам и использовать
глобальные группы как метод включения пользователей в локальные
группы.

Ø    Глобальная группа - это лучший метод для одновременного вклю­чения множества пользователей в другой домен. Необходимые права и доступ обеспечиваются локальной группой, в которую добавляется глобальная группа

Ø    Глобальные группы могут быть добавлены к локальным группам того же домена или доверяющего домена. Они также могут быть добавле­ны к компьютерам, работающим под управлением Windows NT Server и расположенным в том же до­мене или в доверяющем домене

Windows 200’X Server имеет встроенные локальные и глобальные пользова­тельские группы.

1.5        Субъекты и имперсонация

         Одна из целей модели безопасности Windows состоит в том, чтобы обеспечить любой программе, активизированной пользователем, такие права доступа к объектам, которые не превышали бы прав, которые имеет сам пользователь. Это значит, что если пользователю предоставлены права на чтение определенного файла, и он запускает программу, то эта про­грамма не сможет выполнять запись в этот файл, поскольку как и пользо­ватель, будет иметь право только на чтение.

Субъектом (subject) называется комбинация маркера доступа пользователя и программы, которая работает от имени пользователя. Windows ис­пользует субъекты для слежения и управления доступом программ, ис­пользуемых пользователем. Когда программа или процесс запускается от имени пользователя, то говорят, что эта программа работает в контексте безопасности данного пользователя. Контекст безопасности (security con­text) контролирует тот доступ к объектам и системным сервисам, который имеет данный субъект.

Модель клиент-сервер операционной системы Windows определяет два класса субъектов внутри архитектуры безопасности:

Ø    Простой субъект (simple subject) — это процесс, который активизиру­ется в контексте безопасности пользователя при входе в сеть. Он не является защищенным сервером, который может иметь других субъ­ектов в качестве своих клиентов

Ø    Серверный субъект(server subject) является процессом, применяемым как защищенный сервер (примером может служить подсистема Win32). Другие субъекты являются клиентами защищенного сервера. В этой роли серверный субъект обычно имеет контекст безопасности тек клиентов, от имени которых он работает

         Когда субъект вызывает объектный сервис через защищенную подсистему, маркер субъекта определяет, кто сделал вызов, и имеет ли сделавший вы­зов субъект достаточно прав, чтобы его запрос был выполнен.

Windows позволяет одному процессу брать атрибуты безопасности другого процесса. Это делается с помощью технологии, называемой имперсонациеи (impersonation). Например, серверный процесс обычно действует от лица клиентского процесса, если для выполнения задачи требуется дос­туп к объектам, к которым сам сервер доступа не имеет.

1.6        Информация по безопасности объектов (права доступа)

Вес именованные объекты Windows, а также некоторые объекты, не имеюшие имен, могут быть защищены. Дескриптор безопасности (security descriptor) описывает атрибуты безопасности объекта. Дескриптор безопас­ности для объекта включает в свой состав четыре части:

Ø    SID владельца,  который определяет пользователя или  группу, вла­деющую объектом. Владелец объекта может изменять уровень досту­па к объекту

Ø    Групповой SID, который используется только подсистемой POSIX и игнорируется другими подсистемами Windows

Ø    Избирательный список контроля доступа (access control list, ACL), идентифицирующий пользователей и группы, которым предоставлен или запретен определенный вид доступа. ACL контролируется вла­дельцем объекта

Ø    Системный ACL, контролирующий сообщения аудита, генерируемые системой. Системный ACL контролируется администратором систе­мы безопасности

1.6.1      Типы объектов

         Права доступа к объектам, которые могут быть предоставлены или нет, зависят от типа объектов. Например, для очереди заданий на принтер можно указать такие права доступа, как Manage Documents (Управление документами) или Print (Печать), для каталога - Read (Чтение), Write (Запись) и Execute (Запуск файлов на выполнение).

Права доступа к объекту также определяются тем, является ли объект кон­тейнерным (container object) или неконтейнерным (noiicontainer object). Контейнерный объект — это объект, который имеет логические связи с другими объектами, неконтейнерный объект не имеет логических связей с другими объектами. Например, каталог - это контейнерный объект, кото­рый логически связан с объектами типа «файл» и другими каталогами. Файлы являются неконтейнерными объектами. Эта разница между кон­тейнерными и неконтейперными объектами очень важна, потому что объ­екты, содержащиеся внутри контейнерных объектов, могут наследовать определенные типы прав доступа от родительского контейнера.

Замечание

NTFS поддерживаег наследование ACL от объекта "каталог" объектом "файл", который создастся внутри этого каталога.

1.6.2      Список контроля доступа и его элементы

         Каждый ACL состоит из элементов списка контроля доступа (Access control entries, АСЕ), которые определяют право доступа к объекту или разреше­ние на аудит объекта одному пользователю или группе. Существует три типа АСЕ. Два из них предназначены для избирательного контроля досту­па (discretionary access control), а один — для определения системной безо­пасности.

Элементами ACL, определяющими избирательный контроль доступа, яв­ляются AccessAllowed (доступ разрешен) и AccessDenied (доступ запрещен). Они явным образом разрешают или запрещают доступ к объекту для поль­зователя или группы пользователей. Первый встретившийся АСЕ типа Ac­cessDenied отклоняет доступ пользователя к ресурсу, и дальнейшей обра­ботки АСЕ не происходит.

Замечание

Существует очень важное отличие между ситуацией, когда в ACL нет ни одного элемента, то есть он пуст, и ситуацией, когда существует объект, у которого во­обще нет ACL. В случае, когда ACL пуст, права доступа явным образом не указа­ны, и соответственно, доступ неявно запрещен. Для объекта, который совсем не имеет ACL, не существуем зашиты, определенной для этого объекта, и, соответст­венно, любые пользователь и группа могут получить доступ к этому объекту.

Элементом списка ACL, определяющим системную безопасность, является элемент System Audit. Он используется для ведения журнала событий, свя­занных с безопасностью (log of security events) этого объекта и генерации сообщений аудита безопасности.

1.6.3      Маски доступа

         Каждый элемент списка имеет маску доступа (access mask), которая опре­деляет всевозможные действия для объекта определенного типа. Маска доступа похожа на меню, из которого осуществляется выбор типов прав доступа, которые нужно либо предоставить, либо нет.

         Специфические типы (specific types) определяют вид доступа, который соот­ветствует объекту определенного типа. Для каждого типа объекта можно определить до 16 специфических типов доступа. Совокупность специфиче­ских типов доступа для определенного типа объекта называется специфиче­ской маской доступа. Специфические типы и специфическая маска доступа определяются в момент определения типа объекта. Например, файлы Win­dows имеют следующие специфические типы доступа:

Read Data   ReadEA     ReadAttribules

Write Data  WriteEA    WriteAttributes

AppendData Execute

         Стандартные типы (standard types) относятся ко всем объектам и состоят из следующих прав доступа:

Ø    SYNCHRONIZE. Используется для синхронизации доступа и для разрешения процессу ожидать, когда объект перейдет в необходимое сигнальное состояние (signaled state).

Ø    WRITE_OWNER. Используется для назначения с правом записи владельца.

Ø    WRITE_DAC. Используется для разрешения или запрещения досту­па с правом записи к избирательному ACL.

Ø    READ_CONTROL. Используется для разрешения или запрещения доступа с правом чтения к дескриптору безопасности и владельцу.

Ø    DELETE. Используется для разрешения или запрещения доступа с правом удаления.

         Общие или родовые типы (generic types) — это широкий набор типов досту­па, используемых при защите объекта. Точное применение этих типов ус­танавливается приложением, определяющим объект. Например, для того, чтобы проигрывать и редактировать объект голосовой аннотации (voice annotation), приложение, которое определяет объект, может указать спе­цифические виды доступа, используя VOICE_PLAY и VOICE_EDIT. Кро­ме того, это приложение может установить структуру соответствия общего и специфического типов доступа, в которой GENERIC_EXECUTE соот­ветствует VOICE_PLAY, a GENERIC_WR1TE соответствует VOICE_EDIT.

         Специфические стандартные типы детально отражаются в журнале безо­пасности. Общие типы в журнале безопасности не появляются. Вместо этого туда записывается соответствующий специфический или стандарт­ный тип.

1.6.4      Наследование контроля доступа

         Когда внутри контейнерного объекта создается новый объект, он по умол­чанию наследует защиту доступа от родительского объекта.

Изменение прав доступа на каталог действует на весь каталог и файлы, которые находятся в нем, но не относится автоматически к существующим подкаталогам и их содержимому. Для того чтобы права доступа действова­ли на подкаталоги, надо в диалоговом окне Directory Permissions устано­вить флажки Replace Permissions On Existing Files и Replace Permissions On Subdirectories.

1.6.5      Проверка доступа

         Когда пользователь пытается получить доступ к объекту, Windows сравнивает информацию о безопасности в пользовательском маркере дос­тупа с информацией безопасности, содержащейся в дескрипторе безопас­ности объекта.

         Для субъекта создается желаемая маска доступа (desired access mask), осно­ванная на типе доступа, который пытается получить пользователь. Эта маска доступа, обычно создаваемая программой, которую активизировал пользователь, сравнивается с ACL объекта. (Все общие типы доступа при­водятся в соответствие со стандартными и специфическими типами досту­па.) Каждый элемент списка проверяется следующим образом:

Ø    Идентификатор безопасности в АСЕ сравнивается с набором иденти­фикаторов безопасности в маркере доступа пользователя. Если совпадение не найдено, то данный АСЕ пропускается. Дальнейшая обработка основана на типе АСЕ. Элементы ACL типа AccessDenied предшествуют в списке элементам ACL типа AcccssAl-lowed и, следовательно, обрабатываются ранее.

Ø    Если доступ запрещен, система проверяет, содержит ли первоначаль­ная желаемая маска доступа только ReadControI и WRITE_DAC. Если
это так, система проверяет, является ли тот, кто сделал запрос, владельцем объекта. Если это так, доступ разрешается.

Ø     Для АСЕ AccessDenied, действия в маске доступа АСЕ сравниваются с
действиями, описанными в желаемой маске доступа. Если какое-либо
право доступа найдено в обеих масках, то доступ запрещается. В противном случае обработка продолжается проверкой следующего запрошенного АСЕ.

Ø     Для АСЕ AccessAllowed действия в маске доступа АСЕ сравниваются с
соответствующими действиями, описанными л желаемой маске доступа. Если все доступы в желаемой маске доступа совпадают с АСЕ, то
дальнейшая обработка не требуется, и доступ предоставляется. В противном случае обработка продолжается со следующего АСЕ.

Ø    Если для содержимого желаемой маски доступа не найдено полного
совпадения при том, что уже достигнут конец списка контроля досту­па (ACL), доступ неявно отклоняется.

1.7        События безопасности, подлежащие аудиту

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

Замечание

Если вы активизируете аудит, помните, что каждая аудиторская проверка требу­ет небольших накладных расходов (overhead), что отражается на производитель­ности системы.

         Windows может следить за событиями, имеющими отношение как к самой операционной системе, так и к индивидуальному приложению. Ка­ждое приложение может определять свои собственные аудируемые собы­тия. Определения этих событий добавляются в реестр при установке при­ложения на компьютере с Windows.

         Аудируемые события идентифицируются системой по имени исходного модуля (который соответствует специфическому типу события в реестре) и идентификатору события.

         С помощью утилиты Event Viewer события, занесенные в журнал безопас­ности, могут быть отражены по категориям и по идентификатору события. В журнал безопасности могут быть занесены следующие категории собы­тий (категории, заключенные в скобки, можно найти в диалоговом окне Audit Policy в User Manager);

Таблица 6.3. События безопасности, которые могут быть подвергнуты аудиту

1.8        Подсчёт времени репликации

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

         Репликация (replication) - процесс копирования данных из хранилища или из файловой системы на несколько компьютеров для синхронизации данных. Active Directory обеспечивает репликацию с несколькими хозяевами между контроллерами домена в пределах данного домена. Во всех контроллерах домена разрешено сохранение изменений в реплике каталога. Это позволяет обновлять любые реплики в данном домене. Служба репликации автоматически копирует изменения из данной реплики во все другие реплики.

Расчёт месячного времени репликации представлен в табл. 6.4

Таблица 6.4

1.9        Организация безопасности и уровень защиты C2

Уровни защиты распределяются от «А» до «D». Уровень А представляет наивысшую защиту. Уровень C обычно применяется для программного обеспечения в бизнесе. Каждый уровень подразделяется на несколько классов. Например, уровень C подразделяется на C1 и C2. С2 определяет более высокий уровень защиты.

Требования для ОС, которые претендуют на соответствие стандарту C2:

Ø регламентированный доступ и его контроль

Ø идентификация и аутентификация

Ø аудит

Ø повторное использование объектов

Для организации доступа и контроля ОС даёт администратору или пользователю возможность определять, кто может иметь доступ к файлам, и какие операции с этими файлами могут быть произведены. В Windows 200’X Server могут быть проконтролированы объекты и ресурсы, такие как доступ к принтерам и разделяемым областям на сетевых серверах.

Идентификация и аутентификация производятся с помощью средств защищённой регистрации в системе. Для начала работы с Windows 200’X Server все пользователи должны войти в систему. При локальном входе в систему пользователи Windows 200X Server, чтобы убедиться, что в системе не работают программы типа «троянский конь», должны сначала нажать комбинацию клавиш <CTRL>+<ALT>+<DEL>. (Программа типа «троянский конь» может перехватить пользовательскую информацию входа, обеспечивая себе таким образом сетевой доступ). Так как каждый пользователь имеет уникальное пользовательское имя, доменное имя, а также пароль, Windows 200’X Server может обеспечивать ему уникальную идентификацию.

Используя Windows 200’X Server, системный администратор может проводить аудит всех событий, имеющих отношение к безопасности, а также всех пользовательских действий. Утилита User Manager даёт возможность администраторам указать, какие события (например, вход в систему или доступ к файлам) будут подвергаться мониторингу. Вся информация по аудиту сохраняется в журнале событий, который может быть просмотрен с помощью приложения Event Viewer.

Процесс оценки ПО очень сложен. Такого рода оценка базируется на наборе стандартов, опубликованных в так называемой «Оранжевой книге» («Orange Book»). Все дополнительные документы, которые описывают процесс оценок, носят название «Радужные серии» («Rainbow Series»).

         Модель безопасности разработана с учётом уровня безопасности C2 в соответствии с определением, данным Департаментом обороны США.

Основные требования уровня безопасности C2:

Ø    Владелец ресурса (например, файла) должен иметь возможность контроля доступа к этому ресурсу

Ø    ОС должна защищать объекты таким образом, чтобы исключить их случайное использование другими процессами

Ø    Перед тем как пользователю будет предоставлен доступ в систему, он должен идентифицировать себя путём ввода уникального имени и пароля. Система должна иметь возможность использования этих уникальных идентификаторов для отслеживания действий пользователей

Ø    Системный администратор должен иметь возможность аудита всех событий, связанных с безопасностью. Доступ к этим данным должен представляться только авторизованным администраторам.

Ø    Система должна защищать себя от внешнего воздействия. Такого как модификация работающей подсистемы или системных файлов, сохранённых на диске

1.10   Соглашение об именах доменов

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

1.11   Соглашение об именах групп

Корпорация может создать глобальную группу для каждого ресурсного домена. Эта группа может включать в свой состав всех, кто использует этот домен, как свою основную (primary) базу ресурсов. Для всех подразделений или площадок могут быть созданы другие глобальные группы. Работники каждого подразделения могут автоматически становиться членами этой группы. Имя группы должно отражать домен и подразделение, к которым она относится, например: отдел кадров может быть назван Dpt_Pers.Для работников отдела и категории работ может быть создана группа, например, Dpt_Pers_Manager.

1.12   Соглашение об именах пользователей.

         В идеале один пользовательский идентификатор и пароль должны предоставлять доступ ко всем пользовательским ресурсам. Если пользовательский пароль нельзя передать другим системам, то самое лучшее, что можно сделать – это создать последовательную и непротиворечивую структуру имён пользователей в каждой организации, входящей в состав компании. Желательно в имени пользователя в первых трёх символах указывать наименование подразделения, в остальных в произвольной форме личное имя и личный номер пользователя. Например, если условный номер подразделения в классификации компании 057 и необходимо создать имя для пользователя с личным номером 5, то данное имя должно выглядеть следующим образом: U057I005 для случая, если в подразделении работает не более 100 человек. Для подразделения свыше 100 человек, данный номер будет выглядеть таким образом: U057I0005.

1.13   Матрица выбора домена

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

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

Таблица 6.5.Матрица  выбора домена

1.14   Вопросы, помогающие выбрать схему расположения

Для выбора расположения сообществ пользователей, ответьте на следующие вопросы:

Ø где пользователь будет входить в сеть?

Ему необходимо обеспечить доступ к аутентифицирующему резервному контроллеру домена (BDC)

Ø необходимо ли пользователю иметь возможность входить в сеть с нескольких рабочих мест?

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

Ø доступ к каким ресурсам требуется?

Ø Требуется ли пользователю вход в сеть, даже если линия связи с центальной площадкой не работает?

     Являются ли все данные централизованными таким образом, что никакая     обработка не может быть  произведена локально, без линии WAN?

Ø Насколько быстрыми являются линии WAN?

Скорость линии WAN, которая соединяет площадки, определяется исходя из использования ресурсов с помощью этих линий и частоты изменений установок для пользователей или групп.

1.14.1 Требования к аппаратуре

Когда выбирается ПК в качестве главного (PDC) или резервного (BDC) контроллера домена, используйте рекомендации по выбору аппаратуры из табл. 6.6.

1.14.2 Необходимое количество доменов

Количество пользователей в домене зависит от размера базы данных каталога. Таблица 6.7 определяет нужное количество доменов. Встроенные локальные группы для доменов включает такие группы, как Administrator, Domain Admins, Users, Domain Users, Guests, Domain Guests…

1.14.3 Необходимое количество BDC

Соотношение между количеством рабочих станций и серверов в домене определяет время при начальном входе в систему.  Чем больше в домене резервных контроллеров (BDC), тем больше пользователей могут войти в сеть одновременно. Один BDC  может поддерживать до 2000 пользовательских бюджетов.

Табл. 6.8 Кол-во BDC на кол-во пользователей

Рекомендуется производить начальную установку всех BDC на локальной площадке, или с помощью высокоскоростных линий, т.к. каждый новый BDC потребует полной синхронизации с главным контроллером домена (PDC).

1.14.4 Устранение неисправностей

Категории типичных проблем:

Ø    Невозможность просмотра разделяемых ресурсов сервера

Ø    Проблема доступа к разделяемым ресурсам

Ø    Резервный контроллер домена (BDC) не может аутентифицировать пользовательский пароль

Ø    Проблемы, вызванные наличием нескольких главных контроллеров (PDC) в домене

Ø    Проблемы, вызванные специальными символами в имени домена

1.15   Просмотр разделяемых ресурсов

Предположим, работник под именем Polsn входит в домен RCI с паролем SerNik и хочет просмотреть разделяемые ресурсы на сервере, имя которого \\Products, но его пароль здесь Hooray. Polsn увидит сообщение:

Error 5: Access has been denied.

(Ошибка 5 : Доступ запрещён)

Polsn просит администратора сервера \\Products изменить его пароль, но администратор оставляет установленным флажок: Вы должны изменить пароль при следующем входе. Когда Polsn пытается опять просмотреть разделяемые ресурсы сервера, он увидит сообщение:

Error 2242: The password of this user  has expired.

(Ошибка 2242 : Срок действия пароля этого пользователя истёк)

Когда администратор сервера \\Products сбросит данный флажок, Polsn будет иметь возможность видеть серверные разделяемые ресурсы.

1.16   Доступ к разделяемым ресурсам сервера

Два примера помогут объяснить некоторые вопросы доступа.

Ø    Предположим, работник Korsi хочет иметь доступ к разделяемому каталогу на сервере, но не имеет бюджета пользователя в этом домене. Он может получить доступ к этому ресурсу с помощью бюджета Guest на \\Products, получая ассоциированное с этим бюджетом право доступа

Ø    Предположим Polsn вошёл в домен с паролем SerNik. Он хочет присоединиться к разделяемому каталогу на \\Products, где его пароль Hooray. Так  как для Polsn существует бюджет пользователя, он не имеет возможности получить доступ, используя бюджет Guest. Вместо этого ОС предложит Polsn ввести правильный пароль для регистрации на сервере \\Products.

1.17   Не способность BDC аутентифицировать пользовательский пароль

Пользователь пытается присоединиться к домену, где определён его  бюджет, но резервный контроллер (BDC) этого домена не может распознать пользовательский пароль. Эта ситуация возникает, когда пароль изменился, но на момент входа данного пользователя в систему BDC ещё не синхронизирован с PDC. В этом случае BDC передаёт запрос на вход к PDC  в том же самом домене.

Мера, которая может предотвратить подобную ситуацию, заключается в том, что пользователь должен зарегистрироваться  на всех ПК, к которым он имеет доступ, в течении 15 минут после изменения пароля. При этом все кешированные входные параметры пользователя обновляются на каждом ПК. Тогда пользователь будет иметь возможность входа в сеть, и при этом будет использоваться кешированная информация входа, даже если PDC на момент регистрации недоступен.

1.18   Предотвращение существования нескольких PDC в одном домене

         Нельзя конфигурировать несколько главных контроллеров (PDC) в одном домене.

Предположим, администратор устанавливает ПК с Windows 200’x Server с именем ПК \\Main_unit. При установке он сконфигурирован  как PDC домена с именем MainDomain.

После этого администратор отключает \\Main_unit. Затем он устанавливает другой сервер, называемый \\Second_unit, который тоже устанавливается как PDC для MainDomain. Так как \\Main_unit на момент установки второго сервера не работает, первоначальный MainDomain неизвестен, поэтому установки \\Second_unit и создание нового домена MainDomain происходит без ошибки. Два домена с одинаковыми именами не идентичны – они имеют различные идентификаторы безопасности.

         Когда администратор включает \\Main_unit , сервис NetLogon обнаруживает в сети ещё один PDC. При этом NetLogon перестаёт работать, и ПК \\Main_unit не может присоединится к домену. Администратор имеет серьёзную проблему. Просто перекофигурировать \\Main_unit из PDC в BDC и продолжить работу невозможно. Идентификатор безопасности (SID)  для \\Main_unit не будет распознан в текущем PDC, который имеет имя \\Second_unit. Таким образом, ПК \\Main_unit не сможет присоединиться  к домену MainDomain.

         Эта ситуация происходит потому, что уникальный доменный SID создаётся каждый раз, когда создаётся PDC. Все резервные контроллеры домена (BDC) и бюджеты пользователей внутри домена распределяют этот доменный SID. Он является префиксом к их собственному SID. Префикс SID \\Second_unit, установленного как PDC, отличается от префикса SID \\Main_unit,  и эти два ПК не могут одновременно участвовать в одном и том же домене.

Администратор не может изменить имя \\Main_unit и заставить его заново вступить в MainDomain, потому что SID был зафиксирован, когда устанавливалась ОС. Если \\Main_unit должен быть PDC домена MainDomain, администратор должен выключить оба сервера и запустить \\Main_unit, а затем переустановить ОС ПК \\Second_unit и при этом сконфигурировать его как BDC.

         Чтобы избежать этих проблем, сервер \\Second_unit должен быть установлен как резервный контроллер домена в тот момент, когда включён \\Main_unit. Затем, если \\Main_unit выключается, \\Second_unit может быть переконфигурирован в состояние BDC.  SID для \\Main_unit воспринимается сервером \\Second_unit.  Когда \\Main_unit включается, он опять становится PDC.

1.19   Специальные символы в имени домена

В именах доменов не допускается использование следующих спецсимволов:

*  пробел  “  \\  /  [  ]  : |   <  >  +  =  ;  , ?

Хотя некоторые спецсимволы, например, точка (.) являются допустимыми, лучше использовать в именах доменов символы подчёркивания (_) или дефиса (-).

Скачано с www.znanio.ru