Memilih akun layanan Windows — kapan memakai LocalSystem, akun virtual, dan gMSA

“Layanan internal yang selama ini dijalankan sebagai LocalSystem ditandai dalam audit keamanan sebagai ‘hak berlebih’. Harus diganti ke apa?” “Layanan tidak bisa mengakses folder berbagi, jadi dijalankan sebagai pengguna domain. Ketika kata sandi kedaluwarsa layanan berhenti, jadi dibuat tidak pernah kedaluwarsa dan ditulis dalam teks biasa di runbook.” — Di antara konsultasi seputar layanan Windows pelanggan, dua ini adalah yang paling sering muncul.

Yang sama di kedua lapangan adalah bahwa akun yang menjalankan layanan dibekukan sebagai “pengaturan yang kebetulan berhasil”, bukan sebagai keputusan desain. Layanan Windows selalu berjalan dalam konteks keamanan suatu akun, dan akun itu yang memutuskan seluruhnya: apa yang bisa dilakukan secara lokal, sebagai siapa ia tampil dari sisi jauh jaringan, dan siapa yang mengelola kata sandi. Jika dibiarkan pada default, kerentanan di satu layanan langsung menjadi pengambilalihan seluruh mesin, dan kata sandi teks biasa bertebaran di runbook dan skrip.

flowchart TB
    accTitle: Tiga hal yang diputuskan akun eksekusi
    accDescr: Layanan selalu berjalan dalam konteks keamanan suatu akun, dan akun itu memutuskan seluruhnya apa yang dapat dilakukan secara lokal, sebagai siapa ia tampil dari sisi jauh jaringan, dan siapa yang mengelola kata sandi
    acct["Akun yang menjalankan layanan"] --> local["Apa yang dapat dilakukan secara lokal"]
    acct --> net["Sebagai siapa ia tampil dari sisi jauh jaringan"]
    acct --> pwd["Siapa yang mengelola kata sandi"]

Gambar 1: Memilih akun eksekusi adalah keputusan desain yang sekaligus memutuskan hak lokal, identitas jaringan, dan pengelolaan kata sandi.

Ada enam pilihan yang efektif — LocalSystem, LocalService, NetworkService, akun virtual (NT SERVICE\), pengguna domain, dan gMSA (group Managed Service Account). Ditujukan kepada staf IT usaha kecil dan menengah serta pengembang aplikasi Windows, artikel ini merangkai hak, identitas jaringan, dan pengelolaan kata sandi keenamnya ke dalam satu tabel dan merangkum alur keputusan, berdasarkan sumber primer Microsoft Learn per Agustus 2026.

Cara membangun layanan itu sendiri (memilih antara Task Scheduler dan layanan, mengimplementasikan dengan .NET Worker Service) dibahas di “Cara membangun dan mengoperasikan layanan Windows”. Artikel ini berkonsentrasi pada “akun eksekusi”, tempat paling banyak terjadi insiden.

1. Kesimpulan dulu

• Jika ragu, akun virtual adalah kandidat pertama untuk layanan yang selesai di dalam satu mesin, dan gMSA adalah kandidat pertama untuk layanan yang mengakses sumber daya di dalam domain dengan identitas khusus layanan. Microsoft juga memberi panduan memakai akun terkelola (MSA / akun virtual) sedapat mungkin.¹²
• Jangan memilih LocalSystem hanya karena “berhasil”. Token mencakup SYSTEM dan BUILTIN\Administrators dan memegang hak kuat seperti SeDebugPrivilege, jadi pengambilalihan hampir berarti kehilangan semuanya di mesin itu. Default sc.exe create yang LocalSystem adalah tempat berkembang biaknya insiden ini.³⁴
• Perbedaan LocalService dan NetworkService adalah identitas jaringan. Hak lokal minimal untuk keduanya, tetapi ke sisi jarak jauh LocalService tampil anonim dan NetworkService tampil sebagai akun komputer.⁵
• **Akun virtual (NT SERVICE\) adalah default modern yang memisahkan identitas per layanan tanpa pengelolaan kata sandi.** "NT SERVICE\\nama-layanan" dapat ditulis langsung pada ACL, dan akun layanan default SQL Server juga ini.[^understand-service-accounts][^sql-service-accounts]
• Ketika LocalSystem, NetworkService, atau akun virtual keluar ke jaringan, identitasnya menjadi akun komputer (DOMAIN\nama-komputer$). Memberi PC$ pada ACL folder berbagi atau SQL Server sering memungkinkan tidak memakai pengguna domain.³⁶
• Konfigurasi yang memakai pengguna domain untuk layanan menjadi utang baik pada operasi kata sandi maupun Kerberoasting. SCM masuk dengan kata sandi tersimpan, jadi kedaluwarsa menjadi kegagalan mulai, dan “tidak pernah kedaluwarsa + catatan teks biasa” yang menghindari itu menjadi hadiah bagi penyerang.⁷⁸
• gMSA membuat Active Directory menghasilkan dan merotasi kata sandi secara otomatis. Persyaratannya adalah domain dan KDS root key, dan layanan diatur ke “DOMAIN\nama-akun$” dengan kolom kata sandi kosong. Ada aplikasi yang tidak mendukungnya, jadi validasi di muka diperlukan.⁹¹⁰
• Mengganti akun mengubah asumsi profil, %TEMP%, dan DPAPI. Data yang dilindungi dengan DPAPI akun lama tidak dapat didekripsi oleh akun baru.
• Inventaris keadaan saat ini dapat dikonfirmasi dari akun eksekusi pada daftar layanan dan dari event ID 4624 (logon type 5).¹¹

Dalam satu kalimat, kesimpulan artikel ini adalah: jadikan konfigurasi yang “tidak memberi kata sandi manusia kepada layanan” (akun built-in, akun virtual, gMSA) sebagai default, dan perlakukan pengguna domain sebagai pilihan terakhir.

Pada diagram, garis utuh menunjukkan relasi yang selalu berlaku dan garis putus-putus menunjukkan relasi bersyarat (syaratnya ada pada penjelasan masing-masing relasi di halaman rincian). Daftar lengkap relasi (total 19, beserta bukti dan tingkat kepastian) serta definisi konsep utama dikumpulkan di halaman rincian peta pengetahuan (dalam bahasa Jepang). Data: JSON-LD / Turtle

2. Gambaran besar pilihan — enam akun eksekusi dalam satu tabel

Satu langkah tinjauan dulu. Saat layanan mulai, Service Control Manager (SCM) masuk dengan akun yang dikonfigurasi dan, jika berhasil, membuat access token lalu menetapkannya ke proses layanan. Setelah itu, setiap akses sumber daya — berkas, pipe, dan sejenisnya — diputuskan dengan mencocokkan token ini terhadap ACL.⁷ Jadi memilih akun eksekusi adalah desain yang memutuskan isi token yang diberikan ke proses layanan. Berikut enam pilihannya.

