NoLabNoPartY.com » iis

Visualizzare il nome utente in una pagina web con IIS 7.5 in Windows 2008

P@olo — Mon, 11 Apr 2011 05:00:00 +0000

La necessità di visualizzare lo username dell’utente connesso ad un determinato sito web spesso è richiesto anche per discorsi di autenticazione (es. Intranet).

Per poter abilitare questa funzionalità in Windows 2008 bisogna comunque configurare il web server IIS opportunamente per poter visualizzare le informazioni nel modo richiesto.

1. PROCEDURA
Per visualizzare lo username dell’utente connesso al sistema, si utilizza un semplice script ASP per ricavare il nome utente da visualizzare nella pagina web.

<%
Dim sUser
‘*** get the users login
sUser = Request.ServerVariables(“REMOTE_USER”)
‘*** remove the domain info up to the “/”
sUser = mid(sUser, 12)
response.write Ucase(sUser)
%>

Inserire lo script nella pagina web in cui si vuole visualizzare il nome utente.

Se si tenta di accedere alla pagina web, lo username non viene ancora visualizzato. Questo succede perchè dobbiamo ancora configurare IIS per utilizzare l’autenticazione.

Dal server Windows 2008 accedere all’Internet Information Services (IIS) Manager e selezionare il web richiesto.

Cliccare nella schermata di destra nella sezione IIS l’icona Authentication.

Impostare l’opzione Anonymous Authentication come Disabled e l’opzione Windows Authentication come Enabled.

Selezionare Windows Authentication e con il tasto destro del mouse cliccare sulla voce Providers.

Affinchè il processo di autenticazione funzioni correttamente, mettere la voce NTLM all’inizio della lista tramite il bottone Move Up.

2. TEST
Tramite il browser accedere nuovamente alla pagina web . Lo username dell’utente connesso viene ora correttamente visualizzato.

Con questa semplice procedura è quindi possibile visualizzare le informazioni inerenti agli utenti che accedono alla pagina web.

Hai già letto questi articoli?

I siti in ASP collegati ad un db Access visualizzano “HTTP Error 500.19 – Internal Server Error” in IIS 7.5

P@olo — Mon, 31 Jan 2011 06:00:00 +0000

Con la diffusione sempre più radicale dei sistemi a 64-bit, alcune applicazioni web scritte utilizzando parti a 32-bit possono soffrire il passaggio alla nuova piattaforma.

Uno degli esempi più comuni è la situazione in cui una pagina web in ASP si appoggia ad un database Access per la visualizzazione di determinate informazioni.

L’errore si manifesta con un messaggio di errore nell’area in cui dovrebbero comparire i dati.

Questa situazione si verifica se sullo stesso server viene installato WSUS versione 64-bit che durante il suo setup sovrascrive il file suscomp.dll.

Per risolvere il problema sono necessarie due operazioni:

Abilitare l’opzione Enable 32-Bit Applications per il sito che presenta il problema.
Disabilitare il modulo di compressione di IIS.

1. PROCEDURA
Lanciare l’IIS Manager da Start –> Administrative Tools –> Internet Information Services (IIS) Manager e selezionare la voce Application Pools nella parte sinistra dello schermo.

Nella parte destra selezionare il sito che manifesta il problema e cliccare (pannello Actions)sulla voce Advanced Settings.

Identificare il menu General (è il primo della lista) ed impostare il parametro Enable 32-Bit Applications a True.

Se WSUS 64-bit non è installato nel sistema, l’abilitare questa opzione permette di ripristinare la funzionalità del sito, altrimenti è necessaria un’azione aggiuntiva.

Lanciando il sito viene visualizzato un messaggio di errore HTTP Error 500.16. Analizzando i dettagli dell’errore, il sistema riporta un Error Code 0x8007007e nella voce Module DynamicCompressionMod.

Per risolvere questa situazione bisogna disattivare il modulo di compressione in IIS. Ricordo che questo si verifica nel caso sia stato installato WSUS 64-bit sullo stesso server.

Per rimuovere il modulo di compressione bisogna eseguire il comando:

%windir%\system32\inetsrv\appcmd.exe set config -section:system.webServer/httpCompression /-[name='xpress']

