В Wndows Server 2008 R2 версия схемы = 47
Версию схемы можно узнать с помощью запроса
dsquery * CN=Schema,CN=Configuration,DC=Root-Domäne -Scope Base -attr objectVersion
Также есть еще один способ определения версии Active Directory – с помощью ветки реестра:
HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\<Schema Version>
Файл NTDS.DIT содержит данные Active Directory (AD)для конкретного домена и хранится в каталоге %systemroot%\ntds. Размер этого файла может быть достаточно большим. Для увеличения быстродействия AD может потребоваться перемещение файла на другой жесткий диск.
1. Перезагрузите контроллер домена.
2. Нажмите клавишу <F8> в загрузочном меню.
3. Выберите команду Восстановление службы каталогов (Directory Services Restore Mode).
4. Выберите необходимую копию операционной системы, если на компьютере установлено более одной системы. После этого зарегистрируйтесь в системе с правами администратора.
5. Откройте интерпретатор командной строки (Пуск > Выполнить > CMD (Start > Run > CMD)).
6. Откройте утилиту NTDSUTIL.EXE.
7. В приглашении утилиты ntdsutil введите команду files, как показано ниже:
ntdsutil: files
8. В приглашении file maintenance введите следующую команду:
file maintenance: move DB to
9. Для просмотра базы данных в меню file maintenance введите команду info.
10. Для проверки целостности базы данных на новом диске в приглашении file maintenance введите команду integrity.
11. Дважды введите команду quit для возврата к основному приглашению командной строки.
12. Перезагрузите компьютер в обычном режиме работы.
В пример буду приводить набирающую обороты Ubuntu, как систему для простых пользователей.
Набираем в консоли от имени суперпользователя:
apt-get install curlftpfs
Теперь нужно создать папку, куда будем монтировать FTP-хранилища. Предлагаю использовать /media, в этом случае они будут сразу отображаться в наутилусе:
mkdir /media/ftp
Чтобы не делать все операции от суперпользователя, добавим текущего юзера в группу fuse и установим нужные права на целевой каталог:
adduser имя_пользователя fuse
chgrp fuse /media/ftp
chmod g+w /media/ftp
curlftpfs ftp://[пользователь]:[пароль]@имя_сервера /media/ftp [опции]
или
curlftpfs имя_сервера /media/ftp -o user=пользователь:пароль [другие_опции]
мне второй вариант нравится больше.
Не забываем, что многие сервера создаются для виндуз-пользователей. Встроенный в винду FTP-клиент знает только одну кодировку: windows-1251, и именно в этой кодировке подобный FTP-сервер будет передавать имена файлов.
Соответственно, так как у нас utf8, вместо русских имён мы увидим абракадабру. И наоборот: при создании файла с русским именем, абракадабру увидят виндуз-пользователи.
Чтобы этого избежать, дописываем в опции соединения: codepage=windows-1251 (указываем какая кодировка используется на сервере) и iocharset=utf8 (указываем какая кодировка у нас, можно не писать).
curlftpfs имя_сервера /media/ftp -o user=пользователь:пароль,codepage=windows-1251[,iocharset=utf8]
Или делаем то же, но используя модуль iconv, что правильнее:
curlftpfs имя_сервера /media/ftp -o user=пользователь:пароль,modules=iconv,from_code=CP1251,to_code=UTF8
Лирическое отступление.
Мой местный интернет-провайдер держит анонимный FTP-сервер. Его поддерживают замечательные администраторы, он до сих пор не понимает маленькую букву «я» в названиях файлов. Но дело даже не в этом.
Скорость заливки/скачивания на этом сервере не ограничена. Но! При попытке открыть несколько FTP-сессий, скорость на несколько минут падает до нескольких килобайт в секунду. С учётом, что на дворе 21 век, 2010 год, параллельные вычисления и нанотехнологии, считаю такой подход замечательным.
Чтобы забыть про администраторов нетрадиционной сексуальной ориентации, можно использовать опцию -s при подключении curlftpfs. Она отключит многопоточные операции.
curlftpfs имя_сервера /media/ftp -o modules=iconv,from_code=CP1251,to_code=UTF8 -s
Для автомонтирования ресурса при каждом запуске, добавим следующую строчку в файл /etc/rc.local:
sudo -u пользователь curlftpfs [параметры_подключения]
где пользователь – имя локального пользователя, от которого запустится curlftpfs.
fusermount -u /media/ftp
От имени текущего пользователя. Или, если хочется поизвращаться, то от имени суперпользователя:
umount /media/ftp
http://wiki.enchtex.info/tools/console/curlftpfs
После монтирования выполните команду df, о ужас – по умолчанию в таблице монтирования
имя файловой системы присваивается следующего вида:
curlftpfs#ftp://user:pass@host
Опция fsname=поможет скрыть эти данные.
Логин и пароль засвечиваются только в том случае, если писать их в URI для подключения.
Если передать их опциями (-o user=login:password), то всё будет хорошо.
http://www.opennet.ru/tips/info/2090.shtml
Автоматизировать ввод пароля можно через стандартный ~/.netrc файл (man netrc):
machine ftp.test.ru
login логин
password пароль
http://tuxologia.blog.ru/tag/curlftpfs
Автомонтирование через fstab:
curlftpfs#ftp.host.com /mnt/host fuse rw,uid=500,user,noauto 0 0
Совет: Перед изменением /etc/fstab — проведите монтирование вручную, после чего выполните команду mount (или cat /etc/mtab).
Источник и назначение монтирования надо будет внести в fstab согласно этому выводу, с точностью до символа.
Полезные опции:
noauto — не монтировать при загрузке;
uid=# — идентификатор владельца (кому нужно заходить на подмонтированный ресурс);
_netdev — указание, что ресурс сетевой.
http://www.ubuntueasy.com/prilozhenija/montirovanie-ftp-razdelov-ispolzuja-curlftpfs
http://ubuntuforums.org/showthread.php?t=441126
Привет.
В данной статье я расскажу про мелкую, но интересную функциональную единицу в составе Active Directory – механизм AdminSDHolder и то, как он защищает встроенные и стандартные группы. Рассказ будет про современную реализацию – в Windows Server 2008 R2, ну а детали про предыдущие реализации я буду иногда упоминать.
Поехали.
AdminSDHolder – это объект в каждом домене леса Active Directory, который будет хранить в себе информацию о настройках безопасности для специфического подмножества групп, называемых “защищёнными группами” – “protected groups”. В основном это BUILTIN-группы. Сам объект будет располагаться в domain partition, в контейнере System.
Суть работы всего механизма будет достаточно простой. В Active Directory за задачи AdminSDHolder будет отвечать держатель маcтер-роли PDC Emulator. Он будет иметь жёстко прописанный список групп (разный в зависимости от версии серверной ОС, установленной на DC с ролью PDC Emulator), и, с определённой периодичностью (по умолчанию раз в час), данный механизм будет запрашивать перечень всех security principals, входящих в эти группы, а после – выставлять им ACL в соответствии с ACL’ом от объекта AdminSDHolder. Сам объект будет обладать достаточно занимательным ACL’ом, а чтобы исключить влияние унаследованных прав, наследование на данном объекте будет выключено.
Зачем это будет нужно?
Первое – это, безусловно, безопасность. Данный механизм делает ACL’ы учётных записей, находящихся в “защищённых группах”, предсказуемыми и страхует от случайного или преднамеренного изменения. Ну, к примеру, админ, увольняясь, может напоследок сделать какую-нибудь “приятную мелочь” – например, разрешить любому из Domain Users сбрасывать пароль одному из Account Operators, а у оных уже прописать такое же право, но на Enterprise Admins. Такое вручную вычислить достаточно сложно, да и утомителен такой аудит. Механизм обработки AdminSDHolder может решить эту проблему превентивным способом.
Второе – учётные записи, входящие в “защищённые группы”, могут быть в любом месте иерархии Active Directory. Соответственно, на них могут действовать унаследованные ACL’ы, которые будут изменять ситуацию с безопасностью критичных учётных записей. Рассматриваемый механизм блокирует наследование ACL’ов для всех целевых учётных записей.
Для Windows Server 2008 R2 это будут:
На практике возможна ситуация, когда постоянная “прокатка” ACL’ов для определённых security principals нежелательна. Это частично решаемо следующим образом.
Примечание: Частично – потому что вывести из-под этого механизма можно только одну или несколько групп семейства Operators. Для других групп это не получится.
В разделе Configuration есть объект с DN такого вида: CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=корневой_домен_леса. У этого объекта есть замечательный атрибут – dsHeuristics. Данный атрибут выглядит как unicode-строка, где 16й по порядку шестнадцатеричный разряд – это группа из 4х бит, которые, будучи включенными, обозначают:
То есть, если захотите поправить – подумайте, какие группы хотите исключить, вычислите итоговое значение, откройте данный атрибут (он может выглядеть как-то так: 000000000100000с) и поправьте. В примере у меня на 16й позиции символ “C”, это значит, что Print Operators (которые 0100) и Backup Operators (которые 1000) исключаются из процесса.
Примечание: Операция делается на уровне леса, т.е. значение данного атрибута, заданного у корневого домена леса, будет использоваться всеми PDC-эмуляторами в лесу
Это делается через редактирование следующего ключа реестра:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
в котором есть значение AdminSDProtectFrequency типа DWORD32. Если его нет – используется значение по умолчанию, равное 3600 секундам (1 час). Если хотите изменить этот параметр – создайте данное значение и присвойте ему нужное количество секунд. Имейте в виду, что до перезапуска службы ADDS на PDC-эмуляторе это значение не вступит в силу.
Примечание: Значения менее 1й минуты и более 2х часов не будут обрабатываться.
Для этого есть только один надёжный способ – вызов на объекте rootDSE операции RunProtectAdminGroupsTask. Для этого надо будет запустить утилиту ldp.exe, вначале подключиться (сделать ldap connect) к держателю роли PDC-эмулятора, после – подтвердить свои права авторизацией (через ldap bind), ну а после – “заказать” операцию, выбрав в меню Browse->Modify и указав названием атрибута – RunProtectAdminGroupsTask, значением – 1, типом операции – Add и нажав Run. Значение DN надо оставить пустым.
Примечание: До Windows Server 2008 R2 это делалось так же, но использовалась другая операция – FixUpInheritance, и вместо единицы в качестве значения надо было указывать Yes.
В общем-то из ключевого это всё. Теперь тонкости.
Классикой жанра является заблуждение, что “у distribution-групп нет SID’а”. SID есть у всех объектов класса group, потому что данный объект относится к security principal. Если бы у distribution-групп не было SID’а, то тогда, неоднократно переключая тип группы между security и distribution, у группы каждый раз бы создавался новый SID, что, как несложно убедиться, не происходит.
К чему бы я это? К тому, что в маркере доступа SID’ов distribution-групп обычно нет – lsass их туда не добавляет, читая флаг “не-security-enabled-группа” (который, в общем-то, и является основным отличием между distribution и security группами). А вот механизм вычисления перечня security principals, подпадающих под карающий меч AdminSDHolder – добавляет. Говоря проще, если учётная запись X входит в безобидную группу почтовой рассылки “Поздравления к 23 Февраля”, а эта группа входит, допустим, в Backup Operators (бред конечно с практической точки зрения, но вдруг), то все участники списка рассылки будут подпадать под механизм AdminSDHolder. Он не различает security/distribution группы.
Учитывайте это при проектировании механизма защиты учётных записей.
Когда при очередной “прокатке” домена данным механизмом он находит подпадающую под нужный критерий учётную запись или группу, он [механизм] ставит объекту атрибут adminCount в единицу. Что интересно – снимать назад не умеет. Т.е. у не-подпадающих security principal’ов нуль не пишет. Поэтому когда учётная запись, допустим, была участником Domain Admins, а после перестала, на ней сохраняется этот атрибут, и она начинает находиться в интересной ситуации – ACL у неё уже не перезаписывается AdminSDHolder’ом, но наследования нет.
Автоматического исправления этой ситуации нет. Для исправления Microsoft предлагает скрипт, доступный здесь.
Данный механизм – штука весьма интересная. Надо, по крайней мере, знать как он работает и управляется, чтобы не удивляться самопроизвольному изменению ACL’ов у ряда учётных записей. Модифицировать время применения особо не нужно, КПД этого мероприятия сомнительно.
Удач.
Привет.
Кастомизация Active Directory – тема вечная. Вокруг неё накручено много вымыслом, шаманства и прочего, однако тема эта никакого волшебства в себе не содержит. Я это наглядно покажу.
Однажды к одному CIO пришёл руководитель IT-департамента.
– В Active Directory есть глючные объекты, у которых нет картинки. Вот, смотри:
– Траст до партнёрского домена есть, а судя по картинке – глючный. Люди волнуются, говорят, что надо домен переставлять, наверное.
“Люди не должны волноваться. Чистый разум, по которому бежит рябь мысли о переустановке Active Directory, подобен нечистому разуму, а таких по ТК премии лишают. Нельзя так с людьми.” – подумал CIO.
Отображение всех объектов в Active Directory предприятия регулируется в контейнере CN=Display Specifiers,CN=Configuration,DC=доменный контекст. В нём Вы найдёте отдельные контейнеры, название которых соответствует языковому коду – для английского это будет 409, если хотите, чтобы объекты отображались в разных в плане языков консолях Active Directory по разному – просто поправьте не в одном, а в нескольких. Откуда берётся число 409? Это 1033 в hex-варианте, а справочник по кодам языков Вы можете легко найти, никуда не выходя с локальной машины – откройте ключ реестра HKLM\SYSTEM\CurrentControlSet\Control\ContentIndex\Language, там в каждом разделе будет Locale, которое, путём перевода в hex, и даст искомый код. Выглядеть в нашем случае консоль для редактирования этих свойств будет как-то так:
Объект, который мы хотим поправить, имеет класс trustedDomain-display. Откроем вкладку Attribute Editor, и в ней найдём атрибут iconPath. Данный атрибут позволит нам задать до 16 различных картинок, используемых для разных состояний объекта (например, у пользователя разные картинки, когда он в обычном состоянии или в Disabled). Картинку, которую мы поставим, мы заранее выложим в папку \\FQDN домена\SYSVOL\FQDN домена\Pics – этим мы решим вопрос с автоматической репликацией картинки на все контроллеры домена, да и подгружаться она будет с ближайшего, что тоже плюс.
Нам будет нужна только дефолтная, поэтому мы зададим путь к картинке номер нуль для данного типа объектов:
Результат будет таким:
Теперь у этого типа объектов своя, хорошо заметная картинка. Она будет автоматически появляться в любой консоли Active Directory Users & Computers. Ничего дописывать не надо, никаких хаков не делается, всё штатно, централизовано и удобно. Переустановка “глючного домена” отменяется.
Однажды к одному CIO пришёл руководитель IT-департамента.
– Помнишь Васю, которому мы обещали проставиться?
– Конечно помню.
– Вот и я помню. А если забудем? Надо как-то сделать так, чтобы такое не забылось. Иначе мы потеряем лицо.
– Ты не поверишь – но это – встроенная возможность Active Directory
В схеме Active Directory есть штатный атрибут drink – его описание выглядит как “The drink (Favourite Drink) attribute type specifies the favorite drink of an object (or person)”.
Это пачка текстовых строк в Unicode, которая благоразумно не добавлена в объект user по умолчанию. Мы её добавим – сделать это несложно:
regsvr32 schmmgmt.dllmmc, добавим туда оснастку Active Directory Schema, и найдём там в контейнере Classes класс user
Закроем оснастку Active Directory Schema, т.к. она нам больше не понадобится, и откроем ADSI, чтобы теперь добавить этот замечательный атрибут в GUI оснастки Active Directory Users & Computers. Путь наш будет лежать туда же, как и в прошлой истории – в контейнер CN=код языка,CN=Display Specifiers,CN=Configuration в лесу Active Directory. Мы выберем тот тип контейнеров, при просмотре которых у нашего пользователя должны выводиться дополнительные атрибуты – например, OU; называться он будет organizationalUnit-Display, а интересовать нас в нём будет атрибут extraColumns:
Формат добавления строки достаточно прост:
Таких строк, как понятно, можно добавить несколько – всё зависит от того, что Вам конкретно надо отображать в первую очередь. Это удобнее, чем каждый раз кликать на пользователе, чтобы просмотреть нужный атрибут, отсутствующий в консоли Active Directory Users & Computers по умолчанию.
Как понятно, и тип родительского контейнера, и тип объекта, и атрибут можно менять произвольно – плюсом будет то, что это не потребует никакой модификации стандартной консоли и будет сразу работать “из коробки” во всей организации.
Однажды к одному CIO пришёл руководитель IT-департамента.
– Слышал вчера вопли у sales’ов. Михась орал на какого-то своего, мол, “Какое ты имеешь право пить на работе, скотина?”
– Да, работать в такой ситуации невозможно. Ведь администратору Active Directory непонятно по учётной записи пользователя, имеет ли он право пить на работе или нет. Отсюда непонимание, а это – корень всех бед в коллективе. Надо исправлять.
Типы прав в Active Directory – динамическая структура, поэтому мы добавим нужное нам право. Откроем ADSI и зайдём в контейнер CN=Extended-Rights,CN=Configuration в нашем лесу Active Directory.
Мы создадим новый пустой экземпляр объекта класса controlAccessRight и назовём его предсказуемо:
Какие же нам надо будет задать атрибуты, чтобы всё заработало? Их не очень много.
Мы хотим, чтобы это право было у пользователя – открываем ADSI, зацепляемся за схему, находим там classSchema с названием User, и копируем у него атрибут schemaIDGUID:
Этот GUID будет bf967aba-0de6-11d0-a285-00aa003049e2; мы добавим его в атрибут appliesTo у нашего нового типа прав:
Этого хватит – нам же не нужно, чтобы контроллер домена имел право бухать на работе.
В атрибут displayName нам надо будет добавить то, что будет выводиться при просмотре ACL штатными средствами – т.е. “человеческое” название этого права.
Чтобы клиентский софт мог запросить у системы состояние данного права у конкретного объекта, надо задать атрибут rightsGUID. Требования простые – не совпадать с другими, поэтому я взял один из GUID’ов от других прав и поправил, чтобы не было претензий со стороны Минздрава:
Осталось только сказать, что это всё может работать – для этого в атрибут validAccesses запишем 256 – это включит 9й бит, и мы наконец-то увидим плоды нашей работы.
Сделали? Смотрим.
Теперь сотрудника Василия никто не упрекнёт, что он не может бухать на работе – может. Ну, а какое применение такой возможности он найдёт, да и Вы – тут уж сами думайте.
Однажды к одному CIO пришёл руководитель IT-департамента.
– Никто не любит сотрудников техподдержки так, как люблю их я. Их, этих воинов переднего края, этот штрафбат духа и знаний, этот…
– Ты по делу, наверное?
– Да, есть косяк. Состоит он в том, что людям неудобно понимать, когда доменная машина “увидела сетку”, а когда – нет. Просветлённые понимают, а у остальных столько духовности, что их предположения “видит комп доменную сетку или вроде нет” заставляют меня потерять веру в человечество. А ведь без веры нельзя жить.
– Понимаю. Устроит ли ситуация, когда факт нахождения в доменной сети будет идентифироваться путём отображения на сетевом интерфейсе логотипа фирмы с соответствующей подписью?
– Вполне.
В момент, когда Windows подключается к новой сети, пользователю предлагается выбор – домашняя ли это сеть, рабочая или “внешняя”-гостевая. В зависимости от того, что выберет пользователь, будут установлены настройки общего доступа, а также ряд других параметров. Во что ткнёт пользователь – неизвестно. Отсюда “Подключение по локальной сети 5″ с картинкой домика, а впоследствии – вагон разных сетей с жуткими именами и невнятными задачами – поди вспомни, откуда это подключение номер пять взялось – то ли когда в Макдоналдсе сидел, то ли когда дома роутер купил и в него переподключился. Для сотрудников техподдержки же крайне желательно, чтобы можно было задать вопрос “В какой Вы сейчас сети?” и получить относительно вменяемый ответ.
Для начала мы возьмём откуда-нибудь иконку с логотипом нашей организации. Ей хватит размера 64×64 пикселя. Я буду использовать этот файл для примера:
Теперь можно открыть объект групповой политики, действующий на доменные компьютеры, на которых нужно изменить отображение и логику определения сетей, и зайти там в следующий раздел:
Computer Configuration / Policies / Windows Settings / Security Settings / Network List Manager Policies
Так как я редактирую политики с рабочей станции, которая уже находится в домене (что, в общем-то, логично), то картинка будет выглядеть примерно так:
Три строчки из четырёх – это Unidentified Networks, Identifying Networks, All Networks – стандартные, а четвёртая – мой тестовый домен domain7.local. Для начала, поменяем настройки для стандартных объектов.
Здесь будет две настройки – Location Type и User Permissions. Первая будет обозначать то, как будет трактоваться местоположение для неизвестных сетей – как частная сеть (Private), общедоступная (Public) либо отдаваться на откуп локальному пользователю (т.е. у него при подключении новой сети будет то самое окно с выбором из 3х вариантов типов сетей – домашней, предприятия или общедоступной). Мы выставим их так – Location Type сделаем Public, а пользователю запретим менять тип Unidentified сети (User cannot change location). Это отсечёт ситуации, когда пользователь неверно определит тип сети (допустим, в кафе поставит сеть как домашнюю), что ощутимо снизит уровень безопасности (например, появится возможность обнаружения других устройств, да и возможности в плане общего доступа к ресурсам, которые никак не нужны в сети кафе).
Это те сети, которые находятся “в процессе” идентификации. Визуально это рисуется анимацией на иконке подключения, занимает обычно некоторое количество секунд. Настройка здесь одна – “как трактовать тип сети, находящейся в этой фазе”. Почему она важна? Потому что если пользователь хоть раз выбирал вручную тип новой сети, добрая операционная система дала ему возможность выставить галку вида “… И все дальнейшие новые сети считать такими же, как ты выбрал сейчас”. Это уязвимость, потому что ситуация может быть простой – человек дома поставил новый роутер, ОС повторно “нашла” локальную сеть, предложила выбрать – человек выбрал, что сеть доверенная, домашняя, и нажал галку “больше меня не спрашивай, остальные неизвестные сети такие же”. В результате, когда он пойдёт в кафе, где есть Wifi, у него сеть, будучи в процессе Identifying, будет трактоваться как домашняя, давая излишние возможности его соседям по IP-диапазону. Мы выставим этот параметр как Public – т.е. любая сеть, которая “в процессе определения”, будет по определению общедоступной, внешней, и к ней будут применяться максимальные ограничения по совместной работе и доступу к соседским ресурсам.
Это общие настройки для всех сетей. Логика их действия простая – если что-то не зафиксировано администратором, то это можно изменять пользователю. Так как речь идёт о рабочей системе, то такие настройки неправильные. Мы явно определим сеть предприятия, если надо – так же, через политики, раздадим настройки беспроводных сетей. Пользователю не нужно ничего менять. Соответственно, мы выставляем следующие настройки:
Теперь пришла очередь настроить отображение и настройки нашей, доменной сети.
Их будет четыре, и они будут распределены по двум вкладкам. Можно будет задать картинку, имя сети, и права пользователей на смену картинки и имени. Права мы, конечно, отнимем, а название сети и картинку сменим:
Важный момент – картинку мы будем хранить в SYSVOL’е и задавать её местоположение тоже через UNC. Поэтому наши доменные рабочие станции будут забирать картинку с ближайшего SYSVOL, реплицироваться она будет автоматически, и её не надо будет никуда копировать вручную:
Задача решена – теперь определить тип сети визуально что сотрудникам, что IT-товарищам из техподдержки стало проще.
Повысилась безопасность – пользователь не может объявить все сети домашними и таким образом ослабить защиту своего хоста. Мелочь, никакого шаманства и кодинга, а из таких мелочей состоит то, что с точки зрения ряда восточных практик отличает работу от искусства. ActiveDirectory-до лучше, чем ActiveDirectory-дзюцу.
Возможностей, которые предоставляет Active Directory – масса. Главное – знания.
Удач.
WBR, Ruslan V. Karmanov
в AD из оснастки Active Directory Users and Computers (известной также как dsa.msc) в расширенном режиме на вкладке Aеtribute Editor скипировать значение атрибута objectSid не получится в привычной форме.
Обойти это можно используя командную строчку
dsquery * -filter "&(objectcategory=user)(samaccountname=ivan.ivanov)" -attr objectsid
в ответ получим:
objectsid S-1-5-21-1994511428-2624263116-1417297096-1189
немного подправив запрос можно получить любой аттрибут и не только учетных записей пользователей
Еще есть способ получить SID и GUID в буфер обмена из оснастки Active Directory Administrative Center
sipusers = ldap,”dc=myDomain,dc=myDomainExt”,sip
sippeers = ldap,”dc=myDomain,dc=myDomainExt”,sip
extensions = ldap,”dc=myDomain,dc=myDomainExt”,extensions
sip.conf = ldap,”dc=myDomain,dc=myDomainExt”,config
Call files that have the time of the last modification in the future are ignored by Asterisk. This makes it possible to modify the time of a call file to the wanted time, move to the outgoing directory, and Asterisk will attempt to create the call at that time.
задание шаблона
[sets](!) type=friend context=phones host=dynamic secret=password allow=ulaw allow=alaw allow=speex
и его использование[111](sets)secret=password
All lines that starts with semi-colon “;” is treated as comments and is not parsed.
The “;” is a marker for a multi-line comment. Everything after that marker will be treated as a comment until the end-marker “;” is found. Parsing begins directly after the end-marker.
;This is a commentlabel = value;-- This isa comment -;;- Comment --; exten=>1000,1,dial(SIP/lisa)
[section]label = value[section](+)label2 = value2
In this case, the plus sign indicates that the second section (with the same name) is an addition to the first section. The second section can be in another file (by using the #include statement). If the section name referred to before the plus is missing, the configuration will fail to load.
Using templates (or other configuration sections)
[section](name[,name])label = value
The name within the parenthesis refers to other sections, either templates or standard sections. The referred sections are included before the configuration engine parses the local settings within the section as though their entire contents (and anything they were previously based upon) were included in the new section. For example consider the following:[foo]disallow=allallow=ulawallow=alaw[bar]allow=gsmallow=g729permit=192.168.2.1[baz](foo,bar)type=friendpermit=192.168.3.1context=incoming host=bnm
The [baz] section will be processed as though it had been written in the following way:[baz]disallow=allallow=ulawallow=alawallow=gsmallow=g729permit=192.168.2.1type=friendpermit=192.168.3.1context=incoming host=bnm
It should also be noted that there are no guaranteed overriding semantics, meaning that if you define something in one template, you should not expect to be able to override it by defining it again in another template.начиная с версии 1.6.2
Среди других улучшений – новый синтаксис, призванный упростить процесс написания скриптов диалплана. Расширение позволяет программистам пропускать добавочный номер или идентификатор паттерна в многострочном скрипте, используя ключевое слово “same”, как в следующем примере:
exten => _22XX.,1,NoOp(Incoming Call)
same => n,Answer()
same => n,Wait(1)
same => n,Playback(tt-weasels)
same => n,Hangup()
Серверы глобальных каталогов
Каждый системный администратор, который работает с доменными службами Active Directory, по крайней мере, один раз за время своей работы сталкивается с глобальными каталогами, но далеко не каждый системный администратор задумывается, что же такое глобальный каталог и для чего он предназначен. Глобальный каталог (Global Catalog или GC) представляет собой репозиторий распределенных данных, который хранит информацию о каждом объекте, а также облегчает поиск в лесу Active Directory. Глобальный каталог хранится на контроллерах домена, которые назначены в качестве серверов глобального каталога и распространяется посредством репликации с множеством равноправных участников. Первый контроллер домена, установленный в лесе, автоматически конфигурируется как сервер глобального каталога. Вы можете переносить возможности глобального каталога на другие контроллеры домена, а также изменять расположение глобального каталога, устанавливаемое по умолчанию, указывая другой контроллер. Глобальный каталог позволяет пользователям и приложениям находить объекты в любом домене текущего леса посредством поиска атрибутов, включенных в глобальный каталог, которые идентифицируются в схеме в качестве частного набора атрибутов (Partial Attribute Set, PAT). Допустим, у вас есть лес с тремя доменами, причем каждый домен содержит по два контроллера домена. Все шесть контроллеров домена поддерживают репликацию схемы и конфигурации леса. Соответственно, контроллеры в домене А содержат реплики контекста именования домена А, контроллеры в домене B – реплики именования домена B, а контроллеры домена C, соответственно, реплики домена C. Рассмотрим следующую ситуацию: пользователь домена C хочет найти пользователя домена А. В этом случае, когда пользователь в домене C выполняет поиск объекта домена А, результаты запроса предоставляет глобальный каталог. Но если объект содержит специфический атрибут, который по умолчанию не включен в глобальный каталог, то вы можете добавить такой атрибут при помощи оснастки «Схема Active Directory». Таким образом, если бы не было сервера глобального каталога, то контроллер домена, принимающий поисковые запросы объектов в других доменах, пересылал бы поисковые запросы на контроллер в домене с искомым объектом. В этой статье вы узнаете о самой концепции серверов глобального каталога, об их архитектуре, протоколах, процессах, физической структуре, а также о многих нюансах, связанных с данной технологией.
Взаимодействие глобального каталога с другими серверными объектами
Серверы глобального каталога участвуют в следующих процессах и взаимодействуют со службами:
Установка Active Directory. Глобальный каталог автоматически конфигурируется на первом контроллере домена, который устанавливается в лесу;
Репликация Active Directory. В репликации Active Directory каждая реплика на контроллере домена согласована с репликами этого раздела, управляемого другими контроллерами доменов. Глобальный каталог построен на репликации Active Directory. После того как вы создали лес, на контроллере домена, который используется в качестве сервера глобального каталога, автоматически реплицируется частный набор атрибутов на контроллеры домена всех доменов в лесу, отличных от локального. Для оптимизации репликации один из контроллеров домена обычно назначается в качестве сервера-плацдарма, который отвечает за всю входящую и исходящую репликацию раздела для сайта. Например, для обновлений глобального каталога, при репликации Active Directory выбираются серверы глобального каталога в качестве серверов-плацдармов и все изменения, внесенные в центре данных в глобальный каталог, будут реплицироваться на все контроллеры домена в данном сайте. Изменения будут поступать на сервер-плацдарм, а затем реплицироваться на серверы-плацдармы в филиалах, которые реплицируют изменения на контроллеры домена в своих сайтах.
Система доменных имен (DNS). Как и доменные службы Active Directory, серверы глобального каталога не могут функционировать без DNS. Аналогично тому как службы DNS предоставляют данные, необходимые компьютерам в сети для локализации контроллеров домена Active Directory, так и для предоставления IP-адресов серверов глобального каталога клиенты сервера глобального каталога также полностью зависят от DNS.
Служба «Сетевой вход в систему». При попытке пользователя выполнить вход в систему, клиентский компьютер отправляет вызов удаленной процедуры локальной службе «Сетевой вход в систему», инициируя сеанс входа. В вызове удаленной процедуры клиент пересылает данной службе такую информацию как имя компьютера, имя домена, а также имя сайта. Объявление глобального каталога DNS зависит от службы «Сетевой вход в систему». При завершении репликации глобального каталога или при запуске сервера глобального каталога, служба «Сетевой вход в систему» публикует записи расположения службы (SRV) в DNS, которая объявляет контроллер домена как сервер глобального каталога.
Взаимодействие серверов глобального каталога с серверными объектами выглядит следующим образом:
.jpg)
Рис. 1. Пример взаимодействия серверов глобального каталога с доменными службами Active Directory
После создания нового контролера домена DC02, системный администратор определяет его как сервер глобального каталога и реплицирует частичный набор атрибутов из DC01. В домене А, DC01 реплицирует изменения для DC02 домена А, а DC02 – реплицирует обновления данных для DC01 домена В.
На шаге «А» клиентский компьютер КлиентХ отправляет запрос в глобальный каталог, который перенаправляет запрос DNS-серверу для поиска ближайшего сервера глобального каталога «В», после чего клиент связывается с сервером глобального каталога для выполнения своего запроса «С».
Клиентский компьютер КлиентY выполняет вход в домен «1». Он запрашивает DNS-сервер на расположение ближайшего контроллера домена «2». После этого он связывается с ближайшим контроллером домена DC03 и пробует пройти проверку подлинности «3». DC03 запрашивает DNS-сервер на расположение ближайшего сервера глобального каталога «4». Затем данный контроллер домена связывается с сервером глобального каталога DC02 для извлечения членства пользователя в универсальных группах.
Развитие и сценарии использования серверов глобального каталога
Как уже было сказано ранее, одной из важнейших ролей серверов глобального каталога, является эффективное выполнение поиска объектов в доменах Active Directory. Причем, глобальным каталогом выступает контроллер домена, на котором хранится полная копия всех объектов в каталоге для собственного домена и частичная, предназначенная только для чтения копий всех объектов во всех других доменах леса. Всем известно, что для управления доменными службами и идентификацией в Active Directory используется специальное хранилище, расположенное в базе данных Ntds.dit, где содержатся разделы каталога, также называемые контекстами именования. Кроме таких контекстов именования, как «Конфигурация» и «Схема», в лесах с функциональным уровнем Windows Server 2000, Windows Server 2003, Windows Server 2008, а также Windows Server 2008 R2, контроллеры домена поддерживают полную реплику нескольких контекстов именования каталога одного домена. Конфигурация реплицируется на каждый контроллер домена в лесу, также как и схема. Причем, контекст именования для домена реплицируется на все контроллеры домена, но не реплицируется на контроллеры домена в других доменах. В свою очередь, при помощи глобального каталога пользователи могут выполнять поиск данных каталога во всех доменах леса независимо от места хранения данных. Контроллеры домена, которые выполняют роль глобального каталога, также называются серверами глобального каталога, которые, соответственно, отвечают на запросы глобального каталога. Для оптимизации эффективности, глобальные каталоги содержат лишь поднабор атрибутов, которые используются для поиска среди доменов. По этой причине, глобальный каталог также называют частичным набором атрибутов (Partial Attribute Set, PAS), которые определяются корпорацией Microsoft. Атрибуты, из которых состоит глобальный каталог, называются «частичными», так как они включают в себя ограниченный набор атрибутов, а именно атрибуты, которые востребованы схемой и атрибуты, которые чаще всего используются в пользовательских операциях поиска. Эти атрибуты отмечены для включения в частичный набор атрибутов как часть определения их схемы. Хранение самых атрибутов, поиск которых выполняется чаще всего, для всех доменных объектов в глобальном каталоге позволяет пользователям более эффективно использовать возможность поиска без снижения сетевой производительности вследствие отсутствия пересылок на контроллеры доменов и без необходимости хранения на сервере глобального каталога большого объема ненужных данных. Тем не менее, для оптимизации поиска вы можете использовать схему, в которой можно добавлять, изменять или удалять атрибуты, которые хранятся в глобальном каталоге. Стоит обратить внимание на то, что любое изменение частичного набора атрибута приводит к полной синхронизации глобального каталога.
Сервер глобального каталога обычно используется в ситуациях, которые описаны в следующих подразделах.
Поиск объектов
Поскольку контроллер домена, работающий как сервер глобального каталога, содержит объекты всех доменов в лесу, глобальный каталог предоставляет пользователям и приложениям возможность выполнять поиск данных каталога во всех доменах леса независимо от места хранения данных. Если ваш лес состоит из одного домена, то все контроллеры домена имеют полный доступ для записи экземпляров каждого объекта в домене леса. Когда пользователь выполняет поиск какого-либо участника системы безопасности, указав в меню «Пуск» в запросе параметр «Весь каталог», то поиск выполняется непосредственно в глобальном каталоге.
Для доступа к объектам Active Directory использует протокол облегченного доступа к каталогам (Lightweight Directory Access Protocol, LDAP). Запросы поиска LDAP могут быть отправлены и получены службой каталогов Active Directory через порт 389 (порт LDAP по умолчанию) и через порт 3268 (порт глобального каталога). Трафик LDAP, который использует протокол проверки подлинности Secure Sockets Layer (SSL) обеспечивает доступ к портам 686 и 3269. Соответственно, поведение поиска, которое применяется к портам 389 и 3268 также применяется к соответствующим запросам LDAP через порты 686 и 3269. Когда запрос поиска отправляется на порт 389, поиск осуществляется в разделе каталога одного домена. Если объект не находится в данном домене, разделе каталога схемы или конфигурации, контроллер домена пересылает запрос контроллеру домена в домене, который указан в различающемся имени объекта. Когда запрос поиска отправляется на порт 3268, то опрашиваются все разделы каталога в лесу, то есть поиск обрабатывается сервером глобального каталога. Стоит обратить внимание на то, что только серверы глобального каталога могут получать запросы LDAP через порт 3268.
После того как пользователь вводит свой запрос, данный запрос перенаправляется на порт 3268, и отправляется для разрешения на сервер глобального каталога. В свою очередь, если по каким-либо причинам в вашем домене Active Directory нет сервера глобального каталога, ваши пользователи или приложения не смогут выполнять поиск по лесу. Также стоит отметить, что все реплики, которые реплицируются в глобальный каталог, включают все права доступа для каждого объекта и атрибута. То есть, если вы ищете объект, доступ к которому для вас запрещен, вы его не увидите в списке результатов поиска. Соответственно, пользователи смогут найти только те объекты, для которых им предоставлен доступ.
Подтверждение ссылок на объекты в лесу
Контроллеры домена используют глобальный каталог для подтверждения ссылок на объекты других доменов в лесу. То есть, если контроллер домена содержит объект с атрибутом, который содержит ссылку на объект в другом домене, то контроллер домена проверяет ссылку, устанавливая связь с сервером глобального каталога.
Проверка подлинности имени пользователя
В дополнение к роли поставщика поиска в мультидоменном лесу, глобальный каталог играет роль источника идентификации во время входа пользователя в домен. Сервер глобального каталога разрешает имя пользователя в том случае, если контроллер домена, проверяющий подлинность, не имеет сведений об учетной записи этого пользователя. Другими словами, если учетная запись пользователя находится в одном домене, но сам пользователь входит в систему с компьютера, расположенного в другом домене, контроллер домена не может найти учетную запись пользователя и для того, чтобы завершить процесс входа в систему, он должен связаться с сервером глобального каталога. Во время проверки подлинности в мультидоменном лесах, глобальный каталог руководствуется одним из двух следующих требований:
Процесс взаимодействия входа пользователя и глобального каталога выглядит следующим образом:
.jpg)
Рис. 2. Процесс взаимодействия входа пользователя и глобального каталога
Сведения о членстве в универсальных группах в среде с несколькими доменами
Как уже было сказано, во время входа пользователя в домен, пользователь должен пройти проверку подлинности. В процессе проверки, контроллер домена проверяет подлинность пользователя, после чего пользователь получает данные авторизации для доступа к ресурсам. Для предоставления данных для авторизации пользователя, контроллер домена извлекает идентификаторы безопасности (SID) для всех групп безопасности, членом которых является пользователь и добавляет эти идентификаторы SID в маркер доступа пользователя. В свою очередь, контроллер домена всегда может определить членство в локальной группе или глобальной группе домена для любого пользователя из этого же домена, но членства в этих группах не реплицируются в глобальный каталог, так как членами данных групп не могут быть пользователи из разных доменов. Но в универсальных группах могут быть члены из других доменов. Не стоит забывать, несмотря на тот факт, что локальные доменные группы также могут содержать членов из других доменов, они могут быть добавлены для управления только в том домене, где были созданы. А глобальные группы, несмотря на то, что могут быть добавлены для управления доступом в любом домене, могут содержать только учетные записи своего домена.
Универсальная группа также является группой безопасности, которая позволяет управлять ресурсами, распределенными в нескольких доменах. Во время выполнения интерактивного входа, контроллер домена извлекает идентификаторы SIDпользовательского компьютера. По этой причине атрибут универсальных групп member, который содержит список членов в группе, реплицируется в глобальный каталог. Например, пользователь в лесу с несколькими доменами подключается к домену, в котором разрешены универсальные группы. В этом случае контроллер домена, для получения членства в универсальных группах, должен связаться с сервером глобального каталога. Если пользователь ни разу не подключался к домену и сервер глобального каталога недоступен, то он может войти только локально в систему. Но если сервер глобального каталога недоступен при входе пользователя в домен, в котором доступны универсальные группы и пользователь уже подключался к данному домену, то клиентский компьютер пользователя может использовать для входа кэшированные учетные данные.
Кэширование членства в универсальных группах
В универсальные группы включаются пользователи и группы, которые расположены в нескольких доменах в лесу. Членство в универсальных группах реплицируется в глобальном каталоге. Универсальная группа применяется для того, чтобы запретить пользователю доступ к ресурсам, а если глобальный каталог будет недоступен, то операционная система не позволит пользователю пройти проверку подлинности в домене. В небольших филиалах доступная пропускная способность сети и ограничения оборудования сервера приводят к нецелесообразности использования глобального каталога. Разумеется, пользователь сможет использовать кэшированные учетные данные, но он не сможет получить доступ к необходимым ресурсам. Для снижения необходимости подключения к серверу глобального каталога, находящегося в другом сайте, на контроллерах домена, работающих под управлением Windows Server 2003, Windows Server 2008 или Windows Server 2008 R2, в сайте, который не содержит сервер глобального каталога, можно использовать кэширование членства в универсальных группах. Эта функциональная возможности появилась в Windows Server 2003 и она исключает для контроллера домена в мультидоменном лесу необходимость связаться с сервером глобального каталога во время входа пользователей в домены, где доступны универсальные группы, тем самым снижая трафик по глобальной сети. Если функция кэширования членства в универсальных группах включена, то при первой попытке пользователя подключения к домену, в котором доступны универсальные группы, сведения сохраняются локально. Контроллер домена получает сведения об участии пользователя в универсальных группах из глобального каталога и после этого данные сведения неограниченно кэшируются на контроллере домена данного сайта и периодически обновляются. При последующей попытке входа пользователя в данный домен, контроллер домена, для обработки входа пользователей, вместо подключения к серверу глобального каталога использует членства в кэше.
Поэтому, на контроллерах домена с ненадежной связью с сервером глобального каталога рекомендуется включать и настраивать кэширование членства в универсальных группах. Одновременно, сведения об участии пользователей в универсальных группах, могут обновляться до 500 членств каждые 8 часов. После первого входа в систему, кэш пользователя периодически обновляется в течение 180 дней.
По умолчанию, атрибуты для объектов пользователей и компьютеров не заполняются. На следующей иллюстрации вы увидите пример построения списков идентификаторов безопасности контроллером домена для кэширования:
.jpg)
Рис. 3. Пример построения списков идентификаторов безопасности контроллером домена для кэширования
Поиск адресной книги Exchange.
Службы каталогов службы Exchange для почтовых серверов Microsoft Exchange Server тесно интегрированы с доменными службами Active Directory. Когда пользователи в своем почтовом клиенте хотят найти человека в пределах своей организации, чаще всего они выполняют поиск через глобальную адресную книгу (GAL), которая включает совокупность всех получателей почты в организации, включая пользователей электронной почты, контакты и группы. Такими получателями могут быть обычные пользователи, контакты, списки рассылки, группы безопасности и папки. GAL автоматически заполняется специально отведенной для этого службой на почтовом сервере, и пользователи могут создавать списки настраиваемых адресов. Для поиска серверов глобального каталога, почтовые сервера Exchange используют Active Directory и DNS. Когда пользователь пробует открыть в Microsoft Outlook адресную книгу, или когда пользователь пишет сообщение и вводит имя или адрес в поле «To», клиент Outlook использует сервер глобального каталога, указанный сервером Exchange.
Архитектура глобального каталога
Архитектура сервера глобального каталога отличается от архитектуры сервера, у которого нет роли глобального каталога использованием нестандартного порта LDAP 3268, который направляет запросы непосредственно в глобальный каталог. Запросы, которые идут на порт 3268, формируются также как и любые LDAP-запросы, но доменные службы Active Directory изменяют поведение поиска в зависимости от используемого порта. То есть, запросы на порт 3268 направляются на разделы каталога глобального каталога, включая разделы каталога только для чтения, для которых данный сервер является уполномоченным. Запросы на порт 389 направляются на домен с возможностью записи, а также на разделы каталога конфигурации, приложения и схемы реплик, которые расположены на сервере глобального каталога в качестве контроллера домена. Кроме того, во время связи с серверами глобального каталога для получения членства в универсальных группах при входе пользователя в систему, контроллеры домена используют проприетарный интерфейс репликации.
Поиск клиентов включает адресную книгу клиентов Microsoft Exchange Server, которые для поиска адресов электронной почты в глобальном каталоге используют поставщик клиента MAPI Emsabp32.dll. На стороне клиента поставщик MAPI связывается с сервером через проприетарный RPC интерфейс Name Service Provider Interface (NSPI). Пользователи с операционными системами предшествующими Windows 2000 для взаимодействия с диспетчером учетных записей безопасности (Security Accounts Manager, SAM) на эмуляторе основного контроллера домена (PDC) используют сетевой API.
Соответственно, к основным компонентам глобального каталога можно отнести:
На следующей иллюстрации изображена архитектура глобального каталога:
.jpg)
Рис. 4. Архитектура глобального каталога
Протоколы глобального каталога
Протоколы и интерфейсы на всех контроллерах домена одинаковые и для серверов глобального каталога нет специфических протоколов. В данном случае нас интересуют четыре интерфейса и три протокола. Значимость глобального каталога заключается в том, что контроллеры домена используют собственные протоколы репликации RPC не только для репликации, а еще и для связи с сервером глобального каталога при извлечении сведения о членстве в универсальных группах и при обновлении кэша членства в группе, когда включена функция «Кэширование членства в универсальных группах». Для всех требований глобального каталога используются следующие протоколы:
На следующей иллюстрации изображены протоколы глобального каталога:
.jpg)
Рис. 5. Интерфейсы и протоколы глобального каталога
Физическая структура глобального каталога
Как роль контроллера домена, глобальный каталог хранит один доступный для записи раздел каталога домена, в котором расположены объекты со всеми атрибутами. Также сервер глобального каталога хранит частичный набор атрибутов (PAS) с правом на чтение всех объектов остальных доменов в мультидоменном лесу. Объектами схемы, определяющими атрибуты, являются объекты attributeSchema, которые включают атрибут isMemberOfPartialAttributeSet. Если значение этого атрибута равно «true», то атрибут реплицируется в глобальный каталог. Топология репликации глобального каталога формируется автоматически при помощи проверки согласованности знаний (Knowledge Consistency Checker, KCC) – встроенный процесс, который реализует топологию репликации, гарантирующую доставку содержимого каждого раздела каталога на каждый сервер глобального каталога.
Атрибуты, которые реплицируются в глобальный каталог по умолчанию, включаются в базовый набор, определенный корпорацией Microsoft как атрибуты, которые чаще всего используются при поиске. При необходимости, для того чтобы указать дополнительные атрибуты, вы можете воспользоваться оснасткой консоли управления (MMC) «Схема Active Directory». Чтобы назначить объект attributeSchema членом PAS, в данной оснастке вам нужно установить флажок «Реплицировать этот атрибут в глобальный каталог», который задает атрибуту isMemberOfPartialAttributeSet значение «true».
Физическое представление данных глобального каталога ничем не отличается от контроллера домена, то есть, в глобальном каталоге база данных NTDS.dit хранит атрибуты объекта в одном файле. А на контроллере домена, который не является сервером глобального каталога, файл Ntds.dit содержит полную записываемую реплику каждого объекта в разделе каталога одного домена для своего домена, а также доступные для записи разделы каталога конфигурации и схемы.
Например, рассмотрим достаточно типичный сценарий. На сервере глобального каталога расположена полная реплика своего домена, а также частичная реплика только для чтения всех остальных доменов леса. На данном сервере глобального каталога все разделы каталога на сервере глобального каталога хранятся в файле базы данных каталога (Ntds.dit). Соответственно, в данном случае нет раздельного хранилища атрибутов глобального каталога.
К компонентам физической структуры глобального каталога можно отнести:
На следующей иллюстрации изображена физическая структура глобального каталога:
.jpg)
Рис. 6. Физическая структура глобального каталога
Заключение
В этой статье вы познакомились с серверами глобального каталога. Было рассказано о самой концепции серверов глобального каталога, а также о взаимодействии серверов глобального каталога с другими серверными объектами корпорации Microsoft. Рассмотрены ситуации, в которых используются сервера глобальных каталогов, а именно: поиск объектов, подтверждение ссылок на объекты в лесу, проверка подлинности, сведения о членстве в универсальных группах в среде с несколькими доменами, кэширование членства в универсальных группах, а также поиск адресной книги Microsoft Exchange. Помимо этого, вкратце была рассмотрена архитектура, физическая структура, а также протоколы серверов глобального каталога.
Об авторе:
Дмитрий Буланов отвечает на вопросы участников конференции OSZone.net в форумах операционных систем Microsoft. Его статьи на сайте OSZone.net можно найти по этой ссылке. С декабря 2008 года Дмитрий ведет свой блог, посвященный клиентским и серверным операционным системам Microsoft.
В апреле 2010 года был награжден премией Microsoft Most Valuable Professional (MVP), присуждаемой за вклад в развитие технических сообществ. Также в 2010 году он получил статус MC ITP (Microsoft Certified IT Professional), сдав 3 экзамена Microsoft, после чего старается регулярно сертифицироваться по разным технологиям.
С 1 января 2011 года он ведет свой микроблог в Твиттере.
Вы можете задать Дмитрию любой полностью анонимный вопрос здесь.
Как происходит типичный процесс обеспечения нового сотрудника рабочей станцией:
Какие типовые сценарии обычно выполняются при увольнении сотрудника:
Таким образом, при солидном парке ПК и ненулевой текучести кадров, с течением времени в Active Directory накапливается масса записей о рабочих станциях, в точном статусе которых уже не уверен никто.
А выход на самом деле достаточно прост и изящен. Учетная запись рабочей станции с точки зрения каталога AD несильно отличается от учетной записи пользователя. То есть, в свойствах записи есть замечательное поле штампа времени последнего входа в домен. Более того, учетная запись компьютера для аутентификации в домене тоже использует пароль, который обязан автоматически меняться в соответствии с установленными политиками безопасности (по умолчанию, период равен 60 дням).
В базовом же комплекте средств администрирования AD уже есть замечательные консольные утилиты, как нельзя лучше подходящие для наших целей:
Предположим, мы администрируем домен libertine.su. Итак, выполнив в командной строке простую команду
650e756cc528f1_
мы получим список из рабочих станций домена, которые не обновляли свой пароль в течении последнего 61 дня. Точнее, сказать, список из первых 100 записей, подпадающих под данное условие. Если же количество рабочих станций может превышать это значение, плюс мы хотим вывести список только для компьютеров из OU marketing, то нет ничего проще:
650e756cc528f2_
Мы также можем вывести список из компьютеров, которые не заходили в домен в течении заданного числа недель. Да, именно недель и об этом необходимо помнить, во избежании непонимания происходящего Description: ;). Как и о том, что, увы, команда работает только, если домен находится в 2003 native режиме.
Итак, выясним, какие компьютеры из OU Sales не регистрировались в домене за последние 7 недель:
650e756cc528f3_
Ок, мы выяснили. А что же с этим делать дальше? Логика подсказывает, что можно просто удалить. В принципе, без проблем. Но можно их сначала сделать неактивными. Для этого мы используем соответствующие утилиты командной строки. А найденные компьютеры из dsquery передадим туда при помощи механизма туннелирования команд (символ конвейера в командной строке).
Следующей командой мы выключим учетные записи найденных на предыдущем этапе компьютеров:
650e756cc528f4_
Что, у нас не получилось? Все правильно! Параметры в виде полных путей к найденным компьютерам, во вторую часть необходимо передавать по одной, а не сразу весь список.
Можно, конечно, написать глупый cmd файл, примерно такого содержания:
650e756cc528f5_
Таким образом мы в бесконечном цикле последовательно изменим атрибут каждой из находимых рабочих станций.
Но это как-то бесконечно некрасиво. Поэтому мы лучше напишем в этом файле следующую конструкцию:
650e756cc528f6_
Первая и третья строка на вкус. Лично мне такое поведение нравится больше.
Теперь предлагаю переместить все выключенные записи компьютеров домена в одну единую OU под именем disabled old computers. Создаем эту OU при помощи командной строки или оснастки Active Directory Users and Computers.
А теперь создаем еще один cmd файл:
650e756cc528f7_
Попутно можно задуматься о том, сколь бесконечным будет выглядеть результат, если в указанной OU уже содержатся выключенные записи рабочих станций домена. Хотя, разумеется, настоящие индейцы могут попробовать создать специального пользователя, который, имея полные права на модификацию и запись, не будет иметь прав на чтение одной конкретной OU в домене. И запускать в дальнейшем все скрипты от имени данного пользователя.
Да, поскольку я обещал упомянуть утилиту dsrm в контексте управления записями рабочих станций, я ее упоминаю: если создать следующий cmd файл:
650e756cc528f8_
а затем его еще и запустить, то у нас будет отличный повод поменять работу. А если рабочих станций было много, а резервное копирование настроено халатно, то вполне возможно, что нам придется поменять еще и профессию.
Добрый день, друзья! Совсем недавно обновилась версия Windows Server до Release Candidate. Литературы и документации по новому продукту не так много, но совсем недавно появилась одна из первых книг – «Введение в Windows Server 2012».
Основные вопросы, которые рассматриваются в ней:
Книга доступна только на английском языке и в следующих форматах:
PDF – Introducing Windows Server 2012 PDF ebook
EPUB – Introducing Windows Server 2012 EPUB ebook
MOBI – Introducing Windows Server 2012 MOBI ebook