wAdmin.ru » Powershell http://blog.wadmin.ru Записки сисадмина Sun, 05 Feb 2012 12:00:43 +0000 en hourly 1 http://wordpress.org/?v=3.3.1 PowerShell модуль GroupPolicy http://blog.wadmin.ru/2012/02/powershell-grouppolicy-module/ http://blog.wadmin.ru/2012/02/powershell-grouppolicy-module/#comments Fri, 03 Feb 2012 04:40:04 +0000 Сергей Мариничев http://blog.wadmin.ru/?p=5619 handcuffsПродолжаем изучать модули PowerShell, доступные только в RSAT для Widnows 7, хочу обратить Ваше внимание на модуль GroupPolicy.

Напомню что в прошлый раз был модуль Active Directory.

Модуль GroupPolicy доступен в следующих случаях:

  • Windows Server 2008 R2 с установленной ролью контроллера домена.
  • Рядовой сервер Windows Server 2008 R2 с установленной консолью GPMC.
  • Windows 7 с установленным пакетом Remote Server Administration Tools (RSAT).

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

Get-Command -Module GroupPolicy

или более правильная, по мнению курса Advanced Group Policy Troubleshooting, методика

Get-Command *GP*

можно даже вот так

Get-Command -Module grouppolicy | get-help | Format-Table name, synopsis -AutoSize -Wrap

Результат не изменится, помощь есть помощь…

Набор более чем стандартный, есть и Get и Set и Remove, все хорошо документировано, ничего сложного и нет.

Примечание: полный список команд приводить не буду так как он доступен по ссылке на TechNet

Командлеты используются для выполнения нижеперечисленных операций с доменными объектами групповой политики:

  • Создание, удаление, резервное копирование и импорт.
  • Создание, связывание, обновление и удаление связей объектов групповой политики с контейнерами Active Directory.
  • Установка флагов наследования и разрешений в подразделениях и доменах Active Directory.
  • Настройка реестровых параметров политики: обновление, извлечение, удаление.
  • Создание и изменение Started GPO.

Постараюсь не размазывать а привести только самое интересное.

Для использования командлетов сначала импортируем модуль GroupPolicy.

import-module GroupPolicy

Примечание: Пока что все что приводится запускает от имени бесправного доменного пользователя. Позже объясню для чего это нужно.

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

Get-GPO -All

Предположим что вы знаете список имеющихся OU, но забыли название а лезть в оснастку ADUC вам жутко лень. Что делать?

Все просто, вводим команду

dsquery ou

или тоже самое, но на powershell

([ADSISearcher]"objectClass=OrganizationalUnit").findall() | select-Object -property path

Получаем результат.

«OU=Domain Controllers,DC=lab,DC=com»
«OU=Members Servers,DC=lab,DC=com»
«OU=Managed Computers,DC=lab,DC=com»
«OU=TestOU,DC=lab,DC=com»

Структура ясна, теперь запрашиваем список объектов групповых политик для dc=lab,dc=com

Get-GPInheritance -Target "dc=lab,dc=com" -Domain lab.com -Server DC1

Результат вполне ожидаемый.

Name : lab.com
ContainerType : Domain
Path : dc=lab,dc=com
GpoInheritanceBlocked : No
GpoLinks : {Default Domain Policy}
InheritedGpoLinks : {Default Domain Policy}

Теперь изучим политики привязанные к OU – Managed Computers.

Get-GPInheritance -Target "ou=Managed Computers,dc=lab,dc=com" -Domain lab.com -Server DC1

В результате мы видим что в этому OU есть линк на политику «Desktop – Baseline Policy». Посмотрим что можно прочитать про найденную политику.

Get-GPO -Name "Desktop – Baseline Policy"

Результат не впечатляет :) 

DisplayName      : Desktop - Baseline Policy
DomainName       : lab.com
Owner            : LAB\Domain Admins
Id               : 3aa02562-cf15-41a0-f8fb-416a2a421b4f
GpoStatus        : AllSettingsEnabled
Description      :
CreationTime     : 2/26/2011 12:15:42 AM
ModificationTime : 2/26/2011 12:15:42 AM
UserVersion      : AD Version: 0, SysVol Version: 0
ComputerVersion  : AD Version: 0, SysVol Version: 0
WmiFilter        :

Примечание: На практике User Version и Computer Version, если заданы хоть какие нибудь настройки, явно не равняются нулю :)

Предположим, у нас есть некий набор настроенных GPO. Выполним  сначала запрос полномочий

Get-GPPermissions -Name "Desktop – Baseline Policy" -All

а после него создадим отчет по имеющимся настройкам

Get-GPOReport -Name "Desktop – Baseline Policy" -ReportType html > d:\Scripts\gp-report.html

Получилось? Естественно. Ведь в правах скорее всего установлено что все прошедшие проверку могут читать.

Что остается сделать?

Наверное, резервную копию? Проверим получится или нет.

Backup-GPO -Name "Desktop – Baseline Policy" -Path D:\Scripts\backup -Comment "test backup"

Прокатило…

Примечание: Помните про «бесправного пользователя»? В данный момент с его правами удалось сделать резервную копию GPO.

Попробуем выполнить резервную копию всех объектов которые можно прочитать.

Backup-GPO -All -Path D:\Scripts\Backup\all -Comment "test backup – all GPO"

Получилось для всех имеющихся политик?

Итог

Каков вывод?
Модуль GroupPolicy будет полезен администратору, например для автоматизации создания резервных копий объектов GPO и для аудита назначенных полномочий. Как показывает практика, остальные операции, как правило, выполняются из удобного графического интерфейса.

Если немного подумать, можно на базе модуля GroupPolicy написать скрипт для мониторинга изменений объектов. Например можно фиксировать следующие изменения:

  • Изменения прав на объекты.
  • Изменение версий. Атрибуты UserVersion и ComputerVersion.
  • Создание новых объектов.
  • …

Второй вариант немного неожиданный т.к. он основан на стандартном заблуждении многих админов заключенных в том что назначения стандартных разрешений для объектов GPO вполне достаточно.

