Udostępnij przez

Korzystanie z rozszerzenia DsAddSidHistory

Funkcja DsAddSidHistory pobiera podstawowy identyfikator zabezpieczeń (SID) konta podmiotu zabezpieczeń z jednej domeny (domeny źródłowej) i dodaje go do atrybutu sIDHistory podmiotu zabezpieczeń w innej domenie (docelowej), znajdującej się w innym lesie. Gdy domena źródłowa jest w trybie natywnym systemu Windows 2000, ta funkcja także pobiera wartości sIDHistory podmiotu źródła i dodaje je do wartości sIDHistory podmiotu docelowego.

Dodawanie identyfikatorów SID do sIDHistory podmiotu zabezpieczeń jest operacją wrażliwą na zabezpieczenia, która skutecznie przyznaje podmiotowi docelowemu dostęp do wszystkich zasobów, do których miał dostęp podmiot źródłowy, pod warunkiem, że istnieją relacje zaufania między odpowiednimi domenami zasobów a domeną docelową.

W trybie natywnym w domenie systemu Windows 2000 logowanie użytkownika tworzy token dostępu zawierający identyfikator SID konta podstawowego użytkownika i identyfikatory SID grup, a także sIDHistory użytkownika oraz sIDHistory grup, których użytkownik jest członkiem. Posiadanie tych poprzednich identyfikatorów SID (wartości sIDHistory) w tokenie użytkownika przyznaje użytkownikowi dostęp do zasobów chronionych przez listy kontroli dostępu (ACL) zawierające poprzednie identyfikatory SID.

Ta operacja ułatwia niektóre scenariusze wdrażania systemu Windows 2000. W szczególności obsługuje scenariusz, w którym konta w nowym lesie systemu Windows 2000 są tworzone dla użytkowników i grup, które już istnieją w środowisku produkcyjnym systemu Windows NT 4.0. Umieszczenie identyfikatora SID konta systemu Windows NT 4.0 na koncie systemu Windows 2000 sIDHistory, dostęp do zasobów sieciowych jest zachowywany dla użytkownika logując się na swoim nowym koncie systemu Windows 2000.

DsAddSidHistory obsługuje również migrację kontrolerów domen zapasowych Windows NT 4.0 (BDC), serwerów zasobów, a także kontrolerów domen i serwerów członkowskich w trybie macierzystym do domeny Windows 2000 jako serwerów członkowskich. Ta migracja wymaga utworzenia w docelowej domenie systemu Windows 2000 grup lokalnych domeny, które zawierają w swoim sIDHistorypodstawowe SID-y lokalnych grup zdefiniowanych na zapasowym kontrolerze domeny (lub grupy lokalne domeny, do których odwołują się listy ACL na serwerach systemu Windows 2000) w domenie źródłowej. Tworząc docelową grupę lokalną zawierającą sIDHistory i wszystkich członków źródłowej grupy lokalnej, dostęp do zmigrowanych zasobów serwera, chroniony przez listy ACL odwołujące się do źródłowej grupy lokalnej, jest utrzymywany dla wszystkich członków.

Notatka

Użycie DsAddSidHistory wymaga zrozumienia szerszych konsekwencji administracyjnych i bezpieczeństwa w tych i innych scenariuszach. Aby uzyskać więcej informacji, zobacz oficjalny dokument "Planning Migration from Windows NT to Microsoft Windows 2000" (Planowanie migracji z systemu Windows NT do systemu Microsoft Windows 2000) dostarczany jako Dommig.doc w narzędziach pomocy technicznej systemu Windows 2000. Tę dokumentację można również znaleźć na dysku CD produktu w katalogu \support\tools.

Wymagania dotyczące autoryzacji

DsAddSidHistory wymaga uprawnień administratora w domenach źródłowych i docelowych. W szczególności obiekt wywołujący tego interfejsu API musi być członkiem grupy Administratorzy domeny w domenie docelowej. Wykonywane jest zakodowane sprawdzanie tego członkostwa. Ponadto konto podane w parametrze SrcDomainCreds musi być członkiem grupy Administratorzy albo Administratorzy domeny w domenie źródłowej. Jeśli NULL jest przekazywane w SrcDomainCreds, użytkownik wywołujący interfejs API musi należeć do grupy Administratorzy lub Administratorzy domeny w domenie źródłowej.

Wymagania dotyczące domeny i zaufania

