none
Creazione utenti per sql server RRS feed

  • Domanda

  • Buongiorno,

     sono nuovo del forum. Avrei un problema da risolvere con SQL server  e con  una applicazione in visual c# che accede ad un database sql nella directory DATA del server.

    Ho sviluppato la mia applicazione utilizzando la stringa di connessione al database  che utlilizza i permessi di windows per accederre al Database:

    "Server=localhost;Data Source=PC-MAX;Database=Test;Integrated Security=SSPI"

     

    ;

     senza specificare user e pass per accedere, poichè sono amministartore del pc dove ho fatto lo sviluppo della applicazione. Adesso mi sorge il problema di fare accedere al database anche altri utenti a cui fornisco l'applicazione ma che non sono amministartori del pc. Volevo chiedere se esiste la possibilità di creare un utenza utilizzando i ruoli in SQL server managament studio che abbia questi permessi/limitazioni:

    1)può accedere solo al mio database

    2)non deve accedere SQL server managament studio

     

    Ho già provato a creare un nuovo ruolo con username e password ma il problema è che questo ruolo può accedere anche a SSMS e quindi vedere eventualmente anche altri database.

    Volevo infine chiedere se è possibile creare uno script da lanciare da cmd del dos che mi possa creare un utente con le caratteristiche di cui prima in modo da inserirlo nel pacchetto di installazione della mia applicazione, e che lanciandolo durante l'installazione mi possa collegare il mio database sotto DATA al server SQL  e creare un utente.

     

    grazie mille per l'aiuto

    sabato 12 novembre 2011 13:02

