Sdílet prostřednictvím

Principy protokolu Kerberos ve službě Azure NetApp Files

  • Článek

Kerberos je ověřovací protokol, který používá tajný klíč k ověření identity objektů zabezpečení. Tajné klíče se generují tak, že převedou heslo instančního objektu do formátu kryptografického klíče s hodnotou hash pomocí schválené metody šifrování klientem a serverem (například AES). Informace o termínech použitých v tomto dokumentu najdete v části Terminologie protokolu Kerberos.

Distribuční centra klíčů (KDCS), jako je Windows Active Directory, udržují databázi objektů zabezpečení Kerberos a jejich hashovaná hesla. Tajný klíč v Protokolu Kerberos je důkazem jedinečné identity. Proto může být služba KDC důvěryhodná k ověření jakéhokoli objektu zabezpečení u jakéhokoli jiného objektu zabezpečení, jako je ověření hlavního názvu služby klienta NFS (SPN) u hlavního názvu služby serveru NFS při připojení. Je také možné důvěřovat ověření objektu zabezpečení uživatele u hlavního názvu služby serveru NFS pro přístup uživatele k přípojovému bodu NAS. Jako přidaná bezpečnostní opatření protokol Kerberos neodesílá hesla s jasným textem pro ověřování v rámci přenosu.

Azure NetApp Files podporuje použití protokolu Kerberos k zajištění zabezpečení v letu pro protokoly SMB i NFS.

Podporované typy šifrování

Azure NetApp Files podporuje protokol Kerberos nfs s konkrétními typy šifrování v závislosti na provozním režimu a používané verzi.

Pokud chcete zajistit, aby klient používal odpovídající typ šifrování, můžete omezit platné typy šifrování u objektového objektu umístěného v KDC (například v účtu počítače) nebo v ručně vytvořeném souboru keytab klienta, a ne globálně v souboru /etc/krb5.conf, pokud je to možné, protože správa mnoha souborů krb5.conf klienta může být bolestí hlavy správy. Centrální správa protokolu Kerberos z KDC je ve velkých podnikových prostředích škálovatelnější, je jednodušší automatizovat a vynutí, aby klient při podpoře používal silnější typy šifrování.

Poznámka:

Doporučujeme nastavit možnost allow_weak_crypto false v souboru krb5.conf na klientech. Toto nastavení zabraňuje méně zabezpečené enctypes komunikaci protokolu Kerberos (například DES nebo 3DES).

Následující tabulka uvádí podporované typy šifrování protokolu Kerberos (SMB i NFS) pro Službu Azure NetApp Files.

Protokol Podporované typy šifrování
SMB
  • RC4 HMAC
  • AES-128
  • AES-256
NFS AES-256

Podporované režimy zabezpečení kerberos nfs

Kromě konceptu typů šifrování existují také úrovně zabezpečení a kontroly integrity v protokolu Kerberos. V závislosti na používaném režimu zabezpečení tyto režimy zabezpečení pomáhají zabránit útokům typu man-in-the-middle tím, že nabízejí kompletní šifrování provozu NFS.

V Azure NetApp Files jsou tyto režimy zabezpečení zadané v pravidlech zásad exportu nastavené pro svazek pro systém souborů NFS a definované během počátečního připojení NFS prostřednictvím možnosti připojení s sekundou.

Například: # mount -o sec=krb5p

Poznámka:

V případě protokolu SMB Kerberos se režimy zabezpečení protokolu Kerberos řídí prostřednictvím nastavení šifrování PROTOKOLU SMB ve sdílené složce, posílení zabezpečení UNC a zásad podepisování/zapečetění protokolu SMB na řadičích domény.

Azure NetApp Files podporuje následující režimy zabezpečení pro použití s protokolem Kerberos systému souborů NFS:

Režim zabezpečení Popis
krb5 Pouze šifrování ověřování.

K ověřování uživatelů používá řetězce názvů Kerberos V5 a hlavní názvy uživatelů místo místních ID uživatelů systému UNIX (UID) a ID skupin (GID).
krb5i Šifrování ověřování a kontrola šifrované integrity

Používá protokol Kerberos V5 k ověřování uživatelů a také provádí kontrolu integrity operací NFS pomocí zabezpečených kontrolních součtů, aby se zabránilo manipulaci s daty a útokům man-in-the-middle.
krb5p Celá konverzace NFS je zašifrovaná.

Používá protokol Kerberos V5 pro ověřování uživatelů a kontrolu integrity a také šifruje veškerý provoz NFS, aby se zabránilo zašifrování paketů. Toto nastavení je nejbezpečnější, ale zároveň vytváří největší režii na výkon.

Terminologie protokolu Kerberos

Tato část definuje klíčovou terminologii, která se používá při popisu procesů kerberos. Tato část je určená k objasnění termínů, které můžou být pro správce úložiště neznámé.

Pojem definice
Distribuční centrum klíčů (KDC) KDC je ověřovací server, který zahrnuje službu TGS (Ticket-Grant Service) a ověřovací službu (AS). Termíny KDC, AS a TGS se používají zaměnitelně. V prostředích Microsoftu je řadič domény služby Active Directory KDC.
Sféra (nebo sféra Kerberos) Sféra (nebo sféra Kerberos) může používat libovolný řetězec ASCII. Standardem je použití názvu domény velkými písmeny; například contoso.com se stane CONTOSO.COM sféry. Sféry Kerberos se obvykle konfigurují v souborech krb5.conf na klientech a serverech.

Každý principal@REALM musí být jedinečný. Aby nedocházelo k selhání, může mít každá sféra více řadičů domény, které sdílejí stejnou databázi (objekty zabezpečení a jejich hesla) a mají stejné hlavní klíče KDC. Služba Microsoft Windows Active Directory to provádí nativně prostřednictvím replikace služby Active Directory, která probíhá ve výchozím nastavení každých 15 minut.
Objekt zabezpečení Objekt zabezpečení termínů odkazuje na každou entitu v databázi Kerberos. Všichni uživatelé, počítače a služby mají přiřazené objekty zabezpečení pro ověřování protokolem Kerberos. Každý objekt zabezpečení musí být jedinečný v rámci databáze Kerberos a je definován jeho rozlišujícím názvem. Instanční objekt může být hlavní název uživatele (UPN) nebo hlavní název služby (SPN).

Hlavní název má tři části:
  • Primární – primární částí může být uživatel nebo služba, jako je služba NFS. Může to být také speciální "hostitel služby", který označuje, že tento instanční objekt je nastavený tak, aby poskytoval více různých síťových služeb.
  • Instance – Tato část je volitelná v případě uživatele. Uživatel může mít více než jeden objekt zabezpečení, ale každý objekt zabezpečení musí být v KDC jedinečný. Fred může mít například objekt zabezpečení, který je určený pro každodenní použití (fred@contoso.com) a objekt zabezpečení, který umožňuje privilegované použití, například účet sysadmin (admin-fred@contoso.com). Instance se vyžaduje pro instanční objekty a určí plně kvalifikovaný název domény hostitele, který službu poskytuje.
  • Sféra – Sféra Kerberos je sada objektů zabezpečení Kerberos, které jsou zaregistrované na serveru Kerberos. Podle konvence je název sféry obvykle stejný jako název DNS, ale převede se na velká písmena. Velká písmena nejsou povinná, ale konvence poskytuje snadný rozdíl mezi názvem DNS a názvem sféry.
