ACTUALITZACIÓ 11/03/08: Sigui segur per llegir el comentari excel lent i detallada de Dessie Lunsford a aquest post.

He estat treballant en un projecte d'edició de secret tech per a un llibre de l'arribada d'alçar i fa referència Aquesta entrada del bloc per Tyler Butler en el blog de gestió del contingut MSDN. Aquesta és la primera vegada personalment vaig llegir una definició clara del significat d'accés limitat. Heus aquí la carn de la definició:

En SharePoint, usuaris anònims’ els drets són determinats per al nivell de permís d'accés limitat. Accés limitat és un nivell de permís especial que no es poden assignar a un usuari o grup directament. La raó és que existeix és perquè si vostè té una biblioteca o sublloc fins que s'ha trencat l'herència de permisos, i li dóna un accés d'usuari o grup a només aquella Biblioteca/sublloc, per tal de visualitzar els seus continguts, l'usuari o grup ha de tenir accés a la web de l'arrel. En cas contrari, l'usuari o grup serà incapaç de mirar la Biblioteca/sublloc, tot i que tenen drets allà, perquè hi ha coses a la web d'arrel que són necessaris per fer que el lloc o la Biblioteca. Per tant, Quan doneu un permisos del grup només d'un sublloc o biblioteca que s'està trencant l'herència de permisos, SharePoint automàticament li donarà accés limitat a aquest grup o d'usuari a la web de l'arrel.

