All'interno di SharePoint Aggiornamento credenziali account di protezione

Pav Cherny

Download codice disponibile in: ChernySharePoint2009_03.exe(821 KB)

Contenuto

Servizi e account di protezione
Servizi e account di protezione
Un comando per tutti i servizi
Verrà distanza completo
Distribuzione e utilizzo della soluzione
Conclusione

Microsoft Windows SharePoint Services (WSS) 3.0 ed gestibilità di protezione Microsoft Office SharePoint Server (MOSS) 2007 push al limite di servizi e processi di lavoro che si basano su account utente di dominio per supportare il controllo di accesso discrezionale (DAC) basato il modello di protezione di Windows Server. Con il ruolo di account di protezione, account utente di dominio sono sempre impegnati soddisfare le esigenze dell'organizzazione. Questo si applica a qualsiasi ambiente client/server e in modo ancora più per server farm di SharePoint, ogni servizio in una farm mantiene le proprie informazioni di account e impone procedure il proprio specifico aggiornamento, indipendentemente di altri servizi che potrebbe utilizzare le stesse credenziali. L'account in questione potrebbe essere l'account stesso in Active Directory ma è comunque necessario aggiornare singolarmente ciascun servizio dopo una modifica della password.

Naturalmente, è prima necessario ricordare tutti i servizi che utilizzano un account. Può essere difficoltoso per seguire i suggerimenti di protezione suggeriscono utilizzando account di dominio separato per servizi di SQL Server, servizi di Amministrazione centrale e Timer di SharePoint, ricerca servizio e del crawler, condivisi provider di servizi (SSP), pool di applicazioni Web, servizio Single Sign-on, utente importazione profilo e account di Excel Services.

E, naturalmente, non vi sono diverse password complesse per ogni account e le modifiche delle password frequenti per tenere traccia delle. Non sarebbe ottima master questa richiesta senza incorrere overhead amministrativo?

Risorse di protezione

Sito Web di password di Windows SharePoint Services

In questo il seconda dispensa di una serie di due parti, è possibile discutere gli aspetti di protezione di SharePoint, in particolare protezione conto manutenzione e introducono una soluzione per automatizzare le modifiche password ottenere una maggiore protezione e ridurre il carico amministrativo.

L'idea sottostante è relativamente semplice: una soluzione personalizzata possibile ottenere tutti i nomi di account di protezione e le password utilizzando il modello di oggetti amministrativo di SharePoint. La soluzione possibile utilizzare queste informazioni per accedere a Active Directory, modificare la password corrispondente tramite Active Directory (Service INTERFACES) e aggiornare interessati tutti i servizi in locale server farm.

In questo modo, gli amministratori di SharePoint non necessario gestire più password degli account di protezione. Tuttavia, non è così semplice il concetto di implementazione. Alla fine, è possibile trovare manualmente la creazione di diversi componenti, incluse le estensioni di comando Stsadm.exe, le pagine dell'applicazione per il sito Amministrazione centrale SharePoint 3.0, un servizio Windows integrato di SharePoint e un'interfaccia di programmazione base per normalizzare le modifiche delle password in tutti i tipi di servizi SharePoint.

Non si dispone di tempo sufficiente per coprire tutti i servizi MOSS ancora, ma il prototipo corrente supporta WSS 3.0. HO creato un sito Web in sppwd.com che, in prossimo futuro fornirà i componenti MOSS e altri aggiornamenti, nonché un'ulteriore documentazione di funzionalità e le interfacce di programmazione.

Il prototipo corrente è solo a scopo di test ed non è deve essere utilizzato in ambienti di produzione. Non è completamente testato, viene tuttavia illustrato che Gestione account di protezione di SharePoint non è necessario aumentare il sovraccarico amministrativo. Il materiale di accompagnamento per questo articolo, disponibile in Download codice TechNet 2009, include i fogli di lavoro, degli assembly compilati e il codice sorgente.

Servizi e account di protezione

Sono sempre utile perché è necessario utilizzare molti comandi diversi per aggiornare gli account di protezione di SharePoint dopo la modifica di una password in Active Directory? Quindi vedere l'articolo" Modifica account di servizio e password di account di servizio in SharePoint Server 2007 e in Windows SharePoint Services 3.0."

