Belajar Active Directory - Active Directory Certificate Services (AD CS)

#Pendahuluan

Di episode 17 kita mempelajari cara mem-backup dan memulihkan Active Directory — memastikan direktori selamat meskipun terjadi bencana. Tapi ada satu pertanyaan yang belum kita jawab: bagaimana memastikan komunikasi antara pengguna, mesin, dan layanan benar-benar tepercaya? Jawabannya seringkali bergantung pada sertifikat digital. Di episode 18 ini kita membangun Active Directory Certificate Services (AD CS) — layanan yang mengubah AD menjadi pusat penerbitan sertifikat (Certificate Authority) untuk seluruh jaringan.

Kenapa AD CS penting? Bayangkan sebuah aplikasi web internal yang wajib diakses dengan HTTPS. Tanpa CA sendiri, kalian harus membeli sertifikat dari pihak ketiga atau memakai sertifikat self-signed yang tidak dipercaya mesin lain. AD CS memungkinkan organisasi menerbitkan sertifikat untuk mesin, pengguna, dan layanan secara otomatis — terintegrasi dengan AD dan langsung dipercaya oleh semua komputer yang bergabung ke domain.

#Apa Itu PKI

PKI (Public Key Infrastructure) adalah keseluruhan sistem yang menerbitkan, mendistribusikan, menyimpan, dan mencabut sertifikat digital. Komponen intinya:

Sertifikat — dokumen digital berisi identitas subjek (nama komputer atau pengguna), kunci publik, dan tanda tangan CA.
Pasangan kunci — kunci publik yang boleh dibagikan dan kunci privat yang wajib dirahasiakan.
Certificate Authority (CA) — entitas tepercaya yang menandatangani dan menerbitkan sertifikat.
Rantai sertifikat — urutan sertifikat yang menghubungkan sertifikat subjek hingga ke root CA yang dipercaya.

Analogi paling dekat adalah paspor. Paspor kalian diterbitkan oleh kantor imigrasi (CA), dan petugas perbatasan mempercayainya karena penerbitnya sah. Sama halnya di dunia digital: komputer mempercayai sebuah sertifikat jika sertifikat itu ditandatangani oleh CA yang sudah masuk daftar trusted root miliknya.

#Rantai Kepercayaan (Certificate Chain)

Di lingkungan enterprise, sertifikat jarang diterbitkan langsung oleh root CA. Alih-alih, digunakan hirarki berlapis:

Root CA — puncak kepercayaan. Sering di-offline dan disimpan aman agar kunci privatnya tidak pernah terpapar jaringan.
Subordinate CA — jembatan antara root dan CA penerbit.
Issuing CA — CA yang benar-benar menerbitkan sertifikat untuk mesin dan pengguna.

Kenapa berlapis? Ini prinsip isolasi kerusakan. Jika satu issuing CA bocor, kalian cukup mencabut sertifikat subordinate itu tanpa membongkar seluruh root. Root yang offline berarti kunci privatnya tidak bisa dicuri lewat jaringan. Semakin panjang rantai, semakin mudah mengisolasi insiden.

#Tipe CA di AD CS

AD CS menyediakan dua tipe dasar berdasarkan integrasinya dengan AD:

Tipe CA	Terintegrasi AD	Template otomatis	Cocok untuk
Enterprise CA	Ya	Ya	DC, user, dan komputer dalam domain
Standalone CA	Tidak	Tidak	Root CA yang di-offline atau organisasi kecil

Kombinasi yang umum di produksi: Standalone Root CA yang di-offline di puncak, lalu Enterprise Issuing CA yang online dan menerbitkan sertifikat kepada objek AD.

#Use Case Sertifikat di Organisasi

Setelah AD CS berdiri, sertifikat dipakai di banyak tempat:

SSL/TLS untuk web server internal dan aplikasi.
Smart card logon dan Windows Hello for Business.
EFS (Encrypting File System) untuk enkripsi file per pengguna.
Code signing untuk skrip dan aplikasi internal.
802.1x autentikasi WiFi dan jaringan kabel.
S/MIME untuk menandatangani dan mengenkripsi email.
IPsec untuk mengamankan komunikasi antar server.

Intinya: sertifikat mengubah identitas AD menjadi identitas yang bisa dibuktikan secara kriptografis — sesuatu yang tidak bisa dipalsukan hanya dengan mengetahui nama pengguna.

#Instalasi AD CS

Instalasi dilakukan dalam dua tahap: install role, lalu konfigurasi CA. Gunakan PowerShell di server yang akan menjadi CA:

Instalasi AD CS - Enterprise Root CA

Install-WindowsFeature ADCS-Cert-Authority -IncludeManagementTools
Install-AdcsCertificationAuthority -CAType EnterpriseRootCa -CACommonName "Corp-Root-CA" -CryptoProviderName "RSA#Microsoft Software Key Storage Provider" -KeyLength 4096 -HashAlgorithmName SHA256 -ValidityPeriod Years -ValidityPeriodUnits 10
Restart-Service CertSvc

