none
Sharepoint 2007 - выборочный запрет на доступ к узлам RRS feed

  • Вопрос

  • Коллеги,

    помогите, плиз, в решении задачки. Есть сайт, включающий несколько узлов (Узел1, Узел2 и т.д.). На весь сайт даны разрешения на чтение для Domain Users. Хочется сделать так, чтобы для пользователей доменной группы, допустим, Group1, (при этом пользователи входят, естественно, в Domain Users) не было доступа на Узел1.  Создавать для этого узла специальную группу из допущенных пользователей (99% из Domain Users) - несерьезно. А как установить запрет на доступ для группы - найти не могу. Пробовал создать группу без назначения ей прав - не работает.

    Как-то такая задача решается?

    16 июня 2010 г. 13:43

Ответы

  • Безжалостно это. :-)

    Т.е. задачка не решается... Очень жаль...


    Не вижу проблемы. Сначала тогда наследуйте разрешения, т.е. у вас будет доступ всей 1000. Потом изменяете наследование, - появится возможность убрать 10 лишних.
    MCTS, MCITP:EPM
    18 июня 2010 г. 8:05
    Отвечающий

Все ответы

  • На узле1 зайдите в управление разрешениями  Site Settings > Permissions   (_layouts/user.aspx)

    Тут прекращаете наследование разрешений от родительского сайта (Actions - Edit Permissions) и назначаете права только Group1.


    MCTS, MCITP:EPM
    16 июня 2010 г. 13:52
    Отвечающий
  • Мне нужно запретить(!) доступ пользователям, входящим в Group1, к Узлу1. Сохранив этот доступ остальным членам Domain Users (не входящим в Group1). При этом пользователи, входящие в Group1, входят и в Domain Users.

    Другими словами, хочется найти галку "Access Denied", и чтобы этот запрет проверялся ДО проверки разрешений - как в файловой, к примеру, системе NTFS.

    16 июня 2010 г. 14:09
  • Для того, чтобы запретить доступ для группы, это аналогичино, если Вы запрещаете доступ на пользователя.

    Вы должны выбрать параметры сайта зайти в разрешения сайта. Выбрать разрешения и выбрать Вашу группу и настроить права доступа. Всё легко.


    Sergey A Belskiy - Team Leader of developers, DEV-pro || My blog: http://blogs.it-club.in.ua/sbelskiy || My twitter: http://twitter.com/sergey_belskiy || My space: http://sbelskiy.space.live.com
    17 июня 2010 г. 4:55
    Модератор
  • Боюсь, что я чего-то не понимаю. В настройках доступа можно только ДАТЬ права. Запретить доступ нельзя. Если для группы или пользователя не прописать права - это не означает запрета. А мне нужно именно запретить. Наверное, я не очень внятно описал задачу. Попробую еще раз.

    1. В домене 1000 юзеров. Все они входят в группу Domain users.

    2. Есть узел, к которому должны иметь доступ 990 юзеров. 10 человек - не должны. При этом эти 10 входят в Domain Users, т.к. на эту группу завязаны и другие права в других местах.

    3. Создавать группу из 990 человек, чтобы именно ей дать доступ к узлу, не хочется. Проще создать группу "лишенцев" из 10. Создаем группу Group1.

    4. Соответственно, хочется дать доступ к узлу для Domain users (это действительно легко), и при этом ЗАПРЕТИТЬ для Group1.

    17 июня 2010 г. 6:56
  • Если изначально у них есть доступ, значит по любому эта группа прописывается с правами в разрешениях. Нужно её выбрать и убрать права
    Sergey A Belskiy - Team Leader of developers, DEV-pro || My blog: http://blogs.it-club.in.ua/sbelskiy || My twitter: http://twitter.com/sergey_belskiy || My space: http://sbelskiy.space.live.com
    17 июня 2010 г. 7:46
    Модератор
  • Т.е. задача решения не имеет? Такого, как в файловой системе, или на SQL-сервере, сделать нельзя? Чтобы сначала проверялись запреты, и только потом - разрешения? Плоховато...
    17 июня 2010 г. 8:04
  • Мы говорим про разные чуток системы.

    Пример, если у Вас есть родительский сайт в котором созданы дочерние узлы и права наследуются от родительского, то все права которые Вы настраиваите в родительском для пользователей, наследуются на все его дочерние. Чтобы это оставновить, нужно просто прекратить наследование. Там для этого есть кнопка :).

    И Уже после Вы сами назначаете нужные права для этого узла


    Sergey A Belskiy - Team Leader of developers, DEV-pro || My blog: http://blogs.it-club.in.ua/sbelskiy || My twitter: http://twitter.com/sergey_belskiy || My space: http://sbelskiy.space.live.com
    17 июня 2010 г. 8:16
    Модератор
  • Сергей,

    мы говорим про Sharepoint. Про наследование прав не говорим. Нет наследования. Отключено. Что дальше? Я должен создать группу из 990 юзеров (1000 всего минус 10 "лишенцев") и прописать ей права? Очевидное решение. Главное - очень "гуманное". Как в смысле начального создания, так и дальнейшего сопровождения. Особенно если таких узлов десяток-другой. И на один надо не пускать вот этих двоих, на другой - пяток других, на третий - еще кого-то. Тут создал группу из 998 юзеров, тут - из 995 и т.д. Пришел новый человек, который не должен иметь доступа к паре узлов - нет чтобы его в пару же групп и включить, придется во все группы (минус две).

    17 июня 2010 г. 8:59
  • Ну если у Вас отключено. То во первых закрыть доступ всем кто в домене - NT AUTHORITY\Прошедшие проверку 

    После создать группу, кому нужен доступ и вперёд добавлять.

     


    Sergey A Belskiy - Team Leader of developers, DEV-pro || My blog: http://blogs.it-club.in.ua/sbelskiy || My twitter: http://twitter.com/sergey_belskiy || My space: http://sbelskiy.space.live.com
    17 июня 2010 г. 10:53
    Модератор
  • Безжалостно это. :-)

    Т.е. задачка не решается... Очень жаль...

    17 июня 2010 г. 11:47
  • Безжалостно это. :-)

    Т.е. задачка не решается... Очень жаль...


    Не вижу проблемы. Сначала тогда наследуйте разрешения, т.е. у вас будет доступ всей 1000. Потом изменяете наследование, - появится возможность убрать 10 лишних.
    MCTS, MCITP:EPM
    18 июня 2010 г. 8:05
    Отвечающий
  • Управлять пользователями "поштучно" - хлопотно. Чересчур хлопотно. Это не решение. Речь-то идет про выборочное ограничение, а не раздачу прав. А при таком варианте надо будет нового "обычного" пользователя, не "лишенца", руками добавлять на несколько узлов. Обязательно куда-то забудешь вписать.

    Хотелось найти красивое решение, работать на уровне доменных групп. Типа включил пользователя в группу "На Узел1 нельзя" - и все хорошо, на остальные 10 узлов он попадает без дополнительных телодвижений админа.

    18 июня 2010 г. 11:58
  • Управлять пользователями "поштучно" - хлопотно. Чересчур хлопотно. Это не решение. Речь-то идет про выборочное ограничение, а не раздачу прав. А при таком варианте надо будет нового "обычного" пользователя, не "лишенца", руками добавлять на несколько узлов. Обязательно куда-то забудешь вписать.

    Хотелось найти красивое решение, работать на уровне доменных групп. Типа включил пользователя в группу "На Узел1 нельзя" - и все хорошо, на остальные 10 узлов он попадает без дополнительных телодвижений админа.


    В принципе, идеология и практика управления сайтами sharepoint в крупной сети с множеством сайтов предполагает наличие "главного" на каждоц коллекции, наличие "главного" на каждом узле, кот. и разруливает разрешения на подчиненном ему пространстве, что не так хлопотно, как если делать все одному.
    MCTS, MCITP:EPM
    18 июня 2010 г. 12:17
    Отвечающий
  • Ну мы вроде про технические решения, а не про идеологию? Или типа, решения нет - значит по идеологии не надо? Для файловых систем есть, для MS SQL есть, для Exchange тоже есть - ну, значит, им надо, а тут без необходимости. Хотя темы, на мой взгляд, аналогичные - обеспечение совместного доступа к данным.

    Ну ладно, это лирика, к делу относится слабо.

    18 июня 2010 г. 12:56
  • Ну мы вроде про технические решения, а не про идеологию? Или типа, решения нет - значит по идеологии не надо? Для файловых систем есть, для MS SQL есть, для Exchange тоже есть - ну, значит, им надо, а тут без необходимости. Хотя темы, на мой взгляд, аналогичные - обеспечение совместного доступа к данным.

    Ну ладно, это лирика, к делу относится слабо.


    идеология=рекомендуемые правила использования продукта.
    MCTS, MCITP:EPM
    18 июня 2010 г. 13:38
    Отвечающий
  • Ну мы вроде про технические решения, а не про идеологию? Или типа, решения нет - значит по идеологии не надо? Для файловых систем есть, для MS SQL есть, для Exchange тоже есть - ну, значит, им надо, а тут без необходимости. Хотя темы, на мой взгляд, аналогичные - обеспечение совместного доступа к данным.

    Ну ладно, это лирика, к делу относится слабо.


    идеология=рекомендуемые правила использования продукта.
    MCTS, MCITP:EPM


    Денис,

    Чем, по Вашему, "идеология" общих папок Exchange при доступе по HTTP\HTTPS через OWA отличается от библиотек/узлов Sharepoint? Особенно с учетом того, что Sharepoint официально предлагается как замена общим папкам (с угрозой исключить общие папки из будущих версий Exchange)? Тем не менее в Exchange (до 2007 включительно, как в 2010 - пока не знаю), повторюсь, искомое решение есть в явном виде. И никакая "идеология", а также "рекомендуемые правила использования продукта" этому не мешают. Кстати - не могли бы Вы дать ссылку на документ от Микрософта с описанием этой самой декларируемой Вами "идеологии"? Сколько админов (или "главных") на сколько узлов/библиотек (и пользователей). А то ведь в моем примере 1000 юзеров, а может быть и 10 000, и 100 000. Тогда и на одном узле замучаешься их поштучно включать и в дальнейшем рулить.

    Это все переходит в категорию флейма. Если чего-то нет (не доработано, не додумано, и т.д.) - то, значит, и использовать не рекомендуется, по идеологическим мотивам. Кондиционера в "Жигулях" нет (и ставить по ГАИ-шным правилам, строго говоря, нельзя)  - значит,  идеологически нечего летом ездить, надо на работе сидеть, "шарик" настраивать. :-) И, хотя флеймить я умею лучше многих, мне это не очень интересно. Интересно найти решение задачи.

    Для своих конкретных условий я его уже нашел. Кривое, но лучше, чем "поштучное" управление пользователями. Суть решения - сборка мелких "базовых" (ключевые слова) групп юзеров в более крупные, с предоставлением этим "крупным" группам соответствующих прав на узлах (люди-то лишены доступа по функциям, не по цвету глаз). Далее новый человек включается в базовую группу - и автоматически получает доступ к нужным узлам. Тоже хлопотно, но не настолько. И в будущем может не сработать (и даже привести к еще бОльшим проблемам). Но, тем не менее, "на безрыбье...".

    Так что спасибо за участие в обсуждении задачки, за сим позвольте откланяться, до новых встреч! :-)

    18 июня 2010 г. 16:54
  • Кстати - не могли бы Вы дать ссылку на документ от Микрософта с описанием этой самой декларируемой Вами "идеологии"? Сколько админов (или "главных") на сколько узлов/библиотек (и пользователей). А то ведь в моем примере 1000 юзеров, а может быть и 10 000, и 100 000. Тогда и на одном узле замучаешься их поштучно включать и в дальнейшем рулить.

    В правилах форума сказано, что прежде чем задавать вопросы, очень рекомендуется ознакомиться с библиоткой TechNet. Пожалуйста, изучайте ;). Но даже и без изучения документации волне можно заметить, если постараться, что на каждом сайте заранее предопределены группы владельцев, участников и читателей. Надеюсь, разницу в правах этих групп объяснять не нужно.
    Это все переходит в категорию флейма. Если чего-то нет (не доработано, не додумано, и т.д.) - то, значит, и использовать не рекомендуется. Интересно найти решение задачи.
    Не сомневаюсь, что умеете флеймить, что не вяжется с желанием найти решение задачи, т.к. очивидно, что с документацией по продукту Вы познакомились поверхностно, перед тем как его внедрять.
    Так что спасибо за участие в обсуждении задачки, за сим позвольте откланяться, до новых встреч! :-)
    Всегда пожалуйста! :)
    MCTS, MCITP:EPM
    19 июня 2010 г. 8:56
    Отвечающий