UPDATE 11/03/08: Zorg ervoor dat u lezen de uitstekende en gedetailleerde reactie van Dessie Lunsford met deze post.

Ik heb gewerkt aan een project geheime tech bewerken voor een aanstaande boek en het verwijst naar deze blog entry door Tyler Butler op de MSDN ECM blog. Dit is de eerste keer dat ik lees persoonlijk een duidelijke definitie van de betekenis van beperkte toegang. Hier is het vlees van de definitie:

In SharePoint, anonieme gebruikers’ rechten worden bepaald door het machtigingsniveau beperkte toegang. Beperkte toegang is een speciale machtigingsniveau dat niet worden toegewezen aan een gebruiker of groep rechtstreeks. De reden dat het bestaat is omdat als u een bibliotheek of een subsite hebben die machtigingen erfenis heeft gebroken, en u een gebruiker of groep toegang geven tot alleen die bibliotheek/subsite, om de inhoud ervan bekijken, de gebruiker/groep moeten sommige toegang tot het hoofdweb. Anders zullen de gebruiker/groep niet in staat om te bladeren de bibliotheek/subsite, ook al ze rechten er hebben, omdat er dingen in het hoofdweb die nodig zijn zijn om de site of bibliotheek maken. Daarom, Wanneer u een groepsmachtigingen alleen naar een subsite of bibliotheek die machtigingen erfenis breekt geven, SharePoint zal automatisch beperkte toegang geven aan die groep of gebruiker op het hoofdweb.

Deze vraag komt nu en dan op de MSDN forums en ik ben altijd nieuwsgierig geweest (maar niet nieuwsgierig genoeg om het uitzoeken vóór vandaag :)).

</einde>

Abonneren op mijn blog.

Volg mij op Twitter op http://www.twitter.com/pagalvin

In een teken dat Social Computing begint af te nemen met SharePoint, Ik zie een toenemend aantal mijn Site type vragen. Een veel voorkomende vraag gaat iets als dit:

"Ik ben een beheerder en ik nodig om toegang tot elke mijn Site te kunnen. Hoe doe ik dat?"

De truc hier is dat elke mijn Site een eigen siteverzameling is. SharePoint veiligheid wordt gewoonlijk beheerd op het niveau van de siteverzameling en dit reizen veel een SharePoint-beheerder. Normaal, Ze heeft al toegang tot het configureren van de beveiliging in de "main" site collecties en mag niet beseffen dat dit automatisch niet voor mijn Sites werkt.

Siteverzamelingen leven binnen een grotere container collectief, Wat is de webtoepassing. Boerderij admins kunt beveiliging kunt configureren op het web app niveau en dit is hoe beheerders zichzelf toegang tot elke siteverzameling in de webtoepassing kan toekennen. Deze blog entry beschrijft een van mijn persoonlijke ervaringen met beleidsregels voor web toepassingen. Ik heb een web toepassingenbeleid gedefinieerd door ongeval: http://paulgalvin.spaces.live.com/Blog/cns!1CC1EDB3DAA9B8AA!255.entry.

Web toepassingenbeleid gevaarlijk kunnen zijn en ik stel voor dat ze met mate worden gebruikt. Als ik een admin (en gelukkig ik ben niet), Ik zou een aparte AD-account met de naam iets als "SharePoint Web App beheerder maken" en geven die een account de beveiligingsrol web toepassing die het moet. Ik zou niet dit soort dingen voor de regelmatige boerderij admin of afzonderlijke site collectie admins configureren. Het zal de neiging om potentiële problemen te verbergen omdat het web app rol voorrang heeft op een lager niveau beveiligingsinstellingen.

</einde>

Abonneren op mijn blog.

Volg mij op Twitter op http://www.twitter.com/pagalvin

UPDATE (02/29/08): Dit nieuwe codeplex project lijkt te bieden een methode voor het beveiligen van afzonderlijke kolommen: http://www.codeplex.com/SPListDisplaySetting. Hebt u enige ervaring met het werken, laat alstublieft een reactie.

Forum posters heeft vaak een vraag als deze: "Ik heb een manager weergave en en een personeel weergave van een lijst. Hoe beveilig ik de manager weergave zodat personeel kan niet het gebruiken?"

Zij stellen ook vaak een verwante vraag: "Ik wil een specifieke metagegevens kolom beveiligen zodat alleen beheerders die kolom bewerken kunnen terwijl anderen kunnen niet zelfs zien."

Deze antwoorden van toepassing op beide WSS 3.0 en MOSS:

• SharePoint biedt geen out-of-the-box ondersteuning voor het beveiligen van weergaven.
• SharePoint biedt geen out-of-the-box ondersteuning voor beveiliging kolommen.

Er zijn verschillende technieken een kunnen volgen om te voldoen aan deze soorten beveiligingsvereisten. Hier is wat ik kan bedenken:

• Beveiliging op itemniveau voor out-of-the-box gebruiken. Weergaven eren altijd item niveau Beveiligingsconfiguratie. Gebeurtenis ontvangers en/of werkstroom kunt automatiseren beveiligingsinstellingen toewijzing.
• Persoonlijke weergaven gebruiken voor "bevoorrechte" Weergaven. Deze zijn gemakkelijk genoeg om in te stellen. Echter, in verband met hun "persoonlijke" natuur, Deze moeten worden geconfigureerd voor elke gebruiker. Gebruik standaard beveiligingsconfiguratie om te voorkomen dat iemand anders een persoonlijke weergave maken.
• Een webonderdeel voor gegevensweergave gebruiken en uit te voeren een soort AJAXy beveiligingsoplossing trimmen.
• Uw eigen lijst weergave functionaliteit roll en nemen veiligheid trimmen op kolomniveau.
• Wijzigen van de formulieren voor gegevensinvoer en JavaScript gebruiken in combinatie met het beveiligingsmodel te implementeren van beveiliging op gebruikersniveau kolom trimmen.
• Een InfoPath-formulier voor gegevensinvoer gebruiken. Implementeren van beveiliging op gebruikersniveau kolom trimmen via web serviceoproepen aan SharePoint en voorwaardelijk Verberg velden zo nodig.
• Uw eigen ASP.net-gegevens ingang functie waarmee kolom beveiliging trimmen roll.

Geen van deze opties zijn echt dat geweldig, maar er is ten minste een pad te volgen als u wilt, zelfs als het is moeilijk.

OPMERKING: Als je naar beneden een van deze paden, Vergeet niet over "acties-> Openen met Windows Verkenner". U wilt er zeker van dat u met die functie test om ervoor te zorgen dat het niet als een "achterdeur werkt" en uw veiligheid regeling te verslaan.

Hebt u andere ideeën voor of ervaringen met kolommen of weergaven beveiligen, Gelieve e-mail me of een reactie achterlaten en ik zal updaten dit bericht zo nodig.

</einde>

Abonneren op mijn blog.

