Влияет ли AD на ПО пользователя?

[hozman]

Читаю книгу и статьи по тиху. В ближайшее время нужно будет развернуть домен. Хоть и не слишком большой, но тем не менее.
На данный момент, прочёл пару сотен страниц, и, понял, что, в основном, AD позволяет управлять доступом к ресурсам (каталогам т.е. папкам), а также централизованно устанавливать ПО.
Возникла парочка вопросов.
1. Можно ли запретить пользователям запускать ПО, которое не нужно. По критерий не нужности привести всё, что не входит в стандартный флакон винды, т.е. практически ничего, даже меньше + некоторое ПО, которое нужно для работы. Подобных механизмов я пока что не встретил. Народ у нас постоянно понакачает всякой чуши, типа менеджеров браузеров, Амиг и всякой дряни. Потом приходится выметать всё это метлой. Мне надоело. Вот решил упорядочить всё по тиху.
2. На компьютере у бухгалтера уже установлено ПО для работы с банком. Имеется ПО Radius, 1С-ка, клиент банки и многое другое. Если я подключаю его к домену, оно всё будет работать или возникнут некоторые грабли? Может ли AD в чём-то ограничить рботу ПО, установленное на машине клиента изначально т.е. до подключения его к домену?
3. Если машина в домене, ПО устанавливать нужно через домен или не обязательно? Естественно, при наличии прав...

[Iska]

1. Можно ли запретить пользователям запускать ПО, которое не нужно. »
Можно.

