Назад | Перейти на главную страницу

Потребуется ли ИТ-специалистам когда-нибудь пароль домена пользователя?

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

ОБНОВИТЬ:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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