Rogue AD domain Root Certificate Authority en mogelijkheden

[michaelbar]

Beste,

Ik heb interesse in het starten van een Root CA in ons Windows domein voor 2 redenen. Ik was benieuwd in hoeverre dit beide kon.

1. Het mogelijk maken van SSL voor interne servers. Kan dit daar mee?
2. Het gebruiken van WiFi dmv. certificaten. Kan dit daar ook mee?
3. Wat is er nog meer handig mee te doen?

Daarnaast hebben we, als we certutil.exe draaien, kennelijk een oude build server als Root CA, maar die bestaat niet meer... Die is ooit door iemand verkeer geinstalleerd, nu lijkt het domein contaminated. Hoe ruim ik dat netjes op? Heeft iemand hier een goede handleiding voor?

Waar ik vroeger werkte hebben we WiFi dmv. certificaten gedaan, en ja we hebben een uitgebreide Wireless Controller, dus ik vermoed dat dat hier ook kan, enige is, we hebben ook Mac en Linux machines, hoe zit dat dan voor die? Ik kan daar denk ik geen certificate enrollments voor doen, of wel?

Alvast hartelijk bedankt

Mvg.

Kind regards,

Michael Barton

[HKLM_]

Voor punt drie kan je hier kijken. Het is best wel een stappenplan zo te zien. Waarbij ik me eerst zou inlezen en zorgen voor een goede backup

How to decommission a Windows enterprise certification authority and remove all related objects

[ Voor 9% gewijzigd door HKLM_ op 24-06-2020 12:09 ]

[Question Mark]

Een eigen CA, kan eigen certificaten uitgeven. Wat je met die certificaten doet staat in principe los van je CA instantie.

Als je deze als Enterprise CA installeerd, worden je domainjoined Windows machines default voorzien van het root-certificaat, waardoor deze standaard de uitgegeven certs van deze CA vertrouwen. Voor andere machines (non-domain joined en andere OS-en) zul je daar iets voor moeten regelen.

Wat zijn nu exact de vragen die je hebt. MS heeft meer dan prima docu over het installeren van eigen CA's.

Lees je ook heel goed in over het beveiligen van je CA infrastructuur. Ik zag vroeger nog best veel bedrijfjes waarbij de root-CA gewoon actief in het netwerk te benaderen was. Da's niet helemaal best practices..:)

[Trommelrem]

1. Ja.
2. Ja.
3. Windows Hello.
4. Gewoon met Adsiedit de oude zooi verwijderen.

Question Mark schreef op woensdag 24 juni 2020 @ 19:25:
Ik zag vroeger nog best veel bedrijfjes waarbij de root-CA gewoon actief in het netwerk te benaderen was. Da's niet helemaal best practices..:)

SBS2003, SBS2008 en SBS2011 waren dat volgens mij ook

[ Voor 65% gewijzigd door Trommelrem op 24-06-2020 19:35 ]

[Question Mark]

Trommelrem schreef op woensdag 24 juni 2020 @ 19:34:
1. Ja.
2. Ja.
3. Windows Hello.
4. Gewoon met Adsiedit de oude zooi verwijderen.

[...]

SBS2003, SBS2008 en SBS2011 waren dat volgens mij ook

Niet als het goed ingericht is. Als er niet aan ontkomen wordt om je root-CA systeem aan te laten staan, dan moet minimaal de certificate service disabled zijn. Effectief is dan de root-CA niet meer benaderbaar

[Trommelrem]

Question Mark schreef op donderdag 25 juni 2020 @ 09:01:
[...]

Niet als het goed ingericht is. Als er niet aan ontkomen wordt om je root-CA systeem aan te laten staan, dan moet minimaal de certificate service disabled zijn. Effectief is dan de root-CA niet meer benaderbaar

Een SBS is nooit goed ingericht. Exchange hoort niet op een server waar ook de ADDS rol op draait. Maar Microsoft zag dat gelukkig toen al in en is al heel vroeg met BPOS begonnen. Maar is het disablen van de service voldoende? Volgens mij kan LocalSystem dan alsnog bij de edb files komen.

[Question Mark]

Trommelrem schreef op donderdag 25 juni 2020 @ 10:27:
[...]
Maar is het disablen van de service voldoende? Volgens mij kan LocalSystem dan alsnog bij de edb files komen.

Dat is zeker niet voldoende. Een root-CA wil je eigenlijk compleet offline houden, en in een kluis opslaan. Elke issuing CA zou in een ideale wereld voorzien zijn van Hardware Security Modules (HSM) om de private keys te beschermen. Security van CA's kan héél ver gaan. En terecht, de complete chain valt en staat met het kunnen vertrouwen van CA's.

