Come molti sanno WSS (Windows SharePoint Services) utilizza l’autenticazione integrata di Windows, delegando sostanzialemente ad IIS questo tipo di attività.
L’utente, una volta autenticato, riceve le corrette autorizzazioni (o l’appartenenza ai Site Gorups) grazie alle impostazioni gestite nell’ambito dell’amministrazione di SharePoint.
Volendo è anche possibile configurare il tutto in modo che l’autenticazione sia integrata Kerberos.
Per prima cosa occorre editare con Notepad il file Metbase.xml contenuto nella cartella c:\windows\system32\Inetsrv, agendo all’interno della sezione nominata <IIsWebServer> andando alla ricerca della frase NTAuthenticationProviders=”NTLM” e modificandola in NTAuthenticationProviders=”Negotiate,NTLM”.
Quindi, dopo aver salvato e chiuso il file, riavviare IIS con il comando iisreset da prompt di comandi.
A questo punto occorre seguire alcune varianti, in funzione di come si è installato e configurato WSS, ed in particolare sulla base di quali credenziali di sicurezza sono utilizzate dagli Application pool di del virtual server (o dei virtual server) su cui sono stati estesti i servizi WSS.
Se infatti sono stati utilizzati i service account NT Authority\Servizio di rete o NT Authority\Sistema locale non ci saranno problemi (questi account vengono automaticamente aggiornati a Kerberos), ma (come di solito io consiglio) se fosse stato utilizzato uno specifico service account creato ad-hoc… allora occorrerà andare a modificare le proprietà dell’account.
Inoltre, se il server su cui è installato WSS non è un Domain Controller, ma bensì un server member sarà necessario accedere alle proprietà dell’elemento Computer del server IIS su cui è presente WSS (dal tool Users and Computers di Active Directory) e all’interno della scheda Generico impostare l’opzione Considera attendibile il computer per la delega.
Naturalmente, se si utilizza uno specifico service account servirà autorizzare anche questo rendendolo attendibile per la delega, modificandone le proprietà sempre attraverso Users and Computer di Active Directory, questa volta agendo sull’Utente, e modificando la casella di controllo L’account è trusted per delega dalla scheda Opzioni account.
Se l’identità del pool di applicazioni è un account utente di dominio, è necessario configurare un nome principale del servizio per tale account. Per effettuare tale operazione, attenersi alla seguente procedura:
Setspn -A HTTP/NomeserverDominio\Nomeutente
Il tool Setspn è qui scaricabile.
Qualcuno utilizza il service account NT Authority\Servizio di rete o NT Authority\Sistema locale proprio per semplificarsi la vita… ma quel tipo di configurazione a volte potrebbe essere poco gestibile, ed inoltre è complessa da amministrare quando i DB SQL Server 2000 di WSS risiedono su di un’altra macchina… in questo caso va ricordato che se si volesse ugualmente utilizzare queste credenziali occorrerà modificare le autorizzazioni su SQL Server al fine di garantire all’elemento Dominio\Nomecomputer$ corrispondente al server WSS di disporre dei diritti di DB Creator e DB Owner.