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

“Layanan internal yang selama ini kami jalankan sebagai LocalSystem ditandai dalam audit keamanan sebagai ‘hak berlebih’. Harus kami ganti ke apa?” “Layanan tidak dapat mengakses folder bersama, jadi kami menjalankannya sebagai pengguna domain. Ketika katasandi kedaluwarsa layanan berhenti, jadi kami membuatnya tidak pernah kedaluwarsa dan menulisnya dalam teks biasa di runbook.” — Di antara konsultasi seputar layanan Windows pelanggan, dua ini adalah yang paling sering.

Yang sama di kedua lapangan adalah bahwa akun logon layanan dibekukan sebagai “pengaturan yang kebetulan berhasil”, bukan sebagai keputusan desain. Layanan Windows selalu berjalan dalam konteks keamanan suatu akun, dan akun itu memutuskan seluruhnya apa yang dapat dilakukannya secara lokal, sebagai siapa ia tampil dari sisi jauh jaringan, dan siapa yang mengelola katasandi. Biarkan ini pada bawaan dan kerentanan di satu layanan langsung menjadi pengambilalihan seluruh mesin, dan katasandi teks biasa bertebaran ke runbook dan skrip.

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

Gambar 1: Memilih akun logon adalah keputusan desain yang sekaligus memutuskan hak lokal, identitas jaringan, dan pengelolaan katasandi.

Ada enam pilihan yang efektif — LocalSystem, LocalService, NetworkService, akun virtual (NT SERVICE\), pengguna domain, dan gMSA (group Managed Service Account). Ditujukan kepada staf IT di usaha kecil dan menengah serta pengembang aplikasi Windows, artikel ini merangkai hak, identitas jaringan, dan pengelolaan katasandi 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 logon”, tempat paling banyak terjadi kecelakaan.

1. Kesimpulan lebih 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 karena “berhasil”. Token mencakup SYSTEM dan BUILTIN\Administrators dan memegang hak kuat seperti SeDebugPrivilege, jadi pengambilalihan hampir kehilangan semuanya di mesin itu. Bawaan sc.exe create yang LocalSystem adalah tempat berkembang biaknya kecelakaan 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 bawaan modern yang dapat memisah identitas per layanan sekaligus tidak membutuhkan pengelolaan katasandi.** Anda dapat menuliskan "NT SERVICE\\nama-layanan" langsung pada ACL, dan akun layanan bawaan SQL Server juga ini.[^understand-service-accounts][^sql-service-accounts]
• Ketika LocalSystem, NetworkService, atau akun virtual masuk ke jaringan, ia menjadi akun komputer (DOMAIN\nama-komputer$). Memberi PC$ pada ACL folder bersama atau SQL Server sering memungkinkan Anda tidak memakai pengguna domain.³⁶
• Konfigurasi yang memakai pengguna domain untuk layanan menjadi utang baik pada operasi katasandi maupun Kerberoasting. SCM masuk dengan katasandi 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 katasandi secara otomatis. Persyaratannya adalah domain dan KDS root key, dan Anda mengatur layanan ke “DOMAIN\nama-akun$” dengan kolom katasandi kosong. Beberapa aplikasi tidak mendukungnya, jadi Anda perlu memvalidasi di muka.⁹¹⁰
• 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 logon daftar layanan dan dari event ID 4624 (logon type 5).¹¹

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

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

Satu langkah tinjauan dulu. Saat layanan mulai, Service Control Manager (SCM) masuk sebagai 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 logon 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 sebagai 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 sebagai 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 katasandi sama sekali. Satu-satunya yang masuk dengan katasandi tersimpan di SCM (= kedaluwarsa dan kebocoran mungkin) adalah pengguna domain dan pengguna lokal.⁷³

Di bawah ini kita menggali tabel ini satu baris demi satu baris.

3. Apa yang salah 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 bawaan.³

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 bawaan 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 di layanan LocalSystem membuat penyerang dalam satu napas sampai ke mengambil seluruh mesin dan titik awal pergerakan lateral.

3.2. Mengapa masih dipilih

Alasannya sederhana: itu bawaan, dan access-denied tidak pernah muncul. Bawaan ketika Anda menghilangkan obj= pada sc.exe create adalah LocalSystem,⁴ dan banyak kode sampel lama serta templat pemasang masih mengasumsikan LocalSystem. Karena Anda dapat bebas dari galat hak selama pengembangan, struktur yang memproduksi massal “berhasil, jadi biarkan” ada di situ. Dokumentasi Microsoft sendiri juga menyatakan bahwa sebagian besar layanan tidak membutuhkan tingkat hak setinggi ini, dan bahwa jika Anda tidak membutuhkannya Anda harus mempertimbangkan LocalService atau NetworkService.³

flowchart TB
    accTitle: Struktur yang membuat LocalSystem terus dipilih
    accDescr: Bawaan sc.exe create adalah LocalSystem, dan kode sampel serta templat lama juga mengasumsikan LocalSystem, jadi access-denied tidak muncul selama pengembangan dan konfigurasi berhasil jadi biarkan diproduksi massal
    def["Bawaan sc.exe create"] --> lsys["Dibuat sebagai LocalSystem"]
    old["Sampel dan templat lama"] --> lsys
    lsys --> noerr["Tidak ada access-denied selama pengembangan"]
    noerr --> asis["Berhasil, jadi biarkan"]
    asis --> mass["Layanan dengan hak berlebih diproduksi massal"]

