Прежде всего, спасибо за материал, изложен хорошо и последовательно.
Но хотелось бы заметить что никакого жесткого запрета на интерактивные сервисы нет, они по-прежнему работают, совместимость-то надо сохранять. Просто начиная с Висты, если сервис с флагом SERVICE_INTERACTIVE_PROCESS попытается показать какое-то окошко, будь-то MessageBox, собственное отрисованное окно или дочерний процесс система сообщит об этом:
Далее, по желанию пользователя произойдет переход в нулевую сессию, где он сможет увидеть gui.
Плюсы в удобном представлении иерархии обьектов организации и в возможности делегировать права администрирования.
Например предприятие может быть территориально разбросано, скажем отдел сбыта может частично находиться в основном здании, частично — в десятке километров, чтобы иметь возможность этот самый сбыт контролировать. В таком случае целесообразно дать кому-то одному больше прав, переложить на него часть обязанностей, дать возможность создавать пользователей, модифицировать и т.д. Можно конечно поднять поддомен, но это все равно что стрелять из пушки по воробьям. А делегировав права на отдельный OU решаем проблему легко и изящно.
Или ситуация описанная автором. Секретарши должны следить за номерами тел. сотрудников и при необходимости вносить изменения. Дергать админа это не вариант. Можно просто наделить секретарш правом изменять этот атрибут в пределах ведомств которыми они заведуют.
Разбейте на подсети, это решит проблему. Пример: 172.16.8.0/24 — серверы, 172.16.9.0/28 — все высшее начальство, 172.16.10.0/24 — бухгалтерия и т.д. Если выделят достаточно средств — организуйте все на Цисках — для каждой подсети свой влан + свой акцесс-лист. Благодаря первому бухгалтера будут в своем сетевом окружении видеть только компьютеры бухгалтерии, начальство — только друг друга. Второе же защитит от кулхацкеров разобравшихся в адресации сети.
Года три назад пробовал этот движок, очень даже ничего. Кстати забыли упомянуть что там еще есть возможность сетевой игры, несколько дюков одновременно на одном уровне это нечто!
Спасибо, за советы, проблемы давно уже решены, просто привел пример как рушиться преусловутая интеграция если что-то идет не так как должно быть по мнению разработчиков из МС.
продукты Микрософт созданы для совместного существования
Один из Ваших главных доводов. Только Вы, к сожалению забыли упомянуть, что это до поры до времени, пока все идет так как задумал МС, шаг вправо, шаг влево и эта чудесная интеграция уже не фунциклирует.
Хотите пример?
Да вот тот же WSUS, долгое время успешно раздавал апдейты клиентам XP/2003 (юзеры конечно же с урезанными правами). Год назад решили обновить часть машин. Закупили, развернули Windows Vista (мы же идем в ногу со временем). И что с апдейтами? Теперь они не устанавливаються потому что видите-ли нужны права администратора. Куда делать интеграция? Вылетела в трубу.
Вот еще пример.
Берем новенький, коробочный Exchange 2007 и такой же новенький, коробочный Windows Server 2008 R2. Устанавливаем. Опа! Какая-то бредовая ошибка сразу при установке Exchange, гуглим и понимаем что эти два продукта не совместимы между собой! Это интеграция?
о_О Зачем так много?
Всегда выделял места под этот раздел с запасом — 48-100Мб, в зависимости от системы, но целый гигабайт? Что вы там собираетесь хранить кроме пары конфигов и ядра?
Но хотелось бы заметить что никакого жесткого запрета на интерактивные сервисы нет, они по-прежнему работают, совместимость-то надо сохранять. Просто начиная с Висты, если сервис с флагом SERVICE_INTERACTIVE_PROCESS попытается показать какое-то окошко, будь-то MessageBox, собственное отрисованное окно или дочерний процесс система сообщит об этом:
Далее, по желанию пользователя произойдет переход в нулевую сессию, где он сможет увидеть gui.
Например предприятие может быть территориально разбросано, скажем отдел сбыта может частично находиться в основном здании, частично — в десятке километров, чтобы иметь возможность этот самый сбыт контролировать. В таком случае целесообразно дать кому-то одному больше прав, переложить на него часть обязанностей, дать возможность создавать пользователей, модифицировать и т.д. Можно конечно поднять поддомен, но это все равно что стрелять из пушки по воробьям. А делегировав права на отдельный OU решаем проблему легко и изящно.
Или ситуация описанная автором. Секретарши должны следить за номерами тел. сотрудников и при необходимости вносить изменения. Дергать админа это не вариант. Можно просто наделить секретарш правом изменять этот атрибут в пределах ведомств которыми они заведуют.
Этот глюк неистребим!
Извините что ввел в заблуждение.
Один из Ваших главных доводов. Только Вы, к сожалению забыли упомянуть, что это до поры до времени, пока все идет так как задумал МС, шаг вправо, шаг влево и эта чудесная интеграция уже не фунциклирует.
Хотите пример?
Да вот тот же WSUS, долгое время успешно раздавал апдейты клиентам XP/2003 (юзеры конечно же с урезанными правами). Год назад решили обновить часть машин. Закупили, развернули Windows Vista (мы же идем в ногу со временем). И что с апдейтами? Теперь они не устанавливаються потому что видите-ли нужны права администратора. Куда делать интеграция? Вылетела в трубу.
Вот еще пример.
Берем новенький, коробочный Exchange 2007 и такой же новенький, коробочный Windows Server 2008 R2. Устанавливаем. Опа! Какая-то бредовая ошибка сразу при установке Exchange, гуглим и понимаем что эти два продукта не совместимы между собой! Это интеграция?
По-крайней мере по-умолчанию.
о_О Зачем так много?
Всегда выделял места под этот раздел с запасом — 48-100Мб, в зависимости от системы, но целый гигабайт? Что вы там собираетесь хранить кроме пары конфигов и ядра?
Ну, если пароль хеширован и пользователь никогда не входил в систему, то будь вы хоть трижды рутом, а пароль этот достать сможете только брутом.