Archivi categoria: network

SBS 2003 to exchange 2010 mailbox move – MapiExceptionNetworkError: Unable to make connection to the server

La scorsa settimana ho seguito una migrazione tra un vecchio SBS 2003 ed un più recente exchange 2010. Dopo aver configurato un po’ di cose sul nuovo server di posta volevo fare qualche test per vedere se il routing delle mail funzionava correttamente (a volte capita che il routing group tra 2003 e 2010 che viene configurato in automatico in fase di installazione non si comporti in maniera corretta). Provo a spostare una mailbox di test (Assyrus) dal server sbs2003 all’exchange 2010 tramite una move-request ma subito mi viene restituito questo errore:

Summary: 1 item(s). 0 succeeded, 1 failed.
Elapsed time: 00:00:00
Assyrus
Failed

Error:
MapiExceptionNetworkError: Unable to make connection to the server. (hr=0x80040115, ec=-2147221227)
Diagnostic context:
……
Lid: 12696 dwParam: 0x6BE Msg: EEInfo: Generation Time: 2016-02-09 08:57:26:726
Lid: 10648 dwParam: 0x6BE Msg: EEInfo: Generating component: 18
Lid: 14744 dwParam: 0x6BE Msg: EEInfo: Status: 0
Lid: 9624 dwParam: 0x6BE Msg: EEInfo: Detection location: 290
Lid: 13720 dwParam: 0x6BE Msg: EEInfo: Flags: 0
Lid: 11672 dwParam: 0x6BE Msg: EEInfo: NumberOfParameters: 1
Lid: 12952 dwParam: 0x6BE Msg: EEInfo: prm[0]: Long val: 0
Lid: 53361 StoreEc: 0x80040115
Lid: 51859
Lid: 33649 StoreEc: 0x80040115
Lid: 43315
Lid: 58225 StoreEc: 0x80040115
Lid: 50835
Lid: 62321 StoreEc: 0x80040115
Lid: 47987
Lid: 50033 StoreEc: 0x80040115
Lid: 52465 StoreEc: 0x80040115
Lid: 60065
Lid: 33777 StoreEc: 0x80040115
Lid: 59805
Lid: 52209 StoreEc: 0x80040115
Lid: 56583
Lid: 52487 StoreEc: 0x80040115
Lid: 19778
Lid: 27970 StoreEc: 0x80040115
Lid: 17730
Lid: 25922 StoreEc: 0x80040115

Exchange Management Shell command attempted:
‘DomainName.local/MyBusiness/Users/SBSUsers/Assyrus’ | New-MoveRequest -TargetDatabase ‘DB1’

Elapsed Time: 00:00:00

Faccio qualche verifica per cercare di capire cosa possa esserci lato networking che impedisca la comunicazione tra i due server che sono sulla stessa subnet e che risolvono entrambi correttamente i nomi. Penso a cosa possa esserci di differente rispetto a tutte le altre migrazioni di exchange in cui mi sono imbattuto… mh secondo me c’è qualcosa in sbs che rompe le scatole…

Mi viene in mente che nella suite Small Business Server 2003 era presente come componente anche ISA 2004 (non ricordo se veniva installato in automatico di default o se si poteva installare opzionalmente) ed in effetti c’era la console di gestione a disposizione, provo un po’ a guardare eventuali regole e vedo che ci sono una serie di filtri di default che non ho idea di cosa facciano ma che molto probabilmente bloccano qualcosa. Escludo a priori alcuni di questi filtri come causa e poi provo a disabilitarne alcuni altri e finalmente trovo la causa del problema: “RPC Filter”!

Disabilitando quello sono finalmente riuscito a spostare le mailbox dall’sbs 2003 all’exchange 2010.

ISA2004

L'articolo SBS 2003 to exchange 2010 mailbox move – MapiExceptionNetworkError: Unable to make connection to the server sembra essere il primo su ITXPerience.

Windows 10 network adapters missing after upgrade

