В прошлой статье я постарался в понятной форме рассказать о технологии DirectAccess, о ее плюсах и минусах. Теперь, как и обещал, расскажу о том, каким образом настроить сервер DirectAccess в базовой конфигурации для работы только с клиентами Windows 8. Что значит в базовой конфигурации? Это когда у вас есть Windows Server 2012 на котором будет поднята роль для DirectAccess и клиенты (с операционной системой Windows 8 Enterprise) имеющие прямое подключение к интернету . В базовой конфигурации не будет использоваться инфраструктура открытых ключей (PKI) и используется только одна входная точка (сервер DirectAccess), подключенная в одном сайте Active Directory. Так же в базовую конфигурацию не могут входить дополнительные опции, такие как двухфакторная аутентификация (OTP Auth), проверка доступа к сети (NAP). Ну и самое важное – в ней не могут использоваться клиенты Windows 7.
Время не стоит на месте, и мы, что бы не отставать от современного ритма, должны быть активными и мобильными. Для организаций любого уровня становится все более важным иметь простой и безопасный способ подключения удаленных и мобильных клиентов к внутренней сети предприятия. Одной из распространенных технологий удаленного доступа является VPN, хотя можно было обойтись и без него, используя прямые подключения средствами RDP, Radmin, Ammyy и тому подобных вещей. Теперь в списке появляется значимая альтернатива – Microsoft DirectAccess 2012. Число 2012 говорит нам о том, что это сервис включенный в новую редакция сервера Windows Server 2012. Это важно, потому что DirectAccess уже был реализован в 2008 R2, но с кучей нюансов и серьезных требований к инфраструктуре предприятия, где внедряли DirectAccess 2008 R2. Именно поэтому я специально сказал, что только теперь появилась альтернатива для удаленного подключения клиентов, и сейчас объясню почему.
До последнего момента не доходили руки пощупать Windows Server 2012, но все же нужда заставила и пришлось развернуть тестовый стенд. Ощущения не однозначные, но скажу честно, появилось множество возможностей, значительно упрощающих жизнь. В рамках небольшой заметки хотелось бы познакомить читателей с основными изменениями операционной системы, которые бросились в глаза. Можно не пугаться, революции не произошло, домены на месте, все изменения больше качественные, хотя есть и совсем новые технологии, но обо всем по порядку.
Всем администраторам Active Directory периодически приходится сталкиваться с рутинными задачами, которые хотелось бы так или иначе автоматизировать. Как правило, это делается с использованием скриптов на наиболее известных языках программирования: VBScript, Jscript, PowerShell. Последний я считаю наиболее удобным. Благодаря некоторым из его особенностей те же процедуры, которые занимают в VBScript десяток строк и требуют понимания работы WMI, LDAP и еще многих китайских слов – в PowerShell занимает всего пять строк и требуют всего лишь знания программирования на уровне школьных уроков информатики. В настоящей статье мы рассмотрим типовые задачи администрирования Active Directory, и их автоматизацию с помощью PowerShell.
P.S. Статья рассчитана на полных, или почти полных «чайников», пару раз видевших или где-то слышавших о PowerShell. На звание Терминатора не претендую, по сему просьба ногами не пинать.
Предполагается, что читатели уже хотя бы немного знакомы с оболочкой PowerShell и написанием скриптов. Тех, кто не знаком – хотелось бы отослать к списку ресурсов в конце статьи.
В первую очередь, необходимо заметить, что для того, чтобы все нормально работало – необходимо иметь хотя бы один контроллер домена Windows Server 2008 R2 с установленной компонентой ActiveDirectory Web Services. Увы и ах, Windows Server 2003 уходит на свалку истории. Для работы с модулем ad_powershell необходимо установить Remote Server Administration Tools, его так же можно установить на рабочем компьютере и запускать скрипты оттуда. Разумеется, ОС на компьютере должна быть не ниже Windows 7. На контроллерах домена Windows Server 2008 R2 необходимые компоненты уже установлены.
Перед тем, как выполнять скрипты – необходимо установить политику выполнения скриптов. По умолчанию, в целях безопасности включена политика Restricted, что означает, что на данном компьютере вообще запрещен запуск любых PowerShell-скриптов. О том, какие еще бывают политики выполнения – можно почитать в мануале:
Get-Help Set-ExecutionPolicy –Detailed
В нашем случае я рекомендую установить политику RemoteSigned, что позволит запускать любые собственноручно написанные скрипты, при этом запуск скриптов, скачанных из Интернета будет возможен только при наличии цифровой подписи с доверенным сертификатом. Запустите оболочку PowerShell с правами администратора (Run as Administrator) и выполните команду
Set-ExecutionPolicy RemoteSigned
Можно так же выбрать политику Unrestricted, что вообще позволит запускать любой скрипт, независимо от того, откуда он взялся – но я делать этого не рекомендую из соображений безопасности.
Теперь можно проверить работу скриптов – написать простейший скрипт «Hello World!». Я предпочитаю пользоваться PowerShell ISE, хотя можно писать и в простейшем Notepad’е. PowerShell ISE – удобная среда програмирования для PowerShell с возможностью отладки. Входит в состав ОС Wondows 7 и 2008 R2. Вобщем, рекомендую.
Теперь переходим непосредственно к автоматизации. Для того, чтобы создать объекты в Active Directory, или изменить какие-либо свойства, нам необходим список объектов со всеми необходимыми параметрами. Например, список пользователей может содержать следующие парамеры: Имя, Фамилия, Логин, Пароль. Проще всего для этого использовать CSV-файл. CSV – это текстовый файл, содержащий список объектов (например – пользователей), с разделением параметров каким-либо символом (как правило, это запятая «,», хотя может быть и точка с запятой, знак табуляции и т.д.). Каждый объект обозначается одной строчкой. Так же, первая строчка может содержать список параметров.
Пример:
Name;Surname;Login;Password
Ivan,Ivanov;i.ivanov;p@ssw0rd1
Petr,Petrov;p.petrov;p@ssw0rd2
Sidor;Sidorov;s.sidorov;p@ssw0rd3
Чтобы получить список объектов из CSV-файла, используется командлет Import-CSV:
$Users = Import-CSV “c:\temp\users.csv”
Такой файл можно создать и в блокноте, но проще всего будет использовать Microsoft Excel. В Excel необходимо при сохранении файла выбрать формат CSV. Интересно, что Excel при сохранении в формат CSV в качестве разделителя использует знак “;”, хотя вроде бы написано «CSV (разделители – запятые)». PowerShell же по умолчанию считает, что в качестве разделителя используется запятая («,»). Чтобы наш скрипт работал корректно – необходимо либо заменить в CSV-файле все точки с запятой на запятые (используя автозамену в блокноте) либо же, что на мой взгляд правильнее – указать в скрипте использовать точку с запятой в качестве разделителя:
$Users = Import-CSV “c:\temp\users.csv” –Delimiter “;”
Чтобы проверить, как прошел импорт – можно посмотреть, что хранится в переменной $Users.
Как видим, в переменной $Users теперь хранится массив объектов с параметрами Name, Surname, Login, Password. Эти параметры можно использовать для создания учетных записей пользователей в AD.
Прежде чем приступить к работе с Active Directory, необходимо произвести импорт соответствующего модуля в PowerShell. Только после этого появятся команды для работы с AD:
Import-Module ActiveDirectory
Эту строку можно (и даже нужно) вставлять в начало всех скриптов – чтобы не вводить эту команду вручную.
Каждому, кто работал с ActiveDirectory, приходилось создавать учетные записи пользователей. И хотя это делается легко и просто – в несколько щелчков мышкой – иногда, особенно в крупных организациях, приходится создавать много учетных записей в течение дня. Иногда – в районе сотни.
Для нашего примера, в качестве списка пользователей будем брать CSV-файл со следующими полями:
Вначале нам нужно импортировать пользователей из списка:
$Users = Import-CSV $1 –Delimiter “;”
Параметр $1 означает, что в качестве пути к CSV-файлу будет использоваться первый по счету параметр командной строки. Запускаться скрипт будет следующим образом:
PS C:\Users\admin > Add_Users.ps1 c:\temp\users.csv
Далее нам нужно пройтись по всему массиву пользователей из списка:
Foreach($CurrentUser in $Users) {
Знак открытой фигурной скобки означает начало цикла. Этот цикл проходит по всем объектам списка, и прискаивает текущий объект переменной $CurrentUser.
Затем, для упрощения – присвоим значения соответствующих полей отдельным переменным:
$Name = $CurrentUser.Name
$Surname = $CurrentUser.Surname
$Password = $CurrentUser.Password
$OU = $CurrentUser.OU
Для того, чтобы задать пароль пользователю – необходимо перевести его в шифрованный формат SecureString:
$SecurePwd = ConvertTo-SecureString -AsPlainText -Force -String $Password
Так же, OU нам нужно перевести в формат, соответствующий стандарту LDAP (для примера выше: “OU=Accounting,OU= Fin,OU= Contoso_Users,DC=contoso,DC=com”).
Для этого вначале разделим строку $OU на отдельные составляющие:
$OUTmp = $OU –Split “/”
В результате переменная $OUTmp будет содержать массив из всех элементов пути:
PS C:\Users\admin> $OUTmp
Contoso_Users
Fin
Accounting
Далее, используя командлет Foreach-Object, получим из нашего массива первую часть LDAP-пути:
$Path = “” #незабудьте проинициализировать переменную!
$OUTmp | ForEach-Object {$Path = "OU=$_," + $Path}
В переменной $Path появляется первая часть LDAP-пути:
PS C:\Users\admin> $Path
OU=Accounting,OU=Fin,OU=Contoso_Users,
Теперь нам нужно получить полный путь, добавив к пути домен:
$Path += “DC=contoso,DC=com”
Получили полный LDAP-путь:
PS C:\Users\admin> $Path
OU=Accounting,OU=Fin,OU=Contoso_Users,DC=contoso,DC=com
Теперь сформируем дисплейное имя пользователя, его логин, User Principal Name.
$Login = $Name[0] + “.” + $Surname #логин формируется из первой буквы имени и фамилии, например: i.ivanov
$Displayname = $Name + “ “ + $Surname #Дисплейное имя: Ivan Ivanov
$UserPrincipalName = $Login + “@contoso.com”
Наконец, можно перейти к самой главной процедуре: созданию учетной записи пользователя.
New-ADUser $Displayname –SamAccountName $Login –UserPrincipalName $UserPrincipalName -DisplayName $DisplayName -AccountPassword $SecurePwd -ChangePasswordAtLogon 1 -Path $Path
Здесь, в принципе, все параметры понятны. Параметр -ChangePasswordAtLogon 1 означает, что пользователю будет предложено сменить пароль сразу после логина.
По умолчанию в PowerShell, в отличие от стандартного визарда в оснастке ActiveDirectory Users And Computers учетные записи только что созданных пользователей будут отключены (Disabled). Поэтому сразу после создания учетные записи нужно включить:
Enable-ADAccount $Login
Теперь нужно закрыть цикл знаком «}». Можно сохранять скрипт и пробовать.
Готовый скрипт будет выглядеть следующим образом:
Import-Module ActiveDirectory
$Users = Import-CSV $1 –Delimiter “;”
Foreach($CurrentUser in $Users) {
$Name = $CurrentUser.Name
$Surname = $CurrentUser.Surname
$Password = $CurrentUser.Password
$OU = $CurrentUser.OU
$SecurePwd = ConvertTo-SecureString -AsPlainText -Force -String $Password
$OUTmp = $OU –Split “/”
$Path = “” #незабудьте проинициализировать переменную!
$OUTmp | ForEach-Object {$Path = "OU=$_," + $Path}
$Path += “DC=contoso,DC=com”
$Login = $Name[0] + “.” + $Surname
$Displayname = $Name + “ “ + $Surname #в кавычках – пробел!
$UserPrincipalName = $Login + “@contoso.com”
New-ADUser $Displayname –SamAccountName $Login –UserPrincipalName $UserPrincipalName -DisplayName $DisplayName -AccountPassword $SecurePwd -ChangePasswordAtLogon 1 -Path $Path
Enable-ADAccount $Login
}
Как известно, для работы с Active Directory перво-наперво необходимо вводить компьютеры в домен. Сделать это можно двумя способами:
· Мышкой – самый известный способ, через «Свойства» «Моего компьютера». Легко и просто.
· Командой netdom join. Тоже несложно, и можно использовать в скриптах.
У первого способа есть существенный недостаток: учетные записи компьютеров создаются в дефолтном OU Computers. В организациях же, как правило имеются разные OU для разных типов компьютеров (сервер, десктоп, ноутбук), а так же отдельные OU для разных отделов/департаментов/и т.д., с различными групповыми политиками, действующими для разных OU. Поэтому после ввода компьютеров в домен необходимо переносить учетные записи компьютеров вручную в соответствующий OU, а затем перезагружать компьютер еще раз, чтобы на нем применились все необходимые политики. При использовании команды netdom можно указать нужное OU, но набирать все это с клавиатуры – та еще задачка, особенно – когда компьютеров много, и особенно, что часто бывают – задачку эту поручают простым эникейщикам. Где-то в какой-то букве обязательно ошибется.
Самый лучший выход из этой ситуации – создать учетные записи компьютеров заранее, в соответствующих OU. Тогда компьютер сразу после ввода в домен и перезагрузки применит все соответствующие политики.
Разумеется, учетные записи компьютеров, как и пользователей, можно создавать и вручную. Но, поскольку мы – админы, а не эникейщики – будем использовать PowerShell.
Для учетных записей, как и для компьютеров, используем CSV-файл
ComputerName;OU
Server1;Cnotoso_Computers/Servers
Server2;Cnotoso_Computers/Servers
Desktop1;Cnotoso_Computers/Desktops
Desktop2;Cnotoso_Computers/Desktops
Desktop3;Cnotoso_Computers/Desktops
Laptop1;Cnotoso_Computers/Laptops
Далее, пишем скрипт по анологии со скриптом для учетных записей пользователей, только он будет немного проще:
Import-Module ActiveDirectory
$Computers = Import-CSV $1 –Delimiter “;”
Foreach($CurrentComputer in $Computers) {
$ComputerName = $CurrentComputer.ComputerName
$OU = $CurrentComputer.OU
$OUTmp = $OU –Split “/”
$Path = “” #незабудьте проинициализировать переменную!
$OUTmp | ForEach-Object {$Path = "OU=$_," + $Path}
$Path += “DC=contoso,DC=com”
New-ADComputer –Name $ComputerName –Path $Path
}
Иногда бывает необходимо массово сбросить пароли у множества пользователей.
Структура CSV-файла:
Import-Module ActiveDirectory
$Users = Import-CSV $1 –Delimiter “;”
Foreach($CurrentUser in $Users) {
$Login = $CurrentUser.Login
$NewPassword = $CurrentUser.NewPassword
$SecurePwd = ConvertTo-SecureString -AsPlainText -Force -String $Password
Set-ADAccountPassword –Identity $Login –Reset –NewPassword $SecurePwd
}
Допустим, в вашей организации были приняты новые корпоративные стандарты, которые требуют, чтобы у каждого пользователя в AD были указаны, помимо всего остального: адрес электронной почты, номер мобильного телефона, название организации, должность. Из отдела кадров вам прислали табличку со следующими полями:
Из нее мы создаем CSV-файл с полями:
Скрипт будет следующего вида:
Import-Module ActiveDirectory
$Users = Import-CSV $1 –Delimiter “;”
Foreach($CurrentUser in $Users) {
$Name = $CurrentUser.Name
$Surname = $CurrentUser.Surname
$Email = $CurrentUser.E-Mail
$Phone = $CurrentUser.Phone
$Organization = $CurrentUser.Organization
$JobTitle = $CurrentUser.JobTitle
$Login = (Get-ADuser –Filter {GivenName –eq $Name –and Surname –eq $Surname}).SamAccountName #ищем юзера с заданным именем и фамилией и возвращаем его логин
Set-ADUser $Login –EmailAddress $Email –MobilePhone $Phone –Company $Organization –Title $JobTitle
}
В этой статье я попытался рассмотреть простейшие скрипты для автоматизации наиболее часто встречающихся задач администрирования Active Directory. На самом деле, я намеренно не стал чересчур усложнять скрипты, чтобы можно было понять логику работы.
Попробуйте сами вооружиться гуглом и ресурсами, указанными в конце статьи и улучшить скрипты самостоятельно.
Например:
Эти ресурсы очень сильно помогут в изучении PowerShell. Во всяком случае мне они помогли.
Надеюсь, эта статья была вам полезна, и кто-то, кто раньше боялся консоли – перестанет ее бояться. 
Александр Косивченко
Выбор имени домена задача несложная, но как показывает жизнь достаточно часто после запуска dcpromo имя домена генерируется случайным образом. Вроде и ничего страшного, домен работает, принтеры печатают, 1С открывается. Но увы есть ряд ситуаций, когда генерация случайным образом имени, если не выйдет вам боком, то хлопот однозначно добавит. В этой небольшой заметке я попытаюсь рассказать о том, как не стоит именовать ваши домены и почему. Информация хоть и известная, но реальная жизнь показывает, что ошибки в именовании просто повальные. А поскольку процедура переименования домена это ит-шное садо-мазо, лучше все делать изначально правильно.
10 мая сего года в 17:00 по московскому времени пройдет вебинар TechNet, в рамках которого я расскажу о новой технологии, которая появляется в Windows Server 2012: Hyper-V Replica. Эта технология позволяет осуществлять репликацию виртуальных машин между географически разнесенными площадками, что позволяет повысить отказоустойчивость. При этом не требуется покупки какого-либо дополнительного оборудования или программного обеспечения, в отличие от существующих решений вроде Veeam Backup & Replication или репликации на уровне СХД.
Совсем недавно, на конференции Build было проанонсировано новое поколение ОС от Microsoft: Windows 8 и серверная ОС Windows Server 8. Среди прочих нововведений в Windows Server 8 присутствует новая версия гипервизора Hyper-V 3.0. И – это уже стало доброй традицией – в каждой новой версии гипервизора появляются все новые и новые фичи. Не побоюсь этого слова, я был удивлен, узнав, сколько же всего нового появилось в Hyper-V 3.0: это и одновременная миграция нескольких виртуальных машин, и Storage Live Migration, и репликация, и ресурсные пулы и многое другое. Надо сказать, что это еще даже не бета-версия, а только Developer Preview, поэтому какие фичи будут реализованы, какие – нет, и как именно это будет работать – пока невозможно сказать. Тем не менее, мы посмотрим, что нам показывают сейчас. Заранее извиняюсь за сумбур и отсутствие картинок – делать полноценный обзор пока не вижу смысла. Во всяком случае до выхода публичной бета-версии.
Нововведений, как уже было отмечено – просто масса. Среди них:
Самое заметное из нововведений здесь – это появление виртуального Fibre Channel HBA. Теперь LUN’ы можно презентовать от СХД виртуальным машинам напрямую без использования passtrough-дисков. Виртуальные FC HBA, в свою очередь, можно объединять в виртуальные SAN-сети и привязывать к определенным физическим HBA. Это, в частности, позволяет без особых ухищрений реализовывать отказоустойчивую кластеризацию на уровне гостевых ОС.
Помимо этого, появился новый формат файлов виртуальных дисков – VHDX. Их объем может достигать 16 Тб (против 2 Тб у стандартных VHD), так же заявляется устойчивость к сбоям питания.
Еще стоит упомянуть поддержку Offloaded Data Transfer (ODX). Тоже достойная внимания фича: если раньше при копировании блоков данных внутри одного LUN’а или между LUN’ами одной СХД приходилось сначала считывать блок, передавать его по SAN, а затем передавать его обратно для записи – то теперь в этом отпадает необходимость: копирование блоков осуществляется внутри СХД, не нагружая и без того загруженную SAN-сеть и HBA.
Ну и самое интересное: теперь файлы виртуальных дисков могут находиться на SMB-шарах. Это может пригодиться тем, кому не по карману «полноценная SAN». Хотя я, если честно, не знаю, для чего это может пригодиться, когда в комплект Windows Server 8 входит бесплатный Microsoft iSCSI Software Target. Тем не менее, это работает – я проверял.
Множество нововведений касается сетевой подсистемы. Самая главная новость: компания Cisco Systems заявляет о разработке виртуального коммутатора Nexus 1000V для Hyper-V 3.0. До сих пор эта уникальная фича была эксклюзивом для VMware. Теперь же она появится и у Microsoft, и это означает официальное признание того факта, что Microsoft Hyper-V все-таки «созрел» для Enterprise, что бы там ни говорили конкуренты.
Сами виртуальные коммутаторы в Hyper-V 3.0 стали более функциональными. Теперь они поддерживают так называемые расширения (Extensions). Расширения – это специальные модули, разрабатываемые как Microsoft, так и сторонними разработчиками, позволяющие перехватывать или фильтровать трафик, проходящий через виртуальный коммутатор. К примеру, можно использовать стандартный Microsoft Network Monitor для анализа трафика на уровне виртуального коммутатора. А расширение Windows Filtering Platform позволяет фильтровать трафик с помощью правил Windows Firewall. Вскоре после релиза Windows Server 8 появится виртуальный коммутатор Cisco Nexus 1000V, о котором уже говорилось, и скорее всего следующая версия Forefront Threat Management Gateway тоже будет работать с расширениями для виртуальных коммутаторов.
Так же, ряд нововведений коснулся отказоустойчивости и надежности. В частности, заявляется, что failover-кластер теперь может содержать до 63 узлов и до 4000 виртуальных машин. Проверить это мне, увы, не удалось по очевидным причинам.
Что же касается Live Migration – тут есть целых три новости.
И есть еще одна новая фича – Hyper-V Replica. Эта фича позволяет периодически реплицировать файлы виртуальной машины на другой сервер Hyper-V, и в случае необходимости – например, при аппаратном сбое или сбое питания – запустить реплику как полноценную виртуальную машину. Так же реплики позволяют делать откат состояния виртуальной машины – по аналогии со снапшотами, что тоже может оказаться полезным. Репликация осуществляется инкрементно (реплицируются только те блоки данных, которые изменились с момента последней репликации) с интервалом раз в час. Разумеется, этот интервал можно изменить. При создании реплик используется технология Volume Shadow Copy (VSS), поэтому копия получается консистентной. Это особенно важно, если внутри виртуальной машины используются, в частности, базы данных.
Вот, собственно, такой кратенький обзор у меня получился. Прошу прощения за уровень 100 и за отсутствие скриншотов и вообще за стиль статьи «галопом по европам», но пока не вышла хотя бы публичная бета – я наверное воздержусь от глубокого копания. Все еще может измениться и не один раз. Какие-то из описанных фич возможно и выкинут, какие-то останутся, но будут работать по-другому, а возможно добавят что-то новое. Тем не менее, можно составить примерное представление – чего можно ожидать от Hyper-V 3.0. Меня не могут не радовать темпы роста функционала Hyper-V, и если раньше он заметно проигрывал конкурентам – то теперь имеются все шансы значительно сократить это отставание, и это признают уже даже такие гиганты, как Cisco Systems. От себя могу только пожелать удачи Microsoft, и пусть через год они нас не разочаруют!
Сделаю попытку систематизировать свои заметки и закладки по ресурсам о PowerShell. Представленный ниже список ресурсов не сможет охватить все аспекты языка, это всего лишь вырезки из моих закладок. Не могу не добавить небольшой перечень книг про Powershell, они все сопровождаются ссылками на место где их можно приобрести или скачать.
Большинство начинающих системных администраторов считают, что аудит – это слово, имеющее отношение к бухгалтерии, финансам, но уж никак не к информационным технологиям. Их мнение в корне меняется, когда они начинают работать в средних и крупных организациях, где количество администраторов может измеряться десятками. В таких случаях аудит становится страховкой для системного администратора, позволяющей при возникновении форс-мажоров спасти как собственную зарплату, так и в ряде ситуаций – карьеру.
