Actualización 11/03/08: Asegúrese de ler o comentario excelente e detallada de Dessie Lunsford a este post.

Eu estou traballando nun proxecto de edición segredo da tecnoloxía para un libro de up a benvida e fai referencia este blog por Tyler Butler no blog de ECM MSDN. This is the first time I personally read a clear definition of the meaning of Limited Access. Here’s the meat of the definition:

O SharePoint, usuarios anónimos’ dereitos son determinados polo nivel de permiso acceso limitado. Acceso limitado e un nivel de permiso especial que non pode ser atribuído a un usuario ou grupo directamente. A razón pola que existe é porque se ten unha biblioteca ou un subsite que quebrar a herdanza de permisos, e dá acceso a un usuario / grupo para só esa biblioteca / subsite, a fin de ver o seu contido, o usuario / grupo debe ter un acceso á web raíz. Se non, o usuario / grupo non serán capaces de navegar pola biblioteca / subsite, a pesar de teren dereitos non, porque hai cousas na web raíz que son necesarios para facer o sitio web ou biblioteca. Polo tanto, Cando lle dá un permisos de grupo só para un subsite ou biblioteca que está rompendo a herdanza de permisos, SharePoint ha automaticamente dar acceso limitado a ese grupo ou usuario na web raíz.

Esta cuestión vén á tona momento e entón nos foros do MSDN e eu sempre fun curioso (pero non curioso o suficiente para descubrir iso antes de hoxe :)).

</final>

Rexístrate para o meu blog.

Siga-me no Twitter http://www.twitter.com/pagalvin

Un sinal de que Social Computing está empezando a despegar co SharePoint, I see an increased number of My Site type questions. One common question goes something like this:

"I am an administrator and I need to be able to access every My Site. How do I do that?"

The trick here is that each My Site is its own site collection. SharePoint security is normally administered at the site collection level and this trips up many a SharePoint administrator. Normalmente, ela xa ten acceso para configurar a seguridade no principal "" conxuntos de sitios web e pode non entender que iso non funciona automaticamente para meus sitios.

Conxuntos de sitios colectivamente vivir dentro dun recipiente máis grande, which is the web application. Farm admins can can configure security at the web app level and this is how admins can grant themselves access to any site collection in the web application. This blog entry describes one of my personal experiences with web application policies. I defined a web application policy by accident: http://paulgalvin.spaces.live.com/Blog/cns!1CC1EDB3DAA9B8AA!255.entry.

Web application policies can be dangerous and I suggest that they be used sparingly. If I were an admin (e grazas a Deus non son), Quere crear unha conta de AD separado chamado algo así como "SharePoint Web App administrador" and give that one account the web application security role it needs. I would not configure this kind of thing for the regular farm admin or individual site collection admins. It will tend to hide potential problems because the web app role overrides any lower level security settings.

</final>

Rexístrate para o meu blog.

Siga-me no Twitter http://www.twitter.com/pagalvin

Actualización (02/29/08): Este novo proxecto codeplex parece proporcionar un método para fixar columnas individuais: http://www.codeplex.com/SPListDisplaySetting. If you have any experience working with it, por favor, deixe un comentario.

Carteis foro a miúdo unha pregunta como esta: "I have a manager view and and a staff view of a list. How do I secure the manager view so that staff can not use it?"

Tamén a miúdo unha pregunta relacionada: "Quero garantir unha columna de metadatos específico para que os xestores só hai esa columna, mentres que outros non poden sequera velo."

These answers apply to both WSS 3.0 e Moss:

• SharePoint non ofrecen out-of-the-box soporte para fixar puntos de vista.
• SharePoint non ofrecen out-of-the-box soporte para columnas de seguridade.

There are several techniques one can follow to meet these kinds of security requirements. Here’s what I can think of:

• Use out-of-the-box item level security. Views always honor item level security configuration. Event receivers and/or workflow can automate security assignment.
• Use puntos de vista persoais para "privilexiado" views. These are easy enough to set up. Con todo, debido ao seu "persoal" natureza, these need to be configured for each user. Use standard security configuration to prevent anyone else from creating a personal view.
• Use un Data View web Part e aplicar algún tipo de AJAXy solución de seguridade de corte.
• Roll súa propia función de exhibición lista e incorporar o apareza de seguridade no nivel da columna.
• Modificar as formas de entrada de datos e usar JavaScript xunto co modelo de seguridade a aplicar a nivel de columna de eliminación de seguridade.
• Use an InfoPath form for data entry. Implement column-level security trimming via web service calls to SharePoint and conditionally hide fields as needed.
• Roll seu propio ASP.NET función de entrada de datos que aplica a seguridade a nivel de columna de corte.

Ningunha destas opcións son realmente moi grande, pero hai polo menos un camiño a seguir, se precisa, aínda que sexa difícil.

NOTA: Se vai para abaixo calquera destes camiños, non se esqueza de "Accións -> Open with Windows Explorer". You want to be sure that you test with that feature to make sure that it doesn’t work as a "back door" e derrotar ao seu esquema de seguridade.

Se ten outras ideas e experiencias para con columnas de agarre ou vistas, por favor enviar correo-e me ou deixe un comentario e eu vou actualizar esta mensaxe, segundo corresponda.

</final>

Rexístrate para o meu blog.

Actualización: Poño esta pregunta para MSDN aquí (http://forums.microsoft.com/Forums/ShowPost.aspx?PostID=2808543&SiteID=1&mode=1) and Michael Washam of Microsoft responded with a concise answer.

Eu creei un servizo web para actuar como un Fachada BDC-friendly to a SharePoint list. When I used this from my development environment, funcionou moi ben. Cando migrei este para un novo servidor, Eu atopei este erro:

Aquí é a liña 69:

utilización (Lugar SPSite = new SPSite("http://localhost/sandbox"))

Intento varias variacións sobre a URL, ata usar o nome real do servidor, o seu enderezo IP, barra ao final da URL, etc. I always got that error.

Eu soía Google to research it. Lots of people face this issue, ou variacións dela, pero ninguén parecía telo resolto.

Tricksy Moss solicitado un erro tan detallado que non se me ocorreu para comprobar o 12 hive logs. Eventualmente, sobre 24 horas despois meu compañeiro recomenda-me facelo, Eu comproba o 12 rexistro colmea e atopei este:

Unha excepción ocorreu durante o intento de adquirir a facenda local:
System.Security.SecurityException: Acceso ao rexistro solicitado non se admite.
en System.ThrowHelper.ThrowSecurityException(ExceptionResource recurso) en
(String nome, Booleana gravable) en
(String nome) en
() en
() en
(SPFarm& Facenda, Booleana& isJoined)
A Zona da assembly que non foi:  MyComputer

Isto abriu novos camiños de investigación, polo que estaba de volta a Google. Isto levoume a este foro post: http://forums.codecharge.com / posts.php?post_id = 67135. That didn’t really help me but it did start making me think there was a database and/or security issue. I soldiered on and Andrew Connell de post finally triggered the thought that I should make sure that the application pool’s identity account had appropriate access to the database. I thought it already did. Con todo, meu compañeiro foi e deu o app conta de identidade do pool acceso total ao SQL.

Así que fixo ese cambio, everything started working.

O que pasou despois é mellor expresada como un haiku poema:

Problemas levantar as mans.
You swing and miss. Try again.
Éxito! But how? ¿Por que?

Ela non quería deixar as cousas só, como que, preferindo dar permiso mínima necesaria (e, probablemente, con un ollo para escribir un post no blog; Eu batía nela co zócalo, muhahahahaha!).

Ela eliminou os permisos sucesivas da súa conta de identidade do pool de aplicacións ata … there was no longer any explicit permission for the app pool identity account at all. The web service continued to work just fine.

We went and rebooted the servers. Everything continued to work fine.

Así, para recapitular: we gave the app pool identity full access and then took it away. The web service started working and never stopped working. Bizarre.

Se alguén sabe por que isto debería funcionar, por favor, deixe un comentario.

</final>

I needed to meet a security requirement for an InfoPath form today. In this business situation, a relatively small number of individuals are allowed to create a new InfoPath form and a much wider audience are allowed to edit it. (Esta é a nova contratación en boarding forma utilizada pola área de recursos humanos, que lanza un fluxo de traballo).

Para alcanzar este obxectivo, Eu creei creou dous novos niveis de permiso ("create and update" and "update only"), broke inheritance for the form library and assigned permissions to a "create, actualizar" user and a separate "update only" usuario. The mechanics all worked, but it turned out to be a little more involving than I expected. (If you feel a little shaky on SharePoint permissions, check out this blog post). The required security configuration for the permission level was not the obvious set of granular permissions. To create an update-only permission level for an InfoPath form, Eu fixen o seguinte:

1. Create a new permission level.
2. Clear away all options.
3. Selected only the following from "List permissions":

• Edit Items
• View Items
• View Application Pages

Selecting these options allows a user to update a form, but not create it.

The trick was to enable the "View Application Pages". There isn’t any verbage on the permission level that indicates that’s required for update-only InfoPath forms, but turns out it is.

Create-and-Update was even stranger. I followed the same steps, 1 through 3 arriba. I had to specifically add a "Site Permission" option: "Use client integration features". De novo, the description there does not make it seem like it ought to be required for an InfoPath form, but there it is.

</final>

Actualización 01/28/08: Este proxecto codeplex aborda esta cuestión: http://www.codeplex.com/AccessChecker. I have not used it, pero parece prometedor se este é un problema que ten que resolver no seu ambiente.

Actualización 11/13/08: Joel Oleson escribiu un post moi bo sobre o maior problema de xestión de seguridade aquí: http://www.sharepointjoel.com / Guías / artigos / Post.aspx?List = 0cd1a63d% 2D183c% 2D4fc2% 2D8320% 2Dba5369008acb&ID = 113. It links to a number of other useful resources.

Os usuarios do foro e clientes moitas veces facer unha pregunta ó longo destas liñas: "How do I generate a list of all users with access to a site" or "How can I automatically alert all users with access to list about changes made to the list?"

There is no out of the box solution for this. If you think about it for a moment, non é difícil entender por que.

SharePoint security is very flexible. There are at least four major categories of users:

• Usuarios anónimos.
• SharePoint Usuarios e Grupos.
• Usuarios do Active Directory.
• Forms Based Authentication (FBA) usuarios.

A flexibilidade significa que a partir dunha perspectiva de seguridade, any given SharePoint site will be dramatically different from another. In order to generate an access list report, hai que comprobar como o sitio é protexido, query multiple different user profile repositories and then present it in a useful fashion. That’s a hard problem to solve generically.

Como as organizacións están lidando con esta? I’d love to hear from you in comments or e-mail.

</final>

Actualización 12/18/07: Ver o artigo de Paul Liebrand para algunhas consecuencias técnicas de eliminar ou modificar os nomes de grupos estándar (ver o seu comentario a continuación, así).

Visión global:

SharePoint security is easy to configure and manage. Con todo, it has proven to be difficult for some first-time administrators to really wrap their hands around it. Not only that, I have seen some administrators come to a perfect understanding on Monday only to have lost it by Friday because they didn’t have to do any configuration in the intervening time. (Eu admite a ter este problema me). This blog entry hopefully provides a useful SharePoint security primer and points towards some security configuration best practices.

Nota importante:

This description is based on out of the box SharePoint security. My personal experience is oriented around MOSS so there may be some MOSS specific stuff here, but I believe it’s accurate for WSS. I hope that anyone seeing any errors or omissions will point that out in comments or enviar correo-e me. I’ll make corrections post haste.

Fundamentos:

Aos efectos da presente Resumo, existen catro aspectos fundamentais para a seguridade: usuarios / grupos, obxectos que poden ser protexidos, niveis de permisos e de herdanza.

Usuarios e Grupos quebran-se en:

• Os usuarios individuais: Tirado do Active Directory ou creado directamente no SharePoint.
• Grupos: Mapped directly from active directory or created in SharePoint. Groups are a collection of users. Groups are global in a site collection. They are never "tied" a un obxecto específico protexido.

Obxectos que poden ser protexidos romper a polo menos:

• Sitios
• As bibliotecas de documentos
• Elementos individuais en listas e bibliotecas de documentos
• Cartafois
• Varias opcións BDC.

Existen outros obxectos que poden ser protexidos, pero comeza a foto.

Os niveis de permiso: Un feixe de granular / low level access rights that include such things as create/read/delete entries in lists.

Herdanza: By default entities inherit security settings from their containing object. Sub-sites inherit permission from their parent. Document libraries inherit from their site. So on and so forth.

Usuarios e grupos se relacionan con obxectos que poden ser protexidos a través de niveis de permiso e de herdanza.

Os máis importantes Normas de Seguridade para entender, Ever 🙂 :

1. Os grupos son simplemente coleccións de usuarios.
2. Grupos son globais dentro dun conxunto de sitios web (i.e. non hai tal cousa como un grupo definido a nivel local).
3. Nome do grupo non resistir, grupos non facer, en si, have any particular level of security.
4. Groups have security in the context of a specific securable object.
5. Pode asignar niveis de permiso diferentes para o mesmo grupo para cada obxecto protexido.
6. Aplicación web políticas trunfo todo isto (mira abaixo).

Os administradores de seguridade perdidas nun mar de grupo e lista de usuarios poderá contar con estes axiomas para xestionar e entender a súa configuración de seguridade.

Problemas comúns:

• Os nomes dos grupos implicar falsamente permiso: Fóra da caixa, SharePoint defines a set of groups whose names imply an inherent level of security. Consider the group "Contributor". One unfamiliar with SharePoint security may well look at that name and assume that any member of that group can "contribute" to any site/list/library in the portal. That may be true but not because the group’s name happens to be "contributor". This is only true out of the box because the group has been provided a permission level that enables them to add/edit/delete content at the root site. Through inheritance, the "contributors" group may also add/edit/delete content at every sub-site. One can "break" the inheritance chain and change the permission level of a sub-site such that members of the so-called "Contributor" grupo non pode contribuír en todo, pero só ler (por exemplo). This would not be a good idea, obviamente, xa que sería moi confuso.
• Os grupos non son definidos a nivel local. It’s easy to be confused by the user interface. Microsoft provides a convenient link to user/group management via every site’s "People and Groups" ligazón. It’s easy to believe that when I’m at site "xyzzy" and I create a group through xyzzy’s People and Groups link that I’ve just created a group that only exists at xyzzy. That is not the case. I’ve actually created a group for the whole site collection.
• Grupos de adhesión non varía pola web (i.e. é a mesma en todas partes do grupo se usa): Consider the group "Owner" e dous locais, "HR" and "Logistics". It would be normal to think that two separate individuals would own those sites — an HR owner and a Logistics owner. The user interface makes it easy for a security administrator to mishandle this scenario. If I didn’t know better, Eu podería acceder as persoas e con grupos a través da web de RH, select the "Owners" group and add my HR owner to that group. A month later, Logistics comes on line. I access People and Groups from the Logistics site, add pull up the "Owners" group. I see the HR owner there and remove her, thinking that I’m removing her from Owners at the Logistics site. En realidade, I’m removing her from the global Owners group. Hilarity ensues.
• Deixar de citar grupos baseados en papel específico: The "Approvers" group is a perfect example. What can members of this group approve? Where can they approve it? Do I really want people Logistics department to be able to approve HR documents? Of course not. Always name groups based on their role within the organization. This will reduce the risk that the group is assigned an inappropriate permission level for a particular securable object. Name groups based on their intended role. In the previous HR/Logistics scenario, Eu debería crear dous novos grupos: "HR Owners" and "Logistics Owners" e asignar niveis de permiso por cada cordas e ao importe mínimo esixido para os usuarios fagan o seu traballo.

Outras referencias útiles:

• Web aplicación política Gotcha: http://paulgalvin.spaces.live.com/blog/cns!1CC1EDB3DAA9B8AA!255.entry
• Cámara de seguridade do SharePoint: http://www.sharepointsecurity.com/
• Ligazóns de Joel Oleson: http://blogs.msdn.com/joelo/archive/2007/08/23/sharepoint-security-and-compliance-resources.aspx

Se chegou aquí:

Please let me know your thoughts via the comments or email me. If you know other good references, faga o mesmo!