Det kan for eksempel være at noen har lyst til å lagre personnummeret til alle sine brukere i Active Directory, men samtidig ønsker at  denne informasjonen kun skal kunne leses av utvalgte personer og ikke av ”vanlige brukere”. I praksis vil dette si å nekte lesetilgang til en attributt på et objekt i Active Directory ved hjelp av Access Control Lists (ACL).

Når det gjelder Windows 2000 og Windows Server 2003 RTM så er dessverre dette ikke så enkelt å få til. Standardrettighetene i Active Directory gir alle autentiserte brukere (det vil si gruppen Authenticated Users) lesetilgang til alle attributter på alle objekter. Å endre dette vil si å endre rettighetene på alle de berørte objektene i Active Directory. Dette er problematisk da interne prosesser i Active Directory hvert døgn sjekker at alle objekter og attributter har standardrettigheter satt, og setter dem tilbake hvis avvik oppdages.

I Windows Server 2003 Service Pack 1 har vi imdlertid fått muligheten til å merke attributter i Active Directory som konfidensielle og kun la utvalgte brukere lese dem. Denne artikkelen forklarer hvordan du setter en attributt konfidensiell og hvordan du gir en bruker eller gruppe tilgang til å lese den.

Atributter og objekter

For å kunne forstå hvordan dette fungerer må vi ha litt bakgrunnsinformasjon om Active Directory. Hvert Active Directory har et schema. Schemaet inneholder regler for hvilke objekter som kan opprettes i dette Active Directory (AD) og hvilke attributter disse objektene skal eller kan ha.

De fleste kataloger er stort sett like, men mange har utvidet sitt AD med nye attributter og nye objekter. En utvidelse av schema skjer ofte når Microsoft slipper nye produkter eller service packs. Exchange, Windows Server R2, Windows Vista og SMS 2003 er eksempler på produkter som kan oppdatere ditt AD-schema.

I schema lagres to ting; attributt-definisjoner og objekt-definisjoner. En attributt har et navn og regler for hvordan den kan lagre informasjon, om det er en tekst verdi eller en tallverdi, om den skal indekseres i den globale katalogen og om den er konfidensiell. Attributten sn beskriver feks hvordan et etternavn skal lagres på en bruker.

Objekter er kort og godt samlinger av attributter og er en oppskrift på de ulike objektene som kan lages i akkurat dette AD. Et user-objekt definerer hvilke attributter som tilsammen utgjør en bruker i AD. Et objekt inneholder regler for hvilke attributter som må ha verdier på objektet, om objektet arver egenskaper fra andre objekter osv. Én attributt kan altså inngå i flere objekter.

Attributten description er for eksempel med i neste alle objektdefinisjoner i Active Directory. Den formelle definisjonen av et objekt heter object class definition og derfor kalles også noen ganger objekter for klasser. Attributter er også ofte omtalt som properties.


Noen av attributtene i Active Directory.

I denne artikkelen er målet å skjule informasjon om objekter fra brukere. Det vil si at vi må endre reglene for hvilke attributter som er lesbare. Dette kontrolleres i schema på hver attributt med en attributt som kalles searchFlags.

Det som kan være litt forvirrende her er at attributtene i schema selv er objekter i AD. Dvs at en attributt er et objekt som beskriver en attributt som igjen kan være del av en objektdefinisjon. Dette er best synlig i ADSI Edit, hvor vi kan se alle attributtene som et attributt objekt har.


Description attributt objektet i schema.

Her ser vi altså noen av attributtene som tilsammen definerer description attributeSchema objektet eller desctiption attributten. Som vi ser er searchFlags attributten fremhevet siden det er denne vi nå skal endre for de attributtene vi ønsker å skjule.

READ_PROPERTY og CONTROL_ACCESS

Hvis en bruker har READ_PROPERTY (RA) tilgang til en attributt så kan han lese attributtens verdi, hvis han har WRITE_PROPERTY (WR), kan han skrive til attributten. Hvis attributten er konfidensiell må også brukeren ha CONTROL_ACCESS for å kunne lese attributtens verdi.

Etter at Windows Server 2003 Service Pack 1 er installert, utfører Active Directory en ekstra sjekk for konfidensielle attributter når en bruker ber om lesetilgang til en attributt på et objekt. Først sjekkes det om brukeren har READ_PROPERTY tilgang på attibutten og deretter om brukeren har CONTROL_ACCESS på samme attributt. Det som tidligere (Windows 2000 og Windows Server 2003 RTM) bare var en sjekk etter READ_PROPERTY tilgang følges nå av en CONTROL_ACCESS sjekk i SP1.

