Чи буде ІТ-кому потрібен пароль домену користувача?

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

ОНОВЛЕННЯ:

Поки відповіді стосувалися "налаштування" або зміни профілю користувача. Однак є ця стаття від Microsoft про зміну профілю за замовчуванням, який застосовується до користувачів під час першого входу, і ці інструкції щодо зміни налаштувань реєстру Windows іншого користувача у будь-який час. Що змінив би адміністратор під час входу в систему як користувач, який адміністратор не міг змінити, використовуючи ті чи інші доступні методи, які не включають вхід як користувач? Просто "увійти як користувач" не є причиною запитувати або змінити пароль користувача. Я шукаю практичну причину для цього.

Адже адміністратору не прийнятно і не потрібно запитувати пароль користувача.

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

Причиною цього є підзвітність. Кожен користувач несе відповідальність за безпеку свого пароля. Якщо зловмисна активність була віднесена до облікових даних користувача, цей користувач може нести відповідальність. Тому вони повинні забезпечити збереження своїх даних.

Також організація несе відповідальність за те, щоб це не тільки було прийнято, але і було здійснено. Був юридичний випадок, коли хтось із організації надсилав шкідливий електронний лист, використовуючи чужу поштову скриньку. Власник поштової скриньки був остаточно звільнений. Хоча вони стверджували, що дали свій пароль комусь іншому, компанія наполягала на тому, щоб вони відповідали за збереження доброчесності своїх облікових даних, і тому вони несли відповідальність, як це було продиктовано ІТ-політикою їхньої компанії. Потім цей суд був скасований судом, коли цей користувач довів, що в організації існує культура обміну паролями. Суд постановив, що якщо компанія не може сприймати активну реалізацію своєї ІТ-політики, вона не може покладатися на неї підзвітності за цих обставин.

Це говорить про те, що явно існує прогалина між теорією та практикою. Я уклав договір на велику багатонаціональну фірму, яка надає, серед іншого, ІТ-консультаційні послуги, і в рамках документально підтвердженої процедури оновлення ДП нам було доручено запитувати пароль кінцевого користувача.

Особисто я до цього дотримуюся жорсткого підходу. Я не вважаю, що потрібно запитувати паролі (або перенастроювати їх для доступу до облікового запису користувача). Якщо для цього обійдеться значно збільшене навантаження, то так і нехай. Це не привід для компрометації безпеки. Я здогадуюсь, що мені просто пощастило, що я не менеджер, і тому не потрібно брати на себе відповідальність за ці рішення, коли доручає це зробити хтось, хто вище.

Будемо зрозумілими: якщо ви адміністратор домену, ви можете встановити програмне забезпечення - на розум приходить драйвер пристрою, який може буквально робити що завгодно. Однак це різний ступінь непрактичності, починаючи від "Що таке ключ реєстру для фону робочого столу?" аж до "І тоді ми підключаємося до виклику читання файлу всередині шару зашифрованого профілю, щоб змусити Firefox думати, що вони відключили файли cookie з 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 2012 року AD можлива можливість, щоб смарт-карта була (тимчасово) пов’язана з обліковим записом домену? Це дозволить отримати доступ до облікового запису користувача у повній реальності, при цьому не викриваючи їх пароль конкретно. Після закінчення усунення несправностей карту можна було деактивувати. Техніки могли використовувати рахунок, але картки могли добре контролюватися.

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

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

Якщо ви ввійшли як цей користувач, ви не надаєте їм додаткових дозволів. Ви входите в систему як вони зі своїми дозволами.