Автоматическое изменение паролей локальных администраторов.
С помощью средства Set-LocalPassword можно обеспечить более защищенную среду. Служба Active Directory (AD) обеспечивает удобный механизм централизованного управления учетными записями в сложных доменах, однако она не позволяет решить одну проблему управления учетными записями, а именно - проблему обновления паролей для локальных учетных записей "администратор", хранящихся на серверах, которые не являются контроллерами доменов (domain controller, DC).
Чем больше сеть, тем легче мы забываем, что пароли, которыми защищены локальные учетные записи администраторов, тоже являются локальными. Эти записи могут пригодиться в случаях, когда возникает необходимость получить доступ к компьютеру, который не может обратиться к контроллеру домена, и при этом в системе нет кэшированных учетных данных администратора домена. Кроме того, локальные учетные записи администраторов являются слабым звеном системы безопасности, если они защищены слабыми паролями или если эти пароли регулярно не обновляются. Более подробную информацию о кэшируемых учетных данных можно найти в статье Microsoft "How Interactive Logon Works," .
Если сеть имеет комплексную инфраструктуру, обеспечивающую централизованное хранение профилей пользователей, одно из решений проблемы безопасности может состоять в том, чтобы просто отключить локальную учетную запись администратора или заблокировать доступ к ней, если на компьютерах установлена Windows 2000 или более поздняя версия. Более подробные сведения об отключении локальных учетных записей администраторов содержатся в подготовленной специалистами Microsoft статье "How to disable the Local Administrator account in Windows", . Отключение локальной учетной записи администратора означает, что у вас больше не будет хлопот с ее администрированием и что вы всегда сможете в нужное время восстановить ее для выполнения плановых работ в автономном режиме. Если же на вашей рабочей станции произойдет сбой операционной системы, самая серьезная проблема, с которой вам, возможно, придется столкнуться, - это автоматическое восстановление рабочей станции на базе пользовательских данных, которые должны быть надежно укрыты в сетевом хранилище.
Однако организациям, не располагающим подобной централизованной сетевой инфраструктурой, требуются дополнительные средства для изменения паролей. Вероятно, некоторые организации не смогут пойти на отключение локальных учетных записей администраторов. Так, действующая учетная запись может понадобиться для того, чтобы войти в систему в случае, если компьютер потеряет соединение с контроллером домена.
В других организациях регулярно возникает необходимость эксплуатировать системы в автономном режиме, так что их сотрудникам приходится в рамках выполнения правил безопасности отключать кэшированные учетные данные. Одно из возможных решений для этих организаций - автоматизировать процедуру обновления паролей с помощью провайдера WinNT Microsoft Active Directory Service Interfaces (ADSI). Этот провайдер, предназначенный для обеспечения совместимости с сетями Windows NT 4.0, позволяет обращаться к защищенным базам данных отдельных рабочих станций. Провайдер WinNT доступен в системах Windows 2000 и более поздних версий; чтобы установить его в среде NT 4.0, нужно предварительно добавить расширения клиента ADSI с компакт-диска Windows Server 2003 или Windows 2000.
Если судить по документации ADSI, процедура изменения паролей локальной учетной записи "администратор" представляется исключительно простой: демонстрационный сценарий состоит всего лишь из нескольких строчек кода. Однако когда этот сценарий используется в реальных условиях, часто возникают проблемы. Давайте рассмотрим эти проблемы, а также другие соображения, которые необходимо иметь в виду при создании сценариев, предназначенных для обновления паролей локальных учетных записей администраторов.
Как показывает приведенный в документации ADSI демонстрационный сценарий, с помощью всего лишь нескольких строк VBScript-кода Windows Script Host (WSH) можно дистанционно менять пароли локальных администраторов. Допустим, у вас имеется компьютер с именем PC903 и локальной учетной записью la, которую вы хотите защитить паролем tw1nkl3. PC903 является членом домена, и вы зарегистрировались в этом домене как администратор домена, что по умолчанию предоставляет вам все необходимые права для дистанционного администрирования системы PC903. Решить задачу поможет следующий сценарий:
Set user = GetObject (_ "WinNT://ws903b/la, user") user. SetPassword "tw1nkl3" user. SetInfo
Этот демонстрационный сценарий компактен, как и большинство других сценариев, отобранных для документации ADSI. Но для того, чтобы превратить этот код в мощный надежный инструмент для решения реальных задач, вам придется немного над ним поработать.
Один из недостатков этого демонстрационного сценария состоит в том, что он не выполняет процедуру аутентификации. Сценарий просто использует текущие учетные данные для подтверждения ваших полномочий на подключение к удаленной системе и изменение пароля. Теоретически вы можете, оставаясь зарегистрированным и не обладающим административными полномочиями пользователем, указать в сценарии принадлежащие администратору имя пользователя и пароль для ситуаций, когда сценарий с помощью ADSI подключается к службе AD на удаленном компьютере. Однако, испробовав этот подход на практике, я обнаружил, что он влечет за собой слишком много вторичных проблем и дает весьма скромные результаты.
Прежде всего, мне пришлось столкнуться с проблемой абсолютно непредсказуемых сбоев при попытке зарегистрироваться в небольшом домене. Я выяснил, что это известная ситуация, описанная в статье Microsoft "User authentication issues with the Active Directory Service Interfaces WinNT provider" (). Если соединение с компьютером, который вы хотите администрировать, уже установлено, попытка указать другие данные приводит к сбою.
Примирившись с мыслью о том, что необходимо использовать команду RunAs или непосредственно регистрироваться в системе в качестве администратора, я понял, что при этом сценарий становится проще и надежнее. Если для получения доступа к учетной записи и для выполнения сценария вы используете права администратора рабочей станции, вам больше не приходится думать о том, как вводить и передавать учетные данные администратора. Все эти задачи автоматически решаются системой Windows.
Похоже, что во всех написанных программистами сценариях обычно реализуется одна из двух стратегий обработки ошибок: полное подавление ошибок или стратегия "сбой и выход". Эти стратегии хороши, когда требуется продемонстрировать, как работает та или иная технология, но ни одна из них не подходит, если необходимо получить добротный сценарий.
В идеале сценарий, обеспечивающий обновление паролей, должен извещать администратора о случаях, когда эта цель не достигается, и пояснять, по какой причине произошел сбой. Но сценарий не должен завершаться аварийным выходом лишь по той причине, что первая из двухсот систем, чьи пароли администраторов необходимо изменить, функционирует в автономном режиме. Напротив, завершая каждую попытку изменения пароля на той или иной системе, он должен возвращать имя этой системы, сообщать, была ли предпринятая попытка успешной, и если она оказалась неудачной, предлагать наилучшее краткое объяснение. Перед тем как я приступлю к детальному изложению того, как сценарий отображает выходные данные, давайте рассмотрим причины типичных ошибок.
Использование строки соединения (напр., WinNT://ws903b/la, user) позволяет упрощать вызовы WinNT. Но если вызов не проходит, провайдер WinNT возвращает лишь цифровой код ошибки, для понимания которого приходится искать дополнительную информацию. К счастью, при установлении дистанционных соединений в локальной сети часто встречаются только три ошибки. Все они вызываются очевидными причинами, так что если в сценарии будут заложены средства проверки этих ошибок и предусмотрена возможность возвращения полезной информации, такой сценарий может быть весьма полезным.
Первая ошибка возникает в случае недоступности удаленной системы. В этом случае сценарий обычно выдает сообщения об ошибке в течение нескольких секунд. В сети такие ошибки обычно возникают, когда доступ к некоторым системам невозможен - как правило, потому, что эти системы работают в автономном режиме (или потому, что речь идет о ноутбуках, в данный момент не подключенных к сети).
Вторая ошибка возникает, когда пользователь не имеет достаточных прав для установления соединения. Причина, как правило, состоит в том, что учетная запись пользователя не наследует разрешения на управление удаленной рабочей станцией. Такая ситуация возможна в тех случаях, когда пользователь не регистрируется в системе как пользователь, обладающий административными правами на уровне домена, или когда удаленная система не включена в систему безопасности домена.
Причина третьей ошибки - отсутствие указанного имени пользователя на рабочей станции. Эта ошибка часто возникает как побочный эффект непродуманной практики назначения имен.
Как уже отмечалось, эти три ошибки встречаются чаще других, однако список возможных ошибок ими не исчерпывается. В сценарии должны быть предусмотрены и другие ошибки, каковы бы ни были их причины. Сценарий может не выдавать их четкое описание, но он должен, по крайней мере, возвращать код ошибки в шестнадцатеричном формате и сообщение об отказе. Если ваш код ошибок составлен в шестнадцатеричном формате, можете искать причины конкретных проблем на Web-странице кодов ошибок ADSI (ADSI Error Codes) по адресу .
Другие соображения Для изменения локального пароля администратора на удаленной системе требуется лишь три параметра: имя учетной записи, имя компьютера и новый пароль. Знать старый или текущий пароль при этом необязательно. Однако вопрос о том, как представить эту информацию в сценарии, требует дополнительного рассмотрения.
Имя локальной учетной записи администратора Вы можете жестко запрограммировать имя локальной учетной записи администратора в сценарии или предусмотреть возможность использования сценарием идентификатора SID для получения имени учетной записи. Однако ни один из этих подходов не дает возможности создать универсальное инструментальное средство, которое можно было бы использовать для работы с более чем одной учетной записью. Этой цели мог бы послужить сценарий, пригодный для обработки любого имени учетной записи. Простейшее решение состоит в том, чтобы пользователь сам задавал имя учетной записи в качестве первого (и, возможно, единственного) аргумента сценария, вводимого из командной строки.
Имя компьютера В ситуациях, когда компьютеры можно, что называется, пересчитать по пальцам, применимо такое решение: возложить на пользователя задачу указания имен компьютеров в качестве параметров из командной строки. Если же компьютеров много, пожалуй, целесообразнее использовать средства ввода, стандартные для оболочки, предоставив сценарию возможность считывать имена компьютеров из файла или получать их из других выходных данных командной строки.
Новый пароль Лучше всего вводить новый пароль без отображения на экране и с подтверждением. Такой ввод можно обеспечить с помощью компонента ScriptPW (scriptpw.dll) систем Windows 2003 или Windows XP. Объект Password компонента ScriptPW предлагает пользователю, запустившему сценарий, ввести пароль, а затем маскирует введенные символы так, чтобы пароль не смог увидеть кто-нибудь еще. Однако если мы решим использовать объект ScriptPW.Password, возникнет вопрос: а как быть с системами, в которых объект ScriptPW.Password не предусмотрен, например с системами Windows 2000 и NT 4.0? Если использование сценария в старых сетях представляется настолько важным, что вы готовы пойти на риск ввода паролей без применения средств защиты, вы, вероятно, решите санкционировать ввод паролей пользователями в качестве параметра в окне командной строки.
Пример решения для реальных условий эксплуатации Изучив проблемы с демонстрационным сценарием и определив, каким образом следует вводить имя локальной учетной записи администратора, имя компьютера и новый пароль, я создал инструментальное средство Set-LocalPassword. Этот продукт состоит из двух файлов: файл Set-Local-Password.wsf осуществляет замену паролей, а файл Set-LocalPassword.cmd обеспечивает корректную обработку входящих и исходящих данных командной строки средствами WSH.
Назначение программы Set-LocalPassword заключается в том, чтобы осуществлять аутентификацию, а также извещать пользователя о том, была ли успешной каждая операция по обновлению пароля, а если нет, то в чем причина сбоя. Кроме того, программа Set-LocalPassword предназначена для того, чтобы пользователь мог указывать имя локальной учетной записи администратора в окне командной строки. Если вы хотите облегчить работу с программой, можете собрать имена компьютеров, на которых следует выполнять сценарий, во входном файле (в случае, когда у вас много компьютеров) или отобразить их в окне командной строки (если компьютеров мало). Чтобы сценарий можно было использовать в различных версиях Windows, предусмотрена возможность получения сценарием новых паролей одним из двух способов. При работе с системами Windows 2000 и Windows NT 4.0 сценарий использует пароли, вводимые пользователями в окне командной строки, а в средах Windows 2003 и Windows XP он получает пароли с помощью объекта ScriptPW.Password. Функция GetConfirmed-Password, представленная в Листинге 1, делает возможным подтверждаемый скрытый ввод паролей. Эту функцию можно встраивать в любой код VBScript, выполняемый на системах Windows XP или более поздних версий Windows.
Перед тем как приступить к использованию программы Set-Local-Password, необходимо составить список имен компьютеров, на которых вы будете изменять пароли локальных учетных записей администраторов. Теоретически такими именами могут быть имена в стиле NetBIOS, имена DNS (полные или неполные) либо даже IP-адреса. Впрочем, использовать IP-адреса я не рекомендую: они могут быстро меняться и не помогут выявлять системы, на которых возникают проблемы. В сложных сетях вам, возможно, придется использовать полные имена DNS. Если в вашем ведении много компьютеров, можете вводить имена во входной файл .txt. Каждое имя следует располагать на отдельной строке.
Если у вас нет готового решения для формирования списка систем сети, можете экспортировать имена из оснастки Active Directory Users and Computers консоли управления Microsoft Management Console (MMC) или использовать утилиту Dsquery из комплекта Windows Server 2003 Administration Tools Pack. Dsquery функционирует в доменах Windows 2000; важно только, чтобы в них был установлен пакет обновлений Windows 2000 Service Pack 3 (SP3) или более поздней версии. Впрочем, при использовании Dsquery необходимо убедиться в том, что в списке нет имен контроллеров доменов, если только не планируется изменить пароль для учетной записи домена с таким же именем, как имена учетных записей рабочих станций, которые предстоит изменять. Dsquery возвращает и имена компьютеров, заключенные в кавычки. Файл Set-LocalPassword.wsf автоматически убирает кавычки, но они, как правило, создают проблемы для других инструментальных средств, которые принимают имена компьютеров в качестве входных данных.
Как пользоваться программой Метод активизации программы Set-LocalPassword зависит от версии Windows и от того, много или мало компьютеров пройдут через процедуру обновления паролей. Чтобы запустить программу Set-LocalPassword на системе Windows 2003 или Windows XP, состоящей из большого числа компьютеров, войдите в домен с использованием учетной записи, обладающей правами администрирования рабочих станций, откройте окно командой строки и введите команду для запуска программы. Предположим, что имя входного файла C:\computers.txt, что все учетные записи администраторов на рабочей станции имеют имя admin и что вы хотите во всех случаях в качестве пароля использовать символы tw1nkl3. На системе Windows 2003 или Windows XP выполните команду
Set-LocalPassword admin < computers.txt
Set-Local Password предложит ввести и подтвердить новый пароль и начнет изменять пароли. В случае успешной замены на экране отображается имя системы и вслед за ним слово SUCCESS. Если происходит некатастрофический сбой, сценарий отображает имя системы и далее слово FAILURE, а также краткое описание причины. Если вы не хотите отображать сообщения об успехе, можете подавить их с помощью ключа /Q; в этом случае на экране будут отображаться только имена тех систем, которые не удается обновить, а также возможные причины сбоев.
Выходные данные сценария можно перенаправить для записи в файл. Данные о сбоях передаются по стандартному потоку ошибок, поэтому в команде о перенаправлении должен быть указан поток ошибок; его идентификатор - 2. Следующая команда направляет сообщения об успешных изменениях паролей на консоль и перенаправляет сообщения об ошибках в файл error.log:
Если вы хотите изменить пароли всего лишь на нескольких системах, можете указать имя каждой системы в командной строке после имени учетной записи, пароль для которой изменяется:
Set-LocalPassword admin WS01 WS02 WS03 WS04
Чтобы использовать программу Set-LocalPassword на системе Windows 2000 или Windows NT 4.0 с установленными расширениями ADSI, нужно указать пароль в командной строке. Войдите в домен с использованием учетной записи, наделенной правами администрирования рабочих станций, откройте окно командной строки и запустите команду
Изменяем пароли без проблем В организациях, не располагающих централизованной инфраструктурой, необходимо предусмотреть способ регулярного обновления паролей локальных учетных записей администраторов для устранения пробелов в системе защиты. Программа Set-LocalPassword позволяет таким организациям с легкостью изменять важные пароли вне зависимости от размеров сетей Windows.
Листинг 1: Функция GetConfirmedPassword
Function GetConfirmedPassword () 'Требуется система Windows XP или более поздней версии. 'Сценарий ДОЛЖЕН выполняться в среде cscript.exe. Dim pw: Set pw = CreateObject ("ScriptPW. Password") Dim confirmed: confirmed = False Dim password Do While confirmed = False WScript. StdOut. WriteLine "Введите новый пароль:" password = pw. GetPassword WScript. StdOut. WriteLine "Подтвердите новый пароль:" If password = pw. GetPassword Then confirmed = True Else WScript. StdOut. WriteLine "Пароли не совпали". End If Loop GetConfirmedPassword = password End
Алекс Ангелопулос (alexangelopoulos@hotmail.com) - старший инженер по сетям. Специализируется на оказании консультационных услуг в сфере ИТ. Является обладателем сертификатов MCSE, MCP+I и MVP. Источник:
