Microsoft Cloud PKI-implementatie voor Microsoft Intune

In dit artikel worden de implementatiemodellen beschreven die worden ondersteund door Microsoft Intune en de Microsoft Cloud PKI-service.

U hebt twee implementatieopties:

• Basis-CA voor PKI van Microsoft Cloud: Implementeer PKI voor Microsoft Cloud met behulp van hoofdcertificeringsinstanties en ICT-aanvragen in de cloud.

• Bring your own certification authority (BYOCA): implementeer Microsoft Cloud PKI met behulp van uw eigen persoonlijke CA.

Met de Microsoft Cloud PKI-hoofdcertificeringsinstantie kunt u een of meer PKI's maken binnen één Intune tenant. Als u Cloud PKI op deze manier implementeert, wordt een hiërarchie met twee lagen gemaakt, zodat u meerdere uitgevende certificeringsinstanties onder de basiscertificeringsinstantie kunt hebben. Deze certificeringsinstanties zijn niet openbaar. In plaats daarvan maakt u zowel de basiscertificeringsinstantie als de uitgevende certificeringsinstanties in de cloud, privé voor de Intune-tenant. De verlenende certificeringsinstantie geeft certificaten uit aan apparaten beheerd door Intune met behulp van het SCEP-certificaatprofiel voor apparaatconfiguratie.

U kunt ook uw eigen certificeringsinstantie (BYOCA) meenemen. Met deze methode implementeert u Microsoft Cloud PKI met behulp van uw eigen persoonlijke CA. Voor deze optie moet u een uitgevende certificeringsinstantie in de cloud maken die privé is voor de Intune-tenant. De verlenende certificeringsinstantie is verankerd aan een particuliere certificeringsinstantie, zoals ADCS (Active Directory Certificate Services). Wanneer u een Cloud PKI BYOCA-uitgevende CA maakt, wordt er ook een Certificate Signing Request (CSR) gemaakt in Intune. Uw persoonlijke CA is vereist om de CSR te ondertekenen.

Voordat u begint

Het is belangrijk om de vertrouwensketens voor certificaten te controleren en te begrijpen voordat u met de implementatie begint. Zie de basisprincipes van PKI voor Microsoft Cloud voor meer PKI-concepten en -principes.

Relying parties identificeren

Uw relying party's identificeren. De relying party is een gebruiker of systeem dat de certificaten verbruikt die door een PKI zijn gegenereerd. Voorbeelden van relying parties zijn:

• Een Wi-Fi toegangspunt met RADIUS-verificatie op basis van certificaten.
• Een VPN-server die een externe gebruiker verifieert.
• Een gebruiker bezoekt een met TLS/SSL beveiligde website in een webbrowser.

Locatie voor vertrouwensanker bepalen

Bepaal de locatie van het hoofdvertrouwensanker. Een vertrouwensanker is een CA-certificaat, of de openbare sleutel van een CA, dat door een relying party wordt gebruikt als het beginpunt voor certificaatvertrouwen of padvalidatie. Een relying party kan beschikken over een of meer trust anchors die uit meer dan één bron zijn afgeleid. Een vertrouwensanker kan de openbare sleutel van de basiscertificeringsinstantie zijn of de openbare sleutel van de certificeringsinstantie die een certificaat van een eindentiteit verleent aan de relying party.

Zorg voor de vertrouwensketen

Wanneer u certificaten gebruikt om verificatie op basis van certificaten uit te voeren, moet u ervoor zorgen dat beide relying parties beschikken over de vertrouwensketen van het CA-certificaat (die de openbare sleutels en de basiscertificeringsinstantie bevat) van alle certificaten die betrokken zijn bij een gesprek op basis van TLS/SSL. In deze context zijn de vertrouwende partijen:

• De apparaten beheerd door Intune.
• De verificatieservices die worden gebruikt door Wi-Fi, VPN of webservices.

Als het uitgevende CA-certificaat ontbreekt, kan een relying party dit aanvragen via de eigenschap Authority Information Access (AIA) in het certificaat met behulp van de systeemeigen certificaatketenengine van het besturingssysteem.

Opmerking

Wanneer u verbinding maakt met een relying party, zoals een Wi-Fi toegangspunt of VPN-server, wordt er eerst een TLS/SSL-verbinding tot stand gebracht door het beheerde Intune apparaat wanneer wordt geprobeerd verbinding te maken. Microsoft Cloud PKI biedt deze TLS/SSL-certificaten niet. U moet deze certificaten verkrijgen via een andere PKI- of CA-service. Daarom moet u bij het maken van een Wi-Fi- of VPN-profiel ook een vertrouwd certificaatprofiel maken en dit toewijzen aan beheerde apparaten om de TLS/SSL-verbinding te vertrouwen. Het vertrouwde certificaatprofiel moet de openbare sleutels bevatten voor de basiscertificeringsinstanties en certificeringsinstanties die verantwoordelijk zijn voor de uitgifte van het TLS/SSL-certificaat.

