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

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

Можно.

• Политики ограниченного использования программ.
• AppLocker.

Для начала пользователи должны быть пользователями. У Вас как с этим — пользователи, они же администраторы?

Грабли могут возникнуть в вышеуказанном случае — если сейчас пользователь-администратор, которого надо будет перевести в обычного пользователя. У меня, впрочем, с этим проблемы не возникло. Из-за подключения к домену проблем быть не должно.

Крайне желательно.

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

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

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

Групповые политики содержат раздел "политики ограниченного использования программ"

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

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

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

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

Странно. Я думал, что если ПК участник домена, то у него права только те, которые ему разрешает домен.У меня почему-то в политиках нет такого. По дефолту не устанавливается данная роль?
У меня много машин ещё на XP. Это не имеет значения?

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

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


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

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

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

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

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

В таком случае давать ему права локального администратора?

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

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

А куда деваться - приходится....
Но лучше таки выявить проблему.

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

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

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

Верно. Только не «проще», а «возможно».

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

Чаще всего и пользуются локально установленными программами, а не какими-то сетевыми. На сервере только если в rdp-сеансах - нелокальные программы.

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

Вы имеете ввиду при помощи софта для создания msi-пакетов?

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

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

А если всё же они( ключи ) требуются, тогда как?

Я имею в виду другое: Использование ключей и свойств установщика Windows.

Общие принципы см. там же. А вообще — читать документацию на конкретное приложение. Для «толстых» и разветвлённых пакетов приложений могут быть облегчающие подготовку развёртывания Wizard'ы и т.п. Примеры использования можно найти в разделе Автоматическая установка Windows.

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

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

Вы правильно поняли слабое место этих GPO.

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

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

Корпоративный MS Office 2003 с сайта MSVL прекрасно ставится через административную установку
MS Office 2007 опять же имеет встроенные средства создания административной точки со всеми ключами и настройками.

Если устанавливается - значит так надо. Дело пользователя - работать. Дело администратора - обеспечить пользователю рабочее место и провести инструктаж.
Машины везде одинаковые - IBM-PC-совместимые. А "особенности" устанавливаемого программного обеспечения легко устраняются обеспечением одинаковости установленного программного обеспечения. А GPO - средство №1 для этого.

Это про меня. Здесь чего тока нет. До меня покупали трипер всякий или не покупали вообще ничего. Серверов вообще не было. Вместо серверов были машины клиентов, которые были завязаны друг на друга. В общем, совсем никак. Я когда пришёл дал понять, что если не купять сразу 2 сервака и нужное оборудования я уйду. Настраивать всё это хозяйств не было кому. В итоге я остался. Т.к. от прошлого "админа" все коллеги плевались. Он пролежал там на стульчике пока всё совсем не нагнулось и резко спрыгнул, когда пришло время начать шевелится и внедрять новые вещи. Вот я год жил без AD. Теперь решил внедрить хотя бы для управления общим доступом отдельным OU. Это я вижу единственным удобством на данный момент. Остальное как я понимаю не так и удобно, как кажется на первый взгляд.

El Scorpio, я не совмес понимаю о каких средствах Вы говорите. По крайне мере, где эти средства искать..

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

Устаревшие офисы, ключи к которым, разумеется уже не продаются и которые пользователи требуют переустановить на новые.
Или MS разрешает их теперь устанавливать бесплатно?
Далеко не везде такой подход. Все пользователи и директор имеют дома Windows без всяких сисадминов и непонятных долгих загрузок все работает.

Вот есть тема http://forum.oszone.net/thread-264841.html человека, который этим хорошо занимается, практический инструмент создал.
А вот еще практический крутой инструмент http://wpkg.org/

При использовании штатного установочного пакета MSI таких вопросов нет.
Собственно говоря, при создании и настройки GPO вводить ключи не требуются - командная строка запуска пакета формируется автоматически при выборе пакета MSI.
Для простой распаковки пакета MSI в точку административной установки достаточно создать файл CMD из одной строчки "msiexec.exe /a %1 TARGETDIR=d:\admin-msi" и один раз "открыть" MSI этим файлом.
Затем переносите файлы из этого каталога в соответствующий подкаталог сетевого ресурса.
А для редактирования свойств пакета MSI и/или файла параметров MST используется программа Orca или аналогичное ПО.

Что касается прочих установщиков, то они делятся на плохие и очень плохие.
Плохие - позволяют осуществлять установку в автоматическом режиме через параметры, задаваемые в командной строке или в особых файлах. Разумеется, для каждого установщика существуют свои параметры, которые требуется найти в гугле после того, как сможете идентифицировать установщик. Ну а потом ещё требуется придумать способ автоматического запуска установки на всех требуемых компьютерах...
Очень плохие установщики в принципе не рассчитаны на автоматизацию процесса, работают только через графический интерфейс и требуют многократного ручного нажатия кнопки "далее". В принципе вы можете реализовать автоматическое нажатие нужных кнопок через AutoIT, но вот обеспечить централизованный запуск этих программ будет уже сложнее.

100 компьютеров - это "небольшая сеть" :o
Что же тогда по вашему "большая сеть"?

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


Пользователи всегда чем-то недовольны.
При включении начинается установка новых версий программ, а при выключении - установка обновлений Windows.
Но ведь всё это надо же когда-то ставить.
Другое дело, что вы же не каждый день устанавливаете новые программы. И большие пакеты обновлений тоже не каждый день приходят.
В крайнем случае для тяжёлых программных пакетов можно подписать у директора "приказ на установку актуальной версии ПО" (в целях обеспечения правильного ведения бухгалтерского и кадрового учёта 42 улюлюля сего года провести установку ПО 1С: Предприятие версии 8.2.20.220 на АРМ, выполняющие данные действия) и под роспись уведомить особо вредных бухгалтерьеров о том, что в этот день их компьютер будет загружаться на пять минут дольше.

Зато ручная установка займёт не только гораздо больше времени, но ещё и приведёт к "зоопарку" из разных версий программ. Здесь спешил, там забыл, тут работник очень сильно занят был...

Это не то. Я по ковырялся с ним, не нашёл. Спросил у автора, говорит что не возможно такое реализовать при помощи его детища.

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

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

Это я благодаря этой ветке уже понял :)

Я делаю вывод, что нужно устанавливать самые основные вещи через политики, а всё остальное , в том числе, и, с ключами, лучше устанавливать на местах. Ведь так? Иначе придётся лопатить, немеренно, и, кто знает, что с этого выйдет...

Распаковка пакета MSI нужна для ускорения процесса установки. В большинстве случаев копирование over9000 распакованных файлов происходит быстрее копирования упакованного файла с последующей его распаковкой на месте. Опять же при копировании упакованного дистрибутива антивирус сначала проверяет содержимое упакованного архива при копировании, а затем ещё и каждый файл по отдельности при распаковке.
Кроме того при запуске установки с ключом /a инсталлятор может задавать администратору много вопросов, ответы на которые будут записаны в новый пакет MSI с целью последующего использования в автоматической установке.

Угу.
Причём изначально лучше распаковывать пакет MSI во временную папку. Особенно если вы записали команду распаковки в файл CMD.
А уже оттуда копировать файлы в подкаталог общей сетевой папки.
Крайне желательно создать для этого в домене структуру DFS, чтобы указывать в групповых политиках пути к пакетам MSI не \\server\folder, а \\domain\путь\дерева\DFS . Потому что если вы привяжете пути установки к конкретным серверам, то при переходе на другой сервер вы не сможете ни установить эти программы на новые компьютеры, ни удалить ранее установленные программы.
А при наличии дерева DFS вы просто в свойствах ветки \\domain\dfs\system\msi замените сетевую папку \\server1\msi$ на \\server2\msi$ , и все компьютеры продолжат использование файлов по адресу \\domain\dfs\system\msi , как ни в чём не бывало.

Нет, не так.
Согласно действующему законодательству Российской Федерации и текстам лицензионных соглашений на ПО требуется только совпадение количества установленных/используемых экземпляров ПО и количества лицензий. Таким образом вполне допускается использование одного серийного номера на всех установленных продуктах - для большинства программ вы задаёте этот номер при распаковке пакета msi с ключом /a .
Кроме того корпоративные версии продуктов имеют возможность централизованного управления ключами после установки.

Другие программы позволяют устанавливать себя без ввода серийного номера в "пробном" режиме. Так например программа работы с ЭЦП "КриптоПро", распространяемая в дистрибутиве MSI, даёт администратору целых 30 дней на ввод серийного номера лицензии. По мне за это время можно оббежать даже over9000 компьютеров.
Тем более что после первой установки последующие установки будут производиться только для отдельных компьютеров - при подключении новых рабочих мест или переустановки операционной системы.

Как видно, "на местах" нужно устанавливать только те программы, которые не были рассчитаны на автоматическую установку.
Кстати, "персональная" версия программы Finereader, использующая MSI, принципиально запрещает установку через GPO. Эта функция доступна только в "корпоративной" версии.
Также "на местах" можно устанавливать программы, используемые в единственном экземпляре. То есть когда просто по времени проще и быстрее подойти к компьютеру и вручную запустить установочный файл.

UPD.
Пакеты .NET в формате MSI теоретически можно установить через GPO.
Однако лучше всё-таки установить нужные версии NET вручную до ввода компьютера в домен. Или вообще внедрить их в установочный диск Windows

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

А почему на наклейках MS Windows разные номера? MS нарушает российское законодательство?

Для просмотра ключей есть известный софт http://nirsoft.net/utils/product_cd_key_viewer.html с ключом /remotealldomain для домена, т.к. некоторые ключи хранятся в реестре, их можно исправить после установки удаленно.

Для просмотра ключей есть известный софт http://nirsoft.net/utils/product_cd_key_viewer.html с ключом /remotealldomain для домена, т.к. некоторые ключи хранятся в реестре, их можно исправить после установки удаленно. »[/q]
alef2474, а к чему это всё? Мы ж говорили выше о ключах тихой установки, а не о ключах лицензий. Ведь знание ключа установленного софта, не помогает нам установить этот софт с этим ключом!

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

Мы говорили о всех аспектах установки, El Scorpio упомянул именно о лицензионных ключах, административная установка была о том же. Про тихие ключи я давал вам ссылку на тему с Silent Key Finder.
После установки с одним ключом или с пробным ключом можно поменять и проконтролировать ключи, пользуясь последней ссылкой.

Вы озабочены установкой только нелицензионного?

Столкнулся с тем, что Windows XP не удаляет и не переустанавливает NET1 и 2 через GPO.
Таким образом если вывести компьютер из под действия политики, а затем повторно применить к нему эту политику, в системных журналах постоянно будут появляться уведомления об ошибках установки.
К тому же некоторые драйвера требуют NET определённых версий. А поскольку установка драйверов на локальные устройства происходит сразу после установки системы до ввода машины в домен, NET требуемых версий лучше установить сразу.

Поскольку NET является стандартным компонентом Microsoft, обновления для него устанавливаются через WSUS без всякого шаманизма.

На OEM-наклейках разные номера, потому что эти лицензии покупают совершенно разные юридические и физические лица.

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

Не только. В том числе и лицензионного. Ведь тот же офис имеет корпоративный ключ, например. Есть и другие варианты, сами понимаете...