Outlook Anywhere (già RPC over HTTPS nelle versioni precedenti di Exchange) è una caratteristica che permette a utenti che non sono fisicamente in azienda, di utilizzare il proprio Outlook per gestire la posta elettronica così come se fossero fisicamente connessi alla LAN aziendale.

Sfortunatamente l’attivazione di questo servizio non è un semplice wizard avanti-avanti-avanti come spesso Microsoft ci ha abituati.

Innanzitutto nel caso si voglia autogenerare il certificato SSL dobbiamo prevedere l’installazione di una CA su un server (normalmente io scelgo il server di dominio) tramite la gestione ruoli/funzionalità del server, aggiungendo il ruolo “Servizi certificati di Active Directory”.

 

 

Volendo è possibile installare anche la parte web che fornisce una semplice interfaccia per l’invio delle richieste di nuovi certificati ed il download di quelli emessi.

 

A questo punto dalla management shell del server Exchange possiamo generare una richiesta di nuovo certificato grazie a questo comando:

 

New-ExchangeCertificate –GenerateRequest –Path c:\myReq.csr –KeySize 1024 –SubjectName “c=paese, s=provincia, l=città, o=azienda, ou=reparto, cn=nomecomune*” –PrivateKeyExportable $True

 

Dove nomecomune* è il FQDN a cui si raggiungerà il CAS del server Exchange dall’esterno (normalmente una cosa tipo webmail.azienda.com o owa.azienda.com…).

Questo comando genera una Certificate Signing Request (csr appunto) che se aperta con il blocco note appare più o meno così:

 

-----BEGIN NEW CERTIFICATE REQUEST-----
MIIC0jCCAjsCAQAwWzEaMBgGA1UEAwwASD5jb21hbHNwYS5jb20xETAPBgNV
BAsMCGNvbWFsc3BhMQswCQYDVQQHDAJiZzEQMA4GA1UECAwHY29sb2dubzELMAkG
A1UEBhMCasdADSASAJKoZIhvcNAQEBBQADgY0AMIGJAoGBALMQXnR6FLZx2S0V
02B6Iasre8wvj46UylghjfZ9Ii4xjIKFLRDNszeTwrkXJBXQzMOUxzcJBlobZMHq
V7HzPmtWZ5CS+d6JCGW2ClxdaJB5hG0BfChGtTmQnwJAOGUFckYMJyi0XQd3p+8u
88/2aEJyENDUw+V/FVLAAxjASDVJAgMBAAGgggE1MBoGCisGAQQBgjcNAgMxDBYK
Ni4wLjYwMDIuMjBMBgkqhkiG9w0BCQ4xPzA9MA4GA1UdDwEBASDASDEADSdsa
HRMBAf8EAjAAMBASLKJDHALKJBRykJrIZ/qDT8hKTE2DNSSMHtnn5zBVBgkrBgEE
AYI3FRQxSDBGAgEFDBlTUlZFWENIMks3LmNvbWFsc3BhLmxvY2FsDBZDT01BTFNQ
QVxhZG1pbmlzdHJhdG9yDA5wb3dlcnNoZWxsLmV4ZTByBgorBgEEAYI3DQICMWQw
YgIBAR5aAE0AaQBjAHIAbwBzAG8AZgB0ACAAUgBTAEEAIABTAEMAaABhAG4AbgBl
AGwAIABDAHIAeQBwAHQAASDAEWDAAKJSHDLKCAAUAByAG8AdgBpAGQAZQBy
AwEAMA0GCSqGSIb3DQEBBQUAA4GBAGLUXpm9pBpzpDJmv1g4MYFUdZccX1c68H/l
JE1DeJG82OxZdTj+67nE6SNjQ5tH+pUvPaZQ1rerNpxVHh5TecQPANOWk70p0aKS
l1c6PJ9ztDebAgc++ASDEEADA/ae7XTQ
EsTUMqN2

-----END NEW CERTIFICATE REQUEST-----

 

