Omówienie protokołu Kerberos w usłudze Azure NetApp Files

Kerberos to protokół uwierzytelniania, który używa klucza tajnego do weryfikowania tożsamości podmiotów zabezpieczeń. Klucze tajne są generowane przez pobranie hasła podmiotu zabezpieczeń i przekonwertowanie go na skrótowy format klucza kryptograficznego przy użyciu uzgodnionej metody szyfrowania przez klienta i serwera (na przykład AES). Zapoznaj się z sekcją terminologii protokołu Kerberos, aby dowiedzieć się więcej o terminach używanych w tym dokumencie.

Centra dystrybucji kluczy (KDC), takie jak usługa Windows Active Directory, utrzymują bazę danych podmiotów zabezpieczeń protokołu Kerberos i ich skrótowe hasła. W protokole Kerberos klucz tajny jest dowodem unikatowej tożsamości. W związku z tym centrum dystrybucji kluczy może być zaufane w celu uwierzytelnienia dowolnego podmiotu zabezpieczeń dowolnego podmiotu zabezpieczeń, takiego jak uwierzytelnianie głównej nazwy usługi klienta NFS (SPN) na serwerze NFS SPN podczas instalacji. Może być również zaufany do uwierzytelniania podmiotu zabezpieczeń użytkownika na serwerze NFS w celu uzyskania dostępu użytkownika do punktu instalacji NAS. Jako dodatkowa miara zabezpieczeń protokół Kerberos nie wysyła haseł w postaci zwykłego tekstu na potrzeby uwierzytelniania za pośrednictwem przewodu.

Usługa Azure NetApp Files obsługuje korzystanie z protokołu Kerberos w celu zapewnienia bezpieczeństwa w locie zarówno dla protokołów SMB, jak i NFS.

Obsługiwane typy szyfrowania

Usługa Azure NetApp Files obsługuje protokół Kerberos systemu plików NFS z określonymi typami szyfrowania w zależności od trybu operacyjnego i używanej wersji.

Aby upewnić się, że klient używa odpowiedniego typu szyfrowania, można ograniczyć prawidłowe typy szyfrowania w jednostce obiektu znajdującej się w centrum dystrybucji kluczy (na przykład na koncie komputera) lub w ręcznym pliku tworzenia klucza klienta, a nie globalnie w pliku /etc/krb5.conf, jeśli to możliwe, ponieważ zarządzanie wieloma plikami krb5.conf klienta może być bólem głowy zarządzania. Centralnie zarządzanie kerberos z centrum dystrybucji kluczy jest bardziej skalowalne w dużych środowiskach przedsiębiorstwa, jest łatwiejsze do automatyzacji i wymusza na kliencie użycie silniejszych typów szyfrowania, gdy są one obsługiwane.

Uwaga

Zaleca się ustawienie opcji allow_weak_crypto false w pliku krb5.conf na klientach. To ustawienie zapobiega mniejszemu zabezpieczeniu enctypes komunikacji kerberos (takiej jak DES lub 3DES).

W poniższej tabeli przedstawiono obsługiwane typy szyfrowania dla protokołu Kerberos (zarówno SMB, jak i NFS) dla usługi Azure NetApp Files.

Protokół	Obsługiwane typy szyfrowania
SMB	RC4-HMAC AES-128 AES 256
NFS	AES 256

Obsługiwane tryby zabezpieczeń Kerberos systemu plików NFS

Oprócz koncepcji typów szyfrowania istnieją również poziomy zabezpieczeń i sprawdzania integralności w protokole Kerberos. W zależności od używanego trybu zabezpieczeń te tryby zabezpieczeń pomagają zapobiegać atakom typu man-in-the-middle, oferując kompleksowe szyfrowanie ruchu NFS.

W usłudze Azure NetApp Files te tryby zabezpieczeń są określane w regułach zasad eksportu ustawionych dla woluminu dla systemu plików NFS i zdefiniowanych podczas początkowej instalacji systemu plików NFS za pośrednictwem opcji instalacji s.

Na przykład: # mount -o sec=krb5p

Uwaga

W przypadku protokołu Kerberos protokołu SMB tryby zabezpieczeń protokołu Kerberos są kontrolowane za pośrednictwem ustawień szyfrowania SMB w udziale, wzmacniania zabezpieczeń UNC i podpisywania/uszczelniania protokołu SMB na kontrolerach domeny.

Następujące tryby zabezpieczeń są obsługiwane przez usługę Azure NetApp Files do użycia z systemem plików NFS Kerberos:

Tryb zabezpieczeń	opis
krb5	Tylko szyfrowanie uwierzytelniania. Używa ciągów nazw protokołu Kerberos V5 i głównych nazw użytkowników zamiast identyfikatorów lokalnych użytkowników systemu UNIX (UID) i identyfikatorów grup (GID) do uwierzytelniania użytkowników.
krb5i	Szyfrowanie uwierzytelniania i sprawdzanie integralności zaszyfrowanej. Używa protokołu Kerberos V5 do uwierzytelniania użytkowników, a także przeprowadza sprawdzanie integralności operacji NFS przy użyciu bezpiecznych sum kontrolnych, aby zapobiec manipulowaniu danymi i atakom typu man-in-the-middle.
krb5p	Cała konwersacja systemu plików NFS jest zaszyfrowana. Używa protokołu Kerberos V5 do uwierzytelniania i sprawdzania integralności użytkownika, a także szyfruje cały ruch NFS, aby zapobiec wąchaniu pakietów. To ustawienie jest najbezpieczniejsze, ale tworzy również największe obciążenie związane z wydajnością.

Terminologia protokołu Kerberos

W tej sekcji zdefiniowano kluczową terminologię używaną podczas opisywania procesów protokołu Kerberos. Ta sekcja ma pomóc w wyjaśnieniu terminów, które mogą być nieznane administratorom magazynu.

Termin	Definicja
Centrum dystrybucji kluczy (KDC)	Centrum dystrybucji kluczy to serwer uwierzytelniania, który obejmuje usługę przyznawania biletów (TGS) i usługę uwierzytelniania (AS). Terminy KDC, AS i TGS są używane zamiennie. W środowiskach firmy Microsoft kontroler domeny usługi Active Directory jest centrum dystrybucji kluczy.
Obszar (lub obszar Kerberos)	Obszar (lub obszar Kerberos) może używać dowolnego ciągu ASCII. Standardem jest użycie nazwy domeny w wielkich literach; na przykład contoso.com staje się obszarem CONTOSO.COM. Obszary Protokołu Kerberos są zwykle konfigurowane w plikach krb5.conf na klientach i serwerach. W sposób administracyjny każdy principal@REALM musi być unikatowy. Aby uniknąć pojedynczego punktu awarii, każdy obszar może mieć wiele kontrolerów KDC, które współużytkują tę samą bazę danych (podmioty zabezpieczeń i ich hasła) i mają te same klucze główne centrum dystrybucji kluczy dystrybucji kluczy. Usługa Microsoft Windows Active Directory wykonuje to natywnie za pomocą replikacji usługi Active Directory, która odbywa się domyślnie co 15 minut.
Główne	Termin podmiot zabezpieczeń odnosi się do każdej jednostki w bazie danych Kerberos. Użytkownicy, komputery i usługi są przypisanymi podmiotami zabezpieczeń na potrzeby uwierzytelniania Kerberos. Każdy podmiot zabezpieczeń musi być unikatowy w bazie danych Kerberos i jest definiowany przez jego nazwę wyróżniającą. Podmiot zabezpieczeń może być główną nazwą użytkownika (UPN) lub nazwą główną usługi (SPN). Główna nazwa ma trzy części: Primary — podstawową częścią może być użytkownik lub usługa, taka jak usługa NFS. Może to być również specjalna usługa "host", co oznacza, że ta jednostka usługi jest skonfigurowana w celu zapewnienia wielu różnych usług sieciowych. Wystąpienie — ta część jest opcjonalna w przypadku użytkownika. Użytkownik może mieć więcej niż jeden podmiot zabezpieczeń, ale każdy podmiot zabezpieczeń musi być unikatowy w centrum dystrybucji kluczy. Na przykład Fred może mieć podmiot zabezpieczeń przeznaczony do codziennego użytku (fred@contoso.com) i podmiot zabezpieczeń, który umożliwia uprzywilejowane użycie, takie jak konto administratora systemu (admin-fred@contoso.com). Wystąpienie jest wymagane dla jednostek usługi i wyznacza w pełni kwalifikowaną nazwę domeny (FQDN) hosta udostępniającego usługę. Obszar — obszar Kerberos to zestaw podmiotów zabezpieczeń protokołu Kerberos zarejestrowanych na serwerze Kerberos. Zgodnie z konwencją nazwa obszaru jest zwykle taka sama jak nazwa DNS, ale jest konwertowana na wielkie litery. Wielkie litery nie są obowiązkowe, ale konwencja zapewnia łatwe rozróżnienie między nazwą DNS a nazwą obszaru.
Bilety	Bilet to tymczasowy zestaw poświadczeń, który weryfikuje tożsamość jednostki usługi i zawiera klucz sesji. Bilet może być usługą, biletem aplikacji lub biletem przyznawania biletów (TGT). Bilety są wymieniane między klientem, serwerem i centrum dystrybucji kluczy na potrzeby uwierzytelniania Kerberos.
Klucze tajne	Protokół Kerberos używa systemu kluczy symetrycznych, w którym klucz tajny jest używany do szyfrowania i odszyfrowywania. Klucz tajny jest generowany na podstawie hasła Kerberos podmiotu z funkcją skrótu jednokierunkowego. Centrum dystrybucji kluczy przechowuje hasło dla każdego podmiotu zabezpieczeń i w ten sposób może wygenerować klucz tajny podmiotu zabezpieczeń. W przypadku użytkowników, którzy żądają usługi Kerberos, klucz tajny zazwyczaj pochodzi z hasła przedstawionego programowi kinit. Jednostki usługi i demona zwykle nie używają hasła; zamiast tego wynik funkcji skrótu jednokierunkowego jest przechowywany w karcie.
Kartę	Na karcie kluczy znajduje się lista podmiotów zabezpieczeń i ich kluczy tajnych. Klucze tajne na karcie kluczy są często tworzone przy użyciu losowego hasła i są używane głównie dla jednostek usługi lub demona.