Questo è successo ad un mio collega che ha deciso di aggiornare il suo pc con a bordo windows 8.1 a windows 10. Al termine del processo di aggiornamento, concluso senza errori, il sistema operativo non vedeva più correttamente i dispositivi di rete (sia wifi che ethernet) lasciando il pc senza connettività.

Controllando in device manager le schede di rete erano presenti e sembrava tutto ok, mentre andando a controllare in network connections non era presente alcuna connessione:

windows10_adapters_blank

La soluzione è quella di eliminare questa chiave di registro tramite regedit (mi raccomando non eliminatela da riga di comando altrimenti non funziona, non viene cancellata):

HKCRCLSID{988248f3-a1ad-49bf-9170-676cbbc36ba3}

e poi lanciare questo comando:
netcfg -v -u dni_dne

Questa è la KB di riferimento microsoft, parla di reti wireless ma in realtà si applica a qualsiasi tipo di connettività: https://support.microsoft.com/it-it/kb/3084164

L'articolo Windows 10 network adapters missing after upgrade sembra essere il primo su ITXPerience.

Kemp loadmaster virtual appliance initial deployment

Ecco come eseguire il deploy iniziale di un Kemp Loadmaster, in versione virtual appliance, in un ambiente vmware in modo da renderlo raggiungibile da rete per poterlo poi configurare dall’interfaccia web.

  1. Prima di tutto scaricatevi la trial dal sito ufficiale a questo indirizzo: http://kemptechnologies.com/server-load-balancing-appliances/virtual-loadbalancer/vlm-download/kemp_download
  2. Cliccando su download partirà già il download di uno zip da più o meno 70/80 mega. Una volta terminato il download scompattatelo ed all’interno troverete 3 file:kemp_download2
  3. A questo punto collegatevi alla vostra infrastruttura vmware con il vsphere client o via webclient e lanciate il deploy del file .ovf:

kemp_deploy_ovf_webkemp_deploy_ovf

 

4. Seguite il wizard di configurazione, dovete semplicemente specificare su quale host, datastore e network deployare l’appliance, la cosa importante all’inizio è che la network denominata “network” sia raggiungibile in modo da poter poi raggiungere l’appliance e poterla gestire una volta configurata la prima scheda di rete :

kemp_deploy_ovf1

kemp_deploy_ovf2

kemp_deploy_ovf3

kemp_deploy_ovf4

kemp_deploy_ovf5

5. Una volta terminato il deploy dell’ovf (davvero molto veloce) fate partire la vm e collegatevi in console per la configurazione base:

Kemp1

6. Terminato il boot vi verrà richiesto di loggarvi, le credenziali di default per il kemp loadmaster sono:

user: bal

password: 1fourall

Kemp2

7. Dopo esservi loggati dovrete passare alla configurazione di base della scheda di rete, vi verranno richiesti: ip, subnet mask, gateway e dns:

Kemp3 Kemp4 Kemp5

8. Dopo aver inserito tutti i dati il wizard vi comunicherà che potete collegarvi all’interfaccia web all’indirizzo appena impostato per continuare con la configurazione:

Kemp6

9. Connettetevi all’interfaccia web ed accettate la licenza cliccando su “Agree”:

Kemp7

10. Scegliete il tipo di licenza da utilizzare, avete tre possibilità:

a) La 30 day trial che limitata a 5Gbps e vi permette di utilizzare qualsiasi servizio ma solo per 30 gg.

b) La licenza effettiva acquistata.

c) La licenza free che non vi da limiti di tempo ma limita la banda utilizzabile a 20 Mbps.Kemp8

11. Potete iniziare a configurare il vostro load balancer

 

L'articolo Kemp loadmaster virtual appliance initial deployment sembra essere il primo su ITXPerience.

Dell 5548 – CLI configurazione

dell5548

 

Un basic setup di uno switch DELL POWERCONNECT 5548 fatto tramite CLI potrebbe essere il seguente :

 

>reset<
enable
delete startup-config
reload 
 
 
>creare vlan 2<
enable
configure
vlan database
vlan 2
 
