Ricerche IT

Quando ci si trova a lavorare con router e firewall Cisco utilzzando la riga di comando (CLI), in genere si utilizza, in ambiente Windows, Hyperterminal per lavorare tramite console, oppure direttamente il comando telnet se si lavora tramite rete, oppure Putty se si accede tramite SSH. Soprattutto se si deve lavorare più o meno contemporaneamente su più dispositivi, è molto comodo utilizzare un unico programma, e ciò è possibile utilizzando Putty.

Putty è un software di emulazione terminale piuttosto completo, quindi permette di connettersi ad un dispositivo sia tramite porta seriale sia utilizzando diversi protocolli di rete. Putty mi piace molto di più di Hyperterminal quando ci si deve connettere ad un dispositivo Cisco tramite console, soprattutto quando si deve fare copia-incolla delle configurazioni degli apparati. Bisogna però dire che, almeno nelle connessioni seriali, ho riscontrato una certa instabilità di Putty, anche se ancora non mi sono dato la briga di giocare un po’ con le opzioni di connessione.

Per utilizzare Putty per connettersi ad un dispositivo tramite porta seriale, all’apertura del programma scegliere l’opzione "Serial" (l’ultima della lista di fianco a SSH), che è stata introdotta da non molto (credo). Da lì, nel campo "Serial line" scegliere la porta seriale su cui connettersi (COM1 è quella predefinita) e la velocità (9600 bit/s quella predefinita, adatta per connettersi ai dispositivi Cisco), quindi, eventualmente, dal menu ad albero sulla sinistra (Category), andare sulla voce Connection e quindi su Serial per specificare ulteriori opzioni di collegamento. A questo punto, cliccando su Open, ci si ritrova connessi alla porta seriale e possiamo agire sul nostro apparato.

Oltre a qualche pecca di stabilità via seriale (che però appunto potrebbe dipendere da una non corretta configurazione dei parametri di connessione), con Putty non funziona la combinazione di tasti CTRL+BREAK, utile quando si vuole fare un recovery della password di un router Cisco; per ovviare al problema, una volta avviata la connessione cliccare sull’iconcina di Putty in alto a sinistra sulla barra del titolo, scegliere la voce "Special command" quindi scegliere la voce "Break", in modo da ottenere un effetto equivalente alla pressione dei tasti CTRL+BREAK

Può avvenire che a causa di svariati problemi un sistema Windows ad un certo punto si rifiuti di partire rendendo necessaria una reinstallazione del sistema. Alcune volte non è necessario formattare e reinstallare tutto da capo, si può risolvere semplicemente installando Windows sopra se stesso, tramite un ripristino (che alla fine è una reinstallazione di Windows stesso che non cancella le impostazioni preesistenti).

Questo tipo di approccio, quando funziona, può comunque lasciare qualche piccolo problemino, come quelli che mi si sono presentati dopo una reinstallazione di Windows 2000 Professional. Il problema principale era il fatto che Outlook non riusciva a trovare il server Exchange, sebbene la rete ed Outlook fossero correttamente configurati e funzionanti.

La prima cosa che ho notato è che il servizio "Connection Manager di Accesso remoto" non voleva partire dando un errore di accesso negato, coinvolgendo nello stesso problema un altro servizio dipendente da questo, "Auto Connection Manager di Accesso remoto", presentando nel visualizzatore eventi (Event viewer) l’errore con id evento 20035 ed origine "RasMan", e l’errore con id evento 7023 ed origine "Service Control Manager". Per risolvere il problema basta eliminare (previo salvataggio delle chiavi di registro coinvolte) le voci di registro:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\PPP\EAP\25
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\PPP\EAP\26

Così facendo i servizi elencati in precedenza partono senza problemi, ma il problema con Outlook persiste imperterrito.

Per risolvere definitivamente il problema, ho preso la chiave di registro HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc\ClientProtocols esportandola da un PC correttamente funzionante ed importandola sul PC in questione, poiché questa chiave probabilmente è stata cancellata in seguito alla reinstallazione di Windows. Fatto questo, anche il problema con Outlook è sparito ed il PC è pienamente utilizzabile.

