Архивы Active Directory

Продолжая тему анализа доменных учетных записей пользователей и компьютеров, которые давно не проходили авторизацию в домене предлагаю ещё один вариант скрипта из заметки PowerShell – Поиск неиспользуемых учетных записей пользователей и компьютеров в домене. В текущем варианте используется библиотека AD для PowerShell 2.0 В указанном примере в конкретном OU выбираются все действующие учетные записи пользователей и компьютеров и выполняется сравнение даты последней авторизации (LastLogonDate) с максимально возможным значением (текущая дата минус 90 дней) Import-Module ActiveDirectory $SearchOU = "OU=Domain Users and Computers,DC=mydom,DC=com" $DaysLimit = 90 $OldestDate = (Get-Date).AddDays(-$DaysLimit) # $Users = Get-ADUser -Filter {(Enabled -eq $True)} ` -SearchBase $SearchOU -Properties SamAccountName,LastLogonDate,CN $UsersOld = $Users | Where-Object {$_.LastLogonDate -le $OldestDate} $UsersOld | Select ` @{label="SamAccountName";expression={$_.SamAccountName}},` @{label="Last Logon";expression={$_.LastLogonDate}},` @{label="User Full Name";expression={$_.CN}}` | Sort -Property "Last Logon" | Format-Table –AutoSize Write-Host "~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~" write-host "Total users in OU: " $Users.Count " / Unused users: " $UsersOld.Count Write-Host "~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~" # $Comps = Get-ADComputer -Filter {(Enabled -eq $True)} ` -SearchBase $SearchOU -Properties Name,LastLogonDate,Description $CompsOld = $Comps | Where-Object {$_.LastLogonDate -le $OldestDate} $CompsOld | Select ` @{label="PC Name";expression={$_.Name}},` @{label="Last Logon";expression={$_.LastLogonDate}},` @{label="Description";expression={$_.Description}}` | Sort -Property "Last Logon" | Format-Table –AutoSize Write-Host "~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~" write-host "Total computers in OU: " $Comps.Count " / Unused computers: " $CompsOld.Count Write-Host "~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~"

Приведу маленькую шпаргалку по использованию корзины AD (Active Directory Recycle Bin) в домене Windows Server 2008 R2. Для возможности активации корзины AD функциональный уровень леса должен быть не ниже — Windows Server 2008 R2. Чтобы проверить текущий уровень леса выполним: Import-Module ActiveDirectory Get-ADForest | Format-List Name,ForestMode,DomainNamingMaster Параметр DomainNamingMaster вернёт нам имя сервера, который выполняет роль мастера именования (Domain Naming Master FSMO role). Имя этого сервера потребуется нам в дальнейшем при включении функционала корзины AD. Если уровень значения ForestMode ниже Windows2008R2Forest и вы готовы выполнить его повышение, выполним: Get-ADForest | Set-ADForestMode –ForestMode Windows2008R2Forest Для того чтобы активировать функционал корзины AD в лесу с именем “holding.com” в котором мастером именования является контроллер домена “DC01” выполним: Enable-ADOptionalFeature "Recycle Bin Feature" -Scope ForestOrConfigurationSet -Target "holding.com" –Server "DC01" По умолчанию удалённые объекты помещаются в скрытый контейнер CN=Deleted Objects, DC=<mydomain>,DC=<com> Предположим, что мы по ошибке удалили из домена пользователя “Петя Редискин”. Для того чтобы выполнить поиск учетной записи среди всех удалённых объектов попавших в корзину AD выполним: Get-ADObject -SearchBase "CN=Deleted Objects,DC=holding,DC=com" -filter {(Objectclass -eq "user") -AND (displayName -like "*Редискин")} –IncludeDeletedObjects Результат вывода будет примерно следующий: Deleted : True DistinguishedName : CN=Петя РедискинADEL:9101b6d7-be83-480c-939d-c91b851ebbc6,CN=Deleted Objects,DC=holding,DC=com Name : Петя Редискин DEL:9101b6d7-be83-480c-939d-c91b851ebbc6 ObjectClass : user ObjectGUID : 9101b6d7-be83-480c-939d-c91b851ebbc6 Теперь, зная ObjectGUID интересующей нас учетной записи мы можем выполнить её восстановление: Restore-ADObject –identity 9101b6d7-be83-480c-939d-c91b851ebbc6 Если вы предпримите попытку восстановления учетной записи в контейнер/OU который был так же удалён, то получите ошибку: Restore-ADObject : Отсутствует аргумент для параметра "TargetPath". Укажите параметр типа "System.String" и повторите попытку. У нас есть два выхода из этой ситуации – предварительно восстановить удалённый контейнер/OU а затем уже восстанавливать учетную запись пользователя или же при восстановлении учетной записи указать имя существующего контейнера/OU в который будет восстановлена учетная запись с помощью параметра "TargetPath: Restore-ADObject -TargetPath "OU=Restored Users,DC=holding,DC=com" –identity 9101b6d7-be83-480c-939d-c91b851ebbc6 Источники информации: TechNet Library — Active Directory