>configurare vlan 2<
enable
configure
interface vlan 2
ip address 10.0.4.1 255.255.254.0
name nome_scelto_vlan_2
 
>creare il trunk su porta da 45 a 48<
interface range gigabitethernet 1/0/45-48
switchport mode trunk
switchport trunk allowed vlan add 2
 
>untaggare le altre porte sulla nome_scelto_vlan_2(access mode)<
enable
configure
interface range gigabitethernet 1/0/1-44
switchport access vlan 2
 
>abilitare porfast sulle porte non trunk<
enable
configure
interface range gigabitethernet 1/0/1-44
spanning-tree portfast
 
>abilitare routing<
enable
configure
ip routing
>impostare password enable (console)<
enable password level 15 passwordscelta
 
>impostare password http<
username admin password passwordscelta
>salvare le modifiche<
enable
write memory
 
>vedere elenco comandi<
enable
show running-config

Firewall linux : aggiungere rotte statiche e mantenerle dopo il riavvio

f-firestarter-firewall

Può capitare di dover inserire una rotta statica su un router firewall linux che utilizza iptables. Ecco come :

 

In questo esempio abbiamo la classica rete  192.168.1.0  netmask 255.255.255.0  e Gateway 192.168.1.1

Perciò editare il file  :

/etc/rc3.d/S99local

ed inserire :
route add -net 192.168.1.0  netmask 255.255.255.0 gw 192.168.1.1

per eliminarle sostituire “add” con “del

 

Exchange 2013 reverse proxy with IIS + Application Request Routing

Se state cercando un modo semplice per mettere in piedi un reverse proxy per non pubblicare direttamente il vostro CAS su internet e magari posizionarlo in una DMZ in modo da esporre una macchina non appartenente al dominio, l’accoppiata IIS + Application Request Routing (ARR) può fare al caso vostro. ARR può essere anche utilizzato per fare da loadbalancer a costo zero (se ovviamente avete la licenza per mettere in piedi 1/2 macchine windows) e la configurazione, seguendo questa guida, è decisamente semplice; l’infrastruttura che si vuole ottenere è qualcosa di simile a questa in cui il server con ARR si interpone in DMZ tra le richieste dei client ed i CAS server presenti nella lan aziendale:

ARR reverse proxy DMZ

 

Qui trovate tutti gli steps necessari per configurare il reverse proxy/load balancer (se avete più CAS exchange):

http://blogs.technet.com/b/exchange/archive/2013/07/19/reverse-proxy-for-exchange-server-2013-using-iis-arr-part-1.aspx

Una configurazione importante che nella guida viene inserita solo come “raccomandata” è quella alla fine della pagina, senza questa modifica Outlook anywhere non funziona:

“For optimization of RPC-HTTP traffic make the changes as stated. Click on the root of IIS and open the properties for Request Filtering. Then click on “Edit Feature Settings” and change the settings for “Maximum allowed content length” to the below.”

ARR reverse proxy

Altra cosa molto interessante è che due server con ARR possono essere messi in alta affidabilità tramite il servizio integrato Network Load Balancer (NLB) di windows quindi si può ottenere un’infrastruttura completamente ridondata, bilanciata e scalabile sia dal punto di vista dei servizi exchange che dal punto di vista dei reverse proxy. A questo link trovate una guida per la configurazione di nlb in active/passive o active/active:

http://www.iis.net/learn/extensions/configuring-application-request-routing-(arr)/achieving-high-availability-and-scalability-arr-and-nlb

L'articolo Exchange 2013 reverse proxy with IIS + Application Request Routing sembra essere il primo su ITXPerience.

Autenticazione Single-Sign-On con Fortinet FortiGate e Active Directory

Negli ultimi tempi l’utilizzo di Internet in modo troppo superficiale da parte degli utenti sta creando non pochi problemi agli amministratori di rete per filtrare virus e malware o anche semplicemente per limitare completamente l’accesso ad Internet.