[Rolfie]

Question Mark schreef op donderdag 25 juni 2020 @ 11:05:
[...]

Dat is zeker niet voldoende. Een root-CA wil je eigenlijk compleet offline houden, en in een kluis opslaan. Elke issuing CA zou in een ideale wereld voorzien zijn van Hardware Security Modules (HSM) om de private keys te beschermen. Security van CA's kan héél ver gaan. En terecht, de complete chain valt en staat met het kunnen vertrouwen van CA's.

In een enterprise omgeving ben ik dit met je eens. Echter bij kleine bedrijven is heel andere koek. Ik ga er toevallig ook 1 dit weekend bouwen. Maar als maar 1 servers hebt draaien, kom je toch al snel op de domain controller uit voor de installatie van de CA.
Kiss is hier van groter belang dan een mooie CA architectuur.

[Trommelrem]

Rolfie schreef op vrijdag 26 juni 2020 @ 17:52:
[...]

In een enterprise omgeving ben ik dit met je eens. Echter bij kleine bedrijven is heel andere koek. Ik ga er toevallig ook 1 dit weekend bouwen. Maar als maar 1 servers hebt draaien, kom je toch al snel op de domain controller uit voor de installatie van de CA.
Kiss is hier van groter belang dan een mooie CA architectuur.

Is het dan niet goedkoper om de CA in Azure te plaatsen en die VM gewoon uit te laten staan? Een VM in Azure die gedeallokeerd is kost alleen een beetje storage.

[Hero of Time]

Rolfie schreef op vrijdag 26 juni 2020 @ 17:52:
[...]

In een enterprise omgeving ben ik dit met je eens. Echter bij kleine bedrijven is heel andere koek. Ik ga er toevallig ook 1 dit weekend bouwen. Maar als maar 1 servers hebt draaien, kom je toch al snel op de domain controller uit voor de installatie van de CA.
Kiss is hier van groter belang dan een mooie CA architectuur.

Met het risico dat als je van de CA af wilt, je de hele server en dus je AD compleet opnieuw moet opbouwen. Terwijl als de CA rol op een aparte, non AD DS server draait, dus een member server is, dit wel mogelijk is zonder compleet vernietigen van je bestaande AD.

Question Mark schreef op woensdag 24 juni 2020 @ 19:25:
Lees je ook heel goed in over het beveiligen van je CA infrastructuur. Ik zag vroeger nog best veel bedrijfjes waarbij de root-CA gewoon actief in het netwerk te benaderen was. Da's niet helemaal best practices..:)

Niet helemaal, maar wel prima toegestaan als je omgeving klein genoeg is. Wil je echt best practise volgen, dan heb je te maken met minstens 3 servers en speciale hardware voor je keys.

Als je dus met een relatief kleine MKB omgeving zit, is een online enterprise CA geoorloofd volgens de MS richtlijnen.

Wil je het iets beter doen, dan kan je net zo makkelijk een Linux VM bakken die de root is en je AD CS machine is dan de intermediate die de certificaten uitdeelt. Is de root toch offline en kan je toch nog vrij uitgeven zonder telkens de CA te moeten aanslingeren. Iets wat ik eerder had moeten weten, maar ach, achteraf....

[Rolfie]

Ik heb in totaal 2 locaties, met op de hoofdlocatie 2 serves draaien. Een domain controllers en een database server. Op locatie 2 heb ik een domain controller draaien. Beide zijn via een pfsense ipsec verbinding verbonden.
Beide domain controllers zijn ook direct DHCP/DNS maar ook File en Print server.
Ik heb ongeveer 10 clients.
Office zit in Office 365.

Trommelrem schreef op vrijdag 26 juni 2020 @ 20:36:
Is het dan niet goedkoper om de CA in Azure te plaatsen en die VM gewoon uit te laten staan? Een VM in Azure die gedeallokeerd is kost alleen een beetje storage.

Waarom zou dit goedkoper zijn?

Wat zou de toegevoegde waarde van een Certificaat server zijn in Azure. Ik zou daar inderdaad een offline CA Root kunnen neerzetten tegen minimale kosten.
Maar wat bied dit mij voor extra voordelen?

Als je een groter bedrijf hebt, is een Root en subordinate een hele goede setup. Een VM in Azure is daar zeker een mogelijkheid. Maar ik zie de noodzaak hiervoor in deze setup niet.

Hero of Time schreef op vrijdag 26 juni 2020 @ 21:20:
Met het risico dat als je van de CA af wilt, je de hele server en dus je AD compleet opnieuw moet opbouwen. Terwijl als de CA rol op een aparte, non AD DS server draait, dus een member server is, dit wel mogelijk is zonder compleet vernietigen van je bestaande AD.

Ik durf dit niet met zekerheid te zeggen, maar volgens mij kun je gewoon je CA decommission en eventueel een nieuwe ergens neerzetten. Je huidige certificaten werken dan natuurlijk niet meer. Maar volgens mij geinstalleren en een beetje ADSIEDIT doen?
Ik zie eigenlijk ook geen noodzaak om de AD te herbouwen, waarom zou dat nodig zijn?

[Trommelrem]

Rolfie schreef op zaterdag 27 juni 2020 @ 12:54:
Waarom zou dit goedkoper zijn?

Wat zou de toegevoegde waarde van een Certificaat server zijn in Azure. Ik zou daar inderdaad een offline CA Root kunnen neerzetten tegen minimale kosten.
Maar wat bied dit mij voor extra voordelen?

Als je een groter bedrijf hebt, is een Root en subordinate een hele goede setup. Een VM in Azure is daar zeker een mogelijkheid. Maar ik zie de noodzaak hiervoor in deze setup niet.

Omdat je dan geen disk space in je eigen omgeving hoeft te reserveren. Bovendien kun je in Azure nog eens met RBAC werken zodat niet iedere administrator zomaar de CA kan aanvuren en hebben administrators ook geen fysieke toegang tot de CA.

Ik durf dit niet met zekerheid te zeggen, maar volgens mij kun je gewoon je CA decommission en eventueel een nieuwe ergens neerzetten. Je huidige certificaten werken dan natuurlijk niet meer. Maar volgens mij geinstalleren en een beetje ADSIEDIT doen?
Ik zie eigenlijk ook geen noodzaak om de AD te herbouwen, waarom zou dat nodig zijn?

Ja, je kunt in kleinere omgevingen gewoon een nieuwe CA maken en de oude data met ADSIEDIT verwijderen. Het wordt complexer (ook in kleinere omgevingen) als je Windows Hello gebruikt op basis van certificate.

[ Voor 4% gewijzigd door Trommelrem op 27-06-2020 13:14 ]

[Rolfie]

Trommelrem schreef op zaterdag 27 juni 2020 @ 13:13:
Omdat je dan geen disk space in je eigen omgeving hoeft te reserveren. Bovendien kun je in Azure nog eens met RBAC werken zodat niet iedere administrator zomaar de CA kan aanvuren en hebben administrators ook geen fysieke toegang tot de CA.

Er zijn 10 gebruikers, waaronder ik de enige beheerder ben.
We hebben een Admin Administrator account en een speciaal account dat op werkstations admin rechten kan geven (Desktop beheerder). Lichte opzet van het Tiering model van Microsoft.

Ik begrijp je gedachte, voor een grote omgeving. Zo hoor je ook een PKI in te richten (meerdere servers, offline root en eventueel een HSM). Zo heb ik er ook een paar draaien, waar ik wel eens langs komen voor beheer of projecten.

Maar wat bied dit voor extra of betere mogelijkheden voor deze omgeving?
Er is eigenlijk maar 1 Administrator account wat gewoon domain admin is (maar niets op werkstations mag).
Ik zie nog steeds niet het nut van een (Offline) Root.

Ja, je kunt in kleinere omgevingen gewoon een nieuwe CA maken en de oude data met ADSIEDIT verwijderen. Het wordt complexer (ook in kleinere omgevingen) als je Windows Hello gebruikt op basis van certificate.

Windows Hello gebruiken we (nog) niet. Maar het verwijderen van een PKI is altijd lastiger ivm de certificaten die gebruikt zijn of worden.

[Hero of Time]

Rolfie schreef op zaterdag 27 juni 2020 @ 12:54:
[...]

Ik durf dit niet met zekerheid te zeggen, maar volgens mij kun je gewoon je CA decommission en eventueel een nieuwe ergens neerzetten. Je huidige certificaten werken dan natuurlijk niet meer. Maar volgens mij geinstalleren en een beetje ADSIEDIT doen?
Ik zie eigenlijk ook geen noodzaak om de AD te herbouwen, waarom zou dat nodig zijn?

Van wat ik heb gelezen nestelt de rol zich best diep in je AD als het op dezelfde server draait als je AD Ds rol, want als het samen staat en je wilt de AD CS rol verwijderen, je ook de AD DS rol zou moeten verwijderen. Van wat ik dus heb gelezen.