DsAddSidHistory wymaga, aby domena docelowa znajdować się w trybie natywnym systemu Windows 2000 lub nowszym, ponieważ tylko ten typ domeny obsługuje atrybut sIDHistory. Domeną źródłową może być system Windows NT 4.0 lub Windows 2000, tryb mieszany lub natywny. Domeny źródłowe i docelowe nie mogą znajdować się w tym samym lesie. Domeny systemu Windows NT 4.0 są z definicji nie w lesie. To ograniczenie między lasami gwarantuje, że zduplikowane identyfikatory SID, niezależnie od tego, czy są wyświetlane jako podstawowe identyfikatory SID, czy wartości sIDHistory, nie są tworzone w tym samym lesie.

DsAddSidHistory wymaga zewnętrznego zaufania z domeny źródłowej do domeny docelowej w przypadkach wymienionych w poniższej tabeli.

Przypadek Opis
Domena źródłowa to Windows 2000.
 Atrybut źródłowy sIDHistory dostępny tylko w domenach źródłowych systemu Windows 2000 może być tylko do odczytu przy użyciu protokołu LDAP, co wymaga tego zaufania do ochrony integralności.
Domena źródłowa to Windows NT 4.0 i SrcDomainCreds jest NULL.
 Podszywanie się, wymagane do obsługi operacji w domenie źródłowej przy użyciu poświadczeń osoby wywołującej, zależy od tego zaufania. Personifikacja wymaga również, aby docelowy kontroler domeny miał domyślnie włączoną opcję "Zaufane delegowanie" na kontrolerach domeny.

Nie jest jednak wymagane zaufanie między domenami źródłowymi i docelowymi, jeśli domena źródłowa to Windows NT 4.0 i SrcDomainCreds nie jest NULL.

Wymagania dotyczące źródłowego kontrolera domeny

DsAddSidHistory wymaga, aby kontroler domeny wybrany jako obiekt docelowy dla operacji w domenie źródłowej był kontrolerem PDC w domenach systemu Windows NT 4.0 lub emulatorem kontrolera PDC w domenach systemu Windows 2000. Inspekcja domeny źródłowej jest generowana za pomocą operacji zapisu, dlatego kontroler PDC jest wymagany w domenach źródłowych systemu Windows NT 4.0, a ograniczenie tylko kontrolera PDC gwarantuje, że DsAddSidHistory inspekcje są generowane na jednym komputerze. Zmniejsza to konieczność przeglądania dzienników audytu wszystkich kontrolerów domeny, aby monitorować użycie tej operacji.

Notatka

W domenach źródłowych systemu Windows NT 4.0 PDC (docelowy element operacji w domenie źródłowej) musi mieć zainstalowany dodatek Service Pack 4 (SP4) lub nowszy, aby zapewnić odpowiednią obsługę inspekcji.

Następująca wartość rejestru musi zostać utworzona jako wartość REG_DWORD i ustawiona na 1 na źródłowym kontrolerze domeny dla systemów Windows NT 4.0 i Windows 2000.

HKEY_LOCAL_MACHINE
   System
      CurrentControlSet
         Control
            Lsa
               TcpipClientSupport

Ustawienie tej wartości umożliwia wywołania RPC za pośrednictwem transportu TCP. Jest to wymagane, ponieważ domyślnie interfejsy SAMRPC są możliwe do zdalnej komunikacji tylko przez nazwane kanały. Użycie nazwanych potoków powoduje, że system zarządzania poświadczeniami nadaje się do interakcyjnego logowania użytkowników wykonujących wywołania sieciowe, ale nie jest elastyczny w przypadku procesu systemowego, który wykonuje wywołania sieciowe z poświadczeniami dostarczonymi przez użytkownika. RPC przez TCP jest bardziej odpowiednie do tego celu. Ustawienie tej wartości nie zmniejsza bezpieczeństwa systemu. Jeśli ta wartość zostanie utworzona lub zmieniona, należy ponownie uruchomić źródłowy kontroler domeny, aby to ustawienie zostało zastosowane.

Nowa grupa lokalna "<SrcDomainName>$$$" musi zostać utworzona w domenie źródłowej na potrzeby inspekcji.

Inspekcja