Gambar 4: Bawaan dan pengalaman pengembangan “tidak ada access-denied” memproduksi massal layanan yang dibekukan sebagai LocalSystem.

3.3. Perbedaan dari TrustedInstaller — LocalSystem pun tidak tak terbatas

Menyebut LocalSystem “akun terkuat Windows” tidak akurat. Windows Resource Protection (WRP) sejak Windows Vista mengizinkan perubahan pada berkas sistem OS penting, folder, dan kunci registri hanya kepada TrustedInstaller (layanan Windows Modules Installer), dan bahkan SYSTEM atau administrator mendapat access denied pada penulisan ulang.¹² “Anda memerlukan izin dari TrustedInstaller” di Explorer adalah mekanisme ini. Dibalik, LocalSystem dapat menjangkau hampir semuanya di luar area yang dilindungi WRP, dan biasanya tidak ada alasan memberi itu kepada layanan bisnis.

flowchart TB
    accTitle: Hubungan antara area yang dilindungi WRP dan TrustedInstaller
    accDescr: Perubahan pada berkas sistem penting dan kunci registri yang dilindungi WRP hanya diizinkan kepada TrustedInstaller, dan bahkan SYSTEM atau administrator mendapat access denied
    ti["TrustedInstaller"] -->|Dapat mengubah| wrp["Berkas sistem yang dilindungi WRP dan sejenisnya"]
    sysadm["SYSTEM dan administrator"] -->|Access denied| wrp
    sysadm -->|Hampir semuanya diizinkan| other["Di luar area yang dilindungi WRP"]

Gambar 5: LocalSystem pun tidak tak terbatas; perubahan pada area yang dilindungi WRP hanya diizinkan kepada TrustedInstaller.

3.4. Kasus di mana LocalSystem masuk akal

Yang secara luar biasa masuk akal adalah layanan yang hak yang dibutuhkannya sejak awal melebihi kelas administrator — bekerja erat dengan driver perangkat, mengoperasikan fondasi keamanan OS, mengelola layanan atau sesi lain, dan sejenisnya. Perangkat lunak seperti agen cadangan atau EDR berlaku. Bahkan saat itu, patut dikonfirmasi bahwa ada jalur kode yang benar-benar memakai hak itu, dan mempertimbangkan apakah pekerjaan yang membutuhkan hak dapat dipisah (cara membedakannya, lihat “Kapan Anda benar-benar membutuhkan hak administrator di Windows?”).

4. LocalService dan NetworkService — akun built-in dengan 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 tidak dapat berbuat jauh lebih banyak daripada anggota grup Users.⁵¹

Perbedaan keduanya satu poin: sebagai siapa mereka tampil dari sisi jauh jaringan.⁵

• LocalService: Terhubung ke sisi jarak jauh dengan kredensial anonim. Ia tidak dapat mengakses sumber daya yang membutuhkan autentikasi.
• NetworkService: Menyajikan kredensial komputer ke sisi jarak jauh (di lingkungan domain, DOMAIN\nama-komputer$).

Pemisahannya adalah LocalService jika “tidak masuk ke jaringan, atau jika masuk tidak butuh identitas”, dan NetworkService jika “Anda 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 terhubung dengan kredensial anonim dan NetworkService menyajikan kredensial komputer
    ls["LocalService"] --> anon["Terhubung dengan kredensial anonim"]
    anon -.-> ng["Sumber daya yang membutuhkan autentikasi tidak mungkin"]
    ns["NetworkService"] --> comp["Menyajikan kredensial komputer"]
    comp -.-> pc["Di lingkungan domain tampil sebagai PC$"]

Gambar 6: Hak lokal sama-sama minimum, tetapi identitas yang terlihat dari sisi jauh jaringan terbelah menjadi anonim atau akun komputer.

Namun keduanya punya kelemahan dari sudut pandang modern. Akun yang sama dibagi oleh banyak layanan. Jika lima layanan berjalan sebagai LocalService, selama ACL per-akun, kelimanya dapat mengakses sumber daya satu sama lain. SQL Server tidak mendukung akun Local Service karena alasan yang sama: itu akun bersama dan tidak dapat dipisah dari layanan lain.¹

flowchart TB
    accTitle: Akun bersama tidak dapat dipisah
    accDescr: Jika beberapa layanan berbagi LocalService yang sama, selama ACL per-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 per-akun"]

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

Memecahkan “tetap berhak rendah, tetapi pisah per layanan” adalah topik berikutnya, akun virtual.

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

5.1. Anda dapat punya identitas per layanan tanpa katasandi

Akun virtual adalah “akun lokal terkelola” yang tersedia dari Windows Server 2008 R2 / Windows 7 ke atas. Ada tiga karakteristik.⁶