flowchart TB
    accTitle: Apa yang dilakukan SCM saat layanan mulai
    accDescr: SCM masuk dengan akun yang dikonfigurasi, jika berhasil membuat access token dan menetapkannya ke proses layanan, dan setelah itu akses sumber daya diputuskan dengan mencocokkan token terhadap ACL
    scm["SCM"] --> logon["Masuk dengan akun yang dikonfigurasi"]
    logon --> token["Buat access token"]
    token --> proc["Tetapkan ke proses layanan"]
    proc --> access["Akses ke berkas atau pipe"]
    access --> check{"Apakah ACL mengizinkan?"}
    check -->|Ya| ok["Akses berhasil"]
    check -->|Tidak| deny["Akses ditolak"]

Gambar 2: Setiap akses sumber daya layanan diputuskan dengan mencocokkan token yang dibuat SCM saat mulai terhadap ACL.

LocalSystem, LocalService, NetworkService, dan akun virtual semuanya tidak punya konsep kata sandi sama sekali. Satu-satunya yang masuk dengan kata sandi tersimpan di SCM (= kedaluwarsa dan kebocoran mungkin) adalah pengguna domain dan pengguna lokal.⁷³

Di bawah ini tabel ini digali satu baris demi satu baris.

3. Apa yang bermasalah dengan LocalSystem

3.1. Masih lebih kuat daripada “Jalankan sebagai administrator”

LocalSystem (nama tampilan Local System, NT AUTHORITY\SYSTEM) adalah akun yang telah ditentukan yang dipakai SCM, dan ia memegang hak luas di komputer lokal. Token mencakup SID NT AUTHORITY\SYSTEM dan BUILTIN\Administrators, dan ia dapat mengakses sebagian besar objek di sistem. Lebih jauh, SeDebugPrivilege, yang dapat men-debug proses lain, dan SeTcbPrivilege, yang bertindak sebagai bagian dari OS, diaktifkan secara default.³

Kekuatan ini sinonim dengan besarnya kerusakan ketika diambil alih. Jika layanan yang berjalan sebagai LocalSystem punya satu kerentanan eksekusi kode arbitrer, penyerang dalam satu napas sampai ke membaca dan mengubah berkas setiap pengguna di mesin itu (SYSTEM punya Full Control secara default pada NTFS⁵), membaca memori proses lain lewat SeDebugPrivilege, dan mencuri kredensial lalu bergerak lateral dari situ (titik awal Pass-the-Hash dan sejenisnya). Rantai pencurian kredensial dan pergerakan lateral seperti yang dibahas di “NTLM dan Kerberos dijelaskan dengan diagram” dan “Panduan praktis Windows LAPS”.

flowchart TB
    accTitle: Kerusakan ketika layanan LocalSystem diambil alih
    accDescr: Jika layanan yang berjalan sebagai LocalSystem punya satu kerentanan eksekusi kode arbitrer, penyerang sampai ke membaca dan mengubah berkas setiap pengguna, membaca memori proses lain, dan mencuri kredensial lalu bergerak lateral
    vuln["Satu kerentanan eksekusi kode arbitrer"] --> sys["Penyerang memperoleh hak SYSTEM"]
    sys --> files["Membaca dan mengubah berkas"]
    sys --> mem["Membaca memori proses lain"]
    sys --> cred["Mencuri kredensial"]
    cred --> lateral["Pergerakan lateral ke mesin lain"]

Gambar 3: Satu kerentanan pada layanan LocalSystem membuat penyerang dalam satu napas sampai ke penguasaan seluruh mesin dan titik awal pergerakan lateral.

3.2. Mengapa tetap dipilih

Alasannya sederhana: itu default, dan access denied tidak pernah muncul. Default ketika obj= dihilangkan pada sc.exe create adalah LocalSystem⁴, dan banyak kode sampel lama serta kerangka penginstal masih berasumsi LocalSystem. Karena pengembangan bebas dari error hak, struktur “berhasil, jadi dibiarkan” diproduksi massal. Dokumentasi Microsoft sendiri menyatakan bahwa sebagian besar layanan tidak membutuhkan tingkat hak setinggi ini, dan jika tidak diperlukan, LocalService atau NetworkService perlu dipertimbangkan.³

flowchart TB
    accTitle: Struktur yang membuat LocalSystem terus dipilih
    accDescr: Default sc.exe create adalah LocalSystem, dan kode sampel lama serta kerangka juga berasumsi LocalSystem, sehingga access denied tidak muncul selama pengembangan dan konfigurasi "berhasil, jadi dibiarkan" diproduksi massal
    def["Default sc.exe create"] --> lsys["Dibuat sebagai LocalSystem"]
    old["Sampel dan kerangka lama"] --> lsys
    lsys --> noerr["Access denied tidak muncul selama pengembangan"]
    noerr --> asis["Berhasil, jadi dibiarkan"]
    asis --> mass["Layanan berhak berlebih diproduksi massal"]

Gambar 4: Default dan pengalaman pengembangan “tanpa access denied” memproduksi massal layanan yang tertahan sebagai LocalSystem.

3.3. Perbedaan dari TrustedInstaller — LocalSystem pun tidak tanpa batas

Selain itu, menyebut LocalSystem sebagai “akun terkuat Windows” tidak akurat. Windows Resource Protection (WRP) sejak Windows Vista hanya mengizinkan TrustedInstaller (layanan Windows Modules Installer) mengubah berkas sistem, folder, dan kunci registri penting OS; bahkan SYSTEM atau administrator menerima access denied saat menulis.¹² “Izin TrustedInstaller diperlukan” di Explorer adalah mekanisme ini. Sebaliknya, LocalSystem hampir menjangkau semuanya di luar area yang dilindungi WRP, dan biasanya tidak ada alasan memberikannya kepada layanan bisnis.

flowchart TB
    accTitle: Hubungan area terlindungi WRP dan TrustedInstaller
    accDescr: Perubahan berkas sistem dan kunci registri penting yang dilindungi WRP hanya diizinkan untuk TrustedInstaller; bahkan SYSTEM atau administrator menerima access denied
    ti["TrustedInstaller"] -->|Dapat diubah| wrp["Berkas sistem dll. yang dilindungi WRP"]
    sysadm["SYSTEM / administrator"] -->|Access denied| wrp
    sysadm -->|Hampir semua boleh| other["Di luar area terlindungi WRP"]

Gambar 5: LocalSystem pun tidak tanpa batas; perubahan area terlindungi WRP hanya diizinkan untuk TrustedInstaller.

3.4. Kasus di mana LocalSystem masuk akal

Yang masuk akal secara pengecualian adalah layanan yang hak yang dimintanya memang sudah melampaui setara administrator, misalnya yang bekerja rapat dengan driver perangkat, yang mengoperasikan fondasi keamanan OS, atau yang mengelola layanan dan sesi lain. Perangkat lunak seperti agen cadangan dan EDR termasuk di sini. Meski begitu, ada nilai untuk mengonfirmasi apakah benar-benar ada jalur kode yang memakai hak itu, dan apakah pemrosesan yang membutuhkan hak dapat dipisah (cara menilainya ada di “Kapan hak administrator Windows benar-benar diperlukan”).

4. LocalService dan NetworkService — akun built-in hak minimum

LocalService (NT AUTHORITY\LOCAL SERVICE, SID: S-1-5-19) dan NetworkService (NT AUTHORITY\NETWORK SERVICE, SID: S-1-5-20) adalah akun built-in yang disiapkan untuk layanan berhak rendah. Keduanya hanya memegang hak minimal secara lokal, dan secara kasar hanya dapat mengakses setara anggota grup Users.⁵¹

Perbedaan keduanya hanya satu: sebagai siapa ia tampil dari sisi jauh jaringan.⁵

• LocalService: menyambung ke sisi jarak jauh dengan kredensial anonim. Sumber daya yang meminta autentikasi tidak dapat diakses.
• NetworkService: menyajikan kredensial komputer ke sisi jarak jauh (di lingkungan domain: DOMAIN\nama-komputer$).

Pemisahannya: LocalService jika “tidak keluar ke jaringan, atau keluar pun tidak butuh identitas”; NetworkService jika “ingin mengakses sumber daya di dalam domain dengan identitas mesin”.

flowchart TB
    accTitle: Perbedaan LocalService dan NetworkService
    accDescr: Hak lokal minimal untuk keduanya, tetapi ke sisi jarak jauh LocalService menyambung dengan kredensial anonim, dan NetworkService menyajikan kredensial komputer
    ls["LocalService"] --> anon["Menyambung dengan kredensial anonim"]
    anon -.-> ng["Sumber daya yang meminta autentikasi tidak bisa"]
    ns["NetworkService"] --> comp["Menyajikan kredensial komputer"]
    comp -.-> pc["Di lingkungan domain tampil sebagai PC$"]

Gambar 6: Hak lokal sama-sama minimal, tetapi identitas yang terlihat dari sisi jauh jaringan terbagi antara anonim dan akun komputer.

Namun, dari sudut pandang modern, keduanya punya kelemahan. Banyak layanan memakai akun yang sama. Jika lima layanan berjalan sebagai LocalService, selama ACL berunit akun, kelimanya dapat mengakses sumber daya satu sama lain. Alasan SQL Server tidak mendukung akun Local Service juga karena akun bersama, sehingga tidak dapat dipisah dari layanan lain.¹

flowchart TB
    accTitle: Akun bersama tidak dapat dipisah
    accDescr: Jika beberapa layanan memakai LocalService yang sama, selama ACL berunit akun mereka dapat mengakses sumber daya satu sama lain
    sva["Layanan A"] --> acct["LocalService yang sama"]
    svb["Layanan B"] --> acct
    svc["Layanan C"] --> acct
    acct --> mutual["Dapat mengakses sumber daya satu sama lain"]
    mutual -.-> reason["Karena ACL berunit akun"]

Gambar 7: Layanan yang memakai akun yang sama tidak dapat dipisah dari sumber daya satu sama lain lewat ACL.

Yang menyelesaikan “tetap berhak rendah, tetapi ingin dipisah per layanan” adalah akun virtual berikut.

5. Akun virtual (NT SERVICE\) — default modern

5.1. Tanpa kata sandi, identitas per layanan

Akun virtual adalah “akun lokal terkelola” yang dapat dipakai sejak Windows Server 2008 R2 / Windows 7. Cirinya tiga.⁶

• Akun dikelola otomatis; pembuatan dan pengaturan kata sandi tidak diperlukan
• Namanya NT SERVICE\<nama-layanan>, dan menjadi identitas unik per satu layanan
• Di lingkungan domain, akses ke jaringan memakai kredensial akun komputer (DOMAIN\nama-komputer$)

Dengan kata lain, kelebihan LocalService/NetworkService “tidak perlu pengelolaan kata sandi” tetap dipertahankan, sementara kelemahan “tidak dapat dipisah karena akun bersama” dihilangkan. Setup SQL Server memakai akun virtual seperti NT SERVICE\MSSQLSERVER secara default juga karena ini.¹

flowchart TB
    accTitle: Apa yang disatukan akun virtual
    accDescr: Akun virtual mempertahankan kelebihan LocalService dan NetworkService yaitu tidak perlu pengelolaan kata sandi, menghilangkan kelemahan tidak dapat dipisah karena akun bersama, dan punya identitas unik per satu layanan
    merit["Kelebihan (tidak perlu pengelolaan kata sandi)"] -->|Dipertahankan| va["Akun virtual"]
    demerit["Kelemahan (tidak dapat dipisah karena bersama)"] -->|Dihilangkan| va
    va --> ident["Identitas unik per layanan"]
    va --> auto["Pembuatan dan pengaturan kata sandi tidak perlu"]

Gambar 8: Akun virtual mempertahankan kelebihan akun built-in, dan hanya menghilangkan kelemahan tidak dapat dipisah karena bersama.

5.2. “NT SERVICE\nama-layanan” dapat ditulis langsung pada ACL

Kenyamanan praktisnya adalah hanya layanan itu yang dapat ditambahkan secara bernama pada ACL. “Folder data ini hanya dapat ditulis layanan ini” dapat diwujudkan tanpa membuat grup dan tanpa pengelolaan kata sandi.

# Ubah akun logon layanan ke akun virtual
# Nilai obj= adalah "NT SERVICE\nama-layanan". Jangan tentukan kata sandi
sc.exe config MyAppService obj= "NT SERVICE\MyAppService"

# Konfirmasi konfigurasi (periksa SERVICE_START_NAME)
sc.exe qc MyAppService

# Berikan hak ubah pada folder data hanya kepada layanan ini
icacls "C:\ProgramData\MyApp" /grant "NT SERVICE\MyAppService:(OI)(CI)M"

Jika lewat GUI, di services.msc buka properti layanan → tab “Log on” → masukkan NT SERVICE\nama-layanan pada “Account”, dan biarkan kolom kata sandi kosong (spesifikasi SCM adalah tidak menentukan kata sandi untuk akun virtual atau MSA). Setelah diubah, berlaku dengan memulai ulang layanan.

5.3. Batasan — di luar mesin, “layanan mana” tidak diketahui

Identitas akun virtual bersifat lokal-mesin, dan tidak dikenali dari domain. Di jaringan, seperti dibahas kemudian, identitasnya menyusut menjadi akun komputer, sehingga sisi jarak jauh tidak dapat membedakan “layanan mana”, dan identitas yang sama juga tidak dapat dibagi di beberapa server.¹⁰

flowchart TB
    accTitle: Identitas akun virtual menyusut di luar mesin
    accDescr: Di dalam mesin, akun virtual unik per layanan pun menyusut menjadi akun komputer di jaringan, dan sisi jarak jauh tidak dapat membedakan layanan mana
    vaa["Akun virtual A"] --> pc["Akun komputer PC$"]
    vab["Akun virtual B"] --> pc
    pc --> remote["Identitas yang terlihat dari sisi jarak jauh"]
    remote -.-> nodist["Tidak dapat membedakan layanan mana"]

Gambar 9: Di dalam mesin identitasnya unik, tetapi di sisi jauh jaringan semua layanan tampil sebagai PC$ yang sama.

Batasan ini — identitas khusus layanan dibutuhkan di sisi jauh jaringan, atau identitas yang sama dibutuhkan di beberapa server — adalah saat gMSA (bab 8) masuk.

6. Identitas saat keluar ke jaringan — praktik akun komputer (PC$)

6.1. “Layanan tidak dapat mengakses folder berbagi” adalah kesalahpahaman