Операцию резервного копирования доменных объектов групповых политик (GPO) можно выполнить штатным способом с помощью консоли Group Policy Management (gpmc.msc), но если нам потребуется автоматизировать данный процесс, — можно использовать командлеты модуля GroupPolicy для PowerShell 2.0 Приведу пример скрипта, который выполняет резервное копирование GPO в том случае если с момента последнего резервного копирования изменилось время модификации GPO (определение по наличию каталога с именем по отметке времени модификации) # Блок переменных для резервного копирования GPO # $BackupPath — Корневой каталог для сохранения GPO # $GPONameMask — Маска имени GPO. "*" — для полного бэкапа # $NearestDC — Контроллер домена на котором будут выполняться команды, # если в качестве имени DC нужно указать имя текущего хоста , можно использовать значение # [System.Net.Dns]::GetHostEntry([System.Net.Dns]::GetHostName()).HostName # $BackupPath = "\FSGPO-Backup$" $GPONameMask = "KOM-*" $NearestDC = "KOM-DC03.holding.com" # # Блок переменных для уведомлений по электронной почте в случае ошибок # $gvEmailFrom – Email адрес отправителя # $gvEmailTo – Email адрес получателя (например адрес группы рассылки для Администраторов TMG) # $gvSMTPServer – FQDN имя почтового сервера # $gvEmailFrom = "GPO-Backup@holding.com" $gvEmailTo = "DST-GPO-Administrators@holding.com" $gvSMTPServer = "Mail.holding.com" # # Блок отсылки уведомляющего письма об ошибках выполнения скрипта # Trap { If ($Error){ $vEmailSubj = "GPO Backup Error" $vEmailBody = "Group Policy Backup Error on DC " + $NearestDC + ` "`n`nError : " + $Error $vSMTP = New-Object Net.Mail.SMTPClient($gvSMTPServer) $vSMTP.Send($gvEmailFrom, $gvEmailTo, $vEmailSubj, $vEmailBody) } Break } # # Функция для создания структуры каталогов # Function Check-Folder ($Folder) { $CatExists = Test-Path -Path $Folder If ($CatExists -eq $False) {New-Item $Folder -type directory} } # # Блок процедуры резервного копирования GPO # Check-Folder $BackupPath | Out-Null Import-Module GroupPolicy $GPOs = Get-GPO -All -Server $NearestDC | Where-Object {$_.DisplayName -like $GPONameMask} Foreach ($GPO in $GPOs) { $GPOFolder = $BackupPath + "" + $GPO.Id Check-Folder $GPOFolder | Out-Null $FullPath =

Получаем список трастов AD с помощью PowerShell для текущего домена: $myLocalDomain = [System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain() $myLocalDomain.GetAllTrustRelationships() | ft -AutoSize Тоже самое только если нужно явно указать конкретный домен (указываем в переменной $SpecDomain): $SpecDomain = "my.holding.com" $myRootDirContext = New-Object System.DirectoryServices.ActiveDirectory.DirectoryContext(‘domain’,$SpecDomain) $myRootDomain = [System.DirectoryServices.ActiveDirectory.Domain]::GetDomain([System.DirectoryServices.ActiveDirectory.DirectoryContext]$myRootDirContext) $myRootDomain.GetAllTrustRelationships() | ft –AutoSize Источник информации: organic fertilizer — using powershell to list active directory trusts

В случае, если у вас периодически возникает необходимость выполнять какие-то административные действия с помощью интерфейса HP Integrated Lights-Out 2 (iLO2) на серверах HP ProLiant и при этом вы имеете расширенную лицензию iLO 2 Advanced, возможно вам окажется полезным и удобным использование интеграции процесса авторизации в iLO2 с существующей доменной инфраструктурой Active Directory (AD). Рассмотрим пример такой интеграции. Предварительно в домене создаём группу безопасности, в которую включаем учетные записи администраторов, которым необходимо предоставить доступ к интерфейсу iLO2 на серверах. Залогинившись на веб-интерфейс iLO2 со встроенной учетной записью, для начала мы должны убедиться в том, что у нас активирована расширенная лицензия iLO 2 Advanced (Administration > Licensing). Здесь же на закладке Администрирования переходим в раздел управления группами доступа (Administration > User Administration > Group Accounts) выбираем любую неиспользуемую ранее группу, например Administrator, и нажимаем View/Modify В формате distinguishedName (DN) вводим имя доменной группы доступа и включаем соответствующие разрешающие опции. При вводе имени стоит знать о том, что текущая версия прошивки iLO2 (на момент написания заметки — 2.09) не поддерживает национальные символы, и поэтому если вы попытаетесь использовать DN в котором встречается, например, кириллица, получите соответствующее предупреждение. Честно сказать, этот факт меня неприятно удивил, так как за столь длительное время существования iLO2 HP так и не довели это дело до ума. Далее вы узнаете, что это ещё не самый интересный факт. Итак, переходим на закладку управления параметрами подключения к AD (Administration > Security > Directory). Включаем опцию использования доменной аутентификации — Use Directory Default Schema. В поле Directory Server Address указываем через запятую FQDN имена контроллеров домена (при этом надо понимать что в настройках сети при этом должны быть заданы адреса серверов DNS). Порт оставляем по умолчанию – 636 (на контроллерах домена должна поддерживаться возможность безопасного подключения SSL на этот порт). В поле Directory User Context 1 вписываем DN доменного контейнера, в котором

Возникла потребность делегировать права управления почтовыми Контактами Exchange Server 2010 (SP2) отдельной группе пользователей. Процесс предоставления такого уровня прав подразумевает два этапа: 1) Делегирование прав на создание/изменение/удаление объектов типа Контакт в определённой организационной единице (OU) Active Directory (AD) для определённой группы пользователей. 2) Делегирование прав на работу с командлетами Exchange Management Shell (EMS), отвечающими за управление почтовыми контактами. Создадим в домене универсальную группу безопасности. В нашем примере это будет группа KOM-SRV-EXCHANGE-Contact-Managers-TCV2. В оснастке Active Directory — Users and Computers установив курсор на том OU, к которому нужно выдать права вызовем мастер делегирования управления В мастере добавим ранее созданную универсальную группу безопасности Далее выберем создание особой задачи для делегирования Затем укажем то, что мы хотим разрешить управление только объектами типа Контакт (включим опции создания и удаления) Разрешения выберем полные… Завершаем работу мастера и переходим ко второму этапу – настройке прав доступа на Exchange 2010. Нас интересуют две предопределённые роли в механизме управления доступом к объектам Exchange на основе ролей (Role Based Access Control, RBAC): Mail Recipients Mail Recipient Creation Именно в этих ролях присутствуют командлеты EMS отвечающие за создание/изменение/удаление контактов Exchange. Посмотрим в EMS какие командлеты нам доступны: Get-ManagementRoleEntry "Mail Recipient*\*" | Where {$_.Name -like "*contact*"} | ft –AutoSize Как видим, из обоих ролей нам доступно 8 командлетов, и теперь наша задача состоит в том, чтобы создать на основе этих двух предопределённых ролей новые дочерние роли, которые будут содержать в себе только нужные нам командлеты. Сначала создаём новую роль на основе предопределённой существующей роли Mail Recipients. Эта роль будет отвечать за командлеты редактирования Контактов. Из созданной роли удаляем все командлеты не относящиеся к управлению Контактами $vRName1 = "KOM Contact Managers - Redaction" New-ManagementRole -Name $vRName1 -Parent "Mail Recipients" $vRoles = Get-ManagementRoleEntry "$vRName1\*" | Where { $_.Name -NotLike "*Contact*" } Foreach ($vRole in $vRoles) {Remove-ManagementRoleEntry -Identity "$($vRole.Identity)\$($vRole.Name)" -Confirm:$False} Get-ManagementRoleEntry "$vRName1\*" В итоге,