• Akun dikelola secara otomatis; tidak perlu pembuatan maupun mengatur katasandi
• Namanya NT SERVICE\<nama-layanan>, dan menjadi identitas unik untuk setiap layanan
• Di lingkungan domain, ia dapat mengakses jaringan dengan kredensial akun komputer (DOMAIN\nama-komputer$)

Dengan kata lain, ia mempertahankan kelebihan “tanpa pengelolaan katasandi” LocalService/NetworkService dan menghilangkan kekurangan “tidak dapat dipisah karena akun bersama”. Itu juga mengapa penyiapan SQL Server memakai akun virtual seperti NT SERVICE\MSSQLSERVER sebagai bawaan.¹

flowchart TB
    accTitle: Apa yang dibuat kompatibel oleh akun virtual
    accDescr: Akun virtual mempertahankan kelebihan tanpa-pengelolaan-katasandi LocalService dan NetworkService, menghilangkan kekurangan tidak-dapat-dipisah-karena-bersama, dan punya identitas unik per layanan
    merit["Kelebihan (tanpa pengelolaan katasandi)"] -->|Pertahankan| va["Akun virtual"]
    demerit["Kekurangan (tidak dapat dipisah karena bersama)"] -->|Hilangkan| va
    va --> ident["Identitas unik per layanan"]
    va --> auto["Tidak perlu pembuatan maupun mengatur katasandi"]

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

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

Kenyamanan praktisnya adalah bahwa Anda dapat menambahkan hanya layanan itu ke ACL berdasarkan nama. “Hanya layanan ini yang dapat menulis folder data ini” dapat diwujudkan tanpa membuat grup maupun mengelola katasandi.

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

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

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

Di GUI, di services.msc buka properti layanan → tab “Log On” → masukkan NT SERVICE\nama-layanan di “This account”, dan biarkan kolom katasandi kosong (untuk akun virtual atau MSA, tidak menentukan katasandi adalah spesifikasi SCM). Setelah perubahan, mulai ulang layanan menerapkannya.

5.3. Kendalanya — di luar mesin ia bukan “layanan itu”

Identitas akun virtual bersifat lokal-mesin dan tidak dikenali dari domain. Di jaringan ia runtuh menjadi akun komputer seperti yang dijelaskan nanti, jadi sisi jarak jauh tidak dapat membedakan “layanan yang mana”, dan Anda juga tidak dapat berbagi identitas yang sama di beberapa server.¹⁰

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

Gambar 9: Meski dengan identitas unik di dalam mesin, di sisi jauh jaringan setiap layanan tampil sebagai PC$ yang sama.

Saat kendala ini — membutuhkan identitas khusus layanan di sisi jauh jaringan, membutuhkan identitas yang sama di beberapa server — menjadi masalah adalah saat gMSA (Bab 8) dipanggil.

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

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

Di mesin yang tergabung domain, ketika layanan yang berjalan sebagai LocalSystem, NetworkService, atau akun virtual mengakses sumber daya jarak jauh, ia mengautentikasi sebagai akun komputer (DOMAIN\nama-komputer$).³⁶ Banyak konsultasi pembuka “tidak dapat mengakses folder bersama, jadi kami jadikan pengguna domain” sebenarnya terselesaikan oleh ini. ACL tujuan semata-mata tidak mengizinkan PC$.

flowchart TB
    accTitle: Akses jarak jauh sebagai akun komputer
    accDescr: Layanan LocalSystem, NetworkService, atau akun virtual di mesin yang tergabung domain mengautentikasi ke sisi jarak jauh sebagai akun komputer, dan jika ACL tujuan mengizinkan PC$ ia dapat mengakses
    svc["Layanan (LocalSystem, akun virtual, dan sejenisnya)"] --> auth["Autentikasi sebagai PC$"]
    auth --> acl{"Apakah ACL tujuan mengizinkan PC$?"}
    acl -->|Ya| ok["Akses ke folder bersama atau DB berhasil"]
    acl -->|Tidak| ng["Akses ditolak"]

Gambar 10: Di lingkungan domain, memberi PC$ pada ACL tujuan saja sudah membangun akses jarak jauh tanpa pengguna domain.

Pemberian di sisi server berkas sama dengan operasi ACL biasa; tentukan nama-komputer$ sebagai nama akun (di dialog pemilih objek GUI, sertakan “Computers” dalam tipe objek).

# Di sisi server berkas: beri layanan di APPSV01 hak modify pada folder bersama
# Anda perlu memberi baik izin berbagi maupun 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 dan string koneksi berjalan dengan Integrated Security=true tanpa katasandi.

-- Di sisi server DB: izinkan autentikasi terintegrasi Windows dari layanan di APPSV01
CREATE LOGIN [CORP\APPSV01$] FROM WINDOWS;

6.2. Ketahui batas pendekatan PC$

Pendekatan ini punya dua batas.

