IPB

Здравствуйте, гость ( Вход | Регистрация )

> Домен контроллер в локальной сети для разграничения прав доступа пользователей
ReDe
сообщение Jan 26 2008, 14:35
Сообщение #1


Новичок
Иконка группы

Группа: Local moder
Сообщений: 43
Регистрация: 11.10.2006
Из: Чебы
Пользователь №: 2,374



имеется локальная сеть
на всех компах стоит WinXP Home Edition

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

прошу:
первое: прошу дать ссылочки на полезную литературу где разжёвывается что такое домен-котроллер и с чем его едят, плюсы, минусы..
второе: как правильно организовать его в локальной сети на практике.

Сообщение отредактировал ReDe - Jan 26 2008, 14:40
Вернуться к началу страницы
 
+Цитировать сообщение
 
Создать новую тему
Ответов (1 - 9)
maniak_recedivis...
сообщение Jan 27 2008, 11:09
Сообщение #2


Новичок
*

Группа: Posters
Сообщений: 38
Регистрация: 16.2.2007
Из: Москва
Пользователь №: 5,329



Хомяки в домене не живут. А контролер появится с серверной осью.
Почитай здесь: http://support.microsoft.com/
Вернуться к началу страницы
 
+Цитировать сообщение
traktor
сообщение Jan 27 2008, 11:52
Сообщение #3


Ацкой лесной чудовищ
Иконка группы

Группа: Local moder
Сообщений: 2,308
Регистрация: 22.2.2007
Пользователь №: 5,408



Ставишь домен сервер, скажем 2003 вин.
В домены на рабочие станции вешаешь XP Pro.

роль сервера 2003 - есть контролер деомена если я ничего не путаю.
А дальше в ролях есть Active Directory - там выстраиваешь учётные записи сетевые.


--------------------
Я ещё живой и иногда сюда захожу! 18.02.2021
Вернуться к началу страницы
 
+Цитировать сообщение
dimych
сообщение Mar 13 2008, 21:06
Сообщение #4


Новичок
*

Группа: Members
Сообщений: 17
Регистрация: 18.5.2006
Из: Чебоксары СЗР
Пользователь №: 592



а вообще...если все дело в офисе крутится, то выкидывай нафиг все винты, точнее можно их продать куда нибуть, делаешь из компов "тонких клиентов" и все радуются)
и дешевле выйдет, за каждое терминальное подключение 800р заплатишь и все, зато все остальные проги не надо будет покупать)
Вернуться к началу страницы
 
+Цитировать сообщение
GerVin
сообщение Mar 13 2008, 21:38
Сообщение #5


Настоящий ADSL'щик
****

Группа: Posters
Сообщений: 462
Регистрация: 8.10.2005
Пользователь №: 97



Цитата(dimych @ Mar 13 2008, 21:06) *
а вообще...если все дело в офисе крутится, то выкидывай нафиг все винты, точнее можно их продать куда нибуть, делаешь из компов "тонких клиентов" и все радуются)
и дешевле выйдет, за каждое терминальное подключение 800р заплатишь и все, зато все остальные проги не надо будет покупать)

Не знаю как насчет остального софта, но в отношении продуктов Microsoft все предельно ясно - используете Office в терминальном режиме на 10 машинах, значит обязаны купить 10 лицензий Office, и не важно, что физически будет установлена только одна копия на сервере, так что экономии никакой не будет


--------------------
We do what we must because we can
Вернуться к началу страницы
 
+Цитировать сообщение
dimych
сообщение Mar 13 2008, 23:33
Сообщение #6


Новичок
*

Группа: Members
Сообщений: 17
Регистрация: 18.5.2006
Из: Чебоксары СЗР
Пользователь №: 592



вот именно, ключевое слово "используете", фактически доказать и показать что офис использовался с разных терминалов не возможно)
а может он с одной и той же машины всеми пользовался)
Вернуться к началу страницы
 
+Цитировать сообщение
Smersh
сообщение Mar 21 2008, 21:25
Сообщение #7


Новичок
*

