Guida pratica per risolvere i problemi più comuni
Mi scuso per sicuri
errori grammaticali, spero che i pochi che lo leggeranno non ne rimangano
infastiditi.
Il tempo e gli impegni
non mi permettono altro che questi umili articoli.
Prendo per scontato che si lavori su unità di archiviazione NTFS e non FAT32.
Innanzitutto dobbiamo abbandonare tutto quello che siamo stati abituati a pensare con sistemi Windows 9x/ME.
NON e ripeto NON esistono cartelle condivise con password! Il concetto ora è più semplice e articolato, basta capirlo.
Io mi chiamo Andrea e lo stato sa che ho una patente e quindi che posso guidare l’automobile, ma non possiedo un brevetto di volo e quindi non posso pilotare.
Iniziate a capire?
Io sono un individuo, non più uno sconosciuto che inserisce password per poter accedere a dei servizi.
Il sistema è progettato per permettere a me di fare certe cose e ad altri di farne altre. Questo è il concetto fondamentale!
Che vantaggi ho a implementare un sistema di questo tipo?
i. Non devo inserire password diverse ogni volta che voglio accedere ad una cartella.
ii. Se voglio impedire all’utente A di accedere alla risorsa X non devo cambiare la password e poi comunicarla a tutti gli altri.
iii. Se voglio tenere traccia delle operazioni eseguite dall’utente A posso farlo.
Non sono più uno sconosciuto, ma un individuo! Per questo ora è importante che ognuno acceda con una propria login.
Se non riuscite a seguire quello che vi viene indicato e avete XP forse dovete disabilitare la condivisione semplice dalle opzioni di explorer.
Se i tuoi computer lavorano in un workgroup non esiste un sistema uniforme per l’autenticazione degli utenti, ma ogni computer fa da sé.
Appena accedo ad un computer e inserisco le mie credenziali (nome utente e password) mi viene dato un token locale per utilizzare le risorse di questa macchina. Ma appena tento di accedere ad un’altra macchina (perché ho bisogno di una sua risorsa condivisa) le mie credenziali vengono verificate anche da quest’ultima. Cioè vengono trasmesse (ovviamente in un particolare formato codificato, quindi in nessun modo leggibili o deducibili) alla seconda macchina che verifica se è a conoscenza di questo utente.
Come avviene? Guarda tra i suoi utenti locali (nel database SAM) se esiste un utente con medesima login e password. In questo caso mi riconosce e mi concede il suo token.
Se nella lista dei suoi utenti locali l’utente non compare, apparirà una nuova finestra per richiedere nuove credenziali.
Questo sistema si chiama “mirrored account” perché si ha una copia del medesimo utente su entrambe le macchine.
Il token ora mi identifica come utente per la macchina, ma
non è ancora detto che io abbia accesso alla risorsa. Bisogna verificare i
permessi: vedi dal punto
Quindi riassumendo cosa è necessario in un workgruoup? Un utente che necessita l’accesso di determinate risorse condivise deve comparire su tutte le macchine con la medesima login e password. Questo affinché non avvenga una richiesta di credenziali ogni volta che si accede a ciascun computer.
Non è necessario avere sempre l’utente Andrea su ogni computer, ma è sicuramente più comodo che dover immettere credenziali diverse ogni volta!
Cosa importante da ricordare è che le password non possono essere bianche (ovvero nulle).
Un dominio è caratterizzato dalla presenza dei Domain Controller (DC), questi server hanno il compito di autenticare gli utenti. La differenza sostanziale è che si possiede un “elenco” completo di tutti gli utenti del dominio su ogni controller (con le dovute eccezioni in caso di foresta).
Quindi ogni computer non ha più la necessità di possedere degli utenti locali, ma l’uso di questi non è affatto un errore, in certi casi è necessario.
Il token viene quindi rilasciato dal DC ed è questo singolo token che mi permette di accedere alle risorse condivise su tutti i computer del dominio.
Quindi non viene eseguita l’autenticazione sul computer ogni
volta che si accede e la centralizzazione del database utenti semplifica
In presenza di una Forest si potrebbero avere problemi di autenticazione se un utente non appartiene al sottodominio, in questo caso bisogna verificare che sia accessibile un DC con una copia del Global Catalog, ma questo è un argomento che trascende lo scopo di questo testo.
Se invece la nostra macchina alla quale abbiamo fatto logon è esterna al dominio, ma si tenta comunque di accedere ad una risorsa di esso, il concetto di “mirrored account” (spiegato nel precedente paragrafo) funziona ancora.
Infatti se nel dominio è presente un account per quell’utente che ha fatto logon, con la medesima password esso viene riconosciuto e autorizzato.
Ogni risorsa ha delle proprietà e al suo interno si trova
Cosa fondamentale è ricordare che non è pratico assegnare i permessi ad ogni singolo utente, ma spesso è il caso di creare gruppi (se gli utenti sono molti). Assegnare i permessi ad un gruppo corrisponde ad assegnarlo ad ogni utente che ne fa parte.
Esistono gruppi definiti Built-in (ovvero pregenerati) che ci aiutano a questo scopo, vediamone alcuni comuni sia per un dominio che per un workgroup:
E’ un gruppo che racchiude chiunque, anche coloro che non possiedono un token valido; ovvero anche quelli che non sono stati riconosciuti dal sistema. Attenzione ad usarlo.
Simile al precedente, ma questa volta è necessario un token. Il sistema deve avervi riconosciuto.
Utenti ristretti che hanno un limitato accesso ai computer.
Utenze con massimi privilegi. Questi hanno il permesso di modificare a piacere i permessi.
A questo punto non rimane che concedere gli accessi o negarli. Sconsiglio caldamente ai non esperti di utilizzare le impostazioni avanzate nella security. Ora bisogna selezionare chi ha il permesso di leggere e chi di scrivere e modificare, chi di stampare e chi di gestire le stampanti. Assegnare Everyone Controllo completo non è una scelta intelligente, ma assegnarlo agli Authenticated Users è sicuramente meglio.
Non dovrebbero esserci problemi, ricordatevi che assegnare i permessi ad una cartella significa che ogni file che ne viene creato all’interno erediterà questi permessi. Usate spesso la guida come riferimento dei singoli permessi.
Ricordate inoltre di utilizzare la negazione dei permessi solo in casi eccezionali.
Gli amministratori dovrebbero avere sempre un controllo completo (quindi ricordatevi di includerli nella lista), ma come gruppo va utilizzato con parsimonia.
Ovvero non dovrebbe esserci nessun utente che usa giornalmente l’accesso da amministratore. Va usato solo in casi eccezionali.
Questi permessi sono applicati localmente, quindi sono soggetti sia gli utenti che provengono dalla rete sia quelli locali.
Per le cartelle condivise si applicano inoltre i permessi di condivisione.
Quando viene condivisa una cartella è necessario specificare dei permessi di condivisione. Questi permessi influenzano solo le utenze di rete, ovvero coloro che vi accedono da un altro computer.
Questi permessi sono simili (anche se limitati, non possiedono le caratteristiche avanzate) a quelli NTFS e sono cumulativi.
Questo significa che un utente di rete prima deve possedere i requisiti per l’accesso della condivisione e in seguito anche quelli NTFS.
Quindi se ho impostato correttamente i permessi NTFS, quelli di condivisione possono essere tranquillamente Everyone Controllo Completo.
Se invece imposto Everyone Leggi nella condivisione, nessuno potrà mai scrivere, neppure gli amministratori.
Questa non è affatto una guida esaustiva, direi che ho parlato anche troppo di argomenti che necessitano un approfondimento maggiore prima di essere implementati. E’ stata comunque scritta allo scopo di provocare un interesse e risolvere i problemi più comuni che ho incontrato.
Se non vi basta probabilmente avete bisogno di un buon libro, non di qualche suggerimento o trucchetto.
Buona ricerca!