Informacje o porcie sieci

W poniższej tabeli opisano, które porty sieciowe są używane do komunikacji kerberos. Jeśli zapora sieciowa jest włączona, te porty powinny być otwarte, aby umożliwić prawidłowe działanie protokołu Kerberos. Więcej informacji na temat tych portów można znaleźć w rejestrze numerów portów protokołu IANA i IANA.

Usługa	Port
Kerberos	88 (TCP/UDP)
kpasswd	464 (TCP/UDP)
Uproszczony protokół dostępu do katalogów (LDAP) (dla mapowań nazw)	389 (TCP/UDP)
Serwer administracyjny	749 (TCP/UDP)
Wykaz globalny (wyszukiwania użytkowników systemu Windows)	3268 (TCP/UDP)

Wartości wieku pamięci podręcznej w usłudze Azure NetApp Files

W poniższej tabeli przedstawiono czas, przez jaki wpis pamięci podręcznej znajduje się w woluminie usługi Azure NetApp Files.

Pamięć podręczna	Wiek pamięci podręcznej
Bezczynne połączenia serwera nazw	60 s
Przekroczono limit czasu zapytania LDAP	10 sekund
Lokalny wpis hosta DNS dla czasu wygaśnięcia centrum dystrybucji kluczy	24 godz.
Wiek biletu protokołu Kerberos	Określone przez centrum dystrybucji kluczy* i/lub klienta * Domyślnie 10 godzin dla kontrolerów KDC usługi Active Directory systemu Windows
Poświadczenia użytkownika	24 godz.
Niesymetryczność czasu protokołu Kerberos	5 min

Wymagania dotyczące prawidłowego działania środowisk Kerberos w usłudze Azure NetApp Files

Uwierzytelnianie Kerberos jest bardzo zależne od usług zewnętrznych w celu zapewnienia odpowiedniej funkcjonalności. W usłudze Microsoft Active Directory większość tych usług jest łączona w jeden serwer w wielu przypadkach. Na przykład kontroler domeny usługi Active Directory może obsługiwać następujące zależności protokołu Kerberos:

• Usługi synchronizacji czasu
• DNS
• Dystrybucja kluczy Kerberos
• Usługi haseł/logowanie jednokrotne
• Usługi tożsamości (takie jak LDAP)

W przypadku korzystania z natywnej usługi Microsoft Active Directory (jedynym typem centrum dystrybucji kluczy obsługiwanej obecnie przez usługę Azure NetApp Files), większość zależności zewnętrznych dla protokołu Kerberos w usłudze Azure NetApp Files są objęte usługami DNS, KDC i password. W niektórych przypadkach wymagane usługi mogą być hostowane poza domeną usługi Active Directory (np . DNS). W takich przypadkach ważne jest, aby upewnić się, że wymagane usługi są prawidłowo skonfigurowane.

Usługa Azure NetApp Files ma określone zależności dotyczące prawidłowego działania protokołu Kerberos systemu plików NFS. Kontynuuj czytanie, aby uzyskać więcej informacji.

Usługi synchronizacji czasu

Usługi synchronizacji czasu są obowiązkowe w przypadku korzystania z protokołu Kerberos do uwierzytelniania, ponieważ mechanizmy biletów Protokołu Kerberos zależą od niesymetryczności czasu między klientem a serwerem należącym do domyślnego zakresu 5 minut. Jeśli ustawienia czasu na kliencie lub serwerze przekraczają ten pięciominutowy zakres, uwierzytelnianie Kerberos kończy się niepowodzeniem z błędem niesymetryczności czasu (KRB_AP_ERR_SKEW) i odmowa dostępu do udziału NAS. Ten limit czasu jest funkcją zabezpieczeń, która pomaga zapobiegać "atakom powtarzania", w której osoba atakująca może przechwytywać komunikaty między centrum dystrybucji kluczy a klientem, a następnie odtwarzać te komunikaty w późniejszym czasie, aby personifikować uwierzytelnionego użytkownika. Limity niesymetryczności czasu pomagają zminimalizować ryzyko ataków tego typu.

Kluczowe zagadnienia dotyczące problemów z synchronizacją czasu:

• Serwery czasu zewnętrznego (takie jak te znalezione w NIST) powinny być skonfigurowane do użytku z domenami usługi Active Directory w celu zapewnienia dokładnych, spójnych usług czasu.
• Błędy niesymetryczności czasu można zobaczyć w podglądzie zdarzeń w centrum dystrybucji kluczy z błędem KRB_AP_ERR_SKEW, a także w przechwytywaniu pakietów.
• Ponowne odtwarzanie prób ataku jest rejestrowane w podglądzie zdarzeń przy użyciu KRB_AP_ERR_REPEAT.

Aby uzyskać więcej informacji, zobacz Maksymalna tolerancja synchronizacji zegara komputera

Systemy nazw domen (DNS)

Systemy nazw domen (DNS) są obowiązkowe dla protokołu Kerberos jako funkcji zabezpieczeń. Rozpoznawanie nazwy hosta służy do formułowania jednostek usługi Kerberos używanych do uwierzytelniania. W tym procesie wyszukiwania do przodu dla nazw hostów (rekordy A/AAAA) są używane do łączenia się z udziałami korzystającymi z uwierzytelniania Kerberos. To wyszukiwanie do przodu jest następnie używane do formułowania głównej nazwy usługi (SPN) używanej w żądaniu uwierzytelniania Kerberos. Jeśli nie można odnaleźć istniejącej nazwy SPN w centrum dystrybucji kluczy, uwierzytelnianie Kerberos zakończy się niepowodzeniem.

W środowiskach SMB systemu Windows można wypróbować metodę uwierzytelniania kopii zapasowej (np. NTLM). Jednak w wielu przypadkach protokół NTLM jest wyłączony ze względów bezpieczeństwa, co spowodowałoby niepowodzenie dostępu do udziału w przypadku niepowodzenia uwierzytelniania Kerberos. Podgląd zdarzeń systemu Windows często rejestruje główną przyczynę błędów (takich jak zduplikowane/brakujące nazwy SPN, niepowodzenia wyszukiwania DNS, błędy NTLM itp.).

Oprócz rozpoznawania nazw SPN system DNS jest intensywnie używany do rozpoznawania nazw hostów i adresów IP dla usług domenowych, takich jak LDAP, Kerberos KDCs itp. za pośrednictwem rekordów SRV. Aby uzyskać bardziej szczegółowe informacje na temat systemu DNS w usłudze Azure NetApp Files (w tym wymaganych rekordów SRV), zobacz About DNS in Azure NetApp Files (Informacje o systemie DNS w usłudze Azure NetApp Files).

Uwaga

Jeśli adres IP jest używany na potrzeby dostępu kerberos, zachowanie zależy od używanego protokołu NAS (NFS lub SMB). Aby uzyskać więcej informacji, zobacz Adresy IP na potrzeby dostępu za pomocą protokołu Kerberos.

LDAP

Protokół LDAP (Lightweight Directory Access Protocol) wykorzystuje bazy danych tożsamości zaplecza w celu zapewnienia ujednoliconego źródła usług nazw dla klientów i serwerów NAS, dzięki czemu wszystkie uczestniczące urządzenia zgadzają się na autentyczność użytkownika, członkostwo w grupach i identyfikatory liczbowe, które są następnie używane do uprawnień plików.

W przypadku protokołu Kerberos jednostki użytkownika i usługi są przechowywane z wpisami w bazach danych LDAP jako atrybutami na kontach głównych. Usługa Active Directory systemu Windows domyślnie obsługuje tę funkcję. W niektórych przypadkach (takich jak podczas tworzenia aliasów lub jednostek usługi), użytkownicy i komputery wymagają dodania lub modyfikacji nazw głównych usługi. To wymaganie można spełnić przy użyciu programu Użytkownicy i komputery usługi Active Directory Microsoft Management Console (MMC) lub programu PowerShell. Aby uzyskać więcej informacji na temat zarządzania nazwami główną usługi, zobacz Zarządzanie nazwami główną usługi.