Pada mesin yang bergabung ke domain, ketika layanan yang berjalan sebagai LocalSystem, NetworkService, atau akun virtual mengakses sumber daya jarak jauh, ia diautentikasi sebagai akun komputer (DOMAIN\nama-komputer$).³⁶ Banyak konsultasi di awal “tidak dapat mengakses folder berbagi jadi dipakai pengguna domain” sebenarnya selesai dengan ini. Hanya ACL tujuan yang tidak mengizinkan PC$.

flowchart TB
    accTitle: Akses jarak jauh dengan akun komputer
    accDescr: Layanan LocalSystem, NetworkService, atau akun virtual pada mesin yang bergabung ke domain diautentikasi ke sisi jarak jauh sebagai akun komputer, dan dapat mengakses jika ACL tujuan mengizinkan PC$
    svc["Layanan (LocalSystem, akun virtual, dll.)"] --> auth["Autentikasi sebagai PC$"]
    auth --> acl{"ACL tujuan mengizinkan PC$?"}
    acl -->|Ya| ok["Akses ke folder berbagi atau DB berhasil"]
    acl -->|Tidak| ng["Akses ditolak"]

Gambar 10: Di lingkungan domain, cukup memberi PC$ pada ACL tujuan agar akses jarak jauh tanpa pengguna domain terbentuk.

Pemberian di sisi file server sama dengan operasi ACL biasa: tentukan nama-komputer$ sebagai nama akun (di dialog pemilihan objek GUI, sertakan “Computers” pada Object Types).

# Sisi file server: beri hak ubah pada folder berbagi kepada layanan di APPSV01
# Perlu diberikan pada izin berbagi dan izin NTFS
Grant-SmbShareAccess -Name "AppData" -AccountName "CORP\APPSV01$" -AccessRight Change -Force
icacls "D:\Shares\AppData" /grant "CORP\APPSV01$:(OI)(CI)M"

SQL Server sama: buat akun komputer sebagai login, maka connection string tetap Integrated Security=true dan lolos tanpa kata sandi.

-- Sisi server DB: izinkan Windows integrated authentication dari layanan di APPSV01
CREATE LOGIN [CORP\APPSV01$] FROM WINDOWS;

6.2. Kenali batasan cara PC$

Cara ini punya dua batasan.

1. Granularitasnya per mesin. Semua layanan LocalSystem, NetworkService, dan seluruh akun virtual yang berjalan di mesin yang sama, dari sisi jarak jauh tampil sebagai PC$ yang sama. Di tujuan, “hanya izinkan layanan ini” tidak bisa, dan layanan mana yang memakai akun itu juga tidak dapat diaudit.²
2. Tidak dapat dipakai di lingkungan workgroup. Akun komputer adalah objek Active Directory, jadi tidak ada pada mesin yang tidak bergabung ke domain. Diperlukan rancangan yang menangani kredensial akun tujuan secara eksplisit.

Jika ingin melampaui batasan 1, jawabannya di 2026 bukan pengguna domain di bab berikutnya… melainkan melewati masalah itu dan maju ke gMSA.

flowchart TB
    accTitle: Dua batasan cara PC$
    accDescr: Autentikasi dengan PC$ granularitasnya per mesin sehingga izin dan audit per layanan tidak bisa, dan di lingkungan workgroup akun komputer itu sendiri tidak ada sehingga tidak dapat dipakai
    pcs["Cara PC$"] --> lim1["Batasan 1 (granularitas per mesin)"]
    pcs --> lim2["Batasan 2 (workgroup tidak bisa)"]
    lim1 -.-> noaudit["Izin dan audit per layanan tidak bisa"]
    lim2 -.-> nocred["Ke rancangan kredensial eksplisit"]
    lim1 --> gmsa["Jika ingin melampaui, ke gMSA"]

Gambar 11: Jika ingin melampaui dua batasan — granularitas per mesin dan prasyarat domain — lewati pengguna domain dan maju ke gMSA.

7. Masalah memakai pengguna domain untuk layanan

7.1. Masalah struktural kata sandi

Jika pengguna domain (atau pengguna lokal) ditetapkan ke layanan, SCM menyimpan kata sandinya dan memakainya untuk logon setiap kali mulai. SCM tidak mengelola kedaluwarsa, jadi ketika kata sandi kedaluwarsa, logon gagal dan layanan tidak akan mulai.⁷

Dari sini, spiral negatif yang sering terlihat di lapangan dimulai.

1. Terjadi insiden layanan berhenti karena kedaluwarsa
2. Sebagai pencegahan, diatur “kata sandi tidak pernah kedaluwarsa”
3. Prosedur perubahan tidak tertata, dan kata sandi yang sama tertulis dalam teks biasa di runbook, skrip, dan Task Scheduler beberapa server
4. Meski ada orang yang keluar, kata sandi tidak berubah (jika diubah, tidak diketahui mana yang akan berhenti)

flowchart TB
    accTitle: Spiral negatif operasi pengguna domain
    accDescr: Layanan berhenti karena kata sandi kedaluwarsa, diatur tidak pernah kedaluwarsa sebagai pencegahan, kata sandi teks biasa menyebar ke runbook dan skrip, dan tidak dapat diubah meski ada orang yang keluar
    expire["1. Layanan berhenti karena kedaluwarsa"] --> forever["2. Diatur tidak pernah kedaluwarsa sebagai pencegahan"]
    forever --> spread["3. Kata sandi teks biasa menyebar"]
    spread -.-> where["Runbook, skrip, tugas"]
    spread --> stuck["4. Tidak dapat diubah meski ada orang yang keluar"]

Gambar 12: Dimulai dari insiden kedaluwarsa, tidak-pernah-kedaluwarsa dan penyebaran kata sandi teks biasa menjadi tertahan.

Microsoft juga menunjukkan bahwa konfigurasi yang memakai akun domain untuk layanan menelan upaya operasi yang cukup besar untuk pengelolaan manual kata sandi dan SPN, dan pemeliharaan dapat berujung pada penghentian layanan.¹

7.2. Kerberoasting — akun layanan menjadi sasaran

Serangan lain yang khas pada akun layanan pengguna domain adalah Kerberoasting. Layanan yang menerima autentikasi Kerberos mendaftarkan SPN (service principal name) pada akun eksekusi. Karena sembarang pengguna terautentikasi di domain dapat meminta service ticket ke akun yang SPN-nya terdaftar, penyerang mengambil tiket lalu mencoba brute-force kata sandi secara offline. Kata sandi 10–16 karakter yang ditentukan manusia tidak tahan terhadap serangan ini.

flowchart TB
    accTitle: Alur Kerberoasting
    accDescr: Service ticket ke akun layanan yang SPN-nya terdaftar dapat diminta sembarang pengguna terautentikasi, jadi penyerang mengambil tiket lalu mencoba brute-force kata sandi secara offline
    atk["Pengguna terautentikasi di domain"] --> req["Permintaan tiket ke SPN"]
    req --> tkt["Mengambil service ticket"]
    tkt --> brute["Brute-force secara offline"]
    brute --> weak["Sekitar 10–16 karakter akan dipecahkan"]

Gambar 13: Sembarang pengguna terautentikasi dapat meminta tiket, dan kata sandi sepanjang yang ditentukan manusia tidak tahan brute-force offline.