Se si utilizza una Certification Authority di terze parti sarà necessario inviare il file .csr secondo le indicazioni della CA scelta; se invece decidiamo di autogenerarci il certificato apriamo lo snap-in “Autorità di certificazione (locale)” sul server dove è stata installata; tasto destro sulla CA/tutte le attività/Invia nuova richiesta.

 

 

Diamo in pasto al servizio il file .csr salvato e a questo punto lo troveremo nella sottocartella “Richieste in sospeso”.

Tasto destro sulla richiesta e poi “Emetti certificato”. Ora il certificato passerà nella sottocartella “Certificati emessi”.

Tasto destro sul certificato/tutte le attività/esporta dati binari ci permetterà di salvare il file a cui daremo estensione .cer che rappresenta il certificato emesso. Aprendo il certificato comparirà una scheda simile a questa

 

 

Torniamo ora sulla management shell di Exchange ed eseguiamo il comando:

 

Get-ExchangeCertificate | fl | out-file –filePath c:\certificati.txt

 

Che genera un file il cui contenuto può essere simile a questo, dove vengono elencati i certificati installati sul server (nel caso specifico si tratta del certificato autogenerato da Exchange all’installazione):

 

AccessRules        : {System.Security.AccessControl.CryptoKeyAccessRule, System
                     .Security.AccessControl.CryptoKeyAccessRule, System.Securi
                     ty.AccessControl.CryptoKeyAccessRule, System.Security.Acce
                     ssControl.CryptoKeyAccessRule}
CertificateDomains : {HOSTNAME, HOSTNAME.domain.local}
HasPrivateKey      : True
IsSelfSigned       : True
Issuer             : CN=HOSTNAME
NotAfter           : 17/11/2010 11.39.03
NotBefore          : 17/11/2009 11.39.03
PublicKeySize      : 2048
RootCAType         : None
SerialNumber       : 09C2D1123141244F2E1A2BC5C77FD0
Services           : IMAP, POP, IIS, SMTP
Status             : Valid
Subject            : CN=HOSTNAME
Thumbprint         : 89794E7D1337B14A9797B5DC34B24C0567C5AD3F

 

Noi ci concentreremo sul Thumbprint che è l’identificatore che ci permetterà di rimuovere il certificato esistente (valido o scaduto che sia) tramite il comando Powershell:

 

Remove-ExchangeCertificate –thumbprint 89794E7D1337B14A9797B5DC34B24C0567C5AD3F

 

Siamo pronti ad importare il nuovo certificato tramite il comando:

 

Import-ExchangeCertificate –path c:\certificato.cer –FriendlyName “friendlyname*”

 

Io come friendlyname* normalmente metto il FQDN del CAS di Exchange 2007 (posta.dominio.com per esempio)

Il sistema risponde indicandoci il thumbprint del certificato installato che utilizzeremo ora per abilitare il servizio IIS al certificato tramite il comando:

 

Enable-ExchangeCertificate –Thumbprint XXXXXXXXXXXXXXXXXXXXXX – Services IIS

 

Lato Certificati server i giochi sono fatti. Ciononostante lato client se cerchiamo di accedere all’indirizzo https dell’OWA vedremo che ci viene segnalato un errore di certificato. Nel caso specifico il client non riconosce come attendibile la Certification Authority che ha generato il certificato che pure è valido.

Per aggirare l’ostacolo dobbiamo recuperare il certificato della CA aprendo il solito snap-in dell’”Autorità di certificazione” e facendo tasto destro/proprietà sulla CA comparirà una scheda simile a questa:

 

 

Sceglieremo quindi “Visualizza Certificato”; da notare come nella scheda del certificato, questo risulti autogenerato in quanto “emesso da” ed “emesso per” sono lo stesso soggetto

 

 

Spostandosi sul tab dettagli è possibile usare il tasto “Copia su file” per salvare il certificato da distribuire ai client:

 

 