Un primo approccio è quello di configurare il Firewall per limitare l’accesso ad Internet basandosi sull’indirizzo IP della macchina interna da cui proviene la richiesta. In questo modo si è costretti ad utilizzare indirizzi IP statici, o reservation nel server DHCP, e questo preclude la possibilità di creare policy ad-hoc per gli utenti.

Un secondo approccio è quello di usare un proxy server con autenticazione a livello utente così da spostare il discriminante dal livello fisico (indirizzo IP) a livello logico (utente). I vantaggi di questo metodo sono che si possono usare indirizzi dinamici e si può gestire l’accesso allo stesso computer da parte di più utenti. Il contro è quello di dover installare un server proxy e di dover configurare tutti i browser per utilizzarlo. E’ disponibile una guida all’implementazione di un server a questo link Installazione del proxy server squid in ambiente windows.

Il terzo approccio invece è lo scopo di questa guida, avendo a disposizione un FortiGate è possibile, senza nessuna configurazione lato client, autenticare in modo trasparente gli utenti tramite il protocollo NTLM e definire delle policy di accesso ad Internet in funzione del gruppo AD di appartenenza dell’utente.

Questa guida si riferisce alla configurazione del FortiGate con release v5.2.2 build642 del FortiOS.

Introduzione all’FSSO basato su agent

Fortinet Single Sign-On (FSSO), tramite l’utilizzo di un agente installato in uno o più computer è in grado di monitorare i logon degli utenti e passare queste informazioni al FortiGate. Quando un utente esegue il logon su un PC, FSSO:

  • rileva l’evento e registra il nome del PC, dell’utente e del dominio
  • risolve il nome del PC
  • determina a quali gruppi l’utente appartiene
  • invia queste informazioni al FortiGate

Quando successivamente un utente accede ad Internet il FortiGate è in grado di riconoscere l’utente, a quali gruppi appartiene e di conseguenza garantire o negare l’accesso a seconda delle policy impostate.

In ogni Domain Controller è necessario installare un Domain Controller (DC) agent, che invierà i dati di accesso ad un singolo Collector (CA) agent da installare in un altro server o in un DC.

Come vedremo più avanti esiste anche un ulteriore tipo di agent Citrix/Terminal Server (TS) agent.

Quanto descritto sopra è schematizzato nello schema seguente:

FSSO Schema di funzionamento

FSSO Schema di funzionamento

Installazione dell’Agente

Per prima cosa scarichiamo il programma FSSO_Setup direttamente dal sito web Fortinet Support, l’ultima versione disponibile è la 4.3.0161 (FSSO_Setup_4.3.0161_x64.exe), ed eseguiamo il programa in un Domain Controller.

Il programma mostra la Splash Screen con il Setup Wizard:

FSSO Setup Wizard

FSSO Setup Wizard

Invitandoci ad accettare i termini della licenza e a scegliere un percorso di installazione.

Nella schermata successivamente si devono inserire le credenziale di un utente con il quale verrà eseguito il programma, possiamo inserire i dati dell’amministratore di dominio o di un altro account a nostro piacimento:

FSSO User

FSSO User

E’ possibile scegliere alcuni parametri di installazione che potranno essere comunque cambiati successivamente in qualsiasi momento:

  • Monitor user logon events and send the information to FortiGate
  • Server NTLM authentication requests coming from FortiGate

Entrambe le opzioni sono abilitate di default.

  • Select Standard to use Windows domain and username credentials.
  • Select Advanced if you will set up LDAP access to Windows Directory.

Anche qui lasciamo per ora abilitate le opzioni di default.

FSSO Parametri

FSSO Parametri

Con il successivo Next l’installazione del collettore verrà completata e avremo modo di installare il DC Agent su questa macchina, abilitiamo la spunta e clicchiamo su Finish.

La maschera successiva ci invita a selezionare l’IP e la porta del collettore, in caso sia stato installato sulla stessa macchina i parametri dovrebbero essere già preimpostati in caso contrario inserire quelli corretti:

FSSO DC Agent

FSSO DC Agent

Dopo aver impostato i parametri di rete è necessario inserire i domini che dovranno essere monitorati dall’agente, nel caso siano presente più domini è possibile selezionarli a piacimento, altrimenti selezioniamo l’unico disponibile:

FSSO Agent Domain

FSSO Agent Domain

In caso di Active Directory con molti oggetti, per non rallentare o comunque per non sovraccaricare il lavoro dell’Agent con informazioni inutile, è possibile specificare gli utenti che non dovranno essere monitorati dall’agent. Questi utenti non saranno abilitati ad autenticarsi tramite SSO nel FortiGate.

FSSO Agent Users

FSSO Agent Users

Nell’ultima schermata è possibile specificare in quali Domain Controller installare l’Agent e il tipo di modalità:

  • DC Agent Mode
  • Polling

Selezioniamo la modalità DC Agent Mode e iniziamo l’installazione premendo Next:

FSSO DC

FSSO DC

Terminata l’installazione ci verrà richiesto di riavviare il Domain Controller:

FSSO reboot

FSSO reboot

Configurazione dell’Agente

Abbiamo detto in precedenza che il SSO del FortiGate gestisce gli utenti a livello di gruppo, creiamo quindi un Global group di tipo Security con il nome G_Internet_FullAccess e inseriamo al suo interno due utenti per prova:

AD group

AD group

Ora possiamo lanciare il programma Fortiniet Single Sign On Agent Configuration per procedere con la configurazione del SSO.

FSSO Agent Configuration

FSSO Agent Configuration

Verificare lo stato dell’agente sia in RUNNING, come riportato nel riquadro in alto a destra e che entrambe le spunte in alto siano selezionate:

  • Monitoring user logons events
  • Support NTML authentication

Nel riguardo Logging è possibile selezionare varie opzioni per la configurazione dei log dell’Agente, nella sezione Authentication è possibile richiedere al FortiGate di autenticarsi (la password di default è fortinetcanada).

Cliccando su Show Monitored DC è possibile visualizzare lo stato dei DC Agents installati ed eventualmente abilitarli:

FSSO DC Agent Satus

FSSO DC Agent Satus

Il pulsante Select Domains To Monitor consente di modificare quali sono i Domini monitorati dall’agent.

Visto che non vogliamo passare tutte le informazioni al FortiGate clicchiamo sul pulsante Set Group Filters e selezioniamo i gruppi che ci interessano gestire ai fini dell’accesso ad Internet.

Di default non dovrebbe comparire nessun gruppo, pertanto cliccare su Add per creare un nuovo gruppo. Spuntare la voce Default filter e tramite il pulsante Advanced selezionare i gruppi che volete gestire, nel nostro caso selezioniamo solamente il gruppo G_Internet_FullAccess e clicchiamo su Ok, la finestra dovrebbe presentarsi in questo modo:

FSSO Group Filter

FSSO Group Filter

Chiudere la configurazione e tornare alla finestra principale.

Iniziamo a verificare se tutto è configurato correttamente e il Collector inizia a reperire i dati delle logon degli utenti, clicchiamo sul pulsante Show Logon Users e se tutto sta funzionando dovremmo vedere i dati degli utenti:

FSSO User list

FSSO User list

A questo punto la configurazione lato Windows è terminata iniziamo quella nel FortiGate.

Dopo aver eseguito l’accesso al pannello di configurazione Web, aprire il tab User & Device -> Authentication -> Single Sign-On che dovrebbe apparire vuoto.

FortiGate menu

FortiGate menu

Clicchiamo su Create New e inseriamo i dati di collegamento al Collector Agent:

FortiGate Sign-On Server

FortiGate Sign-On Server

Dopo aver inserito il Name, l’Ip e la Password cliccare su Apply & Refresh, dovrebbero automaticamente apparire i Gruppi che abbiamo preventivamente configurato nel Collector Agent.

 

