Comments 23
А зачем нужен скрип создания rdp файла? Не проще создать один раз их сохранить их в общедоступном месте и размещать у пользователя через group policy только линки на них?
Этот скрипт был написан, когда Group Policy Preferences мы еще не использовали, и чтобы раздать ярлыки на сетевые RDP-файлы все равно нужно было писать логон-скрипт, который эти «ярлыки на ярлыки» создавал бы. Мы решили не городить огород и создавать сразу RDP-файлы.
С одной стороны некоторая отказоустойчивость (если недоступен файловый сервер, то все равно можно зайти в терминал поработать, ага?)
С другой тут важен не процесс создания RDP-файла, а именно управление кому какой ярлык на основе членства у группе. У нас было тогда довольно много разных терминалов, и разных групп людей, которым нужно было одно, но не нужно было другое, а через полгода ситуация менялась в обратную сторону. Написанный скрипт позволил делегировать управление членством в группах RDP_ ответственному лицу, начальнику их отдела, и этот вопрос свалился с наших плеч.
Ой, что это я. Не свалился — был делегирован :)
С одной стороны некоторая отказоустойчивость (если недоступен файловый сервер, то все равно можно зайти в терминал поработать, ага?)
С другой тут важен не процесс создания RDP-файла, а именно управление кому какой ярлык на основе членства у группе. У нас было тогда довольно много разных терминалов, и разных групп людей, которым нужно было одно, но не нужно было другое, а через полгода ситуация менялась в обратную сторону. Написанный скрипт позволил делегировать управление членством в группах RDP_ ответственному лицу, начальнику их отдела, и этот вопрос свалился с наших плеч.
Ой, что это я. Не свалился — был делегирован :)
А с группой компьютеров такое прокатит? Например поставить принтер определенной группе компьютеров. Ведь компьютеры трактуются как «особый» пользователь АД?
прокатит.
ну и не нужно наверное напоминать что в этом случае в группе должен состоять компьютер, и скрипт должен запускаться в разделе компьютера (Group Policy — Computer Configuration — Windows Settings — Scripts ) а не пользователя.
ну и не нужно наверное напоминать что в этом случае в группе должен состоять компьютер, и скрипт должен запускаться в разделе компьютера (Group Policy — Computer Configuration — Windows Settings — Scripts ) а не пользователя.
А если что-то давать компьютерам устанавливать из UNC пути — какие права пользователей должны быть в этом пути? Authenthicated Users достаточно или там другой уровень?
Достаточно. Но практика — критерий истины. Просто возьмите и попробуйте.
Помните что Authenthicated Users это весьма широкое понятие, и лучше придерживаться правила: «давать только необходимое».
Я бы лично дал бы права той группе, спомощью которой вы ставите софт.
Ну вот например:
Помните что Authenthicated Users это весьма широкое понятие, и лучше придерживаться правила: «давать только необходимое».
Я бы лично дал бы права той группе, спомощью которой вы ставите софт.
Ну вот например:
- сделали группу UNC_MegaSoft, чтобы устанавливать ваш MegaSoft по UNC путям.
- написали скрипт, который устанавливает все что нужно для тех, кто входит в группу UNC_MegaSoft
- добавили в эту группу ряд компьютеров.
- тогда логично будет назначить на шару права для группы UNC_MegaSoft. убрав все лишнее. В этом случае у вас гарантированно будут права для тех, кому скрипт будет ставить ваш софт, и не будет прав у тех, кто не в группе, и кому это не нужно.
Автору спасибо, давно хотел посмотреть нормальный пример использования AD + GPO.
Также + за хорошую идею насчет использования групп везде где можно.
Также + за хорошую идею насчет использования групп везде где можно.
Статья годная. Но тема глобальных, универсальных и локальных групп, а так же модели A-G-DL-P — не раскрыта.
Зачем? Это и так всё раскрыто в любой самой захудалой книжке по началам работы с AD…
Я вот правда всё время забываю их разницу, т.к. редко приходится сталкиваться :)
Я вот правда всё время забываю их разницу, т.к. редко приходится сталкиваться :)
Вот technet.microsoft.com/en-us/library/cc755692(WS.10).aspx, легко освежит память, какие группы имеют какие ограничения.
Спасибо за цикл статей, с удовольствие прочитал, несмотря на то что не всё может потребоваться в работе.
Пишите ещё!
Пишите ещё!
Использование совета под номером 1 в одной достаточно большой организации привела к тому, что у некоторых пользователей перестали работать внутренние веб-приложения с Kerberos-аутентификацией. Оказалось, что рост числа групп привел к слишком большому размеру Kerberos-токенов. Microsoft-у пришлось вносить изменения в наши конфигурации Exchange и Sharepoint. Сейчас балансируем где-то у верхней границы supported Token Size.
я много раз писал и видимо буду продолжать писать о том, что мой опыт связан с небольшими организациями. Это накладывает свой отпечаток.
Кроме того, первый совет о том, что в ACL, Group Policy и иже с ними лучше использовать группы, а не отдельных людей. В вашей же ситуации проблема была в слишком большом числе групп. Это несколько разные вещи, не находите?
Да, возможно и такое, наверное это даже не экстремально, а действительно необходимо в ОЧЕНЬ большой организации, но это ведь не умаляет достоинства использования групп в сравнении с пользователями? М?
Кстати, а у проблемных пользователей сколько групп было? И какой уровень домена-леса? Интересно :)
Кроме того, первый совет о том, что в ACL, Group Policy и иже с ними лучше использовать группы, а не отдельных людей. В вашей же ситуации проблема была в слишком большом числе групп. Это несколько разные вещи, не находите?
Да, возможно и такое, наверное это даже не экстремально, а действительно необходимо в ОЧЕНЬ большой организации, но это ведь не умаляет достоинства использования групп в сравнении с пользователями? М?
Кстати, а у проблемных пользователей сколько групп было? И какой уровень домена-леса? Интересно :)
проблема была все-таки не в общем колличестве групп в AD, а в том, что некоторые пользователи находились с слишком большом количестве групп (то есть под каждую задачу создавали группу, даже если в ней был всего один человек). Насколько я знаю, речь шла около 1000 групп у одного пользователя. И вот от этого я хотел бы предостеречь ))
Как на Хабре лучше выкладывать скрипты и вообще код, а то больно длинный пост получается.
pastebin.com
gist.github.com
«В результате, чтобы пустить кого-то на сервер 1С, достаточно добавить его в группу»
как уже правильно заметили, создавать группу по каждому чиху тоже может стать накладно.
может быть я невчитался в статью, но не увидел рекомендации создания групп по ролям.
например, те же бухи, которые ходят по рдп на терминал с 1с: создав группы FLD_1c и RDP_1c, на мой взгляд логичнее добавить группу «Бухгалтерия» и включить обе эти группы туда. а самих пользователей уже банально добавлять в «Бухгалтерия». плюс, не надо думать «а какой же группой у нас ставится RDP-ярлычок?», «а какой же группой даются права на SQL?» и прочая прочая.
получается простая схема: есть отдел, есть функционал отдела — есть группа отдела. приходит человек — попадает в группу отдела и имеет щастье.
«А еще лучше прямо запуск самой 1С делать через такой скрипт»
кстати о скриптах — я уже давно для себя решил, что чем меньше скриптов и чем больше готовых решений используется, тем меньше проблем. начиная с такой мелочи, как «ушел человек, который писал этот скрипт полжизни». касательно конкретно 1с — 7рка отлично настраивается через политики с реестром, 8рка — через плагин к AD, который так же через GPO прописывает нужные базы. и опять задача сводится к «пришел дцатый бух, добавили его в группу бухов и группу бухов по функицоналу (ЗП, ОС и тд)». бух запустил комп — все нужное есть сразу.
с другими шедеврами «программизма» конечно сложнее. особенно с поделками, которые хотят админские права и писать исключительно в C:. но это уже отдельный разговор. (и таки да, к сожалению, эти шедевры стоят денег и там низкая конкуренция).
касаемо ярлычков, принтеров и прочая — с приходом GPP потребность в скриптах практически свелась к нулю. а настроить рабочий стол, на мой взгляд, гораздо более правильно через стандартный профиль. в этом случае, опять же, достаточно просто скопировать профиль и поправить права на скопированном. дальше юзверь грузится и засасывает готовый профиль с сервера.
«Например группы которые используются для разрешения доступа к папкам можно называть так FLD_FolderName_RW»
кстати, было бы интересно посмотреть на схему таких групп, когда права на ресурсы назначаются на 3+ уровней вглубь дерева папок. например, «депаратамент — отдел — группа — проекты». у меня получалась уж очень сложная схема. хотя это и было лучше, чем назначать права на папки ручками. плюс, возник такой ньюанс — если называть группы осмысленно, по названиям папок, в какой-то момент упираемся в ограничение на длину имени группы. (группы создавались автоматом, на основе дерева шары)
опять же, предложенная схема «FLD_Foldername» явно заточена под то, что все ресурсы лежат в одном корне DFS? а какие решения были выработаны для случаев, когда права нужно давать на конкретном сервере? или если в лесу несколько доменов/несколько лесов (подразделения/афф конторы)?
«Я не буду вдаваться глубоко в теорию и рассказывать об универсальных, глобальных локальных группах — желающие все подробности смогут найти в документации, благо ее предостаточно»
наверное, стоит немного упомянуть об их функционале? все-таки, если организация работает в одной локалке это одно, а если подразделений по регионам кучка — вопрос групп уже может стать острым. и дело даже не в трафике репликации. а банальной скорости доступа к объектам и тп.
как уже правильно заметили, создавать группу по каждому чиху тоже может стать накладно.
может быть я невчитался в статью, но не увидел рекомендации создания групп по ролям.
например, те же бухи, которые ходят по рдп на терминал с 1с: создав группы FLD_1c и RDP_1c, на мой взгляд логичнее добавить группу «Бухгалтерия» и включить обе эти группы туда. а самих пользователей уже банально добавлять в «Бухгалтерия». плюс, не надо думать «а какой же группой у нас ставится RDP-ярлычок?», «а какой же группой даются права на SQL?» и прочая прочая.
получается простая схема: есть отдел, есть функционал отдела — есть группа отдела. приходит человек — попадает в группу отдела и имеет щастье.
«А еще лучше прямо запуск самой 1С делать через такой скрипт»
кстати о скриптах — я уже давно для себя решил, что чем меньше скриптов и чем больше готовых решений используется, тем меньше проблем. начиная с такой мелочи, как «ушел человек, который писал этот скрипт полжизни». касательно конкретно 1с — 7рка отлично настраивается через политики с реестром, 8рка — через плагин к AD, который так же через GPO прописывает нужные базы. и опять задача сводится к «пришел дцатый бух, добавили его в группу бухов и группу бухов по функицоналу (ЗП, ОС и тд)». бух запустил комп — все нужное есть сразу.
с другими шедеврами «программизма» конечно сложнее. особенно с поделками, которые хотят админские права и писать исключительно в C:. но это уже отдельный разговор. (и таки да, к сожалению, эти шедевры стоят денег и там низкая конкуренция).
касаемо ярлычков, принтеров и прочая — с приходом GPP потребность в скриптах практически свелась к нулю. а настроить рабочий стол, на мой взгляд, гораздо более правильно через стандартный профиль. в этом случае, опять же, достаточно просто скопировать профиль и поправить права на скопированном. дальше юзверь грузится и засасывает готовый профиль с сервера.
«Например группы которые используются для разрешения доступа к папкам можно называть так FLD_FolderName_RW»
кстати, было бы интересно посмотреть на схему таких групп, когда права на ресурсы назначаются на 3+ уровней вглубь дерева папок. например, «депаратамент — отдел — группа — проекты». у меня получалась уж очень сложная схема. хотя это и было лучше, чем назначать права на папки ручками. плюс, возник такой ньюанс — если называть группы осмысленно, по названиям папок, в какой-то момент упираемся в ограничение на длину имени группы. (группы создавались автоматом, на основе дерева шары)
опять же, предложенная схема «FLD_Foldername» явно заточена под то, что все ресурсы лежат в одном корне DFS? а какие решения были выработаны для случаев, когда права нужно давать на конкретном сервере? или если в лесу несколько доменов/несколько лесов (подразделения/афф конторы)?
«Я не буду вдаваться глубоко в теорию и рассказывать об универсальных, глобальных локальных группах — желающие все подробности смогут найти в документации, благо ее предостаточно»
наверное, стоит немного упомянуть об их функционале? все-таки, если организация работает в одной локалке это одно, а если подразделений по регионам кучка — вопрос групп уже может стать острым. и дело даже не в трафике репликации. а банальной скорости доступа к объектам и тп.
Ну тут конечно можно спорить, и конечная реализация сильно зависит от нужд самой компании.
если конкретно, то
— ваш метод «делаем одну две группы и назначаем им необходимые права которые одинаковы для всех (Бухгалтерия=1C+RDP+папкаБухгалтерия+т.д.)» мне лично не очень нравится. т.к. вы создаете группу, обладающую «множество прав», в которое потом вводите туда всех кто приблизительно должен обладать этими правами. а если человек бухгалтер, а ему не все базы нужны, или продажник но по отдельному направдению, или бухгалетр, но без доступа к терминалу и т.д. Я считаю лучше сделать множество групп, и потом из этих групп-кирпичиков «строить» каждому пользователю его личное «множество прав». Это более избирательно и гибко на мой взгляд.
— чтобы достигнуть ситуации как описывал выше makc_de, надо сильно постараться. 1000 групп у человека это конечно перебор. По опыту (а я не устаю напоминать какой он у меня, в организациях какого размера полученный) больше чем 200-300 групп (вообще! не у одного пользователя) в организациях среднего размера не было ни разу.
— отношение к скриптам у каждого свое. иногда скрипты полезны, иногда готовое решение дорого или недостаточно функционально, а иногда наоборот скрипты кривы и только ухудшают ситуацию. Тут единого рецепта наверное нет.
— назначать доступ на папки которые 3+ уровня вниз — это как-то перебор на мой взгляд. Если нужна группа для коллективного доступа — выносите ее выше, максимум на 2 уровень, зачем глубже то? Ну и то же самое касается названий папок. У нас было единой для всех правило: если папка имеет особые права, то она называется по английски и одним словом максимум 2-3 словами без пробелов. Поэтому проблем особых мы как вы понимаете не испытывали
— когда ресурсы лежат на конкретном сервере, то почему бы не ввести эти ресурсы в DFS? Мы всегда придерживались этого правила, и не столкнулись с ситуацией когда его невозможно было бы применить.
— когад в лесу несколько доменов, или вообще несколько лесов, то это не в моем посте нужно описывать :) Это уже не «небольшие организации».
— написать про различия между группами, и применении их на практике… ох. напишу, но потом. :)
Спасибо за критику, единственно прошу, не забывайте про неуниверсальность этих статей. Все таки есть определенная разница между решениями для 300 пользователей и решениями для 3000 пользователей.
если конкретно, то
— ваш метод «делаем одну две группы и назначаем им необходимые права которые одинаковы для всех (Бухгалтерия=1C+RDP+папкаБухгалтерия+т.д.)» мне лично не очень нравится. т.к. вы создаете группу, обладающую «множество прав», в которое потом вводите туда всех кто приблизительно должен обладать этими правами. а если человек бухгалтер, а ему не все базы нужны, или продажник но по отдельному направдению, или бухгалетр, но без доступа к терминалу и т.д. Я считаю лучше сделать множество групп, и потом из этих групп-кирпичиков «строить» каждому пользователю его личное «множество прав». Это более избирательно и гибко на мой взгляд.
— чтобы достигнуть ситуации как описывал выше makc_de, надо сильно постараться. 1000 групп у человека это конечно перебор. По опыту (а я не устаю напоминать какой он у меня, в организациях какого размера полученный) больше чем 200-300 групп (вообще! не у одного пользователя) в организациях среднего размера не было ни разу.
— отношение к скриптам у каждого свое. иногда скрипты полезны, иногда готовое решение дорого или недостаточно функционально, а иногда наоборот скрипты кривы и только ухудшают ситуацию. Тут единого рецепта наверное нет.
— назначать доступ на папки которые 3+ уровня вниз — это как-то перебор на мой взгляд. Если нужна группа для коллективного доступа — выносите ее выше, максимум на 2 уровень, зачем глубже то? Ну и то же самое касается названий папок. У нас было единой для всех правило: если папка имеет особые права, то она называется по английски и одним словом максимум 2-3 словами без пробелов. Поэтому проблем особых мы как вы понимаете не испытывали
— когда ресурсы лежат на конкретном сервере, то почему бы не ввести эти ресурсы в DFS? Мы всегда придерживались этого правила, и не столкнулись с ситуацией когда его невозможно было бы применить.
— когад в лесу несколько доменов, или вообще несколько лесов, то это не в моем посте нужно описывать :) Это уже не «небольшие организации».
— написать про различия между группами, и применении их на практике… ох. напишу, но потом. :)
Спасибо за критику, единственно прошу, не забывайте про неуниверсальность этих статей. Все таки есть определенная разница между решениями для 300 пользователей и решениями для 3000 пользователей.
перечитал свой коммент — действительно как-то резковато получилось. прошу прощения.
тема несколько зацепила :)
«мне лично не очень нравится. т.к. вы создаете группу, обладающую «множество прав», в которое потом вводите туда всех кто приблизительно должен обладать этими правами»
не совсем так. с тем, что собирать «по кирпичикам» гораздо правильнее и надежнее, я с вами абсолютно согласен. только вот когда движуха персонала человек 10 в месяц и больше — на кирпичики уходит неприлично много времени. да и риск ошибок возрастает. (хотя конечно, если в конторе со 100 человеками 5+ админов, это смешные цифры. а если 1-2...)
плюс, опять же, если структура конторы меняется каждые полгода, перепахивать права на каждом юзвере по отдельности — еще та задачка. даже если раз в год — неделя обычно выкинута на изменения и устранения косяков. даже если членство в группах менять не руками, а через скрипты.
плюс, просто может быть у меня не было такого, чтобы 1 бух мог работать с 1с, а другой такой же нет. т.е. внутри отдела/группы отдела, функционал был одинаковый.
что же касается «индивидуальных прав» — группы «бух зп», «бух ос» и тд. и есть те самые нужые права из «множества, доступных отделу/департаменту». например, у вас 3 расчетчика, 3 на ОС и тд. весьма маловероятно, что один расчетчик будет ходить на терминал, а другой работать с ПК. аналогично и с другими.
если отвлечься от бухов, возьмем например, «сметчик» и «сметчик выездной». можно набрать «по кирпичикам» права каждому сотруднику (СПО, ФС, БД, РДП/ВПН, НОУТ), а можно наполнить обе роли и конкретному сотруднику дать одну из них. или сделать роли дополняющими: «сметчик» + «мобильный сотрудник».
при первом варианте мы даже сможем легко давать отчет руководству «сколько у нас мобильных сотрудников такого-то отдела» и тп. при втором варианте, ответить тоже сможем, но уже нужно будет искать пересечение множеств.
и таки да, тут уже общего рецепта точно не будет.
и к вопросу о «кирпичиках», «сб» и тд — может быть вы отдельным постом осветите процесс изменения? т.е. те самые вопросы по «добавлению/удалению кирпичиков» людям, автоматизированность применения изменений на ПК/серверах (см. коммент ниже про «убрать ярлык») и тп. мне почему-то кажется, что при таком подходе у вас эта штука должна быть очень четко проработанной. и скорее всего, расхождение взглядов на группы связано именно с протеканием процессов изменений.
«назначать доступ на папки которые 3+ уровня вниз — это как-то перебор на мой взгляд»
конторы бывают разные. почему 3+ уровня? например, есть куча департаментов, есть куча отделов, есть куча проектов. сделать «сразу хорошо», отделив проекты от отделов не всегда получается. в внутрь отделов/проектов нужно давать доступ сотрудникам других подразделений.
хотя конечно да, если как у вас, руководство положительно смотрит на правильную организацию хранения, такие права и не требуются.
«Тут единого рецепта наверное нет»
почему я упомянул скрипты как нежелательное — написание скриптов это уже оттенок программизма. соответственно, нужно чтобы админ имел и опыт скриптописания и желание возиться со скриптами. а при смене админов, это получается далеко не всегда. (опять же, вопрос движения персонала)
и в отличие от скриптов, показать инструкцию/доку от софтины гораздо проще и надежнее.
(и, кстати, отдельной стезей идет «самописное ПО, которое пишется отцом-основателем» и ситуация когда «отец-основатель» уходит из конторы. в лучшем случае, ПО просто перестает развиваться...)
«когда ресурсы лежат на конкретном сервере, то почему бы не ввести эти ресурсы в DFS»
в принципе согласен, если СПО не кривое, то вполне можно.
«Это уже не «небольшие организации».»
ммм… как сказать. вот скажем, есть контора. покупает другую контору. в присоединяемой организации обычно уже есть свое ИТ-хозяйство. если присоединяется не одна, а несколько контор, то и доменов уже становится несколько. и вариантов становится два: или все конторы вводить в основной лес/домен или настраивать связи между ними. если же ИТ новой конторы остается самостоятельным, то остается только второй вариант — проще дать указания по обеспечению связи, чем разгребать внутреннюю сеть.
и так да, речь о конторах меньше 500 человек, связанных с компами :)
зы: если что, это не критика, это скорее желание понять причины принятых решений, их плюсы и минусы для дальнейшего использования.
ззы: а на тему СКС/каналов связи у вас планируется пост-другой? было бы интересно почитать, особенно, если решения вырабатывались в процессе переездов внутри здания/в другие здания и тд.
тема несколько зацепила :)
«мне лично не очень нравится. т.к. вы создаете группу, обладающую «множество прав», в которое потом вводите туда всех кто приблизительно должен обладать этими правами»
не совсем так. с тем, что собирать «по кирпичикам» гораздо правильнее и надежнее, я с вами абсолютно согласен. только вот когда движуха персонала человек 10 в месяц и больше — на кирпичики уходит неприлично много времени. да и риск ошибок возрастает. (хотя конечно, если в конторе со 100 человеками 5+ админов, это смешные цифры. а если 1-2...)
плюс, опять же, если структура конторы меняется каждые полгода, перепахивать права на каждом юзвере по отдельности — еще та задачка. даже если раз в год — неделя обычно выкинута на изменения и устранения косяков. даже если членство в группах менять не руками, а через скрипты.
плюс, просто может быть у меня не было такого, чтобы 1 бух мог работать с 1с, а другой такой же нет. т.е. внутри отдела/группы отдела, функционал был одинаковый.
что же касается «индивидуальных прав» — группы «бух зп», «бух ос» и тд. и есть те самые нужые права из «множества, доступных отделу/департаменту». например, у вас 3 расчетчика, 3 на ОС и тд. весьма маловероятно, что один расчетчик будет ходить на терминал, а другой работать с ПК. аналогично и с другими.
если отвлечься от бухов, возьмем например, «сметчик» и «сметчик выездной». можно набрать «по кирпичикам» права каждому сотруднику (СПО, ФС, БД, РДП/ВПН, НОУТ), а можно наполнить обе роли и конкретному сотруднику дать одну из них. или сделать роли дополняющими: «сметчик» + «мобильный сотрудник».
при первом варианте мы даже сможем легко давать отчет руководству «сколько у нас мобильных сотрудников такого-то отдела» и тп. при втором варианте, ответить тоже сможем, но уже нужно будет искать пересечение множеств.
и таки да, тут уже общего рецепта точно не будет.
и к вопросу о «кирпичиках», «сб» и тд — может быть вы отдельным постом осветите процесс изменения? т.е. те самые вопросы по «добавлению/удалению кирпичиков» людям, автоматизированность применения изменений на ПК/серверах (см. коммент ниже про «убрать ярлык») и тп. мне почему-то кажется, что при таком подходе у вас эта штука должна быть очень четко проработанной. и скорее всего, расхождение взглядов на группы связано именно с протеканием процессов изменений.
«назначать доступ на папки которые 3+ уровня вниз — это как-то перебор на мой взгляд»
конторы бывают разные. почему 3+ уровня? например, есть куча департаментов, есть куча отделов, есть куча проектов. сделать «сразу хорошо», отделив проекты от отделов не всегда получается. в внутрь отделов/проектов нужно давать доступ сотрудникам других подразделений.
хотя конечно да, если как у вас, руководство положительно смотрит на правильную организацию хранения, такие права и не требуются.
«Тут единого рецепта наверное нет»
почему я упомянул скрипты как нежелательное — написание скриптов это уже оттенок программизма. соответственно, нужно чтобы админ имел и опыт скриптописания и желание возиться со скриптами. а при смене админов, это получается далеко не всегда. (опять же, вопрос движения персонала)
и в отличие от скриптов, показать инструкцию/доку от софтины гораздо проще и надежнее.
(и, кстати, отдельной стезей идет «самописное ПО, которое пишется отцом-основателем» и ситуация когда «отец-основатель» уходит из конторы. в лучшем случае, ПО просто перестает развиваться...)
«когда ресурсы лежат на конкретном сервере, то почему бы не ввести эти ресурсы в DFS»
в принципе согласен, если СПО не кривое, то вполне можно.
«Это уже не «небольшие организации».»
ммм… как сказать. вот скажем, есть контора. покупает другую контору. в присоединяемой организации обычно уже есть свое ИТ-хозяйство. если присоединяется не одна, а несколько контор, то и доменов уже становится несколько. и вариантов становится два: или все конторы вводить в основной лес/домен или настраивать связи между ними. если же ИТ новой конторы остается самостоятельным, то остается только второй вариант — проще дать указания по обеспечению связи, чем разгребать внутреннюю сеть.
и так да, речь о конторах меньше 500 человек, связанных с компами :)
зы: если что, это не критика, это скорее желание понять причины принятых решений, их плюсы и минусы для дальнейшего использования.
ззы: а на тему СКС/каналов связи у вас планируется пост-другой? было бы интересно почитать, особенно, если решения вырабатывались в процессе переездов внутри здания/в другие здания и тд.
Интересный подход, спасибо.
Как вы решаете проблему с оставшимся ярлыком после лишения пользователя членства в группе?
Как вы решаете проблему с оставшимся ярлыком после лишения пользователя членства в группе?
Мы — никак не решаем, т.к. это не предусмотрели просто. :)
А вообще, у пользователя несмотря на оставшийся ярлык, при удалении из группы пропадают права на те ресурсы куда вел ярлык. т.е. кроме захламления рабочего стола пользователя это ничем особым не грозит.
Ну и угроза безопасности, конечно, куда без нее.
А вообще, у пользователя несмотря на оставшийся ярлык, при удалении из группы пропадают права на те ресурсы куда вел ярлык. т.е. кроме захламления рабочего стола пользователя это ничем особым не грозит.
Ну и угроза безопасности, конечно, куда без нее.
Sign up to leave a comment.
Опытные мелочи-5, или «Групповые радости!»