Mitigasi yang efektif adalah membuat kata sandi sekuat yang tidak dapat ditebak atau dipecahkan manusia. Microsoft juga menyebutkan memaksa kata sandi panjang dan memakai gMSA, yang kata sandinya menjadi nilai acak panjang yang dihasilkan mesin.⁸ Dokumen yang sama juga menyinggung Kerberos armoring (FAST), tetapi yang dilindungi FAST adalah data pra-autentikasi dan ketahanan terhadap peniruan KDC; permintaan service ticket ke SPN oleh pengguna terautentikasi itu sendiri tidak dicegah, jadi FAST bukan pengganti kekuatan kata sandi akun layanan. Hubungan SPN dan Kerberos, serta kondisi autentikasi jatuh ke NTLM, diilustrasikan di “NTLM dan Kerberos dijelaskan dengan diagram”.

7.3. Jika tetap memakai pengguna domain

Jika terpaksa memakai pengguna domain karena aplikasi tidak mendukung gMSA dan sejenisnya, jadikan berikut sebagai mitigasi minimum.

• Kata sandi acak 25 karakter atau lebih, dan jangan tulis di luar alat pengelola kata sandi (runbook, skrip, Excel bersama)
• Jadikan akun khusus layanan, dan pisahkan per layanan (jangan dipakai bersama akun manusia²)
• Tolak logon interaktif dan Remote Desktop, dan hanya izinkan “Log on as a service”
• Minimalkan grup keanggotaan (menambah ke Domain Admins di luar pembahasan)
• Tata prosedur rotasi berkala, dan buat daftar tempat yang terdampak perubahan

Melakukan semua ini lebih tidak aman dan lebih merepotkan daripada bermigrasi ke gMSA — itu bab berikutnya.

8. gMSA — serahkan pengelolaan kata sandi kepada Active Directory

8.1. Mekanisme dan efek

gMSA (group Managed Service Account) adalah akun domain yang menyerahkan pengelolaan kata sandi kepada pengontrol domain. Kata sandi dihitung pengontrol domain dari root key KDS (Key Distribution Service), dan hanya host yang diizinkan yang mengambilnya.¹³

flowchart TB
    accTitle: Mekanisme pengelolaan kata sandi gMSA
    accDescr: Pengontrol domain menghitung kata sandi dari root key KDS, hanya host yang diizinkan yang mengambilnya untuk menjalankan layanan, dan kata sandi dirutasi otomatis setiap 30 hari secara default
    kds["KDS root key"] --> dc["DC menghitung kata sandi"]
    dc --> host["Host yang diizinkan mengambil"]
    host --> svc["Dipakai untuk menjalankan layanan"]
    dc -.-> rot["Rotasi otomatis setiap 30 hari secara default"]

Gambar 14: Pengontrol domain yang menanggung pembuatan, distribusi, dan pembaruan kata sandi, sehingga operasi berjalan tanpa manusia mengetahui kata sandi.

Efeknya jelas.⁹

• Kata sandi acak 240 byte: brute-force dan serangan kamus menjadi tidak realistis, dan ketahanan Kerberoasting naik jauh
• Rotasi otomatis setiap 30 hari secara default: manusia tidak perlu merencanakan perubahan, dan layanan tidak perlu dihentikan
• Identitas yang sama dapat dibagi di beberapa server: farm server di bawah load balancing pun dapat saling mengautentikasi sebagai prinsipal yang sama
• Pengelolaan SPN lebih sederhana: pendaftaran dan pengelolaan SPN juga dapat didelegasikan dan disederhanakan

Manusia dapat beroperasi tanpa mengetahui kata sandi — jika diposisikan sebagai mekanisme yang melakukan terhadap akun layanan apa yang dilakukan Windows LAPS terhadap kata sandi administrator lokal, letaknya mudah dipahami.

8.2. Persyaratan

gMSA punya prasyarat.¹⁰

• Lingkungan domain Active Directory (workgroup tidak bisa)
• Tingkat fungsional domain dan forest Windows Server 2012 atau lebih tinggi
• KDS root key sudah dibuat
• Nama gMSA unik di dalam forest, bukan hanya domain
• Interval perubahan kata sandi hanya dapat diatur saat pembuatan

Pembuatan KDS root key adalah pekerjaan sekali, tetapi hingga 10 jam setelah pembuatan, gMSA tidak dapat dibuat karena menunggu replikasi ke semua pengontrol domain. Ini pengaman agar pengambilan kata sandi tidak gagal sebelum replikasi selesai.¹⁴

flowchart TB
    accTitle: Dari pembuatan KDS root key sampai pembuatan gMSA
    accDescr: Setelah KDS root key dibuat, hingga 10 jam gMSA tidak dapat dibuat karena menunggu replikasi ke semua pengontrol domain; setelah replikasi selesai baru dapat dibuat
    add["Buat KDS root key"] --> wait["Tunggu replikasi hingga 10 jam"]
    wait -.-> why["Pengaman agar gagal ambil tidak terjadi"]
    wait --> done["Replikasi ke semua DC selesai"]
    done --> ok["gMSA dapat dibuat"]

Gambar 15: Hingga 10 jam setelah root key dibuat adalah waktu tunggu untuk mencegah gagal ambil sebelum replikasi selesai.

# Jalankan sebagai administrator domain, di pengontrol domain (atau terminal
# administrasi yang punya modul AD PowerShell)

# Periksa ada-tidaknya KDS root key, dan buat jika belum ada (sekali per forest)
Get-KdsRootKey
Add-KdsRootKey -EffectiveImmediately   # Baru dapat dipakai hingga 10 jam kemudian

8.3. Prosedur dari pembuatan sampai pengaturan

Prosedurnya empat tahap: “① buat grup yang diizinkan mengambil → ② buat gMSA → ③ instal di server → ④ atur ke layanan”.¹⁰

flowchart TB
    accTitle: Empat tahap pengenalan gMSA
    accDescr: Pengenalan dalam empat tahap: membuat grup yang diizinkan mengambil kata sandi, membuat gMSA, menginstal di setiap server, dan mengatur ke akun eksekusi layanan
    st1["① Buat grup yang diizinkan mengambil"] --> st2["② Buat gMSA"]
    st1 -.-> add["Tambahkan PC$ server"]
    st2 --> st3["③ Instal di setiap server"]
    st3 -.-> test["Validasi pengambilan dengan perintah Test"]
    st3 --> st4["④ Atur ke layanan"]

Gambar 16: Dari pembuatan grup sampai pengaturan layanan, pengenalan gMSA maju dalam empat tahap.

# ① Buat grup keamanan yang diizinkan mengambil kata sandi,
#    lalu tambahkan akun komputer server yang menjalankan layanan
New-ADGroup -Name "GG-SvcBatchHosts" -GroupScope Global
Add-ADGroupMember -Identity "GG-SvcBatchHosts" -Members "APPSV01$", "APPSV02$"
# Keanggotaan grup dievaluasi saat komputer logon,
# jadi setelah ditambah, me-restart server sasaran lebih pasti

# ② Buat gMSA
New-ADServiceAccount -Name "svc-batch" `
    -DNSHostName "svc-batch.corp.example.com" `
    -PrincipalsAllowedToRetrieveManagedPassword "GG-SvcBatchHosts"