Aquesta pregunta ve cap amunt de tant en tant en els fòrums MSDN i sempre he tingut curiositat (però no suficient curiositat com per entendre això abans d'avui :)).

</final>

Subscriure's al meu blog.

Follow me on Twitter http://www.twitter.com/pagalvin

En un senyal que la Informàtica Social està començant a enlairar-se amb SharePoint, Vaig veure un augment del nombre de preguntes de tipus meu lloc. Una pregunta comuna va alguna cosa com això:

"Sóc un administrador i necessito poder accedir a tots els meus llocs. Com que faig?"

El truc és que cada lloc My és pròpia col·lecció. Seguretat de SharePoint normalment s'administra en el nivell col·lecció lloc i això excursions a molts un administrador de SharePoint. Normalment, ella ja té accés per configurar la seguretat en el principal"" col·leccions del lloc i pot no adonar-se que això no funciona automàticament per als meus llocs.

Col. lectivament en viu dins un contenidor més gran de col·leccions de llocs, Quin és l'aplicació web. Granja administradors poden pot configurar seguretat a nivell de web app i això és com administradors pot concedir-se l'accés a qualsevol col·lecció de llocs en l'aplicació web. Aquesta entrada del bloc descriu una de les meves experiències personals amb normes d'aplicació web. He definit una política d'aplicació web per accident: http://paulgalvin.spaces.live.com/Blog/cns!1CC1EDB3DAA9B8AA!255.entry.

Normes d'aplicació web pot ser perillós i suggereixo que es pot utilitzar amb moderació. Si jo fos un administrador (i gràcies a Déu no estic), Que anava a crear un compte d'anuncis independent anomenat alguna cosa com "Web App administrador de SharePoint" i donar un compte de que la funció de seguretat de aplicació de web que necessita. No puc configurar aquest tipus de coses per administradors del conjunt regular o lloc individual col·lecció administradors. Es tendirà a amagar els problemes potencials perquè el paper de web app substituirà qualsevol configuració de seguretat de nivell inferior.

</final>

Subscriure's al meu blog.

Follow me on Twitter http://www.twitter.com/pagalvin

ACTUALITZACIÓ (02/29/08): Aquest nou projecte de codeplex sembla proporcionar un mètode per assegurar columnes individuals: http://www.codeplex.com/SPListDisplaySetting. Si teniu qualsevol experiència treballant amb ell, Si us plau deixar un comentari.

Cartells fòrum amb freqüència una pregunta com aquesta: "Tinc una visió director i i una visió personal d'una llista. Com segura la vista d'administrador per tal que el personal no es pot utilitzar?"

Ells també amb freqüència una pregunta relacionats: "Vull assegurar una columna de metadades específics per tal que només els gestors poden editar aquesta columna, mentre que altres pot no fins i tot veure-ho."

Aquestes respostes s'aplica a ambdós WSS 3.0 i MOSS:

• SharePoint no proporciona suport d'out-of-the-box per assegurar visites.
• SharePoint no proporciona suport d'out-of-the-box de columnes de seguretat.

Hi ha diverses tècniques podeu seguir per complir amb aquests tipus de requisits de seguretat. Heus aquí el que puc pensar:

• Utilitzar seguretat de nivell d'element de sortida-of-the-box. Vistes sempre respecten la configuració de seguretat de nivell d'element. Auriculars d'esdeveniment i/o flux de treball pot automatitzar l'assignació de seguretat.
• Utilitzar opinions personals per a "el privilegi" vistes. Aquestes són prou fàcils de configurar. No obstant això, a causa de la seva personal"" Natura, Aquests han de ser configurat per a cada usuari. Utilitza la configuració de seguretat estàndard per impedir qualsevol més creant una opinió personal.
• Utilitzar una part de web de visualització de dades i implementar algun tipus de solució d'Estiba de seguretat AJAXy.
• Registre de la seva pròpia funcionalitat d'exhibició de llista i incorporar Estiba de seguretat en el nivell de columna.
• Modificar les formes d'entrada de dades i utilitzar JavaScript en relació amb el model de seguretat per implementar la retallada de la seguretat de nivell de columna.
• Utilitzar un formulari InfoPath per a l'entrada de dades. Retallada de seguretat de nivell de columna mitjançant trucades de servei web del SharePoint i condicional amaga els camps com calgui posar en pràctica.
• Roll el seu propi funció d'entrada de dades d'ASP.NET que implementa la retallada de seguretat de nivell de columna.

Cap d'aquestes opcions no és realment allò gran, però no hi ha com a mínim un camí a seguir si vostè necessita, fins i tot si és difícil.

NOTA: Si se n va algun d'aquests camins, Your say forget about "accions-> Obrir amb Explorador de Windows". Vostè vol estar segur que vostè provar amb aquell tret per assegurar-se que no funciona com una porta del darrere"" i derrotar el seu esquema de seguretat.

Si vostè té altres idees per o experiències amb assegurar columnes o vistes, Si us plau Rebi per email o deixar un comentari i vaig a actualitzar aquest anunci segons s'escaigui.

</final>

Subscriure's al meu blog.

ACTUALITZACIÓ: He publicat aquesta pregunta a MSDN aquí (http://forums.microsoft.com/Forums/ShowPost.aspx?PostID=2808543&SiteID=1&mode=1) i Michael Washam de Microsoft va respondre amb una resposta concisa.

He creat un servei web per actuar com un Façana del BDC amistós a una llista del SharePoint. Quan utilitzava això del meu entorn de desenvolupament, funcionava bé. Quan això migrar a un nou servidor, He trobat aquest error:

Aquí està la línia 69:

utilitzant (Lloc SPSite = SPSite nou("http://localhost/sandbox"))

He provat diferents variacions en l'URL, incloent l'ús de nom real del servidor, la seva adreça IP, barra inclinada final a l'URL, etc. Sempre tenia aquell error.

He utilitzat El Google per investigar-lo. Moltes persones enfronten a aquest problema, o variacions de la mateixa, però ningú semblava tenir-ho resolt.

Tricksy MOSS proporcionat tal una detallada error que no se me per comprovar la 12 rusc de registres. Amb el temps, sobre 24 hores després el meu col lega es recomana que fer-ho, Vaig revisar el 12 rusc de registre i trobava això:

S'ha produït una excepció en intentar adquirir la granja local:
System.Security.SecurityException: Accés registre sol·licitat no està permès.
a System.ThrowHelper.ThrowSecurityException(ExceptionResource recurs) a Microsoft.Win32.RegistryKey.OpenSubKey(Nom de corda, Booleà writable) a Microsoft.Win32.RegistryKey.OpenSubKey(Nom de corda) a Microsoft.SharePoint.Administration.SPConfigurationDatabase.get_RegistryConnectionString() a Microsoft.SharePoint.Administration.SPConfigurationDatabase.get_Local() a Microsoft.SharePoint.Administration.SPFarm.FindLocal(SPFarm& granja, Booleà& isJoined)
La zona de l'Assemblea que no era:  MiPC

Això va obrir noves vies de recerca, Així que va ser a The Google. Que em va portar a aquest correu de fòrum: http://forums.codecharge.com/Posts.php?post_id = 67135. Que realment no ajudar-me però va començar fent-me pensar que hi havia un problema de base de dades i/o seguretat. Jo soldiered i De Andrew Connell publicar finalment ha disparat la idea que jo hauria assegureu-vos que el compte d'identitat del conjunt d'aplicacions tenia accés adequat a la base de dades. Vaig pensar que ja va fer. No obstant això, el meu col lega va anar i va donar l'app piscina identitat compte ple accés a SQL.

Tan aviat com va fer que el canvi, tot va començar a treballar.

El millor és el que va succeir següent expressada com una Haiku poema:

Problemes alça les seves mans.
Vostè swing i es perdi. Torneu.
Èxit! Però, com? Per què?

Ella no volia deixar les coses sola com allò, prefereix donar el permís necessari mínim (i probablement amb un ull escriure una entrada de blog; Em va colpejar a la perforació, muhahahahaha!).

Es va treure els permisos successives del compte identitat app piscina fins … hi havia ja cap permís explícit per al compte d'identitat app piscina gens. El servei web continuar treballant just bé.

Ens vam anar i tornat a arrencar els servidors. Tot va seguir treballant bé.

Així, per recapitular: ens va donar la app piscina identitat accés complet i després va prendre distància. El servei web va començar a treballar i mai no deixà. Estranya.

Si algú sap per què que han treballat, Si us plau deixar un comentari.

</final>

Que necessitava complir amb un requisit de seguretat per a un formulari InfoPath avui. En aquesta situació de negoci, un nombre relativament petit d'individus li permet crear una nova forma de l'InfoPath i un públic molt més ampli que es permeten per editar-lo. (Això és nou-lloguer internats forma utilitzada per recursos humans que llança un flux de treball).

Per complir aquest objectiu, He creat creat dos nous nivells de permís ("crear i actualitzar" i "només actualització"), es va trencar l'herència de la biblioteca forma i assigna permisos per a "crear, Actualització" l'usuari i una actualització independent de"només" l'usuari. La mecànica tot treballat, però va resultar ser una mica més amb la participació del que esperava. (Si et sents una mica inestable en SharePoint permisos, Comprovi aquest correu de blog). La configuració de seguretat requerit per al nivell de permís no era el conjunt de permisos granulars evident. Crear un nivell d'actualització només permís per un formulari InfoPath, Jo vaig fer el següent:

1. Crear un nou nivell de permís.
2. Aclarir totes les opcions.
3. Seleccionats ents de "Permisos de llista":

• Editar elements
• Veure articles
• Veure sol·licitud pàgines

Seleccionar aquestes opcions permet als usuaris actualitzar un formulari, però no crear-lo.

Era el truc per permetre les "pàgines d'aplicació veure". No hi ha cap verbage sobre el nivell de permís que indica que ha requerit per a les formes d'InfoPath només actualització, però resulta que és.

Creació i actualització era encara desconegut. He seguit els mateixos passos, 1 a través de 3 per sobre de. Tenia per específicament afegir un "lloc permís" opció: "Utilitza trets d'integració de client". Una altra vegada, la descripció allà no fa semblar com hauria de ser necessària per a un formulari InfoPath, però no hi és.

</final>

ACTUALITZACIÓ 01/28/08: Aquest projecte codeplex abordi aquesta qüestió: http://www.codeplex.com/AccessChecker. Jo no l'han utilitzat, però es veu prometedor, si aquest és un tema que vostè necessitat d'abordar en el seu entorn.

ACTUALITZACIÓ 11/13/08: Joel Oleson va escriure un post molt bo en el gran tema de gestió de seguretat aquí: http://www.sharepointjoel.com/ Lists/Posts/Post.aspx?Llista = 0cd1a63d % 2D183c % 2D4fc2 %2 D 8320% 2Dba5369008acb&ID = 113. Connecta amb un nombre d'altres recursos útils.

Els usuaris del Fòrum i client sovint fer una pregunta al llarg d'aquestes línies: «Com vaig generar una llista de tots els usuaris amb accés a un lloc" o "com pot jo automàticament avisa tots els usuaris amb accés a la llista sobre els canvis realitzats a la llista?"

No hi ha cap fora de la solució de caixa per a això. Si es pensa en això per un moment, no és difícil entendre per què.

Seguretat de SharePoint és molt flexible. Hi ha almenys quatre grans categories d'usuaris:

• Usuaris anònims.
• Als usuaris del SharePoint i grups.
• Guia Actiu els usuaris.
• Formes basat en l'autenticació (FBA) usuaris.

La flexibilitat vol dir que d'una Perspectiva de seguretat, qualsevol lloc de SharePoint donat serà radicalment diferent de les altres. Per tal de generar un informe de llista d'accés, s'ha de determinar com s'assegura el lloc, Consulta múltiples repositoris de perfil d'usuari diferent i després presentar-lo d'una manera útil. Això és un problema difícil de resoldre genèricament.

Com són les organitzacions tractant amb això? M'encantaria saber de vostè en comentaris o correu electrònic.

</final>

ACTUALITZACIÓ 12/18/07: Veure article de Paul Liebrand algunes conseqüències tècniques de eliminant o modificant els noms de grup per defecte (veure el seu comentari a continuació, així).

Visió de conjunt:

Seguretat de SharePoint és fàcil de configurar i administrar. No obstant això, ha demostrat ser difícil per a alguns administradors primera vegada realment embolicar les seves mans al voltant. No només allò, He vist alguns administradors arribar a una entesa perfecte dilluns a només han perdut per divendres, ja que no cal fer qualsevol configuració en el temps intermedis. (Reconec que té aquest problema jo mateix). Aquesta entrada del blog esperem que proporciona una útil introducció de seguretat de SharePoint i apunta cap a algunes pràctiques millors de configuració de seguretat.

Nota important:

Aquesta descripció es basa de la caixa de seguretat de SharePoint. La meva experiència personal està orientat als voltants molsa perquè hi pot haver alguns molsa matèria específica aquí, però crec que és precís per WSS. Espero que ningú veure errors o omissions a assenyalar que en els comentaris o Rebi per email. Vaig a fer correccions enviar de pressa.

Fonaments:

Als efectes d'aquesta visió de conjunt, hi ha quatre aspectes fonamentals a la seguretat: els usuaris/grups, SecurAble objectes, nivells de permís i l'herència.

Els usuaris i grups trencar a:

• Usuaris individuals: Va treure de l'actiu directori o creades directament en SharePoint.
• Grups: Assignades directament des de l'active directory o creat en SharePoint. Els grups són una col·lecció d'usuaris. Els grups són globals en una col·lecció de llocs. Ells mai "lligat" a un objecte de securable específic.

SecurAble objectes trencar cap avall per com a mínim:

• Llocs
• Biblioteques de documents
• Elements individuals en les llistes i biblioteques de documents
• Carpetes
• Diverses escenes del BDC.

Hi ha altres objectes securable, però apareix el quadre.

Nivells de permís: Un farcell de granular / drets d'accés de nivell baix que inclouen coses com crear/llegir/suprimir entrades de llistes.

L'herència: Per defecte les entitats hereta la configuració de seguretat del seu objecte que conté. Subllocs hereten el permís dels seus pares. Les biblioteques de documents hereta des del seu lloc. Així successivament i així successivament.

Els usuaris i grups relacionar objectes securable mitjançant els nivells de permís i l'herència.

Les normes de seguretat més importants d'entendre, alguna vegada 🙂 :

1. Grups només són col·leccions d'usuaris.
2. Els grups són globals dins d'una col·lecció de llocs (i. e. no hi ha cap tal cosa com a grup definit en l'àmbit de lloc).
3. Nom del grup malgrat les, grups no, a i de si mateixos, tenir qualsevol nivell particular de seguretat.
4. Grups tenir seguretat en el context d'un objecte específic securable.
5. Pot assignar nivells de permís diferent a un mateix grup per a cada objecte de securable.
6. Normes d'aplicació web tot això superen (Vegeu a continuació).

Els administradors de la seguretat perduts en un mar de llistats de grups i usuaris sempre poden confiar en aquests axiomes de gestionar i entendre la seva configuració de seguretat.

Trampes comuns:

• Grup noms falsament implica l'autorització: Fora de la caixa, SharePoint defineix un conjunt dels grups els noms dels quals implica un nivell de seguretat inherent. Considerar el grup "La contribuent". Un desconegut amb seguretat de SharePoint bé pot mirar aquest nom i assumir que qualsevol membre d'aquest grup poden "contribuir" a qualsevol lloc/llista/biblioteca al portal. Això pot ser cert, però no perquè el nom del grup passa a ser "la contribuent". Això només és cert fora de la caixa perquè el grup s'ha proporcionat un nivell de permís que els permet afegir, editar i suprimir contingut en el lloc arrel. Per herència, els col·laboradors"" grup també pot afegir, editar i suprimir contingut en cada sub-lloc. Un pot "trencar" la cadena d'herència i canvi el nivell de permís d'un sub-site que els membres de la anomenada "contribuent" grup no poden aportar res, però només llegir (per exemple). Això no seria una bona idea, Òbviament, des d'aleshores seria molt confús.
• Grups no es defineixen en l'àmbit de lloc. És fàcil confondre per la interfície d'usuari. Microsoft proporciona un enllaç convenient a la gestió de l'usuari/grup a través de "persones i grups de tots els llocs" enllaç. És fàcil creure que quan estic al lloc "xyzzy" i crea un grup a través persones de xyzzy i grups que he creat un grup que només existeix a xyzzy enllaç. Aquest no és el cas. En realitat he creat un grup per a la col·lecció de llocs sencer.
• Membres de grups no varia en el lloc (i. e. és el mateix a tot arreu que el grup s'utilitza): Considerar el "propietari de grup" i dos llocs, "L'H" i "Logística". Seria normal a pensar que els individus separats dos vols propis aquells llocs — un propietari HR i propietari d'una logística. La interfície d'usuari fa que sigui fàcil per a un administrador de seguretat de embalat aquest escenari. Si no saben millor, Puguin accedir a les persones i grups enllaços via el lloc d'HR, Seleccioneu els propietaris"" grup i afegir el meu propietari HR a aquest grup. Un mes més tard, Logística ve en línia. Accedir les persones i grups des del lloc de logística, afegir tiri dels propietaris"" grup. Veig el propietari HR allà i treure-la, pensant que estic traient ella dels propietaris en el lloc de logística. De fet, Jo li estic traient del grup propietaris global. Sobrevé hilaritat.
• Fracassant a grups de nom basat en el paper específic: Els examinadors"" grup és un exemple perfecte. Què pot membres d'aquest aprova grup? On van aprovar-lo? Realment vull Departament de logística de gent per poder aprovar els documents de HR? Per descomptat no. Sempre nom basats en el seu paper dins l'organització de grups. Això reduirà el risc que el grup té assignat un nivell de permís inadequat per a un determinat objecte securable. Grups de nom basats en el seu paper destinat. En el cas anterior HR/logística, He ha creat dos nous grups: "HR propietaris" i "logística propietaris" i assignar els nivells de permís sensible per a cada un i l'import mínim necessari per a aquells usuaris a fer la seva feina.

Altres referències útils:

• Web aplicació política gotcha: http://paulgalvin.spaces.live.com/blog/cns!1CC1EDB3DAA9B8AA!255.entry
• Centre d'informació per a la seguretat del SharePoint: http://www.sharepointsecurity.com/
• Enllaços de Joel Oleson: http://blogs.msdn.com/joelo/archive/2007/08/23/sharepoint-security-and-compliance-resources.aspx

Si ho heu fet això molt:

Si us plau deixi'm saber els seus pensaments mitjançant els comentaris o email. Si coneixeu altres bones referències, Si us plau, fer el mateix!