Категория Архиви: Защита на SharePoint

"Отказан достъп” за да Default.aspx на SharePoint 2010 Подсайт

Един от моите клиенти е живо с техните SharePoint 2010 Днес среда.  Ние открих, че определена група от потребители не можа да имат достъп до началната страница им по подразбиране.  SharePoint отговори с "Достъпът е отказан" и обичайните "влизане като друг потребител" или "иска достъп" отговор. 

Когато ние използва функцията "Проверка на достъп" изпипана потвърждава, че крайните потребители наистина имат достъп.  Още, те не могат да стигнете до страницата.

Проследих много от пътища до различни краища на мъртви, докато аз реших да сравните на уеб части на счупени страница срещу подобна работна страница.  Направих, поставяйки на страницата в режим на поддръжка чрез добавяне на"?съдържание = 1 "на страницата. Така, тя изглеждала по "http://Server/subsite/subsite/default.aspx?съдържание = 1 ". 

Това ми показа две web части, наречена "Грешка" с описание като "Грешка" на счупени страница.  Аз не мисля, за да се калпаче екрана по време.

Аз ги премахнат и че решават проблема.

Съм виждал въпрос като този по време на на форумите в миналото и аз бях изключително скептични относно плакат настояване, че той е защита, настроено правилно.  Аз ° знам ° имах защита нагоре и надясно Усмивка  Следващия път, Ще ви бъда по-отворен и по-малко скептични.

</край>

Абонирайте се за моя блог.

Следвайте ме на Twitter в http://www.twitter.com/pagalvin

Използвате работен поток, за да симулирате тип съдържание сигурност

Друг ден, друг MSDN-форуми вдъхновени пост.

Някой питаше дали може да осигури тип съдържание, така че когато потребителят щракне върху бутона "нов" на списък по избор, само типовете съдържание, за които това лице е предоставен достъп ще се появяват в падащия списък.  Както знаем, Това не се поддържа от кутията.

Този въпрос сега и тогава и този път, Имах една нова идея.  Да предположим, че имаме сценарий като този:

  • Имаме helpdesk билети система.
  • Helpdesk билети система позволява на потребителите да въвеждат редовни helpdesk билет информация, като проблемна област, състояние на проблема, н.
  • Ние искаме да се позволи на "супер" потребителите да зададете полето "спешност".
  • Другите потребители нямат достъп до това поле.  Системата винаги ще присвои "средно" ниво приоритет на исканията им.

Какво можем да направим е да създадете две отделни списъци на SharePoint и две различни типове съдържание, един за "супер" потребители и за всички останали.

Работният поток на всеки списък копира данните в главния списък (действителната helpdesk билет списък) и този процес продължава от там.

Този подход може да работи един вид на колоната ниво на сигурност както и се вливат. 

Не съм опитвал, но тя се чувства разумно и дава доста прости, Ако е доста груба, възможност за реализиране на тип съдържание и дори колоната ниво на сигурност.

</край>

Абонирайте се за моя блог.

Следвайте ме на Twitter в http://www.twitter.com/pagalvin

Одобрение на съдържание като сиромаха автоматично елемент ниво на сигурност

Има един общ бизнес сценарий с формуляри на InfoPath.  Ние искаме позволяват на хората да попълват формуляри на InfoPath и да ги представят в библиотека.  Ние искаме мениджъри (и никой друг) да имат достъп до тези формуляри.

