Fedoseyev.ru

Все нижеописанное относится к Windows 2003, являющейся членом домена Active Directory. Итак, по умолчанию в ней существуют следующие группы безопасности:

1) Administrators (Администраторы) — члены группы обладают полным доступом ко всем ресурсам системы. По умолчанию содержит встроенную учетную запись Administrator.

2) Backup Operators (Операторы архива) — члены этой группы имеют право архивировать и восстанавливать файлы в системе независимо от того, какими правами эти файлы защищены. Backup Operators могут входить в систему и завершать ее работу, но они не имеют права изменять настройки безопасности. По умолчанию пуста.

3) Guests (Гости) — эта группа позволяет выполнить регистрацию пользователя с помощью учетной записи Guest и получить ограниченные права на доступ к ресурсам системы. Члены этой группы могут завершать работу системы. По умолчанию содержит пользователя Guest.

4) Power Users (Опытные пользователи) — члены этой группы могут создавать учетные записи пользователей, но они имеют право модифицировать настройки безопасности только для созданных ими учетных записей. Кроме того, они могут создавать локальные группы и модифицировать состав членов созданных ими групп. То же самое они могут делать с группами Users, Guests и Power Users. По умолчанию пуста.

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

6) Users (Пользователи) — члены этой группы могут выполнять большинство пользовательских функций. Могут создавать локальные группы и регулировать состав их членов. Они не могут получить доступ к общему каталогу или создать локальный принтер. По умолчанию содержит служебные учетные записи NT AUTHORITYAuthenticated Users (S-1-5-11) и NT AUTHORITYINTERACTIVE (S-1-5-4).

7) Network Configuration Operators (Операторы настройки сети) — группа, члены которой имеют некоторые права по настройке сетевых служб и параметров. По умолчанию пуста.

8) Remote Desktop Users (Удаленные пользователи рабочего стола) — эта группа содержит имена пользователей, которым разрешен удаленный доступ к рабочему столу.

9) HelpSenicesGroup (Группа служб поддержки) — группа для поддержки справочной службы Help and Support Service. По умолчанию содержит учетную запись SUPPORT_388945aO.

10) Performance Log Users (Пользователи журналов производительности) — члены этой группы могут просматривать журналы производительности. По умолчанию содержит служебную учетную запись NT AUTHORITYNETWORK SERVICE (S-l-5-20).

11) Performance Monitor Users (Пользователи системного монитора) — группа, члены которой могут выполнять мониторинг производительности системы. По умолчанию пуста.

12) Print Operators (Операторы принтеров) — члены этой группы могут администрировать принтеры в домене. По умолчанию пуста.

13) TelnetClients (Клиенты telnet) — группа, члены которой имеют доступ к службе Telnet Server на данном компьютере. По умолчанию пуста.

admin Default Windows, Безопасность, Шпаргалки

Одна из самых непротиворечивых концепций безопасности гласит, что без крайней необходимости работать под учетной записью администратора не следует. Особенно под учетной записью администратора домена. Однако, решение административных задач, требующих повышенных привилегий, эта концепция не отменяет. Удаленный доступ к серверу через Remote Desktop – это лишние телодвижения, да и, опять же, небезопасно. Наиболее подходящий путь – локальный запуск нужных оснасток управления с использованием команды RunAs, которая позволяет администратору выполнять любые задачи в системе, зарегистрировавшись в ней с использованием учетной записи рядового пользователя.

Для управления удаленными серверами Windows я использую пакеты Administrative Tools для своей клиентской ОС. Они доступны для загрузки с сайта Microsoft:

Windows Server 2003 Administration Tools Pack: http://www.microsoft.com/downloads/details.aspx?FamilyID=c16ae515-c8f4-47ef-a1e4-a8dcbacff8e3&displaylang=en

Microsoft Remote Server Administration Tools for Windows Vista: http://www.microsoft.com/downloads/details.aspx?FamilyId=9FF6E897-23CE-4A36-B7FC-D52065DE9960&displaylang=en

Remote Server Administration Tools for Windows 7: http://www.microsoft.com/downloads/details.aspx?FamilyID=7D2F6AD7-656B-4313-A005-4E344E43997D&displaylang=en