Lístky Lístek je dočasná sada přihlašovacích údajů, která ověřuje identitu instančního objektu a obsahuje klíč relace. Lístek může být služba, lístek aplikace nebo lístek pro udělení lístku (TGT). Lístky se vyměňují mezi klientem, serverem a KDC za ověřování protokolem Kerberos.
Tajné klíče Kerberos používá symetrický systém klíčů, ve kterém se tajný klíč používá pro šifrování i dešifrování. Tajný klíč se vygeneruje z hesla Kerberos objektu zabezpečení pomocí jednosměrné hashovací funkce. KDC ukládá heslo pro každý objekt zabezpečení a může tak vygenerovat tajný klíč objektu zabezpečení. Pro uživatele, kteří požadují službu Kerberos, se tajný klíč obvykle odvozuje od hesla předaný programu kinit. Instanční objekty a objekty démon obvykle nepoužívají heslo; místo toho je výsledek jednosměrné hash funkce uložen v tabulce klíčů.
Klávesová zkratka Keytab obsahuje seznam objektů zabezpečení a jejich tajných klíčů. Tajné klíče v tabulce klíčů se často vytvářejí pomocí náhodného hesla a používají se většinou pro instanční objekty nebo objekty démona.

Informace o síťovém portu

Následující tabulka popisuje, které síťové porty se používají pro komunikaci protokolem Kerberos. Pokud je zavedená síťová brána firewall, měly by být tyto porty otevřené, aby umožňovaly správné funkce protokolu Kerberos. Další informace o těchtoportch

Služba Port
Kerberos 88 (TCP/UDP)
kpasswd 464 (TCP/UDP)
Protokol LDAP (Lightweight Directory Access Protocol) (pro mapování názvů) 389 (TCP/UDP)
Server pro správu 749 (TCP/UDP)
Globální katalog (vyhledávání uživatelů Windows) 3268 (TCP/UDP)

Hodnoty stáří mezipaměti ve službě Azure NetApp Files

Následující tabulka zobrazuje dobu, po kterou se položka mezipaměti nachází ve svazku Azure NetApp Files.

Mezipaměť Stáří mezipaměti
Nečinná připojení názvového serveru 60 sekund
Vypršení časového limitu dotazu LDAP 10 sekund
Položka místního hostitele DNS pro hodnotu TTL služby KDC 24 hodin
Stáří lístku Kerberos Zadané službou KDC* nebo klientem

* Výchozí hodnota je 10 hodin pro klíčové ukazatele výkonu služby Windows Active Directory.
Přihlašovací údaje uživatele 24 hodin
Nerovnoměrná distribuce času Protokolu Kerberos 5 minut

Požadavky na správné fungování prostředí Kerberos ve službě Azure NetApp Files

Ověřování protokolem Kerberos je vysoce závislé na externích službách pro správné fungování. V Microsoft Active Directory se většina těchto služeb v mnoha případech zkombinuje do jednoho serveru. Například řadič domény služby Active Directory může obsluhovat následující závislosti protokolu Kerberos:

  • Služby synchronizace času
  • DNS
  • Distribuce klíčů Kerberos
  • Služby hesel / jednotné přihlašování
  • Služby identit (například LDAP)

Při použití nativní služby Microsoft Active Directory (jediný typ KDC, který služba Azure NetApp Files aktuálně podporuje), je probíraná většina externích závislostí protokolu Kerberos ve službě Azure NetApp Files, jako jsou DNS, KDC a služby hesel. V některých případech můžou být požadované služby hostované mimo doménu služby Active Directory (například DNS). V takových případech je důležité zajistit, aby byly požadované služby správně nakonfigurované.

Azure NetApp Files má specifické závislosti pro správné fungování protokolu Kerberos systému souborů NFS. Další informace najdete v článku.

Služby synchronizace času

Synchronizační služby času jsou při ověřování povinné, protože mechanismy lístku Kerberos závisí na časovém nerovnoměrné distribuci mezi klientem a serverem ve výchozím 5minutovém rozsahu. Pokud nastavení času na klientovi nebo serveru překročí tento pětiminutový rozsah, ověřování Kerberos selže s chybou časové nerovnoměrné distribuce (KRB_AP_ERR_SKEW) a přístup ke sdílené složce NAS se odepře. Tento časový limit je funkce zabezpečení, která pomáhá zabránit útokům na přehrání, kdy útočník může zachytit zprávy mezi KDC a klientem a pak tyto zprávy přehrát později, aby zosobnil ověřeného uživatele. Omezení časové nerovnoměrné distribuce pomáhají minimalizovat riziko těchto typů útoků.

Klíčové aspekty problémů se synchronizací času:

Další informace naleznete v tématu Maximální tolerance pro synchronizaci hodin počítače

Dns (Domain Name Systems)

Systémy DNS (Domain Name Systems) jsou pro Kerberos povinné jako funkci zabezpečení. Překlad názvů hostitelů se používá k formulovat instanční objekty Kerberos používané k ověřování. V tomto procesu se k připojení ke sdíleným složkám využívajícím ověřování Kerberos používají vyhledávání názvů hostitelů (záznamy A/AAAA). Toto dopředné vyhledávání se pak použije k vytvoření hlavního názvu služby (SPN) použitého v žádosti o ověření protokolu Kerberos. Pokud se ve službě KDC nenajde existující hlavní název služby (SPN), ověřování kerberos se nezdaří.

V prostředích SMB systému Windows může být vyzkoušena metoda ověřování zálohování (například NTLM). V mnoha případech je však protokol NTLM zakázán z bezpečnostních důvodů, což by způsobilo selhání přístupu ke sdílené složce při selhání ověřování protokolem Kerberos. Prohlížeč událostí systému Windows často protokoluje původní příčinu selhání (například duplicitní nebo chybějící hlavní názvy služeb (SPN), selhání vyhledávání DNS, chyby ntLM atd.).

Kromě překladu hlavního názvu služby (SPN) se DNS intenzivně využívá k překladu názvů hostitelů a IP adres pro doménové služby, jako je LDAP, KDCS protokolu Kerberos atd. prostřednictvím záznamů SRV. Podrobnější informace o DNS ve službě Azure NetApp Files (včetně požadovaných záznamů SRV) najdete v tématu O DNS ve službě Azure NetApp Files.

Poznámka:

Pokud se pro přístup k protokolu Kerberos používá IP adresa, chování závisí na používaném protokolu NAS (NFS nebo SMB). Další informace najdete v tématu IP adresy pro přístup pomocí protokolu Kerberos.

LDAP

Protokol LDAP (Lightweight Directory Access Protocol) využívá databáze identit back-endu k poskytování sjednoceného zdroje názvových služeb pro klienty a servery NAS, aby všechna účastná zařízení souhlasila s pravostí uživatelů, členstvím ve skupinách a číselnými ID, která se pak používají pro oprávnění k souborům.

V případě protokolu Kerberos se uživatele a instanční objekty ukládají s položkami v databázích LDAP jako atributy v hlavních účtech. Windows Active Directory to ve výchozím nastavení podporuje. V některých případech (například při vytváření aliasů nebo instančních objektů) uživatelé a počítače vyžadují přidání nebo úpravu názvů instančních objektů. Tento požadavek můžete splnit pomocí konzoly MMC (Uživatelé a počítače služby Active Directory Microsoft Management Console) nebo pomocí PowerShellu. Další informace o správě názvů instančních objektů najdete v tématu Správa hlavních názvů služeb.

