Uitgebreide informatie over passthrough-verificatie van Azure Active Directory

Dit artikel bevat een gedetailleerde beschrijving van hoe passthrough-verificatie van Azure Active Directory (Azure AD) werkt. Het richt zich op de beveiligingsaspecten van de functie. Dit artikel is bedoeld voor beveiligings- en IT-beheerders, chief compliance- en security officers en andere IT-professionals die verantwoordelijk zijn voor IT-beveiliging en naleving bij organisaties of ondernemingen van elke omvang.

De behandelde onderwerpen omvatten:

• Gedetailleerde technische informatie over het installeren en registreren van verificatieagents.
• Gedetailleerde technische informatie over wachtwoordversleuteling tijdens het aanmelden van gebruikers.
• De beveiliging van de kanalen tussen on-premises verificatieagents en Azure AD.
• Gedetailleerde technische informatie over het operationeel beveiligen van de verificatieagents.

Beveiligingsmogelijkheden voor passthrough-verificatiesleutels

Passthrough-verificatie heeft de volgende belangrijke beveiligingsmogelijkheden:

• Het is gebouwd op een beveiligde architectuur met meerdere tenants die isolatie biedt van aanmeldingsaanvragen tussen tenants.
• On-premises wachtwoorden worden in geen enkele vorm in de cloud opgeslagen.
• On-premises verificatieagents die luisteren naar en reageren op aanvragen voor wachtwoordvalidatie, maken alleen uitgaande verbindingen vanuit uw netwerk. Het is niet vereist om deze verificatieagents te installeren in een perimeternetwerk (ook wel DMZ, gedemilitariseerde zone en gescreend subnet genoemd). Als best practice behandelt u alle servers waarop verificatieagents worden uitgevoerd als laag 0-systemen (zie referentie).
• Alleen standaardpoorten (poort 80 en poort 443) worden gebruikt voor uitgaande communicatie van de verificatieagents naar Azure AD. U hoeft geen binnenkomende poorten op uw firewall te openen.
  • Poort 443 wordt gebruikt voor alle geverifieerde uitgaande communicatie.
  • Poort 80 wordt alleen gebruikt voor het downloaden van certificaatintrekkingslijsten (CRL's) om ervoor te zorgen dat geen van de certificaten die door deze functie worden gebruikt, zijn ingetrokken.
  • Zie de quickstart azure Active Directory passthrough-verificatie voor de volledige lijst met netwerkvereisten.
• Wachtwoorden die gebruikers opgeven tijdens het aanmelden, worden versleuteld in de cloud voordat de on-premises verificatieagenten ze accepteren voor validatie op basis van Windows Server Active Directory (Windows Server AD).
• Het HTTPS-kanaal tussen Azure AD en de on-premises verificatieagent wordt beveiligd met behulp van wederzijdse verificatie.
• Passthrough-verificatie beveiligt uw gebruikersaccounts door naadloos te werken met Azure AD beleid voor voorwaardelijke toegang, waaronder meervoudige verificatie (MFA), het blokkeren van verouderde verificatie en door beveiligingsaanvallen op wachtwoorden uit te filteren.

Onderdelen die betrokken zijn bij passthrough-verificatie

Zie het Vertrouwenscentrum voor algemene informatie over operationele, service- en gegevensbeveiliging voor Azure AD. De volgende onderdelen zijn betrokken wanneer u passthrough-verificatie gebruikt voor gebruikersaanmelding:

• Azure AD Security Token Service (Azure AD STS): een staatloze STS die aanmeldingsaanvragen verwerkt en waar nodig beveiligingstokens aan gebruikersbrowsers, clients of services uitgeeft.
• Azure Service Bus: Biedt communicatie via de cloud met Enterprise-berichten en stuurt communicatie door waarmee u verbinding kunt maken tussen on-premises oplossingen en de cloud.
• Azure AD Connect-verificatieagent: Een on-premises onderdeel dat luistert naar en reageert op aanvragen voor wachtwoordvalidatie.
• Azure SQL Database: bevat informatie over de verificatieagents van uw tenant, inclusief hun metagegevens en versleutelingssleutels.
• Windows Server AD: On-premises Active Directory, waar gebruikersaccounts en hun wachtwoorden worden opgeslagen.

Installatie en registratie van verificatieagents

Verificatieagents worden geïnstalleerd en geregistreerd bij Azure AD wanneer u een van de volgende acties uitvoert:

• PassThrough-verificatie inschakelen via Azure AD Connect
• Meer verificatieagents toevoegen om de hoge beschikbaarheid van aanmeldingsaanvragen te garanderen

Het operationeel maken van een verificatieagent omvat drie hoofdfasen:

• Installatie
• Registratie
• Initialisatie

In de volgende secties worden deze fasen in detail besproken.

Installatie van verificatieagent

Alleen een Hybrid Identity Administrator-account kan een verificatieagent installeren (met behulp van Azure AD Connect of een zelfstandig exemplaar) op een on-premises server.

Installatie voegt twee nieuwe vermeldingen toe aan de lijst in Configuratiescherm>Programma's>en onderdelen:

• De verificatieagenttoepassing zelf. Deze toepassing wordt uitgevoerd met NetworkService-bevoegdheden.
• De Updater-toepassing die wordt gebruikt om de verificatieagent automatisch bij te werken. Deze toepassing wordt uitgevoerd met LocalSystem-bevoegdheden.

Belangrijk

Vanuit het oogpunt van beveiliging moeten beheerders de server waarop de passthrough-verificatieagent wordt uitgevoerd, behandelen alsof het een domeincontroller is. De agentservers voor passthrough-verificatie moeten worden beveiligd, zoals beschreven in Domeincontrollers beveiligen tegen aanvallen.

Registratie van verificatieagent

Nadat u de verificatieagent hebt geïnstalleerd, wordt deze geregistreerd bij Azure AD. Azure AD wijst elke verificatieagent een uniek, digitaal identiteitscertificaat toe dat kan worden gebruikt voor beveiligde communicatie met Azure AD.

De registratieprocedure verbindt de verificatieagent ook met uw tenant. Vervolgens weet Azure AD dat deze specifieke verificatieagent de enige is die gemachtigd is om aanvragen voor wachtwoordvalidatie voor uw tenant af te handelen. Deze procedure wordt herhaald voor elke nieuwe verificatieagent die u registreert.

De verificatieagents gebruiken de volgende stappen om zichzelf te registreren bij Azure AD:

1. Azure AD vraagt eerst aan dat een beheerder van een hybride identiteit zich aanmeldt bij Azure AD met zijn referenties. Tijdens het aanmelden verkrijgt de verificatieagent een toegangstoken dat deze namens de gebruiker kan gebruiken.
2. De verificatieagent genereert vervolgens een sleutelpaar: een openbare sleutel en een persoonlijke sleutel.
   • Het sleutelpaar wordt gegenereerd via standaard RSA 2048-bits versleuteling.
   • De persoonlijke sleutel blijft op de on-premises server waar de verificatieagent zich bevindt.
3. De verificatieagent doet een registratieaanvraag voor Azure AD via HTTPS, waarbij de volgende onderdelen in de aanvraag zijn opgenomen:
   • Het toegangstoken dat de agent heeft verkregen.
   • De openbare sleutel die is gegenereerd.
   • Een aanvraag voor certificaatondertekening (CSR of certificaataanvraag). Deze aanvraag is van toepassing op een digitaal identiteitscertificaat, met Azure AD als certificeringsinstantie (CA).
4. Azure AD valideert het toegangstoken in de registratieaanvraag en controleert of de aanvraag afkomstig is van een hybride identiteitsbeheerder.
5. Azure AD vervolgens een digitaal identiteitscertificaat ondertekent en terugstuurt naar de verificatieagent.

   • De basis-CA in Azure AD wordt gebruikt om het certificaat te ondertekenen.

     Notitie

     Deze CA bevindt zich niet in het archief met vertrouwde basiscertificeringsinstanties van Windows.

   • De CA wordt alleen gebruikt door de functie passthrough-verificatie. De CA wordt alleen gebruikt om CDR's te ondertekenen tijdens de registratie van de verificatieagent.

   • Geen andere Azure AD-service maakt gebruik van deze CA.

   • Het onderwerp van het certificaat (ook wel Distinguished Name of DN genoemd) is ingesteld op uw tenant-id. Deze DN is een GUID die uw tenant uniek identificeert. Deze DN beperkt het certificaat om alleen met uw tenant te worden gebruikt.

6. Azure AD slaat de openbare sleutel van de verificatieagent op in een database in Azure SQL Database. Alleen Azure AD heeft toegang tot de database.
7. Het uitgegeven certificaat wordt opgeslagen op de on-premises server in het Windows-certificaatarchief (met name in CERT_SYSTEM_STORE_LOCAL_MACHINE). Het certificaat wordt gebruikt door zowel de verificatieagent als de Updater-toepassing.

Initialisatie van verificatieagent

Wanneer de verificatieagent wordt gestart, voor de eerste keer na registratie of na het opnieuw opstarten van een server, heeft deze een manier nodig om veilig te communiceren met de Azure AD-service, zodat deze aanvragen voor wachtwoordvalidatie kan accepteren.

Verificatieagents worden als volgt geïnitialiseerd:

1. De verificatieagent maakt een uitgaande bootstrap-aanvraag naar Azure AD.

   Deze aanvraag wordt gedaan via poort 443 en verloopt via een wederzijds geverifieerd HTTPS-kanaal. De aanvraag maakt gebruik van hetzelfde certificaat dat is uitgegeven tijdens de registratie van de verificatieagent.

2. Azure AD reageert op de aanvraag door een toegangssleutel op te geven voor een Service Bus-wachtrij die uniek is voor uw tenant en die wordt geïdentificeerd door uw tenant-id.

3. De verificatieagent maakt een permanente uitgaande HTTPS-verbinding (via poort 443) naar de wachtrij.

De verificatieagent is nu klaar om aanvragen voor wachtwoordvalidatie op te halen en af te handelen.

Als u meerdere verificatieagents hebt geregistreerd op uw tenant, zorgt de initialisatieprocedure ervoor dat elke agent verbinding maakt met dezelfde Service Bus-wachtrij.

Hoe passthrough-verificatie aanmeldingsaanvragen verwerkt

In het volgende diagram ziet u hoe passthrough-verificatie aanmeldingsaanvragen van gebruikers verwerkt:

Hoe passthrough-verificatie een aanmeldingsaanvraag van een gebruiker verwerkt:

1. Een gebruiker probeert toegang te krijgen tot een toepassing, bijvoorbeeld Outlook Web App.

2. Als de gebruiker nog niet is aangemeld, wordt de browser door de toepassing omgeleid naar de Azure AD aanmeldingspagina.

3. De Azure AD STS-service antwoordt terug met de pagina Gebruikersaanmelding.

4. De gebruiker voert zijn gebruikersnaam in op de aanmeldingspagina van de gebruiker en selecteert vervolgens de knop Volgende .

5. De gebruiker voert het wachtwoord in op de aanmeldingspagina van de gebruiker en selecteert vervolgens de knop Aanmelden .

6. De gebruikersnaam en het wachtwoord worden verzonden naar Azure AD STS in een HTTPS POST-aanvraag.

7. Azure AD STS haalt openbare sleutels op voor alle verificatieagents die zijn geregistreerd in uw tenant uit Azure SQL Database en versleutelt het wachtwoord met behulp van de sleutels.

   Het produceert één versleutelde wachtwoordwaarde voor elke verificatieagent die is geregistreerd in uw tenant.

8. Azure AD STS de aanvraag voor wachtwoordvalidatie, die bestaat uit de gebruikersnaam en de versleutelde wachtwoordwaarden, in de Service Bus-wachtrij die specifiek is voor uw tenant.

9. Omdat de geïnitialiseerde verificatieagents permanent zijn verbonden met de Service Bus-wachtrij, haalt een van de beschikbare verificatieagents de aanvraag voor wachtwoordvalidatie op.

10. De verificatieagent gebruikt een id om de versleutelde wachtwoordwaarde te vinden die specifiek is voor de openbare sleutel. De openbare sleutel wordt ontsleuteld met behulp van de persoonlijke sleutel.

11. De verificatieagent probeert de gebruikersnaam en het wachtwoord te valideren voor Windows Server AD met behulp van de Win32-aanmeldingsgebruikers-API met de dwLogonType parameter ingesteld op LOGON32_LOGON_NETWORK.

    • Deze API is dezelfde API die door Active Directory Federation Services (AD FS) wordt gebruikt om gebruikers aan te melden in een federatief aanmeldingsscenario.
    • Deze API is afhankelijk van het standaardoplossingsproces in Windows Server om de domeincontroller te vinden.

12. De verificatieagent ontvangt het resultaat van Windows Server AD, zoals geslaagd, gebruikersnaam of wachtwoord is onjuist of wachtwoord is verlopen.

    Notitie

    Als de verificatieagent mislukt tijdens het aanmeldingsproces, wordt de volledige aanmeldingsaanvraag verwijderd. Aanmeldingsaanvragen worden niet doorgegeven van de ene on-premises verificatieagent naar een andere on-premises verificatieagent. Deze agents communiceren alleen met de cloud en niet met elkaar.

13. De verificatieagent stuurt het resultaat terug naar Azure AD STS via een uitgaand, wederzijds geverifieerd HTTPS-kanaal via poort 443. Wederzijdse verificatie maakt gebruik van het certificaat dat tijdens de registratie aan de verificatieagent is uitgegeven.

14. Azure AD STS controleert of dit resultaat overeenkomt met de specifieke aanmeldingsaanvraag voor uw tenant.

15. Azure AD STS gaat door met de aanmeldingsprocedure zoals geconfigureerd. Als de wachtwoordvalidatie bijvoorbeeld is geslaagd, kan de gebruiker worden gevraagd om MFA of wordt teruggeleid naar de toepassing.

Operationele beveiliging van verificatieagent

Om ervoor te zorgen dat passthrough-verificatie operationeel veilig blijft, vernieuwt Azure AD periodiek verificatieagentcertificaten. Azure AD activeert de verlengingen. De verlengingen worden niet beheerd door de verificatieagents zelf.

De vertrouwensrelatie van een verificatieagent vernieuwen met Azure AD:

1. De verificatieagent pingt Azure AD om de paar uur om te controleren of het tijd is om het certificaat te vernieuwen. Het certificaat wordt 30 dagen voordat het verloopt vernieuwd.

   Deze controle wordt uitgevoerd via een wederzijds geverifieerd HTTPS-kanaal en gebruikt hetzelfde certificaat dat is uitgegeven tijdens de registratie.

2. Als de service aangeeft dat het tijd is om te vernieuwen, genereert de verificatieagent een nieuw sleutelpaar: een openbare sleutel en een persoonlijke sleutel.

   • Deze sleutels worden gegenereerd via standaard RSA 2048-bits versleuteling.
   • De persoonlijke sleutel verlaat nooit de on-premises server.

3. De verificatieagent maakt vervolgens een aanvraag voor certificaatvernieuwing naar Azure AD via HTTPS. De volgende onderdelen zijn opgenomen in de aanvraag:

   • Het bestaande certificaat dat wordt opgehaald uit de CERT_SYSTEM_STORE_LOCAL_MACHINE locatie in het Windows-certificaatarchief. Er is geen globale beheerder betrokken bij deze procedure, dus er is geen toegangstoken vereist voor een globale beheerder.
   • De openbare sleutel die is gegenereerd in stap 2.
   • Een CSR. Deze aanvraag is van toepassing op een nieuw digitaal identiteitscertificaat, met Azure AD als CA.

4. Azure AD valideert het bestaande certificaat in de aanvraag voor certificaatverlenging. Vervolgens wordt gecontroleerd of de aanvraag afkomstig is van een verificatieagent die is geregistreerd in uw tenant.

5. Als het bestaande certificaat nog geldig is, Azure AD een nieuw digitaal identiteitscertificaat ondertekent en het nieuwe certificaat teruggeeft aan de verificatieagent.

6. Als het bestaande certificaat is verlopen, verwijdert Azure AD de verificatieagent uit de lijst met geregistreerde verificatieagents van uw tenant. Vervolgens moet een globale beheerder of beheerder van een hybride identiteit handmatig een nieuwe verificatieagent installeren en registreren.

   • Gebruik de Azure AD-basis-CA om het certificaat te ondertekenen.
   • Stel de DN van het certificaat in op uw tenant-id, een GUID die uw tenant uniek identificeert. De DN beperkt het certificaat tot alleen uw tenant.

7. Azure AD slaat de nieuwe openbare sleutel van de verificatieagent op in een database in Azure SQL Database waartoe alleen deze toegang heeft. Ook wordt de oude openbare sleutel die is gekoppeld aan de verificatieagent ongeldig gemaakt.

8. Het nieuwe certificaat (uitgegeven in stap 5) wordt vervolgens opgeslagen op de server in het Windows-certificaatarchief (met name op de CERT_SYSTEM_STORE_CURRENT_USER locatie).

   Omdat de procedure voor het vernieuwen van de vertrouwensrelatie niet-interactief plaatsvindt (zonder de aanwezigheid van de globale beheerder of hybride identiteitsbeheerder), heeft de verificatieagent geen toegang meer om het bestaande certificaat bij te werken op de CERT_SYSTEM_STORE_LOCAL_MACHINE locatie.

   Notitie

   Met deze procedure wordt het certificaat zelf niet van de locatie CERT_SYSTEM_STORE_LOCAL_MACHINE verwijderd.

9. Vanaf dit punt wordt het nieuwe certificaat gebruikt voor verificatie. Elke volgende verlenging van het certificaat vervangt het certificaat op de locatie CERT_SYSTEM_STORE_LOCAL_MACHINE.

Verificatieagent automatisch bijwerken

De toepassing Updater werkt de verificatieagent automatisch bij wanneer een nieuwe versie (met oplossingen voor fouten of prestatieverbeteringen) wordt uitgebracht. De Updater-toepassing verwerkt geen aanvragen voor wachtwoordvalidatie voor uw tenant.

Azure AD host de nieuwe versie van de software als een ondertekend Windows Installer-pakket (MSI). De MSI wordt ondertekend met behulp van Microsoft Authenticode met SHA-256 als samenvattingsalgoritme.

Een verificatieagent automatisch bijwerken:

1. De Updater-toepassing pingt elk uur Azure AD om te controleren of er een nieuwe versie van de verificatieagent beschikbaar is.

   Deze controle wordt uitgevoerd via een wederzijds geverifieerd HTTPS-kanaal en gebruikt hetzelfde certificaat dat is uitgegeven tijdens de registratie. De verificatieagent en de Updater delen het certificaat dat is opgeslagen op de server.

2. Als er een nieuwe versie beschikbaar is, retourneert Azure AD de ondertekende MSI terug aan de Updater.

3. De Updater controleert of de MSI is ondertekend door Microsoft.

4. De Updater voert de MSI uit. In dit proces doet de Updater-toepassing het volgende:

   Notitie

   De Updater wordt uitgevoerd met lokale systeembevoegdheden.

   1. Stopt de verificatieagentservice.
   2. Installeert de nieuwe versie van de verificatieagent op de server.
   3. Start de verificatieagentservice opnieuw.

Notitie

Als u meerdere verificatieagents hebt geregistreerd op uw tenant, worden de certificaten van Azure AD niet tegelijkertijd vernieuwd of bijgewerkt. In plaats daarvan vernieuwt Azure AD de certificaten één voor één om hoge beschikbaarheid voor aanmeldingsaanvragen te garanderen.

Volgende stappen

• Huidige beperkingen: ontdek welke scenario's worden ondersteund.
• Quickstart: Aan de slag met Azure AD passthrough-verificatie.
• Migreren van AD FS naar passthrough-verificatie: bekijk deze gedetailleerde handleiding die u helpt bij het migreren van AD FS of andere federatietechnologieën naar passthrough-verificatie.
• Smart Lockout: De Smart Lockout-mogelijkheid op uw tenant configureren om gebruikersaccounts te beveiligen.
• Hoe het werkt: leer de basisbeginselen van hoe Azure AD passthrough-verificatie werkt.
• Veelgestelde vragen: vind antwoorden op veelgestelde vragen.
• Problemen oplossen: informatie over het oplossen van veelvoorkomende problemen met passthrough-verificatie.
• Azure AD naadloze eenmalige aanmelding: meer informatie over de aanvullende Azure AD functie Naadloze eenmalige aanmelding.