Active Directory sjekker om en bruker har READ_PROPERTY tilgang (og i SP1 CONTROLL_ACCESS tilgang) i to tilfeller:

1. Når det evalueres om et objekt matcher er søkefilter.
   Hvis du søker etter objekter med description attributten satt til ”Hemmelig” og description attributten er satt til konfidensiell, samtidig som du ikke har CONTROL_ACCESS til description attributten så vil ikke søket ditt returnere noen treff.
2. Når attributter skal vises fra et objekt som har matchet et søkefilter.
   Hvis du søker etter alle brukerobjekter og ber om å få se description attributten, men denne er satt konfisensiell og du ikke har CONTROL_ACCESS tilgang, vil du få se alle andre attributter på objektene, men ikke description.

Hvordan sette en attributt til konfidensiell

Både attributter som allerede er definert i schema og attributter som du selv legge inn kan settes til konfidensielle. Det eneste unntaket fra denne regelen er at du ikke kan sette base schema attributter som konfisensielle. Base scheme attributter kjennetegnes ved at de har sin systemFlags attributt satt til 0x10 (base schema).

Attributter som er del av base schema kalles også for Category 1 attributter, mens attributter som ikke er det kalles Category 2. Mange av attributtene i AD er en del av base schema, i Window Server 2003 R2 er det ca 880 i denne kategorien og ingen av dem kan altså settes som konfidensielle.

Som tidligere nevt er det searchFlags attributten på attributt objektet til den attributten du ønsker å sette til konfidensiell som må endres. Hvis jeg har lyst til å sette employeeNumber attributten til konfidensiell så er det altså searchFlags på employeeNumber jeg må endre. searchFlags kontrollere flere aspekter på attributter som vist i tabellen nedenfor:

Som vi ser er det bit 7 i searchFlags som kontrollere om en attributt er konfidensiell eller ikke. Ved å legge til eller trekke i fra 128 på denne attributten slår du henholdsvis på og av om attributten skal være konfidensiell. Dette kan gjøres både i ADSI Edit, LDP, LDIFDE eller script.

For å demonstrere dette har jeg laget et lite testmiljø. Her har jeg et AD med to nye brukere:



Tanken er her at Onkel Skrue ønsker å lagre koden til pengebingen i carLicense attributten på sitt brukerobjekt, men ønsker naturlig nok ikke at B-Gjengen skal kunne lese denne. Vi starter med å sette serachFlags attributten til carLicense attributten til 128, til dette bruker vi ADSI Edit. Denne finner du ved å gå inn på Windows Server 2003 Support Tools fra Server-CDen under /support/tools/supptools.msi eller ved å laste ned ADSI Edit her.



ADSI Edit: searchFlags for carLicense attributten er foreløpig 0.



ADSI Edit: Vi endrer den til 128, som er det samme som å sette bit 7 til 1, og slår dermed på konfidensialitet på carLicense attributten. Nå kan denne attributten kun leses av medlemmer av Administrators-gruppen, siden det kun er denne gruppen som har CONTROL_ACCESS til alle attributter i Active Directory. Ikke engang eieren kan lese attributtens verdi.

Neste skritt er å sette verdien på carLicense attributten til Onkel Skrue til 1234. Det gjøres også med ADSI Edit.



ADSI Edit: Vi setter Onkel Skrues carLicense attributt til 1234 for å ha en verdi å teste mot. Jeg har laget et script for å forsøke å lese attributten.

Set objUser = GetObject("LDAP://cn=Scrooge McDuck,ou=Duckburg,dc=adatum,dc=com")
objUser.GetInfo
strcarLicense = objUser.Get("carLicense")
WScript.Echo strcarLicense

Vi kjører det først som Administrator:



Da får vi, helt korrekt, lov til å lese attributten.

Deretter forsøker vi med Onkel Skrues konto og med B-Gjengens konto:



Ingen av disse kan lese attributten. Merk at konfidensialitet og CONTROL_ACCESS ikke berører skrive tilgang (WP) til en attributt. Hvis man har skrivetilgang til en konfidensiell attributt kan man skrive til den uavhengig om man har CONTROL_ACCESS eller ikke.

