Il blog di DiRete

Permessi ad un utente per lavorare su un solo servizio

Se vi capitasse di dover creare un “amministratore Windows dei poveri” al quale dovete far gestire solo il riavvio di un servizio e poco altro, troverete come utile la lettura di questo articolo che provo a riassumere rapidamente.

Dopo aver creato l’utente dovete conoscerne il SID. Il modo più semplice è loggarsi come tale utente sulla macchina e lanciare dal prompt il comando

whoami /all

per trovare il SID (qualcosa tipo S-x-x-xx-xxxxxxxxxx-xxxxxxxxxx-xxxxxxxxx-xxxx).

Lanciate ora sempre dal prompt

sc sdshow "nome_servizio"

otterrete qualcosa tipo

D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOC RRC;;;IU)(A;;CCLCSWLOCRRC;;;SU)(A;;CR;;;AU)(A;;CCLCSWRPWPDTLOCRRC;;;PU)S:(AU;FA ;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;WD)

che è la descrizione della sicurezza sul servizio “nome_servizio”.
Con il comando

sc sdset nome_servizio D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;IU)(A;;CCLCSWLOCRRC;;;SU)(A;;CR;;;AU)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SO)(A;;RPWPDTLO;;;S-x-x-xx-xxxxxxxxxx-xxxxxxxxxx-xxxxxxxxx-xxxx)S:(AU;FA;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;WD)

avete aggiunto all’utente i permessi sul servizio di RP (avviare), WP (arrestare), DT (mettere in pausa/riavviare) e LO (vederne lo stato).

Testato con Windows 2003. Nell’articolo ci sono anche strade più eleganti. Questa mi è sembrata la più veloce.

Abilitare Terminal Services da remoto

Oggi sto litigando con un server al quale devo accedere con un KVM Avocent ed ho qche difficoltà: il mouse va una volta ogni tanto … temo per un problema di risorse (nel 2010 accade ancora, purtroppo). Son riuscito a configurargli la scheda di rete nell’unico reboot in cui ha funzionato correttamente … ma ora devo accedere da remoto e … DOH! Mi son dimenticato di abilitare il remote desktop (aka terminal services). Niente paura, si fa da remoto in 2 minuti, le istruzioni sono in inglese ma è molto molto facile e val la pena che linki direttamente il sito ove le ho trovate:

 http://oreilly.com/windows/archive/server-hacks-remote-desktop.html

Migrare SBS: lo famo all’italiana?

Windows Small Business Server 2003 [SBS] è in pratica Windows Server 2003 Standard + Exchange (il server di posta) + SQL Server (il database) + “altre cosette”. E costa meno del solo Windows 2003 Standard.

Ti danno di più per molti meno soldi. La cosa è alquanto sospetta, giusto?

Giusto.

Lasciando perdere la politica commerciale di MS, migrare da uno SBS ad un altro è molto più complesso che migrare un server normale.

Qualche mese fa ho passato un intero weekend da un cliente per migrare il suo SBS dal vecchio server al nuovo. Ero tutto contento: seguendo la guida di Microsoft alla lettera ero riuscito a finire il tutto in sole 18-20 ore di lavoro filato senza che il cliente perdesse un bit.

Bene.

L’avevo fatto seguendo “all’americana” tutta la check list di Microsoft, compilando come un bravo studente tutte le richieste. Mi mancava solo il blocco note in bachelite (*) con il mollettone.

Ci ho messo un sacco di tempo soprattutto per trovare su Google tutte le soluzioni ai mille errori che capitavano nel registro eventi durante tutta la procedura e che secondo Microsoft non dovevano succedere.

Veniamo all’approccio italiano.

Questa settimana il nuovo server ha avuto un problema e si è reso necessario reinstallare tutto da capo in emergenza.

Risultato? Facendo tutto “all’italiana” ci sono volute circa 10 ore e considerate che non potevo partire da un backup perché vecchio (di ore).

In sintesi: se dovete migrare uno SBS fatevi per scrupolo un bel PST di ogni singolo account di Exchange (dal client e non dal server), backuppate i vari dati e i programmi LOB (e chiamateli così! Dire gestionali fa molto meno fico!) e piallate la macchina.

Dite agli utenti che resetterete le password ed approfittatene per rivedere con chi di dovere se la struttura delle cartelle e dei permessi è ancora adeguata.

Mettere la macchine nel nuovo dominio e migrare i profili è un attimo. Se qualcosa va storto con Outlook avete sempre i PST da reimportare e/o i vecchi profili da usare.

Rifarla da zero è molto più semplice che sperare che tutto vada come deve andare secondo quella dannata lista americana!

😉

Scherzi a parte, chiaramente se avete anche un SQL complesso ed una marea di client la cosa potrebbe essere meno vera. Ma se avete una marea di client forse avete già abbandonato SBS da un pezzo….

(*) “Cosa succederebbe, se agli americani rubassero le miniere di bachelite?”, ci disse un giorno il buon Gigi…

In caso di insonnia: come vengono scoperti i domain controller

