Archivio

Posts Tagged ‘Web Interface’

XenCenterWeb: amministrare Citrix XenServer con un browser

30 Gennaio 2009 Nessun commento

Pur non essendo un gran fanatico delle applicazioni web, poter amministrare i sistemi con un semplice browser senza bisogno di installare nulla è sicuramente una gran comodità. Prosegui la lettura…

Citrix Web Interface 5: dov’è finito il pulsante di refresh?

6 Novembre 2008 Nessun commento

Il nuovo tema “carbon fiber” tutto nero introdotto con la Web Interface 5 è decisamente accattivante. Molti utenti hanno già aggiornato i propri siti, e molti si accingono a farlo. Ma in molti mi hanno domandato dove fosse finito il pulsante di refresh delle applicazioni! Prosegui la lettura…

Deployment del Client ICA tramite Web Interface 4.6 integrata con Access Gateway Advanced

19 Agosto 2008 Nessun commento

A partire dalla versione 4.6 della Web Interface è stato introdotto un nuovo sistema per la verifica e il deploy del Client ICA, che, tra le altre cose, introduce il supporto per Windows Vista. Tuttavia, quando la Web Interface 4.6 è integrata con l’Access Gateway, la verifica e il deployment del Client ICA non sono abilitati.

Prosegui la lettura…

Citrix Web Interface in Silverlight

Qualche giorno fa abbiamo parlato della nuova Web Interface 5 che sarà rilasciata in concomitanza con l’uscita di Delaware. Adesso Andrew Innes pubblica sul blog ufficiale Citrix un interessante articolo sul possibile futuro della Web Interface. Prosegui la lettura…

Come sarà la Web Interface 5.0?

27 Febbraio 2008 Nessun commento

Thomas Koetzing, il cui sito è diventato il riferimento per le modifiche da apportare alle diverse versioni di Web Interface, ci introduce la nuova Web Interface 5.0 che sarà rilasciata con Delaware, la prossima release di XenApp (Presentation Server) compatibile con Windows 2008. Prosegui la lettura…

Disponibile la traduzione in italiano di Citrix Web Interface 4.6 (beta)

12 Dicembre 2007 Nessun commento

Ho deciso di rilascire una versione beta della traduzione della Web Interface 4.6 in italiano, anche se la traduzione non è completa. Prosegui la lettura…

Web Interface for Resource Manager Roadmap

11 Dicembre 2007 Nessun commento

Jason Conger ha annunciato una serie di novità per la sua Web Interface per il Resource Manager. Prosegui la lettura…

Approfondimenti: i certificati SSL e Citrix Secure Gateway (seconda parte)

3 Dicembre 2007 Nessun commento

In questa seconda parte volevo procedere con la generazione di un certificato da utilizzare con il nostro Secure Gateway.

La gestione dei certificati risulta spesso ostica perché si finisce sempre per utilizzare strumenti poco intuitivi e a parlare di formati di certificati strani che confondono solo le idee a chi non è già molto pratico. In realtà l’esperienza sul campo mi ha portato a suggerire sempre di utilizzare gli strumenti di gestione dell’Internet Information Server per gestire i certificati SSL per il Secure Gateway. Questo significa installare IIS sul server dove risiede il nostro Secure Gateway; spesso Web Interface e Secure Gateway risiedono sulla stessa macchina, ma se così non fosse, l’installazione di un IIS inutilizzato non dovrebbe causare problemi.
Utilizziamo IIS per la gestione del certificato, ma in realtà ci interessa lasciare la porta 443 (quella del servizio HTTPS) libera per Citrix Secure Gateway. Dovremo quindi configurare IIS per usare il certificato su una porta diversa, per esempio la 444.

Andando sulle proprietà del sito di default (o di quello su cui abbiamo installato la Web Interface) possiamo iniziare la procedura guidata di creazione di un certificato SSL selezionando il pulsate “Server Certificate” sotto la scheda “Dirctory Security”:
Proprietà IIS Default Web Site

Il primo passo è creare un nuovo certificato:

Crea nuovo certificato

Se il nostro server è inserito in dominio e su Ative Directory è registrata una Certification Authority, possiamo inviare direttamente la richiesta. Spesso il nostro Secure Gateway è inserito in una DMZ e potrebbe anche non essere in dominio: per questo motivo in questo articolo prendiamo in considerazione la via più lunga….

Crea richiesta e inviala più tardi

Scegliamo quindi di preparare la richiesta, ma di non inviarla automaticamente (se non siamo in AD, la seconda opzione è in grigio e non è selezionabile). A questo punto ci vengono richieste le informazioni necessarie alla creazione del nostro certificato.
I primi due parametri da inserire sono il nome de certificato e la sua lunghezza:

Nome certificato e lunghezza

Il nome che inseriamo qui è mnemonico e ci serve per sapere che certificato stiamo creando: non è da confondere con il Common Name, che deve corrispondere al FQDN, che ci verrà richiesto più avanti.
Dobbiamo poi inserire il nome della nostra società e dell’ufficio richiedente:

Azienda e ufficio

Questi valori saranno poi consultabili guardando le proprietà del certificato, quindi è meglio evitare di scrivere valori troppo di fantasia (un certificato richiesto dall’ufficio “pluto” dell’azienda “pippo” potrebbe non essere molto credibile).
Subito dopo ci viene richiesto di inserire il Common Name a cui il certificato fa riverimento:

Common Name

