UPDATE 11/03/08: Kuwa na uhakika wa kusoma maoni bora na ya kina kutoka Dessie Lunsford kwa post hii.

Nimekuwa kazi katika mradi siri tech editing kwa kitabu juu-kuja na marejeo ni kuingia hii blog na Tyler Butler MSDN ECM blog. This is the first time I personally read a clear definition of the meaning of Limited Access. Here’s the meat of the definition:

Katika SharePoint, watumiaji bila majina’ haki ni kuamua na ngazi Limited Kupata ruhusa. Upatikanaji mdogo ni maalum ruhusa ngazi ya kwamba hawezi kuwa kwa ajili ya mtumiaji au kundi moja kwa moja. sababu ipo ni kwa sababu kama una maktaba au subsite kwamba amevunja urithi ruhusa, na kutoa huduma ya mtumiaji / kikundi tu kwamba maktaba / subsite, ili kuona yaliyomo yake, mtumiaji / kundi lazima kuwa na baadhi ya upatikanaji wa mtandao mizizi. Vinginevyo mtumiaji / kikundi hawataweza kuvinjari maktaba / subsite, ingawa wao wana haki kuna, sababu kuna mambo katika mtandao mizizi ambazo zinahitajika atatoa tovuti au maktaba. Kwa hiyo, wakati kutoa ruhusa kundi pekee subsite au maktaba ya kwamba ni kuvunja urithi ruhusa, SharePoint moja kwa moja kutoa Access Limited kwa kuwa kundi au mtumiaji kwenye mtandao mizizi.

Swali hili anakuja juu sasa na kisha kwenye vikao MSDN na nimekuwa daima imekuwa curious (lakini si curious kutosha kufikiri nje kabla ya leo :)).

</mwisho>

Kujiunga na blog yangu.

Kufuata yangu juu ya Twitter kwa http://www.twitter.com/pagalvin

Katika ishara kwamba Computing kijamii ni mwanzo wa kuchukua mbali na 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. Kawaida, she already has access to configure security in the "main" tovuti makusanyo na wanaweza kutambua kwamba hii haina moja kwa moja kazi kwa Tovuti Yangu.

Tovuti makusanyo pamoja kuishi ndani ya chombo kikubwa, 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 (na kuwashukuru wema mimi si), I would create a separate AD account named something like "SharePoint Web App Administrator" 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.

</mwisho>

Kujiunga na blog yangu.

Kufuata yangu juu ya Twitter kwa http://www.twitter.com/pagalvin

UPDATE (02/29/08): Hii mpya codeplex mradi inaonekana kutoa njia kwa ajili ya kupata nguzo ya mtu binafsi: http://www.codeplex.com/SPListDisplaySetting. If you have any experience working with it, tafadhali acha maoni.

Forum mabango ya mara kwa mara kuuliza swali kama hili: "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?"

They also frequently ask a related question: "I want to secure a specific metadata column so that only managers may edit that column while others may not even see it."

These answers apply to both WSS 3.0 na MOSS:

• SharePoint does not provide out-of-the-box support for securing views.
• SharePoint does not provide out-of-the-box support for security columns.

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 personal views for "privileged" maoni. These are easy enough to set up. Hata hivyo, due to their "personal" nature, these need to be configured for each user. Use standard security configuration to prevent anyone else from creating a personal view.
• Use a data view web part and implement some kind of AJAXy security trimming solution.
• Roll your own list display functionality and incorporate security trimming at the column level.
• Modify the data entry forms and use JavaScript in conjunction with the security model to implement column-level security trimming.
• 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 your own ASP.NET data entry function that implements column level security trimming.

None of those options are really that great, but there is at least a path to follow if you need to, even if it’s hard.

NOTE: If you go down any of these paths, don’t forget about "Actions -> 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" and defeat your security scheme.

If you have other ideas for or experiences with securing columns or views, please email yangu or leave a comment and I’ll update this posting as appropriate.

</mwisho>

Kujiunga na blog yangu.