1. Granularitas per mesin. LocalSystem, NetworkService, dan setiap layanan akun virtual yang berjalan di mesin yang sama semuanya tampil sebagai PC$ yang sama dari sisi jarak jauh. Anda tidak dapat “hanya mengizinkan layanan ini” di tujuan, dan Anda juga tidak dapat mengaudit layanan mana yang memakai akun itu.²
2. Tidak dapat dipakai di lingkungan workgroup. Akun komputer adalah objek Active Directory, jadi mesin yang tidak tergabung domain tidak memilikinya. Anda butuh desain yang menangani kredensial akun tujuan secara eksplisit.

Ketika Anda ingin melampaui batas 1, jawaban 2026 bukan pengguna domain di bab berikutnya… melainkan melewati masalah itu dan lanjut ke gMSA.

flowchart TB
    accTitle: Dua batas pendekatan PC$
    accDescr: Autentikasi sebagai PC$ punya granularitas tingkat mesin jadi izin maupun audit per-layanan tidak mungkin, dan di lingkungan workgroup akun komputer itu sendiri tidak ada jadi tidak dapat dipakai
    pcs["Pendekatan PC$"] --> lim1["Batas 1: per mesin"]
    pcs --> lim2["Batas 2: tanpa workgroup"]
    lim1 -.-> noaudit["Tidak ada izin maupun audit per-layanan"]
    lim2 -.-> nocred["Pakai kredensial eksplisit"]
    lim1 --> gmsa["Melampaui ini: gMSA"]

Gambar 11: Ketika Anda ingin melampaui dua batas granularitas tingkat mesin dan prasyarat domain, lewati pengguna domain dan lanjut ke gMSA.

7. Masalah memakai pengguna domain untuk layanan

7.1. Masalah struktural katasandi

Jika Anda menetapkan pengguna domain (atau pengguna lokal) ke layanan, SCM menyimpan katasandi itu dan memakainya untuk masuk di setiap mulai. SCM tidak mengelola kedaluwarsa, jadi ketika katasandi kedaluwarsa logon gagal dan layanan tidak akan mulai.⁷

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

1. Kecelakaan layanan berhenti karena kedaluwarsa terjadi
2. Sebagai pencegahan berulang, “katasandi tidak pernah kedaluwarsa” diatur
3. Prosedur perubahan tidak pernah ditetapkan, dan katasandi yang sama ditulis dalam teks biasa ke runbook, skrip, dan Task Scheduler beberapa server
4. Bahkan ketika seseorang pergi, katasandi tidak berubah (jika Anda mengubahnya, Anda tidak tahu apa yang akan berhenti)

flowchart TB
    accTitle: Spiral negatif mengoperasikan dengan pengguna domain
    accDescr: Katasandi kedaluwarsa dan layanan berhenti, tidak-pernah-kedaluwarsa diatur sebagai pencegahan berulang, katasandi teks biasa menyebar ke runbook dan skrip, dan bahkan ketika seseorang pergi ia tidak dapat diubah
    expire["1. Kedaluwarsa menghentikan layanan"] --> forever["2. Tidak-pernah-kedaluwarsa diatur sebagai pencegahan"]
    forever --> spread["3. Katasandi teks biasa menyebar"]
    spread -.-> where["Runbook, skrip, tugas"]
    spread --> stuck["4. Bahkan ketika seseorang pergi, tidak dapat diubah"]

Gambar 12: Dimulai dari kecelakaan kedaluwarsa, tidak-pernah-kedaluwarsa dan penyebaran katasandi teks biasa menjadi tetap.

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

7.2. Kerberoasting — akun layanan menjadi sasaran

Serangan lain yang khusus untuk akun layanan pengguna domain adalah Kerberoasting. Layanan yang menerima autentikasi Kerberos mendaftarkan SPN (service principal name) pada akun logon. Setiap pengguna terautentikasi di domain dapat meminta tiket layanan ke akun yang punya SPN terdaftar, jadi penyerang memperoleh tiket dan mencoba brute-force katasandi secara offline. Katasandi 10-hingga-16 karakter yang diputuskan manusia tidak akan menahan serangan ini.

flowchart TB
    accTitle: Alur Kerberoasting
    accDescr: Tiket layanan ke akun layanan yang punya SPN terdaftar dapat diminta oleh setiap pengguna terautentikasi, jadi penyerang memperoleh tiket dan mencoba brute-force katasandi secara offline
    atk["Pengguna terautentikasi di domain"] --> req["Minta tiket untuk SPN"]
    req --> tkt["Peroleh tiket layanan"]
    tkt --> brute["Brute-force offline"]
    brute --> weak["Sekitar 10 hingga 16 karakter akan dipecahkan"]

Gambar 13: Setiap pengguna terautentikasi dapat meminta tiket, dan katasandi sepanjang yang diputuskan manusia tidak akan menahan brute-force offline.

Respons yang efektif adalah membuat katasandi sekuat yang tidak dapat ditebak atau dipecahkan manusia. Microsoft juga mencantumkan memaksa katasandi panjang, dan memakai gMSA yang katasandinya menjadi nilai acak panjang yang dihasilkan mesin.⁸ Dokumen yang sama juga menyebut Kerberos armoring (FAST), tetapi FAST melindungi data pra-autentikasi dan ketahanan terhadap spoofing KDC; ia tidak mencegah pengguna terautentikasi meminta tiket layanan ke SPN, jadi ia bukan pengganti kekuatan katasandi akun layanan. Hubungan SPN dan Kerberos, serta kondisi di mana autentikasi jatuh ke NTLM, digambarkan di “NTLM dan Kerberos dijelaskan dengan diagram”.