Този въпрос идва сега и след това върху формулярите (e.g. http://social.technet.microsoft.com/Forums/en-US/sharepointadmin/thread/76ccef5a-d71c-4b7c-963c-613157e2a966/?prof=required)

Бърз начин за решаване на това е да се разреши одобрението на съдържание за библиотеката с формуляри.  Отидете на библиотеката версия настройки и поставям то горе както е показано:

image 

Щракнете върху "Изисква одобрение на съдържание" и това ще ви позволи да изберете стойност за защита на елемент чернова.

Това е малко контра-интуитивен защото не мислим по отношение на "одобрение на съдържание" когато всички ние искаме да направим е да пречат на хората да виждат другите потребители форми.  Въпреки това, Тя работи добре (в моя опит).  Просто не одобрява тези формуляри и те винаги ще се считат за "Чернови". 

Дава одобрение права на хората, които трябва да могат да ги видят и вие сте затворен контур.

Това не е точно голяма новина, но въпросът излезе с някои редовност, така че аз мислех, че ще се струва осчетоводяване.

</край>

Абонирайте се за моя блог.

Следвайте ме на Twitter в http://www.twitter.com/pagalvin

Какво е ограничен достъп Все пак?

АКТУАЛИЗИРАНЕ 11/03/08: Не забравяйте да прочетете отличен и подробен коментар от Dessie Lunsford към този пост.

Съм бил на работа по тайна tech редактиране проект за предстоящи книга и позовавания този блог влизане от Тайлър Бътлър в блога MSDN ECM. Това е първият път, аз лично чета ясно определение за смисъла на ограничен достъп. Ето месото на определението:

В SharePoint, анонимни потребители’ правата се определят от нивото на разрешение на ограничен достъп. Ограничен достъп е ниво на специално разрешение, което не могат да бъдат причислени към потребител или група направо. Причината съществува е, ако имате библиотека или подсайт която е избухнала наследяването на разрешения, и да дадете достъп на потребител/група само тази библиотека/подсайт, за да видите съдържанието му, потребител/група трябва да имат някакъв достъп до уеб на корена. В противен случай потребител/група няма да може да разглеждате библиотеката/подсайт, Въпреки че те имат права там, защото има неща в уеб на корена, които са необходими да се направи сайт или библиотека. Следователно, когато ви даде група разрешения само за подсайт или библиотеката, която унищожава наследяването на разрешения, SharePoint автоматично ще даде ограничен достъп до тази група или потребител на уеб на корена.

Този въпрос идва сега и тогава по форумите на MSDN и винаги съм бил любопитен (но не любопитни достатъчно, за да го разбера преди днес :)).

</край>

Абонирайте се за моя блог.

Следвайте ме на Twitter в http://www.twitter.com/pagalvin

Technorati тагове:

Бързо съвет: Конфигуриране на сигурност, за да позволи на администраторите да имат достъп до никакви Моят сайт в SharePoint

В знак, че социално започва да излети с SharePoint, Виждам, че увеличения брой на "Моят сайт" тип въпроси. Един често задаван въпрос е нещо подобно:

"Аз съм администратор и аз трябва да могат да имат достъп до всеки Моят сайт. Как да направя това?"

Важното тук е, че всеки Моят сайт е собствена колекция от сайтове. SharePoint сигурност обикновено се прилага на ниво на колекция със сайтове и това пътувания до много администратор на SharePoint. Обикновено, Тя вече има достъп за конфигуриране на защитата в "основни" колекции на сайта и може да не осъзнаваш, че това автоматично не работи за моите сайтове.

Колекции от сайтове заедно живеят в по-голям контейнер, което е уеб приложението. Ферма администратори може да конфигурирате сигурност на ниво уеб приложение и това е как администраторите могат да си предоставят достъп до всяка колекция от сайтове в уеб приложението. Този блог пост описва един от моя личен опит с уеб приложението политики. Аз дефинирани правила за уеб приложение от злополука: http://paulgalvin.spaces.live.com/Blog/cns!1CC1EDB3DAA9B8AA!255.entry.

Правила за приложение на Web може да бъде опасно и показват, че те се използват пестеливо. Ако бях администратор (и слава богу аз не съм), Аз ще създаде отделна реклама сметка име нещо като "уеб App администратора на SharePoint" и давам този един акаунт уеб приложение сигурност роля трябва. Не ще да конфигурирате този вид на нещо за редовни ферма администратор или отделен сайт колекция администратори. Тя ще са склонни да скрие потенциални проблеми, защото ролята на уеб ап отменя всяко по-ниско ниво на сигурност настройки.

</край>

Абонирайте се за моя блог.

Следвайте ме на Twitter в http://www.twitter.com/pagalvin

Мнения и колоните на списъци и библиотеки с документи не може да бъде защитено

АКТУАЛИЗИРАНЕ (02/29/08): Този нов codeplex проект изглежда да се осигури метод за осигуряване на отделни колони: http://www.codeplex.com/SPListDisplaySetting. Ако имате опит работа с него, Моля, оставете коментар.