Opties voor implementatie

In deze sectie worden de Microsoft Intune ondersteunde implementatieopties voor Microsoft Cloud PKI beschreven.

Er zijn methoden voor het implementeren van CA-certificaten voor relying party's die niet worden beheerd door Intune. Relying party's, zoals radiusservers, Wi-Fi access points, VPN-servers en webapp-servers die verificatie op basis van certificaten ondersteunen.

Als de relying party lid is van een Active Directory-domein, gebruikt u groepsbeleid om CA-certificaten te implementeren. Zie voor meer informatie:

• Certificaten distribueren naar clientcomputers via groepsbeleid
• Een Windows-apparaat automatisch inschrijven met behulp van groepsbeleid

Als de relying party geen lid is van het Active Directory-domein, zorg er dan voor dat de vertrouwensketen van het CA-certificaat voor de Microsoft Cloud PKI-basis en de verlenende certificeringsinstantie is geïnstalleerd in het beveiligingsarchief van de relying party. Welk beveiligingsarchief geschikt is, is afhankelijk van het besturingssysteemplatform en de hosttoepassing die de service levert.

Houd ook rekening met de relying party softwareconfiguratie die nodig is om andere certificeringsinstanties te ondersteunen.

Optie 1: PKI-hoofd-CA van Microsoft Cloud

Tijdens de implementatie van een Cloud PKI-hoofdcertificeringsinstantie moet het Cloud PKI-basiscertificaat worden geïmplementeerd voor alle relying party's. Als een uitgevend CA-certificaat niet aanwezig is op een relying party, kan de relying party dit automatisch ophalen en installeren door certificaatdetectie te initiëren. Dit proces, dat bekend staat als de certificate chaining engine (CCE), is platformspecifiek en wordt gebruikt om ontbrekende bovenliggende certificaten op te halen. De URL van het uitgevende CA-certificaat bevindt zich in de AIA-eigenschap van een leaf-certificaat (het certificaat dat aan het apparaat is verleend met behulp van een Cloud PKI-uitgevende CA). Een relying party kan de AIA-eigenschap gebruiken om bovenliggende CA-certificaten op te halen. Het proces is vergelijkbaar met het downloaden van CRL's.

Opmerking

Android OS vereist dat servers een volledige certificaatketen retourneren en voert geen certificaatdetectie uit volgens AIA-paden. Raadpleeg de Android SSL-beveiligingsdocumentatie voor meer informatie over vereisten voor certificaatketens op Android. Zorg ervoor dat u de volledige certificaatketen implementeert op door Android beheerde apparaten en relying party's.

Intune beheerde apparaten, ongeacht het besturingssysteemplatform, is de volgende vertrouwensketen van CA-certificaten vereist.

CA-certificaattype	Vertrouwensketen voor CA-certificaat	Implementatiemethode
Cloud PKI CA-certificaat	Certificaat van basiscertificeringsinstantie vereist, verlening van certificeringsinstantie optioneel maar aanbevolen	Intune vertrouwd certificaatconfiguratieprofiel
Privé CA-certificaat	Root CA-certificaat vereist, afgifte van CA-certificaat is optioneel maar aanbevolen	Intune vertrouwd certificaatconfiguratieprofiel

Relying parties vereisen de volgende vertrouwensketen voor CA-certificaten.

CA-certificaattype	Vertrouwensketen voor CA-certificaat	Implementatiemethode
Cloud PKI CA-certificaat	Certificaat van basiscertificeringsinstantie vereist, verlening van certificeringsinstantie optioneel maar aanbevolen	Als de server of service van de relying party een lidserver in het Active Directory-domein (AD) is, gebruikt u groepsbeleid om CA-certificaten te implementeren. Als deze niet in het AD-domein valt, is mogelijk een handmatige installatiemethode vereist.
Privé CA-certificaat	Basiscertificaat van certificeringsinstantie vereist, verlening van certificaat certificeringsinstantie optioneel maar aanbevolen	Als de server of service van de relying party een lidserver in het Active Directory-domein (AD) is, gebruikt u groepsbeleid om CA-certificaten te implementeren. Als deze niet in het AD-domein valt, is mogelijk een handmatige installatiemethode vereist.

In het volgende diagram ziet u certificaten in actie voor zowel client- als relying party's.

In het volgende diagram ziet u de respectieve vertrouwensketens voor CA-certificaten die moeten worden geïmplementeerd op zowel beheerde apparaten als relying party's. De CA-vertrouwensketens zorgen ervoor dat PKI-cloudcertificaten die zijn uitgegeven aan apparaten beheerd door Intune, worden vertrouwd en kunnen worden gebruikt voor verificatie bij relying party's.

Optie 2: Neem uw eigen CA (BYOCA) mee

Tijdens een Bring Your Own-CA-implementatie heeft het Intune beheerde apparaat de volgende CA-certificaten nodig:

• De private CA-vertrouwensketen, met inbegrip van de root-certificaten en de certificaten die CA's uitgeven, van de CA die verantwoordelijk is voor de ondertekening van de BYOCA CSR.
• Het CA-certificaat dat BYOCA uitgeeft.

Alle relying parties moeten al beschikken over de keten van het persoonlijke CA-certificaat.

Intune beheerde apparaten, ongeacht het besturingssysteemplatform, is de volgende vertrouwensketen van CA-certificaten vereist.

CA-certificaattype	Vertrouwensketen voor CA-certificaat	Implementatiemethode
Cloud PKI CA-certificaat	Verlening van certificeringsinstantie is optioneel maar wordt aanbevolen	Intune vertrouwd certificaatconfiguratieprofiel
Privé CA-certificaat	Certificaat van basiscertificeringsinstantie vereist, verlening van certificeringsinstantie optioneel maar aanbevolen	Intune vertrouwd certificaatconfiguratieprofiel

De relying party moet al over de keten van het persoonlijke CA-certificaat beschikken. Het certificaat dat de CA uitgeeft van BYOCA moet echter ook worden geïmplementeerd voor relying party's. Als de relying party een lidserver in het Active Directory-domein is, gebruikt u GPO als implementatiemethode.

Opmerking

Als het door Cloud PKI BYOCA uitgevende CA-certificaat niet is geïmplementeerd op het platform van de relying party, kan de AIA-eigenschap (URL) van het door Cloud PKI uitgegeven SCEP-certificaat (eindentiteit/leaf-certificaat) worden gebruikt door de CCE van de relying party om het Cloud PKI BYOCA uitgevende CA-certificaat (openbare sleutel) aan te vragen en te installeren in zijn vertrouwensarchief. Dit gedrag is echter niet gegarandeerd en afhankelijk van elke OS/Platform-implementatie van de CCE. Het is raadzaam om het door BYOCA uitgevende CA-certificaat te implementeren op het beheerde apparaat en de relying party.

Relying parties vertrouwen het door Cloud PKI BYOCA uitgegeven SCEP-certificaat aan het beheerde apparaat, omdat het is gekoppeld aan de particuliere CA-vertrouwensketen die al aanwezig is op de relying party.

In het volgende diagram ziet u hoe de respectieve vertrouwensketens voor CA-certificaten worden geïmplementeerd op door Intune beheerde apparaten.

* beheerd door Intune. In dit diagram verwijst privé naar de Active Directory-certificaatservice of een niet-Microsoft-service.

Samenvatting

Cloud PKI-hoofd- en uitgevende certificeringsinstanties, en BYOCA-uitgevende certificeringsinstanties die zijn verankerd aan een privé-certificeringsinstantie, kunnen in dezelfde tenant aanwezig zijn, omdat Cloud PKI beide implementatiemodellen tegelijkertijd kan ondersteunen.

Voordat u een implementatie start en certificaten uitgeeft, moet u de locatie van het basisvertrouwensanker bepalen. Dit kan zich in de cloud-PKI-hoofdmap of de persoonlijke hoofd-CA bevinden. De locatie bepaalt de certificaatvertrouwensketen die vereist is voor zowel door Intune beheerde apparaten als relying party's.

• Cloud PKI-basiscertificeringsinstantie: U moet de Cloud PKI-certificaatvertrouwensketen, die bestaat uit de hoofdcertificeringsinstantie & het uitgeven van openbare CA-sleutels, implementeren voor alle relying party's.
• Cloud PKI BYOCA die CA uitgeeft met behulp van een persoonlijke basiscertificeringsinstantie: De vertrouwde keten van het privé-CA-certificaat, die bestaat uit de basiscertificeringsinstantie en de verlenende certificeringsinstantie, zou al moeten worden geïmplementeerd op relying party's in uw infrastructuur. Hoewel dit niet vereist is, raden we u aan een Cloud PKI BYOCA-certificaat aan te maken.