MERK: Når du setter en attributt til konfidensiell så er det en global handling som gjerlder for alle objekter som har denne attributten i hele Active Directory-skogen. Det er ikke mulig å ha en attributt konfidensiell bare på noen brukere eller i ett domene. Siden det er schema som endres gjelder det for hele skogen. (Det er teknisk mulig å få til en løsning hvor en attributt er konfidensiell bare for noen brukere, men det innebærer å gi CONTROLL_ACCESS tilgang til feks Authenticated Users på alle objekter i skogen unntatt noen som skal være konfidensielle. Uansett så er endringen av searchFlags for hele skogen.)

Gi brukere eller grupper tilgang til konfidensielle attributter

Onkel Skrue ønsker naturlig nok å kunne lese og skrive til sin carLicense attributt slik at han kan hente og oppdater koden sin. Derfor må han få CONTROL_ACCESS på carLicense attributten. Det er flere måter å gjøre dette på.

1. Hvis vi gir Onkel Skrue følgende rettigheter på sitt eget brukerobjekt så får han CONTROL_ACCESS:
   - All Extended Rights
   - Allowed to Authenticate
   - Change Password
   - Receive As
   - Reset Password
   - Send As
2. Vi kan gi Skrue CONTROL_ACCESS til alle attributtene til sitt eget objekt.
3. VI kan gi Skrue CONTROL_ACCESS til utvalgte attributter på sitt eget objekt.

Samtlige alternativer kan utføres enten direkte på Skrues objekt eller gjennom arving. Ved arving setter vi rettighetene på en OU eller container over Skrues objekt og lar dem arves nedover i hierarkiet.

For alternativ 1 kan dette utføres med Active Directory Users and Computers eller ADSI Edit. Alternativ 2 og 3 krever derimot spesielle verktøy. Vi må enten bruke DSACLS.EXE fra Windows Server 2003 Resource Kit eller LDP.EXE fra Active Directory Application Mode (ADAM) for Windows Server 2003. MERK: Det er kun den nevnte versjonen av LDP som kan editere ACLs.

DSACLS.EXE

For å fortsette med vårt eksempel skal vi først gi Skrue generell CONTROLL_ACCESS til sitt eget brukerobjekt. Vi benytter DSACLS.EXE med følgende kommando:

dsacls "CN=Scrooge McDuck,OU=Duckburg,DC=adatum,DC=com" /G adatum\scrooge:CA

Her gir vi brukeren ADATUM\Scrooge CONTROL_ACCESS (CA) rettighet til CN=Scrooge McDuck,OU=Duckburg,DC=adatum,DC=com objektet. DSACLS kan også benyttes til å sette rettigheter på Ouer som skal arves av kun bestemte objekter og attributter.

LDP

For å ha enda større kontroll skal vi nå gi Skrue CONTROL_ACCESS kun på carLicense attributten. Dette kan være nyttig i et scenario hvor vi ønsker at forskjellige grupper eller brukere skal kunne lese noen konfidensielle attributter, men ikke alle. Denne gangen skal vi benytter LDP.

Første skritt er å koble seg til en DC og binde seg til katalogen. Deretter må vi velge det objektet vi ønsker å endre rettighetene for:



LDP: Skrues objekt i LDP.

Vi høyreklikker, velger Advanced og deretter Security Descriptor og trykker OK. Følgende bilde kommer opp:



LDP: Skrues security descriptor med alle ACEs.

Vi trykker Add ACE og velger hvem som skal få tilgang til Skrues objekt. Her kan naturligivs både brukere og grupper velges:



LDP: Ny ACE i Skrues DACL.

Vi gir brukeren adatum\scrooge CONTROL_ACCESS tilgang, men denne gangen kun på carLicense attributten. Så trykker vi OK og deretter Update. Skrue har nå tilgang til å lese sin carLicense attributt, selv om den er merket som konfidensiell i Active Directory.

Kompatibilitet

Det er kun Windows Server 2003 SP1 som støtte konfidensielle attributter. Hvis du har en skog (du har en skog, selv om du bare har ett domene med én DC) med enten Windows 2000 eller Windows Server 2003 RTM domenekontrollere så er ikke informasjonen din i Active Directory fullstendig beskyttet. Hvis en bruker kobler seg til en DC med lavere versjon en W2K3 SP1 så vil den ikke kjenne igjen konfidensialitetsflagget og ikke kunne håndheve det.

Brukere som kobler seg til disse DCene kan derfor se informasjon som ellers skulle vært nektet dem.

Mer informasjon

1. How Security Descriptors and Access Control Lists Work
2. How to mark an attribute as confidential in Windows Server 2003 Service Pack 1
   
3. DSACLS.EXE-syntaks
   
4. How to use DSACLS.EXE

Avslutning