7.3. Jika Anda tetap memakai pengguna domain

Jika Anda terpaksa memakai pengguna domain, misalnya karena aplikasi tidak mendukung gMSA, perlakukan berikut sebagai mitigasi minimum.

• Buat katasandi 25 karakter atau lebih yang dihasilkan acak, dan jangan menulisnya di mana pun selain alat pengelolaan katasandi (runbook, skrip, Excel bersama)
• Jadikan akun khusus layanan dan pisah per layanan (jangan berbagi dengan akun manusia²)
• Tolak logon interaktif dan Remote Desktop, dan izinkan hanya “Log on as a service”
• Minimalkan grup keanggotaannya (menambahkannya ke Domain Admins tidak masuk hitungan)
• Tetapkan prosedur rotasi berkala dan masukkan tempat yang terdampak perubahan ke dalam buku besar

Melakukan semua ini tetap kurang aman dan kurang mudah daripada bermigrasi ke gMSA — itu bab berikutnya.

8. gMSA — menyerahkan pengelolaan katasandi kepada Active Directory

8.1. Mekanisme dan efeknya

gMSA (group Managed Service Account) adalah akun domain yang menyerahkan pengelolaan katasandi kepada pengontrol domain. Katasandi dihitung oleh pengontrol domain dari KDS (Key Distribution Service) root key, dan hanya host yang diizinkan yang memperolehnya.¹³

flowchart TB
    accTitle: Cara gMSA mengelola katasandi
    accDescr: Pengontrol domain menghitung katasandi dari KDS root key, hanya host yang diizinkan yang memperolehnya dan memakainya untuk menjalankan layanan, dan katasandi dirotasi otomatis setiap 30 hari secara bawaan
    kds["KDS root key"] --> dc["DC menghitung katasandi"]
    dc --> host["Host yang diizinkan memperolehnya"]
    host --> svc["Dipakai untuk menjalankan layanan"]
    dc -.-> rot["Rotasi otomatis setiap 30 hari secara bawaan"]

Gambar 14: Pengontrol domain mengambil alih menghasilkan, mendistribusikan, dan memperbarui katasandi, dan manusia dapat beroperasi tanpa mengetahui katasandi.

Efeknya jelas.⁹

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

Manusia dapat beroperasi tanpa mengetahui katasandi — jika Anda memahaminya sebagai mekanisme yang melakukan untuk akun layanan apa yang Windows LAPS lakukan untuk katasandi administrator lokal, penempatannya lebih mudah digenggam.

8.2. Persyaratan

gMSA punya prasyarat.¹⁰

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

Membuat KDS root key adalah tugas sekali, tetapi hingga 10 jam setelah pembuatan Anda tidak dapat membuat gMSA, karena Anda menunggu replikasi ke setiap pengontrol domain. Itu perangkat keselamatan untuk mencegah kecelakaan pengambilan katasandi gagal sebelum replikasi selesai.¹⁴

flowchart TB
    accTitle: Dari membuat KDS root key hingga membuat gMSA
    accDescr: Setelah KDS root key dibuat Anda menunggu replikasi ke setiap pengontrol domain, jadi hingga 10 jam Anda tidak dapat membuat gMSA; setelah replikasi selesai Anda dapat membuatnya
    add["Buat KDS root key"] --> wait["Hingga 10 jam menunggu replikasi"]
    wait -.-> why["Perangkat keselamatan untuk mencegah kecelakaan kegagalan pengambilan"]
    wait --> done["Replikasi ke setiap DC telah selesai"]
    done --> ok["Anda dapat membuat gMSA"]

Gambar 15: Tunggu hingga 10 jam setelah membuat root key adalah waktu tunggu untuk mencegah kegagalan pengambilan sementara replikasi belum selesai.

# Jalankan sebagai administrator domain, di pengontrol domain (atau stasiun kerja
# administratif dengan modul AD PowerShell)

# Konfirmasikan apakah KDS root key ada, dan buat jika belum (sekali per forest)
Get-KdsRootKey
Add-KdsRootKey -EffectiveImmediately   # Sebenarnya dapat dipakai setelah hingga 10 jam

8.3. Prosedur dari pembuatan hingga konfigurasi

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

flowchart TB
    accTitle: Empat tahap memperkenalkan gMSA
    accDescr: Perkenalkan dalam empat tahap: membuat grup yang diizinkan mengambil katasandi, membuat gMSA, menginstalnya di setiap server, dan mengaturnya sebagai akun logon 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 di layanan"]

Gambar 16: Dari membuat grup hingga mengatur layanan, memperkenalkan gMSA berjalan dalam empat tahap.