Tutte le risposte

  • salve,

    <IMVHO>

    e' possibile, in un certo senso, gestire parte del tuo problema utilizzano connessioni con autenticazione standard SQL Server e non connessioni con autenticazione integrata, anche se, laddove possibile, sarebbe meglio utilizzare l'autenticazione integrata... dovresti quindi, tu ovvero il "responsabile amministrativo" del server di destinazione, utilizzare SSMS per generare le autorizzazioni di autenticazione e di utilizzo del/i database interessante/i per gli specifici ruoli WinNT del dominio in esame come anche per i singoli account NT (anche se una granularità inferiore, quindi a livello di ruolo WinNT sarebbe preferibile per non "impazzire" a livello di singolo accont)... tale attivita' puo' ovviamente essere gestita anche a livello di applicativo e non e' cosi' complicato, anche se non direttamente collegato all'applicativo stesso ma ovviamente relativo alla connettivita' all'istanza...

    la parte "successiva" del problema e' invece piu' complicata, nel senso che, di base, SQL Server non limita ad un account autorizzato l'accesso con un singolo specifico strumento, quindi SSMS mi resta di base utilizzabile se io fossi stato autorizzato alla connessione... puoi pero' intervenire gestendo appositi logon trigger verificando il nome del programma in connessione ottenuto in relazione con la DMV sys.dm_exec_session sullo spid corrente.. ovviamente nulla vieta al chiamante di modificare a livello di stringa di connessione l'imperativo di nome dell'applicazione, visto che questa e' una proprieta' dinamica ad esempio sullo stack OLE DB come anche su SQL Native Client... quindi potrei tecnicamente bypassare tale limitazione fornendo "credenziali di applicativo falsificate"... resta poi in dubbio circa la bonta' della limitazione stessa, in quanto potrei fisicamente essere un utente limitato (e quindi da te circoscritto all'utilizzo del solo applicativo gestionale) che pero' il sysadmin locale autorizza all'utilizzo di SSMS o SqlCMD o quant'altro...

    diversamente, puoi utilizzare strumenti quali gli application roles dove una diversa gestione della sicurezza ti consente il raggiungimento del secondo obiettivo, a discapito pero' di implicazioni di "liberta'" di connettivita' che quindi ad esempio possono precludere l'utilizzo di Reporting Service o anche Excel per attivita' di analisi BI... similarmente puoi personalizzare ulteriormente il paradigma utilizzando una specie di application role che invece e' a tutti gli effetti un account SQL Server (quindi scriptabile e distribuibile a livello di installazione) "hard coded" a livello applicativo, dove tutti gli utenti dell'applicativo utilizzeranno tale account che (invisibile all'utente) fungera' da "barriera di accesso", ma anche in questo caso dovrai implementarti a livello applicativo una strumentazione di regolamento di accesso alle varie funzionalita' dell'applicativo stesso, quindi giocoforza dovrai ripetere le funzionalita' native di SQL Server in un qualche modo per far si che, ad esempio, "tutti i membri del magazzino non possano accedere alle funzionalita' relative all'are finanza dell'applicativo", cosa che avresti piu' facilmente gestito a livelli (diciamo) SSMS autorizzando i vari ruoli di database che avrai previsto all'esecuzione delle apposito stored procedures di interfacciamento DML con i dati stessi...

    relativamente alla parte finale, si, una volta decisa la "strada" che vorrai percorrere, e' possibile generare gli appositi script, anche se personalmente ritengo che l'attach di un database non sia un'operazione corretta... come ben sai, ogni database creato eredita le proprie impostazioni dal database model, uno dei database di sistema... se tu invece attacchi un database creato sul tuo server su una macchina esterna, non ci sara' nessun "rapporto di affinita'" in questo senso con le impostazioni eventualmente decise dal sysadmin locale (laddove presente)... non saranno quindi presenti nel db eventuali oggetti che il sysadmin abbia piazzato in model per averli disponibili in ogni nuovo database, e soprattutto non saranno rispettate le impostazioni generali stesse, siano esse legate al dimensionamento come anche alla collation utilizzata, con possibili problematiche nella risoluzione di operazioni di comparazione nel caso le collation di sistema e quella del tuo db attaccato non siano uguali (anche questo va valutato e testato nel momento dello sviluppo).... inoltre, non necessariamente il db dovrebbe essere generato nella directory da te indicata (...\Data\) in quanto magari e possibilmente un'apposito set di dischi in raid conterra' tutti i database utente... personalmente preferisco sempre distribuire gli script di generazione dei db, oggetti dei db, e pre-popolamento iniziale, che vengono eseguiti da un apposito tool che distribuiamo unitamente all'applicativo... questo si occupa sia dell'installazione (tramite esecuzione degli script) del database che, in fase successiva che sicuramente avra' luogo (prima o poi), dell'aggiornamente del db stesso, eseguendo allora gli script di allineamento della struttura stessa alla struttura rinnovata del db...

    </IMVHO>

    saluti


    http://www.asql.biz - DbaMgr2k - DbaMgr and further SQL Tools http://www.hotelsole.com/
    domenica 13 novembre 2011 00:57
    Moderatore
  • ciao, grazie per la risposta.

    purtroppo non sono io l'amministartore del server dove l'applicativo dovrà essere installato. In ogni caso ho provato  a fare delle prove sul server SQL che ho in locale sul mio pc, ho lasciato, come mi indichi tu, l'autenticazione integrata però ho dovuto, per gli utenti che non sono amministratori del pc(quindi l gruppo Users) associare l'account di accesso su SSMS BUILTN\Users al mio database ed abilitando, per questo account di accesso, il ruolo sysadmin(oltre a quello publi che era già presente di default)

    Mi chiedo, allora a questo punto, se per poter accedere al database per il gruppo Users è necessario associare per forza il ruolo sysadmin oppure posso giocare sugli altri ruoli(bulkadmin,dbcreator,diskadmin, ecc...) perchè da quello che ho capito il ruolo sysadmin è quello  che ha privilegi maggiori.

    Per quanto riguarda gli script, hai perfettamente ragione forse è meglio creare il database a partire da script, infatti mi sono generato in automatico lo script del databae che mi crea il DB , le tabelle e le stored procedure che avevo fatto. Poi con il comando

    sqlcmd -S . -i test.sql

    faccio tutto. Devo trovare adesso il modo di popolare il db con i valori predefiniti, vedo se riesco a farlo direttamente dallo script che mi creo in automatico da SSMS, esiste un modo?

     

    grazie mille per l'aiuto

    lunedì 14 novembre 2011 12:32
  • salve,

    purtroppo non sono io l'amministartore del server dove l'applicativo dovrà essere installato. In ogni caso ho provato  a fare delle prove sul server SQL che ho in locale sul mio pc, ho lasciato, come mi indichi tu, l'autenticazione integrata però ho dovuto, per gli utenti che non sono amministratori del pc(quindi l gruppo Users) associare l'account di accesso su SSMS BUILTN\Users al mio database ed abilitando, per questo account di accesso, il ruolo sysadmin(oltre a quello publi che era già presente di default)

    Mi chiedo, allora a questo punto, se per poter accedere al database per il gruppo Users è necessario associare per forza il ruolo sysadmin oppure posso giocare sugli altri ruoli(bulkadmin,dbcreator,diskadmin, ecc...) perchè da quello che ho capito il ruolo sysadmin è quello  che ha privilegi maggiori.

    no, non e' necessario che gli utenti interattivi tradizionali di database o di dominio siano giocoforza amministratori, anzi non e' pratica assolutamente consigliabile... tecnicamente possono (e dovrebbero) non appartenere a nessun ruolo a livello di server (server roles) ma solo ai ruoli a livello di database che vorrai eventualmente gestire.. personalmente non utilizzo mai i ruoli di database predefiniti, ma ne gestisco tanti quanti sono in effetti i ruoli applicativi... che so, "Area Finanza" (1 ruolo di db), "Magazzino" (altro ruolo di db), "Management" (altro ancora) e cosi' via... man mano che gestirai gli utenti, questi verrano a far parte del ruolo di database specifico/necessario, e quindi le autorizzazioni di accesso/utilizzo degli oggetti del database [stored procedures, stored procedures, stored procedures, stored procedures, viste, stored procedures, :) .... ] vengono amministrati a livello di ruolo e non di singolo database user... la generazione dei ruoli e' scriptabile cosi' che puoi distribuire i relativi script unitamente agli script di generazione della base dati, poi ti bastera' amministrare ovviamente le assegnazioni ai ruoli dei singoli accont/utenti db che con l'applicazione andrai a gestire...

    Per quanto riguarda gli script, hai perfettamente ragione forse è meglio creare il database a partire da script, infatti mi sono generato in automatico lo script del databae che mi crea il DB , le tabelle e le stored procedure che avevo fatto. Poi con il comando

    sqlcmd -S . -i test.sql

    faccio tutto. Devo trovare adesso il modo di popolare il db con i valori predefiniti, vedo se riesco a farlo direttamente dallo script che mi creo in automatico da SSMS, esiste un modo?


     

    personalmente mi genero gli script di pre-popolamento delle basi dati con il mio amInsert, un piccolo tool che e' in grado di genera comandi INSERT INTO... tale strumento e' liberamente utilizzabile e scaricabile dal mio sito in calce... una volta generati tali script, nel mio caso questi vengono messi a corredo dell'installazione ed utilizzati in seguito agli script DDL di generazione degli oggetti... come gia' precedentemente dicevo, distribuiamo un piccolo tool che diamo a corredo degli applicaltivi che si occupa sia dell'installazione (tramite esecuzione degli script) del database che, in fase successiva che sicuramente avra' luogo (prima o poi), dell'aggiornamente del db stesso, eseguendo allora gli script di allineamento della struttura stessa alla struttura rinnovata del db... in questo modo non necessitiamo di utilizzare SqlCMD che solitamente non si trova installato nei client...

    saluti


    http://www.asql.biz - DbaMgr2k - DbaMgr and further SQL Tools http://www.hotelsole.com/
    lunedì 14 novembre 2011 15:24
    Moderatore
  • ciao,

    sto iniziando a capirci qualcosa, mi hai aperto un mondo a me prima sconosciuto ma che ancora non riesco ad incastrare perfettamente a livello sistemistico, nel senso che in un contesto di un programma applicativo non saprei come inquadrare il tutto e da dove iniziare. Volevo chiederti, quindi, se conosci qualche libro dove poter reperire queste informazioni , mi interessa soprattutto la parta di  programmazione in c# quindi l'utilizzo dei ruoli applicativi e di database nel contesto della programmazione.

    grazie mille

    max

    martedì 15 novembre 2011 18:35