Домен контроллер в локальной сети для разграничения прав доступа пользователей |
Здравствуйте, гость ( Вход | Регистрация )
Домен контроллер в локальной сети для разграничения прав доступа пользователей |
Jan 26 2008, 14:35
Сообщение
#1
|
|
Новичок Группа: Local moder Сообщений: 43 Регистрация: 11.10.2006 Из: Чебы Пользователь №: 2,374 |
имеется локальная сеть
на всех компах стоит WinXP Home Edition требуется организовать домен контроллер. на серверный комп ессено придётся ставить явно не Home. прошу: первое: прошу дать ссылочки на полезную литературу где разжёвывается что такое домен-котроллер и с чем его едят, плюсы, минусы.. второе: как правильно организовать его в локальной сети на практике. Сообщение отредактировал ReDe - Jan 26 2008, 14:40 |
|
|
Jan 27 2008, 11:09
Сообщение
#2
|
|
Новичок Группа: Posters Сообщений: 38 Регистрация: 16.2.2007 Из: Москва Пользователь №: 5,329 |
Хомяки в домене не живут. А контролер появится с серверной осью.
Почитай здесь: http://support.microsoft.com/ |
|
|
Jan 27 2008, 11:52
Сообщение
#3
|
|
Ацкой лесной чудовищ Группа: Local moder Сообщений: 2,308 Регистрация: 22.2.2007 Пользователь №: 5,408 |
Ставишь домен сервер, скажем 2003 вин.
В домены на рабочие станции вешаешь XP Pro. роль сервера 2003 - есть контролер деомена если я ничего не путаю. А дальше в ролях есть Active Directory - там выстраиваешь учётные записи сетевые. -------------------- Я ещё живой и иногда сюда захожу! 18.02.2021
|
|
|
Mar 13 2008, 21:06
Сообщение
#4
|
|
Новичок Группа: Members Сообщений: 17 Регистрация: 18.5.2006 Из: Чебоксары СЗР Пользователь №: 592 |
а вообще...если все дело в офисе крутится, то выкидывай нафиг все винты, точнее можно их продать куда нибуть, делаешь из компов "тонких клиентов" и все радуются)
и дешевле выйдет, за каждое терминальное подключение 800р заплатишь и все, зато все остальные проги не надо будет покупать) |
|
|
Mar 13 2008, 21:38
Сообщение
#5
|
|
Настоящий ADSL'щик Группа: Posters Сообщений: 462 Регистрация: 8.10.2005 Пользователь №: 97 |
а вообще...если все дело в офисе крутится, то выкидывай нафиг все винты, точнее можно их продать куда нибуть, делаешь из компов "тонких клиентов" и все радуются) и дешевле выйдет, за каждое терминальное подключение 800р заплатишь и все, зато все остальные проги не надо будет покупать) Не знаю как насчет остального софта, но в отношении продуктов Microsoft все предельно ясно - используете Office в терминальном режиме на 10 машинах, значит обязаны купить 10 лицензий Office, и не важно, что физически будет установлена только одна копия на сервере, так что экономии никакой не будет -------------------- We do what we must because we can
|
|
|
Mar 13 2008, 23:33
Сообщение
#6
|
|
Новичок Группа: Members Сообщений: 17 Регистрация: 18.5.2006 Из: Чебоксары СЗР Пользователь №: 592 |
вот именно, ключевое слово "используете", фактически доказать и показать что офис использовался с разных терминалов не возможно)
а может он с одной и той же машины всеми пользовался) |
|
|
Mar 21 2008, 21:25
Сообщение
#7
|
|
Новичок Группа: Members Сообщений: 20 Регистрация: 6.12.2007 Пользователь №: 12,326 |
имеется локальная сеть на всех компах стоит WinXP Home Edition требуется организовать домен контроллер. на серверный комп ессено придётся ставить явно не Home. прошу: первое: прошу дать ссылочки на полезную литературу где разжёвывается что такое домен-котроллер и с чем его едят, плюсы, минусы.. второе: как правильно организовать его в локальной сети на практике. Вытряхивай с начальства 300тыс на лицензии =) На сервак, на клиентские лицензии, на лизензии winXP - это для средней конторки на 50 ПК+сервак |
|
|
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 |
а вообще...если все дело в офисе крутится, то выкидывай нафиг все винты, точнее можно их продать куда нибуть, делаешь из компов "тонких клиентов" и все радуются) и дешевле выйдет, за каждое терминальное подключение 800р заплатишь и все, зато все остальные проги не надо будет покупать) ааа бугага а севрвак под такие нужды ты в курсе сколько будет стоить??? а сетевое оборудование??? |
|
|
Sep 30 2008, 18:24
Сообщение
#10
|
|
Настоящий ADSL'щик Группа: Posters Сообщений: 371 Регистрация: 17.8.2006 Пользователь №: 1,221 |
|
|
|
Текстовая версия | Сейчас: 21st September 2024 - 01:32 |