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.
W tym artykule opisano sposób oznaczania atrybutu jako poufnego w systemie Windows Server 2003 z dodatkiem Service Pack 1.
Dotyczy: Windows Server 2003
Oryginalny numer KB: 922836
Podsumowanie
W usłudze katalogowej Active Directory dla systemu Microsoft Windows Server 2000 i Microsoft Windows Server 2003 trudno jest zapobiec odczytywaniu atrybutu przez uwierzytelnionego użytkownika. Ogólnie rzecz biorąc, jeśli użytkownik żąda READ_PROPERTY uprawnień dla atrybutu lub jego zestawu właściwości, dostęp do odczytu jest udzielany. Domyślne zabezpieczenia w usłudze Active Directory są ustawione tak, aby uwierzytelnieni użytkownicy mieli dostęp do odczytu do wszystkich atrybutów. W tym artykule omówiono sposób zapobiegania dostępowi do odczytu atrybutu w dodatku Service Pack 1 (SP1) systemu Windows Server 2003.
Więcej informacji
System Windows Server 2003 z dodatkiem SP1 wprowadza sposób oznaczania atrybutu jako poufnego. W tym celu należy zmodyfikować wartość atrybutu searchFlags w schemacie. Wartość atrybutu searchFlags zawiera wiele bitów reprezentujących różne właściwości atrybutu. Na przykład jeśli bit 1 jest ustawiony, atrybut jest indeksowany. Bit 7 (128) wyznacza atrybut jako poufny.
Wymagania i ograniczenia
Tylko kontrolery domeny z systemem Windows Server 2003 z dodatkiem SP1 lub nowszą wersją wymuszają sprawdzanie dostępu do odczytu dla atrybutów poufnych. Funkcja atrybutów poufnych jest powiązana z instalacją systemu Windows Server 2003 z dodatkiem SP1 lub nowszą wersją. Ta funkcja nie zależy od tego, czy jest włączona domena, czy poziom funkcjonalności lasu.
Nie używaj funkcji atrybutów poufnych, chyba że spełnione są następujące warunki:
Wszystkie kontrolery domeny oparte na systemie Windows Server 2003 mają zainstalowany system Windows Server 2003 z dodatkiem SP1 lub nowszą wersję.
Wszystkie kontrolery domeny oparte na systemie Windows 2000 zostały uaktualnione lub usunięte. Jeśli domena zawiera kombinację kontrolerów domeny z systemem Windows 2000 Server, oryginalna wersja systemu Windows Server 2003 i Windows Server 2003 z dodatkiem SP1, może wystąpić następujący scenariusz:
Jeśli nieautoryzowany klient wysyła zapytanie do kontrolerów domeny opartych na systemie Windows 2000 Server i Windows Server 2003 pod kątem poufnych danych atrybutów, klient może odczytać dane.
Jeśli nieautoryzowany klient wysyła zapytanie do kontrolera domeny opartego na systemie Windows Server 2003 z dodatkiem SP1 na potrzeby poufnych danych atrybutów, klient nie może odczytać danych. Nie można oznaczyć atrybutu schematu podstawowego jako poufnego. Identyfikator pracownika jest przykładem podstawowego atrybutu schematu. Nie można oznaczyć tego atrybutu jako poufnego, ponieważ jego systemsFlags wartość atrybutu jest ustawiona na 0x10 (schemat podstawowy). Aby uzyskać więcej informacji, zobacz sekcję "How to determine an attribute is a base schema attribute" (Jak określić wartość atrybutu searchFlags w przypadku używania istniejącego atrybutu).
Testowanie
Ponieważ testujesz wszelkie zmiany w usłudze Active Directory i dowolnym rozszerzeniu schematu, zalecamy dokładne przetestowanie zmian atrybutów w laboratorium, które odzwierciedla las produkcyjny. Testowanie pomaga zagwarantować, że procedura działa płynnie i że wykryto problemy.
Kontrole kontroli dostępu
Po zainstalowaniu systemu Windows Server 2003 z dodatkiem SP1 i po wykonaniu kontroli dostępu do odczytu usługa Active Directory sprawdza atrybuty poufne. Jeśli istnieją atrybuty poufne i jeśli READ_PROPERTY uprawnienia są ustawione dla tych atrybutów, usługa Active Directory będzie również wymagać CONTROL_ACCESS uprawnień dla atrybutów lub ich zestawów właściwości.
Uwaga
Ustawienie uprawnień Pełna kontrola zawiera uprawnienie CONTROL_ACCESS.
Usługa Active Directory przeprowadza sprawdzanie dostępu do odczytu na obiekcie w następujących przypadkach:
- Podczas oceniania, czy obiekt jest zgodny z filtrem wyszukiwania.
- Gdy zwracasz atrybuty obiektu zgodnego z filtrem wyszukiwania. Domyślnie tylko administratorzy mają CONTROL_ACCESS uprawnienia do wszystkich obiektów. W związku z tym tylko administratorzy mogą odczytywać poufne atrybuty. Administratorzy mogą delegować te uprawnienia do dowolnego użytkownika lub dowolnej grupy.
Ogólne i specyficzne dla obiektu wpisy kontroli dostępu
Każdy obiekt w usłudze Active Directory ma skojarzone z nim informacje dotyczące kontroli dostępu. Te informacje są nazywane deskryptorem zabezpieczeń. Deskryptor zabezpieczeń kontroluje typ dostępu, który jest dostępny dla użytkowników i grup. Deskryptor zabezpieczeń jest tworzony automatycznie podczas tworzenia obiektu.
Zestaw wpisów uprawnień w deskryptorze zabezpieczeń jest nazywany uznaniową listą kontroli dostępu (DACL). Każdy wpis uprawnień w daCL jest znany jako wpis kontroli dostępu (ACE).
Uprawnienia do obiektu można przyznać lub przyznać CONTROL_ACCESS uprawnienia do atrybutów poufnych przy użyciu wpisu kontroli dostępu specyficznego dla obiektu lub ogólnego lub obiektu. Uprawnienia można przyznać, oznaczając je jawnie w obiekcie lub przy użyciu dziedziczenia. Dziedziczenie oznacza, że ustawiono dziedziczony wpis kontroli dostępu w kontenerze, który jest wyższy w hierarchii kontenerów.
Ogólne i specyficzne dla obiektu wpisy kontroli dostępu są w zasadzie takie same. To, co odróżnia je od siebie, to stopień kontroli nad tym, że wpisy kontroli dostępu oferują dziedziczenie i dostęp do obiektów. Ogólne wpisy kontroli dostępu dotyczą całego obiektu. Wpisy kontroli dostępu specyficzne dla obiektu zapewniają większą kontrolę nad tym, które obiekty dziedziczą wpis kontroli dostępu. W przypadku korzystania z wpisu kontroli dostępu specyficznego dla obiektu można określić atrybut lub zestaw właściwości obiektu, który będzie dziedziczyć wpis kontroli dostępu.
Jeśli używasz funkcji atrybutów poufnych, CONTROL_ACCESS uprawnienie jest przyznawane przez przypisanie ogólnego wpisu kontroli dostępu do użytkownika. Jeśli uprawnienie CONTROL_ACCESS zostanie przyznane przez przypisanie wpisu kontroli dostępu specyficznego dla obiektu, użytkownik będzie miał tylko CONTROL_ACCESS uprawnienia do poufnego atrybutu.
Następujące uprawnienia są przyznawane podczas korzystania z ogólnego wpisu kontroli dostępu:
- Wszystkie prawa rozszerzone
- Dozwolone do uwierzytelniania
- Zmień hasło
- Odbierz jako
- Resetuj hasło
- Wyślij jako
Uprawnienia, które są przyznawane w przypadku korzystania z ogólnego wpisu kontroli dostępu, mogą zapewnić więcej dostępu niż jest wymagany w całym obiekcie. Jeśli jest to problem, można ustawić wpis kontroli dostępu specyficzny dla obiektu w obiekcie, tak aby wpis kontroli dostępu dotyczył tylko atrybutu poufnego. W przypadku używania wpisów kontroli dostępu specyficznych dla obiektu można kontrolować właściwość lub właściwość ustawioną na wpis kontroli dostępu.
Interfejs użytkownika w systemie Windows Server 2003 nie uwidacznia uprawnień Control_Access. Za pomocą narzędzia Dsacls.exe można ustawić uprawnienia Control_Access, przypisując ogólny wpis kontroli dostępu. Nie można jednak użyć tego narzędzia do przypisania wpisu kontroli dostępu specyficznego dla obiektu. Jedynym narzędziem, które może ustawić uprawnienia Control_Access przez przypisanie wpisu kontroli dostępu specyficznego dla obiektu, jest narzędzie Ldp.exe.
Uwaga
Szczegółowe omówienie kontroli dostępu wykracza poza zakres tego artykułu. Aby uzyskać więcej informacji na temat kontroli dostępu, odwiedź następujące witryny sieci Web firmy Microsoft:
Kontrola dostępu (autoryzacja)
Zarządzanie tożsamościami i kontrola dostępu
Jak używać dziedziczenia
W dużej domenie nie jest praktyczne ręczne przypisywanie kontroli dostępu do użytkownika lub do grupy dla każdego obiektu, który ma poufny atrybut. Rozwiązaniem jest użycie dziedziczenia w celu ustawienia dziedziczonego wpisu kontroli dostępu, który jest wyższy w hierarchii kontenerów. Ten wpis kontroli dostępu dotyczy wszystkich obiektów podrzędnych tego kontenera.
Domyślnie dziedziczenie jest włączone dla wszystkich jednostek organizacyjnych (OU) i dla wszystkich kont użytkowników, z wyjątkiem wbudowanego konta administratora. Jeśli tworzysz konta użytkowników, które mają wyłączone dziedziczenie lub jeśli tworzysz konta administracyjne, kopiując wbudowane konto administratora, musisz włączyć dziedziczenie dla tych kont. W przeciwnym razie model dziedziczenia nie ma zastosowania do tych kont.
Jak utworzyć atrybut poufny
- Określ atrybut, który ma zostać oznaczyny jako poufny, lub dodaj atrybut, który ma być poufny.
- Przyznaj odpowiednim użytkownikom Control_Access uprawnienia, aby użytkownicy mogli wyświetlać dane atrybutów.
Narzędzia, takie jak narzędzie Ldp.exe i narzędzie Adsiedit.msc, mogą służyć do tworzenia atrybutu poufnego. Pliki ldf są zwykle używane do rozszerzania schematu. Te pliki mogą również służyć do oznaczania atrybutu jako poufnego. Pliki tworzone na potrzeby implementacji powinny być dostrojone w fazie testowania, aby dokładnie wiedzieć, co dodajesz do schematu podczas wdrażania w środowisku produkcyjnym. Pliki ldf pomagają zapobiegać błędom.
Następujące przykładowe pliki ldf mogą służyć do wykonywania następujących czynności:
- Dodawanie atrybutu do schematu
- Oznaczanie atrybutu jako poufnego
- Dodawanie atrybutu do klasy użytkownika
Uwaga
Przed użyciem plików ldf upewnij się, że przeczytasz sekcje "Identyfikatory obiektów" i "Składnia atrybutów", aby uzyskać ważne informacje na temat dodawania obiektów i atrybutów do schematu.
Przykładowe pliki ldf
Poniższy kod dodaje atrybut do schematu, a następnie oznacza atrybut jako poufny.
dn: CN=ConfidentialAttribute-LDF,CN=Schema,Cn=Configuration,DC=domain,DC=com
changetype: add
objectClass: attributeSchema
lDAPDisplayName: ConfidentialAttribute
adminDescription: ten atrybut przechowuje poufne dane użytkownika
attributeID: 1.2.840.113556.1.xxxx.xxxx.1.x
attributeSyntax: 2.5.5.12
oMSyntax: 64
isSingleValued: TRUE
showInAdvancedViewOnly: TRUE
searchFlags: 128Dn:
changeType: modify
add: schemaupdatenow
schemaupdatenow: 1
-
Poniższy kod dodaje nowy atrybut do klasy użytkownika.
dn: CN=User,CN=Schema,CN=Configuration,DC=domain,DC=com
changetype: modify
add: mayContain
mayContain: ConfidentialAttribute
-Dn:
changeType: modify
add: schemaupdatenow
schemaupdatenow: 1
-
Jak umożliwić użytkownikom niebędącym administratorami wyświetlanie danych atrybutów
Uwaga
Poniższe procedury wymagają użycia narzędzia Ldp.exe dołączonego do trybu aplikacji usługi Active Directory (ADAM) systemu Windows Server 2003 R2. Inne wersje narzędzia Ldp.exe nie mogą ustawić uprawnień.
Jak ręcznie ustawić uprawnienia Control_Access na koncie użytkownika
- Otwórz narzędzie Ldp.exe dołączone do systemu Windows Server 2003 R2 ADAM.
- Połącz się i powiąż z katalogiem.
- Wybierz konto użytkownika, kliknij prawym przyciskiem myszy konto, kliknij pozycję Zaawansowane, kliknij pozycję Deskryptor zabezpieczeń, a następnie kliknij przycisk OK.
- W polu DACL kliknij pozycję Dodaj ACE.
- W polu Trustee wpisz nazwę grupy lub nazwę użytkownika, do którego chcesz udzielić uprawnień.
- W polu Kontrola dostępu sprawdź zmiany wprowadzone w kroku 5.
Jak przypisywać uprawnienia Control_Access przy użyciu dziedziczenia
Aby użyć dziedziczenia, utwórz wpis kontroli dostępu, który przyznaje Control_Access uprawnienia do żądanych użytkowników lub grup, które są wyższe w hierarchii kontenerów niż obiekty, które mają poufne atrybuty. Ten wpis kontroli dostępu można ustawić na poziomie domeny lub w dowolnym momencie w hierarchii kontenerów, która działa dobrze dla przedsiębiorstwa. Obiekty podrzędne, które mają poufne atrybuty, muszą mieć włączone dziedziczenie.
Aby przypisać uprawnienia Control_Access, wykonaj następujące kroki:
Otwórz plik Ldp.exe dołączony do systemu Windows Server 2003 R2 ADAM.
Łączenie i wiązanie z katalogiem.
Wybierz jednostkę organizacyjną lub kontener, który jest wyższy w hierarchii kontenerów niż obiekty z atrybutami poufnymi, kliknij prawym przyciskiem myszy jednostkę organizacyjną lub kontener, kliknij pozycję Zaawansowane, kliknij pozycję Deskryptor zabezpieczeń, a następnie kliknij przycisk OK.
W polu DACL kliknij pozycję Dodaj ACE.
W polu Trustee wpisz nazwę grupy lub nazwę użytkownika, do którego chcesz udzielić uprawnień.
W polu Kontrola dostępu sprawdź zmiany wprowadzone w kroku 5.
W polu Typ obiektu kliknij dodany atrybut poufny.
Upewnij się, że dziedziczenie jest włączone w obiektach docelowych.
Jak określić wartość atrybutu systemFlags podczas korzystania z istniejącego atrybutu
Jeśli używasz istniejącego obiektu, musisz sprawdzić, jaka jest bieżąca wartość atrybutu searchFlags. Jeśli dodasz obiekt, możesz zdefiniować wartość podczas dodawania obiektu. Istnieje wiele sposobów uzyskania wartości atrybutu searchFlags. Użyj metody, która działa najlepiej dla Ciebie.
Aby uzyskać wartość atrybutu searchFlags za pomocą narzędzia Ldp.exe, wykonaj następujące kroki:
Kliknij przycisk Start, kliknij przycisk Uruchom, wpisz LDP, a następnie kliknij przycisk OK.
Kliknij pozycję Połączenie, a następnie kliknij pozycję Powiąż.
Powiąż jako administrator domeny głównej lub powiąż jako konto, które jest administratorem przedsiębiorstwa.
Kliknij pozycję Widok, a następnie kliknij pozycję Drzewo.
Kliknij pozycję CN=schema,cn=configuration,dc=rootdomain, a następnie kliknij przycisk OK.
W okienku po lewej stronie rozwiń węzeł CN=schema,cn=configuration,dc=rootdomain.
Znajdź nazwę domeny atrybutu, który chcesz oznaczyć jako poufne, a następnie rozwiń go.
Na liście atrybutów, które są wypełniane dla obiektu, znajdź searchFlags , aby określić bieżącą wartość atrybutu searchFlags dla tego obiektu.
Uwaga
Aby określić nową wartość atrybutu searchFlags, użyj następującej formuły:
128 + currentsearchFlagsattribute wartość =
newsearchFlagsattribute.
Jak określić, czy atrybut jest atrybutem schematu podstawowego
Aby określić, czy atrybut jest atrybutem schematu podstawowego, użyj narzędzia Ldp.exe do zbadania wartości atrybutu systemFlags.
Dane wyjściowe LDP identyfikatora pracownika — systemFlags: 0x10 = (FLAG_SCHEMA_BASE_OBJECT)
W poniższych przykładowych danych wyjściowych Ldp.exe Ldp.exe identyfikuje wartość atrybutu systemFlags jako 0x10 i jako atrybut schematu podstawowego. W związku z tym nie można oznaczyć tego atrybutu jako poufnego.
>> Dn: CN=Employee-ID,CN=Schema,CN=Configuration,DC=domain,DC=com
2> objectClass: top; attributeSchema;
1> cn: Identyfikator pracownika;
1> nazwa wyróżniająca: CN=Employee-ID,CN=Schema,CN=Configuration,DC=domain,DC=com;
1> instanceType: 0x4 = ( IT_WRITE );
1> po utworzeniu: <Data/godzina>;
1> , gdyChanged: <DateTime>;
1> uSNTworzenie: 220;
1> attributeID: 1.2.840.113556.1.4.35;
1> atrybutSyntax: 2.5.5.12 = ( SYNTAX_UNICODE_TYPE );
1> isSingleValued: TRUE;
1> zakresLower: 0;
1> zakresUpper: 16;
1> uSNChanged: 220;
1> showInAdvancedViewOnly: TRUE;
1> adminDisplayName: Employee-ID;
1> adminDescription: Employee-ID;
1> oMSyntax: 64 = ( OM_S_UNICODE_STRING );
1> searchFlags: 0x0 = ( );
1> lDAPDisplayName: employeeID;
1> nazwa: Identyfikator pracownika;
1> objectGUID: 64fb3ed1-338f-466e-a879-595bd3940ab7;
1> schemaIDGUID: bf967962-0de6-11d0-a285-00aa0303049e2;
1> systemOnly: FALSE;
1> systemFlags: 0x10 = ( FLAG_SCHEMA_BASE_OBJECT );
1> objectCategory: CN=Attribute-Schema,CN=Schema,CN=Configuration,DC=domain,DC=com;
Dane wyjściowe LDP elementu SystemFlags numer pracownika: 0x0 = ( )
W poniższych przykładowych danych wyjściowych Ldp.exe Ldp.exe identyfikuje wartość atrybutu systemFlags jako 0. Ten atrybut może być oznaczony jako poufny.
>> Dn: CN=Employee-Number,CN=Schema,CN=Configuration,DC=warrenw,DC=com
2> objectClass: top; attributeSchema;
1> cn: Numer pracownika;
1> distinguishedName: CN=Employee-Number,CN=Schema,CN=Configuration,DC=warrenw,DC=com;
1> instanceType: 0x4 = ( IT_WRITE );
1> po utworzeniu: <Data/godzina>;
1> , gdyChanged: <DateTime>;
1> uSNTworzenie: 221;
1> attributeID: 1.2.840.113556.1.2.610;
1> atrybutSyntax: 2.5.5.12 = ( SYNTAX_UNICODE_TYPE );
1> isSingleValued: TRUE;
1> zakresLower: 1;
1> rangeUpper: 512;
1> mAPIID: 35943;
1> uSNChanged: 221;
1> showInAdvancedViewOnly: TRUE;
1> adminDisplayName: Employee-Number;
1> adminDescription: Employee-Number;
1> oMSyntax: 64 = ( OM_S_UNICODE_STRING );
1> searchFlags: 0x0 = ( );
1> lDAPDisplayName: employeeNumber;
1> nazwa: Numer pracownika;
1> objectGUID: 2446d04d-b8b6-46c7-abbf-4d8e7e1bb6ec;
1> schemaIDGUID: a8df73ef-c5ea-11d1-bbcb-0080c76670c0c0;
1> systemOnly: FALSE;
1> systemFlags: 0x0 = ( );
1> objectCategory: CN=Attribute-Schema,CN=Schema,CN=Configuration,DC=warrenw,DC=com;
Identyfikatory obiektów
Po dodaniu atrybutu lub obiektu klasy do schematu jeden z wymaganych atrybutów jest identyfikatorem obiektu (nazywanym również identyfikatorem OID). Identyfikatory obiektów służą do unikatowego definiowania klas i atrybutów obiektów. Upewnij się, że firma uzyskuje unikatowy identyfikator obiektu w celu zidentyfikowania jego atrybutu. Narzędzia generujące identyfikatory obiektów, takie jak narzędzie Oidgen.exe, nie są obsługiwane. Aby uzyskać identyfikator obiektu od firmy Microsoft, odwiedź następującą witrynę sieci Web firmy Microsoft:
Uzyskiwanie identyfikatora obiektu od firmy Microsoft
Składnia atrybutów
Atrybut AtrybutSyntax jest również wymagany do dodawania nowych obiektów do schematu. Ten atrybut definiuje reprezentację magazynu, kolejność bajtów i pasujące reguły dla porównań typów właściwości. Składnia określa, czy wartość atrybutu musi być ciągiem, liczbą, czy jednostką czasu. Każdy atrybut każdego obiektu jest skojarzony z dokładnie jedną składnią. Upewnij się, że wybrano poprawną składnię atrybutu dla nowego atrybutu. Jest to szczególnie ważne w przypadku synchronizowania katalogu LDAP (Lightweight Directory Access Protocol) z innym katalogiem LDAP. Po dodaniu atrybutu do schematu nie można zmienić jego składni atrybutu.
Aby uzyskać więcej informacji na temat atrybutu AttributeSyntax, zobacz Atrybut-Składnia atrybutu.
Aby uzyskać więcej informacji, zobacz atrybut Search-Flags.