Oprócz nazw głównych usług i identyfikatorów liczbowych na potrzeby uwierzytelniania Kerberos protokół LDAP może być również używany w przypadku tożsamości użytkowników i grup systemu UNIX, które są używane do mapowania nazw tożsamości w usłudze Azure NetApp Files, a także uwierzytelniania początkowego dla instalacji Kerberos systemu plików NFS za pośrednictwem nazwy SPN —> mapowanie nazw użytkowników systemu UNIX. Aby uzyskać więcej informacji, zobacz How NFS Kerberos works in Azure NetApp Files and LDAP's role with Kerberos in Azure NetApp Files (Jak działa kerberos systemu plików NFS w usłudze Azure NetApp Files ) i LDAP z protokołem Kerberos w usłudze Azure NetApp Files.

Jak działa protokół Kerberos protokołu SMB w usłudze Azure NetApp Files

Protokół Kerberos protokołu SMB działa oddzielnie od usług Kerberos systemu plików NFS, ponieważ konta maszyn utworzone dla każdego protokołu nie mogą współużytkować kart kluczy ze względu na potencjalne zmiany numeru wersji klucza (kvno) w jednej karcie klucza wpływającej na drugą usługę. W związku z tym, a także naturalne różnice w protokołach NAS, przepływy pracy usług SMB dla protokołu Kerberos i NFS dla protokołu Kerberos różnią się w niektórych obszarach.

Początkowa konfiguracja usług SMB

Usługi SMB w usłudze Azure NetApp Files są początkowo konfigurowane przez skonfigurowanie połączenia usługi Active Directory, które definiuje kilka krytycznych elementów interakcji z usługami domenowymi, w tym:

• Podstawowy serwer DNS (wymagany)
• Pomocnicza usługa DNS
• Nazwa DNS usługi Active Directory*
• Nazwa lokacji usługi Active Directory (dla odnajdywania kontrolera domeny) (wymagana)
• Nazwa prefiksu serwera SMB
• Jednostka organizacyjna (gdzie konta maszyn powinny być przechowywane w domenie usługi Azure AD)
• Włączanie/wyłączanie szyfrowania AES
• Włączanie/wyłączanie podpisywania LDAP
• Konfiguracja protokołu LDAP
• Szyfrowanie SMB na kontroler domeny
• Uprzywilejowani użytkownicy
• Poświadczenia nazwy użytkownika/hasła użytkownika z uprawnieniami jednostki organizacyjnej

Uwaga

Na konto jest dozwolone tylko jedno połączenie usługi Azure Active Directory (AD). Po utworzeniu połączenia usługi Azure AD każdy nowy wolumin SMB usługi Azure NetApp Files używa konfiguracji połączenia usługi Azure AD.

Konto maszyny protokołu Kerberos protokołu SMB

Konto komputera w usłudze Active Directory zawiera istotne informacje dotyczące użycia w żądaniach uwierzytelniania, w tym główną nazwę usługi (SPN). Podczas tworzenia woluminu SMB w usłudze Azure NetApp Files konfiguracja połączeń usługi Active Directory jest używana do interakcji podczas tworzenia konta komputera w celu zapewnienia bezpiecznego dostępu do udziału SMB za pośrednictwem uwierzytelniania Kerberos (lub NTLM, jeśli jest włączone).

Nowe konta maszyn są tworzone, gdy wolumin SMB usługi Azure NetApp Files jest aprowizowany na określonym zasobie zaplecza w usłudze. Poniżej przedstawiono różne scenariusze tworzenia lub ponownego użycia konta maszyny SMB w konfiguracjach woluminów usługi Azure NetApp Files.

Scenariusz	Result
Pierwszy nowy wolumin SMB	Nowe konto maszyny SMB/nazwa DNS
Kolejne woluminy SMB utworzone w krótkim odstępie czasu od pierwszego woluminu SMB	Ponownie użyte konto maszyny SMB/nazwa DNS (w większości przypadków).
Kolejne woluminy SMB utworzone znacznie później niż pierwszy wolumin SMB	Usługa określa, czy jest potrzebne nowe konto komputera. Istnieje możliwość utworzenia wielu kont maszyn, co powoduje utworzenie wielu punktów końcowych adresów IP.
Pierwszy wolumin z podwójnym protokołem	Nowe konto maszyny SMB/nazwa DNS
Kolejne woluminy dwóch protokołów utworzone w krótkim odstępie czasu od pierwszego woluminu protokołu podwójnego	Ponowne użycie konta maszyny SMB/nazwy DNS (w większości przypadków)
Kolejne woluminy dwóch protokołów utworzone znacznie później niż pierwszy wolumin z podwójnym protokołem	Usługa określa, czy jest potrzebne nowe konto komputera. Istnieje możliwość utworzenia wielu kont maszyn, co powoduje utworzenie wielu punktów końcowych adresów IP
Pierwszy wolumin SMB utworzony po woluminie z podwójnym protokołem	Nowe konto maszyny SMB/nazwa DNS
Pierwszy wolumin z dwoma protokołami utworzony po woluminie SMB	Nowe konto maszyny SMB/nazwa DNS

Konto maszyny SMB utworzone dla woluminu SMB (lub podwójnego protokołu) usługi Azure NetApp Files używa konwencji nazewnictwa zgodnej z maksymalną 15-znakową wartością wymuszaną przez usługę Active Directory. Nazwa używa struktury [prefiksu serwera SMB określonego w konfiguracji połączenia usługi Azure AD]-[unikatowy identyfikator liczbowy].

Jeśli na przykład skonfigurowano połączenia usługi Azure AD tak, aby używały prefiksu serwera SMB "AZURE", konto komputera SMB tworzone przez usługę Azure NetApp Files przypomina "AZURE-7806". Ta sama nazwa jest używana w ścieżce UNC dla udziału SMB (na przykład \AZURE-7806) i jest nazwą używaną przez dynamiczne usługi DNS do tworzenia rekordu A/AAAAA.

Uwaga

Ponieważ nazwa podobna do "AZURE-7806" może być trudna do zapamiętania, warto utworzyć rekord CNAME jako alias DNS dla woluminów usługi Azure NetApp Files. Aby uzyskać więcej informacji, zobacz Tworzenie aliasów serwera SMB.

W niektórych przypadkach podczas tworzenia wielu woluminów protokołu SMB i/lub podwójnych konfiguracja może zakończyć się wieloma różnymi kontami maszyn SMB i nazwami DNS.

Jeśli wymagana jest jedna przestrzeń nazw dostępu użytkowników w woluminach, może to stanowić wyzwanie w konfiguracji, ponieważ pojedynczy alias CNAME może wskazywać tylko jeden rekord hosta A/AAAAA, używając wielu identycznych aliasów rekordów A/AAAAA, może to spowodować nieprzewidywalność dostępu do danych w dostępie do woluminów na różnych kontach maszyn SMB, ponieważ nie ma gwarancji, że punkt końcowy wybrany przez klienta w wyszukiwaniu DNS zawiera oczekiwany wolumin ze względu na działanie okrężne wyboru rekordów DNS w tych konfiguracjach.

Aby rozwiązać ten problem, woluminy usługi Azure NetApp Files mogą uczestniczyć jako obiekty docelowe w konfiguracji systemu plików rozproszonych firmy Microsoft (DFS ), co umożliwia skojarzenie wielu woluminów SMB z pojedynczym punktem wejścia przestrzeni nazw.

Przepływ pracy tworzenia nazwy SPN protokołu Kerberos protokołu SMB

Na poniższym diagramie przedstawiono sposób tworzenia nazwy SPN protokołu Kerberos protokołu SMB protokołu SMB lub podwójnego protokołu SMB usługi Azure NetApp Files. Nazwy SPN protokołu SMB są skojarzone z obiektami konta maszyny SMB w domenie. Nazwę SPN można wyświetlać i zarządzać za pośrednictwem właściwości konta komputera przy użyciu edytora atrybutów w widoku Zaawansowanym.

Możesz również wyświetlać właściwości i zarządzać nimi za setspn pomocą polecenia .

Ten proces jest zgodny z tymi samymi krokami, co w przypadku, gdy zwykły klient systemu Windows dołącza do domeny (DNS, LDAP, Kerberos, RPC zapytania za pośrednictwem nazwanych potoków).

W większości przypadków znajomość szczegółowych kroków nie jest konieczna w przypadku codziennych zadań administracyjnych, ale jest przydatna w rozwiązywaniu problemów z błędami podczas próby utworzenia woluminu SMB w usłudze Azure NetApp Files.

Szczegółowe procedury

Aby uzyskać szczegółowe instrukcje dotyczące tworzenia konta maszyny SMB w usłudze Azure NetApp Files, rozwiń listę.