Политики ограниченного использования программ.
AppLocker (https://www.google.ru/search?q=AppLocker).


Народ у нас постоянно понакачает всякой чуши, типа менеджеров браузеров, Амиг и всякой дряни. Потом приходится выметать всё это метлой. Мне надоело. Вот решил упорядочить всё по тиху. »
Для начала пользователи должны быть пользователями. У Вас как с этим — пользователи, они же администраторы?

2. На компьютере у бухгалтера уже установлено ПО для работы с банком. Имеется ПО Radius, 1С-ка, клиент банки и многое другое. Если я подключаю его к домену, оно всё будет работать или возникнут некоторые грабли? Может ли AD в чём-то ограничить рботу ПО, установленное на машине клиента изначально т.е. до подключения его к домену? »
Грабли могут возникнуть в вышеуказанном случае — если сейчас пользователь-администратор, которого надо будет перевести в обычного пользователя. У меня, впрочем, с этим проблемы не возникло. Из-за подключения к домену проблем быть не должно.

3. Если машина в домене, ПО устанавливать нужно через домен или не обязательно? Естественно, при наличии прав... »
Крайне желательно.

[hozman]

Для начала пользователи должны быть пользователями. У Вас как с этим — пользователи, они же администраторы? »
Обычно я делаю на компьютерах по 2 пользователям. Администратор - только для установки всего, и пользователь с ограниченными правами- для работы. Но иногда бывает так, что пользователь с ограниченными правами не может работать в некоторых программах. Сколько не пытался, например, с некоторыми клиентами, например, у снабженцев ПО для торгов (там ключ есть для торгов древесиной и т.п.) не вышло. Пришлось давать админские права.
Я так понимаю, что на локальной машине может быть пользователь администратором, но в домене то он будет уже не админ. Тогда разница то какая. Ведь как? Локально админ, но он же по факту будет в домене. И получается, что локальное админство ему уже не даст всех привелегий? Или не так?

[Iska]

Не совсем. Локальный администратор имеет все привилегии на машине.

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

[El Scorpio]

1. Можно ли запретить пользователям запускать ПО, которое не нужно. По критерий не нужности привести всё, что не входит в стандартный флакон винды, т.е. практически ничего, даже меньше + некоторое ПО, которое нужно для работы. »
Групповые политики содержат раздел "политики ограниченного использования программ"

На компьютере у бухгалтера уже установлено ПО для работы с банком. Имеется ПО Radius, 1С-ка, клиент банки и многое другое. Если я подключаю его к домену, оно всё будет работать или возникнут некоторые грабли? »
Если часть настроек программ содержится в файлах/реестре профиля пользователя, значит нужно будет скопировать эти объекты в профиль доменного пользователя или произвести повторную настройку ПО. Однако часть настроек может быть привязана к UUID локального профиля.

Но иногда бывает так, что пользователь с ограниченными правами не может работать в некоторых программах. Сколько не пытался, например, с некоторыми клиентами, например, у снабженцев ПО для торгов (там ключ есть для торгов древесиной и т.п.) не вышло. »
Увы, до сих пор не удалось окончательно вывести паразитический вид Programmist 95, представители которого привыкли писать под однопользовательские системы вроде Windows 95 и совершенно не задумываются о том, как будут работать их продукты жизнедеятельности в современных многопользовательских системах с контролем доступа.
Единственное решение - запустить программу Procmon и смотреть, к каким файлам и разделам реестра обращается проблемное ПО. Затем можно (вручную или через групповые политики) назначить этим объектам дополнительные разрешения.

Если машина в домене, ПО устанавливать нужно через домен или не обязательно? »
Дистрибутивы msi проще всего развёртывать через групповые политики домена. К тому же это гарантирует единообразие набора ПО и актуальность версий.
Если дистрибутив сделан по иному принципу, тогда придётся устанавливать вручную. Существует возможность сделать для установщика обёртку msi или подготовить установочный пакет для локальной службы WSUS. Также сервер антивирусной защиты Касперского может создавать свои установочные пакеты.

[Trouble_Maker]

1. Как уже было указано, SRP (Software Restriction Policy) и Applocker, правда Applocker требует наличия клиентов с ОС не ниже Windows 7 Максимальная\Корпоративная. Выдачу административных прав пользователям лучше всего избегать (только по доказанной необходимости). Большему количеству адекватного софта не требуются права администратора, достаточно выдать права на папки или разделы реестра в которые этот софт пишет данные.
2. Проблем быть не должно.
3. А для чего Вам тогда домен, Вы же его для централизованного управления установили, софт можете раздавать политиками, либо скриптами\батфайлами инициализирующими установку софта из сетевой папки, как вариант.

[hozman]

Не совсем. Локальный администратор имеет все привилегии на машине. »
Странно. Я думал, что если ПК участник домена, то у него права только те, которые ему разрешает домен.Групповые политики содержат раздел "политики ограниченного использования программ" »
У меня почему-то в политиках нет такого. По дефолту не устанавливается данная роль?
Дистрибутивы msi проще всего развёртывать через групповые политики домена. К тому же это гарантирует единообразие набора ПО и актуальность версий. »
У меня много машин ещё на XP. Это не имеет значения?

[Trouble_Maker]

Странно. Я думал, что если ПК участник домена, то у него права только те, которые ему разрешает домен. »Локальный администратор он на то и локальный, что имеет административные права лишь на конкретной машине (само собой, например, на КД он никто)
У меня почему-то в политиках нет такого. По дефолту не устанавливается данная роль? »Это не роль. Редактор групповых политик, ветка Конфигурация компьютера\Конфигурация Windows\Параметры безопасности\Политики ограниченного использования программ
У меня много машин ещё на XP. Это не имеет значения? »Нет.

[El Scorpio]

Цитата Iska:
Не совсем. Локальный администратор имеет все привилегии на машине. »
Странно. Я думал, что если ПК участник домена, то у него права только те, которые ему разрешает домен. »
Все компьютеры домена, не являющиеся контроллерами домена, используют две базы ACL - доменную (объекты обозначаются как "ИмяДомена\Объект") и локальную (обозначается как "ИмяКомпьютера\Объект").
При этом уровень пользователя определяются именно локальным ACL.
Разумеется, вы можете вручную указать на компьютере для определённых файлов или разделов реестра права доступа для доменных пользователей и групп. Однако основные системные права доступа при вводе компьютера в домен не изменяются. Просто доменные группы "Администраторы домена", "Пользователи домена" и "Гости домена" автоматически добавляются в состав соответствующих локальных групп.
Таким образом по схеме "доменная группа -> локальная группа -> системные полномочия" администратор домена Иванов на всех компьютерах домена будет администратором, пользователь домена Петров - пользователем, а гость домена Сидоров - гостем.
Однако если вы на каком-то компьютере добавите Петрова или Сидорова в локальную группу администраторов ("ЭтотКомпьютер\Администраторы"), то они будут работать на этом компьютере с правами администратора.
Они не смогут работать с чужими файлами и базами данных по сети (потому что на других компьютерах они будут рядовыми пользователями или даже гостями), однако поставить/удалить программу или изменить любую настройку на своём компьютере им будет вполне по силам.


Цитата El Scorpio:
Дистрибутивы msi проще всего развёртывать через групповые политики домена. К тому же это гарантирует единообразие набора ПО и актуальность версий. »

У меня много машин ещё на XP. Это не имеет значения? »
Хоть Win 2000.
Дистрибутивы MSI поддерживают все версии.
Для правильного определения языка при добавлении распакованного msi в доменную политику используйте соответствующий вариант файла модификации mst из исходного дистрибутива
В частности, это требует 1С:Предприятие 8.x

[hozman]

Локальный администратор он на то и локальный, что имеет административные права лишь на конкретной машине (само собой, например, на КД он никто) »
Ну так тогда смысл какой? Всегда делать пользователя хотя б 2 на каждой машине? 1 для установки ПО (админский), а другой ограниченный (пользователь). Так? Тогда локально давать пользователю только те папки которые ему нужны и всё. Только так?
Но, опять же, групповыми политиками локальной машины с домена нельзя разве управлять? (Вроде я такое читал).

[El Scorpio]

Ну так тогда смысл какой? Всегда делать пользователя хотя б 2 на каждой машине? 1 для установки ПО (админский), а другой ограниченный (пользователь). »
Нет, на компьютере в составе домена нужно делать только одного пользователя - локального администратора для установки и настройки программ. А оператор ЭВМ будет работать от имени доменного пользователя.

Другое дело, что возможны разные ситуации.
Например, пользователь использует программу, для которой не получилось найти причину, вызывающую необходимость использования прав администратора.
Другой вариант - пользователь занимается разработкой программного обеспечения и баз данных, и права локального администратора ему нужны для проверки своих наработок.

[hozman]

Нет, на компьютере в составе домена нужно делать только одного пользователя - локального администратора для установки и настройки программ. А оператор ЭВМ будет работать от имени доменного пользователя. »
В какой-то ветке мне кто-то отвечал, что рекомендуется устанавливать ПО через домен, а не локально. Получается этот админский аккаунт для того и нужен?
А для основной работы пользователь будет работать как оператор посредством аккаунт, созданный на контроллере домена, а не локально, верно?

Например, пользователь использует программу, для которой не получилось найти причину, вызывающую необходимость использования прав администратора. »
В таком случае давать ему права локального администратора?

[El Scorpio]

В какой-то ветке мне кто-то отвечал, что рекомендуется устанавливать ПО через домен, а не локально. Получается этот админский аккаунт для того и нужен? »
Не всё ПО можно установить через GPO.
К тому же здесь очень многое схоже с разницей между единичным, серийным и массовым производством.
Если нужно установить программу на много компьютеров - проще, быстрее и надёжнее подготовить дистрибутив автоустановки.
Если нужно установить программу на одно рабочее место - проще, быстрее и надёжнее сделать это вручную.

К тому же локальный админ нужен для устранения локальных проблем, в том числе ограничивающих сетевое взаимодействие.

Цитата El Scorpio:
Например, пользователь использует программу, для которой не получилось найти причину, вызывающую необходимость использования прав администратора. »
В таком случае давать ему права локального администратора? »
А куда деваться - приходится....
Но лучше таки выявить проблему.

[hozman]

Не всё ПО можно установить через GPO. »
Я так понимаю, что б установить локально ПО, нужно грубо говоря, высунуть сетевой кабель из сетевой карты машины клиента и войти локально на машину клиента, верно? А дальше устанавливать всё, что нужно... Если это не возможно через групповые политики, имею ввиду не именно не возможно а не вышло, или нет необходимости.
Выходит, так решается проблема установки ПО. Если нужно, можно установить программу через GPO, а если не нужно проще установить локально, и, несмотря на то, что машина находится в домене, это не будет мешать ей пользоваться установленными локально программами, верно?

Если нужно установить программу на много компьютеров - проще, быстрее и надёжнее подготовить дистрибутив автоустановки. »
Если по ходу установки программы требуется ввести лицензионный ключ, то тоже возможно сделать дистрибутив автоустановки?

[Iska]

Я так понимаю, что б установить локально ПО, нужно грубо говоря, высунуть сетевой кабель из сетевой карты машины клиента и войти локально на машину клиента, верно? А дальше устанавливать всё, что нужно... »
Нет. Кабель вынимать не нужно. Достаточно войти на машину локально или удалённо (под локальной или доменной учётной записью, обладающими достаточными привилегиями для установки приложений).

Если нужно, можно установить программу через GPO, а если не нужно проще установить локально, и, несмотря на то, что машина находится в домене, это не будет мешать ей пользоваться установленными локально программами, верно? »
Верно. Только не «проще», а «возможно».

Если по ходу установки программы требуется ввести лицензионный ключ, то тоже возможно сделать дистрибутив автоустановки? »
Если это предусмотрено. Например, ключ может вводиться при создании административной установки.

[alef2474]

а если не нужно проще установить локально, и, несмотря на то, что машина находится в домене, это не будет мешать ей пользоваться установленными локально программами, верно? »
Чаще всего и пользуются локально установленными программами, а не какими-то сетевыми. На сервере только если в rdp-сеансах - нелокальные программы.

Если это предусмотрено. Например, ключ может вводиться при создании административной установки. »

Это слишком мудреный ответ, который сразу приводит к вопросу: а для каких реальных программ есть эта административная установка с единым ключом?
Лучше не морочиться с этими GPO устаовками, если персонал не заставляет и есть время. Т.к. топикстартер задает простые очевидные вопросы, то сразу на большой домен он не попадет, а начнет с маленького, где можно обходиться без GPO и GPO вообще затруднительно присунуть.

[Iska]

Это слишком мудреный ответ, который сразу приводит к вопросу: а для каких реальных программ есть эта административная установка с единым ключом? »
Это слишком простой вопрос, который сразу приводит к ответу: для тех производителей ПО, которые не гнушаются зарабатывать на корпоративных лицензиях. Есть и ещё один ответ: существует масса приложений в формате msi-инсталляций, которые не требуют никаких ключей.

с маленького, где можно обходиться без GPO и GPO вообще затруднительно присунуть. »
Вы заблуждаетесь. Нет никаких минимальных ограничений по размеру для использования групповых политик для развёртывания приложений.

[hozman]

Если это предусмотрено. Например, ключ может вводиться при создании административной установки. »
Вы имеете ввиду при помощи софта для создания msi-пакетов?

Лучше не морочиться с этими GPO устаовками, если персонал не заставляет и есть время. Т.к. топикстартер задает простые очевидные вопросы, то сразу на большой домен он не попадет, а начнет с маленького, где можно обходиться без GPO и GPO вообще затруднительно присунуть. »
Вот именно. Не заставляют, но.. есть всякие там вещи типа браузеров, adobe flash player и тд, которые не хочется устанавливать отдельно каждому. Это как-бы сказать, себе же удобнее. Особенно, когда пользователи работают под ограниченными учётками. И приходить к ним, входить под админа, устанавливать каждую мелочь, в тот же момент выслушивать какой я плохой, за то что у них нет прав обновить всё, что они хотят, это не есть приятно и удобно, согласитесь? Вот потому я и распрашиваю. Т.к. собираюсь в течении месяца внедрять домен.

то сразу на большой домен он не попаде »
Вот именно. Машин до 100. А по поводу ключей это уже мысли наперёд. Например, есть же MS Word у меня. Есть ключ к нему. Есс-но если его установить, то проще сразу вшить ключ в дистрибутив.

Это слишком простой вопрос, который сразу приводит к ответу: для тех производителей ПО, которые не гнушаются зарабатывать на корпоративных лицензиях. Есть и ещё один ответ: существует масса приложений в формате msi-инсталляций, которые не требуют никаких ключей. »
А если всё же они( ключи ) требуются, тогда как?

[Iska]

Вы имеете ввиду при помощи софта для создания msi-пакетов? »
Я имею в виду другое: Использование ключей и свойств установщика Windows (http://www.oszone.net/9008).

А если всё же они( ключи ) требуются, тогда как? »
Общие принципы см. там же. А вообще — читать документацию на конкретное приложение. Для «толстых» и разветвлённых пакетов приложений могут быть облегчающие подготовку развёртывания Wizard'ы и т.п. Примеры использования можно найти в разделе Автоматическая установка Windows (http://www.oszone.net/2747/).

[alef2474]

Вы имеете ввиду при помощи софта для создания msi-пакетов? »
Он имел в виду, что в каких-то исключительных случаях бывают программы, для которых нужен один лицензионный ключ, вводимый предварительно на сервере, а для инсталляций через GPO-msi ключи на клиентских машинах вводить не нужно.

для тех производителей ПО, которые не гнушаются зарабатывать на корпоративных лицензиях. »
Так Iska ушел от прямого ответа назвать конкретные широко используемые лицензионные пакеты с административной установкой и соответственно с административными ключами. А без конкретики получается разговор ни о чем и GPO - получается для установки с ключами реально неприменимо, никчемно. GPO полезно, если шеф приказал у всех на компьютерах иметь одинаковую картинку рабстола с его любимым логотипом.

А по поводу ключей это уже мысли наперёд »
Вы правильно поняли слабое место этих GPO.

И приходить к ним, входить под админа, устанавливать каждую мелочь, в тот же момент выслушивать какой я плохой, за то что у них нет прав обновить всё, что они хотят, это не есть приятно и удобно, согласитесь? »
В случае домена тоже самое будет, даже еще хуже в случае применения прославляемого GPO: вас будут ругать, что при загрузке компьютера какая-то хрень долго устанавливается, мешает, а еще и автоматически сбойнуть может, машины же разные, с особенностями.
Это вопрос не применения доменов и GPO, а организации работы в организации: есть шефы, которые хотят, чтобы у всех или у избранных был админдоступ, возможность развлекаться музыкой на работе, а как там сисадмин будет крутиться - его проблемы, все могут его ругать и что-то от него требовать.
Есть организации, где зоопарк машин по ОС и старости, а есть где по 100 штук одинаковых новых стоят(как в тестах Майкрософт), да еще и слово сисадмина - закон - вот оттуда и берутся многочисленные ревнители GPO для инсталляций и прочих дел.