Представьте себе такую ситуацию: необходимо создать 10000 учетных записей пользователей, модифицировать 8000 рабочих станций в 30 местах, после чего перестроить 200 серверов и все это без предоставления пользователям ощутимых преимуществ, по крайней мере, на первый взгляд. Администратор в лучшем случае может рассчитывать на то, что пользователь ничего не заметит. Добро пожаловать в неблагодарный мир инфраструктурной интеграции!
Немногие организации работают в однодоменной структуре, при которой переход в структуру Single-Forest/Single-Domain Windows 2000 выполняется легко. Корпоративный обмен данными, ограничения полосы пропускания, требования к администрированию и внутренняя политика компании часто приводят к тому, что в организации возникает мешанина из доменов и доверительных отношений. Следовательно, на первом этапе при переходе к Windows 2000 необходимо произвести слияние существующих доменов Windows NT 4.0 и устранить все шероховатости. Нам предстоит пройти по всему циклу миграции и рассмотреть некоторые ловушки процесса миграции домена, а также изучить методы работы, позволяющие снизить негативные последствия миграции для пользователей.
Принципы, которым нужно следовать для успешного слияния доменов NT 4.0, частично повторяют те, что используются при миграции с NT 4.0 на Windows 2000.
Проблема SID
В NT 4.0 нельзя просто так взять и перенести учетную запись из одного домена в другой. Для каждой учетной записи, глобальной группы, локальной группы и рабочей станции домена имеется уникальное число, называемое идентификатором SID, которое "привязано" к домену. SID состоит из некоего общего, характерного для данного домена, префикса, который сопровождается уникальным суффиксом для учетной записи. Этот суффикс называется относительным идентификатором - Relative Identifier (RID). Поскольку учетные записи ассоциируются с определенным доменом, между доменами их перемещать нельзя; миграция домена означает, что администратор должен повторно создать на целевом домене каждую учетную запись – пользователя, групп и компьютеров. Созданные записи должны обладать теми же свойствами, что и исходные.
Система безопасности Windows 2000 и NT 4.0 использует SID объектов, а не их имена. В элементах ACL можно отыскать ссылки на различные SID. Большинство списков ACL доступны при назначении прав на файлы или каталоги, но кое-что при обычном просмотре не видно. Во врезке "Знаете ли вы, где находятся ваши SID?" приводится список мест размещения ссылок на различные SID.
К сожалению, повсеместное использование SID означает, что на каждом NT-домене организации могут оказаться сотни тысяч или даже миллионы ссылок на SID. И, конечно, администратору предстоит добавить точно такие же разрешения для каждой вновь созданной учетной записи (читай – нового SID) в объединенном домене и проделать это для всех списков контроля доступа (ACL), в которых ранее присутствовал оригинальный SID. Очевидно, что необходим инструмент для манипулирования ссылками SID в процессе миграции. Ниже этот вопрос будет рассмотрен более подробно.
Выбор домена
Чтобы сократить число доменов, можно создать новый домен и перенести в него содержимое имеющихся доменов. Или же выбрав один из старых доменов, перенести туда все остальные домены. Казалось бы, в первом случае преимущество нового домена налицо. Однако, с учетом всего сказанного о SID, такой подход представляется не очень удачным. Миграция двух доменов равного размера в новый домен означает перемещение двойного объема данных по сравнению с ситуацией, когда используется уже существующий целевой домен. Удваивать объем работ – не лучшая идея, если только оба домена не находятся в слишком уж "запущенном" состоянии, поскольку лишь в этом случае, действительно, новый домен избавит администратора от дополнительной работы по ликвидации неполадок в доменах. Если один домен переносится в другой, нужно сначала почистить целевой домен, хотя иногда это проще сделать на завершающем этапе миграции.
Следующий вопрос – какой домен выбрать в качестве донора, а какой - реципиента? Кого-то, наверное, удивит, что выбор домена на роль "мастера", выбор его имени и места установки PDC быстро превращается из технического вопроса в политический. В подобной ситуации следует ввести побольше объективных оценок для принятия решений, таких, например, которые представлены в оценочной матрице домена. Введите несколько критериев выбора и присвойте каждому свой весовой коэффициент на основе важности того или иного критерия. После создания такой матрицы нужно оценить каждый домен по установленным критериям и определить результат. Эта процедура отчасти субъективна, но упростить процесс принятия решений может. Таблица 1 – пример такой матрицы, критерии которой разбиты на группы индикаторов: затрачиваемых усилий, потенциальных отказов и исправности.
Окончательное решение зависит от того, каким весом обладает тот или иной индикатор. Например, если цель миграции – минимальные усилия, то вес индикаторов затрачиваемых усилий должен быть более высоким, чем у остальных индикаторов, и домен ENGLAND следует сделать целевым доменом. Если необходимо добиться более высокого качества, то "тяжелее" должны быть индикаторы исправности, и в качестве целевого следует выбрать домен CANADA.
Измерение SAM
Когда консолидируется несколько доменов NT, нельзя забывать о размере базы данных учетных записей (SAM). По данным Microsoft, максимальный размер SAM равен 40 Мбайт. Однако, по моему опыту, максимальный размер SAM составляет 20Мбайт, в результате превышения могут возникнуть проблемы с производительностью и репликацией базы.
Каждая учетная запись пользователя обходится примерно в 1 Кбайт данных, каждая учетная запись компьютера требует 0,5 Кбайт, каждая глобальная группа – 4 Кбайт. Используйте эти цифры при расчете размера SAM объединенного домена, а затем сравните результаты расчета и реальный размер SAM. База данных SAM находится в каталоге \winnt\system32\config\sam; имейте в виду, что миграция может охватить не все учетные записи обрабатываемых доменов (например, неиспользуемые учетные записи о компьютерах миграции не подлежат).
Предстартовая подготовка
Прежде чем запустить процедуру миграции, следует подготовить домены-доноры и домены-реципиенты. Перед пересадкой органа врач всегда проверяет совместимость донора и реципиента. Точно так же миграция проходит легче, если домены донора и реципиента подобраны близко друг другу по ряду параметров. Некоторые из этих параметров перечисляются ниже:
Пространства имен. В крупных организациях практически неизбежно дублирование имен в рамках всей совокупности доменов. Дублирование может встретиться в именах пользователей, компьютеров, групп, и в других типах имен. Привести в порядок пространства имен надлежит до начала процедуры миграции. Используйте команды Net User, Net View и Net Group для получения распечатки пространства имен в текстовых файлах. Импортируйте эти файлы в Microsoft Excel и воспользуйтесь функцией Excel VLOOKUP, чтобы найти повторяющиеся значения. Если используются различные инфраструктуры WINS, консолидируйте их до начала миграции (но после того, как будут разрешены конфликты с дублированием имен на серверах WINS).
Сценарии регистрации. Консолидируйте сценарии регистрации с доменов-доноров в единый сценарий, который будет запускаться на всех доменах. Это позволит до начала реальной процедуры миграции пользователей избежать проблем при их регистрации в объединенном домене.
Системная политика NT. Выровняйте названия глобальных групп, для которых будет применяться системная политика NT, и убедитесь, что эта политика одинакова для всех доменов.
Учетные
записи системных служб. Измените контекст служб, запускаемых не от
имени учетной записи System (следует использовать ту учетную запись, которая
будет присутствовать в объединенном домене). Служба на сервере в домене X может
быть запущена в домене Y, если между доменами установлены доверительные
отношения и учетная запись в домене обладает достаточными разрешениями. Не забудьте также про службы на рабочих станциях (т.е. Microsoft
Systems Management Server SMS v1.2 - Package Command Manager).
Безопасность. Постарайтесь сформировать единую модель безопасности, которая будет работать в консолидированном домене. Воспользуйтесь миграцией как поводом навести порядок в системе безопасности во всей организации, но не ставьте эту задачу во главу угла, так как излишнее усердие затянет вас в трясину неподъемной работы.
Этапы работы
Если в миграции задействовано огромное количество серверов и учетных записей, весь объем работ целесообразно разделить на несколько этапов. Четыре направления, слабо связанные между собой, это: миграция учетных записей пользователей, миграция контроллеров домена (DC), миграция серверов домена (не являющихся DC), и, наконец, миграция рабочих станций.
Обычно миграцию серверов можно выполнять в фоновом режиме, с меньшими дополнительными временными затратами, чем для учетных записей пользователей. Далее, миграцию DC и серверов, не являющихся DC, можно выполнить одновременно. Понятно, что миграцию DC следует выполнять с учетом времени начала работ с учетными записями пользователей и переноса не-DC серверов, поскольку контроллеры домена играют роль центров аутентификации и серверов, и пользователей. Рабочие станции можно переносить параллельно. Не исключено, что часть работ придется выполнять в ночное время или в выходные дни из-за большой загруженности сети во время миграции.
Далее я приведу несколько полезных советов по каждому из четырех этапов работ. Но уже сейчас важно понимать, что миграция учетных записей пользователей – наиболее ответственный процесс.
До того, как будет начат любой из этапов, полностью задокументируйте процедуру миграции и несколько раз "прогоните" ее в тестовой лаборатории, каждый раз уточняя описание миграции и совершенствуя сам процесс. В лабораторных условиях восстановите резервные копии реальных серверов в максимально возможном приближении. Если тестовой лаборатории нет, попробуйте ее создать. Проверьте путь в серверную комнату; многие проекты разваливались из-за того, что в нужный момент невозможно было добраться до сервера. Тщательная подготовка окупится сторицей и во время "боевой" миграции - неприятных сюрпризов будет меньше.
Подготовьте пользователей. В самом начале статьи уже говорилось, что слияние доменов нарушит привычную работу пользователей, а взамен они практически ничего не получат. Поэтому важно объяснить им цель выполняемых операций – займитесь рекламой своего проекта. Используйте любые коммуникационные каналы, имеющиеся в вашем распоряжении, напишите статью в корпоративный журнал. Если проект достаточно крупный, придумайте для него логотип, название, создайте сайт. Пользователи должны знать, что происходит.
Миграция учетных записей пользователей
Если предстоит выполнить миграцию очень большого числа учетных записей пользователей, то, вероятно, за один сеанс не управиться. Производительность программы, которая используется для миграции, и временной период, которым вы располагаете, определят число записей, переносимых за один сеанс. Если нельзя перенести все учетные записи за один раз, можно выполнить миграцию пользователей не в рабочую группу, а на сервер, где хранятся персональные файлы пользователей. Это будет означать, что на время миграции сотрудники, выполняющие одну и ту же работу, могут очутиться в разных доменах. С точки зрения перспективы совместного использования ресурсов, такая ситуация вряд ли вызовет проблемы, если используется программа миграции, позволяющая восстанавливать права объектов в домене-доноре. Однако для администратора системы такой подход неудобен. Следовательно, нужно стремиться сократить время переходного периода миграции настолько, насколько это возможно.
Рабочий инструмент миграции
Всякому, кто хотя бы раз выполнял миграцию в режиме реального времени, приходилось заниматься поисками программного инструмента от независимых разработчиков. Для сопоставления подобных программ есть смысл сформировать еще одну оценочную матрицу, в которой нужно перечислить требования к процедуре миграции и дать оценки соответствия продукта поставленным требованиям. Вот некоторые из очевидных требований:
· Возможность проверить и модифицировать любую
встроенную ссылку на SID (в том числе для NTFS и реестра) для максимально
возможного числа приложений (например, для Microsoft Exchange Server, Microsoft SQL Server). Назовем такую
возможность корректировкой ACL.
· Возможность обслуживать существующие ссылки
на SID до тех пор, пока миграция не завершится полностью. Не хотелось бы, чтобы
программа удаляла оригинальные идентификаторы SID; скорее уж она должна
добавлять SID новой учетной записи с аналогичными разрешениями доступа всякий
раз, когда находит оригинальный SID. Такой подход дает администратору
возможность вернуться назад в случае сбоя в процессе миграции без необходимости
последующего восстановления учетных записей.
· Возможность
миграции паролей с одного домена на другой.
· Возможность
проверки значений SID для тысяч или миллионов объектов в LAN или WAN за
короткое время. Таким образом, должен существовать программный агент миграции.
· Возможность
манипуляций с перемещаемыми профилями пользователя (roaming user profile) и локальными профилями. Здесь опять же, поскольку эту задачу следует
выполнять по запросу, желательно наличие программного агента.
И в завершение возможный список производителей программ миграции: Aelita Software, BindView, NetIQ, Quest Software (прежнее название FastLane Technologies).
Продавцы программного обеспечения иногда предлагают за определенную плату арендовать утилиты миграции или разрешают на некоторое время работать с ними бесплатно, если вы пользуетесь услугами компании-партнера. Если после проведения миграции программа миграции больше не понадобится, есть смысл рассмотреть такие предложения.
Профилям пользователя - особое внимание
По моим наблюдениям, наиболее неприятный момент при переносе учетных записей пользователей – миграция профилей NT. Обычно программа миграции копирует существующие блуждающие профили в некий каталог под новым именем, после чего начинается трансляция профиля - для каждого файла, каталога и записи реестра в новой копии программа выполняет процедуру корректировки ACL. Затем вновь созданная учетная запись настраивается на использование нового профиля. Метод хорош, так как он оставляет в неприкосновенности связку оригинальная учетная запись – оригинальный профиль. Но, к сожалению, такой алгоритм работы имеет свои недостатки:
Профили занимают на диске очень много места. На каждом сервере дополнительно должно быть выделено столько же места, сколько занимают уже существующие профили. Таким образом, перед началом миграции нужно убедиться в наличии достаточного количества свободного пространства на дисках сервера.
Трансляция профилей занимает слишком много времени. Трансляция профилей может поглотить все отведенное для миграции время. Постарайтесь заранее оценить затраты времени на трансляцию. Также учтите, что каналы связи могут быть не быстрыми (например, медленный WAN), что еще больше замедлит весь процесс. В результате трансляция профилей может стать определяющим фактором для ответа на вопрос – сколько учетных записей можно обработать за один сеанс.
После загрузки профили могут оказаться испорченными. Когда пользователь регистрируется с новой учетной записью, локальный профиль, находящийся в кэш, перестает соответствовать изменившимся условиям (или вовсе оказывается недоступным). В результате пользователи должны вручную скопировать новые профили по сети. Это отнимает драгоценное время и загружает сеть, а в итоге новый профиль может оказаться испорченным. Некоторые пользователи имеют гигантские профили, которые не помещаются на диске рабочей станции; самый большой профиль, который мне пришлось "гонять" по сети, достигал 1,5 Гбайт. Необходимо разработать надежные процедуры и протестировать их, чтобы в нужный момент прийти пользователю на помощь.
При трансляции профили должны быть актуальными. Миграционные утилиты транслируют копию профиля пользователя, следовательно, нужно заранее быть уверенным, что эта копия не слишком старая. Обновить профили удаленных пользователей особенно важно, поскольку такие пользователи обычно работают с кэш-профилями.
Полезные советы
Вот несколько советов, которые облегчат задачу администратора. В прилагаемых листингах содержатся сценарии для автоматизации некоторых аспектов миграции.
Уменьшите размер дискового пространства, который отводится под профили, подлежащие миграции. Если в вашем распоряжении есть хорошая резервная копия перемещаемых профилей, подлежащих миграции, из них всегда можно до начала миграции выделить значительный объем данных и вставить его обратно после ее завершения. Это позволит сэкономить и время, и место на диске. В Листинге 1 и Листинге 2 демонстрируется код для DOS, реализующий задачу выделения такого балласта из профиля пользователя. Непосредственно перед началом миграции на рабочей станции нужно запустить сценарий Листинга 1. Данный сценарий формирует задачу для каждого пользователя из списка в текстовом файле и передает ее планировщику NT - NT Task Scheduler – того сервера, где располагается собственно профиль пользователя. При этом файлы некоторых типов из профиля пользователя копируются во временные каталоги. В коде Листинга 2 указывается, какие именно файлы следует скопировать. После завершения процедуры миграции нужно выполнить обратную задачу – возвратить выделенные файлы во вновь созданные профили; при этом файлы будут наследовать систему разрешений от каталога верхнего уровня нового профиля.
Отключите пользователей на время миграции. Миграция для большинства учетных записей пользователей может закончиться неудачно, если во время миграции пользователи будут регистрироваться в исходном домене. Отключите пользователей перед началом миграции от исходного домена (и "пустите" их обратно в старый домен только в случае восстановления из-за ошибки миграции). Не предоставляйте пользователям возможности регистрироваться в новом домене до тех пор, пока миграция не завершится полностью.
Добавьте новое меню Start для пользователей, завершивших миграцию. Возможно, вы захотите добавить программу для каждого мигрировавшего профиля пользователя в каталог Start – например, это будет самоудаляющийся BAT-файл, который выполняет некоторые пост-миграционные задачи, или диалоговое окно с пост-миграционными инструкциями для пользователя. Код Листинга 3 копирует новый пункт в меню Start в перемещаемый профиль для мигрировавших пользователей. В данном случае сам пункт меню Start не расшифрован. В качестве примера можно использовать сценарий, который предложит пользователям обновить их контактную информацию в корпоративном телефонном справочнике. Или, например, сценарий, который посылает по электронной почте сообщение, извещая сотрудников службы поддержки о факте самой первой регистрации пользователя после завершения процедуры миграции.
Создайте резервную копию SAM. На тот случай, если что-то пойдет не так, следует заранее позаботиться о создании резервной копии SAM. Рекомендую до начала миграции выключить один из BDC исходного домена, и не включать его после миграции несколько дней. В случае непредвиденных обстоятельств всегда можно перевести BDC на уровень PDC, тем самым восстановив исходный домен.
Каждому пользователю, участвующему в миграции, пошлите сообщение по электронной почте. Если у вас имеется текстовый файл со списком мигрирующих пользователей, с помощью утилиты командной строки отправьте почтовое уведомление о предстоящей миграции или пост-миграционные инструкции. Предварительно нужно сопоставить имена NT и почтовые адреса (и опять – функция Excel VLOOKUP может пригодиться).
Миграция DC
Миграция DC – это скорее их переустановка, нежели действительно миграция. Из соображений безопасности специалисты Microsoft не разработали механизм для перемещения контроллеров домена из одного в другой, как это было сделано для серверов и рабочих станций домена. Я предвижу возражения на столь категоричное утверждение, но перемещение DC в "чужой" домен потребует внести в реестр очень много изменений. Не забудьте, что в "старом" домене нужно поддерживать в рабочем состоянии основной контроллер (PDC) до тех пор, пока нет уверенности, что этот домен можно удалить. Поэтому может потребоваться перенос некоторых функций PDC на другой или новый сервер.
Перед тем, как выполнить переустановку DC, сохраните важные данные и параметры настройки сервера. После этого можно приступать к замене данных на сервере. Вот некоторые типы данных, которые удаляются или заменяются:
·
данные и профили
пользователя;
·
очереди
принтеров;
·
приложения и продукты
Microsoft BackOffice (например, сайты SMS);
·
сетевые
установки (например, IP-адреса);
·
настройки DHCP и WINS.
Подробно вопрос сохранения и последующего
восстановления настроек базы данных DHCP
и WINS рассмотрен в
следующих статьях Microsoft:
"How
to Move a DHCP Database to Another Windows Server"
"Recovering
a WINS Database from Other Backup Sources"
"Restore
of WINS Database to a Different Server Fails"
Миграция серверов – членов домена
Администратор может свободно перемещать серверы между доменами NT, и нет необходимости устанавливать их заново. Миграция сервера, на котором хранятся только данные пользователя, выполняется просто. Создайте резервную копию сервера, поменяйте название домена в модуле Network панели управления Control Panel и перезагрузите сервер. Наверное, главное, что следует помнить в этом случае – сервер должен иметь доступ к PDC старого и нового доменов.
Более осторожно следует перемещать серверы, на которых работают приложения BackOffice, например, Exchange или SQL Server, из-за встроенных на уровне приложения идентификаторов SID и контекста запуска системных служб. Следует убедиться, что учетные записи домена X, которые используются в контексте работы на сервере в домене X, будут работать и после того, как учетные записи "переедут" в домен Y. Проверку следует произвести до того, как сервер мигрирует в домен Y.
Вероятно, вы захотите рассмотреть вопрос о консолидации почтового сервера Exchange всей организации во время проведения процедуры миграции.
Миграция рабочих станций
Если миграционные утилиты позволяют выполнить миграцию рабочих станций, это возможно только для тех из них, которые функционируют в режиме 24*7, в противном случае могут возникнуть проблемы. Механизмы миграции отчасти неэффективны для удаленных рабочих станций, которые в момент проведения миграции могут оказаться попросту выключенными.
Чтобы выполнить миграцию рабочей станции, сначала необходимо удалить ее учетную запись из старого домена и создать новую запись в новом домене. Затем следует включить рабочую станцию в состав нового домена. Также нужно добавить глобальную группу Domain Admins нового домена в локальную группу Administrators рабочей станции. Тонкости в настройках рабочей станции также могут сказаться на проведении процедуры миграции (например, может понадобиться внести изменения в настройки контекста службы SMS Package Command Manager).
Совет: разработайте постепенный механизм миграции рабочих станций в те часы, когда вы точно знаете, что рабочие станции доступны. Дополнительно можно написать сценарий NT, в котором будут задействованы утилиты из стандартного набора Microsoft Windows NT Server 4.0 Resource Kit - Netdom, Usrtogrp, Nltest. Для различных операционных систем клиента могут потребоваться немного различающиеся сценарии, но всегда при выполнении миграции можно применить последовательный обход рабочих станций.
Устранение проблемы SID
Все серверные объекты, которые были перемещены в новый домен, по-прежнему имеют элементы ACL со ссылками на оригинальные SID учетных записей (из старого домена). Финальная фаза миграции – удаление подобных ссылок.
После того, как выполнена миграция всех учетных записей пользователей, всех серверов (почти) и всех рабочих станций, в старом домене должен остаться только один компьютер – PDC. Выключите его на время испытаний, чтобы установить, не осталось ли каких-либо неучтенных связей со старым доменом на компьютерах нового домена. Если по истечении нескольких недель ничего неожиданного не проявится, можно решать вопрос об "удалении" старого домена.
Работы по интеграции инфраструктуры могут оказаться исключительно полезными, но, вероятно, сначала нужно получить одобрение на проведение таких работ от других членов группы администраторов. Если миграция выполнена хорошо, обычные пользователи ничего не заметят, кроме того, что регистрация теперь выполняется в другой домен. Но если работа сделана небрежно, на ликвидацию последствий уйдет не один месяц. Секрет успешного проведения миграции состоит в умении тщательно продумать все этапы и не упускать мелочей.
Знаете ли вы, где находятся ваши
SID?
SID (security identifier - идентификатор защиты) – это критический элемент системы безопасности Windows 2000 и Windows NT 4.0. Следует помнить, что в рамках домена могут существовать не только идентификаторы SID домена, но и SID локальных учетных записей на компьютере и учетных записей в доверяющем домене. Ниже перечислены некоторые очевидные и не очень очевидные места, где могут встретиться ссылки на SID:
Файлы и каталоги NTFS. Каждый файл и каталог на разделе NTFS имеет три различные области, в которых SID может встретиться в составе ACL. Список разграничительного контроля доступа (Discretionary ACL - DACL) указывает на разрешения доступа к объекту. DOMAIN1\JBLOGGS = Full Control – пример элемента DACL. Системный список контроля доступа (System ACL - SACL) определяет, будет ли выполняться аудит при обращении к файлу или каталогу. Для просмотра SACL файла выберите File, Properties в Windows Explorer и перейдите на вкладку Auditing. SID, кроме того, указывает на собственника файла или каталога.
Разделы и параметры реестра. Каждый профиль пользователя NT имеет ассоциированный в ветви HKEY_CURRENT_USER раздел, хранящийся в файле профиля пользователя ntuser.dat. Как и в случае с обычным файлом или каталогом, в списке доступа к разделам реестра, к аудиту и при определении собственника раздела используются ссылки на SID. До того момента, как новая учетная запись в новом домене сможет получить доступ к скопированному профилю пользователя NT, администратор обязан разрешить все ссылки для дескриптора защиты в части ACL и все встроенные ссылки.
Совместно используемые каталоги и принтеры. Совместно используемый в NT файл и принтер имеют систему разрешений, сходную с разрешениями файлов NTFS.
Права пользователей NT. В User Manager в NT, выбрав Policies, User Rights вы увидите группы или отдельных пользователей, которым назначаются те или иные права. Например, право Back up files and directories обычно назначается группам Administrators и Backup Operators, у каждой из которых имеется свой уникальный SID.
Учетные записи служб. Если службы NT запускаются в контексте определенной учетной записи, то во время процедуры миграции нужно помнить о необходимости реконфигурации этих же служб в новом домене.
Списки контроля доступа Microsoft Exchange Server. Каждый почтовый ящик Exchange и общая папка имеют ассоциированный ACL (на вкладке Permissions для каждого объекта это можно выяснить). Кроме того, объекты Exchange Site и Configuration также имеют свои списки ACL.
Списки Microsoft SQL Server. Если для системы SQL Server применяется интегрированный режим безопасности NT-integrated (в отличие от basic security, когда безопасность основана на вводе имени и пароля пользователя SQL), объекты базы данных также имеют списки ACL для предоставления или запрета доступа.
Web, proxy и другие серверы. Автономные серверы тоже могут использовать ссылки на SID для контроля доступа к своим объектам.
Пат Телфорд - MCSE, специализируется на переходе с Windows NT, консультирует в течение 10 лет. С ним можно связаться по адресу: pat@eeljuice.com.
Стефен Даунс - независимый консультант, инструктор, специалист по сетевой инфраструктуре. С ним можно связаться по адресу: stephendownes@tetrix.uk.net.