Lato client sarà sufficiente aprire il certificato e premere “Installa certificato”. Seguendo il wizard di installazione è necessario specificare l’archivio di installazione selezionando “Autorità di certificazione radice attendibili”.

 

 

Al termine della procedura un avviso ci avvertirà che stiamo facendo una operazione rischiosa per la sicurezza in quanto decidiamo di fidarci dei certificati emessi da una CA non nota. Accettiamo e proseguiamo.

Se ora apriamo la pagina dell’Outlook Web Access vedremo che il certificato è considerato valido.

 

Questo è il primo passo, ora configuriamo il server per l’Outlook Anywhere.

Innanzitutto aggiungiamo la funzionalità “Proxy RPC su HTTP” dalla gestione ruoli e funzionalità del server Exchange

 

 

A questo punto si può utilizzare il wizard presente nella Management Console di Exchange 2007 per l’attivazione della funzionalità Outlook Anywhere (nello screenshot la voce cita “Disabilita” perchè già abilitata):

 

 

l’unica richiesta che viene fatta è quella di specificare il FQDN a cui si raggiungerà il CAS di Exchange (è l’indirizzo cui abbiamo associato il certificato) e il tipo di autenticazione che vogliamo, qui scegliamo “Autenticazione di base”. Lasciamo vuoto il flag che riguarda la ripartizione del carico di lavoro (SSL).

Terminata questa procedura, dovremo attendere qualche minuto (una quindicina al massimo) finchè nel registro eventi applicazioni non troveremo una entry con Event ID 3006 come questa:

 

 

A questo punto sarebbe necessario passare alla configurazione del client Outlook. Purtroppo però non è così, infatti a causa di un problema con l’RPC over HTTP di Windows Server 2008, questo non è in grado di comunicare con la porta 6004 sull’indirizzo di loopback IPv6. Passiamo subito alla soluzione, lasciando per chi vuole qualche indirizzo dove approfondire la problematica qui e qui.

Dobbiamo per prima cosa disabilitare l’IPv6 andando nelle impostazioni della scheda e togliendo la spunta al protocollo; purtroppo questo non è sufficiente e dobbiamo, tramite editor di registro, andare nella chiave HKLM\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters e creare un nuovo D-WORD a 32bit con nome DisabledComponents e valore 0xff (255 decimale) il che disabilita IPv6 su tutte le interfacce e su tutti i tunnel, ma sfortunatamente si dimentica di disabilitare l’interfaccia di loopback. Per far questo apriamo il file host e disabilitiamo con il simbolo # la riga

 

::1   localhost

 

Aggiungiamo anche due nuove entry con l’IPv4 del server Exchange e il nome NETBIOS e il FQDN nel dominio locale:

 

192.168.90.100   HOSTNAME

192.168.90.100   HOSTNAME.dominio.local

 

Ora è necessario riavviare per permettere al sistema di leggere le nuove impostazioni. E’ importante verificare che ora un ipconfig mostra soltanto la configurazione IPv4 e non tutti i tunnel.

A questo punto è sufficiente configurare Outlook per effettuare la connessione tramite RPC over HTTPS e il gioco è fatto. Per verificare sarà sufficiente lanciare Outlook con il comando “outlook /rpcdiag”, inserire le credenziali di dominio e controllare che lo stato della connessione sia simile a questo:

 

 

 

Il gioco è fatto, con un po’ di fatica certo, ma è fatto.

Un cliente ha paciosamente giocato con i permessi sulle cartelle pubbliche del suo Exchange 2003 (installato sul DC!) e subito dopo è arrivata la chiamata superallarmata che "non si vedono più le cartelle pubbliche, neanche sul gestore di sistema di Exchange"... grazie al c...ielo ho tempo di darci un occhio stamattina :)
Nel gestore di sistema noto che le "Cartelle" sono vuote:

  
Preoccupato noto anche che nel primo gruppo di archiviazione il database delle cartelle pubbliche è disinstallato:

 
Tentando di installarlo (tasto destro sul db e poi "installa archivio") si ottiene un errore: "The store could not be mounted because the Active Directory information was not replicated yet. You can either: press Cancel and mount store later from its context menu or, press Retry to let Exchange System Manager keep trying to mount store for you." legato alla replica di Active Directory (!?).
Se si “ritenta”, l'errore conseguente è "The Microsoft Exchange Information Store service could not find the specified object. ID no:c1041722".

Nell'application log della macchina vengono loggati l'eventid 8197:
Errore durante l'inizializzazione della sessione per la macchina virtuale NOMESERVER. Numero di errore: 0x8004011d. Assicurarsi che l'Archivio di Microsoft Exchange sia in esecuzione.

particolarmente criptico; e l'event id 9519:
Errore 0x8004010f durante l'avvio del database "Primo gruppo di archiviazione\GUID" nell'Archivio informazioni di Microsoft Exchange.

Compatibilmente con la kb Microsoft http://support.microsoft.com/kb/823017 il problema può comparire se sulla radice delle cartelle pubbliche viene vietato l'accesso al gruppo Everyone.
A questo punto ovviamente le cartelle pubbliche non sono più visibili dal gestore del sistema, quindi il problema deve essere risolto con un diverso strumento.

Innanzitutto per verificare che il problema sia esattamente quello qui riscontrato è sufficiente eseguire dal prompt dei comandi:
DSACLS "CN=Public Folders,CN=Folder Hierarchies,CN=Primo gruppo amministrativo,CN=Administrative Groups,CN=Prima organizzazione,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=NOMEROOTDOMINIO,DC=local" > c:\PfPerms.txt

Nel file risultante verificare che sia presente una riga in cui compare DENY associato al gruppo Everyone:
Deny  Everyone    FULL CONTROL

Se è così sarà sufficiente eseguire, sempre dal prompt, il comando:
DSACLS "CN=Public Folders,CN=Folder Hierarchies,CN=Primo gruppo amministrativo,CN=Administrative Groups,CN=Prima organizzazione,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=NOMEROOTDOMINIO,DC=local" /I:T /R EVERYONE

Rilanciando il gestore del sistema è ora possibile montare il database e quindi rivedere e maneggiare (magari con più attenzione) i permessi sulle cartelle pubbliche.

Come da oggetto, dopo aver installato automaticamente gli ultimi aggiornamenti sul server, tutti i client Outlook 2007 (sia in cached mode che non, questi ultimi se erano configurati per scaricarsi la OAB) continuano a chiedere le credenziali per accedere al servizio remote.sitodelcliente.com che è l'HOST DNS che punta all'indirizzo pubblico nattato sul CAS Exchange 2007. Anche inserendo le credenziali corrette Outlook continua a fare la medesima richiesta. Premendo annulla, annulla, annulla per un po' la richiesta scompare, per tornare alla carica dopo qualche minuto o quando si forza l'invio/ricezione.
Questo comportamento è riscontrato sia per gli utenti connessi in LAN che per quelli con OutlookAnyware configurato ma con macchina in rete LAN; al contrario chi ha il portatile configurato con OutlookAnyware e si trova fuori dall'azienda non riscontra il problema.
Dopo aver ricreato la OAB, rifatta la directory virtuale dell'IIS della OAB e aver verificato che tutti i servizi web di SBS fanno riferimento come uri pubblico a remote.sitodelcliente.com (quello indicato nel certificato di protezione), scopro navigando su social.technet.microsoft.com che il problema nasce da una impostazione che sul mio SBS 2008 non era configurata correttamente.

Si tratta di aprire la configurazione del sito "SBS Web Applications"  


Sotto l'application Autodiscover, scegliere  “Autenticazione”, tasto destro su "Autenticazione Windows" e poi "Impostazioni Avanzate". Il flag "Abilita autenticazione in modalità kernel" deve essere abilitato 

 
La stessa configurazione va replicata sulle directory RPC, EWS e OAB