В больших ИТ-инфраструктурах обслуживающих сразу несколько компаний периодически возникает потребность оперативного получения информации о количестве пользователей и компьютеров в разрезе этих компаний для разных целей, например при анализе текущей ситуации и планировании лицензирования ПО. Для того чтобы разделить всех пользователей и компьютеры в разрезе компаний в AD можно воспользоваться атрибутом company, который имеет место быть не только для учетных записей пользователей (что очевидно), но и для учетных записей компьютеров. Соответственно если мы имеем заполненным значение этого атрибута то с помощью PowerShell можем выполнять нехитрые запросы, сворачивая информацию в нужных нам разрезах. Далее небольшой ряд примеров… *** Подсчитываем в AD количество компьютеров в разрезе версий ОС и организаций к которым относятся эти компьютеры (из атрибута company) и при этом сворачиваем данные сначала по версии операционной системы, а затем по юр.лицу: Import-Module ActiveDirectory $OU = "dc=holding,dc=com" $Filter = "(&(objectClass=computer)(cn=KOM-*)(!description=*cluster*)(!userAccountControl:1.2.840.113556.1.4.803:=2))" Get-ADComputer -SearchBase $OU -ResultSetSize $null -LDAPFilter $Filter -Properties * | Sort-Object operatingSystem, company | Group-Object operatingSystem, company | FT -AutoSize В этом примере используется LDAP-фильтр, в котором выбираются все объекты AD типа Компьютер с именем начинающимся с определённого префикса и при этом отбрасываются выключенные учетные записи и те учетные записи у которых в описании встречается слово cluster, так как, как правило, это служебные учетные записи которые создаются службами класастеризации Windows Server Failover Clustering Если же требуется свернуть данные сначала по организации, а уже потом по версии ОС, достаточно просто поменять местами атрибуты operatingSystem и company на этапе сортировки и группировки *** Подсчитываем фактическое использование клиентских лицензий (CAL) для Lync в консоли Lync Server Management Shell. Пользователи с SIP выключенные: (Get-CsUser -OU "ou=KOM,dc=holding,dc=com" -LdapFilter "&(objectCategory=user)(objectClass=user)(userAccountControl:1.2.840.113556.1.4.803:=2)").count Пользователи с SIP действующие: (Get-CsUser -OU "ou=KOM,dc=holding,dc=com" -LdapFilter "&(objectCategory=user)(objectClass=user)(!userAccountControl:1.2.840.113556.1.4.803:=2)").count Посчитать пользователей по конкретной маске имени организации можно добавив в параметр LdapFilter значение типа (company=*сбыт*) Чобы получить свод в разрезе всех имеющихся значений атрибута company используем командлет AD — Get-ADUser:

В одной из прошлых заметок я уже писал о проблеме выбора ближайшего RWDC при вводе в домен компьютера попадающего в сайт с RODC. В процессе перевода RODC на Windows Server 2012 на одной из удалённых площадок столкнулся с ситуацией, до боли напоминающей старую проблему… В процессе работы мастера повышения сервера до RODC при попытке выбрать в домене группу для Администраторов RODC или же группы для репликации паролей, диалоговое окно выбора доменных объектов не открывалось и возникала странная ошибка, говорящая о невозможности определения состояния RWDC находящегося совершенно “в другой степи” и не имеющего отношения ни к местному сайту ни к ближайшему RWDC. Конечно можно было бы не менять настройки на этом шаге мастера и выполнить установку с настройками по умолчанию, а уже после окончания установки назначить группу Администраторов RODC и задать группы репликации паролей, но в голову пришла мысль о том, что выполнить повышение до RODC можно и с помощью PowerShell сразу указав при этом в явном виде все необходимые группы доступа. Собственно далее – небольшая шпаргалка как это сделать. *** Если это ещё не сделано ранее, вводим компьютер в домен с привязкой процедуры джойна к конкретному ближайшему контроллеру домена RWDC с помощью командлета Add-Computer. Как видно из прошлой заметки, в Win7/2008R2 параметр -Server не работал как мы от него этого ожидали и приходилось указывать контроллер домена после имени домена таким образом: -DomainName:"holding.com\Best-DC" а вот в W8/WS2012 по словам моих коллег (сам я это не успел проверить) ситуация изменилась к лучшему и теперь мы можем использовать команду вида: Add-Computer -DomainName:"holding.com"` -Server:"Best-DC" ` -Credential:"HOLDING\admin" ` -OUPath:"OU=Servers,OU=TCIN,DC=holding,DC=com" ` -Verbose -PathThru *** Перед тем как выполнять процесс повышения в системе должны быть активированы соответствующие фичи. Проверяем статус установки нужных компонент: Import-Module "ServerManager" Get-WindowsFeature "Ad-Domain-Services","DNS" И если нужные компоненты не были установлены ранее, выполняем их установку: Import-Module "ServerManager" Add-WindowsFeature "Ad-Domain-Services","DNS" -IncludeManagementTools *** Перед тем

