none
Database di Access 2007 condiviso su una rete domestica tramite Microsoft SQL Server 2008 R2 RRS feed

  • Domanda

  • Ciao,

    nella rete di casa mia dove è installato Microsoft SQL Server 2008 R2, per la condivisione di un database di Access 2007 su più computer (uno funge anche da server), uso come nome account di accesso: sa e poi naturalmente una password (anche se so che sa è molto vulnerabile).

    Dovendo installare lo stesso Microsoft SQL Server 2008 R2 a casa di un amico per lo stesso motivo di condivisione tra più computer, invece di usare sa come account e poi la password, potrei usare una connessione di tipo trusted visto che il tutto si svolgerebbe solamente all'interno della rete di casa sua?

    1) La connessione dei vari computer avrebbe qualche problema?

    2) Ci sarebbero problemi di riservatezza dei dati causati da qualcuno esterno alla propria rete domestica?

    Scusatemi se sono delle domande banali che potrei trovare su qualche link da voi postato qualche tempo fa, ma ho urgentemente bisogno di una risposta.

    Grazie a chi vorrà darmi una mano.

    Vladimiro


    sabato 28 dicembre 2013 01:44

Risposte

  • infine una domanda: ma la macchina con sql server che sistema operativo ha ? 

    il sistema operativo dove è installato Microsoft SQL Server 2008 R2 è Windows7: cioè il mio computer. 


    credo che abbiamo parlato inutilmente in questo thread perchè tutti i principi di sicurezza che ho enunciato riguardano i sistemi server e mi aspettavo che l'istanza di sql server fosse installata su un sistema server (Windows Server 2008, Windows Server 2012, ecc.ecc.) invece tu hai una infrastruttura di rete integralmente basata su sistemi client (XP, Vista, Windows 7). questo tipo di infrastruttura dispone solo in parte dell'architettura di sicurezza di Windows, di solito è destinata all'home computing e per rendere semplici le cose si usano i Workgroup o i Workplace per far comunicare le macchine in rete in maniera semplificata.

    parliamo quindi di infrastrutture diverse per cui non ha senso continuare.

    ciao.


    Edoardo Benussi
    Microsoft MVP - Directory Services
    edo[at]mvps[dot]org

    venerdì 31 gennaio 2014 08:56
    Moderatore