Abbiamo usufruito di uno degli “incidenti” di Microsoft per debellare nel migliore dei modi un domain controller con Windows 2000 che rimaneva, poverino, attaccato al dominio con tutti i suoi vecchi denti spuntati.

Il tecnico Microsoft (Luca – e lo ringrazio per la disponibilità), è riuscito nel compito richiesto e l’ha rimosso modificando a mano con adsi edit e altri simpatici ammenicoli che sinceramente preferisco sempre evitare.

In seguito all’intervento, però, si sono presentate tutta una serie di malfunzionamenti:

• molti PC al lancio dello script di login facevano riferimento a \\server2000\netlogon\… invece di \\nuovoserver\netlogon\…
• alcune macchine pingavano il nomedominio.local, altre no
• provando ad aprire la cartella \\nuovoserver\netlogon\ Windows diceva che “No network provider accepted the given network path” ed i registri erano pieni di errori con ID 1000 e 1053.

Cercando di capire il motivo mi sono imbattuto in un bell’articolo di Microsoft che spiega come vengono scoperti i domain controller. E’ un articolo piuttosto tecnico che vi salverà in caso di insonnia.

A me è servito leggere solo una parolina: WINS. La rimozione del server (che aveva anche il WINS) ed un malfunzionamento sull’unico WINS rimasto nel dominio causava tutti i problemi. E’ bastato rimuoverlo e rimetterlo nel server rimasto per risolvere il tutto.

Di qui il nuovo acronimo ricorsivo WINS: Windows Insiste Nel Solito WINS… ma perché?!?

😉

Impostare il server NTP in Windows 2003

Non l’ho provato … ma, x esperienza, non fatico a credere che Microsoft abbia trovato una via così complessa per una cosa tanto banale quanto impostare l’orologio di windows perché si sincronizzi automaticamente con un server NTP (tipicamente usiamo time.ien.it)

L’articolo è in inglese, ma è ben scritto:

http://www.windowsnetworking.com/articles_tutorials/Configuring-Windows-Time-Service.html

Sessione remota terminal e console

Oggi son diventato matto con un cliente che non riusciva a collegarsi in console via terminal service su un server 2003. Il client di connessione RDP gli dice che il parametro /console è sconosciuto.
Ho ipotizzato si trattasse di un problema di aggiornamento del client, poiché la versione 5.x non supportava le connessioni console (c.d. session 0) mentre la versione 6.0 le supporta
Tentando di installare l’update, però, windows dichiara che la versione di service pack installata è già più recente … mumble mumble mumble … svelato l’arcano: la nuova versione (6.1) ha cambiato le opzioni !!! Ora è necessario utilizzare il parametro /admin come meglio spiegato in questo documento che, tra l’altro, vi chiarirà per benino la differenza tra una sessione console ed una non console:

http://blogs.sysadmin.it/ermannog/archive/2008/07/28/3032.aspx

Condivisioni windows 2003 non visibili da mac osx?

Avete configurato tutto correttamente. Il client mac vede il server sulla rete (risolve il nome correttamente e raggiunge la macchina via tcp/ip). L’utente ha i permessi giusti. Fate Mela+K e scrivete cifs://xxx.xxx.xxx.xxx … arriva la richiesta di nome utente e password. Li digitate, sono corretti ma … vi dice “accesso negato”. Negli eventi di Windows 2003, invece, appare il log dell’avvenuta (corretta) connessione. Che fare?

Beh, è una fesseria, ma se nn lo sapete non ci arriverete mai! Windows 2003 server è impostato per cifrare SERMPRE le connessioni client-server e questo, nella comunicazione Windows <-> Mac non è possibile.

Quindi, come risolvere? Semplice! Sul server andate in Strumenti di amministrazione -> Criterio di protezione del controller di dominio -> Impostazioni protezione -> Criteri Locali -> Opzione di protezione -> Server di rete Microsoft: aggiungi firma digitale alle comunicazioni (sempre) (okkio che c’è anche la versione “se autorizzato …”) -> disattivatelo!

quindi, da linea di comando (sempre sul server) gpudate e … il gioco è fatto 😉

Trasferire i 5 ruoli di AD da un server all’altro.

Se non vi interessate di Windows 2003 server siete autorizzati a non leggere.

Se state leggendo, invece, dovreste sapere che Active Directory non è multimaster puro: in caso di guasto di uno dei Domain Controller tutti gli altri hanno sì le informazioni su utenti, password eccetera ma alcune informazioni sull’Active Directory rimangono gestite da un solo server. Queste informazioni si chiamano ruoli FSMO.

Il senso del post è che finalmente ho trovato un articolo fatto bene (in inglese) che spiega

• cosa sono i ruoli FSMO
• come capire quale server ha quale ruolo
• come spostare i ruoli FSMO
  
• come forzare lo spostamento dei ruoli FSMO (l’ultima spiaggia quando il server che aveva i ruoli è compromesso)
  

E’ la classica cosa che speri di non dover fare mai e quando ti serve… non ti ricordi a memoria i comandi.

😐