Questa è una delle informazioni più importanti del certificato: è il nome con cui viene chiamato il sito, il fully qualified domain name (FQDN)! Se questo nome non corrisponde al nome internet del nostro Secure Gateway, il certificato non è valido (fallisce uno dei tre test) e il Client ICA non è in grado di stabilire la connessione.
Infine dobbiamo inserire le informazioni geografiche relative alla nostra azienda:

Informazioni geografiche

Anche queste informazioni saranno visibili all’interno del certificato. A questo punto inseriamo il path in cui salvare la richiesta (di default viene salvata sulla radice del disco di sistema) e siamo arrivati alla fine della prima fase di creazione del certificato.

Sommario richiesta certificato

Next e Finish….
Adesso dobbiamo inoltrare la nostra richiesta alla Certification Authority. Di default la CA Microsoft installa alcune pagine web che ci permettono di fare la richiesta del certificato tramite un browser web. Se il server che stiamo usando non è in grado di connettersi via web alla CA, è necessario copiare il file certreq.txt che abbiamo appena creato su un PC in LAN.

Apriamo il browser e andiamo all’indirizzo http://<CA-Server>/certsrv/; nel mio caso il server si chiama DemoDC

Richiesta Certificato

Ovviamente dobbiamo richiedere un certificato….

Advanced request

Di dfault ci verrà proposta la richiesta di un certificato utente, ma a noi server un certificato per il nostro server…. Dobbiamo quindi fare una richiesta avanzata.

Richiesta base64

Apriamo il file certreq.txt che abbiamo creato poco fa (con un doppio click, il file viene aperto nel Blocco Note): il suo contenuto è del testo, per noi illeggibile: in realtà è in formato base64. Selezioniamo quindi la seconda opzione (Submit a certificate request by using a base-64-encoded CMC or PKCS#10 file…)

Certreq.txt

Selezioniamo il testo dal Blocco Note e inseriamolo nel modulo di richiesta.

Form richiesta

Dobbiamo solo verificare il Template del certificato: il nostro certificato serve per un Web Server! Dobbiamo quindi selezionare il Certificate Template e impostarlo sul valore corretto.

Certificato rilasciato

Il nostro certificato è stato rilasciato. In realtà se stiamo usando un utente che non ha i diritti per rilasciare i certificati sulla nostra Certification Authority, è necessario che un utente amministratore si colleghi sul server in questione e, tramite lo snap-in di gestione della Certification Autority, autorizzi il rilascio del nostro certificato; fatto questo dovremo ritornare sulla pagina web della CA e scaricare il certificato (Download CA Certificate….). Ora selezioniamo il formato e scarichiamo il certificato. Se scarichiamo la “certificate chain”, siamo semplicemente scaricando anche il certificato pubblico della (o delle) CA che hanno firmato il nostro certificato. Con il nostro file certnew.cer possiamo ora ritornare sul nostro IIS e processare la richiesta di prima: torniamo nella scheda “Directory Security” del nostro sito e selezioniamo “Server Certificate”.

Process pending request

Selezioniamo il nostro file certnew.cer che abbiamo scaricato dal sito web della nostra Certification Authority:

Certnew.cer

Dobbiamo ora specificare la porta da usare per il traffico SSL. Comq anticipato all’inizio, non ci interessa che IIS usi il certificato direttamente, anzi abbiamo bisogno che la porta 443 sia libera per il Secure Gateway. Selezioniamo quindi una porta diversa, non in uso da altri servizi, come la porta 444.

Porta 444

Abbiamo completato la creazione del nostro certificato che ora è pronto all’uso. L’ultima finestra ci riporta le specifiche del certificato (che dovrebbero essere identiche a quelle del sommario visualizzato nella prima fase):

Sommario Certificato

Leggi anche Approfondimenti: i certificati SSL e il Secure Gateway (prima parte)

Ricerca dei problemi su prodotti Citrix

29 Ottobre 2007 Nessun commento

Citrix ha rilasciato un documento intitolato “Brief Troubleshooting Guide”, una guida per aiutare gli amministratori ad analizzare e individuare problemi sui suoi prodotti. Prosegui la lettura…

Aggiornati alcuni MOD per la Web Interface 4.6

16 Ottobre 2007 Nessun commento

Thomas Koetzing ha aggiornato sul suo sito una serie di modifiche da apportare alla Web Interface per renderle compatibili con l’ultima release, la versione 4.6. Prosegui la lettura…

Internet, sicurezza e Citrix Presentation Server

11 Ottobre 2007 Nessun commento

Ho letto un interessante articolo relativo ai rischi di sicurezza a cui ci si espone utilizzando Presentation Server, Web Interface e altri prodotti Citrix per distribuire le applicazioni e ho pensato di condividere alcune considerazioni. Prosegui la lettura…

SMS Token for Web Interface

10 Agosto 2007 Nessun commento

Girando sul sito di Thomas Koetzing ho trovato un’interessante news per tutti coloro che stanno cercando una soluzione di autenticazione forte per la Web Interface.
Si tratterebbe di un’implementazione free di un sistema che invia tramite SMS i token per l’accesso alla Web Interface. In sostanza l’utente si collega alla classica pagina, inserice utente e password di dominio e viene rediretto su di una pagina dove dovrà inserire il token ricevuto via SMS. Il tutto totalmente integrato in Active Directory!!!

Il prodotto sembrerebbe utilizzare dei gateway SMS accessibili via http (solitamente servizi esterni, a pagamento) per far inviare alla stessa Web Interface il messaggio con il token.

L’articolo fa riferimento all’autore, Claus Isager, e al suo sito (http://www.isager.dk) che però sembra essere irraggiungibile almomento.