Verifica della comunicazione FortiGate <-> Active Directory

Possiamo verificare la connessione FortiGate <-> Collector Agent cliccando sul pulsante Show Service Status del Collector Agent, dovrebbero essere riportati i dati del FortiGate che abbiamo appena configurato.

FSSO Status

FSSO Status

E’ venuto il momento di eseguire il logon su diversi pc con diversi utenti, alcuni facenti parte del gruppo G_Internet_FullAccess altri no e verifichiamo se tutto è configurato correttamente nel FortiGate.

Tramite interfaccia web aprire Log & Report -> Event Log -> User per verificare gli eventi di logon degli utenti:

FortiGate Events log

FortiGate Events log

Da shell invece possiamo utilizzare il comando diagnose debug authd fsso list che dovrebbe visualizzare qualcosa del tipo:

FortiGate console

FortiGate console

Il Single Sign-On tra FortiGate e Active Directory sta funzionando, ora vediamo come sfruttarlo per creare delle policy di accesso ad Internet.

Configurazione Policy di accesso ad Internet

I gruppi Active Directory non possono essere usati direttamente nel FortiGate per le policy di sicurezza, dobbiamo pertanto creare dei gruppi locali e inserirci i gruppi Windows.

Per creare un nuovo gruppo locale andiamo in User & Device -> User -> User groups e clicchiamo su Create New, assegniamo un nome al gruppo (FSSO_Internet_FullAccess) e impostiamo del tipo Fortinet Single Sign-On (FSSO). All’interno dei membri dobbiamo selezionare il gruppo G_Internet_FullAccess (visibile da Active Directory).

I membri di questo gruppo saranno popolati dinamicamente e saranno i membri del gruppo G_Internet_FullAccess creato in precedenza in Active Directory.

L’ultima operazione che ci rimane da fare è quella di configurare una Policy per filtrare l’accesso ad Internet per i membri del gruppo, supponiamo che l’accesso sia stato preventivamente bloccato per tutti.

Apriamo Policy & Objects -> Policy -> IPv4 e clicchiamo su Create New, la policy sarà una normale policy del tipo IN -> OUT con l’unica accortezza di selezionare il gruppo FSSO_Internet_FullAccess come utenti sorgente:

FortiGate Policy

FortiGate Policy

Non ci rimane da fare altro che provare a loggarci su due PC con due diversi utenti, uno appartenente al gruppo G_Internet_FullAccess e uno no, e verificare che solo uno dei due ha accesso ad internet.

 

Remote Desktop Services

Il SSO configurato sopra funziona perfettamente fino a quando gli utenti non utilizzano un server configurato come RDS (Remote Desktop Services). In questo caso infatti non appena un utente autorizzato ad accedere ad Internet effettua il logon tutti gli utenti sullo stesso server possono navigare.

Questo perché sostanzialmente il FortiGate sblocca l’IP non sapendo che su quell’IP lavorano più utenti contemporaneamente.

Il problema si risolve installando su ogni server RDS uno specifico client scaricabile sempre dal sito del Supporto Fortinet che si chiama TSAgent_Setup_x.x.xxxx.exe, nel notro caso TSAgent_Setup_4.3.0161.exe.

Una volta scaricato l’eseguibile mandarlo in esecuzione e cliccare sui vari Next, l’unico parametro da configurare è l’IP del Collector Agent:

TSAgent

TSAgent

Una volta installato il TSAgent sarà visibile all’interno del Connector Agent sotto la voce Show Monitored DCs:

DC Agent Status

DC Agent Status

Se ora provate ad eseguire il logon su un server con due account diversi, uno abilitato e uno no, il FortiGate dovrebbe essere in grado di differenziarli e consentire l’accesso ad Internet al solo utente autorizzato.

Nel caso riportato in figura user1 è autorizzato, user2 no:

Test finale

Test finale

Per un approfondimento ai sistemi di autenticazione del FortiOS è disponibile il documento FortiOS Handbook – Autentication for FortiOS 5.0.