Gå til innhold

[Løst] Tillgang til filer på skjult share


Anbefalte innlegg

Folkens. Vi har en liten utfordring. Vårt program er et dokument styrings program som vi ønsker å tilby en bedre sikring på. Dagens versjon bruker Filepath til dokumentet lagret på en SQL tabell. Dette fungerer veldig bra, men det som er greia er at området for dokumenter er tilgjengelig for alle brukere. Vi ønsker derfor å gjemme dette vekk slik at tilgangen blir borte. Vi har tenkt på masse forskjellige scenario og kom frem til ad AD var veien til frelse. Derfor har jeg gjort som følger:

 

Jeg opprettet en brukergruppe i AD som jeg meldte alle aktuelle brukere inn i. Så fjernet jeg alle brukere fra Security listen slik at kun Administratorer og SYSTEM står igjen.

 

Så lagde jeg en ny gruppe som jeg meldte alle aktuelle brukere inn i.

 

Så la jeg til denne gruppe på FOLDERs Security tab med spesial rettigheter.

 

Jeg la til alle rettigheter og tok DENY på "List folder". Dette resulterte i TO oppføringer i "Permission Entries" der den ene gir DENY på "LIst folder" og den andre gir Full Access på alt. Siden AD bygger på at dårligste rettighet overstyrer resten så antok jeg at dette ville holde. Og Jess, det gjorde det. Jeg kan nå ikke lenger åpne mappen fra en arbeidsstasjon. Men skriver jeg direkte filnavn så funker det. Altså, hvis jeg er på en arbeidsstasjon og skriver \\FileServer\ShareName\Documents\SomeFile.txt så funker dette. Filen dukker opp i Notepad som forventet - Documents er mappen som rettighetene er satt på.

 

Vel og bra helt til jeg la over et bilde (fil.bmp) i mappen. Da skjedde noe rart, nemlig at Windows Photo Viewer står og venter og venter og venter... i evighet. Ser nemlig ut til at dette programmet ikke greier å åpne bildet i denne mappen. Med litt forskning og leting i Registry så har jeg funnet ut at Photoviewer ikke er et program men en DLL og at RunDll32.exe er det som blir kalt opp med photoview.dll og filpath som parameter. Jeg gjetter derfor på at dette programmet derfor kjører som lokal system bruker og dermed ikke har rettigheter til den angitte folderen.

 

Spørsmålet er derfor: Er det mulig i AD å bestemme at Local System User skal kunne få tilgang til resurser?

 

Finnes det et alternativ til det jeg prøver å få til så si gjerne noe om det også ;-)

Lenke til kommentar
Videoannonse
Annonse
Jeg la til alle rettigheter og tok DENY på "List folder". Dette resulterte i TO oppføringer i "Permission Entries" der den ene gir DENY på "LIst folder" og den andre gir Full Access på alt. Siden AD bygger på at dårligste rettighet overstyrer resten så antok jeg at dette ville holde. Og Jess, det gjorde det. Jeg kan nå ikke lenger åpne mappen fra en arbeidsstasjon. Men skriver jeg direkte filnavn så funker det. Altså, hvis jeg er på en arbeidsstasjon og skriver \\FileServer\ShareName\Documents\SomeFile.txt så funker dette. Filen dukker opp i Notepad som forventet - Documents er mappen som rettighetene er satt på.

 

En liten kommentar: Det anbefales ikke at man bruker negative rettigheter ("deny") med mindre det er absolutt umulig å oppnå det man ønsker uten dette. Det er i utgangspunktet ingen forskjell på det å ikke ha noen rettigheter til et objekt overhodet og det å bli nektet en rettighet med "deny", annet enn det du påpeker: At en "deny"-oppføring overstyrer andre rettighetstildelinger.

 

Hvis en bruker mangler rettigheter til en (utdelt) mappe, har vedkommende ikke tilgang. Det betyr ikke at brukeren ikke kan aksessere en fil i den aktuelle mappen, forutsatt at brukeren har de nødvendige rettigheter på det aktuelle filobjektet.

 

Dette kan virke litt ulogisk, men det skyldes at "traverse checking", altså en kontroll av at man har rettigheter på alle containerobjekter man må gå "gjennom" for å nå et objekt, er en egen innstilling i operativsystemet. Denne er som standard deaktivert ved at sikkerhetsinnstillingen "Bypass Traverse Checking" er satt til "Enabled".

 

Vel og bra helt til jeg la over et bilde (fil.bmp) i mappen. Da skjedde noe rart, nemlig at Windows Photo Viewer står og venter og venter og venter... i evighet. Ser nemlig ut til at dette programmet ikke greier å åpne bildet i denne mappen. Med litt forskning og leting i Registry så har jeg funnet ut at Photoviewer ikke er et program men en DLL og at RunDll32.exe er det som blir kalt opp med photoview.dll og filpath som parameter. Jeg gjetter derfor på at dette programmet derfor kjører som lokal system bruker og dermed ikke har rettigheter til den angitte folderen.

 

Det er nok ikke korrekt. Alle prosesser som startes av en bruker, kjøres i samme kontekst som den aktuelle brukersesjonen. Dette er helt uavhengig av om det er en .exe-fil, en script som kjøres via cmd eller PowerShell, en dll-funksjon som kjøres via rundll32 eller noe helt annet. Hvis du laster ned og kjører Process Explorer vil du kunne se dette selv.

 

(Det eneste unntaket er scenarier der en prosess som allerede kjører i bakgrunnen som en annen bruker, tillater at brukersesjonen instruerer den til å gjøre noe. Det er på den måten man f.eks. kan tillate at en ikke-priviligert bruker kan godkjenne installasjon av Windows-oppdateringer; "wuauserv" kjører allerede som LocalSystem.)

 

Problemet du opplever med Windows Photo Viewer er sannsynligvis relatert til noe helt annet, f.eks. at programmet prøver å aksessere eller til og med endre andre filer i den aktuelle mappen ifm. visningen. Det kan f.eks. tenkes at den vil opprette en midlertidig fil, eller leter etter fornåndsvisningsfiler, desktop.ini eller lignende. Et verktøy som Process Monitor vil kunne fortelle deg nøyaktig hva Photo Viewer (og andre prosesser) driver med.

  • Liker 1
Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
  • Hvem er aktive   0 medlemmer

    • Ingen innloggede medlemmer aktive
×
×
  • Opprett ny...