UPDATE: Ik gepost hier deze vraag op MSDN (http://forums.microsoft.com/Forums/ShowPost.aspx?PostID=2808543&SiteID=1&mode=1) en Michael Washam van Microsoft reageerde met een beknopte antwoord.

Ik heb gemaakt een webservice om op te treden als een BDC-vriendelijke gevel naar een SharePoint-lijst. Wanneer mij tweedehands zulks van mijn ontwikkelomgeving, het werkte boete. Wanneer ik dit gemigreerd naar een nieuwe server, Ik ondervonden deze fout:

Hier is lijn 69:

met behulp van (SPSite site = nieuwe SPSite("http://localhost/sandbox"))

Ik heb geprobeerd verschillende variaties op de URL, inclusief het gebruik van de echte naam van de server, het IP-adres, afsluitende schuine strepen op de URL, etc. Ik got altijd welk vergissing.

Ik gebruikte De Google het onderzoek. Veel mensen worden geconfronteerd met deze kwestie, of variaties van het, maar niemand leek te hebben het opgelost.

Tricksy MOSS verstrekt een gedetailleerde fout die het deed zich niet voor mij om te controleren de 12 korf logboeken. Uiteindelijk, over 24 uur na mijn collega aanbevolen dat ik doen, Ik controleerde de 12 component log en vond dit:

Een uitzondering is opgetreden terwijl het proberen te verwerven van de lokale farm:
System.Security.SecurityException: Toegang tot het gevraagde register is niet toegestaan.
op System.ThrowHelper.ThrowSecurityException(ExceptionResource resource) op Microsoft.Win32.RegistryKey.OpenSubKey(Naam, Boolean beschrijfbare) op Microsoft.Win32.RegistryKey.OpenSubKey(Naam) op Microsoft.SharePoint.Administration.SPConfigurationDatabase.get_RegistryConnectionString() op Microsoft.SharePoint.Administration.SPConfigurationDatabase.get_Local() op Microsoft.SharePoint.Administration.SPFarm.FindLocal(SPFarm& boerderij, Boolean& isJoined)
De Zone van de vergadering die niet was:  MyComputer

Dit opende nieuwe mogelijkheden van het onderzoek, dus was het terug naar de Google. Dat leidde me naar dit forumpost: http://forums.CodeCharge.com/Posts.php?post_id = 67135. Die niet echt helpen me maar het beginnen met het maken me denken was er een database en/of security probleem. Ik was op en Andrew Connell van post ten slotte leverde de gedachte dat ik ervoor moet zorgen dat de account van de identiteit van de groep van toepassingen had passende toegang tot de database. Ik dacht dat het al gedaan. Echter, mijn collega ging en gaf de app zwembad identiteit account volledige toegang tot SQL.

Zodra ze dat wijziging aangebracht, Alles begon te werken.

Wat nu is gebeurd is het beste uitgedrukt als een Haiku gedicht:

Problemen hun handen te verhogen.
U swing en missen. &Opnieuw.
Succes! Maar hoe? Waarom?

She didn't want to dingen laat als dat, de voorkeur aan geven de minimaal vereiste machtiging (en waarschijnlijk met het oog op het schrijven van een blog entry; Ik sloeg haar aan de punch, muhahahahaha!).

Ze verwijderd opeenvolgende machtigingen uit de app zwembad identiteit account tot … Er was niet langer een uitdrukkelijke toestemming voor de app account voor de identiteit van de groep op alle. De webservice blijven werken prima.

We gingen en opnieuw opstarten van de servers. Alles bleef om boete te werken.

Dus, om herhaling: Wij gaven de app identiteit volledige toegang tot het zwembad en vervolgens wegnam. De webservice begonnen en nooit gestopt met werken. Bizarre.

Als iemand weet waarom die moet hebben gewerkt, laat alstublieft een reactie.

</einde>

Ik nodig om te voldoen aan een eis van veiligheid voor een InfoPath-formulier vandaag. In deze zakelijke situatie, een relatief klein aantal individuen zijn toegestaan om te maken een nieuw InfoPath-formulier en een veel breder publiek zijn toegestaan om het te bewerken. (Dit is nieuwe-huren op-boarding formulier gebruikt door personeel dat een werkstroom lanceert).

Om die doelstelling te voldoen, Ik heb gemaakt twee nieuwe machtigingsniveaus gemaakt ("maken en bijwerken" en 'alleen update'), overname voor de formulierbibliotheek brak en machtigingen aan een "maken, bijwerken" gebruiker en een aparte bijwerken"alleen" gebruiker. De mechanica alle werkte, maar het bleek te zijn een beetje meer waarbij dan ik had verwacht. (Als u het gevoel een beetje wankel op SharePoint-machtigingen, Kijk op deze blogpost). De vereiste configuratie voor het machtigingsniveau was niet de duidelijk set Granulaire machtigingen. Een update-alleen machtigingsniveau voor een InfoPath-formulier maken, Ik heb de volgende:

1. Een nieuwe machtigingsniveau maken.
2. Duidelijke weg alle opties.
3. Alleen de volgende "Lijstmachtigingen" geselecteerd:

• Items bewerken
• Items weergeven
• Pagina's bekijken-toepassing

Selecteren van deze opties kan een gebruiker een formulier bijwerken, maar het niet aanmaken.

De truc was om de "pagina met toepassing". Er is verbage op het machtigingsniveau dat wordt aangegeven die is vereist voor update-alleen InfoPath-formulieren, maar blijkt uit het is.

Maken-and-Update was zelfs vreemdeling. Ik volgde de dezelfde stappen, 1 door middel van 3 boven. Ik moest een "Site machtiging specifiek toevoegen" optie: "Gebruik clientfuncties integratie". Weer, de beschrijving er maakt het lijkt alsof het zou moeten zijn vereist voor een InfoPath-formulier niet, maar daar is.

</einde>

UPDATE 01/28/08: Dit codeplex project behandelt deze kwestie: http://www.codeplex.com/AccessChecker. Ik heb het niet gebruikt, maar het ziet er veelbelovend uit als dit is een kwestie die u adres in uw omgeving moet.

UPDATE 11/13/08: Joel Oleson schreef een zeer goede post op de grotere veiligheid bestuurlijke kwestie hier: http://www.sharepointjoel.com/ Lists/Posts/Post.aspx?Lijst = 0cd1a63d % 2D183c % 2D4fc2 %2 D 8320% 2Dba5369008acb&ID = 113. Het verbindt met een aantal andere nuttige middelen.

Forumgebruikers en clients vraag vaak een vraag langs deze lijnen: "Hoe genereer ik een lijst van alle gebruikers met toegang tot een site" of "Hoe kan ik automatisch waarschuwen alle gebruikers met toegang tot de lijst over wijzigingen die in de lijst?"

Er is geen out van de box oplossing voor dit. Als je erover nadenkt voor een moment, het is niet moeilijk te begrijpen waarom.

SharePoint veiligheid is zeer flexibel. Er zijn ten minste vier grote categorieën van gebruikers:

• Anonieme gebruikers.
• SharePoint gebruikers en groepen.
• Active Directory: gebruikers.
• Formulieren gebaseerde verificatie (FBA) gebruikers.

De flexibiliteit betekent dat vanuit een veiligheidsperspectief, een bepaalde SharePoint-site zullen drastisch afwijken van een andere. Oog op het genereren van een access-rapport lijst, Men moet nagaan hoe de site is beveiligd, query meerdere andere gebruiker profiel archieven en vervolgens presenteren op een nuttige wijze. Dat is een moeilijk probleem op te lossen generieke.

Hoe organisaties omgaan met dit? Ik zou graag van u horen in commentaren of E-mail.

</einde>

UPDATE 12/18/07: Zie Paul Liebrand van artikel voor sommige technische gevolgen van het verwijderen of veranderen van de standaard groepsnamen (Zie hieronder zijn commentaar zo goed).

Overzicht:

SharePoint veiligheid is eenvoudig te configureren en beheren. Echter, het heeft bewezen te zijn moeilijk voor sommige beheerders eerst echt hun handen eromheen laten teruglopen. Niet alleen dat, Ik heb sommige beheerders komen tot een perfect begrip op maandag alleen te hebben verloren door vrijdag, omdat ze niet hoefde te doen elke configuratie in de tussenliggende tijd. (Ik geef toe aan het hebben van dit probleem zelf). Deze blog entry hopelijk biedt een nuttig SharePoint veiligheid primer en verwijst naar sommige beveiliging configureren-aanbevolen procedures.

Belangrijke opmerking:

Deze beschrijving is gebaseerd op uit de doos SharePoint veiligheid. Mijn persoonlijke ervaring is gericht rond MOSS zodat er enkele MOSS specifieke dingen hier wellicht, maar ik denk dat het juist voor WSS. Ik hoop dat iedereen zien eventuele fouten of omissies die zal erop wijzen in commentaren of e-mail me. Ik maak correcties post haast.

Grondbeginselen:

Voor de toepassing van dit overzicht, Er zijn vier fundamentele aspecten voor de veiligheid: gebruikers/groepen, beveiligbare objecten, machtigingsniveaus en overerving.

Gebruikers en groepen breken neer:

• Individuele gebruikers: Getrokken uit active directory of gemaakt direct in SharePoint.
• Groepen: Toegewezen rechtstreeks uit active directory of gemaakt in SharePoint. Groepen zijn een verzameling van gebruikers. Groepen zijn globaal in een siteverzameling. Ze zijn nooit "gebonden" voor een bepaald beveiligbaar object.

Beveiligbare objecten breken neer aan ten minste:

• Sites
• Documentbibliotheken
• Afzonderlijke items in lijsten en documentbibliotheken
• Mappen
• Verschillende BDC instellingen.

Er andere beveiligbare objecten, maar je krijgt het beeld.

Machtigingsniveaus: Een bundel van granulaire / lage niveau toegangsrechten die zaken als maken/lezen/verwijderen items in lijsten behoren.

Overname: Standaard overnemen entiteiten beveiligingsinstellingen van hun waarin het andere object. Subsites overnemen machtigingen van hun bovenliggende. Documentbibliotheken overnemen van hun site. Enzovoort enzovoort.

Gebruikers en groepen hebben betrekking op beveiligbare objecten via machtigingsniveaus en overerving.

De belangrijkste veiligheidsvoorschriften te begrijpen, Ever 🙂 :

1. Groepen zijn gewoon verzamelingen van gebruikers.
2. Groepen zijn globale binnen een siteverzameling (dwz. Er is niet zoiets als een groep die wordt gedefinieerd op het niveau van een site).
3. Groepsnaam niet weerstaan, groepen niet, in en van zichzelf, hebben een bepaald niveau van beveiliging.
4. Groepen hebben veiligheid in het kader van een bepaald beveiligbaar object.
5. U kunt verschillende machtigingsniveaus toewijzen aan de dezelfde groep voor elk beveiligbare object.
6. Web toepassingenbeleid troef dit alles (Zie hieronder).

Beveiligingsbeheerders verloren in een zee van groeps- en aanbiedingen kunnen altijd rekenen op deze axioma's te beheren en te begrijpen hun Beveiligingsconfiguratie.

Gemeenschappelijke valkuilen:

• Groepsnamen impliceren ten onrechte toestemming: Out of the box, SharePoint definieert een set van groepen waarvan de namen een inherente beveiligingsniveau impliceren. Beschouwen de groep 'Contributor'. Een onbekend met SharePoint beveiliging kan goed kijken naar die naam en ga ervan uit dat elk lid van die groep kan "bijdragen" op elke site/lijst/bibliotheek in het portaal. Dat mag waar zijn, maar niet omdat de naam van de groep gebeurt te zijn 'contributor'. Dit is alleen waar out of the box, omdat de Fractie heeft gekregen een machtigingsniveau dat hen in staat te toevoegen/bewerken/verwijderen inhoud op de hoofdsite stelt. Via overname, de 'contributies" groep kan ook toevoegen/bewerken/verwijderen inhoud op elke sub site. Een kunt "break" de overervingsketen en wijzig het machtigingsniveau van een dergelijke sub-site dat leden van de zogenaamde 'Contributor" groep niet kan helemaal dragen, maar alleen lezen (bijvoorbeeld). Dit zou niet een goed idee, Uiteraard, omdat het zou erg verwarrend.
• Groepen worden niet gedefinieerd op het niveau van een site. Het is gemakkelijk om worden verward door de user interface. Microsoft biedt een handige koppeling naar gebruiker/groep beheer via elke site "mensen en groepen" koppeling. Het is gemakkelijk om te geloven dat als ik op de site "xyzzy" en ik maak een groep door xyzzy van mensen en groepen koppelen die ik heb zojuist een groep die alleen bestaat bij xyzzy. Dat is niet het geval. Ik heb eigenlijk gemaakt een groep voor de hele siteverzameling.
• Lidmaatschap van groepen verandert niet door site (dwz. het is hetzelfde overal die de groep wordt gebruikt): Beschouwen de groep "eigenaar" en twee sites, "HR" en "Logistics". Het zou normaal te denken dat twee afzonderlijke individuen die sites zou zelf — de eigenaar van een HR en een logistiek. De user interface maakt het gemakkelijk voor een beveiligingsbeheerder behandel dit scenario. Als ik niet beter wist, Ik kan toegang tot de personen en groepen links via de HR-site, Selecteer de "eigenaars" groep en mijn HR-eigenaar aan die groep toevoegen. Een maand later, Logistiek komt op regel. Ik heb toegang tot personen en groepen van de logistieke site, trekken van de "eigenaars toevoegen" groep. Ik zie er de HR-eigenaar en haar verwijderen, denken dat ik ben haar het verwijderen van eigenaars op de logistieke site. Eigenlijk, Ik ben het verwijderen van haar uit de globale groep eigenaren. Hilariteit ontstaat.
• Bij gebreke aan naam groepen op basis van specifieke rol: De fiatteurs"" groep is een perfect voorbeeld. Wat kunnen leden van deze groep goedkeuren? Waar kunnen ze het goedkeuren? Wil ik echt mensen logistieke afdeling voor zitten kundig voor HR documenten goedkeuren? Natuurlijk niet. Altijd naam groepen op basis van hun rol binnen de organisatie. Dit zal verminderen het risico dat de groep een ongepaste machtigingsniveau voor een bepaald beveiligbaar object is toegewezen. Naam groepen op basis van hun beoogde rol. In het vorige scenario van de HR/logistiek, Ik heb twee nieuwe groepen: "HR eigenaren" en logistiek eigenaren"" en verstandige machtigingsniveaus voor elk en het minimale bedrag dat vereist is voor gebruikers om hun werk te doen toewijzen.

Andere nuttige verwijzingen:

• Web toepassing beleid gotcha: http://paulgalvin.spaces.live.com/blog/cns!1CC1EDB3DAA9B8AA!255.entry
• Clearinghouse voor SharePoint beveiliging: http://www.sharepointsecurity.com/
• Links van Joel Oleson: http://blogs.msdn.com/joelo/archive/2007/08/23/sharepoint-security-and-compliance-resources.aspx

Als je dit hebt gemaakt veel:

Gelieve te laten me weten wat uw gedachten via de opmerkingen of e-mail me. Als u weet van andere goede referenties, Doe hetzelfde!