Группа: Members
Сообщений: 20
Регистрация: 6.12.2007
Пользователь №: 12,326



Цитата(ReDe @ Jan 26 2008, 14:35) *
имеется локальная сеть
на всех компах стоит WinXP Home Edition

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

прошу:
первое: прошу дать ссылочки на полезную литературу где разжёвывается что такое домен-котроллер и с чем его едят, плюсы, минусы..
второе: как правильно организовать его в локальной сети на практике.

Вытряхивай с начальства 300тыс на лицензии =) На сервак, на клиентские лицензии, на лизензии winXP - это для средней конторки на 50 ПК+сервак
Вернуться к началу страницы
 
+Цитировать сообщение
stepka
сообщение Apr 10 2008, 07:25
Сообщение #8


Настоящий ADSL'щик
****

Группа: Posters
Сообщений: 371
Регистрация: 17.8.2006
Пользователь №: 1,221



Стандартный подход, который Microsoft предлагает во всех курсах по администрированию, обозначается аббревиатурой AGLP. Как известно, это сокращение расшифровывается следующим образом: «Учетная запись (Account) — глобальная группа (Global Group) — локальная группа (Local Group) — Разрешения (Permissions)». Данный подход выражается в следующем (см. рис. 1).



Каждый ресурс, за исключением объектов Active Directory, расположен на каком-либо компьютере. Для регулирования доступа к этому ресурсу создаются локальные группы на данном компьютере либо локальные доменные группы в домене Active Directory. В списках допусков к объектам, составляющим ресурс, фигурируют только эти локальные группы. Число локальных групп соответствует числу уровней доступа, необходимому для данного ресурса. Таких уровней как минимум два: для администрирования ресурса и для повседневного использования.

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

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

Такой подход хорош, но есть одна беда: для исполнения своих служебных обязанностей пользователю требуется доступ ко множеству объектов, поэтому приходится включать его в несколько глобальных групп, регулирующих доступ к этим объектам. Если же круг обязанностей меняется, при стандартном подходе AGLP необходимо тщательно пересмотреть членство пользователя в группах. Как правило, на практике все сводится к добавлению пользователя в новые группы, чтобы он получил доступ к другим ресурсам.

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

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

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

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

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

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

Образуется цепочка взаимоотношений: учетная запись — глобальная группа должностных обязанностей — глобальная группа доступа к ресурсу — локальная группа доступа к ресурсу — разрешения на объекты. Это можно записать в виде аббревиатуры AGGLP, см. рис. 2.

Для того чтобы реализация этой схемы была возможна, в корпоративной сети должна быть развернута служба Active Directory, причем не в режиме совместимости с Windows NT (смешанный режим не допускает вложенного членства в группах, поэтому описанные действия просто невозможны), а в собственном режиме Windows 2000 или режиме Windows Server 2003.



Рис. 2. Администрирование доступа к ресурсам по схеме AGGLP



Рис. 3. Администрирование доступа к ресурсам по схеме AUULP



Еще одно ограничение: так, как описано выше, предлагаемый подход будет работать только в пределах одного домена. Дело в том, что в состав доменных глобальных групп разрешается включать только другие доменные глобальные группы из того же домена и пользователей из того же домена. Для сети со множеством доменов, входящих в состав одного леса (а если Active Directory работает в режиме Windows Server 2003, то и нескольких лесов, связанных доверительными отношениями), этот вариант не подходит. Но ничто не мешает использовать вместо доменных глобальных групп универсальные. В силу ограничений в допустимом вложенном членстве (универсальная группа может включать доменную глобальную, но не наоборот) универсальные группы должны быть обязательно на обеих позициях — как для регулирования доступа, так и для описания должностей.

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

Получившуюся цепочку взаимоотношений можно записать следующим образом: учетная запись — универсальная группа должности — универсальная группа доступа к ресурсу — локальная доменная группа — разрешения на доступ к объектам. Можно эту цепочку обозначить аббревиатурой AUULP, см. рис. 3.

