UPPDATERING 11/03/08: Läs den utmärkta och detaljerad kommentaren från Dessie Lunsford till denna post.

Jag har arbetat på en hemlig teknisk redigering projekt för en kommande bok och den refererar Detta blogginlägg av Tyler Butler på MSDN ECM-blogg. Detta är första gången jag läste personligen en tydlig definition av begreppet begränsad tillgång. Här är kött av definitionen:

I SharePoint, anonyma användare’ rättigheter bestäms av behörighetsnivå begränsad åtkomst. Begränsad åtkomst är en särskild behörighetsnivå som inte kan hänföras till en användare eller grupp direkt. Anledningen till den finns är att om du har ett bibliotek eller en underwebbplats som har brutit behörigheter arv, och du ger en användare/grupp tillgång till endast att biblioteket/underwebbplats, för att visa dess innehåll, användaren eller gruppen måste ha vissa tillgång till rotwebbplatsen. Annars kommer att användaren eller gruppen inte kunna bläddra i biblioteket/underwebbplats, Trots att de har rättigheter det, eftersom det finns saker på rotwebbplatsen som behövs för att återge den webbplats eller bibliotek. Därför, När du ger en gruppbehörigheter endast till en underwebbplats eller bibliotek som bryter mot behörigheter arv, SharePoint ger automatiskt begränsad tillgång till att grupp- eller användarnamn på rotwebbplatsen.

Denna fråga kommer upp då och då på MSDN: S forum och jag har alltid varit nyfiken (men inte så underligt att räkna det ut före dag :)).

</slutet>

Prenumerera på min blogg.

Följ mig på Twitter vid http://www.twitter.com/pagalvin

I ett tecken på att Social Computing börjar ta fart med SharePoint, Jag ser ett ökat antal min webbplats typ frågor. En vanlig fråga går ungefär så här:

"Jag är en administratör och jag behöver för att kunna komma åt varje min webbplats. Hur gör jag det?"

Tricket är att varje min webbplats är dess egna webbplatssamling. SharePoint security administreras normalt på webbplatssamlingsnivå och detta resor upp många en SharePoint-administratör. Normalt, Hon har redan tillgång till Konfigurera säkerhet i den "huvudsakligt" Site samlingar och kanske inte inser att detta inte automatiskt fungerar för mina webbplatser.

Webbplatssamlingar kollektivt levande inuti en större behållare, vilket är webbprogrammet. Farm admins kan kan konfigurera säkerhet på web app nivå och detta är hur administratörer kan bevilja sig tillgång till en webbplatssamling i webbprogrammet. Denna bloggpost beskriver en av mina personliga erfarenheter med web ansökan politik. Jag definierade en web application politik av en slump: http://paulgalvin.spaces.live.com/Blog/cns!1CC1EDB3DAA9B8AA!255.entry.

Spindelväv ansökan politik kan vara farligt och jag föreslår att de bör användas sparsamt. Om jag var en admin (och tack och lov är jag inte), Jag vill skapa en separat annons konto heter något i stil med "SharePoint Web App administratör" och ge det en redovisa web security rollen måste. Jag skulle inte konfigurera något sådant för regelbunden farm admin eller enskild plats samling admins. Det tenderar att dölja eventuella problem eftersom rollen web app åsidosätter eventuella lägre nivå säkerhetsinställningar.

</slutet>

Prenumerera på min blogg.

Följ mig på Twitter vid http://www.twitter.com/pagalvin

UPPDATERING (02/29/08): Detta nya codeplex projekt tycks erbjuda en metod för att skydda enskilda kolumner: http://www.codeplex.com/SPListDisplaySetting. Om du har någon erfarenhet av att arbeta med det., lämna gärna en kommentar.

Forum affischer fråga ofta en som denna: "Jag har en manager syn och och en personal vy av en lista. Hur skyddar jag vyn manager så att personalen inte kan använda det?"

De frågar också ofta en relaterad fråga: "Jag vill säkra en kolumn med specifika metadata så att endast chefer kan redigera kolumnen medan andra inte kanske ens ser det."

Dessa svar gälla båda WSS 3.0 och MOSS:

• SharePoint ger inte stöd för out-of-the-box för att säkra visningar.
• SharePoint ger inte out-of-the-box stöd för säkerhet kolumner.

Det finns flera tekniker som kan följa för att möta dessa typer av säkerhetskrav. Här är vad jag kan komma på:

• Använda out-of-the-box säkerhet på objektnivå. Utsikt över hedra alltid artikelkonfiguration säkerhet på objektnivå. Event mottagare och/eller arbetsflöde kan automatisera säkerhet tilldelning.
• Använda personliga åsikter för "privilegierade" visningar. Detta är lätt att ställa in. Men, på grund av deras "personliga" natur, dessa måste konfigureras för varje användare. Använda standard säkerhetskonfiguration för att hindra någon annan från att skapa en personlig vy.
• Använda en datavywebbdel och genomföra någon form av AJAXy säkerhetslösning trimning.
• Rulla din egen display listfunktionerna och införliva säkerhetsoptimering på kolumnnivå.
• Ändrar inmatningsformulär och använder JavaScript i samband med säkerhetsmodell för att genomföra kolumnnivå säkerhetsoptimering.
• Använda ett InfoPath-formulär för datainmatning. Genomföra kolumnnivå säkerhetsoptimering via web tjänst samtal till SharePoint och villkorligt Dölj fält som behövs.
• Rulla dina egna ASP.NET data inresa funktion som implementerar kolumn nivå säkerhetsoptimering.

Inget av dessa alternativ är verkligen så bra, men det finns åtminstone en väg att följa om du behöver, även om det är svårt.

ANMÄRKNING: Om du går ner någon av dessa vägar, Glöm inte om "åtgärder-> Öppna med Utforskaren". Du vill vara säker på att du testar med den funktionen att se till att det fungerar som en "bakdörr" och besegra dina säkerhetsprogram.

Om du har andra idéer för eller erfarenheter med att säkra kolumner eller visningar, Snälla maila mig eller lämna en kommentar och jag kommer uppdatera detta inlägg som lämpliga.

</slutet>

Prenumerera på min blogg.

UPPDATERING: Jag postat denna fråga till MSDN här (http://forums.microsoft.com/Forums/ShowPost.aspx?PostID=2808543&SiteID=1&mode=1) och Michael Washam av Microsoft svarade med ett koncist svar.

Jag skapade en webbtjänst för att fungera som en BDC-vänlig fasad till en SharePoint-lista. När jag använde detta från min utvecklingsmiljö, det fungerade bra. När jag flyttade detta till en ny server, Jag stötte på detta fel:

Här är linje 69:

med hjälp av (SPSite webbplats = nya SPSite("http://localhost/sandbox"))

Jag försökte olika varianter på Webbadressen, med hjälp av serverns riktiga namn, dess IP-adress, avslutande snedstreck på Webbadressen, m.m.. Jag fick alltid som fel.

Jag använde Google till forskning om det. Massor av människor står inför denna fråga, eller varianter av det, men verkade ingen ha det löst.

Tricksy MOSS som sådan en detaljerad fel att det inte uppstår för mig att kontrollera den 12 kupan loggar. Så småningom, om 24 timmar efter min kollega bör jag göra så, Jag kollade ut den 12 bikupa stock och hittade denna:

Ett undantag uppstod vid försök att förvärva den lokala servergruppen:
System.Security.SecurityException: Önskade registret åtkomst tillåts inte.
på System.ThrowHelper.ThrowSecurityException(ExceptionResource resurs) på Microsoft.Win32.RegistryKey.OpenSubKey(String namn, Boolean skrivbar) på Microsoft.Win32.RegistryKey.OpenSubKey(String namn) på Microsoft.SharePoint.Administration.SPConfigurationDatabase.get_RegistryConnectionString() på Microsoft.SharePoint.Administration.SPConfigurationDatabase.get_Local() på Microsoft.SharePoint.Administration.SPFarm.FindLocal(SPFarm& gård, Booleskt värde& isJoined)
Zonplanera av församlingen som inte var:  Här datorn

Detta öppnade upp nya vägar för forskning, så var det tillbaka till The Google. Som ledde mig till detta foruminlägg: http://forums.CodeCharge.com/posts.php?post_id = 67135. Det hjälpte verkligen mig men det börja göra jag tror det var en databas och/eller säkerhet fråga. Jag soldiered och Andrew Connell Bokför slutligen utlösta tanken att jag ska se till att programpoolens identitet konto hade tillgång till databasen. Jag trodde det gjorde redan. Men, min kollega och gav den app pool identitet konto full tillgången till SQL.

Så snart hon gjorde ändringen, allt började arbeta.

Vad hände nästa bästa uttrycks som en Haiku dikt:

Problem höja sina händer.
Du swing och miss. Försök igen.
Framgång! Men hur? Varför?

Hon ville inte lämna saker ensam sådär, föredrar att ge de minsta krävs tillstånd (och förmodligen tanke skriver en bloggpost; Jag slog henne till punsch, muhahahahaha!).

Hon bort successiva behörigheter från app pool identitetskontot tills … Det fanns inte längre någon uttrycklig tillåtelse för app pool identitetskontot alls. Webbtjänsten fortsatte att fungera bra.

Vi gick och rebooted servrar. Allt fortsatte att fungera bra.

Så, till resumé: Vi gav den full tillgången till app pool identitet och sedan tog det bort. Webbtjänsten började arbeta och aldrig slutat fungera. Bisarra.

Om någon vet varför det bör ha arbetat, lämna gärna en kommentar.

</slutet>

Ett säkerhetskrav för ett InfoPath-formulär idag behov. I den här affärssituationen, ett relativt litet antal individer får skapa ett nytt InfoPath-formulär och en mycket bredare publik får redigera den. (Detta är nya-hyra på ombordstigning form används av mänskliga resurser som startar ett arbetsflöde).

Att uppfylla detta mål, Jag skapade skapade två nya behörighetsnivåer ("skapa och uppdatera" och "uppdatera endast"), bröt arv för formulärbiblioteket och behörigheter till en "skapa, uppdatera" användare och en separat uppdatera"endast" användaren. Mekanikerna alla arbetat, men det visade sig vara lite mer där än väntat. (Om du känner dig lite skakig på SharePoint-behörigheter, Kolla in detta blogginlägg). Krävs säkerhetskonfiguration för behörighetsnivån var inte den uppenbara uppsättningen granulat behörigheter. Att skapa en uppdatering-bara behörighetsnivå för ett InfoPath-formulär, Jag gjorde följande:

1. Skapa en ny behörighetsnivå.
2. Rensa bort alla alternativ.
3. Valt endast följande från "Listbehörigheter":

• Redigera objekt
• Visa objekt
• Visa ansökan sidor

Att välja dessa alternativ tillåter en användare att uppdatera en form, men inte skapar det.

Tricket var att aktivera "Visa ansökan sidor". Det finns inte någon verbage på behörighetsnivån som anger som krävs för endast uppdatera InfoPath-formulär, men visar sig att det är.

Skapa och uppdatera var ännu underligare. Jag följde samma steg, 1 genom 3 ovan. Jag var tvungen att lägga särskilt till en webbplats behörighet"" alternativet: "Använd klientfunktioner integration". Igen, Beskrivning Det gör inte det verka som om det borde krävas för ett InfoPath-formulär, men där är det.

</slutet>

UPPDATERING 01/28/08: Codeplex projektet behandlar denna fråga: http://www.codeplex.com/AccessChecker. Jag har inte använt det, men det ser lovande ut om detta är en fråga som du behöver till adressen i din miljö.

UPPDATERING 11/13/08: Joel Oleson skrev upp ett mycket bra inlägg om större security management frågan här: http://www.sharepointjoel.com/ Lists/Posts/Post.aspx?Lista = 0cd1a63d % 2D183c % 2D4fc2 %2 D 8320% 2Dba5369008acb&ID = 113. Den länkar till ett antal andra användbara resurser.

Forumanvändare och kunder frågar ofta en fråga längs dessa linjer: "Hur jag skapar en lista över alla användare med åtkomst till en webbplats" eller "Hur kan jag automatiskt varna alla användare med tillgång till listan om ändringar i listan?"

Det finns inget ut av den färdiga lösningen för detta. Om du tänker på det för ett ögonblick, Det är inte svårt att förstå varför.

SharePoint-säkerhet är mycket flexibel. Det finns minst fyra stora kategorier av användare:

• Anonyma användare.
• SharePoint-användare och grupper.
• Active Directory-användare.
• Formulärbaserad autentisering (FBA) användare.

Flexibilitet innebär att ur ett säkerhetsperspektiv, en viss SharePoint-webbplats kommer att dramatiskt annorlunda från en annan. För att generera en rapport med tillgång, måste man fastställa hur platsen är säkrad, fråga flera olik förbrukaren profil databaser och sedan presentera den på ett användbart sätt. Det är ett svårt problem att lösa allmänt.

Hur organisationer behandlar detta? Jag skulle gärna höra från dig i kommentarer eller e-post.

</slutet>

UPPDATERING 12/18/07: Se Paul Liebrand artikel för några tekniska konsekvenser av att ta bort eller ändra gruppnamn standard (se hans kommentar nedan samt).

Översikt:

SharePoint-säkerhet är lätt att konfigurera och hantera. Men, Det har visat sig vara svårt för vissa första gången administratörer att verkligen Linda sina händer runt den. Inte bara det, Jag har sett några administratörer komma till en perfekt förståelse på måndag bara för att ha förlorat det genom fredag eftersom de behövde inte göra någon konfiguration i den mellanliggande tiden. (Jag erkänna att jag har detta problem jag själv). Denna bloggpost förhoppningsvis ger en användbar SharePoint security primer och pekar mot några metodtips för konfiguration.

Viktigt att notera:

Denna beskrivning är baserad på ur lådan SharePoint security. Min personliga erfarenhet är orienterade kring mossa så det kan vara lite mossa specifika saker här, men jag tror det är exakt för WSS. Jag hoppas att någon ser eventuella fel eller utelämnanden kommer att påpeka det i kommentarer eller maila mig. Jag ska göra korrigeringar post brådska.

Grunderna:

Vid tillämpningen av denna översikt, Det finns fyra grundläggande aspekter på säkerhet: användare/grupper, objekt, behörighetsnivåer och arv.

Användare och grupper bryta ner till:

• Enskilda användare: Drog från active directory eller skapade direkt i SharePoint.
• Grupper: Mappade direkt från active directory eller skapade i SharePoint. Grupper är en samling av användare. Grupper är globala i en webbplatssamling. De är aldrig "bundna" till specifika objekt.

Objekt bryta ner till minst:

• Platser
• Dokumentbibliotek
• Enskilda objekt i listor och dokumentbibliotek
• Mappar
• Olika BDC-inställningar.

Det andra objekt, men du får bilden.

Behörighetsnivåer: En bunt av granulat / låg nivå åtkomsträttigheter som inkluderar sådana saker som skapa/läsa/ta bort poster i listor.

Arv: Som standard ärver enheter säkerhetsinställningar från deras som innehåller objekt. Underwebbplatser ärver behörighet från deras överordnade. Dokumentbibliotek ärver från deras webbplats. Och så vidare.

Användare och grupper relaterar till objekt via behörighetsnivåer och arv.

De viktigaste säkerhetsreglerna att förstå, Någonsin 🙂 :

1. Grupper är helt enkelt samlingar av användare.
2. Grupper är globala inom en webbplatssamling (dvs. Det finns inget sådant som en grupp som definierats på en webbplatsnivå).
3. Gruppens namn inte motstå, grupper inte, i och för sig, har någon särskild nivå av säkerhet.
4. Grupper har säkerhet inom ramen för ett specifikt objekt.
5. Du kan tilldela olika behörighetsnivåer till samma grupp för varje objekt.
6. Web ansökan politik trumf allt detta (se nedan).

Säkerhetsadministratörer vilse i ett hav av användare och användargrupper listor kan alltid lita på dessa axiom att hantera och förstå deras säkerhetskonfiguration.

Vanliga fallgropar:

• Namn innebär falskeligen tillstånd: Ur lådan, SharePoint definierar en uppsättning grupper vars namn antyda en inneboende säkerhetsnivå. Anser gruppen "Bidragsgivare". En obekant med SharePoint security kanske titta på det namnet och antar att varje medlem i gruppen kan "bidra" till någon webbplats/lista/bibliotek i portalen. Det kan vara sant men inte för att gruppens namn råkar vara "bidragsgivare". Detta gäller endast ur lådan eftersom gruppen har lämnats en behörighetsnivå som ger dem möjlighet att lägga till/redigera/radera innehållet på rotwebbplatsen. Genom arv, "bidragsgivarna" gruppen kan också lägga till/redigera/radera innehållet på varje underwebbplats. Man kan "bryta" i arvskedjan och ändrar behörighetsnivån för en underwebbplats så att medlemmar av den så kallade "bidragsgivaren" grupp inte kan bidra på alla, men bara läsa (till exempel). Detta skulle inte vara en bra idé, uppenbarligen, eftersom det skulle vara mycket förvirrande.
• Grupperna definieras inte på en webbplatsnivå. Det är lätt att förväxla med användargränssnittet. Microsoft tillhandahåller en bra länk till användare/grupp förvaltning via varje webbplats "människor och grupper" länk. Det är lätt att tro att när jag är på plats "xyzzy" och jag skapa en grupp via xyzzy's människor och grupper länk som jag har just skapat en grupp som bara finns på xyzzy. Så är inte fallet. Jag har faktiskt skapat en grupp för hela webbplatssamlingen.
• Grupper medlemskap varierar inte webbplats (dvs. Det är samma överallt gruppen används): Anser gruppen "ägare" och två platser, "HR" och "Logistik". Det skulle vara normalt att tror att två separata individer skulle äga dessa webbplatser — en HR och en logistik ägare. Användargränssnittet gör det enkelt för en säkerhetsadministratör misshandla detta scenario. Om jag inte visste bättre, Jag kan komma åt de personer och grupper länkar via webbplatsen HR, Välj "ägarna" grupp och lägga till min HR ägare till gruppen. En månad senare, Logistik kommer på rad. Jag åt personer och grupper från webbplatsen logistik, Lägg till dra upp "ägarna" grupp. Jag se HR ägare det och ta bort henne, tänker att jag är att ta bort henne från ägarna på webbplatsen logistik. I själva verket, Jag är att ta bort henne från den globala gruppen ägare. Munterhet följer.
• Underlåta att namnet grupper baserat på specifika roll: "Godkännare" gruppen är ett perfekt exempel. Vad kan medlemmar i denna grupp Godkänn? Där kan de godkänner det? Vill jag verkligen människor logistikavdelning för att kunna godkänna HR dokument? Naturligtvis inte. Alltid namn grupper baserat på deras roll inom organisationen. Detta minskar risken att gruppen tilldelats en olämplig behörighetsnivå för ett visst objekt. Namn grupper baserat på deras avsedda roll. I det föregående scenariot som HR/logistik, Jag borde ha skapat två nya grupper: "HR ägare" och logistik ägare"" och tilldela förnuftiga behörighetsnivåer för varje och det minsta belopp som krävs för dessa användare att göra sitt jobb.

Andra användbara referenser:

• Web application politik gotcha: http://paulgalvin.spaces.live.com/blog/cns!1CC1EDB3DAA9B8AA!255.entry
• Clearinghouse för SharePoint security: http://www.sharepointsecurity.com/
• Länkar från Joel Oleson: http://blogs.msdn.com/joelo/archive/2007/08/23/sharepoint-security-and-compliance-resources.aspx

Om du har gjort så här långt:

Låt mig veta dina tankar via kommentarerna eller maila mig. Om du vet andra goda referenser, gör samma!