As organizations continuously evolve in the digital landscape, managing user permissions and access rights effectively becomes crucial for maintaining security and operational efficiency. One powerful approach to access management in Windows Server is Role-Based Access Control (RBAC). This article delves into the concept of RBAC, its benefits, and how to implement it in a Windows Server environment.
Role-Based Access Control is a method for managing user permissions within a system based on predefined roles. In an RBAC model, users are assigned to specific roles that encompass the permissions required to perform their job functions. This simplifies the management of user rights and ensures that individuals have access only to the resources they need.
Key Concepts of RBAC
-
Roles: A role is a collection of access rights. In Windows Server, common roles include Administrator, User, and Guest, among others. Each role aggregates permissions aligned with specific job functions.
-
Users: Users are individuals or entities that require access to system resources. In an RBAC system, users are assigned particular roles based on their job requirements.
-
Permissions: Permissions define what actions a user can perform on resources, such as reading, writing, or executing files.
- Sessions: A session represents the occurrence of a user accessing the system with a specific set of roles. This determines which permissions the user can utilize during that session.
Benefits of Implementing RBAC
-
Enhanced Security: By limiting access based on roles, organizations can minimize the risk of unauthorized access to sensitive information.
-
Simplified Management: Assigning roles rather than individual permissions makes it easier for administrators to manage access rights, particularly in large organizations with extensive user bases.
-
Compliance: RBAC helps in adhering to regulatory requirements by providing a clear structure for managing user permissions, making it easier to maintain audits and compliance checks.
- Scalability: As businesses grow, RBAC can adapt to changing roles and responsibilities without the need to individually assign permissions to each user.
Implementing RBAC in Windows Server
To implement RBAC effectively in a Windows Server environment, follow these essential steps:
Step 1: Identify Roles
Begin by identifying the various roles within your organization. Discuss with team leads and department heads to define roles based on job functions. Common roles might include:
- IT Administrator
- HR Manager
- Finance Analyst
- Sales Representative
Step 2: Define Permissions
Once roles are identified, outline the permissions associated with each role. This will involve determining which resources are accessible to each role and what actions they can perform.
Step 3: Create Active Directory Groups
In Windows Server, you can create Active Directory (AD) groups that correspond to the identified roles. Assign users to these groups based on their job functions.
Here’s how to create a group in Active Directory:
- Open Active Directory Users and Computers.
- Right-click the desired organizational unit (OU) and select New > Group.
- Name the group according to the role and assign the correct type (e.g., Security).
- Click OK.
Step 4: Assign Permissions
Assign the necessary permissions to the AD groups you’ve created. This process can be performed via the Group Policy Management Console or directly on the resources (e.g., file shares) that need managing.
Step 5: Review and Monitor
Continuously review role assignments and permissions to ensure they still align with the operational requirements of the organization. Audit logs to monitor permission usage and make adjustments as necessary.
Best Practices for RBAC in Windows Server
-
Least Privilege Principle: Always assign the minimum permissions necessary for a role. This limits access and reduces risk.
-
Regular Audits: Conduct periodic audits of role assignments and permissions to ensure compliance and relevance to current organizational structure.
-
User Training: Educate users about their roles and responsibilities. Understanding the implications of their permissions helps promote security awareness.
- Documentation: Maintain detailed documentation of roles, permissions, and changes in access rights for compliance and governance purposes.
Conclusion
Implementing Role-Based Access Control in Windows Server presents a structured and efficient means of managing user permissions and securing resources. By understanding the fundamentals of RBAC and following the best practices, organizations can enhance their security posture while ensuring that users have the necessary access to perform their jobs effectively. For more detailed insights, consider visiting the official Microsoft documentation.
For further reading and in-depth understanding, explore resources available on the Microsoft website.
Менеджер авторизации — это попытка Microsoft ввести управление доступом на основе ролей для приложений, запускающихся под Windows. Менеджер авторизации был включен в Release Candidate 1 (RC1) Windows Server 2003. Эта концепция получила название RBAC-модель (Role-Based Access Controls model). Сотрудники института National Institute of Standards and Technology (NIST) Дэвид Феррайоло и Ричард Кун впервые описали концепцию ролевого управления доступом (RBAC) в 1992 году в статье «Role-Based Access Controls», которую можно получить по адресу http://hissa.ncsl.nist.gov/…/rbac1.html. Далее я объясню основные концепции модели RBAC и покажу ее отличие от других моделей управления доступом. Мы рассмотрим, как Microsoft использует Authorization Manager для реализации принципов модели RBAC.
Модель RBAC
До 1992 года большинство платформ и поддерживаемых ими приложений использовали либо модель принудительного управления доступом (mandatory access control, MAC), либо модель с управлением доступом по усмотрению пользователя (discretionary access control, DAC). Две модели описаны в документе Trusted Computer Security Evaluation Criteria (TCSEC), который опубликовало для использования Министерство обороны США в 1985 году. Из этих двух моделей более общая — DAC — используется во многих коммерческих операционных системах, включая Windows 2000 Server и Windows NT.
В модели DAC управление доступом к ресурсам остается на усмотрение пользователей. Такой децентрализованный подход позволяет предоставлять или отменять доступ к любому объекту и ресурсу, которые находятся под непосредственным управлением пользователя (т.е. пользователь является собственником объекта или ресурса). Таким образом, в этой модели пользователь управляет доступом к объектам и ресурсам без участия системного администратора.
Модель MAC представляет более централизованный подход к управлению доступом. В этой модели полномочия и разрешения доступа к ресурсам предоставляются и удаляются централизованно. Такое управление обеспечивает каждому объекту свой индивидуальный уровень разрешений и маркирует ресурсы в соответствии с уровнем доступа в соответствии с установленным для них уровнем авторизации. Структуры, в которых головному предприятию необходимо запретить неконтролируемый информационный поток от организаций высшего уровня к организациям низшего уровня, часто используют такой тип централизованного контроля доступа. Поскольку Microsoft пока не обеспечила какого-либо коммерческого варианта поддержки MAC -модели, мы ограничимся сравнением моделей RBAC и DAC. Отличия RBAC и DAC-моделей перечислены в Таблице 1.
Таблица 1: Сравнение моделей DAC и RBAC.
|
DAC |
RBAC |
|
|
Ориентация |
Ориентирована на объекты и ресурсы |
Ориентирована на организационные роли |
|
Хранение политик управления доступом |
Децентрализованное |
Централизованное |
|
Административная модель |
Затруднения при отображении на административную модель управления доступом |
Относительно легко отображается на административную модель управления доступом |
Ключевой компонент модели RBAC — организационная роль пользователя, которая определяет его обязанности, возможности и ограничения. DAC-модель ориентирована в основном на ресурсы и объекты. С административной точки зрения, управление контролем доступа, основанное непосредственно на ролях, более естественно. Трансляция организационной модели (основанной на ролях пользователей) в объектно-центрическую (основанную на правах доступа к ресурсам) представляет для администраторов, работающих по модели DAC, более сложную задачу.
Модель RBAC — специальный тип группы управления доступом; она связана с набором задач, которые пользователь или группа пользователей могут выполнять в рамках конкретной организации. Однако роль существенно отличается от группы. Группы, как мы их представляем в модели DAC, облегчают управление контролем доступа на уровне ресурса, позволяя задать и поддерживать управление доступом для групп, а не для отдельных пользователей. Роль, напротив, подразумевает набор разрешений на доступ к ресурсу, которые основаны на определениях роли (т.е. отношениях роли к поставленной задаче и отношениях роли к операции, которую нужно выполнить). Чтобы определить те задачи или операции, которые пользователь имеет право выполнить, достаточно знать только роль пользователя. Узнавать о наличии разрешения на доступ к различным ресурсам во время обращения к ним, как в модели DAC, не требуется.
Подтверждение и проверка присвоенных разрешений доступа и принудительное их применение — другая область, в которой модели DAC и RBAC имеют существенные различия. В модели RBAC приложение, поддерживающее роли, осуществляет запрос к базе данных политик RBAC или к связанной с ней службе управления доступом, выясняя, имеет ли пользователь права на выполнение данного действия. В модели DAC децентрализованное подтверждение доступа и проверка разрешений доступа к ресурсу происходит на уровне DAC-ориентированного приложения или самого ресурса. Например, в Windows NT сущность объекта «локальный компьютер», известная как монитор ссылок security reference monitor (SRM), сравнивает содержимое маркеров доступа пользователя со списком контроля доступа объекта (ACL), чтобы определить, имеет ли пользователь права доступа к выбранному объекту.
Централизованное подтверждение и контроль разрешений доступа — существенное преимущество, потому что в большинстве организаций ресурсы и защищаемые информационные объекты поддерживают политику безопасности, которая обычно определяется на самом высоком уровне организации. Поддержка такой политики требует от информационной системы способности централизованно управлять и контролировать права доступа. Можно утверждать, что модель RBAC более полно соответствует административной модели, которую большинство компаний использует для управления доступом к ресурсам и управления контролем доступа к приложениям:
Администратор безопасности ответственен за разработку и применение центральной политики управления доступом. В модели RBAC пользователи не могут передать права на доступ к объектам другим пользователям по своему усмотрению, как в модели DAC.
В модели RBAC для понятий «ресурс» и «приложение» администраторы определяют роли в терминах «приложение», «операция с ресурсом» и «задача». Они передают эту информацию администратору безопасности, который гарантирует, что соответствующая связка роль-операция или роль-задача будут сохранены в базе данных политик управления доступом. Администраторам нет необходимости устанавливать соответствующие ACL на отдельных ресурсах, как это делается при использовании модели DAC.
Хорошим примером приложения, использующего модель RBAC, может служить приложение запроса бюджета и его утверждения. В таком приложении вы обычно определяете роль пользователя и роль руководителя. Члены роли пользователей имеют разрешение создать требование на бюджет в базе данных расходов. Каждый пользователь имеет атрибут руководителя, который связывает пользователя с ролью руководителя, подтверждающего операцию. Членам роли руководителя разрешается изменять только атрибут подтверждения расхода ресурсов для пользователей, с которыми они связаны и которыми они управляют.
Архитектура Windows 2003 RBAC
Прежде чем начать разговор об архитектуре RBAC в Windows 2003, следовало бы упомянуть, что RBAC не является новинкой для операционных систем и приложений Microsoft. Так, например, понятия пользователя и групп ресурсов применялись еще в самых ранних версиях NT, обеспечивая похожую на роли функциональность. Кроме того, структура разработки модели COM использует концепцию специфической для приложения роли, подобно тому, как Windows 2003 задействует модель RBAC. Ключевое различие состоит в том, что вы можете использовать роли общей объектной модели только в приложениях, которые задействуют для записи общую объектную модель и ее продолжение COM+. В Windows 2003 модель RBAC не зависит от типа разработки общей объектной модели. Таким образом, вы можете применять различные варианты общей объектной модели: COM, COM+ или Windows.NET Framework.
Обратите внимание, что модель RBAC, представленная в Windows 2003, не будет заменять все модели DAC, существующие в настоящее время для приложений Windows. Модели RBAC и DAC могут легко сосуществовать. Однако в определенный момент Microsoft, возможно, интегрирует некоторые из моделей DAC в модель RBAC или даже полностью переместит приложения в модель RBAC
На Рисунке 1 показана текущая архитектура модели RBAC Windows 2003 и ее главные компоненты. Менеджер авторизации (Authorization Manager) является механизмом управления и принятия решений в RBAC-системе. Здесь показано, что вся RBAC информация должным образом сохранена в базе данных политик (policy database) и позволяет запросу из приложения и администраторам управлять политикой доступа к базе данных.
Приложения с поддержкой RBAC в процессе работы делают запросы менеджеру авторизации Authorization Manager, чтобы узнать, имеет ли определенный пользователь право исполнить некоторую операцию на уровне приложения. Authorization Manager дает разрешение продолжать операцию, основываясь на членстве пользователя в определенной роли. Для приложения разрешение дается на основе информации о связке операция-роль или задача-роль, хранящейся в базе данных политик. В модели DAC решения о возможности доступа принимает локальный менеджер ресурсов на хост-машине. RBAC-ориентированные приложения обращаются во время работы к менеджеру авторизации через набор интерфейсов, основанных на технологиях COM, показанных на Рисунке 1 как Authorization API (AuthzAPI).
Вы можете сохранить централизованную базу данных политики доступа менеджера авторизации в ActiveDirectry или в XML-файле. Чтобы использовать AD как хранилище базы политик управления доступом, необходимо перевести Windows 2003 на однородный функциональный уровень (Native). Лучше использовать AD, потому что AD позволяет делегировать администрирование политик управления доступом и их компонентов другим администраторам. Хранилище информации по авторизации, основанное на AD, по умолчанию размещается в контейнере Program Data в контексте именования домена AD. Следовательно, хранилище копируется на каждый контроллер домена.
Первичный интерфейс администрирования — оснастка MMC Authorization Manager, показанная на Рисунке 2. Консоль Authorization Manager поддерживает два режима: режим разработчика и режим администратора. В более ограниченном режиме администратора пользователи могут сделать все, что могут делать разработчики, кроме создания новых приложений Authorization Manager, операций, изменения операций, имен приложений или информации о версии. Для переключения между режимами нажмите Action, Options в консоли Authorization Manager.
Возможно, самый важный аспект в использовании модели RBAC в реализации Microsoft состоит в том, что она позволяет реализовать гибкие решения управления доступом. Администраторы могут применить политику управления доступом к специфическому объекту-приложению или операции (например, отправка почтового сообщения, подтверждение расходов). В модели DAC вы используете заданные разрешения управления доступом и применяете политику управления доступом к заранее определенным объектам, например к объектам файловой системы, объектам системного реестра и объектам баз данных.
Далее рассмотрим особенности Authorization Manager, позволяющие легко изменять поведение политики управления доступом во время ее применения к определенным объектам:
- менеджер авторизации поддерживает динамические группы, членство в которых может изменяться в зависимости от результатов запросов к каталогу Lightweight Directory Access Protocol (LDAP), которые генерирует приложение во время работы. Например, приложение взаимодействия с партнерами CRM, поддерживающее роли, может автоматически посылать почтовые сообщения членам динамической группы Customer. Можно определять членство в группе Customers по результатам выполнения запроса LDAP, который приложение создает для базы данных каталога, содержащего данные клиентов.
- менеджер авторизации поддерживает сценарии авторизации, которые выполняются во время работы приложения и предоставляют разрешения на доступ к данным, например, в зависимости от времени дня, валюты и типа значений. В случае приложений электронной коммерции, например, можно блокировать заказы определенных изделий в течение некоторых периодов дня или года. В качестве примера, приложение могло бы разрешить доступ к разделу Рождественских елок в каталоге продуктов только в декабре.
- менеджер авторизации поддерживает детализированный аудит во время работы приложений. Менеджер авторизации проводит аудит удачной или неудачной инициализации приложений, инициализации клиентского контекста и попыток удаления и все попытки доступа. Администраторы могут использовать аудит на уровне базы данных политик в AD или базы политик в виде файла XML.
Благодаря этим особенностям модель управления доступом через менеджер авторизации хорошо сочетается с бизнес-приложениями, такими как CRM-приложения или приложения электронной коммерции, о которых я упоминал ранее. В таких приложениях, решения для управления доступом часто зависят от определенной деловой логики, которая использует специальные операции или зависит от логики технологического процесса. Бизнес-приложения могли бы включать в алгоритм своей работы запросы к каталогу или ожидания почтового сообщения от менеджера, подтверждающего правомерность выполнения операции. Напротив, в модели DAC решения о предоставлении доступа основываются исключительно на членстве в группе и пользовательских разрешениях, содержащихся в маркере доступа пользователя.
Концепции менеджера авторизации
База данных политик авторизации менеджера авторизации включает в себя один или более наборов следующих типов объектов: приложения, группы, роли, задачи, области и Bizrules. База данных политик может содержать политики управления доступом для множества приложений. Например, на Рисунке 3 показана база политик, содержащая Web-приложение управления расходами (Expense Web App) и Web-клиент этого приложения (Customers Leads Web App).
Можно назначить пользователям и группам Windows или специальным группам менеджера авторизации необходимые роли. Пользователи и группы Windows имеют SID и существуют в базе данных безопасности Windows (SAM или AD). Специальные группы менеджера авторизации, известные также как группы приложений (application groups) не имеют SID и существуют только в пределах контекста базы данных менеджера авторизации, приложения или области приложения. Так, на Рисунке 3 показан контейнер Groups в базе данных на уровне политик AD_AuthPolicyStore, контейнера приложения и наборов. Набор — это список объектов в пределах политики управления доступом к приложению.
Существует два типа групп приложения: основной и на LDAP-запросе. Основные группы приложения имеют атрибут членства и нечленства в группе. Атрибут нечленства позволяет запрещать доступ, подобно праву Deny access, которое используется при разграничении доступа к объектам AD или файловым ресурсам. Атрибуты членства и нечленства могут быть присвоены как пользователям и группам Windows, так и другим группам приложений. Группы приложений, базирующиеся на запросах к LDAP, могут обеспечить динамическое членство в группах, зависящее от результатов запроса к LDAP, который посылает приложение во время работы.
Мы определили роли менеджера авторизации в терминах операций и задач. Операция — это низкоуровневая процедура, которая обычно имеет значение для менеджера ресурса. В качестве примеров операций можно привести следующие: »
Прочитать квоту расхода пользователя» или »
Записать пользовательский пароль«. Операции описываются на уровне приложения и идентифицируются номером операции, который должен быть целым числом.
Задача — это набор операций, значение которых важно для администратора приложения (например, «одобрить расход», «подтвердить расход»). Вы можете определить задачи как на уровне приложения, так и на уровнях набора.
Менеджер авторизации поддерживает создание иерархической структуры ролей и их наследование. Во время определения роли менеджер авторизации позволяет определить роль низшего уровня, от которой вновь создаваемая роль будет наследовать все связанные с ней задачи и операции.
Чтобы сделать процесс авторизации более динамическим, менеджер авторизации позволяет связывать сценарии авторизации (или как их называют в Microsoft, Bizrules) и задачи. Менеджер авторизации анализирует Bizrules во время их выполнения, чтобы изменять предоставляемую информацию в реальном времени в зависимости от времени дня, валюты или заданных пороговых значений параметров. Вы можете создавать Bizrules в VBScript или в Jscript, и сохранять их в базе данных политик, наряду с другой информацией из политики.
Также вы можете использовать менеджера авторизации набора, чтобы более точно настроить политику управления доступом к приложению. Указать набор так же просто, как путь в файловой системе (для приложений, базирующихся на файловой системе), контейнер AD (для приложений, основывающихся на AD) или URL (для Web-приложений). На Рисунке 3 изображены два набора, определенные в контейнере приложения Expense Web App: один для обработки коммерческих расходов подразделения (Sales Dept Expenses) и другой — для обработки расходов на управление (Executive Expenses).
Сценарии развертывания
Менеджер авторизации открывает много новых интересных возможностей, связанных с созданием сценариев развертывания приложений. Посмотрим, как менеджер авторизации может усовершенствовать защиту многоуровневых приложений, которые используются архитектурной моделью доверенных приложений (trusted application architectural model).
Существует две архитектурных модели для многоуровневых приложений — модель имитации/делегирования и модель доверенных приложений. Windows 2003 содержит расширения для обеих моделей. Наиболее значимы два расширения Kerberos для имитации/делегирования: ограниченное делегирование и смена протокола.
В модели имитации/делегирования приложение промежуточного слоя (обычно приложение Web-сервера) может выполнять одну из следующих операций.
- Генерация маркера имитации (impersonation token), который отражает данные о разрешениях доступа пользователя и применение этого маркера для обращения пользователя к нужным ресурсам.
- Отправление маркера доступа к требуемому ресурсу. Этот процесс называется делегированием и выполняется только в случае использования протокола Kerberos. Применение авторизационного протокола Kerberos также разрешает многоуровневое делегирование.
Концепция, стоящая за моделью имитации/делегирования, состоит в том, что имитатор объекта «пользователь» выходит за пределы промежуточного слоя и устанавливает параметры настройки управления доступом на конечных ресурсах, имитируя учетные данные пользователя. В модели доверенных приложений имитация пользователя не выходит за рамки промежуточного слоя. В этой модели для доступа к оконечным ресурсам используется служебная учетная запись Web-сервера или Web-приложения.
Интегрирование менеджера авторизации в модель доверенных приложений позволяет принудительно присваивать разрешения на основании ролей и предоставляет возможности детального аудита на уровне Web-приложений в реальном времени. Но интеграция не отменяет преимуществ модели доверенных приложений, таких как:
- Более простое управление доступом на конечном ресурсе и серверах приложений. Вы можете использовать одну учетную запись (служебную учетную запись Web-сервера или Web-приложения) для настройки всех параметров управления доступом.
- Поддержка пула подключений. Пул обеспечивает более высокий уровень масштабируемости, но это возможно только если все подключения с оконечной инфраструктурой работают в том же пользовательском контексте защиты. Пул подключений в модели имитации\делегирования не имеет большого значения, поскольку каждое соединение запускается в различных пользовательских контекстах защиты (в контексте имитированного или делегируемого пользователя).
- Управляемая точка доступа. В модели доверенных приложений доступ ко всем оконечным ресурсам происходит через Web-интерфейс. Пользователи не могут задействовать другие каналы для доступа к оконечным ресурсам (при условии, что соответствующие списки доступа к ресурсам (ACL) находятся на самих этих ресурсах).
На Рисунке 4 показаны различия между моделью имитации\делегирования и моделью доверенных приложений с менеджером авторизации.
Перспективы развития менеджера авторизации и модели RBAC
[LEFT]Windows 2003 позволяет задействовать менеджер авторизации и модель RBAC для работы с бизнес-приложениями, в которых используются роли. Однако, за исключением Microsoft Internet Information Services (IIS) 6.0, имеющего возможность авторизации, основанной на URL, Microsoft не обеспечивает приложениям поддержку ролей без определенной доработки этих приложений. Менеджер авторизации более полезен разработчикам, чем администраторам. Однако положение дел со временем может измениться. А до тех пор вы можете использовать программное обеспечение типа ActiveRoles от FastLane для ролевого управления в AD и других задач. FastLane ActiveRoles обеспечивает поддержку модели RBAC на вершине модели DAC. Более подробную информацию об этом программном обеспечении можно найти в документации на
http://www.quest.com/fastlane/activeroles.
Источник: http://www.oszone.ru
Автор: Жан де Клерк
Иcточник: OSP.ru
Оцените статью: Голосов
Provide feedback
Saved searches
Use saved searches to filter your results more quickly
Sign up
Время на прочтение4 мин
Количество просмотров7.8K
Всем привет!
Про принципы работы Role Based Access Control (он же RBAC) слышали многие. Но реальное применение встречается довольно редко. Меня зовут Корняков Дмитрий, более 6 лет занимаюсь поддержкой инфраструктуры в команде Мир Plat.Form (НСПК). В статье расскажу про предпосылки создания, практическую реализацию и профит, который мы получили от ролевого доступа к ОС на инфраструктуре из 5000+ серверов в десятке доменов в разных ЦОД под управлением FreeIPA и Active Directory.
«Да что тут рассказывать – ещё на начальных курсах по админству про ролевую модель предоставления доступа рассказывают, и все всё знают» (с) Аноним
Когда-то мы использовали дискреционную модель выдачи прав (Discretionary Access Control, DAC). Она простая и эффективная при небольшом количестве серверов и администраторов, но имеет ряд недостатков, и самые существенные из них, напрямую влияющие на решение наших задач, ниже:
-
Накопление огромного количества правил;
-
Неочевидно, кто какие права имеет в моменте;
-
Администраторам систем приходится где-то хранить информацию, какие куда нужны права. Эта информация устаревает/теряется/etc;
-
Выход нового сотрудника/появление нового сервера может повлечь множество заявок на доступ, если с первого раза не заказали всё правильно;
-
Автоматизация выдачи прав при таком подходе выглядит утопией.
Например, на один сервер есть более 10 правил доступа, а серверов в информационной системе — 100. Приходит кто-то и просит выгрузить список администраторов. Проводим нехитрые подсчеты и получаем ужасающую цифру — вам придётся посмотреть 1000 правил. Да, можно что-то заскриптовать и что-то автоматизировать. Но автоматизация не решит таких вопросов, как выделение админов – ведь на сервер могут иметь права прикладные администраторы, ДБА, информационная безопасность. И у всех разные права вполне возможно, что разные они даже внутри одного подразделения.
А аудиторы могут попросить показать права из интерфейса системы, со скриншотами – представляете, если минимум сущностей, то уже выходит на 1000 скринов. Аудитору едва ли понятно, что делает скрипт, а объемы документации могут стать поводом посмотреть в сторону эффективности процессов в компании. Если вы не можете быстро и наглядно выяснить, у кого какие права — это уже звоночек.
Немного подробнее про DAC и сущности в правах
Active Directory — группа пользователей через доменную политику прилетает
на серверы в группы RDP доступа или LocalAdmin
FreeIPA – в линуксах добавляются:
-
Правила HBAC – каким сервисом можно войти на сервер — sshd/vsftpd/mysql/crond/etc;
-
Правила Sudo – какие команды под какими пользователями можно выполнять.
Дискреционная модель выдачи прав – это когда мы всегда выдаём ровно то, что просят. И выдаём, по большому счёту, не разбираясь, какие права уже есть.
Например, у нас есть команда из 3-х человек, у них есть 3 сервера. И набор правил, который описывает уровень доступа:
Появляется ещё один человек в команде, прилетает заявка на доступ, одному человеку на три сервера. Да кто разбираться будет, что там за правила есть, запилим новые!
Появляется 4-й сервер. Ну вы поняли:
А по пути можно заказать не все права, и какие-то из шагов выше могут повториться по нескольку раз. Сущности копятся лавинообразно.
Ролевая модель выдачи прав — это когда роли доступа к серверам предопределяются заранее.
Группа пользователей в таком случае выступает ролью и имеет чётко определённый набор прав. А предоставление прав — это всегда включение пользователя в предопределённую группу. И если подходящей группы нет, она создаётся совместно с функциональным администратором системы, а потом наполняется пользователями.
В таком случае каркас правил минимален и сущности не плодятся.
На примере правил FreeIPA:
Имя роли добавляется в поле “Описание” группы пользователей, для примера выше это CRM-WebDC-ПРОД_Администратор. “Человеческое” имя роли пригодится для последующего заказа в Service Desk, построения отчётов, понятного разграничения прав и т.д. Можно исходить из базового набора, например:
-
CRM-WebDC-ПРОД_Администратор
-
CRM-WebDC-ПРОД_Пользователь_БД
-
CRM-WebDC-ПРОД_Администратор_ИБ
-
И т.д.
Видно, что сущности для ролей переиспользуются, и по имени можно понять, что к чему относится:
Чтобы не скатиться обратно в дискреционную модель, нужно ввести ряд ограничений:
-
Одному пользователю можно назначить неограниченное количество ролей;
-
Один сервер может быть только в одной группе хостов, если нужно иное — оно вам не нужно, дробите группу серверов на две/три/etc;
-
В момент перехода на RBAC сервер удаляется из всех остальных групп доступа/правил.
Если в процессе эксплуатации системы вы понимаете, что появились люди, которым нужен доступ только на половину серверов из группы, значит вы пилите группу на две и увеличиваете гранулярность предоставления прав, создав новую роль. Также не должно возникать ситуации, когда вы даёте на сервер права и по RBAC, и дискретно.
А имея структурированные имена сущностей, их легко выгружать – раз в день любимым скриптовым языком парсите и отправляете в CMDB/WIKI/и т.д. Мы вот такую страничку сделали. Тут можно смотреть дифф с предыдущими состояниями, экспортировать и т.д.
Автоматизация с DevOPS
И вроде всё неплохо, но в процессе мы поняли, что такая история не работает со стендами разработки. Люди и серверы перемещаются между проектами, а права нужны вчера — по заявкам долго.
Да и состояние проектов у ребят описано в гите, и права назначаются через CI. Это отдельная история, подробнее можно почитать в статье тут.
Что мы сделали: примерно тот же формат именования, не всегда разделяем стенды на системы. А главное – мы дали права на предоставление ролей техучётке, которая вшита в CI.
Меняется описание проекта, добавляются пользователи – CI назначает им описанные роли.
Для этого во FreeIPA есть отличный механизм кастомных разрешений на права внутри каталога, о котором не все знают. Т.е. можно дать права ТУЗ управлять строго определённой группой пользователей. Вкладки RBAC -> Privileges, где даём нужные права на нужный DN.
Ниже пример Permission Settings “Разрешения”:
Это заняло порядочное количество времени, но мы не гнались. Для каждой системы нужно было рассказать что да как функциональным админам, выгрузить текущие права, определить на их основе роли. В итоге сейчас у нас на RBAC:
-
> 100 ИС, 3K серверов, 750 ролей;
-
Учёт всех ролей;
-
Особые права для команд разработки.
И всё чётко и структурировано. Теперь у нас есть набор кирпичиков, на основе которых можно развивать автоматизацию. От автоматического исполнения заявок на предоставление прав до триггерного изменения прав, например, при выходе/увольнении/переводе между подразделениями сотрудников, над чем мы сейчас и работаем.
Большая автоматизация начинается с маленьких кирпичиков, всем стабильной и прозрачной инфраструктуры!
Role Based Access Control (RBAC)
is a permissions model introduced by Exchange Server 2010 that enables you to align
the roles you assign to users and administrators to the roles they hold within your
organization. RBAC controls the administrative tasks that can be performed and the
extent to which users can administer their own mailbox and distribution
groups.
1. Implementing RBAC
With RBAC, you do not need modify and manage access control lists (ACLs) on
Exchange Server or Active Directory Domain Services (AD DS) objects. In Exchange
Server 2010, RBAC controls the administrative tasks that users can perform and
the extent to which they can administer their own mailbox and distribution
groups. When you configure RBAC permissions, you can define which Exchange
Management Shell (EMS) cmdlets a user can run and which objects the user can
modify.
RBAC assigns permissions to users in your organization depending on whether a
user is an administrator or an end user. RBAC associates users with the
permissions they need to perform their jobs. It does this using management role
groups and management role assignment policies. The 70-662 examination focuses
on management role groups, which are therefore covered in detail in this lesson.
The following summarizes these methods:
-
Management role groups
RBAC uses management role groups to assign administrator
permissions. Administrators may need to manage an entire Exchange
Server 2010 organization or merely part of it. Some administrators,
for example, may require limited permissions to manage specific
features, such as compliance or specific recipients. Such
administrators, with limited permissions, are often termed
“specialist users.” You use management role groups by
adding users to a built-in role group or to a custom role group.
RBAC assigns each role group one or more management roles that
define the permissions that RBAC grants to the group.
-
Management role assignment
policies
You use management role
assignment policies to assign end-user management roles. Role
assignment policies consist of roles that control what users can do
with their mailboxes or distribution groups. These roles do not
allow the management of features not associated directly with an
individual user or universal security group.
2. Using Management Role Groups
RBAC uses management role groups, which associate
management roles with groups. Administrators manage the Exchange organization
and recipient configuration. Specialist users manage specific Exchange features,
such as compliance, or support the Help desk function but do not have full
administrative rights. Role groups are associated with administrative management
roles that enable administrators and specialist users to manage the
configuration of their organization and recipients. You can assign permissions
to administrators or specialist users by adding them to or removing them from
role groups.
The management role group method consists of the following underlying
components that define how RBAC assigns permissions:
-
Role holder
A role holder is a mailbox that you assign to
a role group. When a mailbox becomes a role group member, RBAC
grants it all of the permissions that the management roles provide.
To assign a mailbox to a role group, you either add the user account
to the group in AD DS or use the
Add-RoleGroupMember cmdlet in the EMS. Note
that both role group members and role group delegates are role
holders. The difference between members and delegates is explained
later in this lesson.
-
Management role group
A management role group is a universal security group to which one
or more management roles have been assigned. It is created using
Exchange Server 2010 tools but is nevertheless an AD DS object, and
a domain administrator can configure its membership using the Active
Directory Users and Computers console on a domain controller. It can
contain mailboxes, users, other universal security groups, and other
role groups. You add and remove members to management role groups,
and you assign management roles to management role groups. The
combination of all the roles assigned to a role group defines
everything that members of that role group can manage in the
Exchange organization.
-
Management role
A management role is a container that holds a
group of management role entries, which define the specific tasks
that the members of a role group can perform. RBAC assigns
management roles to the role group and hence to its members using
management role assignment.
-
Management role entry
A management role entry is an EMS cmdlet
(including parameters), script, or special permission that you can
add to a management role. By adding, for example, a cmdlet to a
management role as a management role entry, you grant members of
role groups to which that role is assigned the right to view and
manage Exchange objects associated with that cmdlet.
-
Management role
assignment
A
management role assignment assigns a role
to a role group. To grant members of a role group the ability to use
the cmdlets and parameters defined in the role, you assign the role
to the role group. When you create a management role, you need to
assign it to a role group so that role group members become role
holders and can use the permissions granted by the role. (For
example, they can use the cmdlets defined by the management role
entries.) Role assignments can use management role scopes to control
where the assignment can be used.
-
Management role scope
When you assign a role with a management role
scope to a role group, the scope defines the objects
that the assignment is permitted to manage. The assignment and its
scope are applied to the members of the role group and define what
those members can manage. A scope can consist of servers, OUs, or
filters on server or recipient objects. Management role scopes are
sometimes known as scopes of influence or
scopes of impact.
Roles, role assignments, and role groups can be managed by administrators who
have been assigned the Role Management management role. Assignees of a specific
management role who have delegating role assignments can assign the role to
other users. When you add a user to a role group, that user is given all the
roles assigned to the role group. If scopes are applied to any of the role
assignments, those scopes control what server configuration or recipients the
user can manage.
If the role assignments built into Exchange Server 2010 roles do not suit your
needs and you want to define which roles are assigned to a role group, you
change the role assignments that link the role group to roles. Typically, the
defaults are sensible, and you do not need to reconfigure them. You can,
however, create a new management role based on an existing built-in role and
change the role assignments for the new role. The procedure to do this is
described later in this lesson.
One or more administrators or specialized users can be members of a role
group. An administrator or specialized user can be a member of more than one
role group. A role group can be assigned one or more role assignments. These
link the role group with one or more administrative roles that define what tasks
can be performed. Role assignments can contain management scopes that define
where the users of the role group can perform actions.
2.1. Built-In Management Role Groups
Exchange Server 2010 offers several built-in role groups that provide
different levels of administrative permissions to user groups. You can add
users to or remove them from any built-in role group. You also can add role
assignments to or remove them from most of these role groups. Table 1 lists and describes the built-in role
groups.
Table 1. Built-In Role Groups
Role Group |
Description |
|---|---|
Delegated Setup |
Role holders can deploy Exchange Server 2010 servers that have been previously provisioned. |
Discovery Management |
Role holders can search mailboxes in the Exchange organization for data that meets specific criteria. |
UM Management |
Role holders can manage Unified Messaging features within an Exchange organization, such as Unified Messaging server configuration, properties on mailboxes, prompts, and auto-attendant configuration. |
Help Desk |
Role holders can perform limited recipient management. For example, this might include managing a user’s display name, address, phone number, and so on. |
Organization Management |
Role holders can perform (almost) any task against any Exchange Server object. This role group provides access to the entire Exchange Server 2010 organization. |
Public Folder Management |
Role holders can manage public folders and databases on Exchange Server 2010 servers. |
Recipient Management |
Role holders can create or modify recipients within the Exchange organization. |
Records Management |
Role holders can configure compliance features, which could include retention policy tags, message classifications, transport rules, and so on. |
|
Server Management |
Role holders can perform Exchange server configuration. They cannot, however, administer recipient configuration. |
View-Only Organization Management |
Role holders can view the properties of any object in the Exchange organization. |
All the built-in management role groups are located in the Microsoft
Exchange Security Groups OU in AD DS. This OU contains several other
universal security groups that grant permissions to the Exchange server
computer accounts. The contents of this OU are shown in Figure 1.
Figure 1. The Microsoft Exchange Security Groups OU
You then use the
Exchange Management Console (EMC) to verify that Don Hall can modify mailbox
settings and create a distribution group but cannot create a mailbox
database.
You can also use the Set-user cmdlet in the EMS
to set user parameters that grant specified privileges. Note that this
is not RBAC and is not the same as assigning a role to a user. It is a
procedure that configures user properties on the basis of the limited
set of parameters associated with the Set-User
cmdlet. For example, the following command enables Don Hall to run
remote PowerShell cmdlets:
Set-User -Identity "Don Hall" -RemotePowerShellEnabled $True
You
can use the Get-User cmdlet to confirm your
settings. The following command lists the configuration for the user Don
Hall:
Get-User -Identity "Don Hall" | FL
Figure 2 shows the
first of these commands and some of the output from the second.
Figure 2. Setting a user permission and checking that it has been
applied
2.2. Creating a Custom Role Group
In addition to using built-in role groups, you can create custom role
groups to delegate specific permissions in an Exchange organization. You
would do this if none of the built-in role groups offered the management
roles and associated permissions you require. When you create a custom role
group, you can assign management roles to the group. You can assign built-in
management roles, but you also have the option of creating new management
roles and adding them retrospectively. You also need to identify the
management scope for any management role you assign or add. If you want to,
you can change the scope of role assignments in a role group
retrospectively.
You use the
New-RoleGroup cmdlet in the EMS to create a role
group. You need to know the management roles you want to assign to the role
initially, and you need to add at least one management role and at least one
member. For example, the following command creates a role group called
Transport Role Group that is assigned to the Transport Rules management
role. The role group is assigned to Kim Akers and Don Hall and can be
managed by Kim Akers. The role group (which is also a universal security
group) is created in the Exchange Security Groups AD DS container:
New-RoleGroup -Name "Transport Role Group" -Roles "Transport Rules" -Members "Kim
Akers", "Don Hall" -ManagedBy "Kim Akers"
Figure 3 shows the output of this
command.
Figure 3. Creating a role group
The following command creates a role group called Melbourne Compliance
Group that is assigned the Transport Rules and Journaling management roles
and uses the Melbourne Recipients recipient scope:
New-RoleGroup -Name "Melbourne Compliance Group" -Roles "Transport Rules", "Journaling"
-CustomRecipientWriteScope "Melbourne Recipients"
The Address Lists management role enables administrators to create,
modify, view, and remove address lists, global address lists, and
offline address books in an organization. There is no built-in
management role group for address list management, but it is a good idea
to create a custom role group whose members can perform this function.
To do this, you would enter the following in the EMS:
New-RoleGroup -Name "Address Lists Management " -Roles "Address Lists"
2.3. Adding a Role to a Role Group
To add a role to a role group, you
create a role assignment. You can create a role assignment with no scope,
with a predefined scope, with a recipient filter-based scope, with a
configuration filter-based scope, or with an OU scope. The following command
assigns the transport rules management role to the Glasgow Recipient Admins
role group and scopes the assignment to the Marketing OU in the Adatum.com
domain:
New-ManagementRoleAssignment -Name "Transport_Rules_Glasgow_Recipient_
Admins" -SecurityGroup "Glasgow Recipient Admins" -Role "Transport Rules"
-RecipientOrganizationalUnitScope Adatum.com/Marketing
Figure 6-4 shows the
result of this command.
Figure 4. Adding the Transport Rules management role to the Glasgow Recipient
Admins role group
As an alternative to using a scope, you can set a condition that ensures
that the rights conferred by the role can be applied only to accounts
located in a specific OU in a specific domain. For example, the following
command assigns the Transport Rules role to the Brisbane Recipient Admins
group but limits its use to accounts in the Marketing OU in the Brisbane
.Adatum.com domain:
New-ManagementRoleAssignment -Name "Transport_Rules_Brisbane" -SecurityGroup "Brisbane
Recipient Admins" -Role "Transport Rules" -DomainOrganizationUnitRestriction Brisbane
.Adatum.com/Marketing
You also can use direct role
assignment to assign permissions. This assigns management roles directly
to a user without using a role group or role assignment policy. Direct
role assignments can be used when you need to provide a granular set of
permissions to a specific user. You can create a role assignment
directly between a user or universal security group and one or more
roles. The role defines what tasks the user can perform. Role
assignments can contain management scopes that define where the user can
perform actions. For example, the following command assigns the
Transport Rules role directly to the user Don Hall and limits its use to
accounts in the Sales OU in the Adatum.com domain:
New-ManagementRoleAssignment -Name "Transport_Rules_Don" -Role "Transport
Rules" -User "Don Hall" -DomainOrganizationUnitRestriction Adatum.com/
Sales
However, Microsoft recommends that you avoid using direct role
assignment because it is significantly more complicated to configure and
manage. If a user leaves the organization, for example, you need to
manually remove the user’s assignments and add them to his or her
replacement. If you have used ACLs to assign permissions, you know that
it is not a good idea to assign permissions directly to users but that
you should instead assign them to security groups and place users in
these groups. The same is true of RBAC. You should assign roles to role
groups, not to individual users.
2.4. Creating a New Management Role
If none of the built-in management roles meet your needs, you can create a
new management role and add it to your custom role group. You use the
New-ManagementRole cmdlet in the EMS to create a
custom management role based on one of the existing management roles. For
example, the following command creates the management role MyManagementRole
based on the Journaling built-in role:
New-ManagementRole -Name MyManagementRole -Parent Journaling
By default, the new
management role inherits all the permissions assigned to the parent role.
Note that a new management role must be based on a current management role
and that the -Parent parameter is mandatory. To remove permissions from the
role, you first obtain the permission you want to remove by using the
Get-ManagementRole EMS cmdlet with a filter (Where)
condition and then pipe this permission into the
Remove-ManagementRoleEntry cmdlet to remove it. For
example, the following command removes a Journaling permission from the
MyManagementRole role:
Get-ManagementRoleEntry -Identity "MyManagementRole\*" | Where {$_.Name -NotLike "Get*"}
| Remove-ManagementRoleEntry
You can also use the Get-ManagementRoleEntry cmdlet
more generally to determine which management role entries have been assigned
to a specific custom management role. For example, the following command
lists the management role entries assigned to the MyManagementRole
role:
Get-ManagementRoleEntry -Identity "MyManagementRole\*"
You can use the Add-ManagementRoleEntry cmdlet to add
management role entries to an existing management role. For example, the
following command adds a new role entry for the
Set-Mailbox cmdlet to the MyManagementRole
management role. The role entry for the Set-Mailbox
cmdlet is added exactly as it is configured in the Journaling parent
role:
Add-ManagementRoleEntry "MyManagementRole\Set-Mailbox"
Creating a new management role, removing unnecessary management role
entries, and adding role entries can be a complex procedure. Microsoft
recommends that you use an existing role rather than create a new one
whenever possible
Note:
NEW-MANAGEMENTROLEENTRY
The New-ManagementRoleEntry cmdlet is used to add
scripts and non-Exchange cmdlets to existing top-level management roles.
The scripts and cmdlets can then be used by the top-level role entries
or any roles derived from the top-level roles. This, however, is beyond
the scope of the 70-662 examination.
2.5. Adding Members to a Role Group
To give a user the permissions that are granted by a role group, you need
to add the user’s mailbox as a member of the role group. You do this
by using the Add-RoleGroupMember cmdlet in the EMS. You
can also add members to a role group (as you can to any other security
group) by using the Active Directory Users and Computers console, but you
need to have domain administrator privileges (or equivalent) to use the AD
DS tool.
For example, the following command adds the mailbox Don Hall to the
Recipient Management role group (remember that you can also perform this
operation by using the Active Directory Users and Computers console):
Add-RoleGroupMember -Identity "Recipient Management" -Member "Don Hall"
2.6. Adding or Removing a Role Group Delegate
Management role group delegates are users or universal security groups
that are members of the role group and can manage the role group. Adding or
removing role group members or delegates to and from a role group rather
than assigning roles directly to users or universal security groups is the
recommended method of controlling who is granted the permissions associated
with the role.
Note:
THE BYPASSSECURITYGROUPMANAGERCHECK
SWITCH
A role group can be managed by the delegates on the role group or by
users who are directly or indirectly assigned the role management role.
If, however, a user is assigned the role management role but is not
added as a delegate of the role group, that user must use the
BypassSecurityGroupManagerCheck switch on the
Add-RoleGroupMember, Remove-RoleGroupMember,
Update-RoleGroupMember, and
Set-RoleGroup cmdlets when managing a role
group.
You use the ManagedBy parameter on the Set-RoleGroup
EMS cmdlet to add a delegate to or remove a delegate from a role group. (If
you view the properties of the group in Active Directory Users and
Computers, the delegate list populates the Managed By area.) However,
the
ManagedBy parameter overwrites the entire delegate list. If you want to add
delegates to the role group rather than replace the entire list of
delegates, carry out the following procedure:
-
Store the role group delegate list in a variable. For example, the
following command stores the delegates in the Recipient Management
role group in the variable $RecipientRoleGroup:$RecpientRoleGroup = Get-RoleGroup "Recipient Management" -
Add the delegate to the role group stored in the variable. For
example, the following command adds the user Don Hall to the
delegate list variable:$RecipientRoleGroup.ManagedBy += (Get-User "Don Hall").Identity -
If you want to add more users or universal security groups, use
similar commands to do so. Use the Get-Group
cmdlet if you want to add a universal security group. -
Apply the amended delegate list to the role group. The following
command applies the list of delegates held in the
$RecipientRoleGroup variable to the Recipient Management role
group:
Set-RoleGroup "Recipient Management" -ManagedBy $RecipientRoleGroup.ManagedBy
If you want to remove one or more delegates from a role group rather than
replace the entire list of delegates, you follow a similar procedure. First,
you store the current delegate list in a variable exactly as you did in the
previous example. You then remove the delegate or delegates from the
delegate list variable. For example, the following command removes the user
Don Hall from the $RecipientRoleGroup variable:
$RecipientRoleGroup.ManagedBy -= (Get-User "Don Hall").Identity
When the variable stores the required list of delegates and only these
delegates, use the Set-RoleGroup cmdlet as before to
configure membership of the role group.
Note:
Remember the difference between a role member and a role delegate.
Both have access to the permissions granted by the role entries in the
role group (for example, they can use the specified EMS cmdlets), but
the delegate can manage the role group, while the member cannot.
2.7. Applying and Modifying Role Assignment Scopes
A management scope defines the objects that an assignment is permitted to
manage. The assignment and its scope are applied to the members of the role
group and define what those members can manage. If a predefined scope meets
your requirements, you should apply it rather than create a new
scope.
However, you can use the New-ManagementScope EMS
cmdlet to create a new scope if you need to do so. You can use the
Set-ManagementScope cmdlet to modify a scope, or
you can apply a different scope to a role assignment by using the
Set-ManagementRoleAssignment cmdlet. The
appropriate assignment is identified using the
Get-ManagementRoleAssignment cmdlet.
Suppose, for example, that you had assigned one or more roles to a role
group called Canberra Sales Managers. Members of the Canberra Sales Managers
group would then have permissions to carry out defined actions; for example,
they might be able to configure properties of individual mailboxes. However,
you want to ensure that members of the Canberra Sales Managers group can
configure only mailboxes belonging to members of the Canberra Salespersons
security group (and not, for example, mailboxes belonging to members of the
Marketing Department). You would then use a command similar to the following
to change the recipient scope for role assignments on the Canberra Sales
Management role group to Canberra Salespersons:
Get-ManagementRoleAssignment -RoleAssignee "Canberra Sales Management" |
Set-ManagementRoleAssignment -CustomRecipientWriteScope "Canberra Salespersons"
By changing the scope of role assignments in a role group, you can change
the objects that role group members can create, change, or remove. You
might, for example, want to change an assignment named Recipient Admins so
that roles granted through that assignment can be applied only to objects
defined in the Adatum.com/RecAdmins scope. To do this, you would enter the
following command, which assigns the Adatum.com/RecAdmins scope to the
Recipient Admins role assignment:
Set-ManagementRoleAssignment -Identity "Recipient Admins" -RecipientRelativeWriteScope
adatum.com/RecAdmins
You can use a recipient filter to define a scope if no predefined scope
meets your needs. For example, the following command creates a scope that
includes all mailboxes within the Marketing OU in the Adatum.com
domain:
New-ManagementScope -Name "Mailboxes in Marketing OU" -RecipientRestrictionFilter
{RecipientType -eq 'UserMailbox'} -RecipientRoot "Adatum.com/Marketing OU"
You can create a role assignment using
a scope based on a recipient filter, a configuration filter, or an OU. The
following command assigns the MyManagementRole role to the Marketing role
group and applies the Mailboxes in Marketing OU scope:
New-ManagementRoleAssignment -Name "Adatum Marketing" -SecurityGroup "Marketing"
-Role "MyManagementRole" -CustomRecipientWriteScope "Mailboxes in Marketing OU"
You can specify a list of servers to be included in a scope. For example,
the following command creates a scope called Selected Hub Transport Servers
that includes the Hub Transport servers Server01, Server02, Server03, and
Server04:
New-ManagementScope -Name "Selected Hub Transport Servers" -ServerList Server01,
Server02,Server03,Server04
You can use the Set-ManagementScope cmdlet in the EMS
if you want to modify an existing scope rather than create a new one. The
following command adds the Hub Transport server Server05 to the Selected Hub
Transport Servers scope:
Set-ManagementScope -Identity "Selected Hub Transport Servers" -ServerList Server01,
Server02,Server03,Server04,Server05
Note:
Remember that the ServerList parameter associated with the
Set-ManagementScope cmdlet is not additive and
that you need to specify all servers, not just the server or servers you
are adding. Watch out for answers in the examination that specifies only
the additional servers.
To obtain details about a management scope or to obtain a list of scopes
that have been configured in the Exchange organization, you use the
Get-ManagementScope EMS cmdlet. For example, the
following command returns detailed information about the management scope
Selected Hub Transport Servers:
Get-ManagementScope -Identity "Selected Hub Transport Servers" | FL
Note:
Remember how RBAC management role
groups work:
-
Role entries define individual permissions. For example, if a
role entry is an EMS cmdlet and its parameters, role holders can
use that cmdlet. -
Roles are made up of one or more role entries. Role holders
are granted the permissions defined by the role entries
contained in the role they hold. -
Exchange Server 2010 has a number of built-in roles. You can
create a custom role based on a built-in role and then remove
role entries from or add them to the custom role. -
Roles are assigned to role groups through role
assignments. -
Role assignments can be limited by management scopes. A role
assigned to a role group defines what role holders (members of a
role group) can do. A scope defines what they can do it
to. -
Roles can be granted directly to users rather than role
groups. This, however, is bad practice and should be
avoided. -
Exchange Server 2010 has a number of built-in role groups. You
can also create custom role groups and assign roles to
them. -
When you add members or delegates to a role group, they become
role holders and are granted all the permissions defined by the
role entries associated with the roles assigned to the role
group. Any scope applied to the role assignment will limit the
entities on which these permissions can be used. -
Role group members can apply the permissions they obtain as
role holders. Role group delegates can apply the permissions and
also manage the role group.
2.8. Using Management Role Assignment Policies
Management role assignment policies consist of roles
that control what a user can do with his or her mailbox or distribution
groups. Microsoft specifies that you should use role groups to assign
permissions to administrators and specialist users and role assignment
policies to assign permissions to users. When you create a role assignment
policy, it defines everything a user can do with his or her mailbox.
For example, you could allow a user to change the display name, set up voice
mail, and configure Inbox rules.
Every user with an Exchange Server 2010 mailbox (including administrators)
is given a role assignment policy by default. You can define the default
role assignment policy to be assigned, choose what this policy should
include, and override the default for certain mailboxes. If appropriate, you
can choose not to assign any role assignment policies by default. Typically,
you configure permissions for users to manage their mailbox and distribution
group options by assigning a user to a role assignment policy.
One or more users can be associated with a role assignment policy, which
is in turn assigned one or more role assignments. These assignments link the
role assignment policy with one or more end-user roles that define what the
user can configure on his or her mailbox. Role assignment policies have
built-in scopes that restrict the scope of assignments to the user’s
own mailbox or distribution groups.
Note:
REGULAR OR DELEGATING ROLE
ASSIGNMENTS
You can assign a management role using either regular or delegating
role assignments. Regular role assignments grant the permissions
provided by the role to the role assignee. Delegating role assignments
grant the role assignee the ability to assign the role to other role
assignees.
Note:
ROLE MANAGEMENT
Roles, role assignments, and role groups can be managed by
administrators who have been assigned the Role Management management
role. Assignees of the federated sharing management role who have
delegating role assignments can assign the role to other role assignees.
Regular assignees are granted only the permissions provided by the
role.
2.9. Configuring Management Role Assignment Policies
The Exchange Server 2010 default role assignment policy provides end users
with the most commonly used permissions. In most Exchange organizations, the
default management role assignment policy meets all requirements. However,
you can, if you need to, modify the default configuration by altering the
default management role assignment policy. To view the default management
role assignment policy configuration, you use the
Get-ManagementRoleAssignment cmdlet in the EMS. For
example, the following command lists all the management roles assigned to
the default role assignment policy:
Get-ManagementRoleAssignment -RoleAssignee "Default Role Assignment Policy"
Figure 5 shows the output
from this command.
Figure 5. Management roles assigned to the default role assignment
policy
To view the details of each management role, you use the
Get-ManagementRole cmdlet in the EMS. For example,
the following command displays all management role entries associated with
the MyBaseOptions management role:
Get-ManagementRole MyBaseOptions | FL
This command produces a very detailed output. Figure 6 shows the portion of
this output that is probably of most interest.
Figure 6. Details of the MyBaseOptions management role