# ③ Di setiap server yang menjalankan layanan, instal gMSA lalu validasi
Install-ADServiceAccount -Identity "svc-batch"
Test-ADServiceAccount -Identity "svc-batch"   # True berarti pengambilan berhasil

# ④ Atur sebagai akun eksekusi layanan. Tambahkan $ di akhir nama, jangan tentukan kata sandi
sc.exe config MyBatchService obj= "CORP\svc-batch$"
Restart-Service MyBatchService

Jika diatur dari services.msc, nama akun seperti CORP\svc-batch$ — tambahkan $ di akhir, dan biarkan kolom kata sandi kosong. Akun jenis MSA tidak dapat dipakai untuk masuk interaktif.¹ Setelah itu, beri CORP\svc-batch$ pada ACL folder berbagi atau SQL Server sebagai ganti PC$, maka akses jaringan dengan identitas khusus layanan selesai tanpa kata sandi.

8.4. Ada aplikasi yang tidak mendukung

Perhatian: tidak semua perangkat lunak berjalan sebagai gMSA. Windows Service, kumpulan aplikasi IIS, tugas Task Scheduler, dan sejenisnya yang mengonfigurasi identitas logon dengan mekanisme standar secara luas mendukung, tetapi ada batasan seperti Failover Clustering sendiri yang tidak mendukung gMSA, dan jika aplikasi secara internal meminta kata sandi maka tidak dapat dipakai.¹⁰ Microsoft juga menyatakan secara eksplisit untuk mengonfirmasi perilaku sebagai gMSA di lingkungan uji sebelum produksi.⁹

flowchart TB
    accTitle: Menilai apakah mendukung gMSA
    accDescr: Aplikasi yang mengonfigurasi identitas logon dengan mekanisme standar secara luas mendukung gMSA, tetapi Failover Clustering dan aplikasi yang secara internal meminta kata sandi tidak dapat memakainya, jadi konfirmasi di lingkungan uji sebelum produksi
    app["Aplikasi yang ingin dipakai"] --> how{"Cara konfigurasi logon?"}
    how -->|Mekanisme standar| okapp["Mendukung gMSA"]
    okapp -.-> ex1["Layanan, IIS, tugas, dll."]
    how -->|Meminta kata sandi| ngapp["gMSA tidak bisa"]
    ngapp -.-> ex2["Failover cluster, dll."]
    okapp --> test["Konfirmasi di lingkungan uji sebelum produksi"]

Gambar 17: Aplikasi yang mengonfigurasi logon dengan mekanisme standar secara luas mendukung, tetapi ada rancangan yang tidak mendukung, jadi validasi sebelum produksi tidak bisa diabaikan.

Selain itu ada saudara: sMSA (standalone Managed Service Account) untuk satu server, dan dMSA (delegated Managed Service Account, diperkenalkan di Windows Server 2025; menautkan ke identitas perangkat untuk menahan pencurian kredensial). Untuk rancangan baru, jadikan gMSA sebagai dasar dan pertimbangkan sesuai persyaratan.⁶

9. Desain yang menyertai — hak logon, profil, DPAPI, audit

Empat hal lagi yang berubah bersama akun perlu dikuasai.

9.1. Hak “Log on as a service” (SeServiceLogonRight)

Untuk mulai sebagai layanan, akun membutuhkan hak pengguna “Log on as a service”. LocalSystem, LocalService, dan NetworkService memilikinya secara built-in, tetapi akun lain (pengguna domain, gMSA, dll.) membutuhkan penetapan eksplisit.¹⁵

Jika diatur dari tab “Log on” GUI services.msc, snap-in memberikan hak ini secara otomatis. Di sisi lain, CreateService/ChangeServiceConfig (API yang dipanggil sc.exe config) tidak memverifikasi apakah akun yang ditentukan memegang hak ini. Penyebab khas layanan yang dikonfigurasi skrip berhenti saat mulai dengan “Logon failure” adalah ini. Jangan andalkan efek samping alat; masukkan secara eksplisit ke prosedur deploy penambahan ke “Log on as a service” di Local Security Policy (secpol.msc), atau konfigurasi lewat GPO/Intune (di lingkungan yang mengonfigurasi hak ini dengan Group Policy, perlu diperhatikan bahwa pemberian lokal ditimpa saat kebijakan diterapkan). Sebaliknya, untuk akun khusus layanan, “Deny log on locally” juga diatur bersama sebagai praktik standar.

flowchart TB
    accTitle: Perbedaan menurut jalur konfigurasi hak "Log on as a service"
    accDescr: GUI services.msc memberikan hak secara otomatis, tetapi API yang dipanggil sc.exe config tidak memverifikasi hak, jadi akun tanpa hak membuat layanan berhenti karena gagal logon saat mulai
    gui["Diatur di services.msc"] --> auto["Hak diberikan otomatis"]
    auto --> okgui["Layanan dapat mulai"]
    cli["Diatur dengan sc.exe config"] --> noval["Hak tidak diverifikasi"]
    noval --> has{"Memegang hak?"}
    has -->|Ya| okcli["Layanan dapat mulai"]
    has -->|Tidak| stop["Berhenti karena gagal logon"]
    stop -.-> fix["Berikan secara eksplisit lewat secpol.msc atau GPO"]

Gambar 18: GUI memberikan hak otomatis, tetapi konfigurasi skrip tidak memverifikasi, jadi pemberian eksplisit perlu dimasukkan ke prosedur.

9.2. Profil, %TEMP%, dan HKEY_CURRENT_USER berubah

SCM memuat profil pengguna akun itu saat layanan mulai.⁷ Artinya, wujud %TEMP%, %APPDATA%, dan HKEY_CURRENT_USER berbeda per akun eksekusi; jika akun diganti, pengaturan dan cache yang tersimpan di profil akun lama tampak “hilang”.

Mitigasi desainnya sederhana: letakkan data layanan bukan di bawah profil, melainkan di jalur eksplisit seperti C:\ProgramData\<nama-aplikasi>, dan berikan ACL-nya kepada akun eksekusi. Dengan itu, penggantian akun tidak disertai migrasi data.

flowchart TB
    accTitle: Ketergantungan profil dan mitigasi penempatan data
    accDescr: Wujud profil berbeda per akun eksekusi, jadi mengganti akun membuat data profil lama tampak hilang; jika data diletakkan di jalur eksplisit dan ACL diberikan, migrasi tidak diperlukan
    sw["Penggantian akun eksekusi"] --> newprof["Memuat profil lain"]
    newprof --> lost["Data lama tampak hilang"]
    lost -.->|Mitigasi| fix["Tempatkan di bawah ProgramData"]
    fix --> acl["Berikan ACL kepada akun eksekusi"]
    acl --> nomig["Penggantian akun pun tanpa migrasi"]

Gambar 19: Jika data diletakkan di jalur eksplisit, bukan di bawah profil, penggantian akun tidak disertai migrasi data.

9.3. Data yang dilindungi DPAPI sepenanggungan dengan akun

Yang lebih sering terlewat adalah DPAPI. Data yang dienkripsi dengan DPAPI lingkup pengguna (CryptProtectData atau ProtectedData .NET) pada prinsipnya hanya dapat didekripsi oleh akun yang sama saat dilindungi. Begitu akun diganti, connection string dan kunci API yang tersimpan tidak dapat dibaca — itu DPAPI yang bekerja dengan benar, tetapi menjadi gangguan jika tidak masuk prosedur migrasi.

