Мы — никак не решаем, т.к. это не предусмотрели просто. :)
А вообще, у пользователя несмотря на оставшийся ярлык, при удалении из группы пропадают права на те ресурсы куда вел ярлык. т.е. кроме захламления рабочего стола пользователя это ничем особым не грозит.
Ну и угроза безопасности, конечно, куда без нее.
Ну тут конечно можно спорить, и конечная реализация сильно зависит от нужд самой компании.
если конкретно, то
— ваш метод «делаем одну две группы и назначаем им необходимые права которые одинаковы для всех (Бухгалтерия=1C+RDP+папкаБухгалтерия+т.д.)» мне лично не очень нравится. т.к. вы создаете группу, обладающую «множество прав», в которое потом вводите туда всех кто приблизительно должен обладать этими правами. а если человек бухгалтер, а ему не все базы нужны, или продажник но по отдельному направдению, или бухгалетр, но без доступа к терминалу и т.д. Я считаю лучше сделать множество групп, и потом из этих групп-кирпичиков «строить» каждому пользователю его личное «множество прав». Это более избирательно и гибко на мой взгляд.
— чтобы достигнуть ситуации как описывал выше makc_de, надо сильно постараться. 1000 групп у человека это конечно перебор. По опыту (а я не устаю напоминать какой он у меня, в организациях какого размера полученный) больше чем 200-300 групп (вообще! не у одного пользователя) в организациях среднего размера не было ни разу.
— отношение к скриптам у каждого свое. иногда скрипты полезны, иногда готовое решение дорого или недостаточно функционально, а иногда наоборот скрипты кривы и только ухудшают ситуацию. Тут единого рецепта наверное нет.
— назначать доступ на папки которые 3+ уровня вниз — это как-то перебор на мой взгляд. Если нужна группа для коллективного доступа — выносите ее выше, максимум на 2 уровень, зачем глубже то? Ну и то же самое касается названий папок. У нас было единой для всех правило: если папка имеет особые права, то она называется по английски и одним словом максимум 2-3 словами без пробелов. Поэтому проблем особых мы как вы понимаете не испытывали
— когда ресурсы лежат на конкретном сервере, то почему бы не ввести эти ресурсы в DFS? Мы всегда придерживались этого правила, и не столкнулись с ситуацией когда его невозможно было бы применить.
— когад в лесу несколько доменов, или вообще несколько лесов, то это не в моем посте нужно описывать :) Это уже не «небольшие организации».
— написать про различия между группами, и применении их на практике… ох. напишу, но потом. :)
Спасибо за критику, единственно прошу, не забывайте про неуниверсальность этих статей. Все таки есть определенная разница между решениями для 300 пользователей и решениями для 3000 пользователей.
Это бывает. И в принципе все можно вытащить из логов Windows (традиционно принтера подключены через принт-сервера, т.е. есть единая точка сбора логов).
Но автоматизированного способа предложить не могу, т.к. на моем веку это было от силы несколько раз и каждый раз делалось тупо вручную: вытаскивались логи, загонялись в Excel, парсились на предмет нужного пользователя и т.д.
Наверняка есть всевозможный платный софт который эту задачу решает. На то он и платный софт.
Пробовали. Тогда это, кажется, называлось как-то иначе.
Там все красиво и здорово, но нам не подошло по трем причинам:
— тогда там не было автоматического режима, оно не работало как сервис. нельзя было один раз настроить и забыть.
— оно показывало много интересного, но нельзя было выдавать данные куда то в стороннее приложение, «для анализу».
— у нас немалое количество не-НР принтеров, а хотелось чтобы решение было универсальное. Скрипт этому требованию полностью удовлетворил.
Я тоже эти продукты не щупал, так что мы с вами говорим про кота в мешке, но по идее из бэкапа Exchange можно извлекать конкретные письма или ящики только восстановив всю базу в т.н. Recovery Group, и дальше уж вытаскивая все что душе угодно.
Вытаскивать ящики прямо из самого бэкапа можно разве что специальными утилитами какими нибудь.
Можно чем то вроде вот такого скрипта: On Error Resume Next
Set Network = WScript.CreateObject(«Wscript.network»)
Set oShell = CreateObject(«Shell.Application»)
Set FSO = CreateObject(«Scripting.FileSystemObject»)
'==================================================
'Создаем папку пользователю с именем его логина
'==================================================
UName = Network.UserName
If Not fso.FolderExists("\\domain\root\Users\" & UName) Then
Set objFolder = FSO.CreateFolder("\\domain\root\Users\" & UName)
End If
'==================================================
'Подключаем диск и даем ему имя
'==================================================
Network.RemoveNetworkDrive «Z:»
DiskPath = "\\domain\root\Users\" & UName
Network.MapNetworkDrive «Z:», diskpath
oShell.NameSpace(«z:\»).Self.Name = «UsersFolder»
я много раз писал и видимо буду продолжать писать о том, что мой опыт связан с небольшими организациями. Это накладывает свой отпечаток.
Кроме того, первый совет о том, что в ACL, Group Policy и иже с ними лучше использовать группы, а не отдельных людей. В вашей же ситуации проблема была в слишком большом числе групп. Это несколько разные вещи, не находите?
Да, возможно и такое, наверное это даже не экстремально, а действительно необходимо в ОЧЕНЬ большой организации, но это ведь не умаляет достоинства использования групп в сравнении с пользователями? М?
Кстати, а у проблемных пользователей сколько групп было? И какой уровень домена-леса? Интересно :)
Компьютер это такая же (ну почти) учетка как и пользователь. И у него тоже есть пароль :)
А что вы никогда не сталкивались с ситуацией что если доменный компьютер некоторое время не включался в сеть, то потом он отказывается входить в домен? Это его т.н. пароль истек.
Если это файловые данные — то правильнее стремится к тому, чтобы все важные файлы лежали в сети (соответственно бэкап работает на стороне сервера).
На мой взгляд идеальная ситуация, это когда при поломке рабочей станции пользователь тупо пересаживается на соседнюю, вводит свой логин-пароль и после некоторых первоначальных (автоматических) настроек продолжает работать дальше. тогда на стороне клиента вообще бэкапить ничего не надо.
А если все таки надо (клиент банки, спец-по и т.д.), и бэкапите не специализированным ПО (типа Symantec с его агентами, или тем же DLO) а скриптом, то запускайте на стороне клиента. Так вы убираете лишнее звено (из цепочки «ЗапускСкриптаНаСервере-ОбращениеНаРабСтанцию-КладемБэкапНаСервер» убираются не нужные первых два шага).
И не забывайте про уведомления. Вы должны ежеутренне приходя на работу видеть сводку ночных бэкапов в сжатом и толковом виде, а не лазить по серверам и их консолям полчаса, выясняя где что и как отработало.
Достаточно. Но практика — критерий истины. Просто возьмите и попробуйте.
Помните что Authenthicated Users это весьма широкое понятие, и лучше придерживаться правила: «давать только необходимое».
Я бы лично дал бы права той группе, спомощью которой вы ставите софт.
Ну вот например:
сделали группу UNC_MegaSoft, чтобы устанавливать ваш MegaSoft по UNC путям.
написали скрипт, который устанавливает все что нужно для тех, кто входит в группу UNC_MegaSoft
добавили в эту группу ряд компьютеров.
тогда логично будет назначить на шару права для группы UNC_MegaSoft. убрав все лишнее. В этом случае у вас гарантированно будут права для тех, кому скрипт будет ставить ваш софт, и не будет прав у тех, кто не в группе, и кому это не нужно.
прокатит.
ну и не нужно наверное напоминать что в этом случае в группе должен состоять компьютер, и скрипт должен запускаться в разделе компьютера (Group Policy — Computer Configuration — Windows Settings — Scripts ) а не пользователя.
Этот скрипт был написан, когда Group Policy Preferences мы еще не использовали, и чтобы раздать ярлыки на сетевые RDP-файлы все равно нужно было писать логон-скрипт, который эти «ярлыки на ярлыки» создавал бы. Мы решили не городить огород и создавать сразу RDP-файлы.
С одной стороны некоторая отказоустойчивость (если недоступен файловый сервер, то все равно можно зайти в терминал поработать, ага?)
С другой тут важен не процесс создания RDP-файла, а именно управление кому какой ярлык на основе членства у группе. У нас было тогда довольно много разных терминалов, и разных групп людей, которым нужно было одно, но не нужно было другое, а через полгода ситуация менялась в обратную сторону. Написанный скрипт позволил делегировать управление членством в группах RDP_ ответственному лицу, начальнику их отдела, и этот вопрос свалился с наших плеч.
Ой, что это я. Не свалился — был делегирован :)
Я исходил из следующих соображений:
— «месячные» диски это отдельные диски, они используются редко, раз в месяц, и по умолчанию «сыпаться» не должны
— исходя из наших объемов, на один 2 ТБ диск влезает 2 месячных бэкапа с некоторым запасом на будущее, соответственно если он сгорит — то мы потеряем максимум наш архив-бэкап за два месяца, причем не по порядку. т.к. на каждом конкретном диске только два месячных архива, и мы их чередуем (январь-март, февраль-апрель и т.д.). Ситуация выглядит не такой уж страшной.
— кроме того возможны варианты, например: например незаслуженно забытое копирование на ВНЕШНИЕ «месячные» диски (их можно насовать хоть гроздью из 12 штук, по одному на каждый месяц) или копирование на диск и складирование в сейф руководителя (некий такой не совсем архив, но и уже не бэкап, дешевая альтернатива хранению ВНЕ офиса). Последний вариант (копирование на внешний диск, например через крэдл, и отключение его от сервера на год) вообще на мой взгляд весьма приемлем, если закрыть глаза на необходимость ручных действий.
— и последнее: обращение к месячным бэкапам на моей практике скорее исключение чем правило, и когда просят восстановить что-то старее, чем несколько месяцев, то обычно точных дат не просят, люди вполне готовы удовлетвориться не «мартом» а «январем».
А вообще, у пользователя несмотря на оставшийся ярлык, при удалении из группы пропадают права на те ресурсы куда вел ярлык. т.е. кроме захламления рабочего стола пользователя это ничем особым не грозит.
Ну и угроза безопасности, конечно, куда без нее.
если конкретно, то
— ваш метод «делаем одну две группы и назначаем им необходимые права которые одинаковы для всех (Бухгалтерия=1C+RDP+папкаБухгалтерия+т.д.)» мне лично не очень нравится. т.к. вы создаете группу, обладающую «множество прав», в которое потом вводите туда всех кто приблизительно должен обладать этими правами. а если человек бухгалтер, а ему не все базы нужны, или продажник но по отдельному направдению, или бухгалетр, но без доступа к терминалу и т.д. Я считаю лучше сделать множество групп, и потом из этих групп-кирпичиков «строить» каждому пользователю его личное «множество прав». Это более избирательно и гибко на мой взгляд.
— чтобы достигнуть ситуации как описывал выше makc_de, надо сильно постараться. 1000 групп у человека это конечно перебор. По опыту (а я не устаю напоминать какой он у меня, в организациях какого размера полученный) больше чем 200-300 групп (вообще! не у одного пользователя) в организациях среднего размера не было ни разу.
— отношение к скриптам у каждого свое. иногда скрипты полезны, иногда готовое решение дорого или недостаточно функционально, а иногда наоборот скрипты кривы и только ухудшают ситуацию. Тут единого рецепта наверное нет.
— назначать доступ на папки которые 3+ уровня вниз — это как-то перебор на мой взгляд. Если нужна группа для коллективного доступа — выносите ее выше, максимум на 2 уровень, зачем глубже то? Ну и то же самое касается названий папок. У нас было единой для всех правило: если папка имеет особые права, то она называется по английски и одним словом максимум 2-3 словами без пробелов. Поэтому проблем особых мы как вы понимаете не испытывали
— когда ресурсы лежат на конкретном сервере, то почему бы не ввести эти ресурсы в DFS? Мы всегда придерживались этого правила, и не столкнулись с ситуацией когда его невозможно было бы применить.
— когад в лесу несколько доменов, или вообще несколько лесов, то это не в моем посте нужно описывать :) Это уже не «небольшие организации».
— написать про различия между группами, и применении их на практике… ох. напишу, но потом. :)
Спасибо за критику, единственно прошу, не забывайте про неуниверсальность этих статей. Все таки есть определенная разница между решениями для 300 пользователей и решениями для 3000 пользователей.
Но автоматизированного способа предложить не могу, т.к. на моем веку это было от силы несколько раз и каждый раз делалось тупо вручную: вытаскивались логи, загонялись в Excel, парсились на предмет нужного пользователя и т.д.
Наверняка есть всевозможный платный софт который эту задачу решает. На то он и платный софт.
Там все красиво и здорово, но нам не подошло по трем причинам:
— тогда там не было автоматического режима, оно не работало как сервис. нельзя было один раз настроить и забыть.
— оно показывало много интересного, но нельзя было выдавать данные куда то в стороннее приложение, «для анализу».
— у нас немалое количество не-НР принтеров, а хотелось чтобы решение было универсальное. Скрипт этому требованию полностью удовлетворил.
Вытаскивать ящики прямо из самого бэкапа можно разве что специальными утилитами какими нибудь.
On Error Resume Next
Set Network = WScript.CreateObject(«Wscript.network»)
Set oShell = CreateObject(«Shell.Application»)
Set FSO = CreateObject(«Scripting.FileSystemObject»)
'==================================================
'Создаем папку пользователю с именем его логина
'==================================================
UName = Network.UserName
If Not fso.FolderExists("\\domain\root\Users\" & UName) Then
Set objFolder = FSO.CreateFolder("\\domain\root\Users\" & UName)
End If
'==================================================
'Подключаем диск и даем ему имя
'==================================================
Network.RemoveNetworkDrive «Z:»
DiskPath = "\\domain\root\Users\" & UName
Network.MapNetworkDrive «Z:», diskpath
oShell.NameSpace(«z:\»).Self.Name = «UsersFolder»
WScript.Quit
Кроме того, первый совет о том, что в ACL, Group Policy и иже с ними лучше использовать группы, а не отдельных людей. В вашей же ситуации проблема была в слишком большом числе групп. Это несколько разные вещи, не находите?
Да, возможно и такое, наверное это даже не экстремально, а действительно необходимо в ОЧЕНЬ большой организации, но это ведь не умаляет достоинства использования групп в сравнении с пользователями? М?
Кстати, а у проблемных пользователей сколько групп было? И какой уровень домена-леса? Интересно :)
А что вы никогда не сталкивались с ситуацией что если доменный компьютер некоторое время не включался в сеть, то потом он отказывается входить в домен? Это его т.н. пароль истек.
Если это файловые данные — то правильнее стремится к тому, чтобы все важные файлы лежали в сети (соответственно бэкап работает на стороне сервера).
На мой взгляд идеальная ситуация, это когда при поломке рабочей станции пользователь тупо пересаживается на соседнюю, вводит свой логин-пароль и после некоторых первоначальных (автоматических) настроек продолжает работать дальше. тогда на стороне клиента вообще бэкапить ничего не надо.
А если все таки надо (клиент банки, спец-по и т.д.), и бэкапите не специализированным ПО (типа Symantec с его агентами, или тем же DLO) а скриптом, то запускайте на стороне клиента. Так вы убираете лишнее звено (из цепочки «ЗапускСкриптаНаСервере-ОбращениеНаРабСтанцию-КладемБэкапНаСервер» убираются не нужные первых два шага).
И не забывайте про уведомления. Вы должны ежеутренне приходя на работу видеть сводку ночных бэкапов в сжатом и толковом виде, а не лазить по серверам и их консолям полчаса, выясняя где что и как отработало.
Помните что Authenthicated Users это весьма широкое понятие, и лучше придерживаться правила: «давать только необходимое».
Я бы лично дал бы права той группе, спомощью которой вы ставите софт.
Ну вот например:
ну и не нужно наверное напоминать что в этом случае в группе должен состоять компьютер, и скрипт должен запускаться в разделе компьютера (Group Policy — Computer Configuration — Windows Settings — Scripts ) а не пользователя.
С одной стороны некоторая отказоустойчивость (если недоступен файловый сервер, то все равно можно зайти в терминал поработать, ага?)
С другой тут важен не процесс создания RDP-файла, а именно управление кому какой ярлык на основе членства у группе. У нас было тогда довольно много разных терминалов, и разных групп людей, которым нужно было одно, но не нужно было другое, а через полгода ситуация менялась в обратную сторону. Написанный скрипт позволил делегировать управление членством в группах RDP_ ответственному лицу, начальнику их отдела, и этот вопрос свалился с наших плеч.
Ой, что это я. Не свалился — был делегирован :)
— «месячные» диски это отдельные диски, они используются редко, раз в месяц, и по умолчанию «сыпаться» не должны
— исходя из наших объемов, на один 2 ТБ диск влезает 2 месячных бэкапа с некоторым запасом на будущее, соответственно если он сгорит — то мы потеряем максимум наш архив-бэкап за два месяца, причем не по порядку. т.к. на каждом конкретном диске только два месячных архива, и мы их чередуем (январь-март, февраль-апрель и т.д.). Ситуация выглядит не такой уж страшной.
— кроме того возможны варианты, например: например незаслуженно забытое копирование на ВНЕШНИЕ «месячные» диски (их можно насовать хоть гроздью из 12 штук, по одному на каждый месяц) или копирование на диск и складирование в сейф руководителя (некий такой не совсем архив, но и уже не бэкап, дешевая альтернатива хранению ВНЕ офиса). Последний вариант (копирование на внешний диск, например через крэдл, и отключение его от сервера на год) вообще на мой взгляд весьма приемлем, если закрыть глаза на необходимость ручных действий.
— и последнее: обращение к месячным бэкапам на моей практике скорее исключение чем правило, и когда просят восстановить что-то старее, чем несколько месяцев, то обычно точных дат не просят, люди вполне готовы удовлетвориться не «мартом» а «январем».