Форум плакати често задават въпрос като този: "Имам мениджър изглед and и персонала изглед на списък. Как правя сигурен изгледа на мениджър, така че персоналът не може да го използвате?"

Те също така често питат свързан въпрос: "Искам да се осигури на метаданни, специфични колона, така че само администратори могат да редактирате тази колона, докато други може да не дори виждате я."

Тези отговори се прилагат за двете WSS 3.0 и Мос:

  • SharePoint не предоставя вън на на кутия поддръжка за осигуряване на изгледи.
  • SharePoint не предоставя вън на на кутия поддръжка за сигурност колони.

Има няколко техники за един може да следва да отговарят на тези видове на изискванията за сигурност. Тук е това, което мога да мисля за:

  • Използвате елемент от вън на на кутия ниво на сигурност. Изглед винаги чест елемент ниво на сигурност конфигурация. Събитие получател и/или работен поток може да автоматизирате сигурност назначение.
  • Използвайте лични изгледи за "привилегировани" пъти видяна. Това са достатъчно лесен, за да настроите. Въпреки това, поради своите "лични" природата, те трябва да се конфигурират за всеки потребител. Използвайте стандартните сигурността конфигурация за предотвратяване на някой друг от създаване на личен изглед.
  • Използване на уеб компонента за изглед на данни и прилагат някакво решение за орязване на AJAXy сигурност.
  • Roll своя собствена списък излагам на показ функционален и включват орязване на защитата на ниво на колона.
  • Модифициране на данни запис форми и използват JavaScript във връзка с модел на сигурност за изпълнение на орязване на защитата на ниво на колона.
  • Използване на формуляр на InfoPath за въвеждане на данни. Прилагане на орязване на защитата на ниво на колона чрез уеб услуга повиквания към SharePoint и условно скриване на полета, ако е необходимо.
  • Roll своя собствена ASP.NET данни влизане функция, която изпълнява колоната ниво на сигурност подстригване.

Нито една от тези опции са наистина, че много, но има поне един път да следват, ако трябва да, дори ако това е трудно.

ЗАБЕЛЕЖКА: Ако отидете по някоя от тези пътеки, не забравяйте за "действия-> Отваряне с Windows Explorer". Искате да се уверите, че ви тест с тази функция, за да се уверите, че тя не работи като "задната врата" и победи вашата схема.

Ако имате други идеи за или опит с осигуряване колони или изгледи, Моля пишете ми или оставете коментар и аз ще актуализира този текст според случая.

</край>

Абонирайте се за моя блог.

Technorati тагове:

Разтвор: System.IO.FileNotFoundException на “SPSite = нови SPSite(URL адрес)”