Установив соответствующий вашей системе пакет администрирования, вы получите доступ прямо со своего компьютера к большинству оснасток управления серверами, таких как Active Directory Domains and Trusts, Active Directory Sites and Services, Active Directory Users and Computers, Distributed File System, DNS, Group Policy Editor, DHCP и пр.

Для запуска любой из оснасток с привилегиями доменного администратора, применим команду RunAs. Например, запустим оснастку Active Directory Users and Computers от имени пользователя admin, принадлежащего к домену domain.ru:

Синтаксис RunAs достаточно прост, чаще всего с ней используются следующие ключи:

1) /user – имя пользователя;

2) /netonly – использование полномочий только для доступа к удаленным ресурсам;

3) /env – использование текущего окружения, без создания окружения, характерного для указанного ключем /user пользователя;

4) /profile – загрузка профиля пользователя;

5) /noprofile – загрузка профиля пользователя не будет осуществляться.

По аналогии можно запускать любую из оснасток, входящих в состав Administration Tools:

Active Directory Domains and Trusts — domain.msc

Active Directory Sites and Services — dssite.msc

Active Directory Users and Computers — dsa.msc

Computer Management — compmgmt.msc

Distributed File System — dfsgui.msc

DNS — dnsmgmt.msc

DHCP – dhcpmgmt.msc

Group Policy Editor — gpedit.msc

Local Security Settings — secpol.msc

Routing and Remote Access — rrasmgmt.msc

Само собой, оснастки для управления локальными ресурсами, которые по умолчанию установлены в любой Windows-системе, начиная с Windows XP, можно использовать и для администрирования удаленных систем. Приведу список самых используемых:

Services – services.msc

Device Manager — devmgmt.msc

Disk Management — diskmgmt.msc

Local Users and Groups — lusrmgr.msc

Shared Folders — fsmgmt.msc

Напоследок напомню, что для работы RunAs необходимо, чтобы была запущена служба Secondary Logon.

admin Default Software, Windows Server, Безопасность, Удаленное администрирование

В большинстве организаций, даже прошедших путь оптимизации бизнес-процессов и автоматизации документооборота, до сих пор активно используются файловые серверы, служащие хранилищами важной корпоративной информации. Системный администратор, ответственный за сохранность данных на файл-серверах, должен позаботиться не только о развертывании надежной системы резервного копирования, но и о максимальном сокращении времени простоев. Я рассмотрю самый что ни на есть частный случай: организацию, размещенную в разных корпусах гипотетического делового центра, с сетью филиалов.

Итак, исходные данные: головной офис с размещением сотрудников в двух разных корпусах, один филиал. Файл-серверы установлены в обоих корпусах головного офиса и в филиале. Между корпусами лежит оптика, с филиалом установлен VPN-канал из первого корпуса головного офиса.

Задача: обеспечить гипотетическому сотруднику максимальную доступность данных вне зависимости от его местонахождения.

Для решения данной задачи мы будем использовать технологию компании Microsoft, метко названную Distributed File System (DFS). DFS была разработана для упрощения доступа к данным и управления ими. В Windows Server 2003 R2 к ней был добавлен механизм репликации, получивший вполне прогнозируемое название DFSR (Distributed File System Replication). Если вкратце описать схему работы DFS, то это будет выглядеть примерно так:

На рисунке условно изображены 3 файл-сервера, каждый из которых служит хранилищем разных общих директорий. Сервер DFS образует корень из этих директорий и открывает к ним общий доступ под именем Summary Data. Клиенты, в свою очередь, имея необходимость использовать данные со всех трех серверов, обращаются только к DFS, который обеспечивает им централизованный доступ к нужным ресурсам. Вполне логично: ни к чему пользователю помнить UNC-пути к отдельно взятым файл-серверам, он должен везде и всегда иметь привычную, удобную рабочую среду.

Вернемся к нашей задаче. Пока наша схема сети выглядит примерно так:

Для наведения порядка в этом бедламе нам потребуется установить службы DFS на серверах. В Windows 2003 это делается через оснастку Add/Remove Windows Components:

В Windows 2008 – через мастер добавления ролей:

После установки служб DFS, запускаем оснастку Distributed File System. Она работает в стандартной среде MMC, слева в меню жмем правой кнопкой мыши (далее – ПКМ) единственный пункт и выбираем New Root. Запустится мастер настройки корня DFS. Он может быть доменным, либо изолированным:

Выбираем доменный, после чего выбираем домен, в котором будет размещено дерево логических имен DFS:

После этого нам останется только выбрать сервер, на котором будет размещен корень…

…и мы приступим непосредственно к его созданию:

Свой корень я назову Corporate FS (сокращение от Corporate File Server) и помещу его в директорию C:Corporate FS

Корень готов. Приступим к присоединению к нему файл-серверов и установке реплик. На корневом DFS-сервере я создал на диске C: общую директорию Main Office Documents с данными, на сервере SRV2 – такую же, но пустую, и на сервере SRV3 директорию Branch Office Documents, тоже с данными.

Теперь жмем на наш корень ПКМ и выбираем New Link. Первым линком будет наш общий ресурс Main Office Documents:

Аналогично добавляем \Srv3Branch Office Documents. В конце концов мы получаем следующую DFS-структуру:

Чуть позже мы ее протестируем. Но пока мы еще не решили задачу резервирования данных. Я продемонстрирую простейшую схему репликации: данные из общей папки с SRV1 будут копироваться на SRV2. Полную репликацию всех сетевых ресурсов и корня DFS рассматривать не будем, так как настраивается она аналогичным образом. Одного примера будет вполне достаточно.

Жмем ПКМ на линк Main Office Documents и выбираем New Target. В появшившемся диалоговом окне выбираем сетевой ресурс с таким же именем на SRV2, ставим галочку в чекбоксе Add this target to the replication set и жмем Ок:

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

Оставляем по умолчанию и жмем Next. На следующем шаге нам будет предложено выбрать топологию репликации. Вариантов всего 4:

— Ring (кольцо) – реплика будет обмениваться информацией с двумя соседними;

— Hub and spoke (звезда) — выделяется основная реплика, с которой обмениваются информацией все остальные;

— Full mesh (полносвязная сеть) — все реплики обмениваются информацией друг с другом;

— Custom (пользовательская) – каждая пара реплик настраивается вручную.

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

 

Для наглядной проверки репликации я создал на сервере SRV1 в C:Main Office Documents несколько папок и файлов:

По умолчанию репликация происходит раз в 15 минут. По прошествии этого времени данные благополучно появились без моего вмешательства и на SRV2:

Можно выполнить принудительную репликацию командой:

ntfrsutl poll /now ИМЯ-РЕПЛИЦИРУЕМОГО-СЕРВЕРА

Осталось опубликовать DFS в Active Directory и протестировать его доступность. Для публикации кликаем ПКМ по корню DFS, выбираем Properties и в открывшемся окне переходим на вкладку Publish:

Обратите внимание: так как наш корень DFS доменный, а не изолированный, при обращении к нему может использоваться конструкция UNC только с названием домена, без уточнения имени сервера. Кстати говоря, DFS с точки зрения клиентской ОС – не более чем обычная общая папка, то есть доступна по UNC и может быть подмонтирована как сетевой диск. Нажимаем Ок.

В качестве тестера может выступить любой доменный клиент. Я воспользуюсь сервером SRV3:

 

В корне Corporate FS, как и предполагалось, ссылки на файл-серверы головного офиса и филиала. Впрочем, по ссылкам мы попадаем туда же, куда и задумывали. Система работает, алиллуйя.

Итак, что же дает нам DFS?

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

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

3. Балансировку нагрузки. В основном, на сетевые интерфейсы.

4. Прозрачность соответствия логического представления данных и их физического расположения. Сотрудник из офиса деревни Ольховка Кировской области может работать с файл-сервером, расположенном на Барбадосе, также, как если бы он стоял у него в соседнем кабинете. Впрочем, сотрудник наверняка и так в этом будет уверен, глядя на DFS.

Айс, не правда ли?

admin Default DFS, Windows Server, Отказоустойчивость, Резервное копирование, Хранение данных