Search

onze sponsors

microsoft_logo.gif


 

computrain_logo.JPG

Forum Login | Register
   Forum

 

Subject: SQL & AD SidHistory
Prev Next
You are not authorized to post a reply.

Author Messages
Arjan FraaijUser is Offline

Posts:110

18-11-2009 10:55:11 Alert 

Hallo,

Momenteel ben ik bezig bij een klant voor de migratie van SQL2000 en SQL 2005 databases naar SQL2008. Dit is een onderdeel van een groter project waarbij ook de huidige filedata en werkplekken worden gemigreerd.

Hierbij wordt overgegaan van domain ABC naar domain XYZ. Bij de migratie van de accounts, filedata en werkplekken wordt gebruik gemaakt van SID history. Tussen domain ABC - XYZ ligt een full 2-way trust.

Niet direct van belang maar om mijn nieuwschierigheid te lessen heb ik de volgende vraag:

Situatie:

Database DB01 staat op een server in het ABC domain. Users zijn met hun ABC\ geauthenticeerd op de database. Op de database zijn rollen gedifineerd waarvan de ABC\ users members zijn.

Nu wordt de gebruiker ABC\JJansen zijn user account en zijn werkplek gemigreerd naar het XYZ domain. Hij logt dus voortaan aan op zijn werkplek met het account YXZ\JJansen.

SID History staat aan dus als hij vanaf zijn nieuwe werkplek een database koppeling maakt naar de DB01 die nog in het ABC domain staat en alleen zijn ABC\JJansen login bevat kan hij de database bereiken via de SidHistory. In profiler security audit zie je XYZ\JJansen als user een verbinding maken en authentiseren. Alle rechten via de rollen (standard en custom) die de ABC\JJansen member van is zijn ook van toepassing voor als wordt ingelogt met XYZ\JJansen....

Nu echter wordt er in de applicatie functionaliteit vrij gegeven op basis van de user roles en een additionele tabel bevoegdheden. Dit wordt gedaan door een query:

select *
from bevoeg, users
where bevoeg.gid = users.gid
  and users.uid = user_id()

En hier gaat het nu mis, de functie user_id() herleid niet met SidHistory. Eigenlijk staat er:

SELECT
 *
from bevoeg, users
where bevoeg.gid = users.gid
  and users.uid = user_id('XYZ\JJansen')

Om dit te laten functioneren moet er op de database ook de login voor XYZ\JJansen worden aangemaakt met lidmaatschap voor dezelfde rollen als ABC\JJansen

Mijn vraag is nu wat zou je als applicatie ontwikkelaar moeten doen om rekening te houden met migraties over verschillende domeinen?
 

Kijk mijn migratie van de databases lost dit uiteindelijk vanzelf op omdat ik het domain account ABC ga vervangen door XYZ nu moet ik echter in deze tussen fase mij ook gaan bemoeien met de werkplek en user account migratie om alles op de database dubbel te authentiseren. Is er voor programmeurs een eenduidige oplossing of tip?

 

Gr,

Arjan

Rob PellicaanUser is Offline

Posts:11

18-11-2009 13:01:37 Alert 
Arjan,

Je zal in ieder geval ervoor moeten zorgen dat de aanroep van USER_ID() vervangen wordt door DATABASE_PRINCIPAL_ID().

