Настройка групп для использования в локальной среде Azure DevOps

  • Статья

Azure DevOps Server 2022 г. | Azure DevOps Server 2020 г. | Azure DevOps Server 2019 г.

Управление пользователями в Azure DevOps Server гораздо проще, если вы создаете для них группы Windows или Active Directory, особенно если развертывание включает SQL Server Reporting Services.

Пользователи, группы и разрешения в развертываниях Azure DevOps Server

Azure DevOps Server и SQL Server Reporting Services сохраняют собственные сведения о группах, пользователях и разрешениях. Чтобы облегчить управление пользователями и разрешениями во всех этих программах, можно создать в развертывании группы пользователей со схожими требованиями к доступу, предоставить этим группам соответствующий доступ в различных программах, а затем просто по мере необходимости добавлять или удалять пользователей из группы. Это гораздо легче, чем обслуживать отдельных пользователей или группы пользователей в трех отдельных программах.

Если сервер находится в домене Active Directory, один из вариантов — создать определенные группы Active Directory для управления пользователями, например группу разработчиков и тестировщиков для всех проектов в коллекции проектов или группу пользователей, которые могут создавать и администрировать проекты в коллекции. Аналогично, можно создать учетную запись Active Directory для служб, которые не могут быть настроены для использования системной учетной записи "Сетевая служба" в качестве учетной записи службы. Для этого создайте учетную запись Active Directory для учетной записи источника данных с доступом на чтение для отчетов в SQL Server Reporting Services.

Важно!

Если вы решили использовать группы Active Directory в Azure DevOps Server, рассмотрите возможность создания конкретных групп, предназначенных для управления пользователями в Azure DevOps Server. Использование ранее существующих групп, созданных для других целей, особенно если ими управляют другие пользователи, не знакомые с Azure DevOps Server, могут привести к непредвиденным последствиям для пользователей при изменении членства для поддержки какой-то другой функции.

По умолчанию во время установки используется системная учетная запись сетевой службы в качестве учетной записи службы для Azure DevOps Server и SQL Server. Если в качестве учетной записи службы необходимо использовать конкретную учетную запись — в целях безопасности или по каким-либо другим причинам, например в случае горизонтально масштабированного развертывания — это можно сделать. Вы также можете создать определенную учетную запись Active Directory для использования в качестве учетной записи службы для учетной записи чтения источника данных для SQL Server Reporting Services.

Если сервер находится в домене Active Directory, но у вас нет разрешений на создание групп или учетных записей Active Directory или если сервер устанавливается в рабочую группу, а не в домене, вы можете создавать и использовать локальные группы для управления пользователями в SQL Server и Azure DevOps Server. Аналогично, можно создать локальную учетную запись для использования в качестве учетной записи службы. Необходимо, однако, иметь в виду, что локальные группы и учетные записи менее надежны, чем доменные группы и учетные записи. Например, в случае отказа сервера придется создавать группы и учетные записи с нуля на новом сервере. Если вы используете группы и учетные записи Active Directory, группы и учетные записи будут сохранены, даже если сервер, на котором Azure DevOps Server, завершится сбоем.

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

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

  • небольшую группу администраторов проектов, которые будут иметь разрешения на создание и управление проектами в коллекции. Эту группу можно назвать TFS_ProjectAdmins;

  • специальную ограниченную группу подрядчиков, которые будут иметь доступ только к одному из проектов. Эту группу можно назвать TFS_RestrictedAccess.

Позднее, по мере расширения развертывания, может потребоваться создать и другие группы.

Создание группы в Active Directory

  • Создайте группу безопасности, которая будет представлять собой группу локального домена, глобальную группу или универсальную группу в Active Directory, в зависимости от того, что лучше соответствует потребностям компании. Например, если группа должна содержать пользователей из нескольких доменов, лучше всего подойдет группа универсального типа. Дополнительные сведения см. в разделе Создание новой группы (доменные службы Active Directory).

Создание локальной группы на сервере

  • Создайте локальную группу и присвойте ей имя, по которому можно будет легко определить ее назначение. По умолчанию любая создаваемая группа будет иметь разрешения, эквивалентные разрешениям группы предусмотренной по умолчанию группы "Пользователи" на этом компьютере. Дополнительные сведения см. в статье Создание локальной группы.

Создание учетной записи для использования в качестве учетной записи службы в Active Directory

Создание локальной учетной записи для использования в качестве учетной записи службы на сервере

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

Возможные дальнейшие действия

Добавление пользователей в проекты

Вопросы и ответы

Вопрос. Можно ли использовать группы для ограничения доступа к проектам или функциям в Azure DevOps Server?

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