operacje DsAddSidHistory są poddawane inspekcji, aby upewnić się, że zarówno administratorzy domeny źródłowej, jak i docelowej mogą wykrywać, kiedy ta funkcja została uruchomiona. Inspekcja jest obowiązkowa zarówno w domenach źródłowych, jak i docelowych. DsAddSidHistory sprawdza, czy tryb audytu jest włączony w każdej domenie, a audyt zarządzania kontami z uwzględnieniem zdarzeń sukcesów i niepowodzeń jest włączony. W domenie docelowej jest generowane unikatowe zdarzenie audytu "Dodaj historię SID" dla każdej pomyślnej lub nieudanej operacji DsAddSidHistory.

Unikalne zdarzenia audytu "Dodawanie historii SID" nie są dostępne w systemach Windows NT 4.0. Aby wygenerować zdarzenia inspekcji, które jednoznacznie odzwierciedlają użycie DsAddSidHistory względem domeny źródłowej, wykonuje operacje na specjalnej grupie, której nazwa jest unikatowym identyfikatorem w dzienniku inspekcji. Grupa lokalna "<SrcDomainName>$$$", której nazwa składa się z nazwy NetBIOS domeny źródłowej z dołączonymi trzema znakami dolara ($) (kod ASCII = 0x24 i Unicode = U+0024), musi zostać utworzona na kontrolerze domeny źródłowej przed dokonaniem wywołania funkcji DsAddSidHistory. Do użytkownika źródłowego i grupy globalnej, którzy są celem tej operacji, są dodawani, a następnie usuwani z członkostwa w tej grupie. Spowoduje to wygenerowanie zdarzeń inspekcji Dodaj członka i Usuń członka w domenie źródłowej, które można monitorować, wyszukując zdarzenia odwołujące się do nazwy grupy.

Notatka

DsAddSidHistory operacji na grupach lokalnych w domenie źródłowej trybu mieszanego systemu Windows NT 4.0 lub Windows 2000 nie można poddać inspekcji, ponieważ grupy lokalne nie mogą być członkami innej grupy lokalnej i dlatego nie można ich dodać do specjalnej lokalnej grupy "<SrcDomainName>$$$". Ten brak inspekcji nie stanowi problemu z zabezpieczeniami w domenie źródłowej, ponieważ dostęp do zasobów domeny źródłowej nie ma wpływu na tę operację. Dodanie identyfikatora SID źródłowej grupy lokalnej do docelowej grupy lokalnej nie udziela dostępu do zasobów źródłowych chronionych przez grupę lokalną wszystkim dodatkowym użytkownikom. Dodanie członków do docelowej grupy lokalnej nie zapewnia im dostępu do zasobów źródłowych. Dodani członkowie mają dostęp tylko do serwerów w domenie docelowej migrowanej z domeny źródłowej, które mogą mieć zasoby chronione przez źródłowy identyfikator SID grupy lokalnej.

Zabezpieczenia transmisji danych

DsAddSidHistory wymusza następujące środki zabezpieczeń:

  • Jeśli jest wywoływane ze stacji roboczej z systemem Windows 2000, poświadczenia obiektu wywołującego są używane do uwierzytelniania i ochrony prywatności wywołania RPC do docelowego kontrolera domeny. Jeśli SrcDomainCreds nie jest NULL, zarówno stacja robocza, jak i docelowy kontroler domeny muszą obsługiwać szyfrowanie 128-bitowe w celu ochrony prywatności poświadczeń. Jeśli szyfrowanie 128-bitowe jest niedostępne i SrcDomainCreds są udostępniane, należy wykonać wywołanie na docelowym kontrolerze domeny.
  • Docelowy kontroler domeny komunikuje się ze źródłowym kontrolerem domeny przy użyciu SrcDomainCreds lub poświadczeń obiektu wywołującego w celu wzajemnego uwierzytelniania i ochrony integralności odczytu SID konta źródłowego (przy użyciu wyszukiwania SAM) oraz sIDHistory (przy użyciu odczytu LDAP).

Modele zagrożeń

Poniższa tabela zawiera listę potencjalnych zagrożeń skojarzonych z wywołaniem DsAddSidHistory i odpowiada na środki zabezpieczeń istotne dla konkretnego zagrożenia.

Potencjalne zagrożenie Środek zabezpieczeń
Człowiek w środku ataku
Nieautoryzowany użytkownik przechwytuje SID wyszukiwania obiektu źródłowego podczas zwrotu wywołania, zastępując identyfikator SID obiektu źródłowego dowolnym innym SID do wstawienia do historii SID obiektu docelowego.
 Identyfikator SID wyszukiwania dla obiektu źródłowego jest uwierzytelnionym RPC przy użyciu poświadczeń administratora osoby wywołującej, z ochroną integralności komunikatów pakietów. Gwarantuje to, że nie można modyfikować wywołania zwrotnego bez wykrycia. Docelowy kontroler domeny tworzy unikatowe zdarzenie inspekcji "Dodaj historię SID", które odzwierciedla identyfikator SID dodany do konta docelowego sIDHistory.
Domena źródłowa trojana
Nieautoryzowany użytkownik tworzy domenę źródłową "Konia trojańskiego" w sieci prywatnej, która ma ten sam identyfikator SID domeny i niektóre z tych samych identyfikatorów SID konta co legalna domena źródłowa. Nieautoryzowany użytkownik próbuje następnie uruchomić DsAddSidHistory w domenie docelowej w celu uzyskania identyfikatora SID konta źródłowego. Odbywa się to bez konieczności posiadania rzeczywistych danych uwierzytelniających administratora domeny źródłowej i bez pozostawienia śladu w dzienniku w rzeczywistej domenie źródłowej. Metoda nieautoryzowanego użytkownika do tworzenia domeny źródłowej konia trojańskiego może być jedną z następujących czynności:
  • Uzyskaj kopię (kopia zapasowa usługi BDC) źródłowej domeny SAM.
  • Utwórz nową domenę, zmieniając identyfikator SID domeny na dysku tak, aby był zgodny z prawidłowym identyfikatorem SID domeny źródłowej, a następnie utwórz wystarczająco dużo użytkowników, aby utworzyć wystąpienie konta przy użyciu odpowiedniego identyfikatora SID.
  • Utwórz replikę BDC. Wymaga to poświadczeń administratora domeny źródłowej. Następnie nieautoryzowany użytkownik przenosi replikę do sieci prywatnej w celu zaimplementowania ataku.

 Chociaż istnieje wiele sposobów na pobranie lub utworzenie żądanego identyfikatora SID obiektu źródłowego, nieautoryzowany użytkownik nie może go użyć do zaktualizowania sIDHistory konta, jeśli nie jest członkiem grupy administratorów domeny docelowej. Ponieważ na docelowym kontrolerze domeny sprawdzanie członkostwa administratora domeny jest natywnie zakodowane, na docelowym kontrolerze domeny nie można zmodyfikować dysku, aby zmienić dane kontroli dostępu chroniące tę funkcję. Próba sklonowania konta źródłowego konia trojańskiego jest poddawane inspekcji w domenie docelowej. Ten atak jest ograniczany przez rezerwowanie członkostwa w grupie Administratorzy domeny tylko dla osób wysoce zaufanych.
Modyfikacja Historii SID na dysku
Zaawansowany nieautoryzowany użytkownik z poświadczeniami administratora domeny i fizycznym dostępem do kontrolera domeny w domenie docelowej mógłby zmodyfikować wartość sIDHistory konta na dysku.
 Ta próba nie jest możliwa przy użyciu DsAddSidHistory. Ten atak jest ograniczany przez zapobieganie fizycznemu dostępowi do kontrolerów domeny wszystkim z wyjątkiem wysoce zaufanych administratorów.
Nieuczciwy kod używany do usuwania zabezpieczeń
Nieautoryzowany użytkownik lub nieautoryzowany administrator z fizycznym dostępem do kodu usługi katalogowej może utworzyć nieautoryzowany kod, który:
  1. Usuwa sprawdzanie członkostwa w grupie Administratorzy domeny w kodzie.
  2. Zmienia wywołania na źródłowym kontrolerze domeny, który przypisuje identyfikator SID do LookupSidFromName, który nie jest audytowany.
  3. Usuwa wywołania dziennika inspekcji (audit log).

 Osoba mająca fizyczny dostęp do kodu DS i wystarczająco kompetentna, aby utworzyć nieuczciwy kod, ma możliwość arbitralnego modyfikowania sIDHistory atrybutu konta. Interfejs API DsAddSidHistory nie zwiększa tego ryzyka bezpieczeństwa.
