none
Проблема с учетной записью RRS feed

  • Вопрос

  • Добрый день коллеги.

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

    Так вот проблема в следующем при запуске на доменном ПК от этого пользователя выдается сообщение что Требуется повышение прав. Добавлял его в разные члены групп, в плоть до администратора предприятия, проблема повторяется.

    На стандартном Администраторе который создан при установке домена проблем нет. От него все запускается.

    Куда копать не понимаю.

Ответы

  • Или я что то не понимаю, или вы мне советуете не то что надо.

    Я не знаю где в моих слловах вы увидели создание локальных учеток. В моем первом сообщении говорилось: "у каждого техпода своя УЗ (прим. ред. доменная), которая состоит в группе TechSupprot (прим. ред. доменной), а эта группа через GPP добавляется (не создается, а именно добавляется) в локальные группы Administrators на конечных машинах."

    К слову сказать ваша статья устарела на пару лет так как уязвимость с паролями МС закрыла, запретив устанавливать пароль через политики


    The opinion expressed by me is not an official position of Microsoft


    Модератор

Все ответы

  • Добрый день!

    Посмотрите кто попадает в группу Администраторы на пользовательском ПК (по умолчанию это Domain Admins). Далее убедитесь, что новый пользователь является членом этой группы.

  • Добрый день!

    Посмотрите кто попадает в группу Администраторы на пользовательском ПК (по умолчанию это Domain Admins). Далее убедитесь, что новый пользователь является членом этой группы.

    Это плохая практика, техподов делать админами домена.

    По красоте эта задача решается иначе - у каждого техпода своя УЗ, которая состоит в группе TechSupprot, а эта группа через GPP добавляется в локальные группы Administrators на конечных машинах. В таком случае если кто-то накосячит у вас будет шанс узнать кто из техподов это сделал. А вот всем давать одну учетку это не решение прямо совсем.

    Что до сообщения, то это похоже на UAC и если это так-то админу новому достаточно подтвердить свои намерения жмакнув кнопку ОК.

    ЕМНИП действия UAC не расспространяются на втроенных админов с RID 500, поєтому под дефолтной учеткой сообщения UAC вы и не видите.


    The opinion expressed by me is not an official position of Microsoft


    Модератор

  • Вот предоставил ему полные права временно для тестов, но проблема повторяется.
  • Вот предоставил ему полные права временно для тестов, но проблема повторяется.
    Прочтите мой ответ

    The opinion expressed by me is not an official position of Microsoft

    Модератор
  • Вот предоставил ему полные права временно для тестов, но проблема повторяется.

    Прочтите мой ответ

    The opinion expressed by me is not an official position of Microsoft

    Это плохая практика, техподов делать админами домена.

    По красоте эта задача решается иначе - у каждого техпода своя УЗ, которая состоит в группе TechSupprot, а эта группа через GPP добавляется в локальные группы Administrators на конечных машинах. В таком случае если кто-то накосячит у вас будет шанс узнать кто из техподов это сделал. А вот всем давать одну учетку это не решение прямо совсем.

    По данному вопросу согласен.

    Что до сообщения, то это похоже на UAC и если это так-то админу новому достаточно подтвердить свои намерения жмакнув кнопку ОК.

    ЕМНИП действия UAC не распространяются на встроенных админов с RID 500, поєтому под дефолтной учеткой сообщения UAC вы и не видите.

    А вот по этому не понятно. UAC на станции отключал, проблеме не решается.

  • Вы предлагаете так техподов сделать?


  • Что до сообщения, то это похоже на UAC и если это так-то админу новому достаточно подтвердить свои намерения жмакнув кнопку ОК.

    ЕМНИП действия UAC не распространяются на встроенных админов с RID 500, поєтому под дефолтной учеткой сообщения UAC вы и не видите.

    А вот по этому не понятно. UAC на станции отключал, проблеме не решается.

    Отключали уведомления в Control panel или сам UAC через реестр? Зачем его отключать - это же один из рубежей защиты от самого себя? Если жмакнуть ОК - прав хватает? Машину перезагружали при тестах?

    The opinion expressed by me is not an official position of Microsoft

    Модератор
  • Что до сообщения, то это похоже на UAC и если это так-то админу новому достаточно подтвердить свои намерения жмакнув кнопку ОК.

    ЕМНИП действия UAC не распространяются на встроенных админов с RID 500, поєтому под дефолтной учеткой сообщения UAC вы и не видите.

    А вот по этому не понятно. UAC на станции отключал, проблеме не решается.

    Отключали уведомления в Control panel или сам UAC через реестр? Зачем его отключать - это же один из рубежей защиты от самого себя? Если жмакнуть ОК - прав хватает? Машину перезагружали при тестах?

    The opinion expressed by me is not an official position of Microsoft

    Отключал UAC временно на локальной машине для тестов.  Машину перезагружал.

  • Что до сообщения, то это похоже на UAC и если это так-то админу новому достаточно подтвердить свои намерения жмакнув кнопку ОК.

    ЕМНИП действия UAC не распространяются на встроенных админов с RID 500, поєтому под дефолтной учеткой сообщения UAC вы и не видите.

    А вот по этому не понятно. UAC на станции отключал, проблеме не решается.

    Отключали уведомления в Control panel или сам UAC через реестр? Зачем его отключать - это же один из рубежей защиты от самого себя? Если жмакнуть ОК - прав хватает? Машину перезагружали при тестах?

    The opinion expressed by me is not an official position of Microsoft

    Отключал UAC временно на локальной машине, для тестов. ПК перезагружал



  • Вот предоставил ему полные права временно для тестов, но проблема повторяется.

    Прочтите мой ответ

    The opinion expressed by me is not an official position of Microsoft

    Это плохая практика, техподов делать админами домена.

    По красоте эта задача решается иначе - у каждого техпода своя УЗ, которая состоит в группе TechSupprot, а эта группа через GPP добавляется в локальные группы Administrators на конечных машинах. В таком случае если кто-то накосячит у вас будет шанс узнать кто из техподов это сделал. А вот всем давать одну учетку это не решение прямо совсем.

    По данному вопросу согласен.

    Что до сообщения, то это похоже на UAC и если это так-то админу новому достаточно подтвердить свои намерения жмакнув кнопку ОК.

    ЕМНИП действия UAC не распространяются на встроенных админов с RID 500, поєтому под дефолтной учеткой сообщения UAC вы и не видите.

    А вот по этому не понятно. UAC на станции отключал, проблеме не решается.

    Добавить пользователей в локальные группы довольно просто, достаточно создать синоним локальной группы Администраторы и добавить туда нужную доменную группу (или отдельных пользователей).  Тогда члены этой группы станут локальными администраторами и смогут входить на любую рабочую станцию с административными привилегиями.

    Однако есть некоторые нюансы, а именно: если сначала добавить в Restricted Groups группу Администраторы, а затем в нее добавить доменную группу (в нашем случае HelpDesk), то локальными администраторами останутся только встроенный Администратор и добавленная нами группа HelpDesk, а все остальные, даже если они были добавлены вручную, будут из этой группы удалены. Более того, добавить обратно этих пользователей можно будет только одним способом — через Restricted Groups, при этом они станут станут локальными админами на всех компьютерах, на которые действует эта политика.

    добавление доменной группы в группу локальных администраторов

     

    Поэтому, чтобы избежать подобных последствий, сначала добавляем в Restricted Groups доменную группу HelpDesk, а уже ее в группу Администраторы. В этом случае члены группы HelpDesk станут локальными администраторами вместе с уже заведенными пользователями и останется возможность добавлять пользователей в группу локальных администраторов вручную.

    добавление доменной группы в группу локальных администраторов

     

    Этот способ работает на всех операционных системах, начиная с Windows 2000. Если же у вас в качестве клиентской операционной системы используется Windows 7, то можно воспользоваться вторым способом:


  • если у вас до сих пор используются ос по типу 2000, то да restricted groups это ваш выбор (и мое вам сочувствие), но если мамонты в вашей компании повымерли то стоит смотреть на GPP (о котором я писал в своем первом ответе - там нет этих плясок с зависимостями и сложнее поламать все и сразу, как часто происходит с restricted groups

    The opinion expressed by me is not an official position of Microsoft


    Модератор
  • если у вас до сих пор используются ос по типу 2000, то да restricted groups это ваш выбор (и мое вам сочувствие), но если мамонты в вашей компании повымерли то стоит смотреть на GPP (о котором я писал в своем первом ответе - там нет этих плясок с зависимостями и сложнее поламать все и сразу, как часто происходит с restricted groups

    The opinion expressed by me is not an official position of Microsoft



    Если объясните как это делается через GPP буду признателен.  Задача получается 5 людям дать локального администратора на любом ПК домена.
  • скорее всего это описано во втором способе той статьи которую вы копировали выше

    https://blogs.technet.microsoft.com/askpfeplat/2017/11/06/use-group-policy-preferences-to-manage-the-local-administrator-group/


    The opinion expressed by me is not an official position of Microsoft

    Модератор
  • скорее всего это описано во втором способе той статьи которую вы копировали выше

    https://blogs.technet.microsoft.com/askpfeplat/2017/11/06/use-group-policy-preferences-to-manage-the-local-administrator-group/


    The opinion expressed by me is not an official position of Microsoft


    Не создавайте локальные учетные записи доменными политиками


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

    Причина высокой опасности – сведения об этой учетной записи, в том числе ее пароль, хранятся в открытом виде в файле groups.xml, в ресурсе sysvol контроллера домена, который по умолчанию доступен ВСЕМ участникам домена на чтение. Пароль зашифрован, но шифрование симметричное, а ключ один для всех копий Windows, и написан в открытом виде в MSDN. Отсюда следует: любой пользователь может скачать этот файл, и путем простых манипуляций узнать пароль от распространяемой учетной записи. Обычно так распространяется учетная запись с правами администратора, и часто она создается без разбора везде…

    Решение – групповыми политиками добавляйте только доменные учетные записи в локальные группы на хостах.
  • Или я что то не понимаю, или вы мне советуете не то что надо.
  • Или я что то не понимаю, или вы мне советуете не то что надо.

    Я не знаю где в моих слловах вы увидели создание локальных учеток. В моем первом сообщении говорилось: "у каждого техпода своя УЗ (прим. ред. доменная), которая состоит в группе TechSupprot (прим. ред. доменной), а эта группа через GPP добавляется (не создается, а именно добавляется) в локальные группы Administrators на конечных машинах."

    К слову сказать ваша статья устарела на пару лет так как уязвимость с паролями МС закрыла, запретив устанавливать пароль через политики


    The opinion expressed by me is not an official position of Microsoft


    Модератор
  • Или я что то не понимаю, или вы мне советуете не то что надо.

    Я не знаю где в моих словах вы увидели создание локальных учеток. В моем первом сообщении говорилось: "у каждого техпода своя УЗ (прим. ред. доменная), которая состоит в группе TechSupprot (прим. ред. доменной), а эта группа через GPP добавляется (не создается, а именно добавляется) в локальные группы Administrators на конечных машинах."

    К слову сказать ваша статья устарела на пару лет так как уязвимость с паролями МС закрыла, запретив устанавливать пароль через политики


    The opinion expressed by me is not an official position of Microsoft



    Не знал что Microsoft закрыла дыры в этом месте. Извините. Да все получилось. Только вот работает все это при добавлении учетных записей. Пробовал добавлять группу и правило не работает. Получается если 10 пользователей надо всех по очереди добавить как вы показали?

  • Не знал что Microsoft закрыла дыры в этом месте. Извините. Да все получилось. Только вот работает все это при добавлении учетных записей. Пробовал добавлять группу и правило не работает. Получается если 10 пользователей надо всех по очереди добавить как вы показали?
    Когда жмакаете Add... жмакните на "..." справа, и выбирите группу со своего домена, все должно работать

    The opinion expressed by me is not an official position of Microsoft


    Модератор
  • Когда жмакаете Add... жмакните на "..." справа, и выбирите группу со своего домена, все должно работать


    Выбирал группу. Появляется в списке но почему то не работает.
    • Изменено Vector BCOModerator 15 мая 2018 г. 12:28 подсократил цитату цитаты...

  • Выбирал группу. Появляется в списке но почему то не работает.

    пробуйте смотреть rsop и gpresult на клиенте. так же клиент можно поперезагружать. посмотрите так же репликацию между кд.

    попробую проверить у себя, по результатам отпишусь


    The opinion expressed by me is not an official position of Microsoft


    Модератор
  • Группу переместил в Builtin, добавил повторно пользователей в группу. И все заработало. Спасибо за помощь.