Het zou dus niet zo eenvoudig zijn om de restanten via adsiedit eruit te werken. Je kan beslissen om de rol niet meer te gebruiken en een nieuwe CA op te zetten op een andere machine, maar het zal toch in de weg blijven zitten, met vage fouten en whatnot tot potentieel gevolg. Om dat dan op te lossen, is je AD opnieuw bouwen.

[Question Mark]

Hero of Time schreef op zaterdag 27 juni 2020 @ 14:10:
[...]
Het zou dus niet zo eenvoudig zijn om de restanten via adsiedit eruit te werken.

Dat valt op zich wel mee, het zijn maar een paar containers in adsiedit die je moet aanpassen.

https://support.microsoft...ification-authority-and-r

En daarnaast hoeft dit alleen maar als bij de install gekozen is voor een "Enterprise CA", een "StandAlone" CA heeft geen enkele integratie met je AD.

Een alternatief voor het optuigen van een eigen CA zou gewoon het aanschaffen van publieke cert's zijn. Die kosten tegenwoordig zo weinig, dat het bijna niet meer loont om zelf een CA te gaan beheren.

[Hero of Time]

Met alles wat ik bij m'n werk tegenkom wat wel handig is om een certificaat voor te hebben, en met het oog op nieuws: Google en Mozilla gaan geldigheid tls-certificaten beperken tot 398 d..., is het wel handig om zelf certificaten te kunnen uitgeven. En bij het maken van een certificaat voor een appliance kan het meerdere pogingen kosten voordat het ding je certificaat slikt.

Als je maar een handje vol locaties hebt waar je een certificaat voor nodig hebt, kan aanschaffen zeker voordeliger zijn dan een eigen omgeving hebben (tijd voor PKI opzetten, uitzoeken hoe het werkt, etc). Maar wil je iets als 802.1x doen voor je wireless, dan is het toch wel handig om een eigen CA te hebben.

[michaelbar]

Hi allemaal,

I'm overwhelmed... ter verduidelijking, ik wil enkel een CA maken voor binnen het kantoor.

Moet ik die dan nog altijd offline halen zoals hier meermaals wordt gesuggereerd?

Alvast hartelijk bedankt voor alle responses.

Dank jullie wel.

Mvg,

Michael Barton

[Hero of Time]

Lees even https://docs.microsoft.co...nd-2012/hh831574(v=ws.11) door. Dat zou hopelijk al een hoop van je vragen moeten beantwoorden. Ik heb datzelfde document gebruikt om mijn omgeving in te richten. Mijn CA is overigens online en staat altijd aan, mede omdat er nog andere rollen op draaien.

Omdat je het nog moet opzetten, maak niet dezelfde fout als ik heb gemaakt door geen intermediate te maken. De server die de root CA bevat met private key kan elk OS zijn wat je wilt en die zet je na het maken van de intermediate uit. Dat is het beste.

[Question Mark]

michaelbar schreef op woensdag 1 juli 2020 @ 16:38:
Moet ik die dan nog altijd offline halen zoals hier meermaals wordt gesuggereerd?

Da's uiteindelijk een afweging die je zelf moet gaan maken. Als je allemaal persoonlijke data van honderden klanten gaat beveiligen met uitgegeven cert's van je CA zijn de eisen misscheien wat anders, als het alleen maar om access voor een guest wifi-netwerk gaan.

Let wel even op dat met CA in dit geval de CA-software bedoeld wordt, en niet de hele server. Als jij de certificate service op Windows stopt en disabled, is je CA in principe al offline. Nadeel is dan wel dat een hacker met voldoende toegang tot het systeem de service weer kan enablen. Daarom wordt vaak aangeraden om het systeem écht uit te schakelen en ook fysiek van het netwerk te verwijderen. Maar dat is dus die afweging die je even zult moeten maken.

[Rolfie]

michaelbar schreef op woensdag 1 juli 2020 @ 16:38:
Hi allemaal,

I'm overwhelmed... ter verduidelijking, ik wil enkel een CA maken voor binnen het kantoor.

Moet ik die dan nog altijd offline halen zoals hier meermaals wordt gesuggereerd?

Alvast hartelijk bedankt voor alle responses.

Dank jullie wel.

Mvg,

Michael Barton

Hangt er een beetje vanaf wat je ermee wilt gaan doen.
Maar bij kleine klanten zou ik gewoon KISS handhaven. Gewoon een Enterprise CA Root draaien op Windows. Anders wordt het al snel complexer.
Deze opzet is goed te gebruiken voor bijvoorbeeld VPN/NAC/Wifi authenticatie.

Wil je hem veiliger / complexer maken, dan moet je met een Offline Root gaan werken, maar die moet je dus ook goed backupen en waren. Bij grote bedrijven gebruikelijk. Maar zeker geen noodzaak.