Zasoby podatne na skradzione SID-y
Jeśli nieautoryzowany użytkownik zdołał użyć jednej z metod opisanych tutaj, aby zmodyfikować konto sIDHistory, i jeśli domeny zasobów interesujących ufają domenie nieautoryzowanego konta użytkownika, to nieautoryzowany użytkownik może uzyskać nieautoryzowany dostęp do zasobów skradzionego identyfikatora SID, potencjalnie bez pozostawiania śladu inspekcji w domenie konta, z której został skradziony identyfikator SID.
 Administratorzy domeny zasobów chronią swoje zasoby, konfigurując tylko te relacje zaufania, które mają sens z punktu widzenia zabezpieczeń. Korzystanie z DsAddSidHistory jest ograniczone w zaufanej domenie docelowej do członków grupy Administratorzy domeny, którzy mają już szerokie uprawnienia w zakresie ich obowiązków.
Nieautoryzna domena docelowa
Nieautoryzowany użytkownik tworzy domenę systemu Windows 2000 przy użyciu konta, którego sIDHistory zawiera identyfikator SID skradziony z domeny źródłowej. Nieautoryzowany użytkownik używa tego konta do nieautoryzowanego dostępu do zasobów.
 Nieautoryzowany użytkownik wymaga poświadczeń administratora dla domeny źródłowej w celu użycia DsAddSidHistoryi pozostawia dziennik inspekcji na źródłowym kontrolerze domeny. Nieautoryzowana domena docelowa uzyskuje nieautoryzowany dostęp tylko w innych domenach, które ufają nieautoryzowanej domenie, co wymaga uprawnień administratora w tych domenach zasobów.

Ograniczenia operacyjne

W tej sekcji opisano ograniczenia operacyjne korzystania z funkcji DsAddSidHistory.

Identyfikator SID SrcPrincipal nie może już istnieć w lesie docelowym jako identyfikator SID konta podstawowego lub w sIDHistory konta. Wyjątkiem jest to, że DsAddSidHistory nie generuje błędu podczas próby dodania identyfikatora SID do sIDHistory zawierającego identyczny identyfikator SID. To zachowanie umożliwia wielokrotne uruchamianie DsAddSidHistory z identycznymi danymi wejściowymi, co skutkuje powodzeniem i spójnym stanem końcowym w celu ułatwienia pracy deweloperów narzędzi.

Notatka

Opóźnienie replikacji Globalnego Katalogu może stworzyć okno czasowe, w którym można utworzyć zduplikowane identyfikatory SID. Jednak zduplikowane identyfikatory SID można łatwo usunąć przez administratora.

SrcPrincipal i DstPrincipal muszą należeć do następujących typów:

  • Użytkownik

  • Grupa z włączoną obsługą zabezpieczeń, w tym:

    Grupa lokalna Grupa globalna Grupa lokalna Domena lokalna (tylko tryb macierzysty systemu Windows 2000) Grupa uniwersalna (tylko tryb macierzysty systemu Windows 2000)

Typy obiektów SrcPrincipal i DstPrincipal muszą być zgodne.

  • Jeśli SrcPrincipal jest użytkownikiem, DstPrincipal musi być użytkownikiem.
  • Jeśli SrcPrincipal jest grupą lokalną lub lokalną domeny, DstPrincipal musi być grupą lokalną domeny.
  • Jeśli SrcPrincipal jest grupą globalną lub uniwersalną, DstPrincipal musi być grupą globalną lub uniwersalną.

SrcPrincipal i DstPrincipal nie mogą być jednym z następujących typów: (DsAddSidHistory kończy się niepowodzeniem z powodu błędu w tych przypadkach)

  • Komputer (stacja robocza lub kontroler domeny)

  • Zaufanie między domenami

  • Tymczasowe zduplikowane konto (praktycznie nieużywana funkcja, spuścizna LANman)

  • Konta z dobrze znanymi identyfikatorami SID. Znane SIDs są identyczne w każdej domenie; tym samym dodanie ich do sIDHistory narusza wymóg unikatowości SID w lesie Windows 2000. Konta z dobrze znanymi identyfikatorami SID obejmują następujące grupy lokalne:

    Operatorzy kont Administratorzy Operatorzy kopii zapasowych Operatorzy wydruku Operatorzy serwerów replikatora Użytkownicy

Jeśli SrcPrincipal ma dobrze znany identyfikator względny (RID) i prefiks specyficzny dla domeny, czyli administratorzy domeny, użytkownicy domeny i komputery domeny, to DstPrincipal musi posiadać ten sam dobrze znany identyfikator RID, aby operacja DsAddSidHistory zakończyła się sukcesem. Konta z dobrze znanymi identyfikatorami RID obejmują następujących użytkowników i grupy globalne:

  • Administrator
  • Gość
  • Administratorzy domeny
  • Goście domeny
  • Użytkownicy domeny