Kromě instančních názvů a číselných ID pro ověřování protokolem Kerberos je možné protokol LDAP použít také pro identity uživatelů a skupin systému UNIX, které se používají k mapování názvů identit ve službě Azure NetApp Files a také k počátečnímu ověřování pro připojení kerberos nfs prostřednictvím mapování uživatelských jmen SPN –> UNIX. Další podrobnosti najdete v tématu Fungování protokolu Kerberos nfs v roli Služby Azure NetApp Files a PROTOKOLU LDAP s Protokolem Kerberos ve službě Azure NetApp Files.

Jak funguje protokol SMB Kerberos ve službě Azure NetApp Files

Protokol SMB Kerberos funguje odděleně od služeb Kerberos systému souborů NFS, protože účty počítačů vytvořené pro každý protokol nemůžou sdílet klíčovétaby kvůli možnému změnám čísla verze klíče (kvno) v jedné tabulce klíčů, která má vliv na druhou službu. V důsledku toho se pracovní postupy pro služby SMB pro protokoly Kerberos a NFS pro Kerberos a NFS v některých oblastech liší v přirozeném rozdílu v protokolech NAS.

Počáteční konfigurace služeb SMB

Služby SMB v Azure NetApp Files se zpočátku konfigurují nastavením připojení Active Directory, které definuje několik důležitých částí pro interakci s doménovými službami, včetně:

  • Primární server DNS (povinné)
  • Sekundární DNS
  • Název DNS služby Active Directory*
  • Název lokality služby Active Directory (pro zjišťování řadiče domény) (povinné)
  • Název předpony serveru SMB
  • Organizační jednotka (kde by měly být účty počítačů uložené v doméně Azure AD)
  • Povolení nebo zakázání šifrování AES
  • Povolení nebo zakázání podepisování PROTOKOLU LDAP
  • Konfigurace PROTOKOLU LDAP
  • Šifrování SMB do řadiče domény
  • Privilegovaní uživatelé
  • Přihlašovací údaje pro uživatelské jméno a heslo uživatele s oprávněními organizační jednotky

Poznámka:

Pro každý účet je povolené pouze jedno připojení Azure Active Directory (AD). Po vytvoření připojení Azure AD bude každý nový svazek SMB služby Azure NetApp Files používat konfiguraci připojení Azure AD.

Účet počítače protokolu SMB Kerberos

Účet počítače ve službě Active Directory obsahuje relevantní informace pro použití v žádostech o ověření, včetně hlavního názvu služby (SPN). Při vytváření svazku SMB ve službě Azure NetApp Files se konfigurace připojení Active Directory používá k interakci při vytváření účtu počítače, který zajišťuje zabezpečený přístup ke sdílené složce SMB prostřednictvím ověřování Kerberos (nebo NTLM, pokud je povoleno).

Nové účty počítačů se vytvoří při zřízení svazku SMB služby Azure NetApp Files u konkrétního back-endového prostředku ve službě. Následující příklady ukazují různé scénáře, ve kterých se může vytvořit nebo znovu použít účet počítače SMB v konfiguracích svazků Azure NetApp Files.

Scénář Výsledek
První nový svazek SMB Nový účet počítače SMB nebo název DNS
Následné svazky SMB vytvořené krátce po sobě od prvního svazku SMB Opakovaně použitý účet počítače SMB nebo název DNS (ve většině případů)
Další svazky SMB se vytvořily mnohem později než první svazek SMB. Služba určuje, jestli je potřeba nový účet počítače. Je možné vytvořit více účtů počítačů, které vytvoří více koncových bodů IP adres.
První svazek se dvěma protokoly Nový účet počítače SMB nebo název DNS
Následné svazky se dvěma protokoly vytvořené krátce po sobě od prvního svazku se dvěma protokoly Opakovaně použitý účet počítače SMB nebo název DNS (ve většině případů)
Následné svazky se dvěma protokoly vytvořily mnohem později než první svazek se dvěma protokoly. Služba určuje, jestli je potřeba nový účet počítače. Je možné vytvořit více účtů počítačů, které vytvoří více koncových bodů IP adres.
První svazek SMB vytvořený po svazku se dvěma protokoly Nový účet počítače SMB nebo název DNS
První svazek se dvěma protokoly vytvořený po svazku SMB Nový účet počítače SMB nebo název DNS

Účet počítače SMB vytvořený pro svazek SMB služby Azure NetApp Files (nebo duální protokol) používá konvenci pojmenování, která dodržuje 15znakové maximum vynucené službou Active Directory. Název používá strukturu [předpona serveru SMB zadaná v konfiguraci připojení Azure AD]-[jedinečný číselný identifikátor].

Pokud jste například nakonfigurovali připojení Azure AD tak, aby používala předponu serveru SMB AZURE, účet počítače SMB, který služba Azure NetApp Files vytvoří, se podobá azure-7806. Stejný název se používá v cestě UNC pro sdílenou složku SMB (například \AZURE-7806) a je název, který dynamické služby DNS používají k vytvoření záznamu A/AAAA.

Poznámka:

Protože název jako "AZURE-7806" může být obtížné zapamatovat, je vhodné vytvořit záznam CNAME jako alias DNS pro svazky Azure NetApp Files. Další informace naleznete v tématu Vytváření aliasů serveru SMB.

Diagram více účtů počítačů nebo záznamů DNS ve službě Azure NetApp Files

V některých případech může konfigurace při vytváření více svazků SMB nebo duálních protokolů skončit s několika různorodými účty počítačů SMB a názvy DNS.

Pokud je potřeba použít jeden obor názvů pro přístup uživatelů mezi svazky, může to v konfiguraci představovat výzvu, protože jeden alias CNAME může odkazovat jenom na jeden záznam hostitele A/AAAAA, zatímco použití několika stejných aliasů záznamů A/AAAAA může způsobit neprediktovatelnost přístupu k datům v přístupu ke svazkům napříč různými účty počítačů SMB. protože neexistuje žádná záruka, že koncový bod, který klient vybere ve vyhledávání DNS, obsahuje očekávaný svazek z důvodu kruhového dotazování výběru záznamu DNS v těchto konfiguracích.

Aby bylo možné toto omezení vyřešit, můžou se svazky Azure NetApp Files účastnit jako cíle v konfiguraci systému souborů DFS (Microsoft Distributed File System), která umožňuje přidružit několik svazků SMB k jednomu vstupnímu bodu oboru názvů.

Diagram distribuovaného systému souborů ve službě Azure NetApp Files

Pracovní postup vytváření SPN protokolu SMB Kerberos

Následující diagram znázorňuje, jak se při vytvoření svazku SMB nebo svazku se dvěma protokoly vytvoří hlavní název protokolu KERBEROS protokolu SMB s protokolem SMB služby Azure NetApp Files. Hlavní názvy služby SMB jsou přidružené k objektům účtu počítače SMB v doméně. Hlavní název služby (SPN) je možné zobrazit a spravovat pomocí vlastností účtu počítače pomocí editoru atributů v rozšířeném zobrazení.

Snímek obrazovky s vlastnostmi Azure-SMB

Pomocí příkazu můžete také zobrazit a spravovat vlastnosti.setspn

Snímek obrazovky s příkazem setspn

Tento proces se řídí stejnými kroky, jako když se běžný klient Windows připojí k doméně (DNS, LDAP, Kerberos, RPC dotazy přes pojmenované kanály).

Diagram účtu počítače Kerberos

Ve většině případů není znalost podrobných kroků nutná pro každodenní úlohy správy, ale je užitečná při řešení potíží se selháními při pokusu o vytvoření svazku SMB ve službě Azure NetApp Files.

Podrobné kroky