flowchart TB
    accTitle: Hubungan data terlindungi DPAPI dan penggantian akun
    accDescr: Data yang dilindungi DPAPI lingkup pengguna hanya dapat didekripsi oleh akun yang sama saat dilindungi, jadi setelah akun eksekusi diganti, rahasia perlu dimasukkan ulang
    protect["Dilindungi DPAPI oleh akun lama"] --> data["Connection string dll. yang sudah dilindungi"]
    data --> who{"Akun yang mendekripsi?"}
    who -->|Akun lama yang sama| okdec["Dapat didekripsi"]
    who -->|Akun baru| ngdec["Tidak dapat didekripsi"]
    ngdec --> re["Masukkan ulang rahasia"]

Gambar 20: Data terlindungi DPAPI sepenanggungan dengan akun saat dilindungi, jadi setelah akun diganti perlu dimasukkan ulang.

Tanggapannya adalah memasukkan prosedur “masukkan ulang rahasia setelah akun diganti” ke rencana migrasi (rancangan tempat penyimpanan ada di “Menyimpan rahasia di aplikasi Windows”). Selain itu, jika konfigurasi cukup dengan Windows integrated authentication lewat gMSA atau PC$, penyimpanan rahasia itu sendiri dapat dihilangkan. Urutan yang benar adalah mempertimbangkan “apakah perlu disimpan” sebelum “di mana disimpan”.

Juga, jika layanan ingin memproses “dengan hak pengguna pemanggil”, jangan kuatkan akun, melainkan pakai impersonation. Ini ada di “Menangani token impersonasi Windows dengan benar”.

9.4. Audit — lihat logon type 5 pada 4624

Mulainya layanan dicatat di log Security sebagai event ID 4624 (An account was successfully logged on) dengan logon type 5 (Service: SCM memulai layanan). Bidang “Virtual Account” dalam peristiwa menunjukkan apakah logon oleh MSA/akun virtual, jadi dapat dipakai juga untuk mengawasi pemakaian akun terkelola.¹¹

flowchart TB
    accTitle: Alur audit mulai layanan
    accDescr: Mulainya layanan oleh SCM dicatat sebagai event ID 4624 logon type 5, dan bidang Virtual Account dapat mengidentifikasi apakah logon oleh akun terkelola
    start["SCM memulai layanan"] --> ev["Mencatat event ID 4624"]
    ev --> type5["Logon type 5 (Service)"]
    type5 --> vafield["Bidang Virtual Account"]
    vafield --> watch["Pengawasan akun terkelola"]

Gambar 21: Mulainya layanan dicatat sebagai 4624 logon type 5, dan pemakaian akun terkelola pun dapat dilacak.

Untuk inventaris keadaan saat ini, cara cepat adalah mengagregasi akun eksekusi pada daftar layanan.

# Agregasi layanan mana yang berjalan sebagai akun mana
Get-CimInstance Win32_Service |
    Group-Object StartName |
    Sort-Object Count -Descending |
    Select-Object Count, Name

# Inventarisasi layanan nonstandar yang berjalan sebagai LocalSystem (bedakan buatan sendiri/pihak ketiga dari jalur)
Get-CimInstance Win32_Service |
    Where-Object { $_.StartName -eq 'LocalSystem' -and $_.PathName -notlike '*\Windows\*' } |
    Select-Object Name, DisplayName, PathName

Jika keluaran ini berjajar “layanan bisnis yang berjalan sebagai LocalSystem” dan “layanan yang berjalan sebagai pengguna domain”, saatnya alur keputusan bab berikutnya.

10. Alur keputusan — tentukan dengan empat pertanyaan

Isi sampai di sini dirangkum sebagai prosedur pemilihan. Jawab empat pertanyaan secara berurutan.

flowchart TB
    accTitle: Alur keputusan akun eksekusi
    accDescr: Tentukan akun eksekusi dengan menjawab berurutan empat pertanyaan: ada-tidaknya akses jaringan, bergabung ke domain, apakah identitas per mesin cukup, dan dukungan gMSA
    q1{"Menyambung ke mesin lain dengan autentikasi Windows?"} -->|Tidak| va["Akun virtual"]
    va -.-> sys["Jika hak istimewa wajib, LocalSystem"]
    q1 -->|Ya| q2{"Bergabung ke domain?"}
    q2 -->|Tidak| cred["Lindungi dan simpan kredensial"]
    q2 -->|Ya| q3{"Identitas per mesin cukup?"}
    q3 -->|Ya| pcacl["Akun virtual + izinkan PC$"]
    q3 -->|Tidak| q4{"Aplikasi mendukung gMSA?"}
    q4 -->|Ya| gmsa["gMSA"]
    q4 -->|Tidak| du["Pengguna khusus + mitigasi"]

Gambar 22: Jika empat pertanyaan dijawab berurutan, mana dari enam pilihan yang harus dipakai menjadi jelas.

Pertanyaan 1: Apakah layanan itu mengakses mesin lain di jaringan (folder berbagi, DB, API, dll.) dengan autentikasi Windows?

Jika tidak, akun virtual adalah default. Hanya jika hak lokal khusus diperlukan, pertimbangkan LocalSystem setelah mengonfirmasi keperluan itu.

Pertanyaan 2: (Jika mengakses) Apakah mesin bergabung ke domain?

Jika workgroup, PC$ maupun gMSA tidak dapat dipakai. Rancang penanganan kredensial akun tujuan secara eksplisit (simpan dilindungi DPAPI dll.), atau pertimbangkan bergabung ke domain.

Pertanyaan 3: (Jika domain) Apakah identitas per mesin (PC$) cukup?

Jika cukup, selesai dengan akun virtual (atau NetworkService) + pemberian PC$ pada ACL tujuan. Jika identitas khusus layanan, atau identitas bersama di beberapa server, dibutuhkan, lanjut ke pertanyaan 4.

Pertanyaan 4: Apakah aplikasi mendukung gMSA?

Jika mendukung (SCM, kumpulan aplikasi IIS, Task Scheduler, dll. yang mengonfigurasi logon dengan mekanisme standar umumnya mendukung), gMSA. Jangan lupa konfirmasi perilaku di lingkungan uji. Jika benar-benar tidak mendukung, pakai pengguna domain khusus setelah menerapkan semua mitigasi di pasal 7.3.

Dalam tabel, sebagai berikut.

11. Ringkasan