Link di riferimento
Impossibile creare una nuova connessione di rete dopo avere ripristinato Windows XP
You cannot log on to an Exchange Server computer when you are running OutlookYou cannot log on to an Exchange Server computer when you are running Outlook

In un dominio (Samba o Microsoft) è centrale la gestione degli utenti e dei gruppi per poter gestire al meglio autorizzazioni ed autenticazione sul sistema informativo. Samba e Linux mettono a disposizione gli strumenti per poter gestire con una certa granularità gli utenti ed i gruppi che si autenticano sul dominio. Pensiamo ad esempio di creare un utente con nome BugsBunny appartenente al gruppo LooneyToons, disponibili sull’intero dominio.

Il primo passo consiste nel creare gli utenti sul sistema Linux, che saranno quindi utenti Linux a tutti gli effetti. Per farlo, è possibile utilizzare il comando useradd -m BugsBunny, dove al posto di BugsBunny va inserito il nome con cui l’utente effettuerà il login; quest’utente avrà bisogno anche di una password, da assegnare tramite il comando passwd BugsBunny. L’utente appena creato però sarà disponibile solamente per il login sul sistema Linux, per poterlo usare come utente del dominio Samba quest’utente va creato in modo esplicito per Samba, utilizzando il comando smbpasswd -a BugsBunny, che richiederà anche la password da utilizzare per quell’utente: in genere è buona norma utilizzare la password già specificata per l’utente Linux, anche se questa cosa devo ancora guardarmela bene.

Per quanto riguarda i gruppi di utenti, i concetti sono più o meno simili. Prima cosa, creare il gruppo LooneyToons sul sistema Linux, tramite il comando groupadd LooneyToons, dove al posto di LooneyToons bisogna inserire il nome del gruppo facente parte del dominio. A questo punto bisogna creare il gruppo in Samba, ed è possibile farlo creando automaticamente la corrispondenza tra il gruppo Samba e il gruppo Linux con un unico comando: net groupmap add ntgroup="LooneyToons" unixgroup=LooneyToons type=d. La postilla type=d sta ad indicare che il gruppo appena creato è un gruppo globale, se si volesse creare un gruppo locale bisognerebbe dare l’istruzione type=l. E’ importante notare che un gruppo globale è visibile sull’intero dominio, a differenza di un gruppo locale.

Ora non rimane altro che assegnare l’utente BugsBunny al gruppo LooneyToons. Per farlo, basta assegnare "l’utente Linux" BugsBunny al "gruppo Linux" LooneyToons con il comando gpasswd -a BugsBunny LooneyToons, e quest’impostazione sarà automaticamente recepita da Samba, per cui a tutti gli effetti l’utente BugsBunny farà parte del gruppo LooneyToons anche in Samba, non solo in Linux. Per verificarlo, è possibile elencare gli utenti che fanno parte del gruppo LooneyToons tramite il comando net rpc group members "LooneyToons" -Uroot, inserire la password dell’utente root di Samba e di seguito comparirà la lista degli utenti facenti parte del gruppo LooneyToons.

Ora possiamo autenticarci con l’utente BugsBunny su una qualsiasi macchina iscritta nel dominio, con i privilegi eventualmente assegnati al gruppo LooneyToons.

Link di riferimento: documentazione ufficiale Samba.

Quando in MSSQL Server si trasferisce un database da un server da un altro, può succedere che un utente definito nel database non sia stato definito come login di accesso a SQL Server. Ad esempio, posso avere un utente del database chiamato DuffyDuck che non è definito come login di accesso. Se io creo un nuovo account SQL e lo chiamo DuckDodgers, questo non corrisponderà all’utente del database DuckDodgers, e ciò sarà fonte di problemi nell’accesso al database da parte delle applicazioni.

Per ovviare al problema bisogna mappare l’utente del database e l’account SQL, e ciò è possibile grazie all’utilizzo della stored procedure sp_change_users_login. Ipotizzando di avere un database chiamato "Universo", per collegare l’utente del database DuckDodgers al login SQL DuckDodgers, digitare la seguente istruzione T-SQL da Query Analyzer:

use universo
exec sp_change_users_login ‘update_one’, ‘DuckDodgers’, ‘DuckDodgers’
go

In questo modo ho risolto il problema.

Quando si crea una casella di posta elettronica su Exchange (versione 2003), solo l’utente definito in Active Directory associato alla casella in questione può accedervi ed operare con tutti i privilegi, nemmeno l’utente Administrator può accedere ad una casella di posta che non gli appartiene.

E’ comunque possibile dalla console di amministrazione di Active Directory (dsa.msc) permettere ad altri utenti di accedere alla casella di posta in questione e inviare messaggi per conto dell’utente proprietario di detta casella. Nel nostro caso, dobbiamo fare in modo che l’utente RoadRunner possa utilizzare pienamente la casella di posta elettronica di WileCoyote.

Per prima cosa, bisogna fare in modo che la casella di posta di WileCoyote sia accessibile anche da altri utenti (nel nostro caso RoadRunner); perché ciò sia possibile, è necessario abilitare la visualizzazione delle caratteristiche avanzate di Active Directory, andando sul menu View e cliccando su "Advanced features". Ora accedere alle proprietà dell’utente WileCoyote ed andare sulla scheda "Exchange Advanced" e cliccare sul pulsante "Mailbox Rights", si aprirà la classica finestra in cui è possibile aggiungere o togliere utenti ed autorizzazioni, aggiungere quindi l’utente RoadRunner e dargli le autorizzazioni "Full mailbox access". Ora l’utente RoadRunner ha il pieno accesso alla casella di WileCoyote.

Il secondo passaggio da compiere risolve un’altra problematica: stando così le cose, RoadRunner ha l’accesso alla casella di posta ma non può inviare messaggi di posta. Per consentire a RoadRunner di inviare messaggi per conto di WileCoyote, sempre da Active Directory cliccare sulle proprietà di WileCoyote, quindi andare nella scheda Security, cliccare in basso sul pulsante Advanced, cliccare su Add e scegliere l’utente RoadRunner, cliccare su Ok e nella successiva finestra, dall’elenco a discesa "Apply onto", scegliere la voce "This object only", quindi mettere il segno di spunta solamente sul tipo di autorizzazione "Send as" e dare sempre conferma col tasto Ok, quindi chiudere Active Directory. Dopo una disconnessione preventiva, l’utente RoadRunner sarà in grado di inviare posta elettronica, accedendo col proprio utente, per conto dell’utente WileCoyote.

La procedura sopra descritta si può applicare anche a più utenti oppure a gruppi definiti in Active Directory.

Link di riferimento: http://msexchangeteam.com/archive/2005/01/07/348596.aspx

Per gestire la configurazione di un firewall PIX di Cisco può essere utile l’accesso via telnet, invece del più scomodo accesso via console. Siccome i dati scambiati tramite protocollo telnet non sono criptati, il firewall PIX normalmente non permette l’accesso via telnet sull’interfaccia esterna (outside) del firewall, considerata poco sicura, per cui è possibile abilitare l’accesso via telnet solamente sull’interfaccia interna (inside).

Assumendo che il nostro firewall abbia un indirizzo IP sull’interfaccia inside uguale a 192.168.0.254, per abilitare il protocollo telnet diamo i seguenti comandi:

telnet 192.168.0.254 255.255.255.0
telnet timeout 5

In questo modo tutti i PC della rete locale potranno accedere al firewall, che richiederà una password per l’autenticazione; se non diamo altri comandi riguardo alla configurazione dell’accesso via telnet, la password predefinita per connettersi al firewall è "cisco", anche se poi dobbiamo conoscere la password per entrare in privileged mode per poter configurare il firewall.

Se vogliamo cambiare password di accesso e non lasciare la password predefinita per l’accesso via telnet, dobbiamo utilizzare il comando

passwd password

dove per password si intende la password che sceglieremo per l’accesso via telnet al nostro firewall.