Podrobný postup vytvoření účtu počítače SMB v Azure NetApp Files najdete v seznamu.

  • Vyhledávání DNS se provádí pomocí konfigurace DNS pro záznam SRV služby Kerberos KDC. Azure NetApp Files ve svých požadavcích používá následující záznamy SRV.

    • _kerberos._tcp.dc._msdcs.CONTOSO.COM
    • _kerberos._tcp.CONTOSO.COM (pokud předchozí dotaz nevrátí žádné výsledky)

  • Vyhledávání DNS se provádí pomocí názvů hostitelů vrácených v dotazu SRV pro záznamy A/AAAA řadičů domény.

  • Azure NetApp Files provádí dotaz DNS, který vyhledá servery LDAP v doméně pomocí následujících záznamů SRV:

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

    Poznámka:

    K těmto dotazům dochází vícekrát ve stejném volání v různých částech procesu. Problémy s DNS můžou v těchto voláních způsobit zpomalení nebo s vypršením časového limitu, úplnými selháními. – Pokud se dotazům nepodaří najít položku nebo pokud nalezené položky nejde kontaktovat, vytvoření svazku SMB se nezdaří. – Pokud jsou dotazy DNS úspěšné, pak se zpracují další kroky.

  • Protokol ICMP (ping) se odešle a zkontroluje, jestli jsou IP adresy vrácené z DNS dostupné.

  • Pokud zásady brány firewall zablokují příkaz ping v síti, požadavek ICMP selže. Místo toho se používají příkazy ping protokolu LDAP.

  • K vyhledání dostupných starších serverů NetLogon pomocí dotazu (&(&(DnsDomain=CONTOSO.COM)(Host=KDChostname.contoso.com))(NtVer=0x00000006)) s filtrem atributů NetLogon se provádí další příkaz ping protokolu LDAP. Novější verze řadiče domény s Windows (větší než 2008) nemají hodnotu NtVer .

  • Ověřování AS-REQ se odesílá ze služby Azure NetApp Files pomocí uživatelského jména nakonfigurovaného pro připojení active directory.

  • Řadič domény odpoví KRB5KDC_ERR_PREAUTH_REQUIRED, což žádá službu, aby bezpečně odeslala heslo pro uživatele.

  • Druhá funkce AS-REQ se odešle s předem ověřenými daty potřebnými k ověření v KDC, aby bylo možné pokračovat v vytváření účtu počítače. V případě úspěchu se službě odešle lístek TGT (Ticket Grant Ticket).

  • V případě úspěchu služba odešle žádost o lístek služby CIFS (cifs/kdc.contoso.com) služby TGS-REQ pomocí lístku TGT přijatého v AS-REP.

  • Provede se nová vazba PROTOKOLU LDAP pomocí lístku služby CIFS. Dotazy se odesílají ze služby Azure NetApp Files:

    • Základní vyhledávání RootDSE pro dnu domény ConfigurationNamingContext
    • OneLevel search of CN=partitions in the DN retrieved for the ConfigurationNamingContext using the filter (&(&(objectClass=crossRef)(nETBIOSName=*))(dnsRoot=CONTOSO.COM)) for the attribute NETBIOSname.
    • Základní vyhledávání pomocí filtru (|(objectClass=organizationalUnit)(objectClass=container)) se provádí v organizační jednotce zadané v konfiguraci připojení služby Active Directory. Pokud není zadáno, použije se výchozí hodnota OU=Computers . Tím ověříte, že kontejner existuje.
    • Vyhledávání podstromů se provádí na základě základního názvu domény pomocí filtru (sAMAccountName=ANF-XXXX$) a zkontrolujete, jestli účet již existuje.
      • Pokud účet existuje, použije se znovu.
    • Pokud účet neexistuje, vytvoří se za předpokladu, že uživatel má oprávnění k vytvoření a úpravě objektů v kontejneru pomocí addRequest příkazu LDAP. Pro účet jsou nastaveny následující atributy LDAP:
    Atribut Hodnota
    CN ANF-XXXX
    sAMAccountName ANF-XXXX$
    objectClass
    • Hlavní
    • Osoba
    • Organizační osoba
    • Uživatelská
    • Počítač
    servicePrincipalName
    • HOSTITEL/ANF-XXXX
    • HOSTITEL/anf-xxxx.contoso.com
    • CIFS/anf-xxxx.contoso.com
    userAccountControl 4096
    operatingSystem Verze NetApp
    dnsHostName ANF-XXXX.CONTOSO.COM
    • Pokud dojde k addRequest selhání, vytvoření svazku selže. Může addRequest selhat kvůli nesprávným oprávněním k objektu kontejneru.
    • Pokud bude úspěšné addRequest , provede se vyhledávání LDAP pomocí filtru (sAMAccountName=ANF-XXXX$) pro načtení atributu objectSid.
    • Konverzace protokolu SMB2 Negotiate se provádí za účelem načtení podporovaného protokolu Kerberos mechTypes z KDC.
    • Provede se nastavení relace SMB2 pomocí hlavního názvu služby CIFS a nejvyšší podporované mechType služby a provede se připojení stromu k IPC$.
    • Ve sdílené složce IPC$ se vytvoří soubor SMB2 lsarpc .
    • Provede se vazba na DCERPC . Soubor lsarpc se pak zapíše a přečte.
    • Pak se provádějí následující požadavky LSA:

  • TGS-REQ pomocí TGT se provede k načtení lístku hlavního kadmin/changepw názvu služby přidruženého k krbtgt účtu.

  • Požadavek KPASSWD se provádí ze služby do KDC za účelem změny hesla účtu počítače.

  • Dotaz LDAP se provádí s filtrem (sAMAccountName=ANF-XXXX) pro atributy distinguishedName a isCriticalSystemObject.

  • Pokud je účet isCriticalSystemObject false (výchozí), načtený NÁZEV se použije k formulaci modifyRequest atributu msDs-SupportedEncryptionTypes. Tato hodnota je nastavena na hodnotu 30, která odpovídá DES_CBC_MD5 (2) + RC4 (4) + AES 128 (8) + AES 256 (16)hodnotě .

  • Provede se druhý protokol Negotiate protocol/Kerberos ticket exchange/"Session setup"/"Tree connect" k IPC$. Účet počítače serveru SMB (ANF-XXXX$) slouží jako instanční objekt Kerberos.

  • Komunikace NetLogon, NetrServer ReqChallenge/Authenticate2 se dokončí.

  • Provede se třetí "Negotiate protocol:/Kerberos ticket exchange/"Session setup"/"Tree connect" k IPC$ ; Účet počítače serveru SMB (ANF-XXXX$) se používá jako instanční objekt Kerberos.

  • Připojení lsarpc NetLogon se provádějí jako konečná kontrola účtu.

Pracovní postup připojení ke sdílené složce SMB (Kerberos)

Když se svazek Azure NetApp Files připojí pomocí protokolu Kerberos, použije se výměna lístků Kerberos během několika žádostí o nastavení relace k zajištění zabezpečeného přístupu ke sdílené složce. Ve většině případů není znalost podrobných kroků nutná pro každodenní úlohy správy. Tyto znalosti jsou užitečné při řešení potíží se selháním při pokusu o přístup ke svazku SMB v Azure NetApp Files.

Diagram pracovního postupu připojení sdílené složky SMB

