Search

onze sponsors

microsoft_logo.gif


 

computrain_logo.JPG

Forum Login | Register
   Forum

 

Subject: t-sql en Active Directory
Prev Next
You are not authorized to post a reply.

Author Messages
Dick van BraakUser is Offline

Posts:3

28-11-2011 22:59:00 Alert 

Ik wil vanuit SQL kunnen editen in de AD (nieuwe gebruikers/wijzigen gebruikers/groepen etc.). Middels een linked-server en openquery kan ik de gegevens uit de AD wel ophalen, maar niet editen.

Wat kan ik hier het beste voor gebruiken? Middels CLR: C# of VB? Of bestaat er een mogelijkheid om vanuit SQL/t-sql powershell te gebruiken? 

Voor mij is dit nieuw. Ik ben benieuwd naar wat gebruikelijk en/of te gebruiken is.  Gaarne jullie reaktie.

Mvg,

Dick

Dick van BraakUser is Offline

Posts:3

30-11-2011 15:07:07 Alert 

Misschien moet ik mijn vraag anders stellen. Welke security-problemen kan ik verwachten als ik CLR open zet in SQL?

Zoals mijn vorige post al min of meer aangeeft, hebben wij alle onze gebruikers in een database staan. Voor meerdere doeleinden wordt dit gebruikt. Mijn idee is dan:  je hebt toch alle gebruikers in SQL staan, waarom gebruik je SQL dan niet als users management systeem? Zeker omdat Microsoft min of meer deze mogelijkheden heeft opengezet middels CLR en C#/VB.

Op het gebied van CLR en security ben ik nog redelijk blanco.

Hugo KornelisUser is Offline

Posts:46

30-11-2011 15:44:21 Alert 
Hoi Dick,

Die anders gestelde vraag kan ik meer mee dan met de eerste. ;)

wat security betreft zijn er twee instellingen voor CLR van belang. De optie "clr enabled", die op de hele service CLR wel of niet toestaat, maar ook de "permission set" die je opgeeft in de CREATE ASSEMBLY opdracht. DIe heeft drie instellingen:

* SAFE: Diverse beperkingen op de code van kracht om je voeten tegen je eigen kogels te beschermen (zie http://msdn.microsoft.com/en-us/library/ms131047.aspx); geen enkele toegang tot bronnen buiten de database.
* EXTERNAL_ACCESS: Zelfde beperkingen als SAFE, maar nu heb je wel toegang tot bronnen buiten SQL Server.
* UNSAFE: Geen enkele beperking. Zelfs het aanroepen van unmanaged code is toegestaan.

De risico's van CLR code zijn grofweg in te delen in twee categorieën:
* Onbedoelde fouten - denk aan bugs in de code die in het ergste geval ertoe zouden kunnen leiden dat het hele SQL Server service proces knarsend en piepend tot stilstand komt. Met SAFE en EXTERNAL_ACCESS zou je hiertegen beschermd moeten zijn omdat alleen managed code kan worden uitgevoerd binnen de context van het SQL Server proces; bij UNSAFE is dit risico aanwezig.
* Bewuste fouten, door kwaadwillenden - dit is van toepassing als de code wordt geschreven door anderen dan de DBA. Hoe kan de DBA controleren of de aangeboden DLL inderdaad doet wat hij zou moeten doen? Misschien heeft de ontwikkelaar er wel stiekum kwaadaardige code in gestopt? Dit risico is niet met de permission set af te vangen (al kan de aanvaller uiteraard wel meer bij EXTERNAL_ACCESS dan bij SAFE, en nóg meer bij UNSAFE).

Hou er verder rekening mij dat alle externe toegang gebeurt in de security context van het windows user dat is opgegeven bij de eigenschappen van de SQL Server service. Best practise is om daar een domain user account voor te gebruiken met minimale privileges, maar in de praktijk wordt daar helaas nog wel eens simpelweg BUILTIN\Administrators of het Local System Account gebruikt. Dan wordt het risico van EXTERNAL_ACCESS en UNSAFE assemblies uiteraard meteen evenredig groter.


Overigens vraag ik me naar aanleiding van je originele vraag wel af of het niet logischer is om AD als bron te gebruiken en desgewenst een kopie te trekken naar SQL Server (via openquery o.i.d.). Ten eerste denk ik dat een netwerkadministrator liever via AD een user toevoegt dan via SQL Server; ten tweede is het mogelijk dat mensen toegang tot het domein krijgen die geen toegang tot SQL Server nodig hebben.

Met vriendelijke groeten,

Hugo Kornelis (SQL Server MVP)
Dick van BraakUser is Offline

Posts:3

01-12-2011 08:51:43 Alert 

Ha Hugo,

Bedankt voor dit duidelijke antwoord. Als ik het goed begrijp en ik schrijf die dll zelf in C#, dan vervalt een groot deel van de security risico? Volgens mij hoeft dat niet zo lastig te zijn.

Wat betreft mijn originele vraag is het misschien aardig om daar wat meer achtergrond info over te geven. Wij zijn namelijk een VO-school en op school is gebruikersbeheer wat dynamischer als in het bedrijfsleven. Wij hebben zo'n 8000 gebrluikers in de AD, waaronder leerlingen, ouders en personeel. Per schooljaar wisselt dit enorm. Immers, er gaan zo'n 1500 leerlingen van school en er komen er zo'n 1500 bij. Daardoor wijzigen ook de ouders. Geen kind op school dan ook geen account. Ook lopende het jaar heb je wijzigingen, als ik alleen al denk aan wijziging van klas (dus in een andere ad-groep). De wens komt dus juist bij ondeze netwerkadministrators vandaan. Het automatiseren van dit proces scheelt veel tijd en dus ook geld.

Onze leerlingadministratie vult in het leerlingadministratiesysteem de leerling/ouder in (SAAS-oplossing). Middels webservices worden de gegevens via SSIS ingelezen in SQL. Op dit moment hebben wij een 'cockpit' op de SQL-database staan waarin diverse parameters ingesteld kunnen worden m.b.t. AD, maar van waaruit ook wachtwoordbrieven zijn te genereren etc. Middels een tool wordt buiten schooltijd de gegevens tussen deze SQL-database en de AD onze AD bijgehouden worden.
Deze SQL-db wordt breder gebruik, waaronder brieven naar ouders en invullen van ouderavonden etc.

Het doel van mijn originele vraag is dus SQL die gebruikers te laten aanmaken/disablen etc (uiteraard in de AD, authenticatie blijft AD doen etc.) i.p. v. de (dure) tool die wij nu gebruiken. De gebruikers worden dus geen SQL-account o.i.d. en krijgen ook geen rechten binnen SQL. Omdat we toch al zoveel doen binnen SQL lijkt mij dit een heel voor de hand liggende methode. Gaan we powershell gebruiken - wat misschien logischer is - dan krijg je wat meer verdeeldheid in programmatuur. Het één doet d it en het ander doet dat, waarbij je ook je (ik) kennis moet uitbreiden.

Middels openquery haal ik al de gebruikers/groepen etc. binnen. Echter,  met openequery en de AD als linked server kan je nog niet editen. Wel kan je op die manier met SQL de verschillen tussen SQL en de AD in kaart brengen en hoef je dus niet alle gebruikers langs in je script om te checken op verschillen. Met C# kan je de AD wel editen en door CLR/C# kan je dat dan zelf vanuit een sp. M.i. heel krachtig. Echter, ik wil natuurlijk niet de security in gevaar brengen...

Mocht bovenstaande een dwaas idee zijn en kan het veel gemakkelijker, dan hoor ik het graag. Daarvoor heb ik deze vraag gesteld op dit forum.

Groeten,

Dick

 

Hugo KornelisUser is Offline

Posts:46

01-12-2011 09:11:24 Alert 
Hoi Dick,

>>Als ik het goed begrijp en ik schrijf die dll zelf in C#, dan vervalt een groot deel van de security risico?<<
Dat hangt ervan af hoe betrouwbaar jij bent. ;)
(Ik schrijf dat met een knipoog, maar het is wel deels serieus - het is de vraag waar elke beheerder wakker van zou moeten liggenn: "wat als mijn systeem-/database-/etc-beheerder niet te vertrouwen is?")

En als je UNSAFE gebruikt, loop je in principe het risico het hele SQL Server proces op te blazen.


>>Mocht bovenstaande een dwaas idee zijn en kan het veel gemakkelijker, dan hoor ik het graag.<<
Ik weet te weinig van AD om hier antwoord op te kunnen geven. Maar ik zal eens navragen bij anderen die er misschien meer verstand van hebben.

Met vriendelijke groeten,

Hugo Kornelis (SQL Server MVP)
Guido GroenewegUser is Offline

Posts:12

13-02-2012 09:18:10 Alert 
Het is niet verstandig om vanuit SQL de Active Directory rechtstreeks te bewerken. Deze gedachte kan je dus het beste laten varen.

Een betere oplossing is om bijvoorbeeld Microsoft Identity Manager te gebruiken, die uit SQL kan lezen en naar AD kan schrijven.
Op deze manier blijft de distributie van accountgegevens centraal en daarmee beheersbaar.
You are not authorized to post a reply.
Forums > Forums > Ontwikkelen > t-sql en Active Directory



ActiveForums 3.6
  
Copyright (c) 2012 PASS Nederland   Privacy Statement  Terms Of Use