Lanciare l’istruzione come Administrator (Run as administrator) dalla command line o creare un file per eseguirlo successivamente.

Lanciato il comando, il sistema visualizza il risultato dell’operazione.

A questo punto se il sito viene aperto, le informazioni prelevate dal database tramite ASP sono visualizzate correttamente. Queste modifiche non impattano sulla funzionalità globale del sistema e di WSUS stesso.

Se si avesse la necessità di riabilitare il modulo di compressione, lanciare il comando:

%windir%\system32\inetsrv\appcmd.exe set config -section:system.webServer/httpCompression /+[name='xpress',doStaticCompression='false',dll='%windir%\system32\inetsrv\suscomp.dll']

Il sito adesso viene visualizzato correttamente con gli utenti soddisfatti da un lato e il ritorno della tranquillità nel reparto IT dall’altro.

Hai già letto questi articoli?

Installare NOD32 ERAS su Windows 2008 R2 con mySQL e IIS

P@olo — Tue, 16 Mar 2010 06:49:56 +0000

Proteggere la rete è una degli aspetti fondamentali per la salvaguardia dei dati, specialmente in un ambiente aziendale dove il numero di PC e file “maneggiati” può assumere un aspetto importante. I sistemi antivirus non solo devono essere affidabili ma devono essere sempre aggiornati e notificare tempestivamente gli amministratori di sistema al presentarsi di un qualche problema.

In una rete di una certa dimensione è impensabile gestire il tutto manualmente passando i computer ad uno ad uno per verificare che tutto sia a posto. Centralizzare la gestione diventa quindi una esigenza fondamentale. L’antivirus NOD32 della Eset è un ottimo prodotto che fornisce un elevata percentuale di protezione con una buona gestione in ambito aziendale.

1. INSTALLAZIONE DEI DRIVER ODBC mySQL
Poichè l’installazione del server ERA si deve appoggiare ad un database di mySQL, dobbiamo predisporre il nostro sistema Windows e mySQL per poter comunicare correttamente.

- Innanzitutto scaricare i driver ODBC di mySQL (la versione attuale è la 5.1.x) dal sito http://dev.mysql.com/downloads/connector/odbc/ procedendo poi con la l’installazione.

- Effettuiamo l’installazione Typical installando tutto il pacchetto (32 & 64 bit driver).

Nel database mySQL bisogna creare l’utente che sarà utilizzato dal sistema ERAS per accedere al db. Per motivi di sicurezza, non è una buona idea utilizzare l’account root.

Creare nel server mySQL l’utente eset:

# mysql –u root –p

mysql> CREATE USER eset@’%’ IDENTIFIED BY ‘password’;
mysql> CREATE DATABASE ESETRADB;
mysql> GRANT ALL PRIVILEGES ON ESETRADB.* TO eset@’%’;
mysql> FLUSH PRIVILEGES;

Se non si volesse concedere l’accesso al database da qualsiasi IP (definito da %), specificare dopo ‘@’ l’IP o il nome DNS della macchina dalla quale si vuole accedere.

2. INSTALLAZIONE DI ERAS
Lanciare il setup di ERAS dal file di installazione prelevato dal sito ESET.

- Accettare l’EULA e procedere selezionando come Installation Type l’opzione Advanced.

- Tramite Browse… selezionare il file della licenza fornito da ESET nod32.lic. Next.

- Lasciare come directory di installazione il default proposto e cliccare su OK.

- Nella schermata Select database, selezionare il tipo di database che si intende utilizzare, mySQL nel nostro caso.

- Nella finestra Database server My SQL, impostare i parametri del driver mySQL, del server e l’utente precedentemente.

- Effettuare il Test Connection per verificare che il programma riesce a connettersi con il database correttamente. Cliccare su OK, poi Next per continuare.

- Nella finestra successiva Data Directories accettare il default cliccando su Next.

- In Server name and ports, lasciare le impostazioni di default se non si hanno particolari esigenze. Le porte indicate saranno successivamente impostate nel firewall di Windows.

- In Security settings impostare le password o lasciare il valore di default BLANK. E’ comunque possibile impostarle anche successivamente tramite ERAC.

