La differenza tra l'account "Sistema locale" e l'account "Servizio di rete"?


386

Ho scritto un servizio di Windows che genera un processo separato. Questo processo crea un oggetto COM. Se il servizio viene eseguito con l'account "Sistema locale" tutto funziona correttamente, ma se il servizio viene eseguito con l'account "Servizio di rete", il processo esterno si avvia ma non riesce a creare l'oggetto COM. L'errore restituito dalla creazione dell'oggetto COM non è un errore COM standard (penso sia specifico per l'oggetto COM che viene creato).

Quindi, come posso determinare la differenza tra i due account, "Sistema locale" e "Servizio di rete"? Questi account integrati sembrano molto misteriosi e nessuno sembra sapere molto su di loro.

Risposte:


701

Dal momento che c'è così tanta confusione sulla funzionalità degli account di servizio standard, proverò a dare una rapida occhiata.

Innanzitutto i conti reali:

  • Account LocalService (preferito)

    Un account di servizio limitato che è molto simile al servizio di rete e che intendeva eseguire servizi standard con privilegi minimi. Tuttavia, a differenza del servizio di rete, accede alla rete come utente anonimo .

    • Nome: NT AUTHORITY\LocalService
    • l'account non ha password (le informazioni sulla password fornite vengono ignorate)
    • HKCU rappresenta l' account utente LocalService
    • ha privilegi minimi sul computer locale
    • presenta credenziali anonime sulla rete
    • SID : S-1-5-19
    • ha il proprio profilo sotto la chiave di registro HKEY_USERS ( HKEY_USERS\S-1-5-19)

     

  • Account NetworkService

    Account di servizio limitato destinato a eseguire servizi privilegiati standard. Questo account è molto più limitato del sistema locale (o anche dell'amministratore), ma ha ancora il diritto di accedere alla rete come macchina (vedi avvertenza sopra).

    • NT AUTHORITY\NetworkService
    • l'account non ha password (le informazioni sulla password fornite vengono ignorate)
    • HKCU rappresenta l' account utente di NetworkService
    • ha privilegi minimi sul computer locale
    • presenta le credenziali del computer (ad es. MANGO$) ai server remoti
    • SID : S-1-5-20
    • ha il proprio profilo sotto la chiave di registro HKEY_USERS ( HKEY_USERS\S-1-5-20)
    • Se si tenta di pianificare un'attività utilizzandola, accedere NETWORK SERVICEalla finestra di dialogo Seleziona utente o gruppo

     

  • Account LocalSystem (pericoloso, non usare!)

    Account completamente attendibile, più dell'account amministratore. Non esiste nulla in una singola casella che questo account non può fare e ha il diritto di accedere alla rete come macchina (ciò richiede Active Directory e concedere le autorizzazioni dell'account macchina a qualcosa)

    • Nome: .\LocalSystem(può anche usare LocalSystemo ComputerName\LocalSystem)
    • l'account non ha password (le informazioni sulla password fornite vengono ignorate)
    • SID : S-1-5-18
    • non ha un profilo proprio ( HKCUrappresenta l' utente predefinito )
    • ha ampi privilegi sul computer locale
    • presenta le credenziali del computer (ad es. MANGO$) ai server remoti

     

Soprattutto quando si parla di accesso alla rete, ciò si riferisce esclusivamente a SPNEGO (Negoziazione), NTLM e Kerberos e non ad altri meccanismi di autenticazione. Ad esempio, l'elaborazione in esecuzione come LocalServicepuò ancora accedere a Internet.

Il problema generale con l'esecuzione come account predefinito standard è che se modifichi una qualsiasi delle autorizzazioni predefinite stai espandendo l'insieme di cose tutto ciò che è in esecuzione come può fare quell'account. Quindi, se concedi DBO a un database, non solo il tuo servizio in esecuzione come Servizio locale o Servizio di rete può accedere a quel database, ma anche tutto il resto in esecuzione come tali account. Se ogni sviluppatore lo fa, il computer disporrà di un account di servizio che dispone delle autorizzazioni per fare praticamente qualsiasi cosa (in particolare il superset di tutti i diversi privilegi aggiuntivi concessi a tale account).

È sempre preferibile dal punto di vista della sicurezza eseguire come proprio account di servizio che dispone esattamente delle autorizzazioni necessarie per fare ciò che fa il proprio servizio e nient'altro. Tuttavia, il costo di questo approccio consiste nella configurazione dell'account del servizio e nella gestione della password. È un atto di bilanciamento che ogni applicazione deve gestire.

Nel tuo caso specifico, il problema che probabilmente stai riscontrando è che l'attivazione DCOM o COM + è limitata a un determinato set di account. In Windows XP SP2, Windows Server 2003 e versioni successive l'autorizzazione di attivazione è stata limitata in modo significativo. È necessario utilizzare lo snap-in MMC Servizi componenti per esaminare l'oggetto COM specifico e visualizzare le autorizzazioni di attivazione. Se non stai accedendo a nulla sulla rete come account del computer, dovresti prendere seriamente in considerazione l'uso del servizio locale (non del sistema locale che è fondamentalmente il sistema operativo).


In Windows Server 2003 non è possibile eseguire un'attività pianificata come

  • NT_AUTHORITY\LocalService (noto anche come account del servizio locale) o
  • NT AUTHORITY\NetworkService (noto anche come account del servizio di rete).

Questa funzionalità è stata aggiunta solo con l'Utilità di pianificazione 2.0 , che esiste solo in Windows Vista / Windows Server 2008 e versioni successive.

Un servizio in esecuzione come NetworkServicepresenta le credenziali della macchina sulla rete. Ciò significa che se il tuo computer fosse chiamato mango, si presenterebbe come l'account del computer MANGO$ :

inserisci qui la descrizione dell'immagine


7
Penso che gli account dei servizi gestiti rimuovano un po 'il problema di configurare l'account e gestire la password (o piuttosto passarla a un amministratore o delegato di dominio).
Carl G

1
Ciao, grazie per la spiegazione. Tuttavia, ho una domanda: utilizzando l'account del sistema locale / del servizio di rete è possibile aggiungere / rimuovere voci ai contenitori nella directory attiva (a condizione che il contenitore nella directory attiva abbia concesso tutte le autorizzazioni al computer su cui sono in esecuzione questi servizi di Windows). Si noti che tutto funziona, quando ho eseguito il servizio come uno degli utenti del dominio, ma non come sistema locale / servizio di rete (per dettagli stackoverflow.com/questions/20943436/… ) Saluti
Dreamer

1
Sì, dovrebbe. Risponderò direttamente alla tua domanda poiché questa domanda è più astratta e si tratta di un'implementazione specifica.
Peter Oehlert,

7
Si noti che l'utente "anonimo" non è solo, non un membro di "utenti autenticati", non è un membro di "tutti" su Windows. Sulle reti Windows, "anonimo" ha accesso solo a risorse che sono state esplicitamente concesse a "anonimo" - per impostazione predefinita, nulla.
David,

1
@HakamFostok Non ho molti riferimenti. Se ricordo bene, Dan Brown ne ha parlato in parte nel suo libro Programmazione della sicurezza di Windows. C'è molto nell'aiuto di Windows e nei documenti MSDN ma non ho riferimenti specifici. Il libro (i) di Jeff Richter sulla programmazione delle finestre, così come Inside Windows (3a o 4a edizione) di Soloman & Russinovich ne ha anche alcuni.
Peter Oehlert,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.