Uwaga
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Azure DevOps Server |Azure DevOps Server |Azure DevOps Server 2022 | Azure DevOps Server 2020
Zarządzanie użytkownikami w usłudze Azure DevOps Server jest znacznie łatwiejsze w przypadku tworzenia dla nich grup systemu Windows lub Active Directory, szczególnie jeśli wdrożenie obejmuje usługi SQL Server Reporting Services.
Użytkownicy, grupy i uprawnienia we wdrożeniach usługi Azure DevOps Server
Wszystkie usługi Azure DevOps Server i SQL Server Reporting Services zachowują własne informacje o grupach, użytkownikach i uprawnieniach. Aby ułatwić zarządzanie użytkownikami i uprawnieniami w tych programach, można tworzyć grupy użytkowników z podobnymi wymaganiami dostępu we wdrożeniu, przyznać tym grupom odpowiedni dostęp w różnych programach oprogramowania, a następnie po prostu dodać lub usunąć użytkowników z grupy zgodnie z potrzebami. Jest to znacznie łatwiejsze niż utrzymywanie poszczególnych użytkowników lub grup użytkowników oddzielnie w trzech oddzielnych programach.
Jeśli serwer znajduje się w domenie usługi Active Directory, jedną z opcji jest utworzenie określonych grup usługi Active Directory do zarządzania użytkownikami, takich jak grupa deweloperów i testerów dla wszystkich projektów w kolekcji projektów lub grupa użytkowników, którzy mogą tworzyć i administrować projektami w kolekcji. Podobnie można utworzyć konto usługi Active Directory dla usług, których nie można skonfigurować do używania konta systemu usługi sieciowej jako konta usługi. W tym celu utwórz konto usługi Active Directory dla konta źródła danych dostępu do odczytu dla raportów w usługach SQL Server Reporting Services.
Ważne
Jeśli zdecydujesz się używać grup usługi Active Directory w usłudze Azure DevOps Server, rozważ utworzenie określonych grup, których celem jest zarządzanie użytkownikami w usłudze Azure DevOps Server. Używanie wcześniej istniejących grup, które zostały utworzone w innym celu, szczególnie jeśli są zarządzane przez inne osoby, które nie znają usługi Azure DevOps Server, mogą prowadzić do nieoczekiwanych konsekwencji użytkownika, gdy zmiany członkostwa w celu obsługi innej funkcji.
Domyślnym wyborem podczas instalacji jest użycie konta systemu usługi sieciowej jako konta usługi dla programu Azure DevOps Server i programu SQL Server. Jeśli chcesz użyć określonego konta jako konta usługi do celów zabezpieczeń lub innych powodów, takich jak wdrożenie skalowane w poziomie, możesz. Możesz również utworzyć określone konto usługi Active Directory, które będzie używane jako konto usługi dla konta czytnika źródła danych dla usług SQL Server Reporting Services.
Jeśli serwer znajduje się w domenie usługi Active Directory, ale nie masz uprawnień do tworzenia grup lub kont usługi Active Directory lub jeśli instalujesz serwer w grupie roboczej zamiast domeny, możesz utworzyć i użyć grup lokalnych do zarządzania użytkownikami w programie SQL Server i usłudze Azure DevOps Server. Podobnie możesz utworzyć konto lokalne do użycia jako konto usługi. Należy jednak pamiętać, że lokalne grupy i konta nie są tak niezawodne, jak grupy domen i konta. Na przykład w przypadku awarii serwera należy ponownie utworzyć grupy i konta od podstaw na nowym serwerze. Jeśli używasz grup i kont usługi Active Directory, grupy i konta będą zachowywane nawet wtedy, gdy serwer hostowany przez usługę Azure DevOps Server ulegnie awarii.
Na przykład po przejrzeniu wymagań biznesowych dotyczących nowego wdrożenia i wymagań dotyczących zabezpieczeń z menedżerami projektów możesz zdecydować się na utworzenie trzech grup do zarządzania większością użytkowników we wdrożeniu:
Ogólna grupa dla deweloperów i testerów, którzy będą uczestniczyć w pełni we wszystkich projektach w domyślnej kolekcji projektów. Ta grupa będzie zawierać większość użytkowników. Możesz nazwać tę grupę TFS_ProjectContributors.
Niewielka grupa administratorów projektu, którzy będą mieli uprawnienia do tworzenia projektów i zarządzania nimi w kolekcji. Możesz nazwać tę grupę TFS_ProjectAdmins.
Specjalna, ograniczona grupa wykonawców, którzy będą mieli dostęp tylko do jednego z projektów. Możesz nazwać tę grupę TFS_RestrictedAccess.
W miarę rozszerzania wdrożenia możesz zdecydować się na utworzenie innych grup.
Aby utworzyć grupę w usłudze Active Directory
- Utwórz grupę zabezpieczeń, która jest domeną lokalną, globalną lub grupą uniwersalną w usłudze Active Directory, zgodnie z najlepszymi potrzebami biznesowymi. Jeśli na przykład grupa musi zawierać użytkowników z więcej niż jednej domeny, typ grupy uniwersalnej najlepiej odpowiada Twoim potrzebom. Aby uzyskać więcej informacji, zobacz Tworzenie nowej grupy (Active Directory Domain Services).
Aby utworzyć grupę lokalną na serwerze
- Utwórz grupę lokalną i nadaj jej nazwę, która szybko zidentyfikuje swój cel. Domyślnie każda utworzona grupa będzie mieć równoważne uprawnienia domyślnej grupy Użytkownicy na tym komputerze. Aby uzyskać więcej informacji, zobacz Tworzenie grupy lokalnej.
Aby utworzyć konto do użycia jako konto usługi w usłudze Active Directory
- Utwórz konto w usłudze Active Directory, ustaw zasady haseł zgodnie z wymaganiami biznesowymi i upewnij się, że dla konta wybrano opcję Konto zaufane dla delegowania . Aby uzyskać więcej informacji, zobacz Create a New User Account (Active Directory Domain Services) (Tworzenie nowego konta użytkownika (Active Directory Domain Services) i Opis kont użytkowników (Active Directory Domain Services).
Aby utworzyć konto lokalne do użycia jako konto usługi na serwerze
- Utwórz konto lokalne, które będzie używane jako konto usługi, a następnie zmodyfikuj członkostwo w grupie i inne właściwości zgodnie z wymaganiami dotyczącymi zabezpieczeń twojej firmy. Aby uzyskać więcej informacji, zobacz Tworzenie konta użytkownika lokalnego.
Spróbuj wykonać tę następną próbę
Pytania i odpowiedzi
.: Czy mogę użyć grup w celu ograniczenia dostępu do projektów lub funkcji w usłudze Azure DevOps Server?
A: Tak, możesz. Można utworzyć określone grupy do udzielania lub ograniczania dostępu do wybranych funkcji, funkcji i projektów na potrzeby zarządzania poziomami dostępu i innymi celami.