Tutte le risposte

  • salve Vladimiro,

    "sa" non e' di suo un account piu' "vulnerabile" di un altro, ma e' buona norma non utilizzarlo in quanto e' un "super user", cio' e' un account con privilegi amministrativi, ed andrebbe eventualmente utilizzato "solo" per attivita' amministrative e non per normali attivita' interattive... diciamo che nel tuo caso sarebbe "buona cosa" utilizzare un account appositamente generato con privilegi inferiori...

    detto cio', le trusted connections sono tendenzialmente ben supportate solo in ambiente di rete "non domestica", una rete che disponga di un Domain Controller, che si occupa appunto, tra le altre cose, di garantire a SQL Server, che la connessione entrante sia certifcata come appartenente alla rete stessa... in ambiente di "rete domestica" tale componente solitamente non c'e', quindi di base non e' possibile utilizzare l'autenticazione trusted per connessioni non locali alla macchina che esegue il servizio SQL Server... si puo', e spesso si riesce ancora, utilizzare un workaround, cioe' creare sulla macchina che esegue SQL Server, tanti account Windows NT (cioe' utenti di macchina stessa) quali e quanti sono gli altri account presenti nella rete domestica... avendo quindi una macchina in cucina utilizzata solitamente dall'account "Mamma", un account in camera del figlio solitamente utilizzata dall'account "Paolo" ed una macchina (con servizio SQL Server) in ufficio solitamentamente usata da te con account "Vladimiro", su quest'ultima macchina dovresti generare gli account "Mamma" e "Paolo"... questo workaround si basa sul principio di illudere SQL Server che la connessione remota proveniente dalla macchina "Mamma" (quindi Cucina\Mamma) sia a tutti gli effetti invece proveniente dalla macchina ufficio (quindi Ufficio\Mamma), perche' la connessione remota vuole/tenta di impersonificare un account locale (Ufficio\Mamma), appunto giocando con l'impersonificazione ancora consentita da NetBios... solitamente (ed a mio parere stranamente) riesce ancora a funzionare (forse per compatibilita' con un passato molto lasco in problemi di sicurezza), anche se talvolta problemi di rete possono alterare l'handshaking e quindi bloccare il processo di impersonificazione...

    relativamente alla seconda domanda, questa e' ovviamente "scomoda" :) cosa intendi con "problemi di riservatezza dei dati causati da qualcuno esterno alla propria rete domestica?" ??? ovviamente se un "esterno" entra nella rete locale, questi ha bucato il firewall a monte dell'uscita internet, e tutte le share di rete sono a sua disposizione, oltre che la macchina della quale puo' aver preso il controllo :(

    questo e' potenzialmente un altro motivo di non connettersi a SQL Server con privilegi amministrativi, in quanto ad esempio l'attaccante potrebbe far eseguire a SQL Server stesso comandi non solo capaci di danneggiare la base dati, ma di attaccare anche il livello del sistema operativo tramite chiamate al subsystem dello stesso... SQL Server mette a disposizione strumenti quali ad esempio la stored procedure di sistema xp_cmdshell, che consente di passare comandi al sistema operativo... oppure generare codice CLR (basato sul DotNet Framework scrivendo ad esempio codice in VB e c#) che effettui anche questo alterazioni a livello di sistema operativo... va comunque detto che, di base, tali funzionalita' vanno esplicitamente abilitate in quanto la politica corrente di Microsoft e' di rilasciare prodotti con una superficie di attacco sempre piu' per fortuna limitata... in ogni caso, se la rete domestica viene violata, penso che nel tuo caso il problema di SQL Server sia probabilmente il problema minore :( ....

    saluti protetti da firewall :)


    http://www.hotelsole.com/asql/index.php - DbaMgr2k - DbaMgr and further SQL Tools http://www.hotelsole.com/

    domenica 29 dicembre 2013 11:35
    Moderatore
  • Ciao Andrea,

    intanto non posso che ringraziarti per il modo in cui hai saputo rispondere a delle mie perplessità.

    relativamente alla seconda domanda, questa e' ovviamente "scomoda" :) cosa intendi con "problemi di riservatezza dei dati causati da qualcuno esterno alla propria rete domestica?" ??? ovviamente se un "esterno" entra nella rete locale, questi ha bucato il firewall a monte dell'uscita internet, e tutte le share di rete sono a sua disposizione, oltre che la macchina della quale puo' aver preso il controllo :(

    ok! dalla risposta si deduce che un eventuale intromissione alla rete locale non potrà mai dipendere dal tipo di connessione adottata.

    si puo', e spesso si riesce ancora, utilizzare un workaround, cioe' creare sulla macchina che esegue SQL Server, tanti account Windows NT (cioe' utenti di macchina stessa) quali e quanti sono gli altri account presenti nella rete domestica

    bene, è proprio quello che cerco, solo che dovresti essere così cortese da spiegarmi come fare.

    Per gli auguri abbiamo ancora una giornata davanti :-)

    Vladimiro

    domenica 29 dicembre 2013 16:39
  • salve Vladimiro,

    nello stesso modo in cui hai generato l'utente con il quale sei connesso ora a Windows... ad esempio, ControlPanel->UserAccounts->....

    personalmente pero' ti consiglierei di fare come di seguito:

    vai in ControlPanel->Administrative Tools->Computer Management...

    aggiungi un Gruppo e dagli un nome consono a quanto debbano fare, ad esempio UtentiSQLInterattivi... poi aggiungi gli account usati sulle altre macchine e rendili membri del gruppo che hai appena creato... questo ti rendera' semplice identificarli e manutenerli... avrai quindi ora, sulla macchina UFFICIO che abbiamo detto ospitare il servizio SQL Server, copia degli account remoti, che localmente saranno UFFICIO\Paolo e UFFICIO\Mamma, oltre che il tuo account interattivo normale gia' presente sulla tua macchina UFFICIO, quindi UFFICIO\Vladimiro... e spero che UFFICIO\Vladimiro sia un account limitato e non un superuser :) ... rendi anche lui membro del gruppo prima inserito... collegati a SQL Server localmente con SQL Server Management Studio e, nel nodo Security->Logins... tasto destro, New Login (di tipo Win NT), nel login name premi il pulsante Search.. nel dialogo che appare, vai in Advanced, e premi il pulsante Object Types.. seleziona solo Gruppi, e quindi "cerca ora"... nella lista che appare sotto, seleziona il gruppo che hai creato e OK per confermare, fino a tornare al dialogo di genarazione della Login Win NT...

    la sicurezza in SQL Server si estende in 3 livelli... il primo livello riguarda la capacita' di connessione al servizio stesso, e l'hai appena garantito al gruppo in oggetto, e per principio di eredita' ovviamente a tutte le login membro del gruppo stesso...

    il secondo livello di sicurezza intende la capacita' di collegarsi ad ogni singolo database, a meno che la login gestita non sia membro di ruoli particolari e specificatamente amministrativi.. "sa" e' superuser per eccellenza in quanto membro del ruolo del server (SQL Server) "sysadmin" e puo' quindi "fare" qualsiasi cosa con il server e collegarsi a qualsiasi database... i "nostri" utenti saranno invece limitati e quindi dobbiamo intervenire per garantire l'accesso al secondo livello di sicurezza, i database... nel pannello "User Mapping", seleziona i database che possono interessare il guppo stesso, tipicamente il database Access che e' stato "montanto" in SQL Server e "spunta" la mappatura a quel/i database...

    qui entra in gioco il terzo livello/fase di sicurezza...

    la login iniziale di connessione, UFFICIO\Mamma, tramite l'appartenenza al gruppo UtentiSQLInterattivi ha superato il primo livello (la connessione al servizio) ed il secondo livello (l'accesso allo specifico database)... non essendo membro di ruoli amministrativi del server, sara' solo membro del ruolo di database "public" e si devono garantire servizi specifici per l'accesso agli oggetti nel database (la terza fase), quindi tabelle, viste, stored procedure, funzioni e quant'altro... un "metodo semplice" si basa sul servirsi di ruoli presenti a livello di ogni database che sono stati gia' preconfezionati garantendo la possibilita' di "leggere tutte le tabelle" (db_datareader) e "scrivere in tutte le tabelle" (db_datawriter)...

    personalmente non uso mai questo tipo di autorizzazioni anche perche' "nessuno", nei miei database, puo' direttamente accedere alle tabelle, ma tutti gli accessi avvengono tramite opportune stored procedures... tecnicamente creo dei ruoli di database specifici che siano autorizzati ad eseguire le stored procedures interessanti al gruppo stesso, e quindi "mappo" gli utenti ai ruoli stessi... ad esempio in maniera semplicistica, chi sia membro del gruppo "Segreteria" potra' accedere solitamente a (quasi) tutti i dati (tramite stored procedures), chi invece sia membro del ruolo "Magazzino", ovviamente potra' solo accedere ai dati relativi all'area di pertinenza, e cosi' via.... pero' forse stiamo andando un po' troppo oltre :)

    spero di aver reso idea di come funzioni la sicurezza in ambiente SQL Server, e scusa gli sproloqui e la lunghezza :)

    saluti autorizzati :)


    http://www.hotelsole.com/asql/index.php - DbaMgr2k - DbaMgr and further SQL Tools http://www.hotelsole.com/

    domenica 29 dicembre 2013 18:02
    Moderatore
  • Ciao Andrea,

    aggiungi un Gruppo e dagli un nome consono a quanto debbano fare, ad esempio UtentiSQLInterattivi... poi aggiungi gli account usati sulle altre macchine e rendili membri del gruppo che hai appena creato

    -> Utenti e gruppi locali -> Utenti / Gruppi

    ho scelto Gruppi e ne ho creato uno nuovo; al momento però dell'inserimento dei membri del gruppo, a parte il mio nome, non mi fa inserire nulla.

    Facendo clic su "Percorsi" appare solo quello del mio computer. Andando sulla Rete trovo però il nome del mio computer e quello di mia figlia.

    Non so cosa fare.

    Vladimiro

    domenica 29 dicembre 2013 20:00
  • salve Vladimiro,

    dei ricreare anche sul tuo computer l'account che tua figlia ha sul suo computer... poi lo potrai unire al gruppo che hai creato...

    saluti


    http://www.hotelsole.com/asql/index.php - DbaMgr2k - DbaMgr and further SQL Tools http://www.hotelsole.com/

    domenica 29 dicembre 2013 20:38
    Moderatore
  • Ciao Andrea,

    sono riuscito a creare il gruppo con i vari account, ho cercato di seguire passo passo quello che mi hai scritto:

    di seguito il link per vedere i vari passaggi (mi sono fermato al secondo punto senza entrare nel merito del database:

    https://skydrive.live.com/view.aspx?cid=DFDFB766AA86F9D8&resid=DFDFB766AA86F9D8%21210&app=Word&wdo=1

    nella seconda immagine l'eventuale autenticazione di Windows o SQL Server risulta ghiacciata per cui non saprei come connettermi da un altro computer se non con sa e password. Dal mio computer che fa da server non c'è neanche bisogno di autenticazione.

    Domani sono a lavoro, eventualmente ci sentiamo domani pomeriggio sul tardi.

    Vladimiro


    domenica 29 dicembre 2013 22:53

  • http://www.hotelsole.com/asql/index.php - DbaMgr2k - DbaMgr and further SQL Tools http://www.hotelsole.com/

    lunedì 30 dicembre 2013 00:42
    Moderatore
  • Ciao Andrea,

    sarà il mio SQL Server Management Studio di un altro pianeta, ma è la seconda volta che mi chiedi di fare delle cose impossibili per la mia applicazione.

    L'altra volta mi chiedevi di passare per il pannello Securables che non ho mai trovato, questa volta mi chiedi di selezionare l'autenticazione di Windows che a me risulta ghiacciata. Ho notato però dalla tua immagine, che all'interno del pulsante cerca non appare nessun nome, mentre a me me lo dà già predefinito senza possibilità di cancellarlo.

    Comunque ti riscrivo i passaggi che faccio, magari sto sbagliando qualcosa.

    Apro SQLMS, seleziono Sicurezza->Account di accesso->ACER/Utenti_SQL_Interattivi e mi ritrovo:

    come vedi la parte da te evidenziata è ghiacciata.

    Che ne pensi?

    Vladimiro

    lunedì 30 dicembre 2013 16:53
  • salve Vladimiro,

    sarà il mio SQL Server Management Studio di un altro pianeta, ma è la seconda volta che mi chiedi di fare delle cose impossibili per la mia applicazione.

    no il tuo e' in italiano ed il mio in inglese, ma ora ho capito una cosa "importante" :)

    tu scrivi: "... Apro SQLMS, seleziono Sicurezza->Account di accesso->ACER/Utenti_SQL_Interattivi e mi ritrovo ..."

    il dialogo mio invece prevedeva non l'accesso in modifica ad un gruppo\account esistente, ma la creazione di uno totalmente nuovo... gestendone uno esistente giocoforza ti ritrovi alcune impostazioni non modificabili :) ... comunque procedi pure :)

    saluti sicurabili 


    http://www.hotelsole.com/asql/index.php - DbaMgr2k - DbaMgr and further SQL Tools http://www.hotelsole.com/

    lunedì 30 dicembre 2013 18:09
    Moderatore
  • Ciao Andrea,

    ... comunque procedi pure :)

    e come? Non so che altro fare oltre a quello che ti ho fatto vedere tramite link.

    Allora:

    mi ritrovo sul mio computer, dove è installato SQL, 3 account di cui uno mio e il gruppo ACER/Utenti_SQL_Interattivi. 

    Dal mio computer un database connesso a SQL, si apre normalmente, mentre da un altro computer che ha come account (senza password) il nome Giulietta, lo stesso database non si connette; solo inserendo "sa" e password si connette.

    Che dici, provo ad installare SQLSMS in inglese?

    Vladimiro

    lunedì 30 dicembre 2013 18:51
  • salve Vladimiro,

    ... comunque procedi pure :)

    e come? Non so che altro fare oltre a quello che ti ho fatto vedere tramite link. Allora: mi ritrovo sul mio computer, dove è installato SQL, 3 account di cui uno mio e il gruppo ACER/Utenti_SQL_Interattivi. Dal mio computer un database connesso a SQL, si apre normalmente, mentre da un altro computer che ha come account (senza password) il nome Giulietta, lo stesso database non si connette; solo inserendo "sa" e password si connette.

    questo e' il problema che intendevo nella risoluzione netbios della soluzione basata su impersonificazione... purtroppo "puo' non funzionare sempre" anche se in letteratura dovrebbe...

    direi di verificare che gli account che hai creato localmente alla TUA macchina replichino correttamente gli account remoti [e l'utilizzo di password dovrebbe aiutare molto :) ]

    Che dici, provo ad installare SQLSMS in inglese?

    direi proprio di no :)

    puoi pero' cambiare autenticazione e rimanere con l'autenticazione standard SQL Server... pero', invece di utilizzare "sa", utilizza un altro account con autenticazione SQL Server, per il quale devi procedere con le autorizzazioni come precedentemente gia' indicato, che e' il sistema piu' tradizionale in ambiente di rete locale non provvista di Domain Controller, e forse e' il motivo per il quale l'autenticazione standard SQL sia ancora disponibile...

    saluti standard...


    http://www.hotelsole.com/asql/index.php - DbaMgr2k - DbaMgr and further SQL Tools http://www.hotelsole.com/

    martedì 31 dicembre 2013 11:16
    Moderatore
  • Grazie Andrea, per il momento ti faccio i miei più cordiali auguri di BUON ANNO NUOVO poi magari ne riparliamo.

    Auguri a tutti.

    Vladimiro

    martedì 31 dicembre 2013 16:47
  • Ciao,

    per forza di cose ho dovuto rifare il restore al computer e di conseguenza una nuova installazione di SQL Server 2008 R2.

    Scegliendo nuovamente la connessione mista, ho dovuto solo inserire la password in quanto l'account "sa" me lo ha dato in default. Per il momento accantonerei il discorso su "sa" in quanto e forse è stato meglio così in quanto probabilmente sbagliavo qualcosa, dall'altro computer di casa non riesco più a connettermi se non disattivando il firewall del percorso di rete pubblica.

    Al seguente link, facendo scorrere il cursore, si possono vedere 4 immagini che dovrebbero far capire quello che ho fatto finora:

    https://skydrive.live.com/view.aspx?cid=DFDFB766AA86F9D8&resid=DFDFB766AA86F9D8%21221&app=Word&wdo=1

    Ho anche attivato SQL Server Browser ma siccome la connessione non avveniva l'ho nuovamente disattivato.

    Spero vivamente che riusciate a farmi capire dove sbaglio. Sono così sconfortato!!!

    Vladimiro

    mercoledì 8 gennaio 2014 17:50
  • immagine 3 -> come fai a connetterti se i protocolli named pipe e tcp/ip sono entrambi disattivati ?

    devi passarli in attivati e, se serve, configurarli (almeno il tcp/ip.


    Edoardo Benussi
    Microsoft MVP - Directory Services
    edo[at]mvps[dot]org

    giovedì 9 gennaio 2014 13:27
    Moderatore
  • immagine 3 -> come fai a connetterti se i protocolli named pipe e tcp/ip sono entrambi disattivati ?

    devi passarli in attivati e, se serve, configurarli (almeno il tcp/ip.


    Edoardo Benussi
    Microsoft MVP - Directory Services
    edo[at]mvps[dot]org

    Ciao Edoardo, se guardi bene l'immagine, sopra di essa ho scritto che i due protocolli pur attivati, non risolvevano il problema per cui li ho nuovamente disattivati. Tu parli di configurare il tcp/ip nel senso del numero di porta? Se è questo che intendi, ho lasciato la porta predefinita 1433.

    Guarda, dopo aver letto la tua risposta, per scrupolo, li ho riattivati ma non è cambiato nulla. Questa cavolo di connessione avviene solo disattivando il firewall del percorso di rete pubblica (invece disattivando l'altro firewall: Reti domestiche o aziendali (private) non succede nulla).

    Vladimiro

    giovedì 9 gennaio 2014 16:45
  • Ciao,

    nessun aiutino?

    Vladimiro

    sabato 11 gennaio 2014 10:31
  • salve Vladimiro,

    come default, il firewall integrato (ma mi risulta che tutti i firewall siano impostati in tal senso) non permette connessioni esterne, e questo sempre per limitare la superficie di attacco disponibile ad eventuali malintenzionati.. tecnicamente quindi, sempre di default, tutto quello che "non e' gestito" tramite apposite eccezioni, e' impostato su "DENY" :) [... e vide che questa era cosa buona :) ]

    devi quindi predisporre un'apposita eccezione, sulla porta di ascolto TCP/IP predisposta, oppure sul "servizio" stesso di SQL Server (basando l'eccezione sull'eseguibile ...  xx:\Program Files\Microsoft SQL Server\MSSQL11.NomeIstanza\MSSQL\Binn\sqlservr.exe ....nel caso SQLBrowser sia attivo, e questo solitamente per le sole istanze nominate, dovresti fare una regola di eccezione anche per la porta UDP 1434... 

    in parole molto povere, il servizio SQLBrowser viene installato automaticamente unitamente all'installazione di SQL Server, tutte le edizioni..
    e' un servizio utilizzato esclusivamente per la risoluzione delle istanze nominate, operante sulla porta UDP 1434, che non siano state impostate con una porta statica bensi' con una porta dinamica (default)..
    SQL Server ha potuto registrare presso Iana solo la porta TCP/IP 1433 da assegnare a SQL Server e quindi questa e' l'unica porta "nota" tipicamente utilizzata per le istanze di default (ma come dicevo, la maggior parte degli amministratori ne cambia l'impostazione proprio perche' risulta una "porta nota" :D); per questo motivo Microsoft ha escogitato un modo per far si che le istanze nominate quali MyComputer\SQLExpress possano essere risolte senza specificare in ogni stringa di connessione la porta sulla quale sia in ascolto il servizio stesso..
    un'istanza con impostazione di porta dinamica, ad ogni startup verifica che la porta utilizzata nell'ultima sessione sia disponibile e libera, ed in questo caso la utilizza nuovamente, diversamente ne utilizza un'altra riservandola per la sessione corrente e registrando questa informazione.. in questo caso e' chiaramente difficile per i vari client sapere a priori verso quale porta indirizzare le proprie richieste..
    qui entra in gioco SQL Browser, che intercetta sulla porta UDP1434 tutti i tentativi di connessione ad istanze nominate provenienti da client che aprano una connessione verso il nostro servizio SQL Server, richieda all'istanza in questione (accedendo alle sue impostazioni di Windows registry) la porta specifica, restituisca questa informazione al chiamante
    sullo stack del protocollo di rete che viene reindirizzato sulla porta utilizzata chiudendo l'accept della connessione.. le conversazioni successive tra client e server (e viceversa), fino a che la connessione non verra' chiusa, continueranno senza la necessita' di far intervenire nuovamente SQL Browser..  e' necessaria la sua abilitazione solo nel caso di utilizzo di istanze nominate con impostazione dinamica della porta e solo per connessioni remote, ma e' possibile in ogni caso disabilitarlo specificando al momento della connessione la porta effettiva di ascolto... questo e' ovviamente piu' semplice se la porta e' fissa e non dinamica :)

    comunque, tornando al firewall.... personalmente preferisco definire l'eccezione non sul programma bensi' sulla sola porta utilizzata, e nel caso "standard" solitamente questa e' la porta TCP/IP 1433, come anche tu riporti, che comunque non andrebbe usata in quanto, come gia' detto, e' una "known port", cioe' "tutti gli attaccanti" sanno che su quella porta solitamente e' in ascolto un servizio SQL Server :) .... di nuovo, le istanze nominate, come standard, non dovrebbero MAI essere in ascolto su quella porta, e di default sono settate per un'impostazione dinamica della porta di ascolto....

    fidandoci del mondo, crea un'eccezione che invece di DENY faccia ALLOW :)

    di seguito uno screenshot

    saluti protetti (DENY ALL!!!) :)


    http://www.hotelsole.com/asql/index.php - DbaMgr2k - DbaMgr and further SQL Tools http://www.hotelsole.com/

    sabato 11 gennaio 2014 16:54
    Moderatore
  • Ciao Andrea,

    ti ringrazio per le ulteriori illustrazioni e per il tempo che mi hai dedicato.

    Leggendoti, tante cose mi sono ancora più chiare perché nel frattempo ho cercato di documentarmi su Shared Memory, Named Pipes, TCP/IP e su SQL Browser.

    Purtroppo la tua illustrazione già l'avevo messa in atto, lasciando il segno di spunta anche su Public e come nome, invece di "SQL Server TCP/IP 1433", gli avevo dato semplicemente il nome di "Nuova_Regola1".

    Il problema è che allora, come adesso, non ho saputo andare avanti; nel senso che dal mio computer lato server mi connetto tranquillamente senza bisogno di inserire l'account, mentre dall'altro lato client cosa debbo inserire se non "sa" e password con cui ho installato SQL?

    Ho anche attivato SQL Browser senza configurarlo però in quanto debbo capire bene come si fa e sarà sicuramente il passo successivo in quanto non ho nessuna voglia di lasciare la connessione sulla porta predefinita.

    Probabilmente mi sto perdendo in un bicchiere d'acqua, ma ancora non riesco a connettermi da lato client :-(

    Vladimiro

    sabato 11 gennaio 2014 19:59
  • Ciao Andrea,

    ti ringrazio per le ulteriori illustrazioni e per il tempo che mi hai dedicato.

    Leggendoti, tante cose mi sono ancora più chiare perché nel frattempo ho cercato di documentarmi su Shared Memory, Named Pipes, TCP/IP e su SQL Browser.

    Purtroppo la tua illustrazione già l'avevo messa in atto, lasciando il segno di spunta anche su Public e come nome, invece di "SQL Server TCP/IP 1433", gli avevo dato semplicemente il nome di "Nuova_Regola1".

    Il problema è che allora, come adesso, non ho saputo andare avanti; nel senso che dal mio computer lato server mi connetto tranquillamente senza bisogno di inserire l'account, mentre dall'altro lato client cosa debbo inserire se non "sa" e password con cui ho installato SQL?

    usare "sa" permette, giustamente, di accedere ad una istanza di sql server ma non bisogna dimenticare che "sa" è un account conosciuto solo da SQL Server e non fa parte degli account di sicurezza del server su cui lavori mentre, per consentire di accedere alle risorse di una macchina che siano condivise in rete sono necessari account utente di Windows che possano anche navigare in rete. ecco cosa ti manca!

    per arrivare al risultato devi avere:

    1) un account di Windows che possa navigare sulle altre risorse della rete locale;

    2) dare i permessi su SQL Server a questo account sia come login all'istanza sia sui securables dei database.

    ciao.


    Edoardo Benussi
    Microsoft MVP - Directory Services
    edo[at]mvps[dot]org

    lunedì 13 gennaio 2014 10:01
    Moderatore

  • per arrivare al risultato devi avere:

    1) un account di Windows che possa navigare sulle altre risorse della rete locale;

    2) dare i permessi su SQL Server a questo account sia come login all'istanza sia sui securables dei database.

    ciao.


    Edoardo Benussi
    Microsoft MVP - Directory Services
    edo[at]mvps[dot]org

    Ciao Andrea,

    ormai è un po' di tempo che affrontiamo insieme questo mio problema.

    Sarà sicuramente la mia poca capacità a saper mettere in pratica quello che mi viene suggerito, sta di fatto che non so più come andare avanti.

    Allora, dal mio computer (server) prendo un database di Access e tramite l'upsize guidato esporto le tabelle in SQL e allo stesso tempo mi ritrovo nel database nuove tabelle connesse a SQL. Come ripeto, dal mio computer la connessione mi viene data automaticamente senza bisogno di inserire né account e né password (come dici tu, mi viene riconosciuta un'istanza di SQL con account predefinito "sa" in quanto è la stessa macchina dove è istallata l'applicazione).

    Faccio una copia del database e lo incollo sul computer di mia figlia; quando tento di aprirlo mi esce la seguente maschera:

    Tu dici:

    1) un account di Windows che possa navigare sulle altre risorse della rete locale;

    2) dare i permessi su SQL Server a questo account sia come login all'istanza sia sui securables dei database.

    Se ricordi, l'altra volta ho provato a ricreare sul mio computer gli stessi account degli altri due computer senza nulla di fatto. Mi spieghi più dettagliatamente, per favore, i passi da compiere?

    Vladimiro


    lunedì 13 gennaio 2014 17:15
  • Ciao,

    debbo arrendermi alle mie lacune?

    Vladimiro

    martedì 14 gennaio 2014 15:34
  • non sono Andrea ma va bene ugualmente :)

    ti mancano alcune basi di networking, di sicurezza e di domini Windows per riuscire ad uscire dall'impasse, comunque proviamoci.

    domande:

    1) quali sistemi operativi hanno le due macchine della tua rete ?

    2) hai un dominio active directory o un workgroup ?

    3) hai già condiviso delle cartelle su ciascuna delle due macchine e riesci ad accedervi rispettivamente dall'altra macchina connessa in rete ?


    Edoardo Benussi
    Microsoft MVP - Directory Services
    edo[at]mvps[dot]org

    martedì 14 gennaio 2014 15:36
    Moderatore
  • assolutamente no :)

    rispondi alle domande che ti ho fatto così proviamo a fare un passetto avanti.


    Edoardo Benussi
    Microsoft MVP - Directory Services
    edo[at]mvps[dot]org

    martedì 14 gennaio 2014 15:43
    Moderatore
  • Ciao Edoardo e scusami per la gaffe!

    1) quali sistemi operativi hanno le due macchine della tua rete ?

    Windows7 Ultimate entrambi i computer

    2) hai un dominio active directory o un workgroup ?non mi pare di avere nessuno dei due; come gruppo di lavoro predefinito mi esce: WORKGROUP

    3) hai già condiviso delle cartelle su ciascuna delle due macchine e riesci ad accedervi rispettivamente dall'altra macchina connessa in rete ?

    non ho nessuna cartella condivisa

    Vladimiro

    martedì 14 gennaio 2014 16:45
  • ok. come attività didattica dovresti provare a condividere una cartella su ciascun pc, creare un account con stessa username e apssword su ciascun pc, provare a fare login su ogni pc con quell'account creato ad hoc e accedere alla cartella condivisa dell'altro pc.

    pensi di riuscirci ?

    aiutati con questo articolo

    http://www.pcadvisor.co.uk/how-to/windows/3434911/how-share-folders-without-homegroups-in-windows-7/


    Edoardo Benussi
    Microsoft MVP - Directory Services
    edo[at]mvps[dot]org

    mercoledì 15 gennaio 2014 09:48
    Moderatore
  • ok. come attività didattica dovresti provare a condividere una cartella su ciascun pc, creare un account con stessa username e apssword su ciascun pc, provare a fare login su ogni pc con quell'account creato ad hoc e accedere alla cartella condivisa dell'altro pc.

    pensi di riuscirci ?

    aiutati con questo articolo

    http://www.pcadvisor.co.uk/how-to/windows/3434911/how-share-folders-without-homegroups-in-windows-7/


    Edoardo Benussi
    Microsoft MVP - Directory Services
    edo[at]mvps[dot]org

    Ciao Edoardo e scusami se non ti ho risposto prima.

    Purtroppo con questo procedimento non ne vengo a capo; ti spiego. 

    A me interessa capire bene la connessione a prescindere dai sistemi operativi installati nei vari computer di una stessa rete.

    Il fatto che stia usando la rete di casa mia è solo un pretesto per imparare come si fa.

    Quello che mi serve realmente, è saper attivare la condivisione tra vari computer nella stessa rete di uno studio dentistico dove dovrò migrare un database di Access in SQL Server.

    Spero solo nella tua/vostra pazienza.

    Vladimiro.

    sabato 18 gennaio 2014 09:54
  • proprio per questo motivo ti faccio fare questo esercizio didattico: se vuoi capire le connessioni, devi capire che ci sono account utente autorizzati ad utilizzare la rete e ad accedere da un sistema ad un altro. gli account utente dei sistemi Windows sono utenti che possono accedere alle macchine della rete, l'account "sa" di SQL non è un utente del sistema Windows ma solo un utente di SQL Server quindi può si accedere a SQL server ma non può navigare sulla rete ed accedere ad altri sistemi della rete stessa.

    Edoardo Benussi
    Microsoft MVP - Directory Services
    edo[at]mvps[dot]org

    sabato 18 gennaio 2014 15:45
    Moderatore
  • salve Vladimiro,

    .... il problema di base.... purtroppo, e' quello che dice Edo.... comprendo la tua esigenza, ma devi purtroppo "soggiacere" ad un vincolo per certi versi elementare... provo a ri-esporre il mio concetto...

    se utilizzi una login SQL Server di tipo standard (e comunque diversa da "sa"), non ti sobbarchi le problematiche che stai incontrando, in quanto il problema "networking" dovrebbe essere automagicamente eliminato... se invece vuoi utilizzare una Authenticated Connection, di base servirebbe un Domain Controller nella rete locale... in parole molto povere, questo e' lo strumento di autenticazione principe in ambiente Windows, ed e' supportato da SQL Server... chiunque si autentichi positivamente in Windows puo' provare a connettersi a SQL Server... se l'autenticazione e' garantita anche da SQL Server, allora sarai dentro l'istanza SQL.... poi seguono le altre 2 fasi della sicurezza che ho in precedenza indicato....

    se NON hai un Domain Controller nella rete locale in quanto questa consta di un WorkGroup di macchine paritarie, si puo' "tentare" la strada, come detto in precedenza, della "impersonificazione"... sulla Macchina1, c'e' l'account Andrea... sulla Macchina2 c'e' l'account Edo, sulla Macchina3 c'e' l'account Vladimiro... il server SQL e' sulla Macchina3... quindi, sempre su tale macchina, devi creare gli account Macchina3\Edo e Macchina3\Andrea, con password uguali a quelle originali delle macchine di origine... quando Macchina1\Andrea prova a connettersi a SQL Server sulla Macchina3, l'account Macchina1\Andrea cerchera' di impersonare Macchina3\Andrea... se ci riesce, potra' tentare di connettersi a SQL Server... lo stesso per Macchina2\Edo... ma come gia' detto, non sempre questo riesce, a prescindere che si siano fatte le cose "per bene"... se non si riesce a risolvere la problematica, che in questo caso e' legata al networking, l'unica strada viabile resta l'autenticazione standard SQL... questo ovviamente partendo dal presupposto che le connessioni di rete intermacchina tra Macchina1 e Macchina3 ovviamente funzionino... per questo Edo ti chiede se ci sono Share condivise tra le macchine e se queste sono raggiungibili dalle macchine remote...

    Edo, ovviamente correggi dove necessario :)

    saluti condivisi di rete :)


    http://www.hotelsole.com/asql/index.php - DbaMgr2k - DbaMgr and further SQL Tools http://www.hotelsole.com/


    sabato 18 gennaio 2014 15:53
    Moderatore
  • proprio per questo motivo ti faccio fare questo esercizio didattico: se vuoi capire le connessioni, devi capire che ci sono account utente autorizzati ad utilizzare la rete e ad accedere da un sistema ad un altro. gli account utente dei sistemi Windows sono utenti che possono accedere alle macchine della rete, l'account "sa" di SQL non è un utente del sistema Windows ma solo un utente di SQL Server quindi può si accedere a SQL server ma non può navigare sulla rete ed accedere ad altri sistemi della rete stessa.

    Edoardo Benussi
    Microsoft MVP - Directory Services
    edo[at]mvps[dot]org

    D'accordo, però riesci a spiegarmi il motivo per cui prima di reinstallare SQL Server sul mio computer, la connessione dal computer di mia figlia la facevo tranquillamente tramite account "sa"?

    Vladimiro


    sabato 18 gennaio 2014 15:56
  • Edo, ovviamente correggi dove necessario :)

    niente da correggere salvo il fatto che non credo che l'uso di "sa" prevalga sui permessi di accesso alle macchine in rete bypassando il controllo del sistema operativo. cerco di spiegarmi meglio partendo dalla base: i diritti principali di accesso di utenti e gruppi sono

    1) logon locally

    2) logon from the network

    e diritti ulteriori sono

    3) logon as a service

    4) logon through terminal services

    soffermandoci solo sui primi due, sono certo che se a "sa" metto un deny esplicito per quei due diritti, sa non potrà accedere all'istanza di SQL che sta installata su un layer superiore rispetto a quello del s.o. il fatto che "sa" possa bypassare il controllo di Windows può essere garantito solo se (e andrò a verificarlo) sa è membro di un gruppo di sicurezza di windows al quale sono automaticamente garantiti quei due diritti altrimenti nisba.

    ecco perchè cerco di far capire a Vladimiro le basi della sicurezza di Windows e del networking.

    ciao.


    Edoardo Benussi
    Microsoft MVP - Directory Services
    edo[at]mvps[dot]org

    sabato 18 gennaio 2014 17:28
    Moderatore
  • D'accordo, però riesci a spiegarmi il motivo per cui prima di reinstallare SQL Server sul mio computer, la connessione dal computer di mia figlia la facevo tranquillamente tramite account "sa"?

    come ho scritto ad Andrea qui sotto, ci sono dei principi di base nella sicurezza di Windows che sono fatti nel modo descritto e ti invito a leggere quel post. ovviamente Windows è uno strumento e permette di configurare il sistema e la sua sicurezza come meglio uno crede (se vuole farsi male :) ).

    un motivo per cui può accadere quello che tu hai scritto qui sopra è

    1) l'account Guest (che esiste su tutti i sistemi) è stato accidentalemente abilitato (di default è disabilitato per ridurre la superficie d'attacco del sistema)

    2) i diritti di cui ho parlato ( Logon locally e Logon from the network) possono essere dati anche al gruppo Everyone ed ecco che consento l'accesso anonimo ai sistemi sia in locale sia dalla rete

    entrambi questi scenari, potrai facilmente capire, sono estremamente pericolosi da adottare ed ecco perchè sono fortemente sconsigliati.

    ciao


    Edoardo Benussi
    Microsoft MVP - Directory Services
    edo[at]mvps[dot]org

    sabato 18 gennaio 2014 17:36
    Moderatore
  • Ok, grazie ad Edoardo ed Andrea.

    Allora:

    1) Ho creato un gruppo Home (anche se lo posso vedere da entrambi i computer, le cartelle predefinite al suo interno non si aprono).

    2) Ho condiviso una cartella con tanto di trasferimento file, lettura ed inserimento dati da entrambi i computer.

    Ed ora cosa debbo fare?

    Vladimiro

    sabato 18 gennaio 2014 22:54
  • 1) Ho creato un gruppo Home (anche se lo posso vedere da entrambi i computer, le cartelle predefinite al suo interno non si aprono).

    2) Ho condiviso una cartella con tanto di trasferimento file, lettura ed inserimento dati da entrambi i computer.

    Ciao,

    prima di creare un altro account sia sul mio computer che sull'altro, vorrei che mi chiariste un dubbio.

    Il mio account è Vladimiro Administrator ed accedo al computer senza inserire né account e né password, l'altro è Giulietta Administrator ed allo stesso modo accede al suo computer senza inserire nulla.

    Quando andrò a creare sul mio computer un nuovo account, basta che scriva solo Giulietta oppure Giulietta/Administrator?

    Vladimiro

    domenica 19 gennaio 2014 18:29
  • Ciao,

    nessun aiuto?

    Vladimiro

    martedì 21 gennaio 2014 17:40
  • le persone che rispondono qui sono volontari, non sono dipendenti di Microsoft ed hanno bisogno di lavorare per mangiare :)

    il fatto che gli utenti siano entrambi Administrator della loro macchina non è buono e neanche il fatto che siano senza password.

    supponiamo che tu attribuisca ad entrambi una password.

    supponiamo che SQL server sia sul pc di Vladimiro

    supponiamo che tu autorizzi l'account Vladimiro ad essere un login di SQL Server e che gli consenti di accedere ai database

    supponiamo che tu vada sul pc di tua figlia e da li effettui la connessione a SQL Server con le credenziali di Vladimiro.

    con queste supposizioni la tua connessione al database dovrebbe andare a buon fine.


    Edoardo Benussi
    Microsoft MVP - Directory Services
    edo[at]mvps[dot]org

    mercoledì 22 gennaio 2014 11:12
    Moderatore
  • Ciao Edoardo,

    le persone che rispondono qui sono volontari, non sono dipendenti di Microsoft ed hanno bisogno di lavorare per mangiare :)

    ci mancherebbe, la mia era solo preoccupazione di essere dimenticato nel vedere che il post andava "sempre più giù" :-) ... mi scuso per questa mia insistenza!

    supponiamo che tu autorizzi l'account Vladimiro ad essere un login di SQL Server e che gli consenti di accedere ai database

    vuoi dire in una nuova query di SQLMS creo:

    Create Login Nuovo_Account_Vladimiro With Password = '0123456'

    e poi dal computer di mia figlia, accedendo con il nuovo account (non da Administrator) in questo modo:

    Nome account di accesso: Nuovo_Account_Vladimiro

    Password: 0123456

    dovrei connettermi?

    Vladimiro

    mercoledì 22 gennaio 2014 22:44
  • cos'è Nuovo_Account_Vladimiro ?

    tu il login in SQL Server lo9 devi creare usando il tuo vero user account name che usi per accedere al pc, inoltre quello dovrebbe avere una password e l'aggiunta del login non serve farlo con un comando T-SQL ma puoi usare l'interfaccia grafica di SSMS.


    Edoardo Benussi
    Microsoft MVP - Directory Services
    edo[at]mvps[dot]org

    venerdì 24 gennaio 2014 08:53
    Moderatore
  • cos'è Nuovo_Account_Vladimiro ?

    tu il login in SQL Server lo9 devi creare usando il tuo vero user account name che usi per accedere al pc, inoltre quello dovrebbe avere una password e l'aggiunta del login non serve farlo con un comando T-SQL ma puoi usare l'interfaccia grafica di SSMS.


    Edoardo Benussi
    Microsoft MVP - Directory Services
    edo[at]mvps[dot]org

    Ciao Edoardo,

    quando pensi di aver capito qualcosa ... :-(

    Una volta creato un nuovo account sia al computer mio che a quello di mia figlia (tipo account standard con password), l'aggiunta di login che ho imparato a fare in SQL Server Management Studio tramite query (sbagliando l'acronimo avevo scritto SQLMS al posto di SSMS):

    tu dici che non serve in quanto posso usare l'interfaccia grafica di SSMS. Che significa? Hai ancora un po' di pazienza per spiegarmi meglio?

    <o:p>Vladimiro</o:p>


    sabato 25 gennaio 2014 16:02
  • vedo che l'account acer\Vladimiro è già uno dei login di sql server.

    hai provato ad usare quello per connetterti a sql dall'altro pc ?


    Edoardo Benussi
    Microsoft MVP - Directory Services
    edo[at]mvps[dot]org

    domenica 26 gennaio 2014 17:50
    Moderatore
  • vedo che l'account acer\Vladimiro è già uno dei login di sql server.

    hai provato ad usare quello per connetterti a sql dall'altro pc ?


    Edoardo Benussi
    Microsoft MVP - Directory Services
    edo[at]mvps[dot]org

    Ciao Edoardo, a questo punto, giuro, non ci capisco più niente e ti spiego il perché.

    Ho provato a connettermi tramite l'account acer\Vladimiro pur sapendo che non sarebbe servito a niente in quanto, anche con altri login creati, la connessione non è avvenuta ugualmente. E poi, anche per il fatto che nel suddetto account non esiste password e l'accoun

    t resta sempre sa:

    Comunque, son passato all'altro computer, ho inserito come account acer\Vladimiro senza inserire la password, naturalmente mi ha dato l'errore di non connessione; ho provveduto ad inserire la stessa password che metto quando l'account è sa e di nuovo l'errore di non connessione; però, subito dopo, modificando l'account acer\Vladimiro con sa, ecco la connessione:

    praticamente con sa e password, senza modificare il firewall e senza aver creato ancora altri account sui due computer, la connessione avviene tranquillamente.

    L'unica cosa diversa che ho fatto nel frattempo, è la formattazione di un vecchio computer con l'inserimento di XP come sistema operativo. 

    Non posso sentirmi soddisfatto in quanto, come ripeto, mi serve imparare il funzionamento perché l'installazione di SQL e la relativa connessione la debbo fare in uno studio privato e certamente non mi posso improvvisare!!!

    Che ne pensi?

    Vladimiro

    domenica 26 gennaio 2014 18:49

  • L'unica cosa diversa che ho fatto nel frattempo, è la formattazione di un vecchio computer con l'inserimento di XP come sistema operativo. 


    non ho ben capito questa faccenda dell'xp.

    vuoi dire che questa connessione è riuscita utilizzando un client xp aggiunto alla rete locale mentre da win7 non funziona ?


    Edoardo Benussi
    Microsoft MVP - Directory Services
    edo[at]mvps[dot]org

    mercoledì 29 gennaio 2014 14:29
    Moderatore

  • L'unica cosa diversa che ho fatto nel frattempo, è la formattazione di un vecchio computer con l'inserimento di XP come sistema operativo. 


    non ho ben capito questa faccenda dell'xp.

    vuoi dire che questa connessione è riuscita utilizzando un client xp aggiunto alla rete locale mentre da win7 non funziona ?


    Edoardo Benussi
    Microsoft MVP - Directory Services
    edo[at]mvps[dot]org

    Ciao Edoardo,

    allora le cose sono andate in questo modo.

    Ho cercato di ripristinare un vecchio portatile giacente in un cassetto per via dello schermo rovinato. L'ho formattato più di una volta inserendo come sistema operativo prima Windows7 e successivamente XP Professional con account di amministratore senza password.

    Non ho ancora provato a connettermi a SQL da questo computer, anche perché l'ho subito riposto nel cassetto ripromettendomi di usarlo non appena avrò un po' più di tempo; mentre, come ripeto, improvvisamente e senza modificare il firewall la connessione sia dal mio computer server (senza bisogno di inserire account e password) che dall'altro computer client (dopo aver inserito "sa" e password) avviene tranquillamente.

    Vorrei chiederti una cosa, quando scrivi:

    vedo che l'account acer\Vladimiro è già uno dei login di sql server.hai provato ad usare quello per connetterti a sql dall'altro pc ?

    come account scrivo acer\Vladimiro e come password cosa metto visto che non esiste nessuna password?

    Fammi sapere.

    Vladimiro


    mercoledì 29 gennaio 2014 17:08
  • Ciao Edoardo,

    fermo restando la seguente richiesta:

    vedo che l'account acer\Vladimiro è già uno dei login di sql server.hai provato ad usare quello per connetterti a sql dall'altro pc ?

    come account scrivo acer\Vladimiro e come password cosa metto visto che non esiste nessuna password?

    adesso che ho la possibilità di fare delle prove, vorrei spiegarti in maniera più chiara come avviene la connessione in SQL Server.

    XP non c'entra nulla.

    Visualizza il seguente link in modo da seguire la mia breve spiegazione:

    https://skydrive.live.com/view.aspx?cid=DFDFB766AA86F9D8&resid=DFDFB766AA86F9D8%21266&app=Word&wdo=1

    I protocolli disattivati non impediscono la connessione.

    Facendo clic su Ripristina impostazioni predefinite la connessione lato client dei due computer (Win7 e XP) non avviene più e neanche la visualizzazione della cartella condivisa (come da tuo suggerimento mi sono esercitato ad attivarla).

    Facendo clic su Risoluzione dei problemi di rete / Connessione in ingresso: I^ e II^ opzione, la connessione dei due client con account "sa" e password ritorna alla grande.

    Vladimiro.


    mercoledì 29 gennaio 2014 23:05
  • nelle premesse che ho scritto è che gli account di windows devono avere una password quindi davo per scontato che anche acer\Vladimiro avesse una password o che tu gliel'avessi definita.

    il fatto che "sa" permetta di bypassare il controllo accessi di windows sulla rete locale è probabilmente dovuto ai "laschi" permessi che tu hai definito.

    in particolare dovresti andare a verificare sul server, nelle local policies, chi ha il diritto di logon locally e di logon from the network oltre a verificare di non aver abilitato l'account guest.

    infine una domanda: ma la macchina con sql server che sistema operativo ha ? ha un sistema operativo server o client ?


    Edoardo Benussi
    Microsoft MVP - Directory Services
    edo[at]mvps[dot]org

    giovedì 30 gennaio 2014 13:10
    Moderatore
  • Ciao Edoardo,

    nelle premesse che ho scritto è che gli account di windows devono avere una password quindi davo per scontato che anche acer\Vladimiro avesse una password o che tu gliel'avessi definita.

    come ripeto, il solo account che ho a tutt'e tre le macchine è account di amministratore senza password. Assodato ciò, quello che ancora non ho capito è se esiste la possibilità di creare un account con password in SQL Server Management Studio e di connettermi lato client con quello.

    in particolare dovresti andare a verificare sul server, nelle local policies, chi ha il diritto di logon locally e di logon from the network oltre a verificare di non aver abilitato l'account guest.

    l'account Guest non è abilitato, per il resto, scusami ma non ho capito se andare a cercare in strumenti di configurazione SQL o in SSMS (tieni sempre presente che la mia versione è in italiano)infine una domanda: ma la macchina con sql server che sistema operativo ha ? 

    il sistema operativo dove è installato Microsoft SQL Server 2008 R2 è Windows7: cioè il mio computer. 

    ha un sistema operativo server o client ?

    non ho capito :-(

    Vladimiro

    giovedì 30 gennaio 2014 17:13
  • infine una domanda: ma la macchina con sql server che sistema operativo ha ? 

    il sistema operativo dove è installato Microsoft SQL Server 2008 R2 è Windows7: cioè il mio computer. 


    credo che abbiamo parlato inutilmente in questo thread perchè tutti i principi di sicurezza che ho enunciato riguardano i sistemi server e mi aspettavo che l'istanza di sql server fosse installata su un sistema server (Windows Server 2008, Windows Server 2012, ecc.ecc.) invece tu hai una infrastruttura di rete integralmente basata su sistemi client (XP, Vista, Windows 7). questo tipo di infrastruttura dispone solo in parte dell'architettura di sicurezza di Windows, di solito è destinata all'home computing e per rendere semplici le cose si usano i Workgroup o i Workplace per far comunicare le macchine in rete in maniera semplificata.

    parliamo quindi di infrastrutture diverse per cui non ha senso continuare.

    ciao.


    Edoardo Benussi
    Microsoft MVP - Directory Services
    edo[at]mvps[dot]org

    venerdì 31 gennaio 2014 08:56
    Moderatore
  • infine una domanda: ma la macchina con sql server che sistema operativo ha ? 

    il sistema operativo dove è installato Microsoft SQL Server 2008 R2 è Windows7: cioè il mio computer. 


    credo che abbiamo parlato inutilmente in questo thread perchè tutti i principi di sicurezza che ho enunciato riguardano i sistemi server e mi aspettavo che l'istanza di sql server fosse installata su un sistema server (Windows Server 2008, Windows Server 2012, ecc.ecc.) invece tu hai una infrastruttura di rete integralmente basata su sistemi client (XP, Vista, Windows 7). questo tipo di infrastruttura dispone solo in parte dell'architettura di sicurezza di Windows, di solito è destinata all'home computing e per rendere semplici le cose si usano i Workgroup o i Workplace per far comunicare le macchine in rete in maniera semplificata.

    parliamo quindi di infrastrutture diverse per cui non ha senso continuare.

    ciao.


    Edoardo Benussi
    Microsoft MVP - Directory Services
    edo[at]mvps[dot]org

    Ok, mi dispiace: adesso i conti tornano! :-)

    Comunque, a me quello che serve sapere è solo una cosa in modo da sentirmi la coscienza a posto.

    Una volta installato SQL Server 2008 R2 in uno studio dentistico e migrato un mio database di Access, la connessione tra i vari computer a questo punto sarà simile a quella di casa mia con accesso "sa" e password.

    Premesso che non credo ci siano persone (esterne alla rete) interessate a spulciare i dati del database, si correrebbe comunque qualche rischio per via di questo tipo di connessione?

    Vladimiro

    sabato 1 febbraio 2014 10:00
  • ammesso che  la rete dello studio dentistico si trovi nella esatta situazione della tua rete locale (probabilmente si se usi gli stessi sistemi operativi), la risposta alla tua domanda:

    "si correrebbe comunque qualche rischio per via di questo tipo di connessione?"

    la risposta è: SI.


    Edoardo Benussi
    Microsoft MVP - Directory Services
    edo[at]mvps[dot]org

    domenica 2 febbraio 2014 16:14
    Moderatore
  • ammesso che  la rete dello studio dentistico si trovi nella esatta situazione della tua rete locale (probabilmente si se usi gli stessi sistemi operativi), la risposta alla tua domanda:

    "si correrebbe comunque qualche rischio per via di questo tipo di connessione?"

    la risposta è: SI.


    Edoardo Benussi
    Microsoft MVP - Directory Services
    edo[at]mvps[dot]org

    Ciao Edoardo,

    una volta però che riesco a trovare la strada giusta per ovviare a "sa", la connessione acquisisce una sicurezza rispettabile! Giusto?

    Vladimiro

    domenica 2 febbraio 2014 17:14
  • dipende molto dall'architettura della rete dove viene deployata l'applicazione.

    Edoardo Benussi
    Microsoft MVP - Directory Services
    edo[at]mvps[dot]org

    martedì 4 febbraio 2014 09:20
    Moderatore
  • Ciao Edoardo,

    allora il thread lo possiamo chiudere qui.

    Grazie Vladimiro.

    martedì 4 febbraio 2014 17:31