Vengono descritti cinque comandi diversi, (updateaccountpassword, SPSearch/farmserviceaccount, SPSearch/farmcontentaccessaccount, updatefarm­credentials ed editssp/ssplogin) e ancora non copertina tutti gli aspetti.

Script di esempio dell'articolo, sebbene utile come un modello, inoltre, viene utilizzata una configurazione di protezione debole poiché si presuppone che è utilizzare la stessa account e password per tutti i servizi della farm. Provare ad adattarsi questo script in un ambiente farm in cui ogni servizio e applicazioni pool utilizza un account utente diverso e una password e si può verificare una grande sfida script. Manutenzione protezione del sistema tramite gli script non è facile in una farm SharePoint.

Il motivo per le complessità è sepolto profondità all'interno la struttura di protezione di SharePoint. Come informazioni utilizzando il comando di enumservices stsadm -o, SharePoint si basa su un numero di servizi e ogni servizio presenta dipendenze di protezione diverse.

Cercare il nome del tipo che il comando enumservices restituisce per ogni servizio in WSS 3.0 SDK, è disponibile che alcuni di questi servizi non utilizzare Nessun account di protezione, mentre altri può utilizzare un account di protezione singolo o richiedono più account. Ad esempio, servizi di messaggistica, correlati e il servizio di diagnostica non sono associati a informazioni di account di protezione, il servizio Timer di SharePoint utilizza un account di protezione singolo, il servizio di ricerca ha un account di servizio, nonché un account del crawler e il servizio di applicazione Web può avere come account di protezione di molti quanti sono i pool di applicazioni.

E non esiste più. Il servizio di amministrazione di SharePoint, ad esempio, deve utilizzare l'account di sistema locale, in modo che non richiede un account di protezione dominio anche in una farm SharePoint. Alcune soluzioni possono inoltre introdurre i propri servizi, ad esempio Microsoft Office Project Server (MOPS) 2007. Il cielo è il limite, considerando che può anche avere qualsiasi numero di soluzioni personalizzate con diversi requisiti di protezione.

Naturalmente c'è modo per applicare le procedure di aggiornamento comuni tra una vasta raccolta di servizi, in modo da renderlo non sorpresa che SharePoint include un'ampia gamma di comandi di aggiornamento. Essenzialmente, ogni soluzione necessario fornire i proprio singoli strumenti e aggiornare le procedure, aumentando il sovraccarico amministrativo in proporzione al numero dei servizi nell'ambiente SharePoint. Nella figura 1 viene illustrata la relazione tra servizi SharePoint e gli account di protezione, nonché i comandi di aggiornamento applicabile.

Figura 1 la relazione tra SharePoint gli account di servizi e protezione

Servizi e account di protezione

La disposizione delle servizi e account di protezione potrebbe sembrare confusione, ma vi è un ordine gerarchico applicato tramite il modello a oggetti SharePoint, come illustrato nella Figura 2 . In base a tutti i servizi SharePoint è la classe SPService. Questa classe non include un account di protezione poiché, come indicato in precedenza, non tutti i servizi richiedono credenziali. Servizi che richiedono credenziali possono ereditare un'identità dalla classe t SPWindowsService o implementare i propri.

Nella figura 2 gerarchie di ereditarietà di servizi SharePoint

La classe di SPSearchService, ad esempio, eredita un'identità di processo dalla classe SPWindowsService e gestisce inoltre il proprio account crawler. La classe SPWebService, invece, non è necessario un'identità di processo SPWindowsService­based in modo che eredita direttamente dalla classe SPService e gestisce il proprio account di protezione in forma di identità del pool di applicazione.

Esistono molti fattori importanti per rendere lontano dalla gerarchia di ereditarietà. Prima e di tutto, non vi sono effettivamente che molti modi diversi per gestire gli account di protezione di una farm SharePoint. Servizi SharePoint utilizzano principalmente le identità di processo o identità pool di applicazioni. Questi tipi di identità sono molto simili rispetto a aggiornamento delle informazioni di protezione, poiché la classe SP­ApplicationPool deriva dalla classe SPProcessIdentity.

In secondo luogo, le identità dei servizi SharePoint sono disponibili per gli script personalizzati e applicazioni amministrative. È possibile ottenere ogni singolo servizio di SharePoint tramite la classe base SP­Service per accedere ai nomi di accesso e password.