Podrobný postup přístupu ke sdílené složce SMB ve službě Azure NetApp Files najdete v seznamu.
  • Klient se pokusí o přístup ke sdílené složce SMB pomocí cesty UNC zobrazené v Azure NetApp Files. Ve výchozím nastavení by cesta UNC obsahovala název serveru SMB (například ANF-XXXX).
  • Dns se dotazuje na mapování názvu hostitele na IP adresu.
  • Probíhá počáteční konverzace protokolu SMB2 Negotiate Protocol .
    • Požadavek se odešle z klienta, aby zjistil, které dialekty SMB server podporuje, a obsahuje to, co klient žádajícího klienta podporuje.
    • Server odpoví tím, co podporuje, včetně následujících:
      • Režim zabezpečení (podepisování nebo ne)
      • Verze protokolu SMB
      • Identifikátor GUID serveru
      • Podporované možnosti (DFS, leasing, velké MTU, multichannel, trvalé popisovače, pronájem adresářů, šifrování)
      • Maximální velikost transakce
      • Maximální velikost čtení a zápisu
      • Objekt blob zabezpečení (Kerberos nebo NTLM)
  • Druhá konverzace smb2 "Negotiate Protocol" probíhá jako "předběžné ověření" /login
    • Požadavek od klienta zahrnuje:
      • Hodnota hash předběžného ověření
      • Podporované režimy zabezpečení (podepisování nebo ne)
      • Podporované možnosti (DFS, leasing, velké MTU, multichannel, trvalé popisovače, pronájem adresářů, šifrování)
      • IDENTIFIKÁTOR GUID klienta
      • Podporované dialekty SMB
    • Pokud je hodnota hash předběžného ověření přijata, server odpoví takto:
      • Režim zabezpečení (podepisování nebo ne)
      • Podporované možnosti (DFS, leasing, velké MTU, multichannel, trvalé popisovače, pronájem adresářů, šifrování)
      • Maximální velikost transakce
      • Maximální velikost čtení a zápisu
      • Objekt blob zabezpečení (Kerberos nebo NTLM)
      • Možnosti integrity a šifrování předběžného ověřování SMB
  • Pokud je vyjednávání protokolu úspěšné, provede se požadavek Nastavení relace.
    • Instalační program používá hodnotu hash předběžného ověření z vyjednávání protokolu.
    • Instalační program informuje server SMB o tom, co klient požaduje, včetně:
      • StructureSize
      • Příznak vazby relace
      • Režim zabezpečení (podepisování povoleno/povinné)
      • Možnosti
      • Podporované typy šifrování Kerberos
  • Odešle se odpověď Nastavení relace.
    • Kredity SMB jsou uděleny.
    • Je vytvořeno ID relace.
    • Příznaky relace jsou nastavené (host, null, encrypt).
    • Je definován typ šifrování Kerberos.
  • Klient odešle požadavek na připojení ke sdílené složce SMB klientem.
    • Příznaky nebo možnosti sdílení se odesílají ze serveru spolu s oprávněními ke sdílení.
  • FSCTL_QUERY_NETWORK_INTERFACE_INFO Příkaz ioctl se odešle, aby získal IP adresu serveru SMB.
  • Server SMB v Azure NetApp Files hlásí informace o síti, včetně: * IP adresa * Funkce rozhraní (RSS zapnuto nebo vypnuto) * Počet front RSS * Rychlost propojení
  • Klient odešle požadavek na připojení ke sdílené složce pro správu IPC$.
    • Sdílená složka IPC$ je prostředek, který sdílí pojmenované kanály, které jsou nezbytné pro komunikaci mezi programy. Sdílená složka IPC$ se používá při vzdálené správě počítače a při prohlížení sdílených prostředků počítače. Nemůžete změnit nastavení sdílené složky, vlastnosti sdílené složky ani seznamy ACL sdílené složky IPC$. Sdílenou složku IPC$ nemůžete přejmenovat ani odstranit.
    • Soubor s názvem srvsvc se vytvoří ve sdílené složce jako popisovač služby.
  • Vazba DCERPC se provádí se souborem srvsvc za účelem navázání zabezpečeného připojení.
    • Soubor se zapíše s dříve načtenými informacemi.
  • Klient Systému Windows vydá protokol TGS-REQ protokolu Kerberos pro službu KDC, aby získal lístek služby (ST) pro službu SMB.
  • Příkaz NetShareGetInfo spustí klient SMB na server a odešle se odpověď.
  • Lístek služby SMB se načte z KDC.
  • Azure NetApp Files se pokusí namapovat uživatele Windows požadujícího přístup ke sdílené složce na platného uživatele systému UNIX.
    • Požadavek Kerberos TGS se provádí pomocí přihlašovacích údajů protokolu Kerberos serveru SMB uložených v tabulce klíčů serveru SMB od počátečního vytvoření serveru SMB, který se použije pro vazbu serveru LDAP.
    • Protokol LDAP vyhledá uživatele se systémem UNIX, který je namapovaný na uživatele PROTOKOLU SMB, který požaduje přístup ke sdílené složce. Pokud v protokolu LDAP neexistuje žádný uživatel systému UNIX, použije služba Azure NetApp Files výchozího uživatele pcuser systému UNIX k mapování názvů (soubory/složky napsané ve svazcích se dvěma protokoly používají mapovaného uživatele systému UNIX jako vlastníka systému UNIX).
  • Provede se další žádost o protokol/požadavek relace/stromové připojení, tentokrát pomocí hlavního názvu služby Kerberos serveru SMB ke sdílené složce IPC$ řadiče domény služby Active Directory.
    • Pojmenovaný kanál je vytvořen ke sdílené složce prostřednictvím srvsvc.
    • Relace NETLOGON se naváže na sdílenou složku a uživatel Windows se ověří.
  • Pokud oprávnění umožňují uživateli, zobrazí sdílená složka seznam souborů a složek obsažených ve svazku.

Poznámka:

Azure NetApp Files přidá položky do kontextové mezipaměti Kerberos pro klienta. Tyto položky se nacházejí v mezipaměti po dobu životnosti lístku Kerberos (nastaveného službou KDC a řízeny zásadami Kerberos).

Vytváření aliasů serveru SMB

Když Azure NetApp Files vytvoří server SMB pomocí zásady vytváření názvů [předpona serveru SMB zadaná v konfiguraci připojení Azure AD]-[jedinečný číselný identifikátor]. (Podrobnosti o jedinečném číselném identifikátoru najdete v tématu Účet počítače SMB Kerberos). Toto formátování znamená, že názvy serverů SMB nejsou vytvořené uživatelsky přívětivým způsobem. Například název SMB-7806 je obtížnější zapamatovat si, než je něco podobného jako "AZURE-FILESHARE".

Kvůli tomuto chování můžou správci chtít vytvořit uživatelsky přívětivé názvy aliasů pro svazky Azure NetApp Files. To vyžaduje nasměrování kanonického názvu DNS (CNAME) na existující záznam DNS A/AAAAA na serveru.

Když se vytvoří ANAME a použije se v požadavcích cest UNC (například \\AZURE-FILESHARE místo \\SMB-7806), DNS přesměruje požadavek CNAME (AZURE-FILESHARE.contoso.com) na správný záznam A/AAAA (SMB-7806.contoso.com), který se používá v načítání SPN kerberosu (cifs/SMB-7806). To umožňuje přístup protokolu Kerberos ke sdílené složce SMB při použití názvu aliasu.

Pokud se vytvoří záznam DNS A/AAAA (například AZURE-FILESHARE.contoso.com) a pokusí se ho použít jako alias, požadavky Kerberos selžou. Selhání je výsledkem vytvořeného hlavního názvu služby použitého k ověření sdílené složky (cifs/AZURE-FILESHARE), která neodpovídá názvu služby Kerberos SPN pro server SMB (cifs/SMB-7806). Selhání je možné zmírnit, pokud se vytvoří jiný hlavní název služby (SPN) a připojí se k účtu serveru SMB (například cifs/AZURE-FILESHARE).

