Zasady grupy: Prawa administratora dla określonych użytkowników na określonych komputerach

11

Jestem programistą, który utknął próbując zarządzać konfiguracją Active Directory dla małej firmy. Kontroler domeny działa w systemie Windows Small Business Server 2008.

Mamy pracowników terenowych korzystających z tabletów; problemy z konfiguracją bloatware ThinkVantage na tablecie będą wymagały od tych użytkowników posiadania uprawnień administratora podczas korzystania z tabletów. Zgadza się - przydatne są dla nich szerokie uprawnienia, gdy przeprowadzam je przez telefon, więc nie szukam obejścia.

Chciałbym użyć zasad grupy do skonfigurowania następującego scenariusza: Użytkownicy w określonej grupie zabezpieczeń (lub jednostce organizacyjnej) powinni znajdować się w grupie BUILTIN / Administratorzy, gdy są zalogowani na komputerach w określonej grupie zabezpieczeń (lub jednostce organizacyjnej). W porządku, jeśli komputery muszą znajdować się w jednostce organizacyjnej, ale wolałbym przypisywać użytkowników według grup.

Oczywiście pracownicy terenowi nie powinni być administratorami na innych stacjach roboczych, a waniliowy personel biurowy nie powinien być administratorem na tablecie.

Obecnie jest to zarządzane lokalnie na każdym tablecie, ale wraz z dodawaniem nowych pracowników staje się to coraz trudniejsze.

Wydaje mi się, że grupy z ograniczeniami są tutaj odpowiedzią, ale bez solidnego uzasadnienia w koncepcjach i metodach AD mam trudności z realizacją.

Jaka jest właściwa technika do tego zadania i jak miałabym je realizować?

WCWedin
źródło

Odpowiedzi:

13

Utwórz grupę, aby obudować użytkowników (lokalni administratorzy-tablety) i dodaj ich do tej grupy

Utwórz podrzędną jednostkę organizacyjną dla bieżącej jednostki organizacyjnej stacji roboczych i umieść tutaj tablety (stacje robocze \ tablety)

Utwórz obiekt zasad grupy (Local-Admins-Tablets-Policy) i połącz go ze stacją roboczą \ Tablets OU

W GPO ustaw następujące ustawienia:

  • Comp Config - Zasady - Ustawienia systemu Windows - Ustawienia zabezpieczeń - Grupy z ograniczeniami
  • Kliknij prawym przyciskiem myszy, Dodaj grupę
  • „Administratorzy”, OK
  • Członkowie tej grupy: myDomain \ Local-Admins-Tablets

Uruchom ponownie komputery i gotowe.

Pamiętaj, że ustawienie grup z ograniczeniami spowoduje zastąpienie istniejącej listy lokalnych administratorów na komputerach. Jeśli masz już innych użytkowników / grupy, musisz również dodać ich do tej zasady. Inne przykłady to myDomain \ Domain Admins itp

EDYCJA: Aha, zmień filtrowanie na GPO i dodaj Komputery Domowe . Najprostszym sposobem na to jest skorzystanie z przystawki MMC do zarządzania zasadami grupy (można to uzyskać w Narzędziach administracji zdalnej serwera od Microsoft)

Izzy
źródło
5
+1. Grupy z ograniczeniami są tutaj rozwiązaniem. Gpupdate / force na stacjach roboczych wystarczy, aby zmiana zaczęła obowiązywać, co eliminuje potrzebę ponownego uruchomienia komputera.
joeqwerty
Jeśli tablety znajdują się w terenie , łatwiej jest skłonić użytkownika do ponownego uruchomienia niż wyjaśnić „otwarte cmd, wpisz gpupdate / force / boot” itd. :)
Izzy
1
Korzystając z Preferencji zasad grupy ( technet.microsoft.com/en-us/library/cc731892%28WS.10%29.aspx ) możesz zaktualizować grupę lokalną bez nadpisywania czegokolwiek.
Zoredache
1
Cóż, to załatwiło sprawę! Tylko dwa pytania: rozumiem, że całkowicie wysadzi wszystkich obecnych członków grupy administracyjnej, w tym lokalnych użytkowników, prawda? To może okazać się paskudną niespodzianką. Zakładam, że nie wpłynie to na domyślne konto administratora; czy to ze mnie zarozumiałe?
WCWedin
1
Nigdy tego nie testowałem, zawsze dodawałem Builtin \ Administrators do tej ograniczonej grupy. Pas i szelki :)
Izzy
12

Odpowiedź Izzy jest dobra, jeśli nie przejmujesz się, że grupa Administratorzy zostanie skutecznie zablokowana przed przyszłymi zmianami z lokalnego komputera. Spowoduje to również usunięcie wszystkich grup, które były już członkami grupy Administratorzy przed zastosowaniem ustawienia zasad.

