В статье рассмотрены варианты удаленного администрирования серверов как изнутри корпоративной сети, так и удаленно, например, из дома.
Apple iPod. Версия 1871 года...
Занимался на днях с сыном. Листали альбом репродукций картин художника Василия Перова.
На картине "Рыболов" 1871 года взгляд выхватил до боли знакомый предмет.
Настройка DNS для поддержки домена .РФ
Массовый ажиотаж, связанный с захватом и регистрацией "хороших" доменных имен в зоне .РФ, постепенно проходит. На первое место выходит новая проблема: что с новыми доменами делать дальше? Ответ один: настраивать DNS и веб-сайт для поддержки вашей новой зоны.
Для начала настоятельно рекомендую прочитать статью "Как работает домен .РФ".
Что такое Access-based Enumeration (ABE)
Мне часто приходится слышать вполне логичный вопрос от своих слушателей:
"Почему Windows показывает пользователям ВСЕ файлы из общих папок, несмотря на то, что к большей их части у пользователя все равно нет доступа?"
Ответ на вопрос и способ решения проблемы описаны в этой статье. В процессе написания и тестирования открыл для себя много интересного.
Миграция сервера печати на новую систему
Вопрос: "Сколько займет миграция сервера печати с двадцатью очередями печати и двадцатью сетевыми принтерами?"
Правильный ответ: "Полчаса (с учетом кофе-брейка)".
Удаленное выключение компьютеров на ночь
Проблема
Требуется обеспечить принудительное выключение определенных клиентских компьютеров в ночное время. Все компьютеры являются членами домена Active Directory.
Теория
Как удаленно выключить компьютер?
Вариантов удаленного выключения существует довольно много:
- через графическую консоль Управление компьютером (Computer Manager), подключенную к удаленному компьютеру;
- через штатную утилиту shutdown.exe;
- с помощью сценария PowerShell;
- и т.п.
На мой взгляд, для автоматизации задачи массового принудительного удаленного выключения компьютеров лучше всего подходит утилита PsShutdown.exe, являющаяся частью пакета PsTools.
Вариант команды PsShutdown может быть таким:
| C:\>PsShutdown \\XP01 -s -f -t 300 –c –n 10 -e p:0:0 –m "Night shutdown. Please contact Servicedesk if you have any questions. Servicedesk phone: 123-45-67." |
Описание используемых ключей:
\\XP01 – имя удаленного компьютера, можно заменить файлом со списком компьютеров (например, @C:\Scripts\Computers.txt)
-s – выключение компьютера (если все компьютеры поддерживают режим гибернации, можно заменить ключом –h);
-f – принудительное закрытие всех открытых приложений;
-t 300 – указание времени в секундах, в течение которого выводится окно уведомления о выключении компьютера;
-c – опция, позволяющая пользователю удаленного компьютера отменить выключение (пользователю будет выводиться кнопка Cancel);
-n 10 – максимальное время в секундах, отводимое на подключение к удаленному компьютеру;
-e p0:0 – указание, что выключение является плановым;
-m “Night shutdown. Please contact Service Desk if you have any questions. Service Desk phone: 123-45-67.” – текст уведомления; замените на свой собственный.
Как сделать выборку компьютеров?
Можно, конечно, вручную создать текстовый файл, в котором перечислить все компьютеры, которые следует выключать. А можно автоматизировать создание актуальной выборки на основе данных из Active Directory.
Проще всего сделать выборку с помощью утилиты dsquery.exe, присутствующей на серверах или в составе пакета RSAT.
Ниже приведен вариант выборки, создающей список всех компьютеров из контейнера Desktops в домене corp.gorbunov.pro:
| C:>DSQUERY * "OU=Desktops,DC=corp,DC=gorbunov,DC=pro" -filter (objectCategory=computer) -attr name -l > C:\Scripts\Computers.txt |
Результат выборки – файл C:\Scripts\Computers.txt со списком имен компьютеров.
Финальное решение
Шаг 1
Создаем на сервере папку C:\Scripts, в которую копируем утилиту PsShutdown.exe.
Шаг 2
В папке C:\Scripts создаем пакетный файл под названием RemoteShutdown.bat.
Файл создает выборку C:\Scripts\Computers.txt и затем запускает массовое выключение компьютеров из выборки.
Для контроля работы файла RemoteShutdown.bat создается файл журнала RemoteShutdownLog.txt.
Листинг файла RemoteShutdown.bat:
| @ECHO OFF DSQUERY * "OU=Desktops,DC=corp,DC=gorbunov,DC=pro" -filter (objectCategory=computer) -attr name -l > C:\Scripts\Computers.txt C:\Scripts\PsShutdown -s -f -t 300 -c -n 10 -e p:0:0 -m "Night shutdown. Please contact Servicedesk if you have any questions. Servicedesk phone: 123-45-67." @C:\Scripts\Computers.txt > C:\Scripts\RemoteShutdownLog.txt |
Для своей сети замените OU=Desktops,DC=corp,DC=gorbunov,DC=pro на путь к своему домену и контейнеру с компьютерами. Фильтр objectCategory=computer можно заменить на свой LDAP-запрос.
Шаг 3
В папке C:\Scripts создаем пакетный файл под названием CancelShutdown.bat.
Этот файл будет полезным для экстренной отмены выключения.
Листинг файла CancelShutdown.bat:
| C:\Scripts\PsShutdown -a -n 10 @C:\Scripts\Computers.txt |
Шаг 4
Добавляем на сервере файл RemoteShutdown.bat в Планировщик заданий для запуска, например, ежедневно в 22:00.
Подробнее об утилите DSQUERY:
http://technet.microsoft.com/en-us/library/cc754232.aspx
Подробнее об утилите PsShutdown:
http://technet.microsoft.com/ru-ru/sysinternals/bb897541.aspx
Как Group Policy работает на медленном канале
Групповая политика не всегда работает так, как мы ожидаем. Причин может быть много и одна из них - наличие медленного канала связи между клиентом и контроллером домена.
А что такое для Windows медленный канал? Как он влияет на групповую политику? Что мы можем настроить в системе? Ответы в статье.
Принудительная синхронизация контроллеров домена Active Directory
В большой сети у системного администратора часто возникает задача быстрой синхронизации всех контроллеров домена. Статья предлагает простое решение.
Multiple Local Group Policy objects
В данной статье я хочу рассказать о множественных локальных групповых политиках (Multiple Local Group Policy objects, MLGPOs) и вариантах их применения.
Виртуализация в Windows 7
Какие есть варианты виртуализации при использовании в качестве основной системы Windows 7, какое решение лучше?
Практический аудит логонов пользователей
Описание проблемы
Перед системным администратором периодически встают вопросы:
- За каким компьютером работает пользователь, например, APetrov?
- На какие компьютеры APetrov входил последнее время?
- Кто недавно входил на компьютер BUHGALTERIA?
Настройка встроенного механизма аудита в Windows теоретически позволяет ответить на данные вопросы, но реальное конфигурирование аудита и, главное, последующий анализ журналов событий не столь удобны, как того хотелось бы.
Решение
Ниже приведен вариант решения проблемы аудита входов пользователей, который успешно применялся мной в большой корпоративной среде (более 2000 клиентов).
Решение основано на сценарии входа, который автоматически запускается при входе пользователя и обновляет файлы аудита в общей папке на файловом сервере.
Пошаговое руководство
Шаг 1. Создание скрытой общей папки
Для начала создаем папку на файловом сервере. Пусть папка будет называться \\Server1\log$. Значок $ на конце имени папки делает ее скрытой, т.е. при навигации по сетевому окружению пользователи такую папку не видят.
Устанавливаем группе Authenticated Users право Modify как на саму общую папку, так и на NTFS. Для проверки правильности конфигурации прав доступа желательно попробовать от имени пользователя создать в папке \\Server1\log$ какой-нибудь файл.
Шаг 2. Создание сценария для записи событий аудита
Создаем файл сценария с именем CurrentUser.vbs. Содержание файла вы найдете здесь или ниже в Приложении. Не забудьте изменить в файле путь к общей папке вместо \\Server1\log$.
Сценарий проверяет в указанной общей папке наличие двух файлов <UserName>.log и <ComputerName>.log. Если файлов нет, то они создаются. Затем в файл <UserName>.log добавляется имя компьютера и дата/время, а в файл <ComputerName>.log. добавляется имя пользователя и дата/время.
При желании в файлах можно сохранять дополнительные атрибуты пользователя, например, подразделение (если этот атрибут заполняется в Active Directory).
Шаг 3. Назначение сценария через групповую политику
Создаем групповую политику и добавляем в нее сценарий входа пользователя. Политику желательно привязать на уровень домена, чтобы она автоматически применялась ко всем пользователям.
Шаг 4. Проверка файла аудита
Тестируем. Для проверки достаточно залогиниться на любой компьютер и проверить факт создания новых файлов с именем пользователя и компьютера в скрытой папке. В дальнейшем все входы в систему будут фиксироваться в этих файлах.
Применение
Для ответа на вопросы “За каким компьютером работает пользователь,APetrov?” и “На какие компьютеры APetrov входил последнее время?” нужно всего лишь открыть файл \\Server1\log$\APetrov.log.
Для ответа на вопрос “Кто недавно входил на компьютер BUHGALTERIA?” нужно открыть файл \\Server1\log$\BUHGALTERIA.log.
Заключение
Описанное выше решение не гарантирует абсолютную достоверность данных, поскольку все пользователи потенциально могут отредактировать файлы аудита. При необходимости ведения “серьезного” аудита данное решение будет лишь дополнением к правильно настроенному аудиту Windows.
В реальной жизни решение оказалось очень удобным как для сотрудников службы Helpdesk, так и для администраторов сети.
При желании вы можете вносить свои модификации в файл сценария для сбора более детальной информации о пользователях или компьютерах.
Приложение
Листинг файла сценария CurrentUser.vbs
Не забудьте изменить в переменной strShareName путь к общей папке вместо моей папки \\Server1\log$.
Строку 'WScript.Sleep 60000 можно раскомментировать, если сценарий требуется запустить с задержкой выполнения.
| Option Explicit Dim objFSO, objNetwork, objShell, objTS, objADSystemInfo, objUser strShareName = "\\Server1\log$" 'WScript.Sleep 60000 'delay listed milliseconds before script execution Set objFSO = CreateObject("Scripting.FileSystemObject") strUserName = objNetwork.UserName strFileName = strUserName & ".log" If objFSO.FileExists(strFile) Then Const FOR_WRITING = 2 'Replace all data within the file Set objTS = objFSO.OpenTextFile(strFile,FOR_APPENDING) strFileName = strComputerName & ".log" If objFSO.FileExists(strFile) Then Set objTS = objFSO.OpenTextFile(strFile,FOR_APPENDING) Wscript.Quit(1) |
.
Пример файла аудита \\Server1\log$\APetrov.log
| Date/time : 15.10.2010 09:39:54 Date/time : 16.10.2010 09:40:13 |
.
Пример файла аудита \\Server1\log$\BUHGALTERIA.log
| Date/time : 16.10.2010 09:40:13 Date/time : 16.10.2010 09:50:52 |
.
Как работает домен .РФ
Теория
Особенностью функционирования системы DNS является поддержка ограниченного стандартами набора из 63 символов: буквы A…Z, a..z английского алфавита, цифры 0,,9 и знак дефиса. Обратите внимание, что символ подчеркивания разрешен только как специальный префикс для обозначений записей служб. Он используется, например, для регистрации в DNS различных служб Active Directory.
Для преодоления ограничения на количество используемых символов был придуман специальный обходной маневр в виде стандарта PUNYCODE. Смысл этого стандарта в том, что все неанглоязычные наименования доменов преобразуются в “нормальные” имена DNS, состоящие из 63 разрешенных символов. Чтобы отличать “неродные” записи от привычных нам для всех преобразованных названий вводится префикс xn--.
На данный момент в корневых DNS зарегистрированы два кириллических домена: .РФ и .ИСПЫТАНИЕ.
Практика
Доменная зона .РФ с точки зрения DNS является зоной xn--p1ai. А, например, доменное имя президент.рф трансформируется в красивое имя
xn--d1abbgf6aiiy.xn--p1ai.
Можно даже “попинговать” хост xn--d1abbgf6aiiy.xn--p1ai:
| C:\>ping xn--d1abbgf6aiiy.xn—p1ai Обмен пакетами с xn--d1abbgf6aiiy.xn--p1ai [195.208.24.91] с 32 байтами данных: Ответ от 195.208.24.91: число байт=32 время=4мс TTL=57 Ответ от 195.208.24.91: число байт=32 время=5мс TTL=57 Ответ от 195.208.24.91: число байт=32 время=4мс TTL=57 Ответ от 195.208.24.91: число байт=32 время=4мс TTL=57 |
А вот команда ping президент.рф уже не работает, хотя сайт http://президент.рф открывается:
| C:\>ping президент.рф При проверке связи не удалось обнаружить узел президент.рф. Проверьте имя узла и повторите попытку. |
В чем же причина такой избирательности?
Причина кроется в том, что за преобразование всех “нестандартных” имен отвечают клиенты. И в приведенном выше примере современный браузер корректно трансформирует кириллическое имя сайта в его punycode-псевдоним, и уже этот псевдоним и запрашивается у серверов DNS. Команда ping про punycode-преобразования ничего не знает и запрашивает у DNS кириллическое имя, которое DNS найти, естественно, не может.
Если мы попробуем отправить письмо на адрес info@xn--d1abbgf6aiiy.xn--p1ai, то Outlook и многие онлайн-службы (Яндекс, Mail.ru), корректно обработают такой почтовый адрес. Outlook и Яндекс даже умеют отправлять письма на info@президент.рф. А Gmail, например, письма ни на punycode-домен, ни на кириллический пока не отправляет.
Если говорить о браузерах, то полноценная поддержка преобразований punycode встроена в IE7 и выше, Firefox 3.6.4 и выше.
Выводы
Punycode-преобразование – удел клиентского приложения.
Для работы многих ИТ-сервисов недостаточно только зарегистрированного в системе DNS кириллического имени. Необходимо убедиться, что все используемые в вашей организации и, возможно, в организациях-контрагентах клиентские приложения корректно преобразуют кириллические имена в стандартные для DNS запросы.
Похожие статьи: Настройка DNS для поддержки домена .РФ
Подробнее о списке корневых доменов: http://www.iana.org/domains/root/db/
Подробнее о стандарте RFC 1035 – DNS naming: http://tools.ietf.org/html/rfc1035
Подробнее о стандарте RFC 2782 – SRV records: http://tools.ietf.org/html/rfc2782
Подробнее о стандарте RFC 3492 – Punycode: http://tools.ietf.org/html/rfc3492
Резервное копирование сертификатов. Часть 4
Особенности резервного копирования сертификата и закрытого ключа при использовании смарт-карт
Каждая смарт-карта использует свое собственное хранилище для размещения сертификатов и закрытых ключей. Генерация пары асимметричных ключей (закрытого и открытого) производится внутри самой смарт-карты, и закрытый ключ затем никогда ее не покидает. Такой подход обеспечивает высокую степень защищенности закрытого ключа. Однако, выход из строя смарт-карты потребует полной замены цифровых сертификатов и последующей настройки приложений.
При необходимости создания резервной копии закрытого ключа и сертификата, хранимых на смарт-карте, необходимо сгенерировать запрос получения сертификата вне смарт-карты, сохранить полученный сертификат в формате .pfx, а затем импортировать сертификат и закрытый ключ в смарт-карту.
Файл в формате .pfx и будет требуемой резервной копией, которую затем можно будет восстановить на другой смарт-карте.
P.S. Для возможности экспорта закрытого ключа из локального хранилища не забудьте заранее разрешить экспорт закрытых ключей в свойствах шаблона запрашиваемого сертификата и затем указать в запросе на получение сертификата, что ключ является экспортируемым. При экспорте сертификата в файл .pfx лучше указывать опцию удаления из компьютера локальной копии закрытого ключа, чтобы затем закрытый ключ физически сохранялся только в резервном файле и на самой смарт-карте.
Подробнее о смарт-картах и Windows PKI:
http://technet.microsoft.com/en-us/library/dd277377.aspx
Схема процесса генерации ключей для смарт-карт:
http://technet.microsoft.com/en-us/library/Dd277377.smar0307_big(en-us,TechNet.10).gif
.gif){kind=link}
Подробнее о процедуре запроса сертификата для смарт-карты:
http://technet.microsoft.com/en-us/library/dd277383.aspx
Подробнее об импорте ключей в смарт-карту:
http://blogs.technet.com/b/pki/archive/2007/11/13/manually-importing-keys-into-a-smart-card.aspx
Связанные статьи:
- Часть 1. Общая часть
- Часть 2. Резервное копирование сертификатов и ключей вручную
- Часть 3. Централизованное резервное копирование
- Часть 4. Особенности резервного копирования ключей для смарт-карт
Резервное копирование сертификатов. Часть 3
Централизованное резервное копирование сертификатов и закрытых ключей средствами Службы Сертификатов Microsoft
Централизованное резервное копирование цифровых сертификатов устраняет ряд сложностей, которые возникают при ручном архивировании сертификатов:
- упрощается администрирование централизованного хранилища сертификатов и закрытых ключей;
- отпадает необходимость обхода всех клиентских машин;
- появляется возможность полной автоматизации процесса архивации;
- восстановление отдельных сертификатов можно делегировать выделенному агенту или агентам.
Суть централизованного автоматического архивирования сертификатов сводится к архивированию базы Службы Сертификатов.
Но! По умолчанию база Службы Сертификатов содержит в себе только сами сертификаты, а закрытые ключи всегда генерируются на локальных компьютерах и затем никуда из локального хранилища не передаются.
Как же заставить локальные компьютеры передавать центру сертификатов свой закрытый ключ?
Ответ следующий. До начала генерации запросов на получение клиентских сертификатов системный администратор должен выполнить следующие действия:
- настроить Key Recovery Agent (KRA) на сервере сертификатов. KRA может быть несколько;
- настроить в свойствах шаблона сертификатов разрешение на архивацию закрытого ключа.
После выполнения этих действий клиентский компьютер в процессе получения клиентского сертификата будет автоматически передавать на сервер сертификации свой закрытый ключ, а центр сертификации, в свою очередь, будет сохранять этот ключ в базе сертификатов в зашифрованном виде (с помощью ключа KRA) как дополнительный атрибут сертификата.
Восстановление сертификата вместе с закрытым ключом выполняется с помощью сертификата и закрытого ключа KRA в стандартный файл .pfx, который затем импортируется на клиентском компьютере.
Планирование безопасного хранения и применения закрытого ключа KRA является критически важным элементом политики безопасности цифровых сертификатов. Закрытый ключ KRA, фактически, становится мастер-ключом, позволяющим дешифровать любые закрытые ключи, сохраненные в базе Службы Сертификатов.
При планировании политики централизованного архивирования ключей необходимо учитывать и некоторые ограничения. Некоторые из них перечислены ниже:
- шаблоны клиентских сертификатов должны быть версии 2 или 3 (версия 3 нужна для использования шифрации CNG);
- для генерации асимметричных ключей должен использоваться алгоритм RSA; ключи, сгенерированные другими алгоритмами, не архивируются средствами Службы Сертификатов.
Пошаговое руководство по централизованному архивированию ключей есть в учебном курсе 6426 “Конфигурирование и устранение неисправностей решений идентификации и управления доступом на основе Windows Server 2008 Active Directory".
Подробнее о процедуре архивации закрытых ключей для серверов Windows Server 2003: http://technet.microsoft.com/ru-ru/library/cc738977(WS.10).aspx
Подробнее о процедуре архивации закрытых ключей для серверов Windows Server 2008: http://technet.microsoft.com/en-us/library/ee449489(WS.10).aspx
Подробнее о резервном копировании базы Службы сертификатов в Windows Server 2008: http://blogs.technet.com/b/pki/archive/2010/08/06/backing-up-windows-server-2008-adcs-ca-keys.aspx
Связанные статьи:
- Часть 1. Общая часть
- Часть 2. Резервное копирование сертификатов и ключей вручную
- Часть 3. Централизованное резервное копирование
- Часть 4. Особенности резервного копирования ключей для смарт-карт
Резервное копирование сертификатов. Часть 2
Архивирование клиентских сертификатов и ключей вручную
Архивирование сертификатов при данном подходе выполняется методом экспорта сертификата в файл.
Экспорт цифрового сертификата может быть выполнен в одном из двух форматов:
- экспорт только сертификата без экспорта закрытого ключа;
- экспорт сертификата вместе с закрытым ключом.
Для выполнения операции экспорта пользовательского сертификата необходимо подключиться к пользовательскому хранилищу сертификатов.
Первый способ – открыть Microsoft Management Console и добавить в нее оснастку Сертификаты.
Второй, более простой способ добраться до цифровых сертификатов пользователя, – открыть Internet Explorer и в свойствах обозревателя открыть вкладку Содержание.
При нажатии кнопки Сертификаты открывается окно, выводящее несколько вкладок различных типов сертификатов, которые есть у пользователя. В нашем случае нужна первая вкладка Личные.
Выбрав нужный сертификат, нажимаем кнопку Экспорт… и в запустившемся мастере экспорта выбираем формат экспортируемого файла.
На приведенном выше рисунке первые три опции доступны, а вот четвертая опция Файл обмена личной информацией – PKSC #12 (.PFX) является недоступной. Почему?
Потому что первые три опции экспортируют в файл только сам сертификат, а закрытый ключ остается в операционной системе. Четвертая же опция экспортирует сертификат вместе с закрытым ключом и данная операция является критичной с точки зрения безопасности. Для того, чтобы вы могли экспортировать из системы закрытый ключ, ваш запрос на получение сертификата должен заранее содержать разрешение на экспорт ключа, а шаблон сертификата (это уже настройки самого центра сертификации) должен разрешать такие запросы.
Ваши задачи как системного администратора в данном случае - заранее спланировать возможность экспорта закрытых ключей из клиентской машины (опция Allow private key to be exported на вкладке Request Handling в свойствах шаблона сертификата), а затем обойти все клиентские машины и экспортировать в централизованное хранилище (флешка, общая папка) клиентские сертификаты в формате .pfx.
Организационные и технические вопросы защиты централизованного хранилища фалов .pfx выходят за рамки данной статьи.
Процесс восстановления сертификатов в нашей схеме будет очень простой: после переустановки операционной системы и приложений нужно дважды щелкнуть на сохраненном файле .pfx и импортировать сертификат и закрытый ключ в хранилище.
Подробнее о настройках шаблонов сертификатов: http://technet.microsoft.com/en-us/library/cc725621(WS.10).aspx.
Связанные статьи:
- Часть 1. Общая часть
- Часть 2. Резервное копирование сертификатов и ключей вручную
- Часть 3. Централизованное резервное копирование
- Часть 4. Особенности резервного копирования ключей для смарт-карт
Резервное копирование сертификатов. Часть 1
Общая часть
Клиентские цифровые сертификаты широко используются в современных коммуникациях. Варианты их применения могут быть самые различные:
- клиентские сертификаты для подключения к веб-серверу по SSL (например, в системах клиент-банк);
- клиентские сертификаты для шифрования данных (например, при использовании Encrypted File System – EFS);
- клиентские сертификаты для добавления цифровой подписи в сообщения электронной почты.
Функционирование приложений, доступность зашифрованных данных в этих примерах целиком зависит от доступности клиентского сертификата пользователя и закрытого ключа, ассоциированного с используемым клиентским сертификатом.
На клиентском компьютере с Windows XP пользовательские сертификаты хранятся в открытом виде в профиле пользователя в папке \Application Data\Microsoft\SystemCertificates\My\Certificates. После входа пользователя в систему сертификаты записываются в специальную область в реестре, откуда к ним получают доступ приложения. Ассоциированные с сертификатами закрытые ключи хранятся в зашифрованном виде в профиле пользователя в папке \Application Data\Microsoft\Crypto\RSA. Закрытые ключи зашифрованы с помощью периодически обновляемого мастер-ключа пользователя.
Что произойдет с приложениями, если клиентский сертификат или закрытый ключ окажутся недоступными, например, при полной переустановке операционной системы или полном удалении профиля пользователя? Ответ очевиден, функционировать приложения не смогут, расшифровать данные будет невозможно.
Для предотвращения описанной выше ситуации системному администратору необходимо спланировать процедуры резервного копирования сертификатов и закрытых ключей.
Возможные варианты резервного копирования сертификатов следующие:
- экспорт сертификатов и ключей вручную в отдельные файлы;
- централизованное архивирование сертификатов и ключей средствами Certificate Services (AD CS в Windows Server 2008).
В последующих статьях я рассмотрел варианты резервного копирования подробнее:
- Часть 2. Резервное копирование сертификатов и ключей вручную
- Часть 3. Централизованное резервное копирование
- Часть 4. Особенности резервного копирования ключей для смарт-карт
Чтобы не перегружать статьи я постарался сконцентрироваться на описании самого процесса архивирования ключей, а не детальных шагах и скриншотах. Если информации окажется недостаточно, оставьте свой комментарий, я с удовольствием добавлю нужные детали.
Создание белых и черных списков доменов в ISA Server 2006
При обслуживании серверов ISA Server часто возникает вопрос автоматизации импорта белых или черных списков сайтов, которые используются для настроек правил доступа.
Однажды я решил эту задачу и предлагаю вам свой вариант решения.
На сервере требуется создать в папку C:\Lists и разместить в ней следующие файлы:
- BLACK_List_Domains.txt (текстовый файл, содержит черный список доменов)
- WHITE_List_Domains.txt (текстовый файл, содержит белый список доменов)
- UpdateNameSet.vbs (сценарий обновления наборов доменных имен)
- SortTextFile.vbs (сценарий для сортировки списков в текстовых файлах)
- _Update.bat (пакетный файл обновления наборов доменных имен)
Для обновления наборов доменов требуется внести изменения в соответствующий текстовый файл, а затем запустить файл _Update.bat.
Сценарий автоматически добавляет домен и все нижележащие домены в набор. Например, для домена xxx.ru сценарий внесет в набор записи xxx.ru и *.xxx.ru.
Важно! Доступ к отдельным страницам сайтов должен регулироваться через наборы URL, а не через наборы доменных имен.
Примечание. Не забудьте настроить политики ISA Server, чтобы белый список имел более высокий приоритет, чем черный. Например, если домен rbc.ru находится и в черном, и в белом списке, то доступ к сайту http://rbc.ru был бы разрешен.
Download: Lists.zip
Подписаться на:
Сообщения (Atom)