• Akun yang menjalankan layanan adalah keputusan desain yang sekaligus memutuskan hak lokal, identitas jaringan, dan pengelolaan kata sandi. Jangan biarkan pada default (LocalSystem).
• LocalSystem memegang token SYSTEM+Administrators dan hak kuat, dan kerusakan ketika diambil alih dimaksimalkan. Sebagian besar layanan bisnis tidak membutuhkan hak ini.
• LocalService dan NetworkService keduanya berhak rendah; perbedaannya adalah identitas jaringan (anonim, atau akun komputer). Karena akun dibagi oleh beberapa layanan, mereka tidak dapat dipisah.
• Akun virtual (NT SERVICE\) adalah default modern yang memisahkan per layanan tanpa pengelolaan kata sandi. Dapat ditulis langsung pada ACL, dan konfigurasinya hanya mengganti nama akun logon.
• LocalSystem, NetworkService, dan akun virtual keluar ke jaringan sebagai DOMAIN\PC$ di lingkungan domain. Memberi PC$ pada ACL folder berbagi atau SQL Server sering memungkinkan tidak memakai pengguna domain.
• Memakai pengguna domain untuk layanan punya masalah struktural: berhenti karena kedaluwarsa, penyebaran kata sandi teks biasa, dan Kerberoasting. Jika memakainya, akun khusus + kata sandi acak panjang + pembatasan logon wajib.
• gMSA adalah mekanisme di mana AD menghasilkan dan merotasi kata sandi secara otomatis; persyaratannya adalah domain, tingkat fungsional 2012 atau lebih tinggi, dan KDS root key. Atur layanan ke “DOMAIN\nama$” dengan kolom kata sandi kosong.
• Ketika akun diganti, masukkan hak “Log on as a service”, perpindahan profil dan %TEMP%, dan memasukkan ulang data yang dilindungi DPAPI ke prosedur migrasi. Audit dapat dikonfirmasi dengan event ID 4624 logon type 5.

Lain kali layanan dipasang, berhenti sejenak di layar pengaturan logon dan tanyakan ini lagi. Sebagai siapa, dan sejauh mana, layanan ini harus dapat mengakses? Jawabannya mestinya suatu baris dari tabel keputusan artikel ini.

Artikel terkait

• Cara membangun dan mengoperasikan layanan Windows — dari memilih antara Task Scheduler dan layanan hingga menjadikan BackgroundService sebagai layanan
• Kapan hak administrator Windows benar-benar diperlukan - UAC, area terlindungi, dan cara membedakan menurut desain
• Menangani token impersonasi Windows dengan benar — meminjam hak per utas dan mengembalikan dengan aman
• NTLM dan Kerberos dijelaskan dengan diagram — mengapa autentikasi “jatuh” ke NTLM
• Panduan praktis Windows LAPS — menghentikan kata sandi administrator lokal yang sama di seluruh PC
• Menyimpan rahasia di aplikasi Windows - menghindari pengaturan teks biasa dengan DPAPI

Area konsultasi terkait

KomuraSoft LLC menangani rancangan akun eksekusi dan pengerasan hak minimum untuk layanan Windows dan aplikasi residen, migrasi layanan yang ada yang dibangun dengan asumsi LocalSystem ke akun virtual atau gMSA, serta investigasi gangguan yang disebabkan access denied, DPAPI, dan profil setelah penggantian akun. Memulai dari tahap “ditandai dalam audit, tetapi tidak tahu dari mana mulai” tidak apa-apa.

• Pengembangan aplikasi Windows
• Investigasi bug dan analisis penyebab
• Konsultasi teknis dan tinjauan desain
• Hubungi kami

Tautan referensi

Artikel terkait

Artikel terbaru dengan tag yang sama untuk mendalami topik-topik terdekat.

Topik terkait

Halaman-halaman ini menempatkan topik dalam konteks layanan dan keputusan yang lebih luas.

Layanan yang terkait dengan topik ini

Artikel ini berkaitan langsung dengan layanan berikut.

Pertanyaan yang sering diajukan

Pertanyaan yang sering muncul dalam konsultasi tentang topik artikel ini.

Layanan yang selama ini dijalankan sebagai LocalSystem, apakah harus segera diganti?

Perubahan segera tidak selalu jawaban yang tepat untuk semua kasus. Pertama periksa apakah layanan itu benar-benar membutuhkan hak lokal setara LocalSystem (hak istimewa yang lebih kuat daripada administrator). Jika hanya baca/tulis berkas dan komunikasi jaringan, kandidat pertama adalah pindah ke akun virtual (NT SERVICE\nama-layanan). Saat migrasi, konfirmasikan pemberian izin ke folder dan registri yang diperlukan, penanganan data yang bergantung pada profil atau DPAPI, dan ada-tidaknya hak "Log on as a service". Pastikan mulai dan fungsi utama di lingkungan uji, baru kemudian alihkan produksi.

Mana yang harus dipilih, akun virtual atau NetworkService?

Untuk pilihan baru, akun virtual lebih disarankan. Di jaringan, keduanya tampil sebagai akun komputer (DOMAIN\nama-komputer$), dan hak lokal keduanya juga kecil. Namun NetworkService dipakai bersama oleh beberapa layanan, sehingga pemisahan lewat ACL "hanya izinkan layanan ini" tidak bisa dilakukan. Akun virtual punya identitas unik per layanan, dan NT SERVICE\nama-layanan dapat ditulis langsung pada ACL. Produk Microsoft mutakhir seperti SQL Server juga memakai akun virtual sebagai default.

Bisakah gMSA dipakai di lingkungan workgroup (tanpa domain)?

Tidak. gMSA adalah mekanisme di mana pengontrol domain Active Directory menghasilkan dan mengelola kata sandi; prasyaratnya adalah domain plus pembuatan KDS root key. Di lingkungan workgroup, dasarnya adalah menyelesaikan pemrosesan lokal dengan akun virtual atau LocalService/NetworkService. Jika perlu mengakses mesin lain, dibutuhkan rancangan lain, misalnya memakai kredensial akun yang disiapkan di tujuan secara eksplisit. Akses jaringan sebagai akun komputer (PC$) juga hanya berlaku di lingkungan domain.

Setelah akun logon layanan diganti, pengaturan dan kredensial yang tersimpan tidak bisa dibaca. Mengapa?

Karena setiap akun logon terikat pada profil pengguna, %TEMP%, HKEY_CURRENT_USER, dan kunci DPAPI-nya sendiri. Khususnya, data yang dilindungi dengan DPAPI lingkup pengguna (CryptProtectData dan sejenisnya) pada prinsipnya hanya dapat didekripsi oleh akun yang sama yang melindunginya. Berkas yang disimpan di bawah profil (AppData dan sejenisnya) juga menjadi jalur lain bagi akun baru. Sebelum mengganti akun, rencanakan prosedur membuat ulang data yang dilindungi DPAPI (memasukkan ulang kunci API dan sejenisnya) dan memigrasikan berkas di bawah profil.

Jika layanan hanya perlu mengakses folder berbagi, apakah pengguna domain diperlukan?

Dalam banyak kasus, tidak. Di lingkungan domain, layanan yang berjalan sebagai LocalSystem, NetworkService, atau akun virtual mengautentikasi ke sisi jarak jauh sebagai akun komputer (DOMAIN\nama-komputer$). Tambahkan PC$ itu ke izin berbagi dan izin NTFS folder berbagi, maka baca/tulis bisa dilakukan. Jika kontrol akses dengan identitas khusus layanan dibutuhkan, atau identitas yang sama di beberapa server, pertimbangkan gMSA, bukan pengguna domain.

Profil penulis

Halaman perkenalan penulis artikel.

Go Komura

Direktur KomuraSoft LLC

Berspesialisasi dalam pengembangan perangkat lunak Windows, konsultasi teknis, dan investigasi bug, terutama pada proyek dengan sistem yang sudah ada dan bug yang sulit direproduksi.