Podporované možnosti serveru SMB ve službě Azure NetApp Files

Když se vytvoří požadavek SMB negotiate protocol, server SMB služby Azure NetApp Files se dotazuje na podporu konkrétních funkcí. Následující tabulka ukazuje možnosti dotazované a odpověď vrácená ze svazku SMB služby Azure NetApp Files při provedení připojení ke stromu nebo nastavení relace.

Funkce SMB Podporuje azure NetApp Files?
Cíl DFS Ano
Leasing Ano
Velké MTU Ano
Vícekanálový protokol SMB Ano
Trvalé popisovače SMB Ano
Pronájem adresářů No
Šifrování SMB Ano (pokud je povoleno)

Podporované možnosti a vlastnosti sdílené složky SMB ve službě Azure NetApp Files

Během přístupu ke sdílené složce SMB se provede požadavek "připojení stromu" a na server Azure NetApp Files se dotáhnou podporované možnosti a vlastnosti sdílené složky SMB. Následující tabulka ukazuje možnosti sdílení, na které se dotazovaly, a odpověď vrácená ze svazku SMB služby Azure NetApp Files, jak je vidět v zachytávání paketů.

Funkce sdílení protokolu SMB Podporuje azure NetApp Files?
Nepřetržitě dostupná (CA) Ano, pro konkrétní úlohy* (pokud je povoleno)
Horizontální navýšení kapacity No
Cluster No
Asymetrický No
Přesměrování na vlastníka No

* Viz Povolení nepřetržité dostupnosti u stávajících svazků SMB pro podporované úlohy.

Následující tabulka zobrazuje dotazované vlastnosti sdílené složky a odpověď vrácená ze svazku SMB služby Azure NetApp Files.

Funkce sdílení protokolu SMB Podporuje azure NetApp Files?
Cíl DFS Ano
Kořen DFS No
Omezit výhradní otevření No
Vynucené sdílené odstranění No
Povolit ukládání do mezipaměti oboru názvů No
Výčet na základě přístupu Ano (pokud je povoleno)
Vynucení oplocku ii No
Povolení hodnoty hash V1 No
Povolení hodnoty hash v2 No
Vyžaduje se šifrování. Ano (pokud je povoleno)
Vzdálené komunikace identit No
Komprimované vstupně-výstupní operace No
Izolovaný přenos No

Jak funguje kerberos NFS ve službě Azure NetApp Files

Kerberos systému souborů NFS funguje odděleně od služeb SMB, protože účty počítačů vytvořené pro každý protokol nemůžou sdílet klíčovétaby kvůli možnému změnám čísla verze klíče (kvno) v jedné tabulce klíčů, která má vliv na druhou službu. V důsledku toho se pracovní postupy pro služby SMB pro Protokol Kerberos a NFS pro Kerberos v některých oblastech liší.

Počáteční konfigurace sféry Kerberos

Sféra Kerberos NFS se konfiguruje, když se informace o sférách Kerberos vyplní na portálu Azure NetApp Files na stránce připojení služby Active Directory.

Snímek obrazovky s konfigurací sféry Kerberos

Název serveru Azure AD a IP adresa služby KDC se používají k připojení ke službám Azure AD KDC při počátečním vytvoření účtu počítače. Služba Azure NetApp Files využívá informace o existující doméně k vyplnění zbytku konfigurace sféry. Příklad:

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

Při konfiguraci sféry kerberos systému souborů NFS se do služby přidá položka místních hostitelů se službou KDC zadanou v konfiguraci. Při úpravě sféry se ve službě také upraví položka místních hostitelů.

Diagram konfigurace sféry Kerberos

Tato položka místního hostitele funguje jako "poslední možnost", pokud dojde k výpadku KDC v KDC zadaném v konfiguraci sféry a selhání dotazování redundantních řadičů domény prostřednictvím DNS.

Poznámka:

Pokud je potřeba snížit KDC v sférě Kerberos kvůli údržbě (například pro upgrady nebo vyřazení serveru z provozu), doporučujeme nakonfigurovat sféru tak, aby používala službu KDC, která neprochází údržbou, aby nedocházelo k výpadkům.

Počáteční vytvoření účtu počítače nebo hlavního názvu služby (SPN)

Pokud je na svazku Azure NetApp Files povolený protokol Kerberos, vytvoří se v doméně v zadané organizační jednotce v připojeních služby Active Directory účet počítače nebo objekt zabezpečení s názvem NFS-{SMB-server-name}. Názvy účtů počítačů se zkracují po 15 znachů.

Poznámka:

Při přidávání klientů s Linuxem s názvy hostitelů většími než 15 znaků do domény služby Active Directory se zkrátí hlavní názvy služby (SPN) účtu počítače Kerberos. Například linuxový klient s názvem MORE-THAN-FIFTEEN má název účtu počítače , který MORE-THAN-FIFT$se stane hlavním názvem MORE-THAN-FIFT$@CONTOSO.COMslužby . Když DNS vyhledá název hostitele klienta, najde delší název a pokusí se tento název použít v požadavku SPN ( MORE-THAN-FIFTEEN@CONTOSO.COM). Vzhledem k tomu, že hlavní název služby neexistuje, pokusí se klient použít další hlavní název služby (SPN) v tabulce klíčů v požadavku (obvykle název hostitele nebo hostitele). Hlavní názvy účtů počítače nativně pracují s protokolem Kerberos nfs služby Azure NetApp Files. V důsledku toho se ujistěte, že názvy hostitelů klienta linuxu používané pro kerberos NFS s Azure NetApp Files nepřekračují 15 znaků. Případně pokud chcete použít hlavní název služby hostitele nebo názvu hostitele, nakonfigurujte uživatele systému UNIX v protokolu LDAP s uživatelským jménem "hostitel". Tato konfigurace poskytuje mapování názvů krb-unix pro hlavní název služby( SPN).

V Azure NetApp Files se do služby přidají bloky klíčů Kerberos (nebo položky keytab) se službou NFS SPN (nfs/nfs-server-name.contoso.com@CONTOSO.COM). Vytvoří se více položek: jeden pro každý podporovaný typ šifrování. Ve službě Azure NetApp Files se pro kerberos NFS podporuje pouze typ šifrování AES-256.

Ve většině případů nebude znalost těchto kroků nutná pro každodenní úlohy správy, ale jsou užitečné při řešení potíží s případným selháním při pokusu o vytvoření svazku Kerberos NFS ve službě Azure NetApp Files.

Pracovní postup vytváření SPN kerberosu NFS

Následující diagram znázorňuje, jak se vytvoří hlavní název služby SYSTÉMU souborů NFS systému souborů NFS systému souborů NFS nebo duální svazek protokolu NFS s povoleným protokolem Kerberos. Ve většině případů nebude podrobné informace o podrobných krocích nutné pro každodenní úlohy správy, ale jsou užitečné při řešení potíží se všemi chybami při pokusu o vytvoření svazku SMB v Azure NetApp Files.

Diagram pracovního postupu vytváření SPN kerberos systému souborů NFS

