Будет ли когда-нибудь нужен пароль пользователя домена?

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

ОБНОВИТЬ:

Ответы до сих пор ссылались на «настройку» или изменение профиля пользователя. Тем не менее, есть эта статья от Microsoft на изменение профиля по умолчанию , который будет применяться для пользователей при входе в систему в первый раз , и эти инструкции по изменению параметров реестра Windows , другого пользователя в любое время. Что изменит администратор, войдя в систему как пользователь, которого администратор не сможет изменить, используя эти или другие доступные методы, которые не включают вход в систему как пользователь? Просто «вход в систему как пользователь» не является причиной для запроса или изменения пароля пользователя. Я ищу практическую причину для этого.

Администратор не должен и не должен запрашивать пароль пользователя.

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

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

Организация также несет ответственность за обеспечение того, чтобы это не только принималось, но и выполнялось. Был юридический случай, когда кто-то в организации отправлял вредоносное письмо, используя чужой почтовый ящик. Владелец почтового ящика был в конечном итоге уволен. Хотя они утверждали, что передали свой пароль кому-то еще, компания настаивала на том, что они несут ответственность за поддержание целостности своих учетных данных, и поэтому они несут ответственность, как это было продиктовано политикой ИТ их компании. Затем это было отменено судом, когда этот пользователь доказал, что в организации существует культура совместного использования паролей. Суд постановил, что, если компания не сможет активно применять свою ИТ-политику, она не может полагаться на нее в качестве подотчетности в этих обстоятельствах.

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

Лично я придерживаюсь жесткого подхода к этому. Я не считаю, что запрашивать пароли (или переустанавливать их для доступа к учетной записи пользователя) необходимо. Если существует значительно возросшая нагрузка, чтобы обойти это, то пусть будет так. Это не повод для компрометации безопасности. Думаю, мне просто повезло, что я не менеджер, и поэтому мне не нужно брать на себя ответственность за эти решения, когда кто-то из вышестоящих поручит это сделать.

Давайте проясним: если вы являетесь администратором домена, вы можете установить программное обеспечение - драйвер устройства, который приходит на ум, - которое может буквально сделать все, что угодно. Тем не менее, это в разной степени нецелесообразно, начиная от "Какой раздел реестра для фона рабочего стола, опять же?" вплоть до «И затем мы подключаемся к вызову чтения файла в слое зашифрованного профиля, чтобы обмануть Firefox, думая, что они отключили куки с doubleclick.net».

Вы спрашиваете об абсолюте, и я думаю, что это неправильный способ взглянуть на это, потому что ответ будет: «Вам действительно не нужен пароль пользователя» , что очень вводит в заблуждение. Реальность такова, что до тех пор, пока Microsoft не предоставит (или вы не установите стороннее программное обеспечение, чтобы разрешить) такую ​​возможность, как * NIX's su/ sudo, вы никогда не сможете идеально имитировать учетную запись пользователя для всех целей, сохраняя при этом видимость здравомыслия, не требуя случайных Примечание об использовании я не сказал «раскрытие!» - их пароля.

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

Когда-то, как в 1998 году, мой ИТ-отдел раньше запрашивал пароль пользователя, когда мы делали замену ПК, чтобы мы могли настроить его точно так же, как у него был старый. Вплоть до расположения иконок. Поскольку мы находились в среде Novell NetWare без соответствующего домена WinNT, изменение их сетевого пароля не изменило их локальный пароль, поэтому нам нужно было иметь этот пароль, если мы хотим обеспечить такой уровень бесперебойного обслуживания.

Это было 13 лет назад. Вы специально спрашивали о доменах Windows. На работе, которую я только что покинул, в крупном университете, конечный пользователь мог решать, раскрывать ли пароль или нет, где бы он ни работал. Другими словами, конечный пользователь выбрал его, а не принудил ИТ. У некоторых очень занятых руководителей высшего звена в орг-диаграмме, как правило, входил помощник администратора, поэтому ИТ-специалистам было легко подключиться (согласие уже было делегировано).

В Windows единственный способ вручную настроить профиль пользователя - войти в систему под этим пользователем. Если по какой-либо причине этот профиль требует ручной настройки (остаются плохие деинсталляции, которые мешают переустановке, или другие странные вещи), ИТ-специалисту необходимо будет войти в систему как этот пользователь. Это может быть сделано путем принудительной смены административного пароля, когда пользователь раскрывает свой пароль, или когда пользователь регистрирует ИТ-сотрудника под себя и позволяет ИТ-специалисту работать.

Некоторым приложениям во время установки требуется возможность вносить изменения или ссылаться на профиль пользователя (например, приложения CRM, которые интегрируются с Outlook) путем использования переменных среды, таких как% userprofile%, изменения HK_CURRENT_USER и тому подобного.

Несмотря на то, что вы, безусловно, могли бы «перепроектировать» установку с помощью таких инструментов, как procmon, а затем вручную изменить профиль пользователя, реестр и т. Д., Это крайне неэффективно, непрактично и подвержено ошибкам.

Абсолютно 100% нет. Все, что необходимо сделать с другой учетной записью пользователя, следует сделать, сбросив пароль пользователя, войдя в систему, а затем либо заставив пользователя вызвать службу поддержки, либо восстановив пароль для чего-либо, о чем говорят пользователи, и установив учетную запись для принудительного изменения пароля. при следующем входе. Признайте, что я работал в достаточно больших и безопасных средах, и раскрытие вашего пароля кому-либо обычно являлось основанием для увольнения (и так должно быть в большинстве ситуаций).

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

Конечно, можно привести аргументы, что вам никогда не придется запрашивать пароль. Я бы предпочел сказать своим пользователям "никогда не делиться" ... и да, конфигурация в большинстве случаев может быть обработана администратором для пользователя. Но устранение неполадок - другое дело.

Мы поддерживаем индивидуальную программу с 2600 студентами и 500 сотрудниками. Мы ежедневно решаем «странные» проблемы с программным обеспечением. Довольно часто мы сталкиваемся с проблемой как с пользователем, чтобы решить проблему (или с некоторой уверенностью определить, что потребуется перезагрузка). Безусловно, мы пытаемся сделать это с присутствующим пользователем - но это не всегда практично; у них есть график для поддержания.

А как насчет смарт-карт? Есть ли в среде AD 2010/2012 какая-либо возможность, чтобы смарт-карта могла быть (временно) связана с учетной записью домена? Это позволило бы получить доступ к учетной записи пользователя в полной мере, не раскрывая при этом свой пароль. Карта может быть деактивирована после устранения неполадок. Техники могли бы использовать учетную запись, но карты могли бы хорошо контролироваться.

Мы использовали устройства для считывания отпечатков пальцев в течение многих лет, но процесс его настройки для конкретной технологии, а затем очистки этого отпечатка просто невозможен. Я не уверен, насколько сложным будет процесс «авторизации», а затем «деактивации» смарт-карты для конкретного пользователя, но, похоже, это может быть достойным компромиссом.

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

Если вы войдете в систему как этот пользователь, вы не дадите им дополнительные разрешения. Вы входите в систему как они со своими разрешениями.