Możesz jednak użyć tego samego ustawienia zasad w nieco inny sposób, aby ominąć te irytacje (zakładając, że nawet uważasz je za irytacje).

  • Utwórz strukturę jednostki organizacyjnej / grupy w taki sam sposób jak poprzednio
  • Gdy znajdziesz się w sekcji Grupy z ograniczeniami w obiekcie zasad grupy, Dodaj grupę, ale zamiast określać Administratorów , podaj YOURDOMAIN \ Local-Admins-Tablets .
  • W sekcji „Ta grupa jest członkiem” kliknij Dodaj i wpisz Administratorzy

Jest to subtelna, ale ważna różnica w sposobie działania dwóch sekcji. Członkowie tej grupy skutecznie działają w taki sposób, że „Grupa A będzie zawierała tylko Grupy X, Y i Z”. Ta grupa należy do grupy skutecznie działającej jako „Upewnij się, że grupa A jest członkiem grup X, Y i Z”.

Po ustawieniu zasad dla członków tej grupy jedyną rzeczą, która może zmodyfikować członkostwo w grupie, jest nadrzędny obiekt zasad, który również korzysta z członków tej grupy lub innych zasad korzystających z tej grupy .

Ryan Bolger
źródło
2

Wydaje się, że wszystko, co naprawdę musisz zrobić, to utworzyć zasady grupy, które dodają grupę domen do lokalnej grupy administratorów. Można to łatwo zrobić za pomocą prostego skryptu uruchamiania lub Preferencji zasad grupy .

Prosty skrypt startowy do dodawania członków grupy.

DomainName="example"
Set oShell = WScript.CreateObject("WScript.Shell")
Set oProcsEnv = oShell.Environment("Process")
ComputerName = oProcsEnv("COMPUTERNAME")
Set oGroup = GetObject("WinNT://" & ComputerName & "/" & "Administrators")
If Not oGroup.IsMember("WinNT://"&DomainName&"/_Group_Tablet_Admins") Then _
    oGroup.Add ("WinNT://"&DomainName&"/_Group_Tablet_Admins")
Zoredache
źródło
Zakładając, że używa W2K8, czego nie mogę powiedzieć na podstawie jego pytania.
joeqwerty
Preferencje po stronie klienta są obsługiwane w domenie 2003r2. Po prostu nie miałem przydatnego linku do artykułu z 2003r2.
Zoredache
Edytowałem pytanie, aby dodać system operacyjny. Wydaje się, że GPP dobrze pasuje do tego scenariusza, ponieważ użytkownicy raczej nie będą później modyfikować swoich grup, przez co ich tymczasowy charakter będzie sporny. To powiedziawszy, wdrożenie wymagań wstępnych na każdym komputerze klienckim wydaje się ogromnym bólem głowy.
WCWedin
1
Dlatego robienie tego za pomocą prostego skryptu uruchamiania jest również prostą opcją. Uważam, że preferencje są przydatne również w wielu innych sprawach. Być może warto je zainstalować dla innych rzeczy, które będziesz w stanie osiągnąć w przyszłości.
Zoredache
1

Jedyny problem z wymienionym rozwiązaniem polega na tym, że przyznaje on lokalnym administratorom prawa do wszystkich komputerów, na których obowiązują te zasady. Zazwyczaj chciałbyś przyznać uprawnienia administratora tylko określonej maszynie. Zauważyłem, że gdy użytkownik zdaje sobie sprawę, że ma lokalne uprawnienia administratora, instaluje oprogramowanie dla wszystkich swoich partnerów.

Można to zrobić na wiele różnych sposobów, ale mogę tylko zasugerować jeden. Wykonaj powyższe kroki, ale także utwórz grupę dla każdego komputera, na którym użytkownicy potrzebują dodatkowych uprawnień. Każda z tych „grup komputerów” jest dodawana do grupy myDomain \ Local-Admins.

Użytkownicy są następnie dodawani do grupy odpowiadającej urządzeniu, do którego potrzebują dostępu.

Są więc administratorem, ale tylko tą maszyną.

Jakub
źródło
0

Mówisz, że dodawanie nowych pracowników jest kłopotliwe, ale czy nie powinno to być dodawanie nowych tabletów, które byłyby kłopotliwe?

Zrobiłbym coś w ten sposób:

Mieć grupę zabezpieczeń domeny, która zawiera wszystkich użytkowników, którzy powinni być administratorami na komputerach typu Tablet (tj. TabletAdministrators).

Na każdym tablecie dodaj tę grupę do grupy Administratorzy.