• Wyszukiwanie DNS jest wykonywane przy użyciu konfiguracji DNS dla rekordu SRV centrum dystrybucji kluczy Kerberos. Usługa Azure NetApp Files używa następujących rekordów SRV w żądaniach.

  • _kerberos._tcp.dc._msdcs.CONTOSO.COM
  • _kerberos._tcp.CONTOSO.COM (jeśli poprzednie zapytanie nie zwraca żadnych wyników)

• Wyszukiwanie DNS jest wykonywane przy użyciu nazw hostów, które są zwracane w zapytaniu SRV dla rekordów A/AAAA kontrolerów KDCs.

  • Polecenie ping LDAP (powiązanie LDAP i zapytanie RootDSE ) jest wykonywane w celu wyszukiwania dostępnych starszych serwerów NetLogon przy użyciu zapytania (&(DnsDomain=CONTOSO.COM)(NtVer=0x00000016)) z filtrem atrybutów dla netLogon. Nowsze wersje kontrolera domeny systemu Windows (nowsze niż 2008) nie mają obecnej NtVer wartości .

• Zapytanie DNS jest wykonywane przez usługę Azure NetApp Files w celu znalezienia serwerów LDAP w domenie przy użyciu następujących rekordów SRV:

  • _ldap._tcp.CONTOSO.COM
  • _kerberos._tcp.CONTOSO.COM

  Uwaga

  Te zapytania są wykonywane wiele razy w tym samym wywołaniu w różnych częściach procesu. Problemy z systemem DNS mogą powodować spowolnienie w tych wywołaniach lub, z przekroczeniem limitu czasu, zakończone niepowodzenia. — Jeśli kwerendy nie mogą znaleźć wpisu lub jeśli nie można skontaktować się z wpisami, tworzenie woluminu SMB zakończy się niepowodzeniem. — Jeśli zapytania DNS powiedzie się, zostaną przetworzone następne kroki.

• Protokół ICMP (ping) jest wysyłany w celu sprawdzenia, czy adresy IP zwrócone z systemu DNS są osiągalne.

• Jeśli polecenie ping jest blokowane w sieci przez zasady zapory, żądanie ICMP kończy się niepowodzeniem. Zamiast tego są używane polecenia ping LDAP.

• Kolejne polecenie ping LDAP jest wykonywane w celu wyszukiwania dostępnych starszych serwerów NetLogon przy użyciu zapytania (&(&(DnsDomain=CONTOSO.COM)(Host=KDChostname.contoso.com))(NtVer=0x00000006)) z filtrem atrybutu NetLogon. Nowsze wersje kontrolera domeny systemu Windows (większe niż 2008) nie mają obecnej wartości NtVer .

• Uwierzytelnianie AS-REQ jest wysyłane z usługi Azure NetApp Files przy użyciu nazwy użytkownika skonfigurowanej z połączeniem usługi Active Directory.

• Kontroler domeny odpowiada za KRB5KDC_ERR_PREAUTH_REQUIREDpomocą polecenia , który prosi usługę o bezpieczne wysłanie hasła dla użytkownika.

• Drugi klucz AS-REQ jest wysyłany z danymi wstępnego uwierzytelniania wymaganymi do uwierzytelniania za pomocą centrum dystrybucji kluczy w celu uzyskania dostępu w celu kontynuowania tworzenia konta komputera. W przypadku pomyślnego wysłania biletu biletu przyznania biletu (TGT) do usługi.

• W przypadku powodzenia usługa TGS-REQ jest wysyłana przez usługę, aby zażądać biletu usługi CIFS (cifs/kdc.contoso.com) z centrum dystrybucji kluczy przy użyciu biletu TGT otrzymanego w as-REP.

• Jest wykonywane nowe powiązanie LDAP przy użyciu biletu usługi CIFS. Zapytania są wysyłane z usługi Azure NetApp Files:

  • Wyszukiwanie podstawowe rootDSE dla nazwy DN domeny ConfigurationNamingContext
  • OneLevel wyszukiwania CN=partitions w dn pobrany dla ConfigurationNamingContext przy użyciu filtru (&(&(objectClass=crossRef)(nETBIOSName=*))(dnsRoot=CONTOSO.COM)) atrybutu NETBIOSname.
  • Wyszukiwanie podstawowe przy użyciu filtru (|(objectClass=organizationalUnit)(objectClass=container)) jest wykonywane na jednostki organizacyjnej określonej w konfiguracji połączeń usługi Active Directory. Jeśli nie określono, zostanie użyta wartość domyślna OU=Computers . Sprawdza to, czy kontener istnieje.
  • Wyszukiwanie poddrzewa jest wykonywane na podstawie dn domeny przy użyciu filtru (sAMAccountName=ANF-XXXX$), aby sprawdzić, czy konto już istnieje.
    • Jeśli konto istnieje, jest używane ponownie.
  • Jeśli konto nie istnieje, zostanie utworzone, pod warunkiem, że użytkownik ma uprawnienia do tworzenia i modyfikowania obiektów w kontenerze przy użyciu addRequest polecenia LDAP. Następujące atrybuty LDAP są ustawiane na koncie:

  Atrybut	Wartość
  CN	ANF-XXXX
  sAMAccountName	ANF-XXXX$
  objectClass	Góra Osoba Person organizacyjny User Komputer
  servicePrincipalName	HOST/ANF-XXXX HOST/anf-xxxx.contoso.com CIFS/anf-xxxx.contoso.com
  userAccountControl	4096
  operatingSystem	Wydanie usługi NetApp
  dnsHostName	ANF-XXXX.CONTOSO.COM

  • Jeśli błąd zakończy się niepowodzeniem addRequest , tworzenie woluminu zakończy się niepowodzeniem. Błąd addRequest może zakończyć się niepowodzeniem z powodu nieprawidłowych uprawnień w obiekcie kontenera.
  • addRequest Jeśli operacja zakończy się powodzeniem, wyszukiwanie LDAP przy użyciu filtru (sAMAccountName=ANF-XXXX$) jest wykonywane w celu pobrania atrybutu objectSid.
  • Konwersacja protokołu SMB2 "Negotiate protocol" jest wykonywana w celu pobrania obsługiwanego protokołu Kerberos mechTypes z centrum dystrybucji kluczy.
  • Wykonywana jest konfiguracja sesji SMB2 przy użyciu nazwy SPN CIFS i najwyższego obsługiwanego mechType połączenia drzewa z IPC$.
  • Plik SMB2 lsarpc jest tworzony w udziale IPC$.
  • Wykonywane jest powiązanie z dcERPC . Plik lsarpc zostanie zapisany, a następnie odczytany.
  • Następnie są wykonywane następujące żądania LSA:
    • Lsa_openpolicy2
    • Lsa_lookupsids2

• TGS-REQ przy użyciu biletu TGT jest wykonywany w celu pobrania biletu dla kadmin/changepw nazwy SPN skojarzonej krbtgt z kontem.

• Żądanie KPASSWD jest wykonywane z usługi do centrum dystrybucji kluczy w celu zmiany hasła konta komputera.

• Zapytanie LDAP jest wykonywane przy użyciu filtru (sAMAccountName=ANF-XXXX) dla atrybutów distinguishedName i isCriticalSystemObject.

• Jeśli konto isCriticalSystemObject ma wartość false (wartość domyślna), pobierana nazwa wyróżniająca jest używana do formułowania modifyRequest atrybutu msDs-SupportedEncryptionTypes. Ta wartość jest ustawiona na 30, co odpowiada wartości DES_CBC_MD5 (2) + RC4 (4) + AES 128 (8) + AES 256 (16).

• Wykonywana jest druga operacja "Negotiate protocol"/Kerberos ticket exchange/"Session setup"/"Tree connect" z protokołem IPC$. Konto komputera serwera SMB (ANF-XXXX$) służy jako podmiot zabezpieczeń protokołu Kerberos.

• Ukończono komunikację NetLogon, NetrServer ReqChallenge/Authenticate2.

• Wykonywana jest trzecia "Negotiate protocol:/Kerberos ticket exchange/"Session setup"/"Tree connect" to IPC$; konto maszyny serwera SMB (ANF-XXXX$) jest używane jako podmiot zabezpieczeń protokołu Kerberos.

• Połączenia i lsarpc NetLogon są wykonywane jako ostateczna kontrola konta.

Przepływ pracy połączenia udziału SMB (Kerberos)

Gdy wolumin usługi Azure NetApp Files jest instalowania przy użyciu protokołu Kerberos, wymiana biletów Protokołu Kerberos jest używana podczas żądań konfiguracji wielu sesji w celu zapewnienia bezpiecznego dostępu do udziału. W większości przypadków znajomość szczegółowych kroków nie jest niezbędna do wykonywania codziennych zadań administracyjnych. Ta wiedza jest przydatna podczas rozwiązywania problemów z błędami podczas próby uzyskania dostępu do woluminu SMB w usłudze Azure NetApp Files.

Aby uzyskać szczegółowe informacje o sposobie uzyskiwania dostępu do udziału SMB w usłudze Azure NetApp Files, rozwiń listę.

• Klient próbuje uzyskać dostęp do udziału SMB przy użyciu ścieżki UNC pokazanej w usłudze Azure NetApp Files. Domyślnie ścieżka UNC będzie zawierać nazwę serwera SMB (na przykład ANF-XXXX)
• Usługa DNS jest odpytywana w celu zamapowania nazwy hosta na adres IP
• Trwa początkowa konwersacja protokołu SMB2 "Negotiate Protocol"
  • Żądanie jest wysyłane od klienta w celu wykrycia, które dialekty SMB są obsługiwane przez serwer i zawiera informacje obsługiwane przez klienta żądającego
  • Serwer odpowiada na obsługiwane elementy, w tym:
    • Tryb zabezpieczeń (podpisywanie lub nie)
    • Wersja protokołu SMB
    • Identyfikator GUID serwera
    • Obsługiwane możliwości (DFS, dzierżawa, duże jednostki MTU, multichannel, trwałe dojścia, dzierżawa katalogów, szyfrowanie)
    • Maksymalny rozmiar transakcji
    • Maksymalny rozmiar odczytu/zapisu
    • Obiekt blob zabezpieczeń (Kerberos lub NTLM)
• Druga konwersacja protokołu SMB2 "Negotiate Protocol" odbywa się jako "wstępne uwierzytelnianie"/logowanie
  • Żądanie od klienta obejmuje:
    • Skrót autoryzacji wstępnej
    • Obsługiwane tryby zabezpieczeń (podpisywanie lub nie)
    • Obsługiwane możliwości (DFS, dzierżawa, duże jednostki MTU, multichannel, trwałe dojścia, dzierżawa katalogów, szyfrowanie)
    • Identyfikator GUID klienta
    • Obsługiwane dialekty SMB
  • Jeśli skrót autoryzacji wstępnej jest akceptowany, serwer odpowiada:
    • Tryb zabezpieczeń (podpisywanie lub nie)
    • Obsługiwane możliwości (DFS, dzierżawa, duże jednostki MTU, multichannel, trwałe dojścia, dzierżawa katalogów, szyfrowanie)
    • Maksymalny rozmiar transakcji
    • Maksymalny rozmiar odczytu/zapisu
    • Obiekt blob zabezpieczeń (Kerberos lub NTLM)
    • Funkcje integralności i szyfrowania wstępnego protokołu SMB
• Jeśli negocjowanie protokołu zakończy się pomyślnie, zostanie wykonane żądanie "Konfiguracja sesji".
  • Instalator używa skrótu uwierzytelniania wstępnego z negocjacji protokołu.
  • Instalator informuje serwer SMB o tym, co obsługuje klient żądający, w tym:
    • Rozmiar struktury
    • Flaga powiązania sesji
    • Tryb zabezpieczeń (włączony/wymagany podpisywanie)
    • Możliwości
    • Obsługiwane typy szyfrowania Kerberos
• Zostanie wysłana odpowiedź "Konfiguracja sesji".
  • Środki na protokół SMB są przyznawane.
  • Identyfikator sesji jest ustanawiany.
  • Flagi sesji są ustawione (gość, wartość null, szyfrowanie).
  • Zdefiniowano typ szyfrowania Kerberos.
• Żądanie połączenia drzewa jest wysyłane przez klienta na potrzeby połączenia z udziałem SMB.
  • Flagi/możliwości udostępniania są wysyłane z serwera wraz z uprawnieniami do udostępniania.
• Polecenie ioctlFSCTL_QUERY_NETWORK_INTERFACE_INFO jest wysyłane, aby uzyskać adres IP serwera SMB.
• Serwer SMB w usłudze Azure NetApp Files zgłasza z powrotem informacje o sieci, w tym: * adres IP * Możliwości interfejsu (funkcja RSS włączone lub wyłączone) * Liczba kolejek RSS * Szybkość łącza
• Żądanie połączenia drzewa jest wysyłane przez klienta na potrzeby połączenia z udziałem administracyjnym IPC$.
  • Udział IPC$ to zasób, który współużytkuje nazwane potoki, które są niezbędne do komunikacji między programami. Udział IPC$ jest używany podczas zdalnego administrowania komputerem i podczas przeglądania zasobów udostępnionych komputera. Nie można zmienić ustawień udziału, właściwości udziału ani list ACL udziału IPC$. Nie można również zmienić nazwy ani usunąć udziału IPC$.
  • Plik o nazwie srvsvc jest tworzony w dojściu udziału jako usługi.
• Powiązanie DCERPC jest wykonywane z plikiem w srvsvc celu nawiązania bezpiecznego połączenia.
  • Plik jest zapisywany przy użyciu wcześniej pobranych informacji.
• Protokół TGS-REQ protokołu Kerberos jest wystawiany przez klienta systemu Windows do centrum dystrybucji kluczy w celu uzyskania biletu usługi (ST) dla usługi SMB.
• Polecenie NetShareGetInfo jest uruchamiane przez klienta SMB na serwerze, a odpowiedź jest wysyłana.
• Bilet usługi SMB jest pobierany z centrum dystrybucji kluczy.
• Usługa Azure NetApp Files próbuje zamapować użytkownika systemu Windows żądającego dostępu do udziału prawidłowemu użytkownikowi systemu UNIX.
  • Żądanie TGS protokołu Kerberos jest wykonywane przy użyciu poświadczeń protokołu Kerberos serwera SMB przechowywanych przy użyciu tabłu klucza serwera SMB z początkowego tworzenia serwera SMB do użycia na potrzeby powiązania serwera LDAP.
  • Protokół LDAP jest wyszukiwany dla użytkownika systemu UNIX mapowanego na użytkownika SMB żądającego dostępu do udziału. Jeśli żaden użytkownik systemu UNIX nie istnieje w protokole LDAP, domyślny użytkownik pcuser systemu UNIX jest używany przez usługę Azure NetApp Files do mapowania nazw (pliki/foldery zapisane w woluminach podwójnych protokołów używają mapowanego użytkownika systemu UNIX jako właściciela systemu UNIX).
• Jest wykonywane inne negocjowania protokołu/żądania sesji/połączenia drzewa, tym razem przy użyciu nazwy SPN serwera SMB z udziałem IPC$ kontrolera domeny usługi Active Directory.
  • Nazwany potok jest ustanawiany do udziału za pośrednictwem .srvsvc
  • Sesja NETLOGON jest ustanawiana dla udziału, a użytkownik systemu Windows jest uwierzytelniany.
• Jeśli uprawnienia zezwalają na to użytkownikowi, udział zawiera listę plików i folderów zawartych w woluminie.

Uwaga