# ① Buat grup keamanan yang diizinkan mengambil katasandi,
#    dan tambahkan akun komputer server yang akan menjalankan layanan
New-ADGroup -Name "GG-SvcBatchHosts" -GroupScope Global
Add-ADGroupMember -Identity "GG-SvcBatchHosts" -Members "APPSV01$", "APPSV02$"
# Keanggotaan grup dievaluasi saat logon komputer, jadi
# memulai ulang server target setelah menambahkan adalah pendekatan yang andal

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

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

# ④ Atur sebagai akun logon layanan. Tambahkan $ ke nama, dan jangan tentukan katasandi
sc.exe config MyBatchService obj= "CORP\svc-batch$"
Restart-Service MyBatchService

Ketika mengatur dari services.msc juga, nama akun seperti CORP\svc-batch$ — tambahkan $ di akhir, dan biarkan kolom katasandi kosong. Akun keluarga MSA tidak dapat dipakai untuk masuk interaktif.¹ Setelah itu, beri CORP\svc-batch$ pada ACL folder bersama atau SQL Server sebagai pengganti PC$, dan akses jaringan dengan identitas khusus layanan selesai, tanpa katasandi.

8.4. Beberapa aplikasi tidak mendukungnya

Sebagai peringatan, tidak setiap perangkat lunak akan berjalan sebagai gMSA. Hal yang mengonfigurasi identitas logon lewat mekanisme standar — layanan Windows, kumpulan aplikasi IIS, tugas Task Scheduler — didukung secara luas, tetapi ada kendala seperti failover clustering sendiri tidak mendukung gMSA, dan aplikasi yang bagian dalamnya menuntut katasandi tidak dapat memakainya.¹⁰ Microsoft juga menyatakan dengan gamblang bahwa Anda harus mengonfirmasi perilaku sebagai gMSA di lingkungan uji sebelum produksi.⁹

flowchart TB
    accTitle: Membedakan apakah sesuatu mendukung gMSA
    accDescr: Aplikasi yang mengonfigurasi identitas logon lewat mekanisme standar secara luas mendukung gMSA, tetapi failover clustering dan aplikasi yang bagian dalamnya menuntut katasandi tidak dapat memakainya, jadi konfirmasikan di lingkungan uji sebelum produksi
    app["Aplikasi target"] --> how{"Bagaimana logon diatur?"}
    how -->|Mekanisme standar| okapp["gMSA didukung"]
    okapp -.-> ex1["Layanan, IIS, tugas"]
    how -->|Katasandi dituntut| ngapp["gMSA tidak mungkin"]
    ngapp -.-> ex2["Failover clustering"]
    okapp --> test["Uji sebelum produksi"]

Gambar 17: Aplikasi yang mengonfigurasi logon lewat mekanisme standar didukung secara luas, tetapi beberapa desain tidak didukung, jadi validasi sebelum produksi tak tergantikan.

Ada juga saudara: sMSA (standalone Managed Service Account) untuk satu server, dan dMSA (delegated Managed Service Account, diperkenalkan di Windows Server 2025, yang terikat pada identitas perangkat untuk menahan pencurian kredensial). Untuk pembangunan baru, ambil gMSA sebagai dasar dan pertimbangkan sesuai persyaratan.⁶

9. Desain pendamping — hak logon, profil, DPAPI, dan audit

Empat hal lagi yang berubah bersama akun, untuk diingat.

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, dan sejenisnya) membutuhkan penetapan eksplisit.¹⁵

Jika Anda mengaturnya dari tab “Log On” GUI services.msc, snap-in memberi hak ini secara otomatis. Di sisi lain, CreateService / ChangeServiceConfig (API yang dipanggil sc.exe config) tidak memverifikasi bahwa akun yang ditentukan punya hak ini. Penyebab khas layanan yang dikonfigurasi skrip berhenti saat mulai dengan “layanan tidak mulai karena kegagalan logon” adalah ini. Jangan andalkan efek samping alat; masukkan ke prosedur deploy, secara eksplisit, 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, pemberian lokal ditimpa ketika kebijakan diterapkan, jadi itu juga perlu perhatian). Sebaliknya, langkah standar untuk akun khusus layanan adalah mengatur “Deny log on locally” bersama-sama.

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

Gambar 18: GUI memberi hak secara otomatis, tetapi konfigurasi skrip tidak memverifikasinya, jadi Anda perlu memasukkan pemberian eksplisit ke dalam prosedur.

9.2. Profil, %TEMP%, dan HKEY_CURRENT_USER berubah

SCM memuat profil pengguna akun itu saat layanan mulai.⁷ Jadi %TEMP%, %APPDATA%, dan HKEY_CURRENT_USER yang sesungguhnya adalah hal berbeda per akun logon, dan ketika Anda mengganti akun, pengaturan dan cache yang disimpan di profil akun lama tampak seolah “hilang”.

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

flowchart TB
    accTitle: Ketergantungan profil dan respons penempatan data
    accDescr: Profil yang sesungguhnya adalah hal berbeda per akun logon, jadi mengganti akun membuat data profil lama tampak hilang, tetapi menempatkan data di jalur eksplisit dan memberi ACL membuat migrasi tidak perlu
    sw["Mengganti akun logon"] --> newprof["Profil berbeda dimuat"]
    newprof --> lost["Data lama tampak seolah hilang"]
    lost -.->|Respons| fix["Tempatkan di bawah ProgramData"]
    fix --> acl["Beri ACL kepada akun logon"]
    acl --> nomig["Tidak ada migrasi meski akun berubah"]

Gambar 19: Hindari profil dan letakkan data di jalur eksplisit, dan penggantian akun tidak lagi disertai migrasi data.

9.3. Data yang dilindungi DPAPI terikat pada akun

Yang lebih mudah terlewat adalah DPAPI. Data yang dienkripsi dengan DPAPI lingkup pengguna (CryptProtectData atau ProtectedData .NET) pada prinsipnya hanya dapat didekripsi oleh akun yang sama yang melindunginya. Saat Anda mengganti akun, string koneksi atau kunci API yang tersimpan tidak lagi dapat dibaca — itu DPAPI melakukan tugasnya dengan benar, tetapi jika tidak ada di prosedur migrasi ia menjadi insiden.

flowchart TB
    accTitle: Hubungan antara data yang dilindungi DPAPI dan penggantian akun
    accDescr: Data yang dilindungi dengan DPAPI lingkup pengguna hanya dapat didekripsi oleh akun yang sama yang melindunginya, jadi setelah Anda mengganti akun logon Anda perlu memasukkan ulang rahasia
    protect["Lindungi DPAPI dengan akun lama"] --> data["String koneksi yang dilindungi dan sejenisnya"]
    data --> who{"Akun mana 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 yang dilindungi DPAPI terikat pada akun yang melindunginya, dan setelah penggantian akun Anda perlu memasukkan ulang.

Responsnya adalah memasukkan ke rencana migrasi prosedur “masukkan ulang rahasia setelah penggantian akun” (untuk desain di mana menyimpannya, lihat “Menyimpan rahasia di aplikasi Windows”). Juga, konfigurasi yang dapat selesai dengan autentikasi terintegrasi Windows sebagai gMSA atau PC$ dapat menghilangkan penyimpanan rahasia itu sendiri. Urutan yang benar adalah mempertimbangkan “dapatkah kita tidak menyimpannya” sebelum “di mana kita menyimpannya”.

Dan jika layanan ingin memproses “dengan hak pengguna yang memanggil”, Anda memakai impersonation daripada membuat akun lebih kuat. Untuk itu, lihat “Menangani token impersonasi Windows dengan benar”.

9.4. Audit — lihat 4624 logon type 5

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

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

Gambar 21: Mulai layanan dicatat sebagai 4624 logon type 5, dan Anda bahkan dapat melacak penggunaan akun terkelola.

Untuk inventaris keadaan saat ini, mengagregasi akun logon daftar layanan adalah metode cepat.

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

# Inventaris layanan non-standar yang berjalan sebagai LocalSystem (bedakan internal / 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 merangkai “layanan bisnis yang berjalan sebagai LocalSystem” dan “layanan yang berjalan sebagai pengguna domain”, alur keputusan bab berikutnya dipanggil.

10. Alur keputusan — putuskan dengan empat pertanyaan

Berikut isi sejauh ini, sebagai prosedur pemilihan. Jawab empat pertanyaan secara berurutan.

flowchart TB
    accTitle: Alur keputusan akun logon
    accDescr: Putuskan akun logon dengan menjawab secara berurutan empat pertanyaan apakah ada akses jaringan, gabung domain, apakah identitas tingkat mesin cukup, dan dukungan gMSA
    q1{"Win auth ke rekan?"} -->|Tidak| va["Akun virtual"]
    va -.-> sys["LocalSystem jika diperlukan"]
    q1 -->|Ya| q2{"Tergabung domain?"}
    q2 -->|Tidak| cred["Lindungi kredensial tersimpan"]
    q2 -->|Ya| q3{"Tingkat mesin cukup?"}
    q3 -->|Ya| pcacl["Akun virtual + PC$"]
    q3 -->|Tidak| q4{"Aplikasi mendukung gMSA?"}
    q4 -->|Ya| gmsa["gMSA"]
    q4 -->|Tidak| du["Pengguna + mitigasi"]

Gambar 22: Jawab empat pertanyaan secara berurutan dan mana dari enam pilihan yang harus Anda pakai diputuskan.

Pertanyaan 1: Apakah layanan itu mengakses mesin lain di jaringan (folder bersama, DB, API, dan sejenisnya) dengan autentikasi Windows?

Jika tidak, akun virtual adalah bawaan. Hanya jika hak lokal khusus dibutuhkan, konfirmasikan kebutuhan itu lalu pertimbangkan LocalSystem.

Pertanyaan 2: (Jika ia mengakses) Apakah mesin tergabung domain?

Di workgroup, baik PC$ maupun gMSA tidak dapat dipakai. Pakai desain yang menangani kredensial akun tujuan secara eksplisit (lindungi penyimpanan dengan DPAPI atau sejenisnya), atau pertimbangkan bergabung ke domain.

Pertanyaan 3: (Di domain) Apakah identitas tingkat mesin (PC$) cukup?

Jika ya, akun virtual (atau NetworkService) + memberi PC$ pada ACL tujuan selesai. Jika Anda butuh identitas khusus layanan, atau identitas bersama di beberapa server, lanjut ke pertanyaan 4.

Pertanyaan 4: Apakah aplikasi mendukung gMSA?

Jika ya (hal yang mengonfigurasi logon lewat mekanisme standar — SCM, kumpulan aplikasi IIS, Task Scheduler — umumnya ya), gMSA. Jangan lupa pemeriksaan perilaku di lingkungan validasi. Jika tidak didukung bagaimanapun, pakai pengguna domain khusus setelah menerapkan setiap mitigasi di bagian 7.3.

Dalam tabel sebagai berikut.

11. Ringkasan

• Akun logon layanan adalah keputusan desain yang sekaligus memutuskan hak lokal, identitas jaringan, dan pengelolaan katasandi. Jangan biarkan pada bawaan (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 bawaan modern yang dapat memisah per layanan sekaligus tidak membutuhkan pengelolaan katasandi. Anda dapat menuliskannya langsung pada ACL, dan konfigurasi hanya mengganti nama akun logon.
• LocalSystem, NetworkService, dan akun virtual masuk ke jaringan sebagai DOMAIN\PC$ di lingkungan domain. Memberi PC$ pada ACL folder bersama atau SQL Server sering memungkinkan Anda tidak memakai pengguna domain.
• Memakai pengguna domain untuk layanan punya masalah struktural penghentian dari kedaluwarsa, penyebaran katasandi teks biasa, dan Kerberoasting. Jika Anda memakainya, akun khusus + katasandi acak panjang + pembatasan logon dibutuhkan.
• gMSA adalah mekanisme di mana AD menghasilkan dan merotasi katasandi secara otomatis; persyaratannya adalah domain, tingkat fungsional 2012 atau lebih tinggi, dan KDS root key. Atur layanan ke “DOMAIN\nama$” dengan kolom katasandi kosong.
• Ketika Anda mengganti akun, masukkan hak “Log on as a service”, memindah 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 Anda memasang layanan, berhenti sejenak di layar pengaturan logon dan tanyakan ini lagi. Sebagai siapa, dan sejauh mana, layanan ini harus dapat mengakses? Jawabannya harus 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 Windows
• Kapan Anda benar-benar membutuhkan hak administrator di Windows? - 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 katasandi administrator lokal bersama di seluruh PC
• Menyimpan rahasia di aplikasi Windows - Menghindari konfigurasi teks biasa dengan DPAPI

Area konsultasi terkait

KomuraSoft LLC menangani desain akun logon dan pengerasan hak minimum untuk layanan Windows dan aplikasi residen, memigrasikan layanan yang ada yang dibangun dengan asumsi LocalSystem ke akun virtual atau gMSA, dan menyelidiki kegagalan yang disebabkan access denied, DPAPI, dan profil setelah penggantian akun. Memulai dari tahap “kami ditandai dalam audit, tetapi tidak tahu dari mana mulai” tidak apa-apa.

• Pengembangan aplikasi Windows
• Investigasi bug dan akar masalah
• 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.

Haruskah saya segera mengganti layanan yang selama ini dijalankan sebagai LocalSystem?

Perubahan segera tidak selalu jawaban yang tepat untuk setiap kasus. Pertama pastikan apakah layanan itu benar-benar membutuhkan hak lokal kelas LocalSystem (hak kuat di luar administrator). Jika hanya baca/tulis berkas dan komunikasi jaringan, memindah ke akun virtual (NT SERVICE\nama-layanan) adalah kandidat pertama. Saat migrasi, pastikan pemberian akses ke folder dan kunci registri yang dibutuhkan, cara data yang bergantung pada profil atau DPAPI ditangani, dan apakah hak "Log on as a service" ada. Konfirmasikan mulai dan fungsi utama di lingkungan validasi, lalu alihkan produksi.

Haruskah saya memilih akun virtual atau NetworkService?

Untuk pilihan baru, kami merekomendasikan akun virtual. Di jaringan keduanya tampil sebagai akun komputer (DOMAIN\nama-komputer$), dan keduanya punya hak lokal yang kecil. Namun NetworkService dibagi oleh beberapa layanan, jadi Anda tidak dapat memisah dengan ACL yang "hanya mengizinkan layanan ini". Akun virtual punya identitas unik per layanan, dan Anda dapat menuliskan NT SERVICE\nama-layanan langsung pada ACL. Produk Microsoft terkini seperti SQL Server juga memakai akun virtual sebagai bawaan.

Dapatkah saya memakai gMSA di lingkungan workgroup (tanpa domain)?

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

Setelah saya mengganti akun logon layanan, pengaturan dan kredensial yang tersimpan tidak lagi dapat 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 dari 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 saya hanya ingin layanan mengakses folder bersama, apakah saya butuh pengguna domain?

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 bersama dan ia dapat membaca serta menulis. Jika Anda ingin kontrol akses dengan identitas khusus layanan, atau identitas yang sama di beberapa server, pertimbangkan gMSA daripada 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.