BOL (http://msdn.microsoft.com/en-us/library/ms181466.aspx):
This feature will be removed in a future version of Microsoft SQL Server. Avoid using this feature in new development work, and plan to modify applications that currently use this feature. Use DATABASE_PRINCIPAL_ID instead.

Of dit toevallig ook je probleem op lost is een 2e.

Eduard BeijnesUser is Offline

Posts:37

18-11-2009 13:51:29 Alert 
ik zou gebruiker abc\janssen geen directe toegang geven maar via een windows groep abc\groep. de migratie is dat dat abc\groep en xyz\groep (waar xyz janssen in gaat komen) allebei een periode rechten hebben. vervolgens komt een moment dat janssen overgezet wordt en omdat abc\groep en xyz\groep rechten hebben kan hij/zij gewoon verder met werken en heb je ook geen user_id functie probleem. tijdens de migratie van jassen kun je 'm uit abc verwijderen of aan het eind alle abc zaken schonen.


An ape in an suit stays an ape.
Eduard BeijnesUser is Offline

Posts:37

18-11-2009 14:12:53 Alert 

aangezien ik de post niet kan bijwerken: windows groep(en) -> databaserol -> tabellen en andere db objecten is wat ik bedoel.

dus databaserol veranderd niet en abc en xyz groepen hebben toegang via de dbrol.

 


An ape in an suit stays an ape.
Arjan FraaijUser is Offline

Posts:110

18-11-2009 15:17:26 Alert 
@Beide: alvast bedankt voor jullie reacties!

@Rob, goed om rekening mee te houden. DATABASE_PRINCIPAL_ID zoals jezelf al aangeeft lost helaas niet het probleem op, deze retouneerd het zelfde id als user_id()

@Eduard: Je hebt gelijk, dit is ook waar ik in de migratie van SQL2000 / SQL2005 naar SQL 2008 toe werk. Alle Windows based single logins worden vervangen door groep structuren.

Volgens mij is het niet mogelijk om integrated security applicaties te bouwen die geen domain afhankelijkheid hebben of wel? gebruikers zijn altijd lid van een domain of domain\group. Er is dus altijd een overgangs fase. Het gebruik van groups zorgt voor een iets wat betere beheersbaarheid of niet? Je hebt nu maar één group login op de database ipv 100 losse accounts en je hoeft dus alleen de group te vervangen tijdens de migratie of domain verplaatsing van de database.

Wil je domain on afhankelijke applicaties ontwikkelen zit je toch weer vast aan SQL based logins?

Conclusie? Windows based login's en applicaties op basis van Integrated Security is een sterker security level dan SQL based logins en SQL based applicaties, echter is dit laatste flexibeler in de migratie naar een ander domain. (RevLogin)

Gr,
Arjan
Rob PellicaanUser is Offline

Posts:11

18-11-2009 15:49:20 Alert 
Denk niet dat domein migraties dagelijkse kost is of zou moeten zijn. (Laten we hier maar geen discussie starten over waarom ze uberhaupt een domeinmigratie uit willen voeren).

En als je netjes met Domein Groepen werkt, zie ik het probleem ook niet. Stel je hebt nu 10 database rollen met daaraan gekoppeld 50 AD groepen. Om daar 50 nieuwe groepen aan toe te voegen lijkt me slechts een paar minuten werk. Problem solved.

Arjan FraaijUser is Offline

Posts:110

18-11-2009 16:48:38 Alert 
@Rob, inderdaad. Het gaat hier echter wel op 150 DB servers met gemiddels 12 databases per server... die momenteel nog geen groupen structuur gebruiken. Een onderdeel van mijn migratie plan is het opschonnen van de individuele logins door gebruik van domain groups.

Ik vroeg mij alleen af of er voor applicatie ontwikkelaars een methoden is om te werken op basis van SSPI maar toch eenvoudiger migraties uit te kunnen voeren. Sommige organisaties veranderen met de lifecycle van Microsoft 2,5 jaar hun domain structuur. Zeg maar zo iets eenvoudigs om C-Names te gebruiken voor database verwijzingen in applicaties ipv hardcoded server namen.

Voordat ik echter databases kan migreren worden eerst de users en werkplekken gemigreerd en lopen ze dus tegen applicaties issues aan. Voor nu heb ik een SP gemaakt op basis van RevLogin die op iedere server elk uur kijkt of er nog nieuwe ABC users zijn toegevoegd en tot welke rollen zij behoren en daarvoor automatisch de XYZ equivilant voor aanmaakt. Ieder gemigreerde database werkt op basis van groups.

Gr,
Arjan

Gr,
Arjan
Arjan FraaijUser is Offline

Posts:110

18-11-2009 16:53:10 Alert 
PS. Windows heeft nog een additioneel probleem dat als je lid bent van veel groupen je Security Token te lang kan worden (aantal sid's in de token) waardoor dit weer additionele problemen kan veroorzaken. Ik weet het dit is te ondervangen door een goed domain ontwerp maar soms kom je ergens en moet je roeien met wat beschikbaar is....
André KammanUser is Offline
PASS Nederland

Posts:137


19-11-2009 01:03:36 Alert 

Hoi Arjan,

Wat geeft ORIGINAL_LOGIN() terug ?

Groeten,

André

Arjan FraaijUser is Offline

Posts:110

19-11-2009 07:30:53 Alert 
Hallo André,

ORIGINAL_LOGIN() geeft vanaf SQL2005 de login weer waarmee op de database werkelijk is aangemeld. Ik heb even het volgende getest:
Rechten gegeven op een SQL2008 database voor user ABC\JJansen geen rechten voor XYZ\JJansen.
SSMS gestart als XYZ\JJansen en ik kan een verbinding maken met de database (SidHistory) op als ik alleen SQL gebruik dan heb ik bij het testen als XYZ\JJansen ook gewoon alle rechten zoals ABC\JJansen heeft gekregen.

SELECT * FROM fn_my_permissions (NULL, 'DATABASE'); geeft alle rechten weer die ABC\JJansen heeft terwijl ik ben aangemeld als XYZ\JJansen. Dus op SQL niveau lijkt alles gewoon te kloppen en worden de rechten uitgedeeld op basis van de SidHistory. Dit is ook zo op SQL2000.

SQL lijkt SidHistory dus gewoon te snappen maar een aantal functionaliteiten die je als ontwikkelaar gebruikt doen dit niet, zoals de query:
select *
from bevoeg, users
where bevoeg.gid = users.gid
and users.uid = user_id()

De user_id() is eigenlijk gelijk aan user_id('XYZ\JJansen') aangezien deze geen werkelijke user is wordt er niets terug gegeven. Je zou eigenlijk hopen dat via de SidHistory de user id van ABC\JJansen wordt gegeven.

De database is waarschijnlijk ook niet te migreren naar SQL 2008 ben ik door dit stukje wel achter gekomen. Waar bij SQL2000 in de sysusers tabel de GID wordt gevuld met de laatste role UID waar je aan bent toegevoegd is dit niet het geval in SQL2005/2008. De ontwikkelaar van deze applicatie is er kennelijk vanuit gegaan dat iemand maar lid mag zijn op de database van één rol.
In SQL2005/2008 lijkt de users.gid altijd op die van de public role te blijven staan.

Hoewel BOL SQL 2008 zegt:
gid Group ID to which this user belongs. If uid is the same as gid, this entry defines a group. Overflows or returns NULL if the combined number of groups and users exceeds 32,767. For more information, see Querying the SQL Server System Catalog.
Volgens mij functioneert dit dus niet meer zoals in sql 2000 en moet je dus als ontwikkelaar nooit gebruik maken van system related tables voor functionaliteit in de applicaties....

Dus dat is de tip aan de ontwikkelaar en de eind conclusie:
-- Gebruik maken van system tables : NEE
-- Kan je volledig integrated security afhankelijke applicaties maken die als je een domain verandering krijgt geen effect hebben op de applicatie : NEE

Nog even verder gezocht en gevonden: http://sqlservings.blogspot.com/2009/11/what-i-learned-today-gid-in-sysusers.html

@Allen, bedankt voor jullie reacties!




You are not authorized to post a reply.
Forums > Forums > Ontwikkelen > SQL & AD SidHistory



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