После перевода серверов виртуализации на Windows Server 2012 возникло желание использовать новый функционал Hyper-V — Shared Nothing Live Migration для хостов не являющихся членами кластеров. Здесь я опишу практический пример действий, которые были выполнены для того, чтобы отделить трафик миграции от основного трафика управления хостом виртуализации. В рассматриваемом примере имеется два сервера виртуализации HP ProLiant DL380 G5 с дополнительно установленным двух-портовым гигабитным сетевым адаптером HP NC360T. Таким образом каждый сервер имеет по четыре гигабитных сетевых интерфейса, которые мы будем использовать в следующем порядке: Port 1 NC373I (On-Board NIC1) – Под трафик резервного копирования DPM Port 2 NC373I (On-Board NIC2) – Под трафик Live Migration (LM) Port 3 NC360T (PCI-E NIC Port1) – Под трафик управления хостом Port 4 NC360T (PCI-E NIC Port2) – Под трафик виртуальных машин Настраиваем отдельный сетевой интерфейс для Live Migration Соответственно первое что мы должны сделать, это выделить отдельную IP подсеть и назначить каждому серверу IP адрес из этой подсети. В нашем примере под задачи миграции выделена подсеть 10.160.35.0/24 и адрес из этой подсети указан на интерфейсе Port 2 на каждом из серверов. Указываем только IP адрес и маску подсети. Шлюз по умолчанию оставляем пустым (он указан только на интерфейсе управления хостом — Port 3). По кнопке Advanced открываем расширенные настройки IPv4 и отключаем регистрацию в DNS На закладке Networking оставляем включенным только минимально необходимое количество модулей: Client for Microsoft Networks QoS Packet Scheduler File and Printer Sharing for Microsoft Network Internet Protocol Version 4 (TCP/IPv4) Также не забываем выставить приоритет использования сетевых интерфейсов таким образом, чтобы интерфейс управления (в нашем случае Port 3) был самым первым. Control PanelNetwork and InternetNetwork Connections > Меню Advanced После того как на обоих наших серверах виртуализации настроены сетевые интерфейсы для миграции, проверим их взаимную доступность выполнив Ping IP адресов сегмента 10.160.35.0/24 с одного сервера на другой. В нашем примере

На первоначальном этапе внедрения новых ОС нам нужно подготовить доменную инфраструктуру применения групповых политик – расширить набор шаблонов групповых политик для поддержки новых систем, расположенный в центральном хранилище шаблонов в сетевой папке, например в нашем случае это будет папка \\holding.com\SYSVOL\holding.com\Policies\PolicyDefinitions\ Перед нами стоит задача – собрать все новые и обновлённые *.ADMX файлы шаблонов групповых политик и соответствующие им английские и русские языковые *.ADML файлы (чтобы администраторы в домене могли при необходимости использовать для редактирования групповых политик оснастку Group Policy Management (GPMC) на обоих языках). Для выполнения этой задачи нам понадобится 4 дистрибутива (*.ISO файлы), из которых мы будем извлекать соответствующие файлы: Windows 8.1 RTM English (32 или 64 бита) Windows 8.1 RTM Russian (32 или 64 бита) Windows Server 2012 R2 RTM English Windows Server 2012 R2 RTM Russian Создадим структуру временных папок, например C:\Temp\ADMX , в которой подкаталоги \W81_EN , \W81_RU, \WS2012R2_EN, \WS2012R2_EN, \WS2012R2_RU будут использоваться для извлечения ADMX/ADML файлы из соответствующих систем а подкаталог \WIM будет использоваться для временного монтирования WIM-образов из состава дистрибутивов соответствующих систем. Общий порядок выполняемых действий с каждым из 4 перечисленных дистрибутивом такой: 1) Монтируем в виртуальный DVD-привод ISO-образ дистрибутива;2) Внутри смонтированного ISO-образа находим WIM-образ содержащий копию ОС и изучив его монтируем эту копию ОС во временный подкаталог \WIM;3) Внутри смонтированного WIM находим файлы ADMX/ADML и копируем их в соответствующие подкаталоги;4) Размонтируем WIM-образ;5) Размонтируем ISO-образ.Итак, рассмотрим эту цепочку действий на примере дистрибутива Windows Server 2012 R2 RTM English. Монтируем ISO-образ дистрибутива в командной строке вызывая командлеты PowerShell: PowerShell Mount-DiskImage 'C:\Temp\Windows Server 2012 R2\RTM\SW_DVD5_Windows_Svr_Std_and_DataCtr_2012_R2_64Bit_English_Core_MLF_X19-05182.ISO' При указании полного пути ISO-файла образа обязательно используем одинарные кавычки, т.к. использование двойных кавычек в данной ситуации по непонятной для меня причине вызывают у PS ошибку.В нашем примере, в результате выполнения этой команды, образ смонтировался с буквой диска H:\ Находим в смонтированном образе файл H:\sources\install.wimТеперь нам нужно забраться внутрь этого файла

Ранее как-то я уже писал пост о проблеме c миграцией VM, с которой довелось столкнуться на свеже-установленном хосте Hyper-V на Windows Server 2012. Как я тогда предположил, корнем проблемы было поднятие роли Hyper-V до ввода в домен. Однако комментаторы меня заставили усомниться в этом предположении, более того, спустя некоторое время я заметил, что проблема регистрации SPN «всплыла» снова. То есть, даже не смотря на то, что нужные службе VMMS недостающие SPN для учетных записей проблемных хостов были прописаны в домене вручную, журнал Microsoft/Windows/Hyper-V-VMMS/Admin был переполнен регистрируемыми каждые 2 минуты десятками сотен однотипных ошибок: Log Name: Microsoft-Windows-Hyper-V-VMMS-AdminSource: Microsoft-Windows-Hyper-V-VMMSDate: 10.01.2014 11:50:42Event ID: 14050Task Category: NoneLevel: Error User: SYSTEMComputer: KOM-AD01-VM08.holding.comDescription:Failed to register the service principal name ‘Hyper-V Replica Service’. Log Name: Microsoft-Windows-Hyper-V-VMMS-AdminSource: Microsoft-Windows-Hyper-V-VMMSDate: 10.01.2014 11:50:42Event ID: 14050Task Category: NoneLevel: Error User: SYSTEMComputer: KOM-AD01-VM08.holding.comDescription:Failed to register the service principal name ‘Microsoft Virtual System Migration Service’. Log Name: Microsoft-Windows-Hyper-V-VMMS-AdminSource: Microsoft-Windows-Hyper-V-VMMSDate: 10.01.2014 11:50:42Event ID: 14050Task Category: NoneLevel: Error User: SYSTEMComputer: KOM-AD01-VM08.holding.comDescription:Failed to register the service principal name ‘Microsoft Virtual Console Service’. Поиски решения привели к статье KB2761899 — Hyper-V VMM service fails and Event ID 14050 is logged when dynamicportrange is changed in Windows Server 2012. Применительно к моей ситуации любопытной оказалась информация об одной из возможных причин: This problem may also occur if the NTDS port has been restricted to a specific port on your domain controllers. If this selected NTDS port is not within the default ranges, you must add this port by running the script in the «Resolution» section on every Hyper-V host. Тут же вспомнился тот факт, что ранее один из доменных администраторов, видимо руководствуясь статьёй KB224196 — Restricting Active Directory replication traffic and client RPC traffic to a specific port, применил ко всем контроллерам домена групповую политику в которой присутствовал скрипт изменения порта службы NTDS, в частности в параметрах реестра был

Возникла необходимость в развёртывании сервера FTP с анонимной авторизацией для внутренних задач в локальной сети. И чтобы не плодить лишние сущности, то есть не разворачивать дополнительный сервер исключительно под эту задачу, возникло желание использовать существующие файловые сервера. В нашем случае файловый сервис реализован на базе двух серверов состоящих в кластере Failover Cluster на Windows Server 2012 R2 и использующих общее дисковое хранилище. Решение предлагаемое Microsoft для кластеризации FTP на базе Failover Cluster в статье KB974603 — How to configure FTP for IIS 7.0 or higher in a Windows Server 2008 or Windows Server 2012 failover cluster нам в чистом виде не подошло, так как оно предполагает наличие выделенного общего кластерного диска, а в нашей ситуации вся доступная ёмкость общего дискового хранилища в кластере уже была отдана под роль файлового сервиса. Статья The Admin’s Window — Configuring highly available FTP server on a Windows Server 2008 failover cluster (without FTP dedicated storage) натолкнула на размышления о том, как можно обойти эту ситуацию. В этой статье описан метод небольшого изменения существующей кластерной конфигурации таким образом, чтобы можно было для роли сервера высоко-доступного FTP использовать кластерную группу ресурсов (в том числе и общую дисковую емкость) существующего файлового кластера. Несмотря на то, что указанной статье без малого три года и речь в ней шла о Windows Server 2008/2008 R2 и IIS 7, мы решили попробовать реализовать данный сценарий на Windows Server 2012 R2, добавив в предложенную реализацию функционал общей конфигурации IIS как описано в KB974603. Однако после развертывания и тестирования такой конфигурации стало понятно, что в ней тоже есть свои недостатки. В дальнейшем после некоторых экспериментов получилось собрать такую конфигурацию, при которой на узлах существующего файлового кластера для кластерного экземпляра службы FTP используется отдельная кластерная группа ресурсов. При этом IIS на узлах кластера использует общую конфигурацию (IIS Shared Configuration), а корневая папка высоко-доступного FTP-узла

После внедрения Audit Collector из состава System Center 2012 R2 Operations Manager при анализе изменений членства глобальных доменных групп безопасности стало очевидно, что вариант описанного ранее скрипта в заметке PowerShell – Поддержание группы безопасности для Password Settings objects (PSOs) в актуальном состоянии не является оптимальным, так как в результате его выполнения каждый раз фактически происходит переписывание состава членства группы безопасности, что судя по последующему анализу журналов безопасности на контроллере домена, порождает множественные события удаления/добавления пользователей в эту самую группу. Привожу вариант измененного скрипта, использующего новые командлеты из PowerShell модуля ActiveDirectory на Windows Server 2012 R2. В обновлённом скрипте используется поиск и добавление в группу только конкретных учетных записей, а не полное переписывание членства как это было ранее. # Блок переменных # $SearchOUDN - Контейнер с доменными учетными записями пользователей в формате distinguishedName # $LDAPPathSG - Доменная группа безопасности в формате distinguishedName # $CountDisabledUsers - Признак обработки отключенных учетных записей пользователей (1 или 0) # $CountServiceUsers - Признак обработки сервисных учетных записей пользователей (1 или 0) # $CountAdministrators - Признак обработки административных учетных записей пользователей (1 или 0) # $SearchOUDN = "OU=Branch Users,DC=holding,DC=com" $SecGroupDN = "CN=KOM-SRV-PSO-Users,OU=My Groups,DC=holding,DC=com" # $CountDisabledUsers = 0 $CountServiceUsers = 0 $CountAdministrators = 1 # # Блок поиска # $LAPF = '(objectCategory=person)(objectClass=user)' If ($CountDisabledUsers -eq 0) { $LAPF = $LAPF + '(!(userAccountControl:1.2.840.113556.1.4.803:=2))' } If ($CountServiceUsers -eq 0) { $LAPF = $LAPF + '(!(sAMAccountName=s-*))' } If ($CountAdministrators -eq 0) { $LAPF = $LAPF + '(!(sAMAccountName=a-*))' } $LAPF = '(&' + $LAPF + ')' $UsersInOU = Get-ADObject -LDAPFilter $LAPF -SearchBase $SearchOUDN # # Блок наполнения группы безопасности # $OldMembers = Get-ADGroupMember -Identity $SecGroupDN $NewMembers = @() ForEach ($User in $UsersInOU){ If ($OldMembers.DistinguishedName -notcontains $User.distinguishedName) { $NewMembers = $NewMembers + $User } } # Write-Host 'Total user accounts in OU: ' $UsersInOU.Count Write-Host 'Current users in group: ' $OldMembers.Count # If

Как и в предыдущей заметке было решено оптимизировать скрипт изложенный ранее в заметке PowerShell – Поддержание групп безопасности политики репликации паролей RODC в актуальном состоянии для выполнения с использованием новых командлетов из PowerShell модуля ActiveDirectory на Windows Server 2012 R2 таким образом, чтобы в результате работы скрипта не происходило полное переписывание членства пользователей в группах безопасности. Для работы скрипта потребуется конфигурационный файл в формате *.csv, в котором будет содержаться информация о том, какие OU в домене будут использоваться для поиска учетных записей пользователей и заполнения ими определённых групп репликации паролей. Каждая строчка файла представляет собой связку DN доменной группы безопасности репликации паролей и DN OU. Файл должен иметь примерно такое содержание: RODCAllowGroupDN;UsersOUDN CN=RODC-Group1,OU=Groups,DC=mydom,DC=com;OU=Branch1,DC=mydom,DC=com CN=RODC-Group2,OU=Groups,DC=mydom,DC=com;OU=Branch2,DC=mydom,DC=com CN=RODC-Group3,OU=Groups,DC=mydom,DC=com;OU=Branch3,DC=mydom,DC=com В самом скрипте в блоке переменных в переменной $DataFile нужно указать полный путь к соответствующему CSV файлу. # Блок переменных # $DataFile - Путь к файлу для сопоставления групп безопасности c OU # $CountDisabledUsers - Признак обработки отключенных учетных записей пользователей (1 или 0) # $CountServiceUsers - Признак обработки сервисных учетных записей пользователей (1 или 0) # $CountAdministrators - Признак обработки административных учетных записей пользователей (1 или 0) # $DataFile = '.\RODC-AddUsersToGroupsFromOUs.csv' $CountDisabledUsers = 0 $CountServiceUsers = 1 $CountAdministrators = 1 # # Описание фильтра поиска # $LAPF = '(objectCategory=person)(objectClass=user)' If ($CountDisabledUsers -eq 0) { $LAPF = $LAPF + '(!(userAccountControl:1.2.840.113556.1.4.803:=2))' } If ($CountServiceUsers -eq 0) { $LAPF = $LAPF + '(!(sAMAccountName=s-*))' } If ($CountAdministrators -eq 0) { $LAPF = $LAPF + '(!(sAMAccountName=a-*))' } $LAPF = '(&' + $LAPF + ')' # # Функция сравнения и наполнения группы безопасности # Function AddUsersToGroupFromOU ($GroupDN, $OUDN) { Write-Host 'Processing group: ' $GroupDN Write-Host 'Search in OU: ' $OUDN $UsersInOU = @() $OldMembers = @() $NewMembers = @() # $UsersInOU = Get-ADObject -LDAPFilter $LAPF -SearchBase $OUDN $OldMembers = Get-ADGroupMember -Identity $GroupDN ForEach ($User in $UsersInOU){ If ($OldMembers.DistinguishedName -notcontains $User.distinguishedName)

Очередная заметка цикла об установке и базовой настройке SharePoint Server 2013 SP1 будет посвящена настройке общей службы SharePoint – Службы профилей пользователей (User Profile Service) и связанной с ней службы — Службы синхронизации профилей (User Profile Synchronization Service). Онлайн документацию на русском языке о развертывании и настройке Службы профилей можно найти в документе Администрирование службы профилей пользователей в SharePoint Server 2013, где мы можем найти краткое определение этих двух служб: Служба профилей пользователей — это общая служба в SharePoint Server 2013, позволяющая создавать и администрировать профили пользователей, доступ к которым можно получить с нескольких сайтов и из нескольких ферм. Служба синхронизации профилей в SharePoint Server 2013 позволяет администраторам службы профилей пользователей синхронизировать сведения профилей пользователей и групп, которые хранятся в хранилище профилей SharePoint Server 2013, со сведениями профилей, которые хранятся в службах каталогов и бизнес-системах предприятия. Согласно документа Создание, изменение и удаление приложений службы профилей пользователей в SharePoint Server 2013 нам необходимо убедиться в том, что выполнены предварительные требования для развертывания Службы профилей: - Используется редакция SharePoint Server 2013 Standard или Enterprise- Существует экземпляр Службы управляемых метаданных (Managed Metadata Service).- Существует пул приложений и развернутое на нём семейство сайтов, которое использует шаблон узла личного сайта (My Site Host template) В нашем случае эти условия соблюдены и мы приступаем к реализации следующего плана действий: 1. Настройка Службы профилей пользователей (User Profile Service) 1.1. Создаем управляемую учетную запись (Managed Account) для Службы профилей1.2. Создаем новый экземпляр общей Службы профилей (User Profile Service)1.3. Проверяем доступность веб-узла Личных сайтов 2. Настройка Службы синхронизации профилей пользователей (User Profile Synchronization Service) 2.1. Включаем поддержку доменных имен NetBIOS для Службы профилей2.2. Настраиваем разрешения для учетной записи SharePoint Farm service account на уровне сервера SharePoint2.3. Создаем учетную запись синхронизации и предоставляем ей разрешения на уровне домена2.4. Запускаем Службу синхронизации профилей2.5. Создаем и настраиваем подключение синхронизации к службе каталогов

В Active Directory (AD) для учетной записи пользователя есть возможность использовать атрибут thumbnailPhoto для хранения фотографии пользователя в виде двоичных данных. В рамках этой заметки мы рассмотрим процедуру настройки импорта значений этого атрибута в свойство профиля пользователя в Службе профилей SharePoint Server 2013 для дальнейшего отображения фотографий пользователей на веб-сайтах SharePoint. Несмотря на то, что максимально допустимый размер значения этого атрибута в AD составляет 100KB, в сети чаще всего можно встретить рекомендации использовать для записи в этот атрибут графические файлы размером не более 10KB с расширением 96×96 пикселей. Пример того, как с помощью PowerShell можно установить фотографию пользователя в значение выше-обозначенного атрибута в AD: Import-Module ActiveDirectory $userName = "Felix" $filePath = "C:\Temp\Felix-96x96.png" [byte[]]$img = Get-Content $filePath -encoding byte Get-ADUser -filter {samaccountname -eq $userName} | Set-ADUser -replace @{thumbnailphoto=$img} После этого установленная фотография начнёт отображаться в таких приложениях, как Outlook и Lync Помимо Powershell для пакетной установки фотографий в AD можно использовать такие инструменты, как например Exclaimer Outlook Photos. Убедившись в том, что фотографии пользователей установлены в AD, переходим к настройке Службы профилей SharePoint 2013 на веб-узле Центра администрирования (ЦА) фермы SharePoint по ссылкам: Central Administration > Application Management > Service Applications > Manage service applications. Выбираем приложение User Profile Service Application и в ленте нажимаем Manage В разделе настроек People выбираем пункт Manage User Properties. В открывшемся списке свойств профиля находим представленное в конфигурации по умолчанию свойство Picture и открываем для него меню действий, где выбираем пункт правки Edit В открывшейся форме редактирования параметров свойства переходим к разделу Add New Mapping и создаём ассоциацию этого свойства с атрибутом AD thumbnailPhoto с направлением синхронизации (Direction) Import. Чтобы возможность такой настройки была доступна, нами ранее предварительно должно быть сконфигурировано соединение службы профилей со службой каталогов AD, как было описано ранее в заметке Настройка Службы профилей (User Profile Service) Сохраняем изменения свойства

В этой части мы рассмотрим порядок настройки Ubuntu Server 14.04 LTS для обеспечения возможности работы с механизмами аутентификации пользователей прокси-сервера Squid 3 по протоколам Kerberos и NTLM в среде домена Active Directory (AD). Для поддержки NTLM наш Linux-сервер будет присоединён к домену AD, а для поддержки Kerberos для сервера в домене будет создана специальная служебная учетная запись пользователя. В дальнейшем при конфигурации Squid, протокол Kerberos будет использоваться как приоритетный, а протокол NTLM будет применяться в случаях когда клиент прокси-сервера по какой-то причине не может использовать Kerberos. Добавляем поддержку Kerberos Сначала проверим список установленных пакетов dpkg-query --list | grep krb krb5-locales 1.12+dfsg-2ubuntu4 all Internationalization support for MIT Kerberos libgssapi-krb5-2:amd64 1.12+dfsg-2ubuntu4 amd64 MIT Kerberos runtime libraries krb5 GSS-API Mechanism libkrb5-26-heimdal:amd64 1.6~git20131207+dfsg-1ubuntu1 amd64 Heimdal Kerberos - libraries libkrb5-3:amd64 1.12+dfsg-2ubuntu4 amd64 MIT Kerberos runtime libraries libkrb5support0:amd64 1.12+dfsg-2ubuntu4 amd64 MIT Kerberos runtime libraries - Support library Можно встретить упоминания о том что нужно установить пакеты krb5-user и libkrb53. Однако в нашем случае установка пакета libkrb53 будет безуспешна и, как я понял, в системе уже присутствует заменяющий пакет libkrb5-3, поэтому мы выполним установку только пакета krb5-user sudo apt-get install krb5-user Сохраним на всякий случай появившийся в системе после установки пакета krb5-user конфигурационный файл krb5.conf в krb5.conf.default и откроем исходный файл в текстовом редакторе (с подсветкой синтаксиса): sudo cp /etc/krb5.conf /etc/krb5.conf.default sudo nano -Y sh /etc/krb5.conf Очистим содержимое файла (или закомментируем все открытые строки) и впишем туда следующие строки: [libdefaults] default_realm = HOLDING.COM dns_lookup_kdc = no dns_lookup_realm = no ticket_lifetime = 24h default_keytab_name = /etc/squid3/PROXY.keytab # for Windows 2003 # default_tgs_enctypes = rc4-hmac des-cbc-crc des-cbc-md5 # default_tkt_enctypes = rc4-hmac des-cbc-crc des-cbc-md5 # permitted_enctypes = rc4-hmac des-cbc-crc des-cbc-md5 # for Windows 2008 with AES default_tgs_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5 default_tkt_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5 permitted_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5 [realms] HOLDING.COM = { kdc =

В одной из прошлых заметок мы рассмотрели процедуру присоединения сервера на базе Ubuntu Server 14.04 LTS к домену Active Directory (AD) для обеспечения работы процедур аутентификации и авторизации на прокси-сервере Squid 3.3. Тем самым мы упростили доступ рядовых доменных пользователей к ресурсам Интернет. Однако не стоит забывать и об администраторах. Использование локальных учетных записей для аутентификации и авторизации администраторов на Linux-серверах может доставлять свои неудобства, когда количество таких серверов в организации увеличивается. В этой заметке мы рассмотрим процедуры настройки сервера Ubuntu направленные на упрощение процедур аутентификации и авторизации при входе в Linux-систему путём использования учетных записей пользователей и групп безопасности домена AD. Как и в предыдущих заметках посвященных теме интеграции Linux в AD, в качестве хранилища доменных учетных записей пользователей и групп в нашем примере будут использоваться контроллеры домена под управлением ОС Microsoft Windows Server 2012 R2. Прежде чем приступим, хочу сделать одно важное замечание. В этой заметке мы будем выполнять корректировку некоторых системных конфигурационных файлов, отвечающих за работу аутентификации и авторизации для локального и удалённого входа в Linux-систему. Поэтому, перед тем как начать подобные корректировки, настоятельно рекомендую сделать резервную копию системы, например снапшот виртуальной машины, ибо в случае некорректных настроек PAM мы сможем получить проблемы со входом в систему (например после перезагрузки сервера). *** Устанавливаем плагин для Samba4 (nss_winbind) и поддержку Winbind для PAM: sudo apt-get install libnss-winbind libpam-winbind *** Проверяем работу Kerberos пытаясь получить билет для какого-нибудь доменного пользователя. kinit artur-p@HOLDING.COM Проверяем наличие билета Kerberos klist Ticket cache: FILE:/tmp/krb5cc_1000 Default principal: artur-p@HOLDING.COM Valid starting Expires Service principal 07/01/2014 14:06:14 07/02/2014 00:06:14 krbtgt/HOLDING.COM@HOLDING.COM renew until 07/02/2014 14:06:09 Очищаем кэш билетов: kdestroy *** Конфигурация Samba4 по умолчанию для новых пользователей подразумевает создание домашнего каталога пользователя по шаблону (template homedir) /home/{Домен}/{Логин} с отсутствием оболочки (template shell). Немного изменим конфигурацию /etc/samba/smb.conf задав параметр описывающий оболочку sudo nano -Y sh /etc/samba/smb.conf Новое содержимое

Продолжая тему интеграции систем на базе Linux в доменную инфраструктуру Active Directory (AD), в этой заметке мы рассмотрим вопрос настройки Single sign-on (SSO) при подключении к Linux-серверу на базе Ubuntu Server 14.04 LTS по протоколу SSH с клиентских компьютеров под управлением Windows. Начнём с настроек на стороне Linux-сервера, который будет выступать в качестве сервера SSH на базе пакета OpenSSH (описание установки и базовой настройки рассмотрено ранее). Для начала включим поддержку GSSAPI для службы сервера OpenSSH и пропишем ограничение по группам доступа: sudo nano -Y sh /etc/ssh/sshd_config Фрагмент изменённых и добавленных строк конфигурационного файла: # GSSAPI options GSSAPIAuthentication yes GSSAPICleanupCredentials yes # User groups access contol AllowGroups adm kom-srv-linux-administrators Разрешённые группы нужно указывать через пробел. В списке могут фигурировать как локальные (для локальных пользователей) так и доменные (для доменных пользователей) группы доступа, при этом их названия должны быть указаны в нижнем регистре, так как их возвращает команда groups для текущего пользователя. Для вступления изменений в силу перезапускаем службу сервера SSH: sudo service ssh restart *** Теперь нам нужно реализовать возможность для Kerberos-подсистемы представляться разным службам от имени принципала (SPN) HOST/{ServerFQDN}@{DomainFQDN}.Посмотрим что возвращает команда: sudo net ads keytab list Warning: "kerberos method" must be set to a keytab method to use keytab functions. Vno Type Principal 3 des-cbc-crc HTTP/kom-ad01-squid.holding.com@HOLDING.COM 3 des-cbc-md5 HTTP/kom-ad01-squid.holding.com@HOLDING.COM 3 arcfour-hmac-md5 HTTP/kom-ad01-squid.holding.com@HOLDING.COM 3 aes256-cts-hmac-sha1-96 HTTP/kom-ad01-squid.holding.com@HOLDING.COM 3 aes128-cts-hmac-sha1-96 HTTP/kom-ad01-squid.holding.com@HOLDING.COM Как видно, мы получаем список ключей, которые хранятся в keytab-файле указанном в параметре default_keytab_name конфигурационного файла /etc/krb5.conf, который мы задали ранее конфигурируя систему для Squid. Однако в силу того, что дополнительно мы создавали файл /etc/default/squid3 где прописали путь к keytab-файлу необходимому для Squid, мы смело можем отключить параметр default_keytab_name конфигурационного файла /etc/krb5.conf, чтобы в системе по умолчанию использовался файл /etc/krb5.keytab. Итак, отредактируем файл krb5.conf: sudo nano -Y sh /etc/krb5.conf Закомментируем в нём ранее записанную нами строку: # default_keytab_name = /etc/squid3/PROXY.keytab ***

В этой заметке будет рассмотрен пример настройки VPN-сервиса на базе Windows Server 2012 R2 с ролью Remote Access. Для повышения доступности VPN-сервиса в рассматриваемой далее конфигурации будет использоваться два виртуальных сервера (на базе Hyper-V) объединённых в NLB-кластер. Для повышения гибкости правил предоставления доступа к разным ресурсам локальной сети для VPN-клиентов на стороне VPN-серверов будет выполнена привязка схемы аутентификации к расположенным в локальной сети RADIUS серверам (на базе Network Policy Server). Для повышения безопасности VPN-соединений в качестве основного протокола будет использоваться L2TP/Ipsec с использованием цифровых сертификатов. Двухфакторная аутентификация будет основана на проверке сертификата и доменной учетной записи пользователя Среда исполнения В рассматриваемом примере будет создан Windows NLB кластер из двух виртуальных серверов одинаковой конфигурации на базе Hyper-V из Windows Server 2012 R2 Datacenter EN. На виртуальных серверах устанавливается Windows Server 2012 R2 Standard EN. Каждый из виртуальных серверов будет иметь по два сетевых интерфейса, настройка которых будет рассмотрена далее. Серверам присвоены имена – KOM-AD01-VPN01 и KOM-AD01-VPN02. Создаваемый в процессе описания NLB-кластер будет использовать имя KOM-AD01-VPNCL. В качестве поставщика аутентификации будут использоваться два отдельных сервера внутри локальной сети с заранее установленной и настроенной ролью Network Policy and Access Services (RADIUS) с именами KOM-AD01-NPS01 и KOM-AD01-NPS02. Аутентификация для протокола L2TP/IPsec с использованием сертификатов потребует наличия Доменного или Автономного Центра сертификации (ЦС) для создания цифровых сертификатов для VPN-клиентов. В рассматриваемой конфигурации а качестве Автономного ЦС будет использоваться отдельный сервер внутри локальной сети с именем KOM-AD01-CA01 Упрощённая схема взаимодействия компонент конфигурации будет выглядеть следующим образом: Данная конфигурация построена по принципу избыточности основных функциональных компонент. Если потребности в наличии такой избыточности нет, то описанную ниже конфигурацию вполне можно реализовать в рамках одного виртуального сервера, совместив соответствующие серверные роли на нём. Так как планируемая конфигурация получается многокомпонентной, то во избежание лишних сложностей, мы не будем пытаться настроить весь функционал сразу. Вместо этого мы сначала настроим базовый функционал

PowerShell —Аудит использования учетных записей

Windows Server 2008 R2 —Корзина Active Directory

PowerShell —Резервное копирование групповых политик (GPO)

PowerShell —Получаем список трастов AD

HP iLO2 —Настраиваем доменную авторизацию

Exchange 2010 —Делегируем управление контактами

Извлекаем информацию из Active Directory в разрезе компаний с помощью PowerShell

Windows Server 2012 —Поднимаем RODC через PowerShell

Отделяем трафик Hyper-V Shared Nothing Live Migration

Обновляем ADMX шаблоны групповых политик в центральном доменном хранилище до уровня Windows 8.1 и Windows Server 2012 R2

Hyper-V-VMMS Event ID 14050 — Failed to register the service principal name ‘Hyper-V Replica Service’. Возвращаясь в к проблеме регистрации SPN в Windows Server 2012 R2

Настраиваем высоко-доступный сервер FTP в существующем файловом кластере на базе Windows Server 2012 R2 Failover Cluster (без выделенного диска под роль FTP)

PowerShell –Обновление группы безопасности для Password Settings objects (PSOs) в Windows Server 2012 R2

PowerShell –Обновление групп безопасности политик репликации паролей RODC в Windows Server 2012 R2

Установка и базовая настройка SharePoint Server 2013 SP1 на Windows Server 2012 R2 (в топологии Two-tier farm). Часть 7 –Настройка Службы профилей (User Profile Service)

Импорт фотографий пользователей из Active Directory в SharePoint Server 2013

Настройка прокси сервера Squid 3.3 на Ubuntu Server 14.04 LTS. Часть 4. Конфигурация Kerberos и NTLM

Аутентификация и авторизация в домене Active Directory при подключении к серверу Ubuntu Server 14.04 LTS

SSO-подключение к серверу Ubuntu Server 14.04 LTS по протоколу SSH с помощью PuTTY с компьютера на базе Windows в домене Active Directory

Windows Server 2012 R2 Remote Access —Настраиваем VPN сервер с двухфакторной аутентификацией на базе L2TP/IPsec и авторизацией через RADIUS