In terzo luogo, il modello a oggetti di SharePoint sa già come gestire identità di processo e l'identità del pool di applicazione. Tra le altre cose, il modello di oggetto include la logica per impostare e aggiornare le password, in modo che non è necessario reinvent la rotellina quando si utilizzano gli strumenti personalizzati. È solo necessario chiamare i metodi necessari, anche se non è senza ostacoli poiché molto bene l'SDK di WSS non spiegare le dipendenze.

L'aggiornamento degli account di protezione è necessario più di impostare le proprietà di nome utente e password (o SecurePassword) di identità di processo (SPProcess­Identity) o identità pool di applicazioni (SPApplicationPool) e viene chiamato il metodo Update. In questo modo non inserire la farm nuovamente in stato operativo. Il metodo Update consente di aggiornare semplicemente la password nel database di configurazione di SharePoint, ma non aggiornare i servizi sottostanti o il pool di applicazioni.

È importante tenere presente che le risorse interessate esistere di fuori dell'ambiente SharePoint. Servizi Windows mantenere le informazioni di protezione nel database del controllo Gestione servizi (SCM), si trova nel Registro di sistema su ciascun server nella directory HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services.

Le applicazioni Web, invece, sono risorse di IIS. Per aggiornarli, è necessario chiamare distribuzione metodo l'identità oltre al metodo Update. Il metodo di distribuzione è attiva la logica di SharePoint per aggiornare tutti i server della farm per mezzo di chiamate API locali e i processi timer di SharePoint. Modificato anche credenziali chiave la farm caso la modifica per modificare la password del pool di applicazioni per l'applicazione Web Amministrazione centrale (SPWebService.AdministrationService).

Questa modifica della password viene applicata anche il servizio Timer di SharePoint, che è ridotto strettamente con l'infrastruttura amministrativo, è necessario aggiornare il servizio Timer di SharePoint direttamente. Per ulteriori informazioni riguardanti le procedure standard per eseguire le modifiche delle password in un ambiente con con più server farm, è consigliabile leggere la colonna dal mese scorso " Gestione credenziali account di protezione."

Un comando per tutti i servizi

Nonostante le complessità la buona notizia è che il modello a oggetti di SharePoint si occupa di tutti i dettagli di aggiornamento fondamentali di una server farm. È solo necessario sfruttare le funzionalità esistenti di un'estensione Stsadm personalizzata per implementare un comando singolo aggiornamento per tutti i servizi:

stsadm -o changepwd -user DOMAIN\Account -oldpwd old_p@ssw0rd
 -newpwd new_ p@ssw0rd

È effettivamente necessario numerose Update diversi. Dopo tutto, è chiaro che è necessario modificare la password in tutti i percorsi, Active Directory, database di configurazione, database di servizi di Windows, IIS e qualsiasi altri archivi di credenziali un determinato servizio può utilizzare.

Non un'opzione per tralasciare una password non aggiornata. Con un'estensione di comando comporta la liberazione di tutte le dipendenze implica cambi password più coerente delle risorse interessate tutti e meno problemi relative password della farm.

Implementazione di un'estensione Stsadm è inoltre, semplice e divertente. Semplicemente seguire i passaggi indicati NELL'SDK di WSS sotto il titolo" Procedura: estesa l'utilità STSADM." Inoltre consigliabile verificare fuori Blog di John Lapointe Per esempi di grandi e un eccezionale elenco di estensioni utile che potrebbe risultare utile nelle attività lavorative quotidiane come amministratore di SharePoint.

Con Stsadm implementazione dettagli dall'area di lavoro, è possibile concentrare l'attenzione nostri sforzi sull'implementazione della soluzione effettiva, che è difficile sufficiente considerare che possono servizi SharePoint utilizzare qualsiasi numero di credenziali. Questo può includere identità di processo, le identità pool di applicazioni e altri account.

Non è solo possibile conoscere le dipendenze di protezione di un front-end ogni servizio di SharePoint. È possibile ottenere immediatamente con i servizi WSS e MOSS standard che però una soluzione veramente utile deve inoltre supporta servizi personalizzati con requisiti diversi.

Gestione di diversi meglio avviene tramite UN'API. L'API separa l'estensione di comando da servizi sottostanti e in questo modo consente agli sviluppatori di collegare i propri componenti che contengono la logica per eseguire le modifiche password per i servizi.

È possibile chiamare questi componenti collegabili i proxy del servizio. Basandosi su questi componenti proxy l'estensione di comando può contenere qualsiasi servizio, gli sviluppatori non necessario fornire più password ulteriori strumenti di aggiornamento e gli amministratori non necessario gestire più complessità di protezione di servizi sottostante. Pertanto si riduce il carico amministrativo per gestire gli account di protezione in un ambiente SharePoint.

Il proxy del servizio API necessario eseguire due operazioni di base: è necessario abilitare l'estensione del comando da determinano i conti di protezione di ogni servizio supportato ed è necessario abilitare l'estensione comando aggiornare la password associata. Di conseguenza, l'API richiede due metodi: Resolve­Identities e Cambia password.

In primo luogo, l'estensione del comando enumera tutti i servizi della farm utilizzando l'insieme SPFarm.Local.Services. Per ogni tipo di servizio, l'estensione del comando Carica anche in modo dinamico un proxy di servizio registrato per il servizio in un file di configurazione basato su XML che segue la convenzione di denominazione passwordproxies.*.xml (ad esempio passwordproxies.WSSProxies.xml).

Quindi, l'estensione del comando chiama il metodo ResolveIdentities del proxy di assistenza registrati, passando un riferimento all'oggetto servizio. Il componente proxy estrae gli account di protezione desiderato dal servizio sottostante e restituisce queste informazioni e l'estensione del comando.

Il risultato è un'associazione tra gli account di protezione e i servizi che è il contrario dell'associazione definito nel modello di oggetti di SharePoint. Invece di servizi da elementi padre di account di protezione, account di protezione sono ora gli elementi padre di servizi, come illustrato nella Figura 3 . Questa architettura riflette la relazione effettiva tra servizi e account di protezione migliore.

Nella figura 3 Storno la relazione tra gli account di protezione e servizi SharePoint

Più importante, l'estensione di comando può ora aggiornare gli account di protezione in Active Directory e quindi scorrere tutti gli oggetti servizio dipendente per chiamare il metodo ChangePassword dei proxy corrispondenti per aggiornare la password.

Anche in questo caso, i componenti di proxy contengono la logica di specifiche del servizio necessaria eseguire le modifiche delle password. L'estensione del comando non riguardano i dettagli di implementazione specifiche del servizio.

Se si desidera nei dettagli, estrarre il file di SPPwdServiceProxy.cs nel materiale di accompagnamento. Definisce il proxy API per mezzo di SPPwdServiceProxy classe astratta con relativi due metodi ResolveIdentities e Cambia password. Per esempi di implementazione, vedere le definizioni delle classi della libreria di classi WSSProxies.

La libreria WSSProxies viene illustrato come utilizzare proxy del servizio API per eseguire le modifiche delle password per i servizi di WSS 3.0 standard. Non è complicato modificare la password di account di protezione a livello di codice. È sufficiente sono tre righe di codice per identità di processo e le stesse tre righe per identità pool di applicazioni. Il modello a oggetti di SharePoint farà il resto.

Solo l'account di ricerca per indicizzazione di classe SPSearchService rappresenta una sfida poiché Microsoft contrassegnato scrittura password ricerca per indicizzazione solo in modo da non può leggere con normali metodi. Ciò rende difficile agli sviluppatori di soluzioni di creare soluzioni di protezione.

Verrà distanza completo

Con un'estensione unico comando che copre tutti i servizi, concentrare troverete nostro l'attenzione su un paio di ulteriore miglioramento opportunità. Il primo elemento è eliminare la necessità di specificare la password in testo non crittografato prompt, che non è una tecnica di protezione. Anche la casella password semplice nell'interfaccia utente grafica potrebbe mascherare queste informazioni.

Un'altra opportunità è per aumentare la complessità della password senza aumentare il carico amministrativo. Ad esempio password con sette caratteri alfanumerici casuale sono una volta considerato sicuro, ma che presupposto è stata stabilita molto tempo fa e probabilmente non contiene true per gli account di protezione ora.

Come sta utilizzando 50 o più caratteri per le risorse importanti, ad esempio gli account di protezione di SharePoint: 3ZK2AQUuqZ7/M7­NBIEvc {XKregSMaVmQgiZaZXik­hL8E {dQuwyQ per la farm conto, TA3pIa7yUyJikc6FxTFl = K9EQcb8lBn­hp8ej03lt3 + mA = 7aqgKA per l'applicazione Web predefinita; PXMzzAxrHvO/L9MZyd0SkVuMv9/co0ocluYCq/4TID/n + DLj­XYA per l'account del servizio ricerca; e qjoNlEvOX $ 7vbEjrnDd5lXLPYvZEFf­gRpij $8amSbEVpj2O474Q per l'account del crawler?

Strikes me come funny a immaginare un amministratore di immettere manualmente questi tipi di password. Un'altra opportunità di miglioramento relativo ai controlli di protezione. Per impostazione predefinita, SharePoint non segnalare è configurazioni di protezione debole, ad esempio pool di applicazioni possano accedere alla metabase di IIS o utilizzando l'account di farm come propria identità di protezione. Una soluzione personalizzata è possibile eseguire questi controlli in modo regolare.

E infine perché amministratori di SharePoint dispone gestire le password per account di protezione? Pirati informatici probabilmente sono le uniche interesse a conoscenza di queste password. Gli amministratori in genere non necessario utilizzarli.

Naturalmente, SharePoint offre numerose opzioni per affrontare queste opportunità. È possibile utilizzare gli script, ma gli script in genere gestiscono le password in testo non crittografato. È possibile utilizzare processi personalizzati del timer che elabora il servizio Timer di SharePoint in intervalli pianificati, ma il servizio Timer di già occupa di numerose attività, incluse distribuzioni di credenziali.

Sarebbe difficile coordinare processi di distribuzione delle credenziali con i processi di modifica di password. È sembrata preferibile implementare un servizio separato SharePoint che utilizza l'account di farm come l'identità di processo per poter accedere completa il modello di oggetti amministrativo di SharePoint.

Tra l'altro, è possibile interrompere il servizio in qualsiasi momento senza influenzare altri processi e sarà possibile disabilitare questo servizio, se si desidera modificare manualmente le password. La soluzione include numerosi strumenti per questo scopo, ad esempio le estensioni del comando stsadm, un'applicazione Windows e pagine di applicazione di personalizzato Amministrazione centrale, così come visualizzata nella Figura 4 .

Nella figura 4 SPPwd Architettura della soluzione

Essenzialmente, tutte le applicazioni SPPwd utilizzano lo stesso insieme di estensioni Stsadm, in modo da un solo percorso del codice indipendentemente dal quale strumento utilizzato. Tramite un livello della logica di business comuni, le estensioni di comando in combinazione con i proxy del servizio eseguire effettiva elaborazione, mentre l'applicazioni SPPwd utilizzato gli oggetti di stub caricare dinamicamente le estensioni del comando in fase di esecuzione.

Questo accoppiamento separato consente di sostituire alcune estensioni di comando senza dover modificare le applicazioni SPPwd. Ad esempio, se si preferisce utilizzare un generatore di password differente, è possibile creare un'estensione di comando, distribuzione nella global assembly cache e modificare la voce di comando genpwd nel file di configurazione stsadmcommands.passwordmanagement.xml. La soluzione si inserisce nella cartella %Programmi%\File comuni\Microsoft Shared\Web Server Extensions\12\Config in base alle convenzioni di extensibility Stsadm.

Il generatore predefinito crea le password lunga, che dovrebbe essere sufficiente nella maggior parte dei casi. Nella figura 5 Elenca le estensioni del comando SPPwd con una breve descrizione delle rispettive funzioni. È inoltre possibile utilizzare stsadm - Guida <extension> comando per visualizzare ulteriori informazioni su parametri disponibili ed esempi della riga di comando.

Distribuzione e utilizzo della soluzione

I fogli di lavoro nel materiale di accompagnamento illustrato in dettaglio distribuire e utilizzare la soluzione SPPwd in un ambiente con solo server nonché come in una server farm. È solo necessario distribuire la soluzione in un server di SharePoint utilizzando i comandi di Stsadm addsolution e deploysolution standard.

SharePoint quindi distribuisce la soluzione a tutti i server della farm mediante processi timer. Non appena questi processi sono completati, è possibile attivare la funzionalità di soluzione per estendere il sito Amministrazione centrale e installare il servizio di Windows utilizzando l'estensione del comando sppwdsetup.

Il materiale di accompagnamento include un file DeployTo.bat per automatizzare queste attività. Tra le altre cose, il file batch illustrato attendere processi timer da completare prima di procedere con ulteriori operazioni di distribuzione.

Per impostazione predefinita, il servizio SPPwd è disponibile solo sul server in cui si esegue il file DeployTo.bat. È possibile configurare per eseguire su più server di SharePoint, il servizio, ma è esiste una sola istanza di un account di protezione in Active Directory e impone i seguenti due requisiti: solo un'istanza di servizio SPPwd può essere attendibile per un account di protezione specifico e l'account di protezione non deve essere utilizzato in più farm.

Account con lo stesso processo più istanze del servizio può causare problemi di accesso simultaneo e non è necessario poiché SharePoint propaga automaticamente aggiornamenti di credenziali nella farm locale. Condividere gli account non sono supportati perché il servizio di SPPwd non aggiornare informazioni sull'account di protezione in più farm di protezione.

Il servizio SPPwd Aggiorna solo gli account di protezione specificare il nome di dominio nell'attributo adminDescription completo su del server e che conferma nell'attributo descrizione che si sta utilizzati solo in locale farm di SharePoint, come indicato nella Figura 6 . Vedere il materiale di accompagnamento per ulteriori informazioni sulla configurazione di account di protezione e il servizio SPPwd per automatizzare le modifiche delle password.

Nella figura 6 SPPwd distribuzione e configurazione di account di protezione

Conclusione

Gli account di protezione sono destinazioni primo per attacchi, poiché sono in grado di fornire accesso completo a tutte le raccolte siti e i dati del sito in una farm indipendentemente dalle autorizzazioni e i controlli di accesso definiti a livello di SharePoint. Una strategia di base per impedire gli attacchi di corso è utilizzare password di account di protezione e modificarli frequentemente.

Questo è difficile eseguire dato che l'account utente di dominio non cambiare le proprie password in modo autonomo. È necessario eseguire le modifiche delle password manualmente oppure utilizzare una soluzione automatica. Indipendentemente dal metodo scelto, sono presenti numerose dipendenze che la documentazione di SharePoint e SDK WSS non descrivono molto bene.

È necessario aggiornare e distribuire le password modificate e non esistono altri problematiche correlate al conto di farm. Ad esempio, quando si modifica la password dell'account di farm, si modifica credenziali chiave la farm e di conseguenza il recupero del database di configurazione da un backup.

Tuttavia, non non alternativa alla modifica della password di account farm regolarmente se si desidera mantenere la protezione del sistema di una farm SharePoint. Assicurarsi che si esegue un backup dopo la modifica la password dell'account di farm.

Automatizzare le modifiche delle password è complessa nonostante il fatto che il modello a oggetti SharePoint include la logica necessaria per eseguire gli aggiornamenti di credenziali. Potrebbe sembrare semplice immediatamente prima anche anche un approccio basato su script rapidamente possibile attivare in una sfida enorme. Una soluzione completa calcolato Sull'microsoft .NET Framework e il modello di oggetti amministrativo di SharePoint è consigliabile, ma la soluzione migliore può entrare solo direttamente da Microsoft in forma di innovazioni di account di sistema aggiuntive.

Quasi dieci anni fa, Microsoft consente di modificare l'account di sistema locale per soddisfare le esigenze dei clienti aziendali mediante Microsoft Exchange Server. Questo infine ha causato l'account in Windows Server 2003 del servizio di rete. Ma l'account di servizio di rete non è adatto per server farm in modo da è comunque necessario utilizzare gli account utente di dominio e gestire la manutenzione associati e problemi di protezione al meglio la capacità.

Cherny Pav è un esperto IT e l'autore specializzato nelle tecnologie Microsoft per la collaborazione e comunicazione unificata. Sua pubblicazioni includono white paper, manuali del prodotto e libri con particolare attenzione su operazioni e amministrazione del sistema. Pav è presidente di Biblioso Corporation, una società specializzata in servizi di documentazione e la localizzazione gestiti.