АКТУАЛИЗИРАНЕ: Аз афиш този въпрос за MSDN тук (http://forums.microsoft.com/Forums/ShowPost.aspx?PostID=2808543&SiteID=1&mode=1) и Michael Washam на Microsoft отговори с кратък отговор.

Създадох web услуга да действа като КБД екологични фасади списък на SharePoint. Когато се използва това от моята среда за разработка, мина успешно. Когато аз мигрирали това нов сървър, I откри тази грешка:

System.IO.FileNotFoundException: Уеб приложението на http://localhost/sandbox не може да бъде намерен. Проверете дали сте сте въвели URL правилно. Ако URL Адресът трябва да бъде обслужващи съществуващо съдържание, системният администратор може да се наложи да добавите ново искане URL съпоставяне разглежданото приложение. в Microsoft.SharePoint.SPSite...ctor(SPFarm стопанство, URI requestUri, Булева contextSite, SPUserToken userToken) в Microsoft.SharePoint.SPSite...ctor(RequestUrl на низ) в Conchango.xyzzy.GetExistingDocument(MinId на низ, MaxId на низ, TitleFilter на низ) в c:\Документи и SettingsPaulMy DocumentsVisual студио 2005ProjectsxyzzyBDC_DocReviewBDC_DocReviewDocReviewFacade.asmx.cs:линия 69

Тук е линия 69:

използване на (Сайт на SPSite = нови SPSite("http://localhost/sandbox"))

Опитах различни варианти на URL АДРЕС, включително използване на истинското име на сървъра, неговия IP адрес, теглещата черти на URL АДРЕС, н. Аз винаги имам тази грешка.

I използва Google да го изследвания. Много хора се сблъскват с този проблем, или вариации от него, но никой не изглежда да го решени.

Tricksy МОС, при условие че такава подробна грешка, която не се ми да провери 12 кошер трупи. В крайна сметка, за 24 часа след Моят колега препоръчва се аз го направите, I извлечен 12 hive регистър и че това:

Възникна изключение при опит да придобие локалната група:
System.Security.SecurityException: Желания за достъп регистър не е позволено.
в System.ThrowHelper.ThrowSecurityException(ExceptionResource ресурс) в Microsoft.Win32.RegistryKey.OpenSubKey(Име на низа, Булев записваем) в Microsoft.Win32.RegistryKey.OpenSubKey(Име на низа) в Microsoft.SharePoint.Administration.SPConfigurationDatabase.get_RegistryConnectionString() в Microsoft.SharePoint.Administration.SPConfigurationDatabase.get_Local() в Microsoft.SharePoint.Administration.SPFarm.FindLocal(SPFarm& ферма, Булев& isJoined)
В зоната на общото събрание, че не е:  MyComputer

Това откри нови възможности за научни изследвания, така че е обратно към на Google. Това ме доведе до това форум пост: HTTP://forums.codecharge.com/posts.PHP?post_id = 67135. Това наистина не ми помогне, но то did трепвам ме кара да мисля, е проблем на база данни или сигурност. Аз на въоръжение and Андрю Connell Публикувай накрая задейства мисълта, че трябва да се уверите, че на набора лична сметка е подходящ достъп до базата данни. Мислех, че вече е. Въпреки това, Моят колега отиде и дава ап пул самоличност акаунт пълен достъп до SQL.

След като тя прави тази промяна, Всичко започва да работи.

Какво се случи напред е най-добре изразено като Хайку Поемата:

Проблеми с повишаване на ръцете си.
Вие суинг и Мис. Опитайте отново.
Успех! Но как? Защо?

Тя не иска да остави нещата на мира, предпочитайки да даде минимално необходимото разрешение (и вероятно оглед писане блог запис; Аз я побеждава Пунш, muhahahahaha!).

Тя отстранени разрешения за последователно от ап самоличност акаунт до … вече не е изрично разрешение за ап идентичност акаунт на всички. Уеб услугата продължава да работи добре.

Отидохме и rebooted сървъри. Всичко продължава да работи добре.

Така, за да recap: дадохме ап идентичност пълен достъп до басейна и след това го отне. Уеб услугата започва да работи и никога не спря да работи. Странни.

Ако някой знае защо това трябва да са работили, Моля, оставете коментар.

</край>

Technorati тагове:

Минимално изискваната гаранция за формуляри на InfoPath

Трябваше да отговарят на изискването за сигурност за формуляр на InfoPath днес. В тази ситуация, Бизнес, относително малък брой хора е позволено да създадете нов формуляр, InfoPath и много по-широка аудитория могат да го редактират. (Това е нов-под наем за качване на борда формуляр използван от човешки ресурси, стартира работен поток).

За тази цел, Съм създал създадени две нови нива на разрешение ("създаване и актуализиране на" и "update само"), счупи наследство за библиотеката с формуляри и присвоява разрешения за на "създаване на, актуализация" потребител и отделна "актуализация само" потребител. Всички механика работи, но се оказа, да бъде малко по-завладяващо, отколкото очаквах. (Ако се чувстваш малко неуверен в SharePoint разрешения, Вижте този блог пост). Конфигурацията на необходимата сигурност за нивото на разрешение не е очевидно набор от разрешения, гранулиран. Да се създаде разрешение само за актуализация ниво за формуляр на InfoPath, Направих следното:

  1. Създаване на ново ниво на разрешение.
  2. Изчистите всички опции.
  3. Избрани само следното от "Списък разрешения":
    • Редактиране на елементи
    • Преглед на елементи
    • Приложение страници

Изборът на тези опции позволява на потребителя да актуализира форма, но не го създаде.

Номерът е да се даде възможност "заявление страници". Няма никакви verbage на нивото на разрешение, което показва, че е задължително за само за актуализация на формуляри на InfoPath, но оказва се, че е.

Създаване и актуализация е още по-странни. Аз следват същите стъпки, 1 чрез 3 по-горе. Аз трябваше да добавите специално разрешение за сайт "" опция: "Използване на функции за интегриране на клиента". Отново, описанието има прави да изглежда като тя е трябвало да се изисква за формуляр на InfoPath, но там е.

</край>

Technorati тагове: ,

SharePoint не предоставя “Кой има достъп” Отчети

АКТУАЛИЗИРАНЕ 01/28/08: Този codeplex проект разглежда този въпрос: http://www.codeplex.com/AccessChecker. Не са го употребявали, но тя изглежда обещаващ, ако това е въпрос, който трябва да се справят във вашата среда.

АКТУАЛИЗИРАНЕ 11/13/08: Joel Оулсън пише до много добър пост за по-големите въпрос за управление на сигурността тук: HTTP://www.sharepointjoel.com/ Lists/Posts/Post.aspx?Списък = 0cd1a63d % 2D183c % 2D4fc2 %2 D 8320 % 2Dba5369008acb&ID = 113. То е свързано с редица други полезни ресурси.

Форум на потребителите и клиентите често питат един въпрос в тази насока: "Как аз генериране на списък на всички потребители с достъп до сайт" или "как да мога автоматично предупреждава всички потребители с достъп до списъка за промени, направени в списъка?"

Там е никакъв вън на кутия разтвор за този. Ако мислите за това за момент, не е трудно да се разбере защо.

SharePoint сигурност е много гъвкав. Има най-малко четири основни категории на потребители:

  • Анонимни потребители.
  • SharePoint потребители и групи.
  • Active Directory потребители.
  • Формуляри, базирани удостоверяване (FBA) потребители.

Гъвкавост означава, че от гледна точка на сигурността, даден SharePoint сайт ще бъде коренно различно от друг. За да генерирате списък отчет на access, трябва да се провери как сайта е защитено, заявка множество различни потребителски профил хранилища и след това го представя в полезен мода. Това е труден проблем за решаване на генерични.

Как са организации се занимават с това? Бих искал да чуя от вас в коментарите или имейл.

</край>

Technorati тагове: ,

SharePoint сигурност основи грунд / Се избегне обща клопки

АКТУАЛИЗИРАНЕ 12/18/07: Вижте статията на Пол Liebrand за някои технически последици на премахване или промяна на имена на групи по подразбиране (Виж си коментар по-долу, както и).

Общ преглед:

SharePoint сигурност е лесно да конфигурирате и управлявате. Въпреки това, тя доказа, че е трудно за някои първи път администраторите да наистина увийте ръцете си около нея. Не само, че, Аз съм виждал някои администратори идват до перфектно разбиране в понеделник само да са го загубили от петък, защото те не трябва да правя кой да е очертание в междинния време. (Признавам, да има този проблем себе си). Този блог влизане Надяваме се предоставя полезна SharePoint сигурност грунд и точки към някои конфигурация най-добрите практики за сигурност на.

Важна бележка:

Това описание се базира на кутията SharePoint сигурност. Моят личен опит е ориентирани около Мос, така може да има някои Мос специфични неща тук, но аз вярвам, че е точно за ВиК. Надявам се, че всеки, който вижда грешки или пропуски ще която посочи в коментарите или пишете ми. Ще направя корекции побърза пост.

Основи:

За целите на този преглед, има четири основни аспекти на сигурността: потребители/групи, защитими обекти, нива на разрешение и наследяване.

Потребители и групи прекъсване до:

  • Отделни потребители: Извади от активна директория или създадени директно в SharePoint.
  • Групи: Нанесен директно от active directory или създаден в SharePoint. Групи са колекция от потребители. Групи са глобални в колекция от сайтове. Те никога не са "обвързани" за определен защитим обект.

Защитими обекти прекъсване до най-малко:

  • Сайтове
  • Библиотеки с документи
  • Отделни елементи от списъци и библиотеки с документи
  • Папки
  • Различни BDC настройки.

Там други защитими обекти, но вие получите картинката.

Нива на разрешение: Пакет от гранулиран / ниско ниво на достъп права, които включват неща като създаване/четене/изтриване на записи в списъци.

Наследяване: По подразбиране лица наследяват настройките за защита от техните съдържащи обекти. Подсайтове наследяват разрешения от родителя. Наследяване на библиотеки с документи от сайта им. Така на и така напред.

Потребители и групи се отнасят до защитими обекти чрез нива на разрешение и наследяване.

Най-важните правила за сигурност да разберат, Ever 🙂 :

  1. Групи са просто колекции на потребители.
  2. Групи са глобални за колекция от сайтове (т.е.. няма такова нещо като група, определена на ниво сайт).
  3. Името на групата не издържат, групите не, в и за себе си, имат определено ниво на сигурност.
  4. Групи имат сигурност в контекста на определен защитим обект.
  5. Можете да присвоите различни нива на разрешения на една и съща група за всеки защитим обект.
  6. Правила за приложение на Web коз всичко това (Вижте по-долу).

Администратори на защита, изгубени в морето от група и потребителски списъци винаги могат да разчитат на тези аксиоми да управляват и разбират тяхната сигурност конфигурация.

Общите клопки:

  • Имената на групите лъжливо предполага разрешение: На кутията, SharePoint дефинира набор от групи, чиито имена означава, присъщи ниво на сигурност. Помислете за групата "Сътрудник". Един непознат с SharePoint сигурност добре може да погледнете това име и предположи, че всеки член на тази група може да "допринесе" към всеки сайт/списък/библиотека в портала. Това може да е вярно, но не защото името на групата се случва да бъде "сътрудник". Това е вярно само на кутията, защото групата е била предоставена на ниво на разрешение, което им дава възможност за добавяне/редактиране/изтриване на съдържанието на главния сайт. Чрез наследяване, "сътрудници" група може също добавяне/редактиране/изтриване на съдържанието на всеки под-сайт. Една може да "счупи" по наследство верига и промените нивото на разрешение на един под-сайт такива че членовете на така наречените "сътрудник" групата не може да съдейства на всички, но само четат (за пример). Това не би било добра идея, очевидно, тъй като това би било много объркващо.
  • Групите не са определени на ниво сайт. Това е лесно да бъдат объркани от потребителския интерфейс. Microsoft снабдявам удобен звено към потребител/група за управление през всеки сайт "хора и групи" връзка. Това е лесно да вярват, че когато съм в сайта "xyzzy" създам група чрез xyzzy на хора и групи връзка, че току-що създадохте група, която съществува само в xyzzy. Това не е така. Всъщност аз създадох група за цялата колекция.
  • Членство в групи не се различава от сайт (т.е.. същото е навсякъде се използва група): Помислете за групата "собственик" и двата обекта, "HR" и "Логистика". Би било нормално да се мисли, че две отделни индивиди ще притежава тези сайтове — HR собственик и собственик на логистиката. Потребителски интерфейс го прави лесен за администратор по сигурността да mishandle този сценарий. Ако не знаете по-добре, Аз може да достъп на хора и групи връзки чрез сайта на HR, изберете "собственици" Група и да добавите ми ВП собственик към тази група. Един месец по-късно, Логистика идва на линия. Аз достъп хора и групи от сайта на логистиката, Добави издърпайте нагоре "собственици" Група. Вижте собственика на HR там и я премахнете, Мисля, че съм я премахване от собствениците на сайта на логистиката. Всъщност, Аз съм я премахване от групата на собствениците на глобалната. Веселие произтича.
  • При липса на име групи въз основа на специфична роля: "Одобряващите" Група е перфектен пример. Какво може членовете на тази група одобрение? Къде може да го одобри? Наистина искам хората Логистичен отдел, за да може да одобрява документи за HR? Не, разбира се. Винаги името групи въз основа на тяхната роля в рамките на организацията. Това ще намали риска, че групата е присвоен на неподходящо разрешение ниво за определен защитим обект. Името групи въз основа на ролята им предназначение. В предходния сценарий HR/логистика, Трябваше да се създаде две нови групи: "HR собственици" и "Логистика собственици" и да присвоите нива на разумното разрешение за всяка и минималната сума, необходима за тези потребители, за да вършат работата си.

Други полезни препратки:

Ако сте го направили това далеч:

Моля да ме мислите си чрез коментари или ми пишете. Ако знаете други добри препратки, Моля, направете същото!

Technorati тагове: