Freigeben über

Einrichten von Gruppen für die Verwendung in Azure DevOps lokal

Azure DevOps Server 2022 | Azure DevOps Server 2020 | Azure DevOps Server 2019

Die Verwaltung von Benutzern in Azure DevOps Server ist viel einfacher, wenn Sie Windows- oder Active Directory-Gruppen für sie erstellen, insbesondere, wenn Ihre Bereitstellung SQL Server Reporting Services umfasst.

Benutzer, Gruppen und Berechtigungen in Azure DevOps Server-Bereitstellungen

Azure DevOps Server und SQL Server Reporting Services verwalten alle ihre eigenen Informationen zu Gruppen, Benutzern und Berechtigungen. Um die Verwaltung von Benutzern und Berechtigungen in diesen Programmen zu vereinfachen, können Sie Gruppen von Benutzern mit ähnlichen Zugriffsanforderungen in der Bereitstellung erstellen, diesen Gruppen den entsprechenden Zugriff in den verschiedenen Softwareprogrammen gewähren und dann einfach nach Bedarf Benutzer aus einer Gruppe hinzufügen oder entfernen. Dies ist viel einfacher als die Aufrechterhaltung einzelner Benutzer oder Benutzergruppen in drei separaten Programmen.

Wenn sich Ihr Server in einer Active Directory-Domäne befindet, besteht eine Möglichkeit darin, bestimmte Active Directory-Gruppen zum Verwalten Ihrer Benutzer zu erstellen, z. B. eine Gruppe von Entwicklern und Testern für alle Projekte in der Projektsammlung oder eine Gruppe von Benutzern, die Projekte in der Sammlung erstellen und verwalten können. Ebenso können Sie ein Active Directory-Konto für Dienste erstellen, die nicht für die Verwendung des Netzwerkdienstsystemkontos als Dienstkonto konfiguriert werden können. Erstellen Sie dazu ein Active Directory-Konto für das Datenquellenkonto mit Lesezugriff für Berichte in SQL Server Reporting Services.

Wichtig

Wenn Sie active Directory-Gruppen in Azure DevOps Server verwenden möchten, sollten Sie bestimmte Gruppen erstellen, deren Zweck der Benutzerverwaltung in Azure DevOps Server zugeordnet ist. Die Verwendung zuvor vorhandener Gruppen, die für einen anderen Zweck erstellt wurden, insbesondere dann, wenn sie von anderen verwaltet werden, die mit Azure DevOps Server nicht vertraut sind, kann zu unerwarteten Benutzerfolgen führen, wenn sich die Mitgliedschaft ändert, um eine andere Funktion zu unterstützen.

Die Standardauswahl bei der Installation besteht darin, das Netzwerkdienstsystemkonto als Dienstkonto für Azure DevOps Server und SQL Server zu verwenden. Wenn Sie ein bestimmtes Konto als Dienstkonto für Sicherheitszwecke oder andere Gründe verwenden möchten, z. B. eine skalierte Bereitstellung, können Sie. Möglicherweise möchten Sie auch ein bestimmtes Active Directory-Konto erstellen, das als Dienstkonto für das Datenquellenleserkonto für SQL Server Reporting Services verwendet werden soll.

Wenn sich Ihr Server in einer Active Directory-Domäne befindet, Sie aber keine Berechtigungen zum Erstellen von Active Directory-Gruppen oder -Konten haben oder wenn Sie Ihren Server in einer Arbeitsgruppe anstelle einer Domäne installieren, können Sie lokale Gruppen erstellen und verwenden, um Benutzer über SQL Server und Azure DevOps Server zu verwalten. Ebenso können Sie ein lokales Konto erstellen, das als Dienstkonto verwendet werden soll. Beachten Sie jedoch, dass lokale Gruppen und Konten nicht so robust sind wie Domänengruppen und Konten. Wenn beispielsweise ein Serverfehler auftritt, müssen Sie die Gruppen und Konten auf dem neuen Server neu erstellen. Wenn Sie Active Directory-Gruppen und -Konten verwenden, bleiben die Gruppen und Konten erhalten, auch wenn der Server, auf dem Azure DevOps Server gehostet wird, fehlschlägt.

Nach der Überprüfung der Geschäftsanforderungen für die neue Bereitstellung und die Sicherheitsanforderungen mit den Projektmanagern können Sie beispielsweise drei Gruppen erstellen, um die Mehrzahl der Benutzer in der Bereitstellung zu verwalten:

  • Eine allgemeine Gruppe für Entwickler und Tester, die vollständig an allen Projekten in der Standardprojektsammlung teilnehmen. Diese Gruppe enthält die Mehrzahl der Benutzer. Sie können diese Gruppe TFS_ProjectContributors benennen.

  • Eine kleine Gruppe von Projektadministratoren, die über Berechtigungen zum Erstellen und Verwalten von Projekten in der Sammlung verfügen. Sie können diese Gruppe TFS_ProjectAdmins benennen.

  • Eine spezielle, eingeschränkte Gruppe von Auftragnehmern, die nur Zugriff auf eines der Projekte haben. Sie können diese Gruppe TFS_RestrictedAccess benennen.

Später, im Zuge der Erweiterung der Bereitstellung, könnten Sie entscheiden, andere Gruppen zu erstellen.

So erstellen Sie eine Gruppe in Active Directory

  • Erstellen Sie eine Sicherheitsgruppe, die eine lokale Domäne, eine globale oder eine universelle Gruppe in Active Directory ist, je nach Ihren geschäftlichen Anforderungen. Wenn die Gruppe beispielsweise Benutzer aus mehr als einer Domäne enthalten muss, passt der universelle Gruppentyp ihren Anforderungen am besten. Weitere Informationen finden Sie unter Erstellen einer neuen Gruppe (Active Directory Domain Services).

So erstellen Sie eine lokale Gruppe auf dem Server

  • Erstellen Sie eine lokale Gruppe, und geben Sie ihm einen Namen, der den Zweck schnell identifiziert. Standardmäßig verfügen alle von Ihnen erstellten Gruppen über die entsprechenden Berechtigungen der Standardgruppe "Benutzer" auf diesem Computer. Weitere Informationen finden Sie unter Erstellen einer lokalen Gruppe.

So erstellen Sie ein Konto, das als Dienstkonto in Active Directory verwendet werden soll

So erstellen Sie ein lokales Konto, das als Dienstkonto auf dem Server verwendet werden soll

  • Erstellen Sie ein lokales Konto, das als Dienstkonto verwendet werden soll, und ändern Sie dann die Gruppenmitgliedschaft und andere Eigenschaften entsprechend den Sicherheitsanforderungen für Ihr Unternehmen. Weitere Informationen finden Sie unter Erstellen eines lokalen Benutzerkontos.

Versuchen Sie dies als Nächstes:

Hinzufügen von Benutzern zu Projekten

Q & A

F: Kann ich Gruppen verwenden, um den Zugriff auf Projekte oder Features in Azure DevOps Server einzuschränken?

A: Ja, Sie können. Sie können bestimmte Gruppen erstellen, um Den Zugriff auf ausgewählte Features, Funktionen und Projekte zu gewähren oder einzuschränken, um Zugriffsebenen und andere Zwecke zu verwalten.