Вариант AUULP также не лишен недостатков. Информация об универсальных группах распространяется в составе данных глобального каталога, поэтому добавление большого количества универсальных групп автоматически приведет к увеличению трафика репликации. Что касается обработки этих данных контроллерами домена, то с этой стороны проблем возникнуть не должно — вычислительная мощность компьютеров, которые сейчас имеются в продаже, с запасом покрывает необходимые потребности. А вот трафик репликации — это дополнительная статья расходов для территориально распределенной организации, отдельные подсети которой соединены между собой через VPN с использованием публичных каналов.

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

Более серьезная проблема связана с необходимостью разграничения прав по администрированию полученной структуры в среде с децентрализованным администрированием. Можно выделить особую группу администраторов, уполномоченных управлять членством в группах, описывающих должности, и потребовать, чтобы все администраторы на местах обращались к этим уполномоченным администраторам при каждом переходе с должности на должность пользователей, входящих в их зону ответственности, но тогда в результате получится корпоративная сеть с централизованным управлением. Можно всем администраторам на местах предоставить разрешение Add/remove members на универсальные группы, описывающие должности, чтобы они сами могли вносить соответствующие изменения, но тогда они смогут исключать из такой группы «чужих» пользователей, т. е. пользователей, входящих в зону ответственности другого администратора.

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

Для каждой зоны ответственности «местного» администратора следует:
создать глобальную группу (как правило, в зону ответственности администраторов на местах входит какой-либо один домен или объект - организационное подразделение, поэтому для работы в рамках такой зоны достаточно манипуляций с глобальными доменными группами), соответствующую универсальной группе, описывающей должность;
включить эти глобальные группы в соответствующие универсальные группы;
уполномочить администраторов на местах распоряжаться членством в этих глобальных группах. При этом они смогут управлять членством в такой группе только пользователей из своей зоны ответственности.

Таким образом, для сетей с децентрализованным управлением предлагается следующая схема взаимоотношений: учетная запись — «местная» глобальная доменная группа — универсальная группа должности — универсальная группа доступа к ресурсу — локальная доменная группа — разрешения на доступ к объектам. Соответствующая аббревиатура — AGUULP, см. рис. 4.
Размещение объектов и дополнительный контроль

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

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

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

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

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

Дополнительный контроль всех настроек, устанавливаемых в рамках реализации подхода AUULP/AGUULP, возможен с использованием групповых политик. Если ресурс представляет собой фиксированный набор папок и/или файлов, целесообразно контролировать списки разрешений на эти папки и файлы с помощью групповой политики: раздел Computer Settings — Security Settings — File System. Соответствующий объект групповой политики (GPO) должен применяться к тому серверу, на котором размещается ресурс, но в то же время не затрагивать те серверы, которых данная настройка не касается. Поэтому целесообразно этот объект групповой политики размещать в том объекте — организационном подразделении, где непосредственно размещается данный сервер, и дополнительно настроить на GPO список разрешений, чтобы настройка не затрагивала остальные серверы, расположенные здесь же.

Вложенное членство в группах также можно регулировать через групповые политики. Надо только иметь в виду, что эти политики должны применяться ко всем контроллерам домена, или как минимум к тому из них, который является мастером инфраструктуры. Соответствующие настройки выполняются в разделе Computer Settings — Security Settings — Restricted Groups:
локальная доменная группа, регламентирующая доступ к ресурсу, - настройка Members, включить только соответствующую универсальную группу;
универсальная группа, регламентирующая доступ к ресурсу, - настройка Member of, включить только соответствующую локальную доменную группу;
универсальная группа, описывающая набор прав доступа, необходимых для исполнения должностных обязанностей, - настройка Member of, включить соответствующие универсальные группы, регламентирующие доступ к необходимым ресурсам.

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

Кроме того, при планировании структуры групповых политик, реализующих дополнительные проверки списков доступа к файлам и папкам, а также проверки членства в группах, нужно иметь в виду следующее. Настройки раздела Computer Settings — Security Settings — File System из разных объектов групповых политик суммируются, и правила разрешения конфликтов при наследовании GPO действуют в отношении каждого отдельно взятого файла или папки, упомянутых в этом разделе. Поэтому соответствующие параметры могут настраиваться в любых GPO, действие которых распространяется на компьютер, содержащий ресурс. Желательно, чтобы это был GPO, применяемый к компьютеру последним.