UPDATE: I posted swali hili kwa MSDN hapa (http://forums.microsoft.com/Forums/ShowPost.aspx?PostID=2808543&SiteID=1&mode=1) and Michael Washam of Microsoft responded with a concise answer.

Mimi umba huduma ya mtandao wa kutenda kama BDC-kirafiki facade to a SharePoint list. When I used this from my development environment, ni kazi nzuri. Wakati mimi alihamia hii server mpya, Mimi wamekutana kosa hili:

Hapa ni mstari 69:

kutumia (SPSite tovuti = mpya SPSite("http://localhost/sandbox"))

Nilijaribu tofauti tofauti juu ya URL, ikiwa ni pamoja na kutumia seva jina halisi, anwani yake ya IP, trailing mikwaju juu ya URL, nk. I always got that error.

Nilikuwa Google to research it. Lots of people face this issue, au tofauti yake, lakini hakuna mtu walionekana kuwa ni kutatuliwa.

Tricksy MOSS zinazotolewa kosa vile kina kwamba hakuwa kutokea kwangu kuangalia 12 hive logs. Hatimaye, kuhusu 24 baada ya masaa yangu mwenzake ilipendekeza mimi kufanya hivyo, I checked nje 12 mzinga logi na kupatikana hii:

ubaguzi ilitokea wakati wa kujaribu kupata shamba la mtaa:
System.Security.SecurityException: Tafsiri upatikanaji Msajili haruhusiwi.
saa System.ThrowHelper.ThrowSecurityException(ExceptionResource rasilimali) katika
(Kamba jina, Boolean writable) katika
(Kamba jina) katika
() katika
() katika
(SPFarm& kilimo, Boolean& isJoined)
Kanda ya mkutano kwamba wameshindwa mara:  MyComputer

Hii kufunguliwa fursa mpya ya utafiti, hivyo ilikuwa nyuma ya Google. Kwamba aliniongoza hii jukwaa baada ya: http://forums.codecharge.com / posts.php?post_id = 67,135. 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 ya 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. Hata hivyo, mwenzangu akaenda akawapa pool programu utambulisho akaunti kamili upatikanaji wa SQL.

Haraka kama yeye alifanya kwamba mabadiliko, everything started working.

Kilichotokea ijayo ni bora walionyesha kama haiku shairi:

Matatizo ya kuinua mikono yao.
You swing and miss. Try again.
Mafanikio! But how? Kwa nini?

Yeye hakutaka kuacha mambo peke yake kama kwamba, wakipendelea kutoa kima cha chini cha required ruhusa (na pengine kwa jicho kwa kuandika kuingia blog; Mimi kuwapiga wake Punch, muhahahahaha!).

Yeye kuondolewa ruhusa mfululizo kutoka akaunti ya programu pool utambulisho mpaka … 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.

Hivyo, kwa kurejea: we gave the app pool identity full access and then took it away. The web service started working and never stopped working. Bizarre.

Kama mtu anajua kwa nini kwamba wanapaswa kuwa na kazi, tafadhali acha maoni.

</mwisho>

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. (Hii ni mpya-kuajiri juu-bweni fomu kutumiwa na Rasilimali kwamba yazindua workflow).

Kufikia lengo, Mimi umba kuundwa mbili ngazi ruhusa mpya ("create and update" and "update only"), broke inheritance for the form library and assigned permissions to a "create, update" user and a separate "update only" mtumiaji. The mechanics all worked, but it turned out to be a little more involving than I expected. (Kama wewe kujisikia shaky kidogo juu ya SharePoint ruhusa, angalia hii baada ya blog). 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, Nilifanya zifuatazo:

1. Kujenga mpya ruhusa ngazi.
2. Wazi mbali chaguzi zote.
3. Selected only the following from "List permissions":

• Hariri Items
• View Items
• View za Maombi

Kuchagua njia hizo inaruhusu mtumiaji update fomu, lakini si kujenga.

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, lakini zinageuka ni.

Create-and-Update was even stranger. I followed the same steps, 1 kupitia 3 juu ya. I had to specifically add a "Site Permission" chaguo: "Use client integration features". Tena, maelezo kuna haina kufanya hivyo kuonekana kama inavyopaswa zinazohitajika kwa ajili ya fomu InfoPath, lakini kuna ni.

</mwisho>

UPDATE 01/28/08: Mradi huu codeplex anwani suala hili: http://www.codeplex.com/AccessChecker. I have not used it, lakini inaonekana kuahidi kama hili ni suala unahitaji kushughulikia katika mazingira yako.

UPDATE 11/13/08: Joel Oleson aliandika juu ya post nzuri sana juu ya suala kubwa usimamizi wa usalama hapa: http://www.sharepointjoel.com / Lists / Posts / Post.aspx?List=0cd1a63d-183c-4fc2-8320-ba5369008acb&ID=113. It links to a number of other useful resources.

Forum users and clients often ask a question along these lines: "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, it’s not hard to understand why.

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

• Anonymous users.
• SharePoint Users and Groups.
• Active Directory users.
• Hutengeneza Uthibitishaji Based (FBA) watumiaji.

The flexibility means that from a security perspective, any given SharePoint site will be dramatically different from another. In order to generate an access list report, one needs to ascertain how the site is secured, query multiple different user profile repositories and then present it in a useful fashion. That’s a hard problem to solve generically.

How are organizations dealing with this? I’d love to hear from you in comments or email.

</mwisho>

UPDATE 12/18/07: Angalia makala Paulo Liebrand kwa ajili ya madhara ya baadhi ya kiufundi ya kuondoa au kubadilisha majina kundi default (kuona maoni yake hapa chini pamoja na).

Overview:

SharePoint security is easy to configure and manage. Hata hivyo, 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. (Mimi kukubali kwa kuwa tatizo hili mimi mwenyewe). This blog entry hopefully provides a useful SharePoint security primer and points towards some security configuration best practices.

Muhimu Kumbuka:

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 email yangu. I’ll make corrections post haste.

Misingi:

Kwa madhumuni ya muhtasari huu, kuna nne kimsingi masuala ya usalama: watumiaji / vikundi, securable vitu, ruhusa ngazi na urithi.

Watumiaji na Vikundi kuvunja chini kwa:

• Mtu binafsi watumiaji: Vunjwa kutoka saraka ya kazi au kuundwa moja kwa moja katika SharePoint.
• Vikundi: 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" na kitu maalum securable.

Securable vitu kuvunja kwa angalau:

• Maeneo ya
• Kudhibiti maktaba
• Mtu binafsi vitu katika orodha na maktaba hati
• Folders
• Mbalimbali BDC mazingira.

Kuna wengine securable vitu, lakini unaweza kupata picha.

Ruhusa ngazi: mzigo wa punjepunje / low level access rights that include such things as create/read/delete entries in lists.

Urithi: 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.

Watumiaji na vikundi yanahusiana na vitu securable kupitia ngazi ruhusa na urithi.

Muhimu Usalama Rules Kuelewa, Ever 🙂 :

1. Vikundi ni tu makusanyo ya watumiaji.
2. Vikundi ni wa kimataifa ndani ya ukusanyaji tovuti (i.e. hakuna kitu kama kundi maalum katika ngazi ya tovuti).
3. Kundi jina bila kuzingatia, vikundi hawana, katika na wenyewe, have any particular level of security.
4. Groups have security in the context of a specific securable object.
5. Unaweza hawawajui ngazi mbalimbali ruhusa kwa kikundi kimoja kwa kila kitu securable.
6. Mtandao maombi ya sera mbiu ya yote haya (angalia hapa chini).

Usalama watendaji waliopotea katika bahari ya kundi na nyimbo mtumiaji anaweza daima kutegemea imani za hawa kusimamia na kuelewa usalama wao Configuration.

Kawaida Pitfalls:

• Kundi majina ya uongo kuashiria ruhusa: Nje ya boksi, 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" kundi hawawezi kuchangia wakati wote, lakini tu kusoma (kwa mfano). This would not be a good idea, wazi, tangu itakuwa utata sana.
• Vikundi si hufafanuliwa katika ngazi ya tovuti. 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" kiungo. 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.
• Vikundi vya jumla haina kutofautiana na tovuti (i.e. ni sawa kila mahali kundi ni kutumika): Consider the group "Owner" na maeneo mawili, "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, Mimi ili kupata Watu na viungo Vikundi kupitia tovuti ya Utumishi, 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. Kwa kweli, I’m removing her from the global Owners group. Hilarity ensues.
• Kushindwa kwa jina makundi ya msingi ya jukumu maalum: 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, Mimi lazima tumemuumba makundi mawili mpya: "HR Owners" and "Logistics Owners" na kuwapa ruhusa ngazi busara kwa kila mmoja na kiasi cha chini zinazohitajika kwa watumiaji hao kufanya kazi zao.

Nyingine muhimu Marejeo:

• Mtandao maombi ya sera ya gotcha: http://paulgalvin.spaces.live.com/blog/cns!1CC1EDB3DAA9B8AA!255.entry
• Clearinghouse kwa SharePoint usalama: http://www.sharepointsecurity.com/
• Viungo kutoka Joel Oleson: http://blogs.msdn.com/joelo/archive/2007/08/23/sharepoint-security-and-compliance-resources.aspx

Kama wameweza kuifanya hii mbali:

Please let me know your thoughts via the comments or email me. If you know other good references, tafadhali kufanya hivyo!