L'originale della “pessima” traduzione è questo: http://www.adopenstatic.com/faq/
http://learn.iis.net/page.aspx/246/using-fastcgi-to-host-php-applications-on-iis-7/
Browser
Per configurare Internet Explorer ad utilizzare Kerberos per l'autentificazione su IIS, occorrono le seguenti configurazioni.
Occorre selezionare su Strumenti -> Internet Options -> Advanced l'opzione "Enable Integrated Windows Authentication (Requires Restart)". Seppure tecnicamente IWA consenta sia l'autentificazione NTLM che quella con Kerberos, IE utilizzerà solo NTLM se questa opzione non è contrassegnata, mentre con il segno di spunta utilizzerà entrambe. (Rferito ad IE6)
Il sito web al quale state connettendovi deve essere locato nella zona "Intranet Scurity" . Se il sito è collocato nella "Internet" zone, IE non cercherà di autentificarsi con Kerberos. Questo perchè nella maggior parte degli scenari Internet una connessione ad un domain controller non può essere stabilita.
La semplice regola che ogni sito che contenge full spor come un indirizzo IP o un FQDN è nella zona internet. Se state connettendovi ad un indirizzo IP o ad un FQDN allora utilizzate i settaggi di IE per aggiungere questo sito alla intranet zone.
Domain Controller
Per permettere al Domain Controller di generare il ticket corretto da fornire al client deve essere registrato un appropriato Service Principal Name (SPN) nell'Active Directory. Quando un server Windows 2003 è aggiunto ad un dominio, vengono generati automaticamente sia un HOST SPN sia per il nome NetBIOS che per il FQDN del server. Se il vostro web server è accessibile sia http://servername che http://servername.domain.tld (tld = Top Level Domain, such .com or .local) e l'applicazione web gira come Network Service, Local Service or Local System, non avete bisogno di modificare alcun SPN.
Se la vostra applicazione web è posta su un sito che viene avviato con un account cystom, allora SPN HTTP/servername o HTTP/servername.domain.tld deve essere registrato. se questi HTTP SPN esistono sotto ogni altro account, devono essere rimossi,
Infine, se il sito web è accessibile da hostname arbitrari, che non sono correlati all'attuale nome del server allora deve essere registrata una SPN per l'hostname.
- a servername under a custom user account:setspn –A HTTP/servername Domain\Username
- an arbitrary hostname under a computer account:setspn –A HTTP/hostname.domain.tld Domain\MachineName
- an arbitrary hostname under a custom user account:setspn –A HTTP/hostname.domain.tld Domain\UserName
IIS Server
Non c'è molto da configurare su IIS server. Per primo Integrated Windows Authentication (IWA) dovrebbe essere abilitata sul sito web o sull'applicazione. Per default questa opzione abilita sia NTLM Authentication Providers in the IIS metabase. Se avete editato il metabase per rimuovere il Negotiate provider, potete avere la necessità di rimetterla dietro. L'installazione di alcuni prodotti come Sharepoint Portal Server 2001 rimuove il Negotiate provider.
Secondo, tutte le applicazioni web ospitate sul nome DNS in questione hanno bisogno di essere lanciate in una o più pool che stanno girando sotto il stesso user account. Ciò è semplice se tutte le applicazioni stanno girando sotto lo stesso pool di applicazioni web. Tuttavia se avete la necessità non avete bisogno di suddividere l'applicazione in pool multipli, queste devono girare sotto lo stesso account.
Sommario Questo dovrebbe essere tutto quello che è richiesto per permettere al browser Internet Explorer di autentificarsi con IIS utilizzando Kerberos. Per verificare che questo stia avvenendo potete utilizzare lo strumento descritto in determining whether the browser is using NTLM or Kerberos per autentificare su IIS.
Delegatione
- Il client richiede un ticket di servizio Kerberos service ticket al server web
- Il web server vede che ha la necessità di aprire una connessione con SQL server utilizzando le credenziali dell'utente ottiene i necessari ticket da KDC.
- Il server KDC fornisce dei tichet se al server web è permessa la delega.
- Il server apre la connessione inviando i ticket ottenuti da KDC
- Il server SQL Server permette alla connessione di essere aperta oppure ritorna un errore indicando che al web server non è permesso di loggarsi sul server SQL
- Il web server ritorna la pagia all'utente finale.
Per far funzionare tutto questo, dobbiamo effettuare alcune configurazioni aggiuntive. In Active Directory dobbiamo fornire i permessi al web server cosi che possa ottenere i ticket a seconda del comportamento dell'utente. Localizzate il web server in Active Directory Users and Computers MMC, pulsante destro e scegliere "Proprietà", vi è un tab con "Delegation" dove è possibile configurare le opzioni necessarie. La tab per la Delegation può essere differente a seconda che si abbia un dominio Windows 2000 oppure un dominio Windows 2003.
Selezionare "Use Kerberos Only ed aggiungere il server SQL desiderato.
Protocol Transition, Constrained Delegation, S4U2S and S4U2P
La transizione di protocollo è una nuova capacità di Windows Server 2003. L'implementazione di Kerberos in un dominio Windows Active Directory fornisce la robustezza di Kerberos ed evita una serie di problemi tecnici con altre implementazioni non Windows (platform infrastructure, ticket renewal, ticket proxy). Tuttavia anche Kerberos presenta degli svantaggi – la necessità di ottenere un ticket da un server KDC. Nel mondo di IIS connettersi ad un KDC è semplicemente impossibile nella maggior parte degli scenari. Sia perchè il KDC non è normalmente esposto su internet (client bloccati da firewall), o (più comunemente) un KDC non è raggiungibile semplicemente perchè i necessari record SRV (service records) sono posti solamente sul DNS interno.
Windows Server 2003 introduce due nuovi servizi che indirizzano alcuni dei problemi su menzionati.
In particolare su Windows Server 2003 sono introdotti:
· Protocol Transition – questo permette ad un meccanismo non-Kerberos di essere utilizzato per autentificarsi al server IIS, mentre IIS può utilizzare Kerberos per connettersi ad un altro server backend.
· Constrained Delegation – questo permette agli amministratori di specificare qualeservizi backend possa contattare IIS.
Per facilitare l'uso di queste funzionalità Windows Server 2003 introduce due nuovi servizi che can be leveraged by your applications and by IIS:
- Services For User to Self (S4U2S)
- Services For User to Proxy (S4U2P)
Configurazioni di Active Directory
Per supportare il Protocol Transition avete bisogno di Windows Server 2003 per il vostro server IIS ed avete bisogno di avere un dominio con un livello di funzionalità portato a livello Windows Server 2003 (questo richiede che tutti i DC nel vostro dominio stiano utilizzando almeno Windows Server 2003). Per avviare il livello utilizzate Active Directory Domains and Trusts MMC Snapin).
Per configurare Active Directory utilizzando la aprite Active Directory Users and Computers MMC Snapin.
Assumendo che non state utilizzando un account utente custom per la vostra pool di applicazioni web, localizzate l'oggetto computer del vostro server IIS a raggiungete le proprietà della macchina. Sulla tabella delega scegliete entrambi:
· Trust this computer for delegation to specified services only and
· Use any authentication protocol
Avete adesso bisogno di specificare i servizi backend che la macchina IIS è permessa di delegare. Click su "add" e quindi su "users and computers". Inserire il computer o l'account utente che il servizio di backend sta utilizzando (ad esempio, se state avviando SQL Server sotto un account LocalSystem o remote server, immettere il nome del computer. If you are running SQL Server under a custom user account, enter that user's account). Una lista dei Services Principal Names (SPNs) registrata sotto l'account verrà mostrata. Selezionate la SPN che volete che IIS sia in grado di contattare.
Configurazione di IIS
Non c'è molto da configurare su IIS oltre alle cose configurate precedentemente per il servizio di Delega Kerberos. La differenza principale è che l'user account del pool della applicazione web necessita di avere SeTCBPrivilege (Act as Part of the Operating System) ed SeImpersonateUser (Impersonate a User After Authentication). Queste opzioni implicano sia lanciare la vostra applicazione com LocalSystem, oppure dare ad un account custom questi diritti NT User Rights. Questi diritti possono essere assegnato editando le local security policy (start ->; Run -> secpol.msc). Altenativamente le Group Policy possono pure essere usate
Nota: avviare un pool di applicazioni web con ogni account che ha SeTCBPrivilege è un rischio di sicurezza. Ogni potenziale compromissione della vostra applicazione web potrà risultare come attaccante che ha pieni diritti sul vostro server IIS.
Questa è l'intera configurazione che è richiesta per supportare Protocol Transition natively on IIS su un server backend Ora potete autentificarvi ad IIS utilizzando un meccanismo di autentica alternativo ed ancora delegare ad un servizio backend simile a come abbiamo configurato IIS e SQL precedentemente
Services For User to Self
Services For User to Self (S4U2S) fornisce l'abilità per un servizio che gira sul server di ottenere un ticket Kerberos per un client, anche se l'utente finale non è stato autentificato attraverso Kerberos. Al posto delle credenziali (Ticket Granting Ticket) o delle credenziali utente (username/password) al KDC, il servizio fornisce le proprie credenziali.
Il token risultante che viene ritornato dipende da come il servizio NT User Rights the service account has. Se il servizio ha SeTCBPrivilege (Act as Part of the Operating System) allora il token ritornato è un Impersonation token. Se il servizio non ha questo privilegio, il token è un Identification token. (TCB in SeTCBPrivilege sta per Trusted Computing Base a.k.a. the trusted kernel of the operating system). Un Identification token può essere utilizzato per determinare il gruppi dell'utente e per validare i suoi diritti di accesso alle risorse. Un token Impersonation permette di accedere agli oggetti kernel mode utilizzando l'identità degli utenti.
Per permettere di utilizzare un Impersonation token di impersonare un utente finale, il servizio deve avere anche il privilegio SeImpersonatePrivilege (Impersonate a Client After Authentication). Se si tenta di impersonare un utente senza questo diritto il token Impersonation viene scalato a Identification token.
Se il servizio ha entrambi i privilegi SeTCBPrivilege e SeImpersonatePrivilege allora il servizio può direttamente impersonare l'user (sul sistema locale) senza avere le credenziali dello stesso o il TGT. Un servizio può fare questo si direttamente richiamando LsaLogonUser (o il costruttore per la classe .NET WindowsIdentity che wraps LsaLogonUser), o relying sul Kerberos SSP fornito da Windows Server 2003.
I Services for User to Self (S4U2S) aiutano a fornire alla Protocol Transition – la capacità di esegure le autentificazione Kerberos anche se l'utente finale si è autentificato su IIS con un protocollo differente.
Services for User to Proxy
I Services for User To Proxy (S4UTP) forniscono la capacità per un servizio di ottenere un ticket Kerberos on behalf of an end user that can be used to authenticate to a remote service. Mentre il protocollo S4U2S visto precedentemente permette ad un servizio di ottenere un Ticket Kerberos, il flag Forwardable non è settato e non permette al servizio di autentificarsi ad un servizio remoto (ad esempio un database backend) on behalf of the end user.
Per ottenere un ticket Kerberos forwardable (i.e. Utilizzabile dal servizio per connettersi ad un altro servizio backend come un database), il flag di delegazione devono essere abilitati in Active Directory.
La serie di eventi è la seguente:
In order for the service to be able to get forwardable tickets on an end user's behalf, a flag needs to be set on the service account’s userAccountControl property in Active Directory: TrustedToAuthenticateForDelegation (T2A4D). This flag has the value 0x1000000 (or 16777216 in decimal).
Note: if the end user had authenticated initially using Kerberos, then this particular flag doesn’t need to be set. We use it only when we are using Protocol Transition and we need to get forwardable tickets.
The T2A4D is new in Windows Server 2003 Active Directory domains. In a Windows 2000 functional level domain, a different flag: TrustedForDelegation (with a value of 0x80000 or 524288 in decimal) is set. This corresponds to the "Trust this computer for delegation to any service (Kerberos Only)" option in a Windows Server 2003 domain (see below). This was the only way to configure delegation in a Windows Server 2000 domain, and is known as "unconstrained delegation".
