OPDATERING 11/03/08: Sørg for at læse den fremragende og detaljeret kommentar fra Dese Lunsford til denne post.

Jeg har arbejdet på en hemmelig tech redigering projekt for en kommende bog og det referencer Denne blog-indtastning ved Tyler Butler på MSDN ECM bloggen. Dette er første gang, jeg har personligt læst en klar definition af meningen med begrænset adgang. Her er kød af definitionen:

I SharePoint, anonyme brugere’ rettigheder bestemmes af tilladelsesniveauet begrænset adgang. Begrænset adgang er et særlig tilladelsesniveau, der kan ikke tildeles til en bruger eller gruppe direkte. Den eksisterer grunden er, at hvis du har et bibliotek eller et underordnet, er brudt nedarvning af tilladelser, og du give en bruger eller gruppe adgang til dette bibliotek/underordnet, for at få vist dens indhold, brugergruppen skal have nogle adgang til rodwebstedet. Ellers vil brugergruppen ikke kunne gennemse det bibliotek/underordnede websted, Selvom de dér har rettigheder, fordi der er ting i rodwebstedet, der er nødvendige til at gengive det websted eller et bibliotek. Derfor, Når du giver en gruppetilladelser kun til et underordnet websted eller bibliotek, der bryde nedarvning af tilladelser, SharePoint vil automatisk give begrænset adgang til denne gruppe eller bruger på rodwebstedet.

Dette spørgsmål kommer nu og derefter på MSDN-foraene, og jeg har altid været nysgerrige (men ikke nysgerrige at regne det ud før i dag :)).

</slutningen>

Abonner på min blog.

Følg mig på kvidre på http://www.twitter.com/pagalvin

I et tegn på, at sociale Computing begynder at take off med SharePoint, Jeg ser et øget antal mit websted type spørgsmål. Et fælles spørgsmål går noget som dette:

"Jeg er en administrator og jeg har brug at kunne få adgang til alle mit websted. Hvordan gør jeg det?"

Tricket her er, at hver mit websted egen websteder. SharePoint sikkerhed administreres normalt på webstedsgruppeniveau og dette ture oppe mange en SharePoint-administrator. Normalt, Hun har allerede adgang til at konfigurere sikkerhed i "main" site samlinger og kan ikke indse, at det virker automatisk for mine websteder.

Grupper af websteder kollektivt levende inde i en større beholder, der er web-applikation. Farm admins kan kan konfigurere sikkerhed på web app plan og dette er, hvordan admins kan tildele sig selv adgang til enhver gruppe af websteder i webprogrammet. Dette blogindlæg beskriver en af mine personlige erfaringer med web application politikker. Jeg defineret en web applikation politik ved et uheld: http://paulgalvin.spaces.live.com/Blog/cns!1CC1EDB3DAA9B8AA!255.entry.

Web application politikker kan være farligt, og jeg vil foreslå at de bruges sparsomt. Hvis jeg var en admin (og Gudskelov jeg er ikke), Jeg ville oprette en særskilt annonce konto opkaldt noget lignende "SharePoint Web App Administrator" og give en kontoen web application sikkerhedsrollen det behov. Jeg ville ikke Konfigurer denne slags ting for regelmæssig farm admin eller individuelle site collection admins. Det bliver en tendens til at skjule potentielle problemer, fordi web app rolle tilsidesætter eventuelle lavere niveau Sikkerhedsindstillinger.

</slutningen>

Abonner på min blog.

Følg mig på kvidre på http://www.twitter.com/pagalvin

OPDATERING (02/29/08): Dette nye codeplex projekt synes at give en metode til sikring af enkelte kolonner: http://www.codeplex.com/SPListDisplaySetting. Hvis du har nogen erfaring med at arbejde med det, venligst efterlade en kommentar.

Forum plakater stille ofte et spørgsmål som dette: "Jeg har en manager visning og og et personale visning af en liste. Hvordan sikrer jeg visningen manager, således at personalet ikke kan bruge det?"

De spørger også jævnligt en beslægtet afhøre: "Jeg ønsker at sikre en kolonne med specifikke metadata, således at kun ledere kan redigere denne kolonne, mens andre ikke kan selv se det."

Disse svar gælder for begge WSS 3.0 og MOSS:

• SharePoint indeholder ikke out-of-the-box understøttelse for at sikre visninger.
• SharePoint indeholder ikke out-of-the-box understøttelse for sikkerhed kolonner.

Der er flere teknikker man kan følge for at opfylde disse former for sikkerhedskrav. Her er hvad jeg kan tænke på:

• Bruge out-of-the-box sikkerhed på elementniveau. Udsigt ære altid vare sikkerhedskonfiguration. Hændelsesmodtagere og/eller arbejdsprocessen kan automatisere sikkerhedsindstilling.
• Bruge personlige visninger for "privilegeret" visninger. Disse er let nok at sætte op. Dog, på grund af deres "personlige" natur, disse skal konfigureres for hver bruger. Brug Standardsikkerhed konfiguration til at forhindre andre i at oprette en personlig visning.
• Bruge webdelen datavisning og gennemføre en slags AJAXy trimning sikkerhedsløsning.
• Roll din egen liste display funktionalitet og indarbejde sikkerhed trimning på kolonneniveau.
• Ændre dataindtastningsformularerne og bruge JavaScript sammen med sikkerhedsmodellen for at gennemføre kolonneniveau sikkerhed trimning.
• Bruge en InfoPath-formular til indtastning af data. Gennemføre kolonneniveau sikkerhed trimning via web serviceopkald til SharePoint og betinget hide felter efter behov.
• Roll din egen ASP.NET data entry funktion, der implementerer kolonne sikkerhed trimning.

Ingen af disse muligheder er virkelig så stor, men der er mindst en sti at følge, hvis du skal, Selvom det er svært.

NOTE: Hvis du går ned nogen af disse stier, Glem ikke om "handlinger-> Åbn i Windows Stifinder". Du vil være sikker på, at du tester med denne funktion for at sikre, at det ikke virker som en "bagdør" og besejre dine sikringsordning.

Hvis du har andre ideer til eller erfaringer med sikring af kolonner eller visninger, Vær så venlig e-mail mig eller efterlade en kommentar og jeg vil opdatere denne postering som passende.

</slutningen>

Abonner på min blog.

OPDATERING: Jeg bogført dette spørgsmål til MSDN her (http://forums.microsoft.com/Forums/ShowPost.aspx?PostID=2808543&SiteID=1&mode=1) og Michael Washam af Microsoft reagerede med et kortfattet svar.

Jeg oprettede en webtjeneste til at fungere som en BDC-venlige facade til en SharePoint-liste. Når jeg brugte dette fra min udviklingsmiljø, Det fungerede fint. Når jeg overflyttet dette til en ny server, Jeg fandt denne fejl:

Her er linjen 69:

ved hjælp af (SPSite site = ny SPSite("http://localhost/sandbox"))

Jeg prøvet forskellige variationer på URL-adressen, herunder ved hjælp af serverens rigtige navn, dens IP-adresse, efterstillet skråstreg på URL-adressen, osv. Jeg fik altid at fejl.

Jeg brugte Google til forskning det. Masser af mennesker står over for problemet, eller variationer af det, men syntes ingen at have det løst.

Tricksy MOSS forudsat en detaljeret fejl, at det ikke faldt til mig at kontrollere den 12 hive logs. Til sidst, om 24 timer efter min kollega anbefalede jeg gøre det., Jeg tjekkede ud den 12 hive log og fandt denne:

Der opstod en undtagelse under forsøget på at erhverve den lokale farm:
System.Security.SecurityException: Anmodede indskrive adgang er ikke tilladt.
på System.ThrowHelper.ThrowSecurityException(ExceptionResource ressourcer) på Microsoft.Win32.RegistryKey.OpenSubKey(String navn, Boolesk skrivbar) på Microsoft.Win32.RegistryKey.OpenSubKey(String navn) på Microsoft.SharePoint.Administration.SPConfigurationDatabase.get_RegistryConnectionString() på Microsoft.SharePoint.Administration.SPConfigurationDatabase.get_Local() på Microsoft.SharePoint.Administration.SPFarm.FindLocal(SPFarm& Farm, Boolesk værdi& isJoined)
Zonen for den forsamling, der ikke var:  MyComputer

Det åbnede op for nye muligheder for forskning, så det var tilbage til Google. Det førte mig til dette forumindlæg: http://forums.CodeCharge.com/posts.php?post_id = 67135. Der ikke virkelig hjælpe mig, men det begynde at gøre mig tror, der var et problem med databasen og/eller sikkerhed. Jeg fortsatte og Andrew Connell bogføre endelig udløst den tanke, at jeg skal sørge for at programgruppens identitet konto havde passende adgang til databasen. Jeg troede det allerede gjorde. Dog, min kollega gik og gav app pool identitet konto fuld adgang til SQL.

Så snart hun har foretaget denne ændring, alt begyndte at arbejde.

Hvad der skete næste er bedst udtrykt i en Haiku digt:

Problemer hæve deres hænder.
Du swing og miss. Prøv igen.
Succes! Men hvordan? Hvorfor?

Hun ønskede ikke at lade tingene alene, men foretrækker at give den mindste nødvendige tilladelse (og formentlig med henblik på at skrive en blog post; Jeg fik hende til punch, muhahahahaha!).

Hun fjernede successive tilladelser fra app programgruppens identitet konto indtil … der var ikke længere nogen udtrykkelig tilladelse til app programgruppens identitet konto på alle. Webtjenesten fortsatte med at fungere fint.

Vi gik og genstartet serverne. Alt fortsatte med at fungere fint.

Så, at opsummere: Vi gav den app pool identity fuld adgang og derefter tog det væk. Webtjenesten begyndte at arbejde og aldrig standsede i orden. Bizarre.

Hvis nogen ved, hvorfor der bør har arbejdet, venligst efterlade en kommentar.

</slutningen>

Jeg havde brug at opfylde en sikkerhedskrav for en InfoPath-formular i dag. I denne situation, business, et relativt lille antal personer er tilladt at oprette en ny InfoPath-formular og en meget bredere publikum får lov til at redigere det.. (Dette er nye-leje på bording formular bruges af menneskelige ressourcer, der starter en arbejdsproces).

At opfylde dette mål, Jeg oprettede oprettet to nye tilladelsesniveauer ("oprette og opdatere" og "Opdater kun"), brød arv for formularbiblioteket og tildelt tilladelser til en "Opret, opdatere" brugeren og en separat "Opdater kun" bruger. Den mekanik alle arbejdede, men det viste sig for at være lidt mere med end jeg havde forventet. (Hvis du føler dig lidt usikker på SharePoint-tilladelser, Tjek dette blog-indlæg). Den krævede sikkerhedskonfiguration for tilladelsesniveauet var ikke det indlysende sæt kornede tilladelser. Oprette en opdatering, der kun tilladelsesniveau til en InfoPath-formular, Jeg gjorde følgende:

1. Oprette en nye tilladelsesniveau.
2. Ryd væk alle indstillinger.
3. Valgt kun følgende fra "listetilladelser":

• Rediger elementer
• Vis listeelementer
• Se programsider

At vælge disse indstillinger tillader brugeren at opdatere en form, men ikke opretter den.

Tricket var at aktivere "Vis ansøgning sider". Der er ikke nogen verbage på det tilladelsesniveau, der angiver, der er nødvendige for update-only InfoPath-formularer, men vender ud det er.

Opret og Opdater var endda fremmede. Jeg fulgt den samme foranstaltninger, 1 gennem 3 ovenfor. Jeg havde udtrykkeligt tilføje en "Site tilladelse" indstilling: "Brug funktioner til integration". Igen, Beskrivelse der gør det ud som om det skulle være nødvendigt for en InfoPath-formular ikke, men der er det.

</slutningen>

OPDATERING 01/28/08: Dette codeplex projekt løser problemet: http://www.codeplex.com/AccessChecker. Jeg har ikke brugt det, men det ser lovende, hvis dette er et problem, du har brug for til adresse i dit miljø.

OPDATERING 11/13/08: Joel Oleson skrev op en meget god stilling på større sikkerhed forvaltning spørgsmålet her: http://www.sharepointjoel.com/lists/posts/post.aspx?Liste = 0cd1a63d % 2D183c % 2D4fc2% 2 D 8320% 2Dba5369008acb&ID = 113. Det knytter sig til en række andre nyttige ressourcer.

Forum brugere og klienter stille ofte et spørgsmål i den retning: "Hvordan jeg genererer en liste over alle brugere med adgang til et websted" eller "hvordan kan jeg automatisk advare alle brugere med adgang til listen om ændringer af listen?"

Der er ingen ud af boksen løsning for dette. Hvis du tænker over det et øjeblik, Det er ikke svært at forstå hvorfor.

SharePoint sikkerhed er meget fleksibel. Der er mindst fire hovedkategorier af brugere:

• Anonyme brugere.
• SharePoint-brugere og grupper.
• Active Directory-brugere.
• Formularbaseret godkendelse (FORMULARBASERET GODKENDELSE) brugere.

Fleksibilitet betyder, at set fra et sikkerhedssynspunkt, enhver given SharePoint site bliver dramatisk anderledes fra en anden. For at generere en rapport over liste, et behov for at fastslå, hvordan webstedet er sikret, forespørge på flere forskellige bruger profil repositories og derefter præsentere det på en nyttig måde. Det er et svært problem at løse generisk.

Hvordan er organisationer beskæftiger sig med dette? Jeg ville elske at høre fra dig i kommentarerne eller e-mail.

</slutningen>

OPDATERING 12/18/07: Se Paul Liebrand artikel for nogle tekniske konsekvenser af fjerne eller ændre standardnavnene på gruppe (se hans bemærkning nedenfor samt).

Oversigt:

SharePoint sikkerhed er let at konfigurere og administrere. Dog, Det har vist sig for at være svært for nogle første gang administratorer virkelig ombryde deres hænder omkring det.. Ikke kun det, Jeg har set nogle administratorer kommer til en perfekt forståelse på mandag kun at have mistet det af fredag, fordi de ikke behøvede at gøre enhver konfiguration i den mellemliggende tid. (Jeg indrømmer at have dette problem selv). Denne blogoptegnelse forhåbentlig giver en nyttig SharePoint sikkerhed primer og peger i retning af nogle sikkerhed konfiguration af bedste praksis.

Vigtig bemærkning:

Denne beskrivelse er baseret på ud af boksen SharePoint sikkerhed. Min personlige erfaring er orienteret omkring mos, så der kan være nogle MOSS specifikke ting her, men det forekommer mig nøjagtig for WSS. Jeg håber, at nogen ser fejl eller udeladelser vil påpege at, i kommentarer eller e-mail mig. Jeg vil foretage rettelser post hast.

Fundamentals:

Med henblik på denne oversigt, der er fire grundlæggende aspekter til sikkerhed: brugere/grupper, securable objekter, tilladelsesniveauer og arv.

Brugere og grupper bryde ned til:

• Individuelle brugere: Trukket fra active directory eller skabt direkte i SharePoint.
• Grupper: Tilknyttede direkte fra active directory eller oprettet i SharePoint. Grupper er en samling af brugere. Grupper er globale i en gruppe af websteder. De er aldrig "bundet" til et bestemt objekt.

Securable objekter bryde ned til mindst:

• Websteder
• Dokumentbiblioteker
• Individuelle elementer på lister og dokumentbiblioteker
• Mapper
• Forskellige BDC-indstillingerne.

Der andre securable objekter, men du får billedet.

Tilladelsesniveauer: Et bundt af kornet / lavt niveau adgangsrettigheder, der omfatter sådanne ting som oprette/læse/slette poster i lister.

Arv: Objekter arver som standard sikkerhedsindstillinger fra deres indeholdende objekt. Underordnede websteder nedarver tilladelse fra deres forældre. Dokumentbiblioteker arver fra deres hjemmeside. Så videre og så videre.

Brugere og grupper vedrører securable objekter via tilladelsesniveauer og arv.

De vigtigste sikkerhedsregler for at forstå, nogensinde 🙂 :

1. Grupper er simpelthen samlinger af brugere.
2. Grupper er globale inden for en gruppe af websteder (dvs. der er ikke sådan noget som en gruppe, der er defineret på et webstedsniveau).
3. Gruppenavnet ikke modstå, grupper ikke, i og for sig selv, har nogen bestemt sikkerhedsniveau.
4. Grupper har sikkerhed i forbindelse med et bestemt objekt.
5. Du kan tildele forskellige tilladelsesniveauer til den samme gruppe for hvert objekt.
6. Web application politikker trumfe alt dette (Se nedenfor).

Sikkerhedsadministratorer tabt i et hav af gruppen og bruger lister kan altid stole på disse aksiomer at håndtere og forstå deres sikkerhedskonfiguration.

Fælles faldgruber:

• Gruppenavne indebærer fejlagtigt tilladelse: Ud af boksen, SharePoint definerer et sæt af grupper hvis navne indebærer en iboende sikkerhedsniveau. Overveje gruppen "Bidragyder". En uvant med SharePoint sikkerhed kan godt kigge på dette navn og antage, at ethvert medlem af denne gruppe kan "bidrage" til ethvert websted/liste/bibliotek i portalen. Det kan være sandt, men ikke fordi gruppens navn sker for at være "bidragyder". Dette er kun rigtigt ud af kassen fordi gruppen har fået et tilladelsesniveau, der sætter dem i stand til at tilføje/redigere/slette indhold på rodwebstedet. Gennem arv, "bidragydere" Gruppen kan også tilføje/redigere/slette indholdet på hvert underordnet websted. Man kan "bryde" arven kæden og ændre tilladelsesniveauet for et underordnet websted sådan at medlemmer af den såkaldte "bidragyder" Gruppen kan ikke bidrage på alle, men kun læse (for eksempel). Dette ville ikke være en god idé, naturligvis, da det ville være meget forvirrende.
• Grupper er ikke defineret på et webstedsniveau. Det er nemt at blive forvirret af brugergrænsefladen. Microsoft giver et praktisk link til bruger eller gruppe forvaltning via hver site "mennesker og grupper" link. Det er nemt at tro, at når jeg er på webstedet "xyzzy" jeg oprette en gruppe gennem xyzzy's folk og grupper link, jeg har lige oprettet en gruppe, som kun findes på xyzzy. Det er ikke tilfældet. Jeg har faktisk lavet en gruppe til hele gruppen af websteder.
• Grupper medlemskab er ikke afhængig af hjemmeside (dvs. Det er den samme overalt benyttes gruppen): Overveje gruppen "ejer" og to websteder, "HR" og "Logistik". Det ville være normalt at tænke, at to separate enkeltpersoner ville eje disse websteder — en HR ejer og en logistik ejer. Brugergrænsefladen gør det nemt for en sikkerhedsadministrator at fejlhåndtere dette scenario. Hvis jeg ikke vidste bedre, Jeg kan få adgang til personer og grupper links via webstedet HR, Vælg "ejere" gruppe og tilføje min HR ejer til denne gruppe. En måned senere, Logistik kommer på linje. Jeg adgang til personer og grupper fra webstedet logistik, tilføje pull up "ejere" gruppe. Jeg ser HR ejeren der og fjerne hende, tænker at jeg fjerner hende fra ejere på webstedet logistik. Faktisk, Jeg fjerner hende fra gruppen globale ejere. Munterhed ensues.
• Undlade at navnet grupper baseret på specifikke rolle: "Godkendere" Gruppen er et perfekt eksempel. Hvad kan medlemmer af denne gruppe Godkend? Hvor kan de godkende det? Vil jeg virkelig folk logistikafdeling at godkende HR dokumenter? Naturligvis ikke. Altid navn grupper baseret på deres rolle i organisationen. Dette vil reducere den risiko, at gruppen er tildelt en upassende tilladelsesniveauet for et bestemt objekt. Navnet grupper baseret på deres tiltænkte rolle. I det forrige HR/logistik scenarie, Jeg skal have lavet to nye grupper: "HR ejere" og "logistik ejere" og tildele fornuftige tilladelsesniveauer for hver og det minimumsbeløb, der kræves til disse brugere at gøre deres job.

Andre nyttige referencer:

• Web application politik gotcha: http://paulgalvin.spaces.live.com/blog/cns!1CC1EDB3DAA9B8AA!255.entry
• Clearinghouse for SharePoint sikkerhed: http://www.sharepointsecurity.com/
• Links fra Joel Oleson: http://blogs.msdn.com/joelo/archive/2007/08/23/sharepoint-security-and-compliance-resources.aspx

Hvis du har gjort det så langt:

Lad mig vide dine tanker via kommentarer eller email mig. Hvis du kender andre gode referencer, venligst gøre det samme!