Untuk CA penerbit (issuing), gunakan tipe subordinate:

Instalasi Enterprise Issuing CA

Install-AdcsCertificationAuthority -CAType EnterpriseSubordinateCa -CACommonName "Corp-Issuing-CA" -CryptoProviderName "RSA#Microsoft Software Key Storage Provider" -KeyLength 2048 -HashAlgorithmName SHA256 -ValidityPeriod Years -ValidityPeriodUnits 5

Tip

Gunakan kunci 4096-bit untuk Root CA dan 2048-bit untuk Issuing CA. Kecepatan menandatangani issuing CA lebih penting daripada ukuran kuncinya, sedangkan root jarang dipakai sehingga aman memakai kunci terpanjang.

Setelah instalasi, konfigurasi berlanjut di konsol certsrv.msc: menentukan masa berlaku, lokasi database sertifikat, dan opsi kriptografi.

#Certificate Templates

Template adalah resep sertifikat yang menentukan penggunaan, masa berlaku, panjang kunci, dan siapa yang boleh menerima sertifikat. AD CS membawa template bawaan yang siap pakai:

Web Server — untuk IIS dan SSL/TLS.
Computer dan User — untuk autentikasi mesin dan pengguna.
Smartcard Logon — untuk autentikasi kartu pintar.
EFS Recovery Agent — untuk memulihkan file terenkripsi.

Jika template bawaan tidak memenuhi kebutuhan, buat custom template: duplikasi template versi 2 atau lebih, ubah atribut, lalu atur permission enrollment. Permission menentukan siapa yang boleh Read, Enroll, atau Autoenroll terhadap template tersebut — prinsipnya, batasi enrollment hanya pada grup yang benar-benar membutuhkan.

Warning

Template versi 1 tidak bisa dimodifikasi langsung di konsol. Selalu duplikasi menjadi versi 2+ sebelum mengubah properti, agar perubahan tidak memengaruhi template bawaan sistem.

#Enrollmen Sertifikat

Ada empat jalur enrollment:

Manual — pengguna meminta sertifikat lewat certlm.msc atau certmgr.msc.
Web enrollment — lewat antarmuka web CA di jalur http://ca-server/certsrv.
NDES — untuk perangkat jaringan yang tidak punya identitas AD (router, switch, printer).
Auto-enrollment — mesin dan pengguna menerima sertifikat otomatis tanpa interaksi.

Auto-enrollment adalah mode yang paling efisien. Setelah template diizinkan untuk autoenroll dan CA dipublikasikan ke AD, buat GPO yang mengaktifkannya:

Publikasikan Root CA dan paksa pemeriksaan auto-enrollment

certutil -dspublish -f C:\Certs\Corp-Root-CA.crt RootCA
certutil -addstore -f -enterprise Root C:\Certs\Corp-Root-CA.crt
certutil -pulse

Aktifkan auto-enrollment di GPMC: buka GPO, arahkan ke Computer Configuration > Policies > Windows Settings > Security Settings > Public Key Policies > Certificate Services Client - Auto-Enrollment, set Configuration Model menjadi Enabled, lalu centang opsi renew, update, dan remove sertifikat yang tidak berlaku.

Dengan GPO ini, setiap komputer yang boot atau setiap pengguna yang logon otomatis diperiksa template-nya dan menerima sertifikat jika memenuhi syarat. Sertifikat terbaru diperpanjang tanpa perlu pengguna tahu apa-apa — itulah kekuatan identitas terpusat yang bekerja di balik layar.

#Verifikasi Sertifikat

Untuk memastikan rantai kepercayaan sehat, cek dari sisi CA dan sisi klien:

Di CA: certutil -dump menampilkan detail CA, dan Get-CAService mengecek status layanan.
Di klien: buka certlm.msc lalu buka Trusted Root Certification Authorities — sertifikat root harus muncul di sana, dan sertifikat mesin muncul di folder Personal.

Note

Jika sertifikat klien tidak muncul, periksa urutan kepercayaan: apakah root sudah terpublikasi, apakah template mengizinkan autoenroll, dan apakah GPO sudah di-apply dengan gpresult /r.

#Penutup

Di episode ini kalian telah membangun PKI di atas AD:

Sertifikat adalah identitas digital yang diterbitkan oleh CA, dan rantai kepercayaan menghubungkan sertifikat ke root yang dipercaya.
Enterprise CA terintegrasi dengan AD dan mendukung template serta auto-enrollment; Standalone CA cocok untuk root yang di-offline.
Template mengontrol isi sertifikat dan siapa yang boleh menerimanya.
Auto-enrollment via GPO membuat sertifikat terdistribusi dan diperbarui otomatis.

Sertifikat bukan lagi barang mahal yang dibeli dari vendor — sekarang ia adalah layanan infrastruktur yang dikelola sendiri. Di episode 19, kita membahas Read-Only Domain Controllers (RODC): bagaimana menempatkan domain controller di kantor cabang tanpa mengorbankan keamanan, lengkap dengan password replication policy. Sampai jumpa!