Ustawianie wartości rejestru

Poniższa procedura przedstawia sposób ustawiania wartości rejestru TcpipClientSupport.

, aby ustawić wartość rejestru TcpipClientSupport

  1. Utwórz następującą wartość rejestru jako wartość REG_DWORD na źródłowym kontrolerze domeny i ustaw jej wartość na 1.

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\TcpipClientSupport

  2. Następnie uruchom ponownie źródłowy kontroler domeny. Ta wartość rejestru powoduje, że SAM nasłuchuje na protokole TCP/IP. DsAddSidHistory zakończy się niepowodzeniem, jeśli ta wartość nie zostanie ustawiona na źródłowym kontrolerze domeny.

Włączanie audytowania zdarzeń zarządzania użytkownikami/grupami

Poniższa procedura przedstawia sposób włączania inspekcji zdarzeń zarządzania użytkownikami/grupami w domenie źródłowej lub docelowej systemu Windows Server 2000 lub Windows Server 2003.

Aby włączyć inspekcję zdarzeń zarządzania użytkownikami/grupami w domenie źródłowej lub docelowej systemu Windows 2000 albo Windows Server 2003

  1. W przystawce MMC Użytkownicy i komputery usługi Active Directory wybierz kontener kontrolerów domeny docelowej.
  2. Kliknij prawym przyciskiem myszy kontrolery domeny i wybierz pozycję właściwości .
  3. Kliknij kartę zasad grupy.
  4. Wybierz domyślne zasady kontrolerów domeny i kliknij przycisk Edytuj.
  5. W obszarze Konfiguracja komputera\Ustawienia systemu Windows\Ustawienia zabezpieczeń\Zasady lokalne\Polityka audytukliknij dwukrotnie Audyt zarządzania kontami.
  6. W oknie inspekcji zarządzania kontami wybierz zarówno powodzenia, jak i inspekcję Niepowodzenie. Aktualizacje zasad obowiązują po ponownym uruchomieniu lub po odświeżeniu.
  7. Sprawdź, czy inspekcja jest włączona, wyświetlając obowiązującą politykę inspekcji w przystawce MMC Zasad Grup.

Poniższa procedura przedstawia sposób włączania inspekcji zdarzeń zarządzania użytkownikami/grupami w domenie systemu Windows NT 4.0.

Aby włączyć inspekcję zdarzeń zarządzania użytkownikami/grupami w domenie systemu Windows NT 4.0

  1. W programie User Manager for Domainskliknij menu Zasady i wybierz pozycję Audyt.
  2. Wybierz pozycję Przeprowadź inspekcję tych zdarzeń.
  3. Dla zarządzania użytkownikami i grupami, sprawdź powodzenie i niepowodzenie.

Poniższa procedura przedstawia sposób włączania inspekcji zdarzeń zarządzania użytkownikami/grupami w domenie źródłowej systemu Windows NT 4.0, Windows 2000 lub Windows Server 2003.

Aby włączyć inspekcję zdarzeń zarządzania użytkownikami/grupami w domenie źródłowej systemu Windows NT 4.0, Windows 2000 lub Windows Server 2003

  1. W programie User Manager for Domainskliknij menu użytkownika i wybierz pozycję Nowa grupa lokalna.
  2. Wprowadź nazwę grupy składającą się z nazwy NetBIOS domeny źródłowej, do której dołączono trzy znaki dolara ($), na przykład FABRIKAM$$$. Pole opisu powinno wskazywać, że ta grupa jest używana do inspekcji użycia DsAddSidHistory lub operacji klonowania. Upewnij się, że w grupie nie ma żadnych członków. Kliknij przycisk OK.

Operacja DsAddSidHistory kończy się niepowodzeniem, jeśli inspekcja źródła i miejsca docelowego nie jest włączona zgodnie z opisem w tym miejscu.

Konfigurowanie zaufania, jeśli jest to wymagane

Jeśli jedno z poniższych jest prawdziwe, należy ustanowić relację zaufania z domeny źródłowej do domeny docelowej (musi to nastąpić w innym lesie domenowym):

  • Domena źródłowa to Windows Server 2003.
  • Domena źródłowa to Windows NT 4.0 i SrcDomainCreds jest NULL.
  • Last updated on