Podrobný postup vytvoření hlavního názvu služby Kerberos NFS pomocí služby Azure NetApp Files najdete v seznamu.
  • Přihlašovací údaje správce předané službě KDC zadané v konfiguraci sféry pomocí uživatelského jména zadaného pro použití v připojení ke službě Active Directory – uživatel musí mít oprávnění k zobrazení nebo vytváření objektů v zadané organizační jednotky.
  • Servery DNS zadané v konfiguraci připojení Active Directory služby Azure NetApp Files se dotazují službou Azure NetApp Files pro záznamy služby Kerberos (SRV) v následujících formátech:
    • Dotaz URI pro _kerberos.CONTOSO.COM
    • Dotaz SRV pro _kerberos-master._udp CONTOSO.COM
    • Dotaz SRV pro _kerberos-master._tcp CONTOSO.COM

Poznámka:

K těmto dotazům dochází vícekrát ve stejném volání v různých částech procesu. Problémy s DNS můžou v těchto voláních způsobit zpomalení nebo úplné selhání. Zdá se, že tyto záznamy ve výchozím nastavení neexistují v nasazeních služby Active Directory a musí být vytvořeny ručně.

  • Pokud se dotaz nepodaří najít položku nebo pokud nalezené položky nelze kontaktovat nebo použít jako hlavní KDC, pak se jako poslední možnost pro připojení k KDC přes port 88 použije dotaz záznamu A s použitím názvu sféry nalezeného v konfiguraci sféry kerberos nfs.
  • Během konfigurace protokolu Kerberos systému souborů NFS se do místního souboru hostitelů přidá statická položka hostitele pro zadaný KDC jako záloha, pokud vyhledávání DNS selže.
  • Pokud je položka DNS uložená v mezipaměti pro sféru, použije se. Pokud ne, použije se položka místního souboru. Záznamy DNS uložené v mezipaměti jsou aktivní, pokud je pro záznam DNS nakonfigurovaný hodnota TTL (Time to Live). Položka místního souboru je nakonfigurovaná s 86 400 sekundou TTL (24 hodin). Konfigurace přepínače ns pro vyhledávání hostitelů ve službě Azure NetApp Files používá nejprve soubory a pak DNS. Po nalezení místní položky se neprovedou žádné další dotazy.
  • Účet počítače SMB vytvořený při vytvoření připojení ke službě Active Directory se použije jako přihlašovací údaje pro vazbu protokolu LDAP služby Active Directory pomocí SASL/GSS přes port 389 a vyhledá všechny existující položky požadovaného názvu hlavního názvu služby (SPN) nebo názvu účtu počítače. Pokud název hlavního názvu služby nebo účtu počítače již existuje, odešle se chyba. Pokud hlavní název služby (SPN) v dotazu LDAP neexistuje, pak se vytvoření účtu počítače provede v určené organizační jednotky s položkami pro následující atributy nastavené službou Azure NetApp Files:
    • cn (NFS-MACHINE)
    • sAMAccountName (NFS-MACHINE$)
    • objectClass (top, person, organizationalPerson, user, computer)
    • servicePrincipalName (hostitel/NFS-MACHINE, hostitel/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)
  • Heslo účtu počítače kerberos nfs je nastavené pro účet NFS-MACHINE přes port 464.
  • Bloky klíčů Kerberos (keytabs) pro hlavní název služby NFS se ukládají do služby Azure NetApp Files.
  • Ve službě Azure NetApp Files se vytvoří pravidlo mapování statických názvů, které zajistí, že se kořenový uživatel každého klienta Kerberos NFS mapuje na root při použití protokolu Kerberos.
  • Do interních systémů služby se přidá soubor krb5.conf s informacemi o sférách NFS.

Připojení kerberos systému souborů NFS

Když je svazek Azure NetApp Files připojený pomocí příchutí zabezpečení protokolu Kerberos přes systém souborů NFS, provede se následující pracovní postup. Podrobnější účet Kerberos najdete v tématu Synopsis kerberos (Network Authentication Service) (V5).

Diagram pracovního postupu připojení kerberos systému souborů NFS

Podrobný postup připojení svazku Kerberos NFS ke službě Azure NetApp Files najdete v seznamu.
  • Klient se pokusí připojit k cestě exportu systému souborů NFS v Azure NetApp Files a určí -opříchuť zabezpečení krb5 (nebo krb5i nebo krb5p ).
  • DNS se používá k formulovat požadavek na instanční objekt NFS do služby Azure NetApp Files prostřednictvím záznamu A/AAAA nebo PTR (v závislosti na tom, jak byl vydán příkaz mount).
  • Klient načte TGT z KDC prostřednictvím volání AS-REQ pomocí hlavního názvu klienta nalezeného v tabulce klíčů klienta.
  • Cesta k exportu je zaškrtnutá, aby se zajistila, že existuje v systému souborů.
  • Pravidlo zásad exportu je zaškrtnuté, aby se zajistilo, že přístup Kerberos k cestě exportu je povolený.<
  • Lístek služby NFS vyžaduje klient prostřednictvím volání AP-REQ z KDC. Azure NetApp Files zkontroluje platnou položku s platným typem šifrování pomocí TGT z klienta získaného z KDC.
  • Pokud je TGT platný, vydá se lístek služby.
  • Hlavní název služby klienta (například CLIENT$@CONTOSO.COM) se mapuje na kořenového uživatele prostřednictvím pravidla mapování názvů v Azure NetApp Files.
  • Kořenový uživatel se dotazuje v databázích názvových služeb (soubory a LDAP) na členství ve skupině nebo existenci.
  • Vazba protokolu LDAP pomocí účtu počítače serveru SMB se provádí, aby bylo možné vyhledat uživatele root ldap.
  • Vzhledem k tomu, že kořen ve službě Azure NetApp Files vždy existuje, nemělo by to způsobovat žádné problémy, ale dotazy LDAP na kořenové adresáře můžou selhat. Tato selhání je možné ignorovat.
  • Lístek služby NFS se vrátí klientovi a připojení proběhne úspěšně. Kořenový uživatel má kořenový přístup k připojení Kerberos prostřednictvím instančního objektu účtu počítače klienta (zobrazitelný příkazem klist -e z klienta).
  • Azure NetApp Files přidá položky do kontextové mezipaměti Kerberos pro klienta. Tyto položky se budou nacházet v mezipaměti po dobu životnosti lístku Kerberos nastaveného službou KDC a řízeny zásadami protokolu Kerberos.
  • NFSv4.1 pravidelně (každých 20 sekund) odesílá aktualizace lístku Kerberos jako "keepalives".

Přístup k připojení kerberos systému souborů NFS s hlavními objekty zabezpečení uživatele

Když je připojení Kerberos služby Azure NetApp Files nfs přístupné uživatelem (jiným než kořenovým uživatelem, který používá hlavní název služby účtu počítače), provede se následující pracovní postup.

Diagram přístupu k připojení kerberos systému souborů NFS s instančními objekty uživatele

Podrobný postup přístupu ke svazku Kerberos systému souborů NFS s jiným uživatelem nežroot se službou Azure NetApp Files najdete v seznamu.
  • Uživatel se přihlásí k KDC buď pomocí výměny uživatelského jména nebo hesla, nebo prostřednictvím souboru keytab, aby získal TGT prostřednictvím volání AS-REQ, které se použije ke shromažďování lístku služby ze svazku Azure NetApp Files.
  • Pravidlo zásad exportu je zaškrtnuté, aby se zajistilo, že přístup kerberosu k cestě exportu klientského počítače je povolený.
  • Azure NetApp Files kontroluje lístek služby NFS v mezipaměti. Pokud žádný neexistuje, pak se lístek služby NFS vyžádá prostřednictvím volání AP-REQ a služba zkontroluje platnou položku s platným typem šifrování pomocí lístku TGT od klienta získaného z KDC.
  • Pokud je TGT platný, vydá se lístek služby.
  • Hlavní název uživatele (UPN) uživatele se mapuje prostřednictvím implicitního mapování. Pokud je user1@CONTOSO.COMnapříklad hlavní název uživatele (UPN) , služba se dotazuje na uživatele se systémem UNIX s názvem user1. Vzhledem k tomu, že uživatel se systémem UNIX v místní databázi souborů v Azure NetApp Files neexistuje, používá se protokol LDAP.
  • Vazba protokolu LDAP pomocí účtu počítače serveru SMB se pokouší povolit vyhledávání ldap pro namapovaného uživatele. Dotaz DNS SRV se provádí pro záznamy DNS Kerberos (_kerberos a _kerberos-master). Pokud nelze použít žádné platné záznamy, konfigurace se vrátí do konfigurace sféry. Tyto dotazy SRV DNS služby KDC nejsou omezené na lokalitu.
  • Záznamy PROTOKOLU LDAP SRV se dotazují na platné servery LDAP. Jedná se o obor webu.
  • Pokud uživatel v ldapu neexistuje nebo ldap nemůže být dotazován (server je mimo provoz, vyhledávání DNS selže, dojde k selhání vazby, vyprší časový limit vyhledávání LDAP, uživatel neexistuje) pak mapování selže a přístup se odepře.
  • Pokud uživatel existuje, shromáždí se členství ve skupinách.
  • Mapování proběhne úspěšně a klientovi se vydá lístek služby NFS (v klist -e příkazech). Přístup je povolený na základě oprávnění k souborům v cestě exportu.

Role PROTOKOLU LDAP s Protokolem Kerberos ve službě Azure NetApp Files

Služba Azure NetApp Files spoléhá na protokol LDAP pro kerberos systému souborů NFS. Protokol Kerberos systému souborů NFS v Azure NetApp Files vyžaduje protokol Kerberos pro mapování názvů UNIX pro příchozí hlavní názvy uživatelů. Vzhledem k tomu, že Azure NetApp Files nepodporuje vytváření místních uživatelů systému UNIX, protokol LDAP je potřeba k provádění vyhledávání pro uživatele systému UNIX, když se požaduje mapování názvů.

  • Při vytvoření připojení Azure AD se název domény Active Directory použije k určení procesu vyhledávání serverů LDAP.
  • Pokud potřebujete server LDAP, _ldap.domain.com použije se pro vyhledávání SRV pro servery LDAP.
  • Po zjištění seznamu serverů se jako server LDAP pro připojení přes port 389 použije nejlepší dostupný server (na základě doby odezvy ping).
  • Vazba protokolu LDAP se pokouší použít účet počítače SMB prostřednictvím GSS/Kerberos.
  • Pokud není k dispozici žádné připojení uložené v mezipaměti nebo přihlašovací údaje Kerberos, vydá se nový požadavek na lístek Kerberos. Připojení uložená v mezipaměti pro názvové servery v Azure NetApp Files živě po dobu 60 sekund. Pokud je nečinnost delší než 60 sekund, vymaže se mezipaměť připojení.
  • DNS se používá k vyhledání příslušných řadičů KDCS protokolu Kerberos prostřednictvím záznamů SRV.
  • Pokud se pomocí dotazu DNS nenajde žádné řadiče výkonu, použije se KDC zadaný v souboru krb5.conf pro služby SMB.
    • Pokud je KDC nedostupný nebo nemůže zpracovat požadavek Kerberos, vazba protokolu LDAP selže. Vyhledávání názvů také selže. Přístup k připojení byl odepřen, protože neprobíhá žádné platné ověřování.
    • Pokud je vazba úspěšná, provede se dotaz LDAP pro uživatele a jeho přihlašovací údaje. Pokud doba hledání překročí 10 sekund, hledání selže.
  • Pokud vyhledávání najde uživatele, mapování proběhne úspěšně a přístup se udělí přes Kerberos (pokud je lístek platný nebo nevypršela jeho platnost).

IP adresy pro přístup pomocí protokolu Kerberos

Ověřování protokolem Kerberos ve výchozím nastavení využívá překlad názvu hostitele na IP adresu k formulování hlavního názvu služby (SPN) použitého k načtení lístku Kerberos. Pokud je například sdílená složka SMB přístupná pomocí cesty UNC (Universal Naming Convention), například \SMBVOLUME.CONTOSO.COM, vydá se požadavek DNS pro plně kvalifikovaný název domény SMBVOLUME.CONTOSO.COM a načte se IP adresa svazku Azure NetApp Files. Pokud neexistuje žádná položka DNS (nebo se tato položka liší od požadovaných položek, jako jsou aliasy nebo CNAMEs), nebude možné načíst správný hlavní název služby (SPN) a požadavek Kerberos selže. V důsledku toho může být přístup ke svazku zakázán, pokud je zakázaná metoda náhradního ověřování (například New Technology LAN Manager).

Položky DNS ve službě Azure NetApp Files se vytvářejí automaticky pomocí dynamického DNS a jsou formulovány pomocí názvu serveru SMB. Pro všechny varianty a aliasy definovaného názvu by se měl vytvořit ruční záznam DNS CNAME a odkazovat na dynamickou položku DNS. Další informace najdete v tématu Principy DNS ve službě Azure NetApp Files.

Protokol Kerberos NFSv4.1 funguje podobným způsobem pro načítání hlavního názvu služby(SPN), kde jsou vyhledávání DNS nedílnou součástí procesu ověřování a lze je také použít ke zjišťování sféry Kerberos.

Pokud se IP adresa (místo názvu hostitele) používá v žádosti o přístup ke svazku Azure NetApp Files, pak požadavek Kerberos funguje odlišně v závislosti na používaném protokolu.

Chování protokolu Kerberos protokolu SMB s IP adresami a názvy DNS

Při použití protokolu SMB se požadavek na cestu UNC pomocí IP adresy (například \\x.x.x.x) ve výchozím nastavení pokusí k ověřování použít protokol NTLM. V prostředích, kde je protokol NTLM zakázán z bezpečnostních důvodů, požadavek SMB používající IP adresu ve výchozím nastavení nemůže k ověřování používat Protokol Kerberos nebo NTLM. V důsledku toho se přístup ke svazku Azure NetApp Files odepře. V novějších verzích Windows (počínaje Windows 10 verze 1507 a Windows Serverem 2016) je možné klienty Kerberos nakonfigurovat tak, aby podporovaly názvy hostitelů IPv4 a IPv6 v hlavních nástavcích pro komunikaci smb, aby tento problém vyřešili.

Chování Kerberos NFSv4.1 s IP adresami a názvy DNS

Při použití NFSv4.1 požadavek na připojení k IP adrese pomocí jedné z sec=[krb5/krb5i/krb5p] možností používá zpětné vyhledávání DNS prostřednictvím PTR k překladu IP adresy na název hostitele. Tento název hostitele se pak použije k formulování hlavního názvu služby pro načtení lístku Kerberos. Pokud používáte NFSv4.1 s Protokolem Kerberos, měli byste mít pro svazek Azure NetApp Files A/AAAA a PTR přístup k názvu hostitele i IP adrese pro připojení. Azure NetApp Files vytvoří dynamický záznam DNS A/AAAA. Pokud pro tuto podsíť existuje reverzní zóna DNS, vytvoří se automaticky také záznam PTR. Pro odchylky od standardních konvencí názvu hostitele služby Azure NetApp Files použijte záznamy CNAME pro aliasy DNS.

Další informace najdete v tématu Principy DNS ve službě Azure NetApp Files.