Czy to jest właściwa technika, czy nie, nie wiem. To tylko pierwszy pomysł, który przychodzi mi do głowy, jak wdrożyć.

Barrett Jacobsen
źródło
2
Nie należy go dodawać ręcznie do każdej maszyny. Do tego służą Zasady Grupy
Izzy,
1
Podczas konfigurowania nowego tabletu muszę dodać 15 użytkowników do jednego tabletu. Dodając nowego pracownika, muszę dodać jednego użytkownika do 20 tabletów. Oba są kłopotliwe, ale mechanika chodzenia od maszyny do maszyny sprawia, że ​​ten drugi proces jest nużący i powolny. Twoje podejście znacznie to złagodzi, nawet jeśli nie będzie to szczególnie eleganckie.
WCWedin
1
+1 w tym głosowaniu, aby nieco go przywrócić. To może nie być najlepsze rozwiązanie, ale jest to prawidłowe rozwiązanie. Nie należy głosować za proponowaniem prawidłowego rozwiązania tylko dlatego, że nie jest to preferowane rozwiązanie. Jedyne, czego brakuje w tym rozwiązaniu, to użycie grup z ograniczeniami do zautomatyzowania procesu dodawania grupy do grupy lokalnych administratorów. Mówię +1 za wysiłek i wkład w odpowiedź.
joeqwerty
0

Napisałem skrypt, który działa jako zasada komputera z prawami administracyjnymi na lokalnej stacji roboczej. Sprawdza opis ostatniego zalogowanego użytkownika w AD, który administrator domeny może ustawić z „Użytkownicy i komputery usługi Active Directory”, jeśli zawiera nazwę stacji roboczej, skrypt dodaje użytkownika do lokalnej grupy administracyjnej, jeśli nazwa stacji roboczej nie znajduje się w Opis użytkownika, usuwa użytkownika z lokalnej grupy administracyjnej. Opis może zawierać więcej niż jedną nazwę komputera, na przykład:

Opis użytkownika: „Lokalny administrator na WKST-E445R i WKST-VM398”

Aby więc uczynić kogoś lokalnym administratorem tylko na jednym komputerze, muszę tylko dodać nazwę tego komputera do opisu użytkownika w AD i poprosić użytkownika o ponowne uruchomienie , a usunięcie nazwy komputera usuwa uprawnienia lokalnego administratora.

Czy to nie jest najładniejsze rozwiązanie? :-)

Oto skrypt:

    @if "%debug%" neq "%username%" echo off
set ver=MakeLocalAdmin.cmd henrik@c o m m o r e.se 20150423
:: Adds last logged on domain user to local Administrators group if run by computer GPO with Administrative rights and the user's Comment contains Computername

set log=nul
:: or set log=c:\logs\MakeLocalAdmins.txt

:: Check who was last logged on user
FOR /F "tokens=3 delims= " %%G in ('reg query "hklm\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\LogonUI" /v LastLoggedOnUser') DO (
set DomainAndUserName=%%G)

:: Remove the spaces
set DomainAndUserName=%DomainAndUserName: =%

:: Get only username part
set LastLoggedOnUserName=%DomainAndUserName:*\=%


:: Check OS language, so we can adapt to localized name of Admin group and Comment
FOR /F "tokens=3 delims= " %%G in ('reg query "hklm\system\controlset001\control\nls\language" /v Installlanguage') DO (
set Language=%%G)

echo %date% %Time% ; %0 ; %computername%; %LastLoggedOnUserName%; %DomainAndUserName%, %Language% >> %log%
goto %Language%

:: Add any langauage specific part below, but if an unknown install language is found,
:: an error 'label not found' should mean script terminates, but anyway make sure it terminates. 
goto end

:0409
:: English
net user /domain %LastLoggedOnUserName% | find "Comment " | find "%computername%" >> %log%
set NoLocalAdmin=%errorlevel%
if %NoLocalAdmin% equ 0 net localgroup Administrators /add "%DomainAndUserName%" >> %log%
if %NoLocalAdmin% equ 1 net localgroup Administrators /del "%DomainAndUserName%" >> %log%
goto end

:041D
:: Swedish 
:: †„” åäö (Swedish char's)
net user /domain %LastLoggedOnUserName% | find "Kommentar " | find "%computername%" >> %log%
set NoLocalAdmin=%errorlevel%
if %NoLocalAdmin% equ 0 net localgroup Administrat”rer /add "%DomainAndUserName%" >> %log%
if %NoLocalAdmin% equ 1 net localgroup Administrat”rer /del "%DomainAndUserName%" >> %log%
goto end



:end
HeHe
źródło