Problema PEC

I provider di PEC sono stati obbligati a passare al protocollo TLS 1.2. Chi usasse versioni vecchie di Outlook (fino alla 2010) molto probabilmente non riuscira piu a scaricarla dal proprio client. Occorre fare una modifica al registro.
Copiate le righe sotto in un file di testo e salvatelo con estensione .reg.
Doppio click ed aggiungete al registro


Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client]
"DisabledByDefault"=dword:00000000

AZURE AD Connect manual sync

Se dovesse essere necessario forzare un aggiornamento manuale di Azure AD Connect per via di qualche aggiornamento.


Aprire powershell come administrator
Enter-PSSession -ComputerName srvaepweb
Import-Module ADSync

Start-ADSyncSyncCycle -PolicyType Delta (solo modifiche parziali)
Start-ADSyncSyncCycle -PolicyType Initial (sincronizzazione completa)

Exit

p.s. cercate di ricordarvi di chiudere sempre le sessioni che aprite, per abitudine. Se dimenticate di chiudere le sessioni, ad esempio quando vi collegate in O365, prima o poi riceverete il messaggio di troppe sessioni aperte.

REFERENCE
https://community.spiceworks.com/how_to/140656-manually-force-sync-azure-ad-connect-using-powershell

DAC - Gestione avanzata dei permessi di accesso ai file

Come e' possibile consentire l'accesso a dei file ad utente quando questo accede tramite il proprio PC aziendale, ma non quando lo fa da una postazione esterna?

Per fare questo ci puo aiutare il DAC, che da Windows server 2012 R2 si e' evoluto aggiungendo la compound authentication (
Essenzialmente il DAC si basa claim e resource properties, estendendo le proprieta dei ticket kerberos.

In reference trovate una serie di articoli sull'argomento, molto chiari sull'argomento.

REFERENCE
https://www.petri.com/dynamic-access-control-dac-introduction
https://www.petri.com/dynamic-access-control-dac-kerberos-claim-types-resource-properties
https://www.petri.com/dynamic-access-control-dac-configure-deploy-central-access-policy

WINDOWS SERVER TIME SETTING - DOMAIN

Con il cambio dell'ora, uno degli argomenti che spesso torna in auge, e' la sua corretta impostazione in una rete.
In una rete a dominio una delle prime cose da mettere a punto e' l'impostazione dell'ora. Questo perché e' fondamentale nel processo di autenticazione.
Molto in breve e necessario fare in modo che il controller di dominio che detiene il ruolo FSMO PDC, si sincronizzi con una sorgente esterna autorevole (ES: ntp.inrim.it, pool.ntp.org ecc. ecc.), e fare si che tutti gli altri membri di dominio (domain controller, server membri e client) si sincronizzino con esso (agendo di fatto come client), considerandolo come fonte autorevole dell'ora per il dominio.
Di solito la sola operazione da effettuare e' la prima, sul PDC. I client sono in grado di sincronizzarsi in modo nativo con il PDC.
Se questi non dovessero sincronizzarsi con quest'ultimo, allora potrebbe essere necessario intervenire anche su queste impostazioni. Nella mia esperienza, il problema che alcune volte ho incontrato era il servizio ora di Windows non avviato.
Vi riporto in breve i passi necessari per impostare il PDC ed alcuni riferimenti, molto ben fatti, che vi consiglio di leggere.

WINDOWS TIME: COPIA DELLE IMPOSTAZIONI
regedit
HKLM\SYSTEM\CurrentControlSet\Services\w32time

WINDOWS TIME: RESET A DEFAULT
net stop w32time
w32tm /unregister
w32tm /register
net start w32time

WINDOWS TIME: IMPOSTAZIONI PDC

w32tm /config /syncfromflags:manual /manualpeerlist:"0.it.pool.ntp.org,0x8 1.it.pool.ntp.org,0x8 2.it.pool.ntp.org,0x8 3.it.pool.ntp.org,0x8 ntp.ien.it,0x8" /reliable:yes /update

W32tm /resync /rediscover
net stop w32time && net start w32time

WINDOWS TIME: VERIFICA DELLE IMPOSTAZIONI
w32tm /query /configuration
w32tm /query /status

WINDOWS TIME: VERIFICA DEL FUNZIONAMENTO
w32tm /monitor

NOTE:
Possibilmente evitate quello di default time.windows.com, con cui piu volte ho avuto problemi.
In caso di macchine virtuali, ricordate di disattivare la sincronizzazione dell'ora con l'host.

REFERENCE
https://www.itpromentor.com/time-sync/
https://www.windowserver.it/2011/02/active-directory-configurare-windows-time-service/
https://support.microsoft.com/it-it/help/816042/how-to-configure-an-authoritative-time-server-in-windows-server
https://defaultreasoning.com/2009/11/16/synchronize-time-with-external-ntp-server-on-windows-server-2008-r2/
https://blogs.msmvps.com/acefekay/2009/09/18/configuring-the-windows-time-service-for-windows-server/

https://docs.microsoft.com/it-it/windows-server/networking/windows-time-service/windows-time-service-tools-and-settings

EXCHANGE MIGRATION ENDPOINT - OFFICE 365 HYBRID

In questi giorni sto effettuando una migrazione ibrida da SBS2011 ad Office365. Il primo problema con cui ho avuto a che fare e' stata la creazione di un migration endpoint in Office365.

Il problema dipendeva dal certificato usato in Exchange, non emesso da una CA valida (usavo un certificato emesso da SBS2011 come certification authority). Dopo aver rimpiazzato il certificato con uno emesso da una CA pubblica sono riuscito a crearlo senza problemi.
In generale, visto il costo abbastanza basso dei certficati SSL SAN e wildcard, conviene sempre usarli, soprattutto se il nostro exchange server deve essere raggiungibile dall'esterno usando smartphone ed altri dispositivi.
Nel mio caso ho usato un certificato SAN con tre nomi:
mail.domain.com
autodiscover.domain.com
domain.com
In caso di un singolo exchange tre nomi sono piu che sufficienti.

Inoltre nel mio caso ho usato un certificato SSL emesso da Let's Encrypt, che ha il vantaggio di essere gratuito (e gli svantaggi di durare solo 90 gg. e di poter essere ottenuti solo tramite una procedura leggermente più macchinosa da mettere in piedi).

Una volta ottenuto il certificato in Exchange e' necessario assegnarlo ai servizi (SMTP e IIS e POP3/IMAP se usati). Eseguire un iisreset, in caso di problemi.

A queso punto dobbiamo effettuare una serie di operazioni principalmente in tre ambiti.

DNS
Impostare i nomi DNS necessari, per il server di posta e per l'autodiscover. Verificare tramite il sito https://testconnectivity.microsoft.com che non ci siano problemi e nel caso risolverli.

ON PREMISES
Abilitare il servizio di replica delle cassette postali (e metterlo in avvio automatico)
Nome del servizio:
MSExchangeMailboxReplication
Servizio di replica delle cassette postali di Microsoft Exchange (in italiano)

Abilitazione dell'MRS PROXY
Per verificarne lo stato:
Get-WebServicesVirtualDirectory |fl
Per abilitarlo:
Get-WebServicesVirtualDirectory |Set-WebServicesVirtualDirectory -MRSProxyMaxConnections 50 -MRSProxyEnabled $true
E' possibile verificarne il funzionamento anche tramite browser, tramite il seguente link:
https://ExchangeFQDN/EWS/mrsproxy.svc
In questo modo si può verificare il certificato usato ed eventualmente la validità.

OFFICE365
Andare in recipients - migration.
Premendo sui tre puntini, scegliere migration endpoint. Premere su ADD - Exchange remote e compilare i campi.
Ricordarsi di usare un utente che sia amministratore di Exchange

N.B. i certificati di let's encrypt potrebbero avere qualche problema con i dispositivi mobile.

REFERENCE:
https://www.petenetlive.com/KB/Article/0001358
https://letsencrypt.org/
https://www.ictpower.it/guide/implementazione-di-lets-encrypt-in-ambiente-windows-server-2016.htm

CERTIFICATI SSL - LET'S ENCRYPT

Let's Encrypt e' una CA pubblica ufficialmente riconosciuta legata al mondo dell'open source.
Tramite di essa e' possibile ottenere dei certificati SSL validi (emessi da una CA pubblica).

VANTAGGI:
 - Gratuito

SVANTAGGI
 - durano solo 90 gg.
 - non esiste un client ufficiale in ambito Windows.
 - certificati validi solo per la domain validation (es: siti web)

In questo caso vorrei installare un certificato SSL ottenuto da let's encrypt in Exchange. Per farlo, ho installato il client Windows di CertifyTheWeb (https://certifytheweb.com x scaricare il client) sul server Exchange. Affinché la procedura funzioni deve essere presente un server IIS. Dopo aver installato il client e' necessario effettuare una registrazione inserendo un indirizzo email (nel mio caso ne ho usato uno attinente al dominio) e quindi impostare un server web (IIS/default web site). A questo punto e' possibile far rilevare automaticamente i domini, e nel caso aggiungerli. Impostare un nome primario e procedere con la richiesta. Usare il metodo HTTP01, che e' quello più rapido. Nel default web site viene creata una directory/store chiamata .well-known, usata per la transazione ACME (il protocollo usato per parlare con let's encrypt per ottenere il certificato).
Per verificare se la procedura ha funzionato si puo andare in IIS/default web site/tasto dx/bindings.
Il certificato appena creato apparirà' nei binding per il protocollo htts. Il binding https viene aggiunto automaticamente, se non già presente. In alternativa si puo aprire un browser qualsiasi e verificare il certificato in uso.

P.S. se non ho letto male, ad oggi, per ottenere un certificato wildcard occorre usare il metodo DNS01, che prevede la creazione manuale di un record txt nella zona DNS del dominio. Il problema di questo metodo e' l'impossibilita di abilitare l'auto rinnovo del certificato.

N.B. i certificati di let's encrypt potrebbero avere qualche problema di funzionamento con dispositivi mobile e smartphone.

REFERENCE:
https://www.petenetlive.com/KB/Article/0001358
https://letsencrypt.org/
https://certifytheweb.com/
https://www.ictpower.it/guide/implementazione-di-lets-encrypt-in-ambiente-windows-server-2016.htm

OFFICE 365 SMTP RELAY

1 - SMTP CLASSICO (serve una licenza)

Usando le credenziali di utente di office 365
In questo caso e' necessario usare l'smtp autenticato:

smtp.office365.com/587 0 25
username utente di office 365
password password di office 365

2 - DIRECT SEND (non serve una licenza)

Nel caso in cui fosse presente qualche device es: stamapnti multifunzione, e' possibile usare il direct send
Questa modalita consente di spedire solo agli indirizzi interni del tenant e non ad utenti esterni (es: gmail.com, libero.it ecc. ecc.)
Per impostare il direct send occorre usare, come smtp, il valore riportato nel record MX (ES: dominio-it.mail.protection.outlook.com)
Inoltre e' necessario aggiungere gli ip pubblici da cui si esce in internet (da cui il device che spedisce esce!) al record SPF.

Normalmente il record spf dovrebbe essere qualcosa del tipo:

v=spf1 include:spf.protection.outlook.com ~all

occorre aggiungere anche il proprio ip pubblico (assicuratevi che sia statico)

v=spf1 ip4:10.5.3.2 include:spf.protection.outlook.com ~all

SMTP: dominio-it.mail.protection.outlook.com
Port: 25 (TLS/StartTLS Enabled)
Email: Any email address for one of your Office 365 accepted domains. This email address does not need to have a mailbox.


3 - SMTP RELAY (all'antica :) )
Questo dovrebbe essere il piano B, da usare solo se le opzioni sopra non funzionano!
Il vantaggio rispetto al DIRECT SEND e' di poter spedire anche ad indirizzi esterni all'organizzazione.

SMTP: dominio-it.mail.protection.outlook.com
Port: 25 (TLS/StartTLS Enabled)
Email: Any email address for one of your Office 365 accepted domains. This email address does not need to have a mailbox.

Connettore
Creare un connettore:
Da: Your organization's email server
A: Office 365
Domain restrictions: IP address/range (inserire i propri IP pubblici)

Anche in questo caso aggiungere il proprio range di ip pubblici al record SPF in DNS

v=spf1 include:spf.protection.outlook.com ~all

occorre aggiungere anche il proprio ip pubblico (assicuratevi che sia statico)

v=spf1 ip4:10.5.3.2 include:spf.protection.outlook.com ~all

Se, per esempio lo si dovesse usare per spedire email da un sito creato ed ospitato su un provider (insomma esterno alla rete), anche l'ip pubblico del sito deve essere aggiunto al record SPF. Si imposta la restrizione per l'ip da cui si spedisce nel connettore

REFERENCE:
https://docs.microsoft.com/en-us/exchange/mail-flow-best-practices/how-to-set-up-a-multifunction-device-or-application-to-send-email-using-office-3