В то же время содержимое раздела Computer Settings — Security Settings — Restricted Groups замещается целиком, и действовать будут только установки, указанные в последнем применяемом GPO. Поэтому необходимо соблюдать следующие ограничения.
В настройках групповой политики Computer Settings - Security Settings - Restricted Groups должна фигурировать вся проверяемая структура членства в группах, касающаяся групп данного домена.
Недопустима ситуация, когда результирующие настройки раздела Computer Settings - Security Settings - Restricted Groups будут разными для разных контроллеров домена. В противном случае синхронизация данных между доменами при попытке определить членство в группах приведет к неопределенному результату.

Рекомендуется действовать следующим образом.
Указать настройки Computer Settings - Security Settings - Restricted Groups в одном и только в одном GPO для каждого домена. Прописать там параметры членства во всех группах, созданных в данном домене.
Привязать этот GPO ко всем объектам - организационным подразделениям, в которых находятся контроллеры домена.
Переместить данный GPO в списке привязок наверх, чтобы он применялся последним и именно его настройки вступали в силу.

Если указывать настройки Computer Settings — Security Settings — Restricted Groups в нескольких GPO, придется следить за тем, чтобы содержимое настроек было всегда одинаковым. При этом любая перестройка будет затруднена и может вызвать проблемы, если новое состояние забыли скопировать в какой-то из задействованных GPO.
Право выбора

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

Могут быть и другие способы, реализующие разграничение доступа на основе должностей сотрудников или их организационных ролей, что с функциональной точки зрения одно и то же. Например, в состав Windows Server 2003 включен компонент Authorization Manager, реализующий похожий подход, но только там для предоставления пользователю необходимого набора прав и разрешений используются наборы сценариев на VBScript или Jscript, из которых вызываются системные API, реализующие работу со списками разрешений и предоставление системных прав. В случае его использования необходимо сначала разработать соответствующие сценарии, зато при подходящем наборе сценариев получается гарантированный результат.

Тем не менее, если администратору затруднительно по какой-либо причине использовать сценарии в Authorization Manager (например, еще не установлена Windows Server 2003 или же Active Directory пока работает в режиме Windows 2000 Native), можно воспользоваться предлагаемым подходом AUULP или придумать что-то свое. В любом случае всем администраторам желаю успехов в нашем нелегком труде!
Вернуться к началу страницы
 
+Цитировать сообщение
Сашка-Хуожник
сообщение Sep 21 2008, 12:26
Сообщение #9


Новичок
*

Группа: Members
Сообщений: 2
Регистрация: 1.12.2006
Пользователь №: 3,592



Цитата(dimych @ Mar 13 2008, 22:06) *
а вообще...если все дело в офисе крутится, то выкидывай нафиг все винты, точнее можно их продать куда нибуть, делаешь из компов "тонких клиентов" и все радуются)
и дешевле выйдет, за каждое терминальное подключение 800р заплатишь и все, зато все остальные проги не надо будет покупать)


ааа бугага а севрвак под такие нужды ты в курсе сколько будет стоить??? а сетевое оборудование???
Вернуться к началу страницы
 
+Цитировать сообщение
stepka
сообщение Sep 30 2008, 18:24
Сообщение #10


Настоящий ADSL'щик
****

Группа: Posters
Сообщений: 371
Регистрация: 17.8.2006
Пользователь №: 1,221



Цитата(Сашка-Хуожник @ Sep 21 2008, 13:26) *
ааа бугага а севрвак под такие нужды ты в курсе сколько будет стоить??? а сетевое оборудование???

сервак+ винда серверная от 150000 деревянных. + еще х3 сколько на каждый терминал уйдёт...

Сообщение отредактировал stepka - Sep 30 2008, 18:25
Вернуться к началу страницы
 
+Цитировать сообщение

ОтветитьСоздать новую тему
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0

 



RSS Текстовая версия Сейчас: 29th March 2024 - 07:34