Akun Layanan Jaringan mengakses folder berbagi


31

Saya punya skenario sederhana. Ada aplikasi di ServerA yang berjalan di bawah akun Layanan Jaringan bawaan. Perlu membaca dan menulis file pada folder share di ServerB. Izin apa yang harus saya atur pada folder share di ServerB?

Saya bisa membuatnya bekerja dengan membuka dialog keamanan berbagi, menambahkan pengguna keamanan baru, mengklik "Jenis Objek" dan memastikan "Komputer" dicentang, dan kemudian menambahkan ServerA dengan akses baca / tulis. Dengan melakukan ini, akun apa yang mendapatkan akses ke share? Hanya Layanan Jaringan? Semua akun lokal di ServerA? Apa yang harus saya lakukan untuk memberikan akses akun Layanan Jaringan ServerA ke bagian ServerB?

Catatan:
Saya tahu ini mirip dengan pertanyaan ini . Namun, dalam skenario saya ServerA dan ServerB berada di domain yang sama.

Jawaban:


27

"Izin Berbagi" dapat "Semua Orang / Kontrol Penuh" - hanya izin NTFS yang benar-benar penting. (Isyarat argumen keagamaan dari orang-orang yang memiliki keterikatan yang tidak sehat dengan "Izin Bagikan" di sini ...)

Dalam izin NTFS pada folder di ServerB Anda bisa bertahan dengan "DOMAIN \ ServerA - Modify" atau "DOMAIN \ ServerA - Write", tergantung pada apakah diperlukan untuk dapat memodifikasi file yang ada atau tidak. (Modifikasi benar-benar disukai karena aplikasi Anda dapat membuka kembali file setelah itu membuatnya untuk menulis lebih lanjut - Modifikasi memberikan hak itu, tetapi Menulis tidak.)

Hanya konteks "SISTEM" dan "Layanan Jaringan" pada ServerA yang akan memiliki akses, dengan asumsi Anda memberi nama "DOMAIN \ ServerA" dalam izin. Akun pengguna lokal pada komputer ServerA berbeda dari konteks "DOMAIN \ ServerA" (dan harus dinamai secara individual jika Anda ingin memberi mereka akses).

Sebagai tambahan: Peran komputer server berubah. Anda mungkin ingin membuat grup di AD untuk peran ini, memasukkan ServerA ke dalam grup itu, dan memberikan hak grup. Jika Anda pernah mengubah peran ServerA dan menggantinya dengan, katakanlah, ServerC, Anda hanya perlu mengubah keanggotaan grup dan Anda tidak perlu menyentuh izin folder lagi. Banyak admin memikirkan hal semacam ini untuk pengguna yang disebutkan dalam izin, tetapi mereka lupa bahwa "komputer juga manusia" dan peran mereka terkadang berubah. Meminimalkan pekerjaan Anda di masa depan (dan kemampuan Anda untuk melakukan kesalahan) adalah apa yang menjadi efisien dalam gim ini ...


1
Anda tidak dapat secara actaully memberikan akun lokal di satu komputer akses ke sumber daya di komputer lain.
pipTheGeek

3
@ pip: Tetapi Anda dapat membuat sumber daya lokal dengan nama pengguna dan kata sandi yang sama di mesin jarak jauh, lalu memberikan akun itu akses yang diperlukan. Hasil akhirnya adalah sama.
John Rennie

8
Layanan Jaringan adalah pengecualian. Ini tidak memetakan di sebagai account komputer. Pada Windows 2000, akun Sistem melakukan hal yang sama.
K. Brian Kelley

1
Ini tampaknya tidak mungkin persis seperti yang dijelaskan dalam Windows Server 2008+. Saya tidak dapat menambahkan server sebagai 'domain \ server' tetapi saya dapat (jika saya menyertakan komputer dari "Seluruh Direktori") hanya sebagai 'server'. Juga, setelah ditambahkan server terdaftar 'server $'.
Kenny Evitt

12

Akun layanan jaringan komputer akan memetakan ke komputer tepercaya lainnya sebagai akun nama komputer. Misalnya, Jika Anda menjalankan sebagai akun Layanan Jaringan di ServerA di MyDomain, yang seharusnya dipetakan sebagai MyDomain \ ServerA $ (ya, tanda dolar diperlukan). Anda melihat ini sedikit ketika Anda memiliki aplikasi IIS berjalan sebagai akun Layanan Jaringan yang terhubung ke SQL Server pada server yang berbeda, seperti instalasi SSRS atau Microsoft CRM yang diperkecil.


5

Saya setuju dengan Evan. Namun, saya percaya solusi ideal, jika keamanan menjadi perhatian Anda, adalah membuat akun pengguna khusus untuk menjalankan aplikasi / layanan tersebut, dan memberikan akun tersebut izin yang diperlukan ke folder bersama. Dengan cara ini, Anda dapat yakin bahwa hanya aplikasi / layanan yang mengakses bagian tersebut. Ini mungkin berlebihan meskipun.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.