- Nella schermata Updates digitare lo username e la password fornito da ESET per effettuare gli aggiornamenti.

- Nella finestra SMTP Settings impostare i parametri che rispecchiano il vostro ambiente operativo.

- Impostare il livello di log desiderato. Abilitando Log to OS Application Log, le informazioni vengono copiate nell’Event Viewer i Windows in System.

Se proseguendo con l’installazione, si dovesse presentare un errore simile a quello riportato in figura, la prima cosa da fare è visualizzare il log di installazione tramite il bottone View Log.

Analizzando il file di log, si nota che il sistema si aspetta di trovare il file Create_MYSQLERA.SQL nella directory \Temp\1\.

Tramite una ricerca con Windows Explorer, il file risulta essere presente nel directory \Temp. Copiando semplicemente il file nella directory richiesta \Temp\1\ il problema si risolve.

Dopo questo semplice intervento, riavviare la procedura di installazione nuovamente.

La fase di installazione termina correttamente.

3. CONFIGURAZIONE DEL FIREWALL
Per permettere la comunicazione tra ERAS, ERAC e client, bisogna aprire le porte richieste nel firewall di Windows, cioè TCP 2222, 2223, 2224 e 2846.

4. IMPOSTARE IIS COME SERVER http PER “L’UPDATE MIRROR SERVER”
Per poter utilizzare IIS come server http, bisogna verificare che il server http interno a ERAS sia disabilitato.

- Se precedentemente abilitato, da ERAC cliccare Tools ? Server Options ? Updates e deselezionare l’opzione Provide update files via internal HTTP server. Click su OK.

- Creare un nuovo Sito e specificare come Physical path la directory in cui ERAS scarica gli aggiornamenti C:\ProgramData\ESET\ESET Remote Administrator\Server\mirror e come Port 2221 utilizzata per la comunicazione con i client.

- Verificare in Authentication che la voce Allow anonymous access to this Web site sia Enabled.

- Doppio click su MIME Types per accedere alla configurazione in modo da definire il parametro richiesto da ERAS.

- Cliccare su Add per aggiungere un nuovo tipo e digitare i parametri riportati nella figura:

- Aprire Default Document e cliccare su Disable. Click OK.

- Aprire la porta TCP 2221 nel firewall del Server per permettere la connessione.

- Per verificare che il server http funzioni correttamente, digitare nel browser l’indirizzo: http://IP_Server:2221/Update.ver. Se viene visualizzata la pagina simile a quella in figura, ERAS è operativo per distribuire gli aggiornamenti tramite IIS.

- Per permettere il corretto funzionamento del sistema per la gestione dei client, verificare che nel firewall dei client stessi siano abilitate le porte 135-139 e 445 per la condivisione dei file. Nell’esempio l’opzione nel firewall di Windows XP.

5. INSTALLAZIONE DI ERAC
L’installazione della console ERAC normalmente viene effettuata su una workstation diversa da ERAS (è possibile comunque installarla anche sulla stessa macchina) e non richiede particolari parametri per il suo funzionamento. Una volta terminata l’installazione è sufficiente specificare il server su cui è installato ERAS per poter gestire il sistema.

A questo punto siamo connessi con il server ed è possibile effettuare tutte le operazioni necessarie per configurare il sistema per la nostra rete.

Hai già letto questi articoli?

Configurare WSUS in modalità NLB

P@olo — Mon, 01 Dec 2008 14:00:29 +0000

Con il periodo nero dell’economia mondiale, le aziende stanno facendo un massiccio “cost saving” per arginare i bilanci sempre più critici. Purtroppo il settore IT è quello che più ne fa le spese con pesanti tagli sul budget di investimento informatico.

Le nuove soluzioni da proporre al management per la gestione e implementazione dei sistemi IT sono per il momento da tenere nel cassetto in attesa di tempi migliori… che fare allora? E’ qui che sta anche la bravura dei sistemisti… trovare soluzioni funzionali risparmiando drasticamente sui costi.