Проблема сводится к тому что в большинстве случаев почти все объекты GPO можно прочитать, ошибка может привести к следующим последствиям.

Предположите на мгновения что некто сделал резервную копию GPO в котором у вас задаются пароли для локальных администраторов или настройки для сервисов…

Представили?

Дальнейшая судьба этих GPO скорее всего будет следующей:

  • Резервная копия будет восстановлена в тестовом окружении.
  • GPO назначено на OU.
  • После применения политики будут слиты хэши от пользователей которых вы настроили (например назначили пароль локальному администратору через Group Policy Preference) или получены пароли учетных записей от которых стартуют сервисы (частенько это могут оказаться учетки с правами доменного администратора или учетные записи пользователей имеющих очень большие права :) ).

Вариантов масса. Могу предположить сценарий похищения политик которые отвечают за настройки серверов с целью их анализа и пр.
Конечно, если у вас все в порядке с правами доступа к объектам, то вам вышеназванные жутики вам не страшны, но если у вас все могут читать то стоит задуматься…

PS Это не методика взлома Групповых политик, это повод задуматься над тем что у вас есть сейчас.

]]> http://blog.wadmin.ru/2012/02/powershell-grouppolicy-module/feed/ 0 Сбор запланированных заданий средствами PowerShell http://blog.wadmin.ru/2012/01/get-sched-task/ http://blog.wadmin.ru/2012/01/get-sched-task/#comments Thu, 19 Jan 2012 07:11:13 +0000 Сергей Мариничев http://blog.wadmin.ru/?p=5821 запланированные заданияЗапланированные задания. Казалось, что может быть проще..?

Есть утилита schtasks.exe, она умеет собирать, создавать и удалять задания. Пишем

schtasks.exe /?

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

Однако не все так просто как кажется. При наличии десятка серверов все кажется простым и понятным, но при наличии 500 и более серверов задача слегка усложняется. Вполне возможно что на рабочих станциях включен планировщик и вам необходимо собрать данные по запланированному заданию которое вы назначили через GPP, как пример можно привести задачу по развертыванию FEP 2010.

Примечание: Вопрос управления заданиями уже обсуждался, но это не мешает нам к нему вернуться.

Простой метод сбора информации о запланированных заданий приведен ниже. Скрипт формирует CSV файл который потом замечательно можно проанализировать в Excel.

# добавляем снапин от Quest
Add-PSSnapin Quest.ActiveRoles.ADManagement

# задаем нужный OU
$OU = ‘Domain/Members Servers’

# указываем имя файла отчета
$reportFile = "report.txt"

$servers = Get-QADComputer -SearchRoot $OU -SearchScope Subtree

foreach ($server in $servers) {
Write-Host $server.dnshostname
$tasks = schtasks.exe /Query /FO CSV /v /s $server.dnshostname
$tasks | ft HostName,TaskName,"Last Run Time" | Out-File -NoClobber -Append $reportFile
# если нет задачи выводить информацию в файл, а сразу получать результат на экран то можно
# сделать следующим образом.
# $tasks | ConvertFrom-Csv | ft HostName,TaskName,"Last Run Time"
}

PS Как мне правильно заметили эта публикация является модификацией более старой статьи.

]]> http://blog.wadmin.ru/2012/01/get-sched-task/feed/ 7 PowerShell – мониторинг состава групп http://blog.wadmin.ru/2012/01/powershell-group-member-monitoring/ http://blog.wadmin.ru/2012/01/powershell-group-member-monitoring/#comments Tue, 17 Jan 2012 07:12:02 +0000 Сергей Мариничев http://blog.wadmin.ru/?p=5860 powershellХороший знакомый попросим меня «по быстрому» набросать скрипт для мониторинга изменения участников групп в Active Directory.

Получилось кривовато, но вполне работоспособно. Логика работы скрипта проста:

  • Создаем текстовые файлы по именам групп при первом запуске.
  • При следующих запусках сравниваем текущее состояние с тем что есть в старых файлах.
  • При необходимости пишем в файл отчета.
  • Удаляем старый файл, создаем новый и записываем в него состав группы.

На всякий случай текст скрипта в текстовом формате – скачать.

Примечание: По мере «шлифовки» будут вносится правки.

# добавляем снапин от Quest
Add-PSSnapin Quest.ActiveRoles.ADManagement

# задаем формат даты
$currentDate = Get-Date -format M.d.yyyy

# указываем нужные пути и файл отчета
$reportFolder = "D:\Scripts\Powershell\GroupCheck\"
$report = "D:\Scripts\Powershell\$($currentDate)_report.txt"

# собираем данные о группах
$groups = Get-QADGroup -SizeLimit 0
$PreviousDay = @{}

# функция сравнения
function CompareResults ($query, $group) {
        foreach ($result in $query) {
                # пользователь добавлен в группу
                if ($result.SideIndicator -eq "=>") {
                        Write-Output "User added – $($result.InputObject.NTAccountName)"
                        "Group $($group). add user – $($result.InputObject.NTAccountName)" | Out-File -Append $report
                }
                # пользователь удален из группы
                if ($result.SideIndicator -eq "<=" ) {
                        Write-Output "User removed – $($result.InputObject)"
                        "Group $($group). remove user – $($result.InputObject)" | Out-File -Append $report
                }
        }
}

foreach ($group in $Groups) {
        $fileName = $reportFolder + $group + ".txt"
        if (!(Test-Path $fileName)) {
                New-Item $fileName -ItemType file -Force
        }
        $PreviousDay[$group] = Get-Content $fileName

        $MemberList = Get-QADGroupMember $group -SizeLimit 0
        $PreviousList = Get-Content $fileName
       
 if (($MemberList -ne $null) -and ($PreviousList -eq $null)) {
                foreach ($user in $MemberList) {
                        Write-Output "$($group): Add user – $($user.NTAccountName)"
                }
        } elseif (($MemberList -eq $null) -and ($PreviousList -ne $null)) {
                foreach ($user in $PreviousList) {
                        Write-Output "$($group): Remove user – $user"
                }
        } elseif (($MemberList -ne $null) -and ($PreviousList -ne $null)) {
                # анализ группы
                Write-Output "Check group – $($group)"
                $DiffResult = diff -ReferenceObject $PreviousList -DifferenceObject $MemberList
                CompareResults $DiffResult $group
        } else {
                # пустая группа
                Write-Output "Group $group – has no members"
        }
        $MemberList | Select-Object -Expand NTAccountName | Out-File $fileName
}

]]> http://blog.wadmin.ru/2012/01/powershell-group-member-monitoring/feed/ 2 Читаем RSS средствами PowerShell http://blog.wadmin.ru/2011/12/read-rss-via-powershell/ http://blog.wadmin.ru/2011/12/read-rss-via-powershell/#comments Wed, 28 Dec 2011 09:56:37 +0000 Сергей Мариничев http://blog.wadmin.ru/?p=5526 powershellВ процессе предпраздничного разгребания накопленных черновиков нашелся скрипт для получения RSS лент средствами PowerShell.

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

Хотя, вполне можно придумать сценарий когда у вас на рабочей станции  нет никаких ридеров, но есть доступ в интернет и злой дядька сисадмин не дает запускать ничего кроме IE который ходит только на один узел :)

Придумать можно все что угодно…

Скрипт простой, вот он:

# задаем адрес канала
$feed="http://feeds.feedburner.com/wmemories"
# создаем объект System.Net.WebClient
$client = New-Object System.Net.WebClient
# задаем кодировку. Без нее будут выводится крякозябры
$client.Encoding = [System.Text.Encoding]::UTF8

$rss = [xml]$client.DownloadString($feed)
# получаем все что есть
$rss.rss.channel.item | format-list
# или компактно выводим результаты в форме таблички
$rss.rss.channel.item | format-table title,pubDate, link

]]> http://blog.wadmin.ru/2011/12/read-rss-via-powershell/feed/ 1 Получаем Uptime в Windows. http://blog.wadmin.ru/2011/12/windows-uptime/ http://blog.wadmin.ru/2011/12/windows-uptime/#comments Wed, 28 Dec 2011 08:55:34 +0000 Сергей Мариничев http://blog.wadmin.ru/?p=5529 uptimeКогда то давно вопрос получение uptime от серверов уже поднимался, но в предновогодние дни стоит затронуть его еще раз…

Назову причину – коллега забыл про сервер разработки и его аптайм до вчерашнего дня составил 832 дня !

Молиться надо на таких разработчиков раз они не только не уронили, но и не доставали более двух лет :)

В любом случае на цифирьки посмотреть не мешает, при большом аптайме, как минимум не установлены критические обновления. И закончится это может в любой момент и вероятность того что закончится оно «плохо» или «могло быть и лучше если бы почесались»…

Да простят меня «линуксоиды», мерится аптаймами не будем :) просто посмотрим как можно получить нужную цифру и на методики получения информации о том сколько у нас отработала система.

Примечание: Коллеги линукс-админы, это не камень в ваш огород, я знаю много отличных специалистов, но в ваших рядах затесались (в семье не без урода) те кто свято верит в то что сервер с ядром 2.2 и аптаймом в 5 лет совершенно безопасен и стабилен (при этом сервер светится как новогодняя елка во внешний мир). Я не поддерживаю такого и чаще всего просто не понимаю. Дискуссии про то что линукс мега надежен и супер стабилен и про то что виндофс  бяка поддерживать не буду. Надеюсь на понимание.

Специально для тех кто забывает про серверы…

Используем Диспетчер Задач

В Windows Vista и Windows Server 2008, в диспетчере задач есть возможность посмотреть аптайм.

  1. На таскбаре жмем мышом и выбираем Task Manager. Можно использовать комбинацию CTRL+SHIFT+ESC. Тут уж кто как привык.
  2. Выбираем вкладку Performance.
  3. В свойствах System видим нужное значение.

taskmgr

Примечание: К сожалению данная методика не доступна в Windows 2003. 

Используем утилиту systeminfo

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

Открываем командную строку и вводим:

systeminfo | find "System Boot Time:"

systeminfo

 

Утилита Uptime

Для удобства Microsoft сделал довольно полезный инструмент который можно получить по ссылке:

http://support.microsoft.com/kb/232243

Для использования необходимо:

  • Загрузить утилиту.
  • Запихнуть ее в папку которая включена в переменную %PATH%
  • Для получения справки используйте ключ /?
  • Если справка не требуется то вводите. 
    uptime.exe

uptime

Используем утилиту NET STATISTICS

В выводе команды:

net statistics workstation

Среди предоставленной информации есть время последней загрузки системы

statistics

Используем Event Viewer

Метод заключен в поиске сообщения с кодом 6005 (запуск сервиса EventLog) от источника EventLog и события с кодом 6006 (остановка сервиса EventLog)

Get-EventLog -LogName system | Where-Object {$_.EventID -eq 6005 -or $_.EventID -eq 6006} | Select TimeGenerated, EventID

Естественно эту же информацию легко получить с удаленного хоста введя команду:

Get-EventLog -LogName system -Computer HOST_NAME -Credentil (Get-Credential)| Where-Object {$_.EventID -eq 6005 -or $_.EventID -eq 6006} | Select TimeGenerated, EventID

Более просто этот метод реализуется просмотром журнала System и поиска событий с кодами 6005 и 6006.
system-uptime

Используем WMI

У WMI класса Win32_PerfFormattedData_PerfOS_System есть счетчик SystemUptime, который можно использовать для получения необходимого значения.

# указываем текущий компьютер
strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")
Set colOperatingSystems = objWMIService.ExecQuery ("Select * From Win32_PerfFormattedData_PerfOS_System")

For Each objOS in colOperatingSystems
# для получения минут делим SystemUpTime на 60
intSystemUptime = Int(objOS.SystemUpTime / 60)
strMessage = "System uptime is " & intSystemUptime & " minutes"
msgBox strMessage, 0, "System Uptime"
Next

Можно использовать LastBootUpTime из класса Win32_OperatingSystem, но об этом в следующем методе.

Используем PowerShell

В данном методе используется WMI класс Win32_OperatingSystem и разница по времени между LocalDateTime и LastBootUpTime.

$wmi = Get-WmiObject -Class Win32_OperatingSystem
$wmi.ConvertToDateTime($wmi.LocalDateTime) – $wmi.ConvertToDateTime($wmi.LastBootUpTime)

Получаемся не совсем аккуратная «простыня»

Days              : 12
Hours             : 22
Minutes           : 18
Seconds           : 29
Milliseconds      : 912
Ticks             : 11171099124010
TotalDays         : 12,9295128750116
TotalHours        : 310,308309000278
TotalMinutes      : 18618,4985400167
TotalSeconds      : 1117109,912401
TotalMilliseconds : 1117109912,401

Более компактного вывода можно добиться командой которая дает немножко нестандартный, но все же вывод.

[math]::round(((Get-Date) - ($q=gwmi Win32_OperatingSystem).ConvertToDateTime($q.lastbootuptime)).TotalDays, 2)

Более наглядный вариант умеющий выводить в файл результаты:

$ErrorActionPreference = "SilentlyContinue"
$reportFile = "D:\Scripts\Output\LastReboot.htm"
$reportFolder = "D:\Scripts\Output"
Remove-Item $reportFolder -Recurse

$InputFile = Get-Content Servers.txt
$LastReboot = @()
foreach ($computer in $InputFile) {
$q = "" | Select-Object ‘Machine Name’,‘Last Reboot TimeStamp’,‘Reboot Initiator’,‘Reboot Reason Code’
$q.‘Machine Name’ = $computer
$q.‘Last Reboot TimeStamp’ = [Management.ManagementDateTimeConverter]::ToDateTime((Get-WmiObject -class Win32_OperatingSystem -computername $computer -namespace "root\CIMV2").LastBootUpTime)
$LastReboot += $q
}
New-Item $reportFolder -ItemType directory

$LastReboot | Sort-Object ‘Last Reboot TimeStamp’ -Descending | ConvertTo-Html | Out-File $reportFile
Invoke-Expression $reportFile

PS несмотря на обилие методик я все же предпочитаю «дедовский метод» – утилиту uptime.exe.

]]> http://blog.wadmin.ru/2011/12/windows-uptime/feed/ 8 Модуль Active Directory для PowerShell http://blog.wadmin.ru/2011/12/powershell-active-directory-module/ http://blog.wadmin.ru/2011/12/powershell-active-directory-module/#comments Mon, 12 Dec 2011 09:43:31 +0000 Сергей Мариничев http://blog.wadmin.ru/?p=4441 powershellНа днях спорил с одним из коллег по методикам управления Active Directory средствами PowerShell-а.

Коллега доказывал что нет ничего лучше и удобнее чем PowerGUI, но он либо забыл либо не учел что есть еще Active Directory Module for Windows PowerShell и не учел то что PowerGUI хоть и удобен, но все же является сторонним средством которое надо хотя бы изредка обновлять.

Собственно, ниже речь пойдет о том как установить и о методиках использования модуля Active Directory для PowerShell.

Устанавливаем Active Directory Module для Windows PowerShell

С выходом PowerShell 2.0 мы получили замечательный модуль для администрирования Active Directory. Модуль Active Directory для Windows PowerShell работает на Windows Server 2008 R2 и на Windows 7, для его работы необходим веб-сервис который должен быть размещен на одном из контроллеров домена.

Подготовка контроллера домена

Для работы нам понадобится установка Active Directory Web Services (ADWS) на контроллере с Windows Server 2008 R2 AD DS. В случае если у вас нет контроллера на Windows Server 2008 R2, можно установить Active Directory Management Gateway Service на имеющиеся системы список которых есть чуть ниже.

Загрузить Active Directory Management Gateway Service можно здесь.

Установку производится на следующие ОС:

  • Windows Server 2003 R2 with Service Pack 2
  • Windows Server 2003 SP2
  • Windows Server 2008
  • Windows Server 2008 SP2

После установки появится новый сервис:

adws-service

Теперь можно устанавливать модуль Active Directory для Windows PowerShell. Он доступен на всех версиях Windows Server 2008 R2 (кроме Web Edition) и на Windows 7.

Установка Active Directory Module для Windows PowerShell на 2008 R2

Первый вариант установки слегка устарел, но он вполне работоспособен. Запускаем cmd.exe, вводим:

Servermanagercmd -install RSAT-AD-PowerShell
Servermanagercmd -install RSAT-AD-AdminCenter

Второй вариант установки доступен через добавление фичи RSAT-AD-PowerShell и для полного комплекта еще и RSAT-AD-AdminCenter (для кучи), через выполнение следующих команд:

Import-Module ServerManager

Add-WindowsFeature RSAT-AD-PowerShell
Add-WindowsFeature RSAT-AD-AdminCenter

Примечание: Перечисленные ниже команды относятся только к рядовому серверу Windows Server 2008 R2членом, на контроллере RSAT-AD-PowerShell функция будет установлена во время выполнения DCPromo.

Установка Remote Server Administration Tools (RSAT) для Windows 7

Чтобы установить Модуль Active Directory для Windows PowerShell, Вы должны загрузить RSAT (Remote Server Administration Tools)  для Windows 7 здесь.

После завершения установки открываем «Control Panel» – «Programs and » – «Turn Windows features on or off» и выбираем Модуль «Active Directory for Windows PowerShell»:

add-win-features

По умолчанию с модулем «Active Directory for PowerShell» устанавливаются следующие компоненты.

  • Windows PowerShell
  • Платформа Microsoft .NET Framework 3.5.1

После запуска ADWS установленных хотя бы на один контроллер можно запускать установленный модуль »Active Directory for PowerShell» одним из способов:

Метод №1

Открываем «Control Panel» – «Administrative Tools» – «Active Directory Module for Windows Powershell»

Active Directory for PowerShell

Нажимаем правой кнопкой мыши и выбираем »Run as administrator».

Метод №2

Я предпочитаю второй вариант т.е. импорт AD PowerShell модуля прямо из сессии PowerShell. Для этого выполняем следующую команду:

Import-Module ActiveDirectory

Использование

Импорт модуля мы произвели ранее, но на всякий случай убеждаемся что он у нас есть:

get-module -ListAvailable

ModuleType Name                      ExportedCommands
---------- ----                      ----------------
Manifest   ActiveDirectory           {}
Manifest   AppLocker                 {}
Manifest   BitsTransfer              {}
Manifest   GroupPolicy               {}
...

Нужный модуль есть в списке, импортируем его:

Import-Module ActiveDirectory

Изучаем домен с помощью командлета Get-ADDomain. Полный вывод давать не буду, тут и ниже буду приводить только чать.

Get-ADDomain

ChildDomains                       : {}
ComputersContainer                 : OU=Computers,OU=Preparation,OU=test-lab,DC=lab,DC=local
DistinguishedName                  : DC=lab,DC=local
DNSRoot                            : LAB.LOCAL
DomainControllersContainer         : OU=Domain Controllers,DC=LAB,DC=LOCAL
DomainMode                         : Windows2003Domain
InfrastructureMaster               : DC01.LAB.LOCAL
Name                               : LAB
NetBIOSName                        : RETAIL
ParentDomain                       : {}
PDCEmulator                        : DC01.LAB.LOCAL
ReplicaDirectoryServers            : {dc02.LAB.LOCAL}
RIDMaster                          : DC01.LAB.LOCAL
UsersContainer                     : OU=Users,OU=Preparation,OU=test-lab,DC=lab,DC=local

Информативно, не правда ли?
Теперь мы знаем имя домена, имена контроллеров

(Get-ADDomain).ReplicaDirectoryServers

держателей FSMO ролей, режим и пр.

Теперь вводим:

Get-ADDomainController
Domain                     : LAB.LOCAL
Enabled                    : True
HostName                   : DC01.LAB.LOCAL
IPv4Address                : 192.168.0.1
IPv6Address                :
IsGlobalCatalog            : True
IsReadOnly                 : False
LdapPort                   : 389
Name                       : DC01
OperatingSystem            : Windows Server 2008 R2 Standard
OperatingSystemVersion     : 6.1 (7600)
OperationMasterRoles       : {PDCEmulator, RIDMaster}
Site                       : LABSite

Вывод «порезан», но из него видно что операционная система у нас Windows Server 2008 R2 Standard, что этот контроллер является Global Catalog-ом.

Для полной ясности выясним кто у нас является Администратором, вернее получим список группы Administrators.

$group = Get-AdGroup Administrators
Get-ADUser -Filter {MemberOf -recursivematch $group.DistinguishedName}

Дальше проще.
Смотрим когда пользователь Administrator в последний раз менял пароль.

Get-ADUser Administrator -properties PasswordLastSet
DistinguishedName : CN=Administrator,CN=Users,DC=LAB,DC=LOCAL
Enabled           : True
GivenName         :
Name              : Administrator
ObjectClass       : user
ObjectGUID        : ed5de06a-265c-43da-ab4e-65f3e09e4c32
PasswordLastSet   : 11.06.2011 12:54:33
SamAccountName    : Administrator

Выходит что давно :)
Изучаем то что имеется дальше и запрашиваем список имеющихся учетных записей компьютеров.

Get-ADComputer -LDAPFilter "(name=*)"
DistinguishedName : CN=SRV-01,OU=OU=Members Servers,DC=LAB,DC=LOCAL
DNSHostName       : SRV-01.LAB.LOCAL
Enabled           : True
Name              : SRV-01
ObjectClass       : computer
SamAccountName    : SRV-01$
UserPrincipalName :
...

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

Get-ADComputer -LDAPFilter "(name=SRV-01)" -properties *

CanonicalName                      : LAB.LOCAL/Members Servers/SRV-01
CN                                 : SRV-01
Created                            : 25.04.2011 11:53:17
Enabled                            : True
IPv4Address                        : 192.168.1.100
IPv6Address                        :
isCriticalSystemObject             : False
LastLogonDate                      : 07.12.2011 6:57:28
Location                           : Site-2
MemberOf                           : {CN=SCOM-MS-02_PrimarySG_2164,CN=LAB,CN=OperationsManager,DC=LAB,DC=LOCAL, CN=SCOM-MS-01_PrimarySG_2164,CN=LAB,CN=OperationsManager,DC=LAB,DC=LOCAL}
msDFSR-ComputerReferenceBL         : {CN=6c3d3b66-923e-4aaa-9cdc-1319aaa6e95c,CN=Topology,CN=DFS-TESTMEDIA,CN=DFSR-GlobalSettings,CN=System,DC=LAB,DC=LOCAL}
Name                               : SRV-01
OperatingSystem                    : Windows Server 2003
OperatingSystemHotfix              :
OperatingSystemServicePack         : Service Pack 2
OperatingSystemVersion             : 5.2 (3790)
PasswordLastSet                    : 03.12.2011 18:23:53
servicePrincipalName               : {Dfsr-12F9A27C-BF97-4787-9162-D31B6C55EB04/SRV-01.LAB.LOCAL, WSMAN/SRV-01, WSMAN/SRV-01.LAB.LOCAL, SMTPSVC/SRV-01.LAB.LOCAL...}

По прежнему интересно?

Судя по выводу мы имеем Windows 2003 Server, с установленным SP2, на котором имеются следы от DFSr и SMTP, обнаруживается так же присутствие установленного SCOM-а.

Посмотрим список SPN-ов подробнее.

(Get-ADComputer -LDAPFilter "(name=SRV-01)" -properties *).servicePrincipalName

Содержательно, но надо двигаться дальше. Для полноты картины посмотрим в DefaultDomainPasswordPolicy:

Get-ADDefaultDomainPasswordPolicy
ComplexityEnabled           : True
DistinguishedName           : DC=lab,DC=local
LockoutDuration             : 00:10:00
LockoutObservationWindow    : 00:10:00
LockoutThreshold            : 5
MaxPasswordAge              : 45.00:00:00
MinPasswordAge              : 0.00:00:00
MinPasswordLength           : 10
objectClass                 : {domainDNS}
objectGuid                  : 515a4469-fda9-4a18-95f9-404da09f3210
PasswordHistoryCount        : 5
ReversibleEncryptionEnabled : False

Изучим всех пользователей с не-истекающими паролями:

Get-ADUser -filter {PasswordNeverExpires -eq $True -AND Enabled -eq $True} | Select Distinguishedname
Distinguishedname
-----------------
CN=Administrator,CN=Users,DC=lab,DC=local
CN=user01,CN=TestOU,DC=lab,DC=local
CN=user02,CN=TestOU,DC=lab,DC=local
CN=user03,CN=TestOU,DC=lab,DC=local

Можно было бы выбрать любое количество свойств для отображения, но нам нужно только одно свойство PasswordLastSet. Немного изменяем команду:

Get-ADUser -filter {PasswordNeverExpires -eq $True -AND Enabled -eq $True} -properties PasswordLastSet | Sort PasswordLastSet | Select Distinguishedname,PasswordLastSet

Distinguishedname                                      PasswordLastSet
-----------------                                      ---------------
CN=Administrator,CN=Users,DC=lab,...                   1/24/2011 1:20:19 PM
CN=user01,CN=TestOU,DC=lab,DC=local                    1/24/2011 3:20:19 PM
CN=user02,CN=TestOU,DC=lab,DC=local                    1/24/2011 3:20:18 PM
CN=user03,CN=TestOU,DC=lab,DC=local                    1/24/2011 3:20:18 PM

Теперь считаем учетные записи срок действия паролей для которых истек

Get-ADUser -filter {Enabled -eq $True} -properties passwordExpired | where {$_.PasswordExpired} | measure-object
Count    : 5
Average  :
Sum      :
Maximum  :
Minimum  :
Property :

Много и интересно :) но мало пригодно для использования.

Для комплекта стоит создать отчет об активных аккаунтах у которых не истекает пароль в виде таблички.

Get-ADUser -filter {Enabled -eq $True -AND PasswordNeverExpires -eq $False} -properties * | Sort PasswordLastSet | Select Name,PasswordLastSet,PasswordExpired,@{Name="PasswordAge";Expression={(Get-Date)-$_.PasswordLastSet}}
Name             PasswordLastSet       PasswordExpired PasswordAge
----             ---------------       --------------- -----------
user04           1/24/2011 3:20:19 PM  False 5.05:23:24.7644101
…

Как использовать полученные данные решать вам. Уверен что данные выше «галопом по европе» рецепты будут использованы только в благих целях.

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

]]> http://blog.wadmin.ru/2011/12/powershell-active-directory-module/feed/ 11 Смена ip адресов. Головная боль? http://blog.wadmin.ru/2011/12/change-ip-addresses-a-headache/ http://blog.wadmin.ru/2011/12/change-ip-addresses-a-headache/#comments Mon, 05 Dec 2011 07:11:51 +0000 Сергей Мариничев http://blog.wadmin.ru/?p=5179 networkПредположим что у вас есть несколько задач имеющих под собою цель смены ip-адресов в некой абстрактной сети.

Что первое приходит в голову?

  • У нас есть новый DHCP (старый планируется на снос).
  • У нас есть новые DNS-серверы которые вы согласно плану уже развернули.
  • От Wins-ов мы старательно хотим избавиться, но они унаследованы и пока это не получается и мы обдумываем переход на GlobalNames.

Примечание: Естественно все это поднято в варианте Server Core на кластере Hyper-V, все это хозяйство уже бэкапится через DPM 2010 ну и т.д. и т.п…

Предположим что у вас есть список хостов, предположим что у вас даже есть схема сети и даже розетки пронумерованы и есть понимание что розетка номер 05-01-12 на кроссе уходит в кабинет такой то.

Если это так то вам несказанно повезло :)

Когда вы разобравшись в бумагах, понимаете что часть компьютеров имеют статические адреса, часть получают адреса динамически, что есть компьютеры в рабочей группе, а есть вообще непонятно что т.к. у них по хитрому умыслу разработчиков не прописано ни DNS-а ни шлюза. Одним словом зоопарк. Вы приходите в ужас от перспективы весело провести выходные и мысленно уже считаете сколько пива может понадобится что бы избавится от постэффектов :)

PowerShell в помощь. Да. Да. Именно его.

Для работы нам понадобится класс .NET - [System.Net.Dns]::GetHostAddresses() и немного терпения.

Разрешение имени в адрес происходит следующим образом.

[System.Net.DNS]::GetHostAddresses("yandex.ru")

Обратное преобразование выполняется так

[System.Net.DNS]::GetHostByAddress("77.88.21.3")

На практике это будет выглядеть примерно так.

$ServerName = "HOST_NAME"
[System.Net.Dns]::GetHostAddresses($ServerName)
# или обратное преобразование
$IP = "192.168.0.1"
[System.Net.Dns]::GetHostEntry($IP)

Но перебирать имена из имеющегося списка и адреса довольно скучно и очень хочется создать актуальный список адресов и использовать его для дальнейших исследований.

Список получен. Что дальше?

# берем данные из файла
$hosts = Get-Content servers.txt
# если файла нет то задаем список адресов
#hosts = "192.168.0.1","192.168.0.2","192.168.0.3"

# создадим пустой массив для результатов
$ResultList = @()

# в цикле разрешаем имена
foreach ($hostname in $hosts) {
$result = $null
$currentEAP = $ErrorActionPreference
$ErrorActionPreference = "silentlycontinue"

$result = [System.Net.Dns]::gethostentry($hostname)

$ErrorActionPreference = $currentEAP
If ($Result) {
$Resultlist += "$($Result.HostName) – $($Result.AddressList)"
} Else {
$Resultlist += "$IP – No HostNameFound"
}
}
# выводим результаты в файл
$resultlist | Out-File output.txt

Когда вы начинаете понимать что проще застрелиться чем понять что происходит вы натыкаетесь на мысть – «А не скачать ли мне nmap?»

Я же предлагаю не впадать в крайности и прибегнуть к помощи все того же PowerShell-а. Теперь проходим по диапазонам адресов.

$ErrorActionPreference = "SilentlyContinue"

# ЗАдаем диапазон для сканирования 1-254
1..254 | foreach -Process {
# создадим объект
$obj = New-Object PSObject;

$ping = get-WmiObject -Class Win32_PingStatus -Filter ("Address=’192.168.0." + $_ + "’");
$obj | Add-Member NoteProperty IPAddress($ping.Address);
$obj | Add-Member NoteProperty StatusCode($ping.StatusCode);

# если хост отвечает
if($ping.StatusCode -eq 0) {
$obj | Add-Member NoteProperty Status("Online");
$dns = [System.Net.Dns]::GetHostByAddress($ping.Address);

if($dns -ne $null) {
$obj | Add-Member NoteProperty ResolvedHostName($dns.HostName);
} else {
$obj | Add-Member NoteProperty ResolvedHostName("");
}
} else {
# если хост не отвесает то ставим ему статус offline
$obj | Add-Member NoteProperty ResolvedHostName("");
$obj | Add-Member NoteProperty Status("Offline");
}

# выводим результат на экран
Write-Output $obj
# или в файл
Add-content .\result.txt $obj;

# Чистим за собою
$dns = $null;
}

После найденных хостов которые используют статические адреса можно немного модифицировать код

$NICs = Get-WmiObject Win32_NetworkAdapterConfiguration | Where {$_.IPEnabled -eq "TRUE"}
foreach($NIC in $NICs) {
$NIC.EnableDHCP()
$NIC.SetDNSServerSearchOrder()
}

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

Не гадайте. Я отвечу просто – не хватает списка настроек найденных хостов.

# задаем имя файла
$hostlist = "servers.txt"
# читаем из него список
$servers = Get-Content $hostlist
# вводим учетные данные под которыми будем получать настройки
$credential = Get-Credential

foreach ($server in $servers) {
$colItems = Get-WmiObject Win32_NetworkAdapterConfiguration -Namespace "root\CIMV2" -ComputerName $server -credential $credential -ErrorAction SilentlyContinue | where{$_.IPEnabled -eq "True"}
foreach($objItem in $colItems) {
$str = "$($server); $($objItem.DHCPEnabled); $($objItem.IPAddress); $($objItem.IPSubnet); $($objItem.DefaultIPGateway)"
Write-Host $str
Add-content .\result.txt $str
}
}

В этом скрипте стоит обратить внимание на $objItem.DHCPEnabled.

  • True – указывает на то что хост получает настройки с DHCP.
  • False – настройки прописаны руками.
В моем случае требовалось заменить адреса WINS-ов и DNS-а. Дописан проверку на True-False я добавил следующий код.
# задаем список DNS серверов
$DNSServers = "198.100.1.1″,"198.101.1.1″
$NIC.SetDNSServerSearchOrder($DNSServers)
# указываем шлюз по умолчанию
$NIC.SetGateways("192.168.0.1″)
# включаем регистрацию
$NIC.SetDynamicDNSRegistration("TRUE")
# задаем новые WINS-ы
$NIC.SetWINSServer(“198.100.1.2″, "198.101.1.2″)

Если требуется удалить все статические настройки то код меняется на следущий

$NIC.EnableDHCP()
$NIC.SetDNSServerSearchOrder()

Можно конечно помучится и прописать новую статику как показано ниже, но подумайте о том чтоит ли это делать…

$NIC.EnableStatic("192.168.1.42", "255.255.255.0")

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

# список опций
# 0 – Log Off
# 4 – Forced Log Off
# 1 – Shutdown
# 5 – Forced Shutdown
# 2 – Reboot
# 6 – Forced Reboot
# 8 – Power Off
# 12 – Forced Power Off
#
# показываем только – 4, 5, 6 – force logoff of user, force shutdown, 6 force reboot
$computerName = read-host "Type the computername or ip address"
$command = read-host "Choose the following number:
4 – logoff user
5 – shutdown
6 – reboot"
(gwmi win32_OperatingSystem -ComputerName $computerName).Win32Shutdown($command)
]]> http://blog.wadmin.ru/2011/12/change-ip-addresses-a-headache/feed/ 0 Альтернатива SAPD.exe средствами PowerShell http://blog.wadmin.ru/2011/12/reading-lsa-service-account-secrets-using-powershell/ http://blog.wadmin.ru/2011/12/reading-lsa-service-account-secrets-using-powershell/#comments Sun, 04 Dec 2011 09:17:48 +0000 Сергей Мариничев http://blog.wadmin.ru/?p=5250 powershellУ моего кота есть дурная привычка приходить по утрам, примерно в 06.45, и начинать будить. Происходит это примерно так:

  • Попытка №1 – вопль прямо в ухо «Хозяяяяин, вставай…»
  • Если попытка оказалась не успешной то  попытка №2 более эффективна т.к. при ней берется правая лапа, которой сначала без когтей кот аккуратно касается уха. Если результата нет то когти выпускаются на ноль целых хрен десятых миллиметра. Дальше когти длиннее.

Достижение задачи  стопроцентное…

Вы спросите какое отношение мой кот имеет к PowerShell и SAPD.exe?

Отвечу что самое непосредственное т.к. он обожает наблюдать когда я работаю с ISE или консолью powershell. На другие окна реагирует однозначно т.е. ложиться на клавиатуру, мол нефиг ерундой заниматься :)

Хотя. я немного отвлекся от тематики. Вернемся во вчерашний день.

Вчера, после просмотра записи доклада Полы Янушкевич, я подводя итоги погуглил на тему утилиты SAPD.exe (получение паролей от учетных записей сервисов). Нужная страница нашлась сразу же, вот она - http://waldemar-dacko.blogspot.com/2011/10/sapd-and-service-account-password.html.

Примечание: В свое время, у меня была своя реализация этой задачи написанная на VBS  и я решил потестировать SAPD.exe.

Слил. Поставил. Работает.

Собственно ничего нового в SAPD.exe нет. Все настройки хранятся в реестре, если быть точнее то в ветке

HKEY_LOCAL_MACHINE\SECURITY\Policy\Secrets

Нужный сервис ищется в ветке

_SC_имя_сервиса

Которая содержит следующие значения:

  • CurrVal – текущее зашифрованное значение
  • CupdTime – время последнего обновления
  • OldVal – старое значение
  • OupdTime – время обновления старого значения
  • SecDesc – дескриптор

Для того что бы добраться до ветки

HKLM:\Security\Policy\Secrets

Нужно запустить powershell с помощью утилиты psexec

PsExec.exe -i -s powershell.exe

Дальше, что называется, счет идет на секунды :)

Искать и переписывать на PowerShell имеющийся VBS-скрипт не стал т.к. есть готовое решение на PowerShell, вот оно.

Результирующие скрипт без каких либо изменений доступен для загрузки тут.

Вывод?

Не стоит запускать сервисы из под аккаунтов с повышенными привилегиями т.к. пароль можно получить не то что бы очень просто, а удивительно быстро :)

 

]]> http://blog.wadmin.ru/2011/12/reading-lsa-service-account-secrets-using-powershell/feed/ 7 Быстрое создание hostlist.txt http://blog.wadmin.ru/2011/11/create-hostlist-file/ http://blog.wadmin.ru/2011/11/create-hostlist-file/#comments Mon, 07 Nov 2011 06:48:12 +0000 Сергей Мариничев http://blog.wadmin.ru/?p=4880 hostlist.txtЯ неоднократно писал про то что использую в работе файл servers.txt или hostlist.txt, но ни разу не показывал как именно я собираю данные.

Вариантов масса – можно экспортировать данные из оснастки ADUC, можно рисовать руками, но лучше скриптом.

Для работы скрипта должен быть установлен модуль Active Directory Module for PowerShell (из пакета RSAT). Естественно запускаться это все должно на Windows 7.

# импортируем модуль ActiveDirectory
Import-Module ActiveDirectory
# Указываем путь для поиска
$base = ‘OU=Servers,DC=domain,DC=local’
# на всякий случай берем только свежие записи
$d = [DateTime]::Today.AddDays(-30)
# выполняем поиск
$computers = Get-ADComputer -Filter ‘PasswordLastSet -ge $d’ -Searchbase $base
# выводим результаты в файл hostlist.txt
foreach($computer in $computers) {
$computer.Name | Out-file hostlist.txt -append
}

PS уверен что приведенный ниже скрипт можно упростить :)

Выкладывайте свои варианты в комментариях.

]]> http://blog.wadmin.ru/2011/11/create-hostlist-file/feed/ 8 Зачем нужно подписывать скрипты? http://blog.wadmin.ru/2011/09/do-i-need-signed-script/ http://blog.wadmin.ru/2011/09/do-i-need-signed-script/#comments Fri, 30 Sep 2011 10:38:05 +0000 Сергей Мариничев http://blog.wadmin.ru/?p=4683 Зачем нужно подписывать скрипт Первой и самой главной ошибкой тех кто начинает работать с PowerShell является запуск представленной ниже команды на всех хостах.

Set-ExecutionPolicy Unrestricted

Вроде как удобно, но поверьте последствия могут быть самые разнообразные…

Результатом выставления уровня запуска в режим Unrestricted будет ослабление надежной политики безопасности «по умолчанию» и как возможные последствия – потеря контроля и возможная компроментация учетных записей. Насколько хватит фантазии :)

Примечание: Напомню, что по умолчанию высталена безопасная политика Restricted (ничего и никому), об этом я недавно писал, надеюсь что вы это читали, а если не читали то обязательно зайдете.

Перед тем как поступить опрометчиво подумайте стоит ли оно этого…

  • Запускаете ли вы скрипты на рабочих станциях? Для каких целей?
  • Запускаете ли вы их в контексте пользователей имеющих административные привилегии?
  • Если запускаете то подписаны ли они?

Предлагаю рассмотреть следующий сценарий.

  1. На всех рабочих станциях Execution Policy выставлено в Unrestricted (встречаю довольно часто).
  2. В контексте пользователя запускается логон-скрипт ан powershell по подключению принтеров и общих папок, копированию некого набора файлов и пр.

Какие минусы?

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

Откройте консоль powershell и введите.

$profile

Вы получите путь до powershell-профиля пользователя. Редактируем этот файл командой.

notepad $profile

Открывается файл powershell-профиля для текущего пользователя. Вводим строку «Write-Host HELLO!«, сохраняем, закрываем. Закрываем консоль powershell, открываем новую. В окне видим надпись HELLO!

Что это может дать?

Первое что приходит в голову – возможность запускать нужные команды в контексте безопасности пользователя профиль которого надо подменить. Например скопировать файлы с жесткого диска пользователя на нужный ресурс (нет у вас доступа и полномочий а инфу стырить хочется…) или загрузить файл и выполнить его.

Примечание: В случае запуска логон-скрипта то что внесено в Powershell-профиль выполнится автоматически.

Подобное возможно в случае если «Мои документы» хранятся в папке права на которую выставлены некорректно или удалось подпихнуть заранее созданный файл профиля пользователю под которым планируется зловредная акция :)

Вариантов множество… Включите фантазию.

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

Как бороться.

Прежде всего нужно определиться где и для чего вы будете использовать PowerShell-скрипты.

Мое мнение – PowerShell создан для административных задач и запускать его нужно только на доверенных компьютерах. Все остальные задачи можно решать средствами GPO.

После понимания области применения необходимо настроить политики запуска только для подписанных скриптов т.к. при попытке подмены файла, скрипт заданный в профиле не будет выполняться.

Итог

Вы подписываете скрипты?
Настроены  ли ваши политики на использование только подписанных скриптов?

Что вы думаете по поводу вышесказанного?

]]> http://blog.wadmin.ru/2011/09/do-i-need-signed-script/feed/ 8