none
Недоступно управление компами в домене RRS feed

  • Вопрос

  • Привет. Вот непонятно с чего.

    Несколько компов, в основном Win7. Недоступно управление извне. Ни службами, ни процессы посмотреть - воообще ничего. C$ и админка тоже не работают. При всём этом нормально работают.

    GPO ситуацию не улучшает.

    Есть какие-то утилиты или способы понять в чём дело? Как исправить... За этими компами не шибко продвинутые пользователи, вроде... Коненчо, крайне желательно это всё удалённо и незаметно

    9 февраля 2016 г. 15:14

Ответы

Все ответы

  • Причина, вероятно, в том, что на компьютерах включен Windows Firewall. В вашем сценарии наиболее правильно  настроить на всех компьютерах разрешающее правило для входящих соединений с вашей административной рабочей станции.
    9 февраля 2016 г. 15:30
    Модератор
  • ну, да... COM+ и доступ к уведомлениям. Это, разумеется, есть. Настроено. Через те же GPO
    9 февраля 2016 г. 15:39
  • Если на целевом компьютере выключить Windows Firewall, вам удается получить к нему доступ по сети, административные инструменты работают?
    9 февраля 2016 г. 15:47
    Модератор
  • Хм... А как это сделать удалённо? Допустим, через ту же GPO запустить остановку службы - покатит?
    9 февраля 2016 г. 15:51
  • Есть специализированные политики Computer Configuration - Windows Settings - Security Settings - Windows Firewall with Advanced Security. Там в Свойствах политики вы можете управлять параметром Firewall State. 
    9 февраля 2016 г. 15:58
    Модератор
  • Я - безусловно - искренне рад, что "в Багдаде всё спокойно".

    Однако, вопрос актуален.

    Через GPO - не помогло. Ручное отключение службы FireWall не помогло.

    Ну вот... Ну вот никак...

    16 февраля 2016 г. 10:35
  • А вот спрошу: а права у используемой УЗ вообще имеют право локального админа на этих ПК? Уверены?)))

    Как вариант - указать принудительное добавление нужной УЗ в локальные админы через Preferences, чтобы даже если "шибко продвинутые пользователи" удалят к едрени бабушке назначенные права, то все вернулось в нужное для админа состояние

    16 февраля 2016 г. 11:36
  • А вот спрошу: а права у используемой УЗ вообще имеют право локального админа на этих ПК? Уверены?)))

    Как вариант - указать принудительное добавление нужной УЗ в локальные админы через Preferences, чтобы даже если "шибко продвинутые пользователи" удалят к едрени бабушке назначенные права, то все вернулось в нужное для админа состояние

    1. УЗ доменного админа. По логике должна иметь права и локального.

    2. Вы про "ограниченные УЗ" в GPO?

    16 февраля 2016 г. 14:57
  • Проверить, не прошлись ли по конфигурации компов шаловливые ручёнки поклонников нонаме - блокировка админских шарингов (через реестр), запрет сервайса RemoteRegistry ...

    Ну, и да, проверить, что группа Domain Admins действительно присутствует в локальной Administrators.

    Ещё можно легко лишить доменного админа сетевого доступа с использованием привилегий Network Logon Right и Deny Network Logon Right, проверить в локальных политиках (тоже можно "починить" доменными).


    S.A.

    16 февраля 2016 г. 15:36
  • Проверить, не прошлись ли по конфигурации компов шаловливые ручёнки поклонников нонаме - блокировка админских шарингов (через реестр), запрет сервайса RemoteRegistry ...

    Ну, и да, проверить, что группа Domain Admins действительно присутствует в локальной Administrators.

    Ещё можно легко лишить доменного админа сетевого доступа с использованием привилегий Network Logon Right и Deny Network Logon Right, проверить в локальных политиках (тоже можно "починить" доменными).


    S.A.

    1. Ручёнки были проверены, конечно. У юзеров не было админских прав, но при должных знаниях это не преграда... Перепроверить удалённо можно?

    2. Группы удалённо проверить пока тоже не выйдет. Локально - небыстро, увы.

    3. А метод починки в доступе где-то есть? Доменные политики перекрываются локальными?

    17 февраля 2016 г. 8:38
  •  Доменные политики перекрываются локальными?

    Нет, доменные политики имеют приоритет.

    Покажите/опишите здесь результаты выполнения следующих команд:

    ping <IP-адрес целевого компьютера>

    ping <имя целевого компьютера>

    telnet <имя целевого компьютера> 135

    telnet <имя целевого компьютера> 445

    start \\<имя целевого компьютера>\C$

    17 февраля 2016 г. 10:20
    Модератор
  • 1. Ручёнки были проверены, конечно. У юзеров не было админских прав, но при должных знаниях это не преграда... Перепроверить удалённо можно?

    2. Группы удалённо проверить пока тоже не выйдет. Локально - небыстро, увы.

    3. А метод починки в доступе где-то есть? Доменные политики перекрываются локальными?

    1. Перепроверить удалённо можно при наличии доступа, при его отсутствии ... Можно однозначно задать нужное доменными политиками. Значения параметров реестра AutoShareServer и AutoShareWks - в 1 (через Параметры безопасности или Preferences/Настройки). Запуск сервайса RemoteRegistry в Auto (Параметры безопасности -> Системные службы). Можно и на другие службы внимание обратить (для гарантированного запуска).

    2. Через политики, Параметры безопасности -> Группы с ограниченным доступом, или тоже через Preferences/Настройки (уже написал Valery Moskov), обеспечить наличие Domain Admins в Administrators. Кроме того, в разделе Параметры безопасности -> Локальные политики -> Назначение прав пользователя - гарантировать доступ доменным администраторам, например, привилегии "Отказать ..." сделать предопределёнными с пустым набором.

    3. Локальные политики перекрываются доменными. Если, опять же, не развлекались с их блокировкой (типа https://xakep.ru/2011/10/24/57477/), но таких персонажей в корпоративной сети нужно лечить административными методами.


    S.A.

    17 февраля 2016 г. 12:19
  • 1. ping <IP-адрес целевого компьютера>

    2. ping <имя целевого компьютера>

    3. telnet <имя целевого компьютера> 135

    4. telnet <имя целевого компьютера> 445

    5. start \\<имя целевого компьютера>\C$

    1. всё в порядке

    2. всё в порядке

    3. открывается стандартное окно телнета. Всё чёрное плюс немигающее подчёркивание вначале

    4. то же самое

    5. Вылетает ошибка. Заголовок \\comp\c$, в окне ещё раз \\comp\c$, потом "Вход в систему не произведён: конечная учётная запись задана неверно"

    19 февраля 2016 г. 10:31
  • Значения параметров реестра AutoShareServer и AutoShareWks - в 1 (через Параметры безопасности или Preferences/Настройки). Запуск сервайса RemoteRegistry в Auto (Параметры безопасности -> Системные службы). Можно и на другие службы внимание обратить (для гарантированного запуска).

    RemoteRegistry в Auto был установлен и ранее. С AutoShareServer и AutoShareWks не экспериментировал.

    Так ли это делается?

    19 февраля 2016 г. 10:54
  • 2. Через политики, Параметры безопасности -> Группы с ограниченным доступом, или тоже через Preferences/Настройки (уже написал Valery Moskov), обеспечить наличие Domain Admins в Administrators.

    Например, так?

    Группы прописаны руками, так как по понятным причинам поиском не ищутся

    Админы домена в итоге будут ли добавляться в админы компа?

    19 февраля 2016 г. 11:27
  •  Кроме того, в разделе Параметры безопасности -> Локальные политики -> Назначение прав пользователя - гарантировать доступ доменным администраторам, например, привилегии "Отказать ..." сделать предопределёнными с пустым набором.
    Сделал. Долго же они обрабатываются
    19 февраля 2016 г. 11:55