Ed ecco che si riafferma, soprattutto per le PMI, una tecnologia per la gestione clients che, onestamente, ho sempre ritenuto efficace: WSUS. Tecnologia Microsoft, WSUS è una soluzione molto valida per la gestione dei sistemi di rete che permette di mantenere un parco macchine aggiornato limitando notevolmente i costi di implementazione e amministrazione poichè non prevede nessuna licenza di utilizzo.

1. DEFINIRE L’AMBIENTE OPERATIVO
Naturalmente per avere questo servizio con determinati standard funzionali, WSUS deve essere opportunatamente configurato in modo da garantire la continuità del servizio (cluster) e prestazioni di rete adeguate (Network Load Balancing) per meglio distribuire il carico del server destinato a svolgere questo ruolo. Per evitare confusione è bene specificare che WSUS in modalità cluster non ha molto senso… è ben più utile per SQL ed Exchange invece.

Prima di procedere con l’installazione di WSUS, bisogna definire l’ambiente operativo per rispettare i termini di continuità e di prestazioni del servizio. Per fare in modo che il servizio sia fault tolerant e per evitare l’overload del server, il database di WSUS (SUSDB) viene “appoggiato” ad un server SQL configurato in modalità cluster mentre WSUS viene installato su un server in modalità NLB. Oggi giorno quasi tutte le aziende sono dotate di uno storage SAN dedicato ai sistemi “core” come Exchange e SQL. Quindi una valida soluzione può essere l’utilizzo di un LUN dedicato del SAN per rendere accessibili in remoto gli aggiornamenti di WSUS.

2. REQUISITI
WSUS richiede per la sua installazione i seguenti requisiti:

IIS 6.0
Microsoft .NET Framework v2.0 Redistributable Package
Microsoft Report Viewer Redistributable 2005
WSUS SP1

3. CONFIGURARE SQL SERVER 2005 PER WSUS
Prima di procedere con l’installazione, è necessario configurare il cluster SQL in modo da operare correttamente con quanto richiesto da WSUS.

L’utente utilizzato per l’installazione di WSUS ha i diritti di amministratore sul Server SQL.
L’opzione Nested Triggers è attiva (default).
- Per verificare, aprire SQL Server Management Studio, fare click col tasto destro sul server nell’Object Explorer e selezionare Properties.
- In Advanced, impostare l’opzione Allow Triggers to Fire Others come True (default) o False.
Windows Authentication deve essere utilizzata in SQL. WSUS supporta solo questa modalità.
Il servizio Remote SQL Connections deve essere impostato come TCP/IP only.

Ricordarsi di specificare come Remote computer da configurare il nome del server virtuale SQL (sqlcluster nella figura) poichè è configurato come cluster.

L’account utilizzato per installare il database utilizzato da WSUS (SUSDB) in SQL deve essere presente in Security -> Login.

4. REGISTRAZIONE SPN
Un parametro fondamentale per il corretto funzionamento dell’accesso remoto al database SQL è la registrazione del service principal name (SPN) per questo server. Senza questa impostazione, si avranno problemi di autenticazione Kerberos e quindi WSUS non riuscirà a stabilire la connessione con il database e i clients non riusciranno a connettersi.

Per effettuare la registrazione di SPN è necessario il tool setSPN.exe che è presente nei Support Tools di Windows Server 2003. Procedere in questo modo:

Installare i Support Tools in un qualsiasi server di dominio e logarsi come Domain Admin.
Dal command prompt eseguire:
- setspn -A MSSQLSvc/
- es. setspn -A MSSQLSvc/sqlcluster sqlservice
Dal command prompt eseguire:
- setspn -A MSSQLSvc/: (port: normalmente è la 1433)
- es. setspn -A MSSQLSvc/sqlcluster:1433 sqlservice
Riavviare il server SQL dopo che la replica AD è stata effettuata.

Per verificare che SPN è stato correttamente registrato, dal command prompt eseguire:

setspn -L

E’ possibile verificare o editare questo parametro utilizzando ADSI Editor che è sempre presente nei Support Tools.

Per verificare che SQL stia effettivamente funzionando con l’autenticazione Kerberos, eseguire la seguente query nel server SQL:

select auth_scheme from sys.dm_exec_connections where session_id=@@spid

