L'eseguibile avviato da un servizio Windows utilizzando l'account di sistema locale non può accedere alle condivisioni di rete

Question

Ho un eseguibile che viene avviato da un servizio Windows, questo programma verrà eseguito su una macchina dei clienti e dovrà connettersi a una condivisione remota per eseguire una determinata attività. Questa condivisione è specificata dal cliente tramite un'interfaccia utente, quindi non lo sappiamo in anticipo, il che significa che non può essere "hardcoded" o la condivisione mappata in anticipo.

In precedenza avevamo richiesto al cliente di accedere alla propria macchina ed eseguire il file eseguibile all'accesso, ma abbiamo sempre voluto consentire al nostro programma di funzionare all'interno di un servizio e non richiedere un accesso, principalmente per renderlo più semplice per il cliente e impedire qualsiasi disconnessione accidentale che arresta il nostro software. Quindi questo significa anche che non sappiamo quali account utente locali esistono su un computer dei clienti, quindi dobbiamo avviare il servizio utilizzando l'account di sistema locale.

Ora abbiamo, come menzionato sopra, un servizio wrapper per avviare l'eseguibile ed eseguire varie attività. Questo sembra funzionare bene nella maggior parte dei casi e accede bene alla rete sottostante - lo scopo del nostro software prevede principalmente l'acquisizione di pacchetti ecc.

Tuttavia, quando il software tenta di connettersi a una condivisione Windows (nome UNC), non può connettersi. Considerando che se l'eseguibile è stato avviato manualmente si collega bene.

I suggerimenti che ho generalmente visto per risolvere questo tipo di problemi sembrano tutti dire che utilizzare un account utente in quanto l'account di sistema non può accedere alle condivisioni di rete, ma nel nostro caso questo non è possibile. Esiste un altro modo per farlo funzionare?

Modifica: ho dimenticato di dire che questa applicazione potrebbe (e più comunemente verrà) eseguita su Win2K non XP, e penso di aver ragione nel dire che l'account di rete locale non è disponibile prima di XP?

Answer 1

Se puoi modificare il tuo servizio Windows in modo che venga eseguito con l'account Servizio di rete, il tuo eseguibile sarà in grado di accedere alle condivisioni di rete (questo è uno dei motivi per cui è stato creato l'account del Servizio di rete).

Gli account del sistema locale e del servizio locale non dispongono di credenziali di rete e pertanto non possono essere autenticati sulla rete. Questo è di progettazione.

Modifica: IIRC, l'account del servizio di rete è stato introdotto in Server 2003 e aggiunto a uno dei service pack di XP.

Se non puoi fare affidamento sull'account del servizio di rete disponibile, potresti prendere in considerazione la creazione di un account di dominio dedicato, l'archiviazione delle credenziali dell'account da qualche parte, la lettura dall'interno del tuo servizio, quindi il login e la rappresentazione di quell'utente prima di accedere alla rete Condividere. In alternativa, il servizio Windows potrebbe essere eseguito direttamente come account dedicato, nel qual caso richiederebbe l'accesso "come servizio" privilegio.

Answer 2

Quando si dispone di un servizio che funziona con NT AUTHORITY \ LOCALSYSTEM (che è il nome dell'account del servizio), viene visualizzato come account DOMAINNAME \ COMPUTERNAME $ (notare il segno $) per il resto della rete. Cioè, appare come l'account del COMPUTER in Active Directory. Concedi il tuo file e condividi le autorizzazioni su DOMAINNAME \ COMPUTERNAME $ e dovresti essere bravo.

Answer 3

Perché non puoi usare un altro account? Esiste un account del servizio di rete integrato in Windows, in particolare per i servizi che richiedono l'accesso alla rete.

Ad ogni modo, fai molta attenzione quando un servizio avvia un exe.

Se l'accesso in scrittura alla cartella con exe non è disabilitato, un utente può sostituire quell'exe con (ad esempio) cmd.exe . La prossima volta che il servizio tenta di avviare exe, voilà: una shell di comando con diritti di sistema!