Usługa Azure NetApp Files dodaje wpisy do pamięci podręcznej kontekstu Protokołu Kerberos dla klienta. Te wpisy znajdują się w pamięci podręcznej przez czas trwania biletu protokołu Kerberos (ustawiony przez centrum dystrybucji kluczy i kontrolowane przez zasady Protokołu Kerberos.

Tworzenie aliasów serwera SMB

Gdy usługa Azure NetApp Files tworzy serwer SMB przy użyciu konwencji nazewnictwa [prefiks serwera SMB określony w konfiguracji połączenia usługi Azure AD]-[unikatowy identyfikator liczbowy]. (Aby uzyskać szczegółowe informacje o unikatowym identyfikatorze liczbowym, zobacz Konto komputera protokołu Kerberos protokołu SMB). To formatowanie oznacza, że nazwy serwerów SMB nie są tworzone w przyjazny dla użytkownika sposób. Na przykład nazwa "SMB-7806" jest trudniej zapamiętać niż coś podobnego do "AZURE-FILESHARE".

Ze względu na to zachowanie administratorzy mogą chcieć utworzyć przyjazne dla użytkownika nazwy aliasów dla woluminów usługi Azure NetApp Files. Wymaga to wskazania nazwy kanonicznej DNS (CNAME) istniejącego rekordu A/AAAAA DNS na serwerze.

Gdy rekord CNAME jest tworzony i używany w żądaniach ścieżki UNC (na przykład \\AZURE-FILESHARE zamiast \\SMB-7806), dns przekierowuje żądanie CNAME (AZURE-FILESHARE.contoso.com) do odpowiedniego rekordu A/AAAAA (SMB-7806.contoso.com), który jest używany w pobieraniu nazwy SPN protokołu Kerberos (cifs/SMB-7806). Umożliwia to dostęp protokołu Kerberos do udziału SMB podczas korzystania z nazwy aliasu.

Jeśli zostanie utworzony rekord A/AAAA DNS (na przykład AZURE-FILESHARE.contoso.com) i podjęto próbę użycia jako aliasu, żądania Kerberos kończą się niepowodzeniem. Błąd jest wynikiem skonstruowanej nazwy SPN używanej do uwierzytelniania w udziale (cifs/AZURE-FILESHARE) niezgodnej nazwy SPN protokołu Kerberos dla serwera SMB (cifs/SMB-7806). Awarię można rozwiązać, jeśli zostanie utworzona inna nazwa SPN i dołączona do konta komputera serwera SMB (na przykład cifs/AZURE-FILESHARE).

Obsługiwane możliwości serwera SMB w usłudze Azure NetApp Files

Po wysłaniu żądania protokołu SMB "negocjuj protokół" serwer SMB usługi Azure NetApp Files jest odpytywane pod kątem obsługi określonych możliwości. W poniższej tabeli przedstawiono możliwości, których dotyczy zapytanie, oraz odpowiedź zwrócona z woluminu SMB usługi Azure NetApp Files po wykonaniu połączenia z instalacją sesji/drzewem.

Możliwość protokołu SMB	Obsługiwane przez usługę Azure NetApp Files?
Docelowy system plików DFS	Tak
Leasing	Tak
Duża jednostki MTU	Tak
Wielokanałowy protokół SMB	Tak
Trwałe dojścia protokołu SMB	Tak
Dzierżawa katalogów	Nie.
Szyfrowanie SMB	Tak (jeśli włączono)

Obsługiwane możliwości i właściwości udziału SMB w usłudze Azure NetApp Files

Podczas uzyskiwania dostępu do udziału SMB wykonywane jest żądanie "łączenie drzewa", a obsługiwane możliwości i właściwości udziału SMB są wykonywane przez klienta do serwera usługi Azure NetApp Files. W poniższej tabeli przedstawiono możliwości udostępniania, których dotyczy zapytanie, oraz odpowiedź zwrócona z woluminu SMB usługi Azure NetApp Files, jak pokazano w przechwyceniu pakietów.

Możliwość udostępniania SMB	Obsługiwane przez usługę Azure NetApp Files?
Stale dostępne (CA)	Tak, w przypadku określonych obciążeń* (jeśli włączono)
Skalowanie w poziomie	Nie.
Klaster	Nie.
Asymetryczny	Nie.
Przekierowywanie do właściciela	Nie.

* Zobacz Włączanie ciągłej dostępności na istniejących woluminach SMB dla obsługiwanych obciążeń.

W poniższej tabeli przedstawiono właściwości udziału, których dotyczy zapytanie, oraz odpowiedź zwrócona z woluminu SMB usługi Azure NetApp Files.

Możliwość udostępniania SMB	Obsługiwane przez usługę Azure NetApp Files?
Docelowy system plików DFS	Tak
Główny system plików DFS	Nie.
Ogranicz otwarte wyłączność	Nie.
Wymuszone usunięcie udostępnione	Nie.
Zezwalaj na buforowanie przestrzeni nazw	Nie.
Wyliczanie oparte na dostępie	Tak (jeśli włączono)
Siłowy poziom II oplock	Nie.
Włączanie skrótu V1	Nie.
Włączanie skrótu w wersji 2	Nie.
Wymagane szyfrowanie	Tak (jeśli włączono)
Komunikacja zdalna tożsamości	Nie.
Skompresowane we/wy	Nie.
Transport izolowany	Nie.

Jak działa protokół Kerberos systemu plików NFS w usłudze Azure NetApp Files

Protokół Kerberos systemu plików NFS działa niezależnie od usług SMB, ponieważ konta maszyn utworzone dla każdego protokołu nie mogą współużytkować kart kluczy ze względu na potencjalne zmiany numeru wersji klucza (kvno) w jednej karcie klucza wpływającej na drugą usługę. W związku z tym przepływy pracy dla usług SMB dla protokołu Kerberos i NFS dla protokołu Kerberos różnią się w niektórych obszarach.

Początkowa konfiguracja obszaru Kerberos

Obszar Kerberos systemu plików NFS jest konfigurowany, gdy informacje o obszarze Protokołu Kerberos są wypełniane w portalu usługi Azure NetApp Files na stronie połączeń usługi Active Directory.

Nazwa serwera usługi Azure AD i adres IP centrum dystrybucji kluczy są używane do nawiązywania połączenia z usługami Azure AD KDC podczas początkowego tworzenia konta komputera. Usługa Azure NetApp Files wykorzystuje istniejące informacje o domenie, aby wypełnić pozostałą część konfiguracji obszaru. Na przykład:

Kerberos Realm: CONTOSO.COM
KDC Vendor: Microsoft
KDC IP Address: x.x.x.x 
KDC Port: 88
Clock Skew: 5
Active Directory Server Name: dc1.contoso.com
Active Directory Server IP Address: x.x.x.x
Comment: -
Admin Server IP Address: x.x.x.x
Admin Server Port: 749
Password Server IP Address: x.x.x.x
Password Server Port: 464
Permitted Encryption Types: aes-256
-    Configured by Azure NetApp Files administrator in the portal
-    Automatically configured by the service using Active Directory connection information/system defaults

Po skonfigurowaniu obszaru Kerberos systemu plików NFS wpis hostów lokalnych jest dodawany w usłudze z centrum dystrybucji kluczy określonej w konfiguracji. Po zmodyfikowaniu obszaru wpis hostów lokalnych jest również modyfikowany w usłudze.

Ten wpis hosta lokalnego działa jako "ostateczność", jeśli awaria centrum dystrybucji kluczy występuje w centrum dystrybucji kluczy określonych w konfiguracji obszaru i nie może wysyłać zapytań o nadmiarowe kontrolery KDC za pośrednictwem systemu DNS.

Uwaga

Jeśli centrum dystrybucji kluczy w obszarze Kerberos musi zostać wyłączone do konserwacji (np. w przypadku uaktualnień lub likwidacji serwera), zaleca się skonfigurowanie obszaru w celu korzystania z centrum dystrybucji kluczy, które nie jest poddawane konserwacji, aby uniknąć awarii.

Początkowe tworzenie konta komputera/głównej nazwy usługi

Po włączeniu protokołu Kerberos na woluminie usługi Azure NetApp Files konto komputera/podmiot zabezpieczeń o nazwie NFS-{SMB-server-name} jest tworzone w domenie w określonej jednostce organizacyjnej w połączeniach usługi Active Directory (jednostka organizacyjna). Nazwy kont maszyny są obcinane po 15 znakach.

Uwaga

W przypadku dodawania klientów systemu Linux z nazwami hostów większymi niż 15 znaków do domeny usługi Active Directory ich nazwy SPN konta maszyny Protokołu Kerberos są obcięte. Na przykład klient systemu Linux o nazwie MORE-THAN-FIFTEEN ma nazwę konta komputera o nazwie MORE-THAN-FIFT$, która staje się nazwą SPN .MORE-THAN-FIFT$@CONTOSO.COM Gdy dns wyszukuje nazwę hosta klienta, znajduje dłuższą nazwę i próbuje użyć tej nazwy w żądaniu SPN ( MORE-THAN-FIFTEEN@CONTOSO.COM). Ponieważ ta nazwa SPN nie istnieje, klient próbuje użyć następnej nazwy SPN na karcie klucza w żądaniu (zazwyczaj host/nazwa hosta). Tylko nazwy SPN konta komputera działają natywnie z usługą Azure NetApp Files NFS Kerberos. W związku z tym upewnij się, że nazwy hostów klienta systemu Linux używane dla protokołu Kerberos systemu plików NFS z usługą Azure NetApp Files nie przekraczają 15 znaków. Alternatywnie, jeśli chcesz użyć nazwy SPN hosta/nazwy hosta, skonfiguruj użytkownika systemu UNIX w protokole LDAP przy użyciu nazwy użytkownika "host". Ta konfiguracja zapewnia mapowanie nazw krb-unix dla nazwy SPN.

W usłudze Azure NetApp Files bloki kluczy Protokołu Kerberos (lub wpisy na karcie kluczy) są dodawane do usługi za pomocą nazwy SPN usługi NFS (nfs/nfs-server-name.contoso.com@CONTOSO.COM). Tworzone są wiele wpisów: jeden dla każdego obsługiwanego typu szyfrowania. W usłudze Azure NetApp Files tylko typ szyfrowania AES-256 jest obsługiwany w przypadku protokołu Kerberos systemu plików NFS.

W większości przypadków znajomość tych kroków nie będzie konieczna w przypadku codziennych zadań administracyjnych, ale jest przydatna podczas rozwiązywania problemów z błędami podczas próby utworzenia woluminu Kerberos systemu plików NFS w usłudze Azure NetApp Files.

Przepływ pracy tworzenia nazwy SPN protokołu Kerberos systemu plików NFS

Na poniższym diagramie przedstawiono sposób tworzenia nazwy SPN systemu plików NFS podczas tworzenia woluminu NFS usługi Azure NetApp Files lub podwójnego protokołu z włączonym protokołem Kerberos. W większości przypadków znajomość szczegółowych kroków nie będzie konieczna w przypadku codziennych zadań administracyjnych, ale jest przydatna podczas rozwiązywania problemów z błędami podczas próby utworzenia woluminu SMB w usłudze Azure NetApp Files.

Aby uzyskać szczegółowe instrukcje dotyczące sposobu tworzenia głównej nazwy SPN protokołu Kerberos systemu plików NFS za pomocą usługi Azure NetApp Files, rozwiń listę.

• Poświadczenia administratora przekazane do centrum dystrybucji kluczy określone w konfiguracji obszaru przy użyciu nazwy użytkownika podanej do użycia w połączeniu usługi Active Directory — użytkownik musi mieć uprawnienia do wyświetlania/tworzenia obiektów w określonej jednostki organizacyjnej.
• Serwery DNS określone w konfiguracji połączenia usługi Active Directory usługi Azure NetApp Files są odpytywane przez usługę Azure NetApp Files dla rekordów usługi Kerberos (SRV) w następujących formatach:
  • Zapytanie o identyfikator URI dla _kerberos.CONTOSO.COM
  • Zapytanie SRV dla _kerberos-master._udp. CONTOSO.COM
  • Zapytanie SRV dla master._tcp _kerberos. CONTOSO.COM

Uwaga

Te zapytania są wykonywane wiele razy w tym samym wywołaniu w różnych częściach procesu. Problemy z systemem DNS mogą powodować spowolnienie w tych wywołaniach lub zakończyć błędy. Te rekordy nie istnieją domyślnie we wdrożeniach usługi Active Directory i muszą zostać utworzone ręcznie.

• Jeśli kwerendy nie mogą znaleźć wpisu lub jeśli znalezione wpisy nie mogą być kontaktowane lub używane jako główne centrum dystrybucji kluczy, to zapytanie rekordu A przy użyciu nazwy obszaru znalezionej w konfiguracji obszaru NFS Kerberos jest używane jako ostatni środek do nawiązania połączenia z centrum dystrybucji kluczy za pośrednictwem portu 88.
• Podczas konfiguracji protokołu Kerberos systemu plików NFS statyczny wpis hosta dla określonego centrum dystrybucji kluczy jest dodawany do pliku hostów lokalnych jako kopii zapasowej, jeśli wyszukiwanie DNS zakończy się niepowodzeniem.
• Jeśli dla obszaru znajduje się buforowany wpis DNS, jest on używany. Jeśli nie, zostanie użyty wpis pliku lokalnego. Buforowane wpisy DNS działają tak długo, jak czas wygaśnięcia (TTL) jest skonfigurowany dla rekordu DNS. Wpis pliku lokalnego jest skonfigurowany przy użyciu 86 400 sekund czasu wygaśnięcia (24 godziny). Konfiguracja przełącznika ns dla odnośników hostów w usłudze Azure NetApp Files używa najpierw plików, a następnie dns. Po znalezieniu wpisu lokalnego nie są wykonywane żadne zapytania.
• Konto maszyny SMB utworzone podczas tworzenia połączenia usługi Active Directory jest używane jako poświadczenia dla powiązania LDAP usługi Active Directory przy użyciu sygnatury dostępu współdzielonego/GSS przez port 389, aby wyszukać wszystkie istniejące wpisy żądanej nazwy SPN lub nazwy konta komputera. Jeśli nazwa SPN lub nazwa konta komputera już istnieje, zostanie wysłany błąd. Jeśli nazwa SPN nie istnieje w zapytaniu LDAP, tworzenie konta maszyny jest wykonywane w wyznaczonej jednostki organizacyjnej z wpisami dla następujących atrybutów ustawionych przez usługę Azure NetApp Files:
  • cn (NFS-MACHINE)
  • sAMAccountName (NFS-MACHINE$)
  • objectClass (top, person, organizationalPerson, user, computer)
  • servicePrincipalName (host/NFS-MACHINE, host/NFS-MACHINE. CONTOSO.COM, nfs/NFS-MACHINE, nfs/NFS-MACHINE. CONTOSO.COM)
  • userAccountControl (4096)
  • msDs-SupportedEncryptionTypes (AES-256_CTS_HMAC_SHA1_96)
  • dnsHostName (NFS-MACHINE.CONTOSO.COM)
• Hasło konta maszyny kerberos systemu plików NFS jest ustawione dla konta NFS-MACHINE na porcie 464.
• Bloki kluczy Protokołu Kerberos (tabki kluczy) dla nazwy SPN systemu plików NFS są zapisywane w usłudze Azure NetApp Files.
• Reguła mapowania nazw statycznych jest tworzona w usłudze Azure NetApp Files, aby upewnić się, że użytkownik główny dla każdego klienta kerberos systemu plików NFS jest mapowany na katalog główny podczas użycia protokołu Kerberos.
• Plik krb5.conf jest dodawany do systemów wewnętrznych usługi z informacjami o obszarze NFS.

Instalowanie protokołu Kerberos systemu plików NFS

Gdy wolumin usługi Azure NetApp Files jest instalowany przy użyciu smaków zabezpieczeń protokołu Kerberos za pośrednictwem systemu plików NFS, jest wykonywany następujący przepływ pracy. Aby uzyskać bardziej szczegółowe konto protokołu Kerberos, zobacz Synopsis usługi uwierzytelniania sieciowego Kerberos (V5).

Aby uzyskać szczegółowe instrukcje dotyczące sposobu instalowania woluminu Kerberos systemu plików NFS za pomocą usługi Azure NetApp Files, rozwiń listę.

• Klient próbuje zainstalować ścieżkę eksportu systemu plików NFS w usłudze Azure NetApp Files i określa -osmak zabezpieczeń krb5 (lub krb5i lub krb5p).
• System DNS służy do formułowania żądania dla jednostki usługi NFS w usłudze Azure NetApp Files za pośrednictwem rekordu A/AAAAA lub PTR (w zależności od sposobu wydania polecenia instalacji).
• Klient pobiera TGT z centrum dystrybucji kluczy za pośrednictwem wywołania AS-REQ przy użyciu głównej nazwy klienta znalezionej na karcie klucza klienta.
• Ścieżka eksportu jest sprawdzana, aby upewnić się, że istnieje w systemie plików.
• Reguła zasad eksportu jest sprawdzana, aby upewnić się, że dostęp kerberos jest dozwolony do ścieżki eksportu.<
• Bilet usługi NFS jest żądany z centrum dystrybucji kluczy przez klienta za pośrednictwem wywołania AP-REQ. Usługa Azure NetApp Files sprawdza kartę klucza prawidłowego wpisu z prawidłowym typem szyfrowania przy użyciu biletu TGT od klienta uzyskanego z centrum dystrybucji kluczy.
• Jeśli bilet TGT jest prawidłowy, zostanie wystawiony bilet usługi.
• Nazwa SPN klienta (na przykład CLIENT$@CONTOSO.COM) jest mapowana na użytkownika głównego za pomocą reguły mapowania nazw w usłudze Azure NetApp Files.
• Użytkownik główny jest odpytywane w bazach danych usług nazw (plikach i LDAP) w celu członkostwa w grupach/istnienia.
• Powiązanie LDAP przy użyciu konta maszyny serwera SMB jest wykonywane w celu umożliwienia wyszukiwania LDAP dla użytkownika głównego.
• Ponieważ katalog główny zawsze istnieje w usłudze Azure NetApp Files, nie powinno to powodować żadnych problemów, ale zapytania LDAP dotyczące katalogu głównego mogą zakończyć się niepowodzeniem. Te błędy można zignorować.
• Bilet usługi NFS jest zwracany do klienta i instalacja zakończyła się pomyślnie. Użytkownik główny ma dostęp główny do instalacji protokołu Kerberos za pomocą jednostki konta komputera klienta (możliwe do wyświetlenia za klist -e pomocą polecenia z klienta).
• Usługa Azure NetApp Files dodaje wpisy do pamięci podręcznej kontekstu Protokołu Kerberos dla klienta. Te wpisy będą znajdować się w pamięci podręcznej przez czas trwania biletu Protokołu Kerberos ustawionego przez centrum dystrybucji kluczy i kontrolowane przez zasady protokołu Kerberos.
• System plików NFSv4.1 okresowo (co 20 sekund) wysyła aktualizacje odświeżania biletu Kerberos jako "keepalives".

Dostęp do instalacji protokołu Kerberos systemu plików NFS przy użyciu podmiotów zabezpieczeń użytkowników

Gdy do instalacji kerberos systemu plików NFS usługi Azure NetApp Files uzyskuje się dostęp użytkownika (innego niż użytkownik główny, który używa nazwy SPN konta komputera), jest wykonywany następujący przepływ pracy.

Aby uzyskać szczegółowe instrukcje dotyczące uzyskiwania dostępu do woluminu Kerberos systemu plików NFS za pomocą użytkownika innego niż główny za pomocą usługi Azure NetApp Files, rozwiń listę.

• Użytkownik loguje się do centrum dystrybucji kluczy za pomocą wymiany nazwy użytkownika/hasła lub za pośrednictwem pliku tab klucza w celu uzyskania biletu TGT za pośrednictwem wywołania AS-REQ do użycia do zbierania biletu usługi z woluminu usługi Azure NetApp Files.
• Reguła zasad eksportu jest sprawdzana, aby upewnić się, że dostęp protokołu Kerberos jest dozwolony dla ścieżki eksportu dla maszyny klienckiej
• Usługa Azure NetApp Files sprawdza buforowany bilet usługi NFS. Jeśli żaden z nich nie istnieje, bilet usługi NFS jest żądany za pośrednictwem wywołania AP-REQ, a usługa sprawdza kartę klucza prawidłowego wpisu z prawidłowym typem szyfrowania przy użyciu biletu TGT od klienta uzyskanego z centrum dystrybucji kluczy
• Jeśli bilet TGT jest prawidłowy, zostanie wystawiony bilet usługi
• Główna nazwa użytkownika (UPN) jest mapowana za pomocą niejawnego mapowania. Jeśli na przykład nazwa UPN to user1@CONTOSO.COM, usługa wysyła zapytanie do użytkownika systemu UNIX o nazwie user1. Ponieważ ten użytkownik systemu UNIX nie istnieje w lokalnej bazie danych plików w usłudze Azure NetApp Files, jest używany protokół LDAP.
• Powiązanie LDAP przy użyciu konta komputera serwera SMB próbuje zezwolić na wyszukiwanie LDAP dla zamapowanego użytkownika. Zapytanie SRV DNS jest wykonywane dla rekordów DNS Protokołu Kerberos (_kerberos i _kerberos-master). Jeśli nie można użyć prawidłowych rekordów, konfiguracja wróci do konfiguracji obszaru. Te zapytania SRV DNS centrum dystrybucji kluczy nie są objęte zakresem lokacji.
• Rekordy SRV LDAP są odpytywane dla prawidłowych serwerów LDAP. Są one objęte zakresem witryny.
• Jeśli użytkownik nie istnieje w protokole LDAP lub nie można wykonać zapytania o protokół LDAP (serwer nie działa, wyszukiwanie DNS kończy się niepowodzeniem, niepowodzenie powiązania, upłynął limit czasu wyszukiwania LDAP, użytkownik nie istnieje), a następnie nie powiedzie się mapowanie i odmowa dostępu.
• Jeśli użytkownik istnieje, zbierane są członkostwa w grupach.
• Mapowanie kończy się pomyślnie, a bilet usługi NFS jest wystawiany klientowi (widoczny w klist -e poleceniach). Dostęp jest dozwolony na podstawie uprawnień do pliku na ścieżce eksportu.

Rola LDAP z protokołem Kerberos w usłudze Azure NetApp Files

Usługa Azure NetApp Files korzysta z protokołu LDAP dla protokołu Kerberos systemu plików NFS. Protokół Kerberos systemu plików NFS w usłudze Azure NetApp Files wymaga protokołu Kerberos dla mapowań nazw systemu UNIX dla przychodzących nazw SPN użytkowników. Ponieważ usługa Azure NetApp Files nie obsługuje tworzenia lokalnych użytkowników systemu UNIX, protokół LDAP jest wymagany do wykonywania wyszukiwania dla użytkowników systemu UNIX, gdy zażądano mapowania nazw.

• Po utworzeniu połączenia usługi Azure AD nazwa domeny usługi Active Directory służy do określania procesu wyszukiwania serwerów LDAP.
• Gdy wymagany jest serwer LDAP, _ldap.domain.com jest używany do wyszukiwania SRV dla serwerów LDAP.
• Po odnalezieniu listy serwerów najlepszy dostępny serwer (na podstawie czasu odpowiedzi ping) jest używany jako serwer LDAP dla połączenia przez port 389.
• Próba powiązania LDAP jest podejmowana przy użyciu konta maszyny SMB za pośrednictwem usługi GSS/Kerberos.
• Jeśli nie ma buforowanego połączenia lub poświadczeń protokołu Kerberos, zostanie wystawione nowe żądanie biletu protokołu Kerberos. Buforowane połączenia dla serwerów nazw w usłudze Azure NetApp Files na żywo przez 60 sekund. W przypadku bezczynności przez więcej niż 60 sekund pamięć podręczna połączenia zostanie wyczyszczone.
• System DNS służy do znajdowania odpowiednich kontrolerów KDC protokołu Kerberos za pośrednictwem rekordów SRV.
• Jeśli nie można odnaleźć kontrolerów KDC za pośrednictwem zapytania DNS, używane jest centrum dystrybucji kluczy określone w pliku krb5.conf dla usług SMB.
  • Jeśli to centrum dystrybucji kluczy jest nieosiągalne lub nie może przetworzyć żądania Protokołu Kerberos, powiązanie LDAP kończy się niepowodzeniem. Wyszukiwanie nazw również kończy się niepowodzeniem. Odmowa dostępu do instalacji, ponieważ nie doszło do prawidłowego uwierzytelniania.
  • Jeśli powiązanie powiedzie się, zapytanie LDAP jest wykonywane dla użytkownika i jego poświadczeń. Jeśli czas wyszukiwania przekroczy 10 sekund, wyszukiwanie zakończy się niepowodzeniem.
• Jeśli wyszukiwanie znajdzie użytkownika, mapowanie powiedzie się i dostęp zostanie udzielony za pośrednictwem protokołu Kerberos (pod warunkiem, że bilet jest prawidłowy/nie wygasł).

Adresy IP na potrzeby dostępu przy użyciu protokołu Kerberos

Domyślnie uwierzytelnianie Kerberos wykorzystuje rozpoznawanie nazwy hosta do adresu IP w celu sformułowania głównej nazwy usługi (SPN) używanej do pobierania biletu protokołu Kerberos. Na przykład gdy dostęp do udziału SMB jest uzyskiwany przy użyciu ścieżki UNIVERSAL Naming Convention (UNC), takiej jak \SMBVOLUME.CONTOSO.COM, żądanie DNS jest wystawiane dla w pełni kwalifikowanej nazwy domeny SMBVOLUME.CONTOSO.COM, a adres IP woluminu usługi Azure NetApp Files jest pobierany. Jeśli nie ma wpisu DNS (lub obecny wpis różni się od żądanych elementów, takich jak aliasy/CNAMEs), nie można pobrać odpowiedniej nazwy SPN, a żądanie Kerberos kończy się niepowodzeniem. W związku z tym dostęp do woluminu może być niedozwolony, jeśli metoda uwierzytelniania rezerwowego (np. New Technology LAN Manager) jest wyłączona.

Wpisy DNS w usłudze Azure NetApp Files są tworzone automatycznie przy użyciu dynamicznego systemu DNS i są formułowane przy użyciu nazwy serwera SMB. W przypadku wszelkich odmian/aliasów dla zdefiniowanej nazwy należy utworzyć ręczny rekord CNAME DNS i wskazać dynamiczny wpis DNS. Aby uzyskać więcej informacji, zobacz Omówienie systemu DNS w usłudze Azure NetApp Files.

Protokół Kerberos NFS 4.1 działa w podobny sposób w przypadku pobierania nazwy SPN, gdzie wyszukiwania DNS są integralną częścią procesu uwierzytelniania i mogą być również używane do odnajdywania obszaru Kerberos.

Jeśli adres IP (a nie nazwa hosta) jest używany w żądaniu dostępu do woluminu usługi Azure NetApp Files, żądanie Protokołu Kerberos działa inaczej w zależności od używanego protokołu.

Zachowanie protokołu Kerberos protokołu SMB z adresami IP i nazwami DNS

W przypadku korzystania z protokołu SMB żądanie ścieżki UNC przy użyciu adresu IP (na przykład \\x.x.x.x) domyślnie próbuje użyć protokołu NTLM do uwierzytelniania. W środowiskach, w których protokół NTLM jest niedozwolony ze względów bezpieczeństwa, żądanie SMB używające adresu IP nie może domyślnie używać protokołu Kerberos ani NTLM do uwierzytelniania. W związku z tym odmowa dostępu do woluminu usługi Azure NetApp Files. W nowszych wersjach systemu Windows (począwszy od systemów Windows 10 w wersji 1507 i Windows Server 2016) klienci Protokołu Kerberos mogą być skonfigurowani do obsługi nazw hostów IPv4 i IPv6 w nazwach SPN na potrzeby komunikacji SMB w celu obejścia tego problemu.

Zachowanie protokołu Kerberos NFSv4.1 z adresami IP i nazwami DNS

W przypadku korzystania z systemu plików NFSv4.1 żądanie instalacji do adresu IP przy użyciu jednej z sec=[krb5/krb5i/krb5p] opcji używa wyszukiwania wstecznego DNS za pośrednictwem ptR w celu rozpoznania adresu IP do nazwy hosta. Ta nazwa hosta jest następnie używana do formułowania nazwy SPN na potrzeby pobierania biletu Kerberos. Jeśli używasz systemu plików NFSv4.1 z protokołem Kerberos, musisz mieć wolumin A/AAAA i PTR dla woluminu usługi Azure NetApp Files w celu pokrycia zarówno nazwy hosta, jak i adresu IP dostępu do instalacji. Usługa Azure NetApp Files tworzy dynamiczny rekord A/AAAAA DNS. Jeśli istnieje odwrotna strefa DNS dla tej podsieci, rekord PTR jest również tworzony automatycznie. W przypadku odchyleń od standardowych konwencji nazw hostów usługi Azure NetApp Files użyj rekordów CNAME dla aliasów DNS.

Aby uzyskać więcej informacji, zobacz Omówienie systemu DNS w usłudze Azure NetApp Files