Il risultato deve riportare KERBEROS, come illustrato nella figura.

5. INSTALLAZIONE DI WSUS
Installare il primo WSUS server in modo da creare il database SUSDB nel server SQL. Dal command prompt eseguire il programma di installazione:

WsusSetup.exe SQLINSTANCE_NAME=server\instance

Se viene utilizzata l’istanza di default di SQL, specificare solo il nome del server. Per installare altri WSUS front-end servers, eseguire dal command prompt:

WsusSetup.exe /q FRONTEND_SETUP=1 SQLINSTANCE_NAME=server\instance CREATE_DATABASE=0 DEFAULT_WEBSITE=0

Viene installato solo il front-end di WSUS connesso al database SUSDB (precedentemente creato) nel cluster SQL con la porta web impostata su 8530. Una volta terminata l’installazione, l’applicazione richiede la definizione dei parametri operativi (proxy, prodotti, etc.).

Configurare l’area di sharing
Poichè più front-end devono accedere gli stessi contenuti, una buona soluzione può essere l’utilizzo di un LUN dedicato dello storage SAN per salvare i contenuti di WSUS. Naturalmente una qualsiasi area condivisa (Network Share, DFS) è adatta allo scopo.

Appoggiandosi ad un SAN, è necessario installare Microsoft iSCSI nei servers utilizzati per WSUS NLB per assegnare l’area condivisa definendo il disco dedicato (nella figura è indicato come W:\).

Spostare il contenuto di WSUS nell’area di share
Per spostare il contenuto delle directory di sistema di WSUS nell’area di share (SAN in questo caso), è necessario spostare il contenuto dalle directory locali tramite il comando:

cd \Program Files\Update Services\Tools\
wsusutil movecontent sharename logfilename (es. wsusutil movecontent W:\ movelogresult)

Il risultato, come illustrato nella figura, è la creazione delle directory con gli aggiornamenti di WSUS.

6. CONFIGURARE IIS PER I SERVER FRONT-END
Per accedere agli aggiornamenti nell’area condivisa, i server WSUS front-end devono avere IIS configurata opportunamente per permettere l’accesso remoto.

Tramite IIS Manager, impostare l’accesso all’area condivisa.

7. CONFIGURARE NLB
A questo punto è finalmente possibile configurare NLB. Poichè la documentazione in Internet su come implementare NLB è ampia e facilmente reperibile, non viene illustrata in questo articolo.

Terminata la procedura, effettuiamo un check per verificare che NLB sta funzionando. Dal command prompt eseguire il comando nlb query.

Verificati che gli host coinvolti in NLB hanno uno stato CONVERGED, il cluster NLB è operativo e funzionante.

8. CONFIGURARE WSUS CLIENTS
Poichè i clients sono generalmente configurati tramite GPO, il parametro utilizzato per identificare l’Intranet update service location deve essere l’indirizzo del Web virtuale (nlbcluster). nlbcluster è il DNS name del cluster NLB.

9. TESTARE WSUS
Naturalmente prima di mettere in produzione il servizio WSUS con questa configurazione, è opportuno testare il tutto con pochi clients o meglio in un ambiente di LAB per evitare spiacevoli sorprese e forti mal di testa.

Hai già letto questi articoli?

Rights Management Service: gestione del servizio

P@olo — Fri, 18 Jul 2008 10:52:48 +0000

Una volta implementato il servizio RMS, è fondamentale che tutte le componenti siano pienamente funzionanti per limitare al minimo il rischio di failure del sistema e quindi di accesso ai documenti protetti.

Il recupero dei documenti protetti infatti può rivelarsi impossibile dovuto ad una errata configurazione. Un’attenta pianificazione seguita da un’accurata fase di test è quindi fortemente consigliata.

1. CONFIGURAZIONE
Per un funzionamento ottimale di RMS, seguire alcune semplici regole può evitare dei forti mal di testa.

Il servizio RMS non dovrebbe risiedere su domain controller o Exchange server onde evitare il workload dei sistemi con conseguenti rallentamenti dei servizi svolti.
Nel DNS, è opportuno creare un CNAME alias dell’URL definito nell’SCP (Service Connection Point) anzichè il nome del server perchè nel caso di una sostituzione del server o cambio dell’IP del server stesso, il servizio continua a funzionare e non viene interrotto (in configurazione cluster). Si possono utilizzare più CNAME dello stesso url che puntano su diversi server.

Utilizzare un servizio web (IIS) dedicato solo per RMS.
I certificati per la protezione dei documenti vengono emessi basandosi sull’indirizzo e-mail dell’account. Verificare che ad ogni account venga attribuito un indirizzo e-mail.
Per generare il certificato è meglio utilizzare il nome del cluster.
E’ fortemente consigliato che il servizio RMS e il database SQL risiedano fisicamente su due server diversi. Un server SQL generalmente dovrebbe essere configurato in maniera da garantire tempi minimi di ripristino in caso di crash (cluster, backup). Da non dimenticare che tutte le info, certificati e configurazioni risiedono nel database SQL.
Per attivare SCP (registrare l’url in Active Directory) sono richiesti i diritti di Enterprise Admin. Se l’SCP è stato precedentemente registrato e devo re-installare da zero il servizio RMS, SCP va rimosso.

2. RIMUOVERE SCP
Per rimuovere l’SCP, si può procedere tramite la console grafica Windows RMS Administration.

Un altro metodo per effettuare l’operazione è tramite lo snap-in ADSIEDIT.MSC (si trova nei Support Tools in W2K3) connettendosi alla Configuration naming context. Aprire il nodo cn=Services e cancellare il nodo cn=RightManagementService che rimuoverà il Service Connection Point. Attenzione ad utilizzare questo tool.

Come alternativa è possibile utilizzare il DRM Toolkit lanciando il comando:

ADSCPRegister:ADSCPRegister unregisterscp https://my_domain/_wmcs/Certification

Il comando ADSCPRegister permette la registrazione dell’SCP in Active Directory. E’ utile nel caso non si abbiano sufficienti diritti in AD: mando l’istruzione all’Enterprise Admin per farla eseguire ed effettuare quindi la registrazione. Evito inoltre che altri accedano al server.

3. SOSTITUIRE IL SERVER RMS
Se ci troviamo nella situazione di dover sostituire un server impiegato per il servizio RMS (hardware obsoleto, upgrade, etc.), l’operazione è semplice in quanto è sufficiente installare un nuovo server nel cluster e rimuovere il vecchio.

Una volta configurato il nuovo server, questo deve essere aggiunto nel cluster.
Nel vecchio server da rimuovere deve essere fatta l’operazione di unprovisioning (riduzione del numero dei servers nel cluster) che ne azzera la configurazione.
Il CNAME precedentemente impostato nel DNS deve essere aggiornato per far puntare l’URL al nuovo server.
Aggiornare l’eventuale load balancing se impostato.

4. RIMUOVERE IL SERVIZIO RMS
Se spengo il server RMS, tutti i documenti protetti non sono più accessibili. Per la corretta rimozione del servizio RMS deve essere effettuata l’operazione di decommisioning per ripristinare l’accesso ai documenti. Tutti i servers coinvolti devono essere messi in questo stato.

Quando il server è in uno stato di decommissioning, solo le use licenses vengono fornite. Per rimuovere tutte le protezioni è quindi sufficiente aprire il documento protetto e poi salvarlo.

Questa procedura è utile nel caso il progetto pilota non venga approvato.

5. BACKUP E DISASTER RECOVERY
Tutte le informazioni, configurazioni e licenze (chiave pubblica e privata) di RMS risiedono nel database SQL, quindi il backup del database è fondamentale. SQL dovrebbe garantire un sistema di fault tolerance (cluster) per evitare blocchi del servizio e naturalmente una strategia di backup adeguata in base all’utilizzo del servizio.

Stesso discorso vale per il server RMS il quale deve essere adeguatamente protetto contro potenziali failures. Per questo scopo possono essere utilizzati sistemi di ripristino come Ghost, Symantec BackupExec o altri per effettuare un veloce ripristino del server.

L’utilizzo di una configurazione cluster (2 front-end) evita il blocco del servizio a patto che il database sia sempre accessibile e funzionante.