Как устанавливается агент Data Protection Management

Итак я расписал в шагах, как устанавливается сервис от Microsoft по резервному копированию.

• Как развернуть System Center Data Protection Management 2012 R2
• Разворачиваем DPM 2012 R2 отдельно от SQL Server

У меня резервируется, как я и говорил ранее: File Share, Exchange Mailbox, SQL Database. Но прежде чем перейти к их пошаговому исполнению, нужно на контролируемую систему где развернуты сервисы бекапирования установить агент.

Шаг №1: Авторизуюсь на системе где установлена центральная консоль Microsoft System Center 2012 R2 DPM Administrator Console под учетной записью которая имеет доступ к оснастке, у меня это Login: POLYGON\ekzorchik, запускаю оснастку
Management - Action - Install - Install agents — выбираю найденные серверные системы, к примеру srv-sql и нажимаю Add

Затем нажимаю Next, указываю административные данные на доступ:

• User name: ekzorchik
• Password: 712mbddr@
• Domain: polygon

и нажимаю Next, выбираю что после установке DPM агента нужно его активировать, а активация происходит после перезагрузки сразу или отложить перезагрузку (в ручную отправить систему в перезагрузку)

На заметку: Т.к. у меня это srv-sql, а на нем база данных DPM, то выбираю перезагрузку позже «No, I will restart the selected computers later«, кстати в зависимости от системы куда устанавливается агент не стоит бездумно перезагружать ее в автоматическом режиме если она не тестовая.

и нажимаю Next, Install

Итого агент успешно установлен

• Tasks: Install protection agent on srv-sql.polygon.local
• Results: Success

Вот теперь закрываю оснаску Microsoft System Center 2012 R2 DPM Administrator Console и перезагружаю систему srv-sql для активации агента.

Шаг №2: Проверяю, что оснастка Microsoft System Center 2012 R2 DPM Administrator Console видит работоспособность агента: Management -

из скриншота выше видно, что агент на системе srv-sql установлен и его статус OK.

Агент — это сервис:

• Service name: DPMRA
• Log on as: Local System account

работает по порту

• 5719/TCP - Канал данных DPM дабы выполнять операции DPM, к примеру синхронизации и восстановления.
• 5718/TCP - Канал данных DPM взаимодействия с координатором агента

Теперь когда агент установлен можно осуществлять настройку что резервировать, об этом в другой заметке дабы не нагромождать эту. На этом я прощаюсь, с уважением автор блога Олло Александр aka ekzorchik.

Как добавить Storage в DPM 2012 R2

Прежде чем приступить к настройке, что бекапировать через DPM 2012 R2 нужно в центральную консоль Microsoft System Center 2012 R2 DPM Administrator Console — это у меня на системе где имя хоста srv-dpm добавить диск на котором и будут располагаться файлы резервных копий. А после инициализировать диск, как Storage дабы сервис DPM мог с ним работать. Вот об этом маленьком шаге и пойдет речь в этой практической заметке.

Предварительные действия:

• Как развернуть System Center Data Protection Management 2012 R2
• Разворачиваем DPM 2012 R2 отдельно от SQL Server

Шаг №1: Т.к. я все тестирую сперва, а мой стенд располагается в виртуальных машинах моего полигона на базе Debian 10 + Proxmox 6, то для VM: srv-2012r2b через Web-интерфейс https://IP&DNS:8006 - user&pass - VM: 104 (srv-2012r2b) - Hardware - Add - Hard Disk — добавляю диск размером в 100Gb

• Bus: VirtIO Block
• Device: 2
• Storage: disk2 (что есть disk2 об этом в заметке)
• Disk size (GiB): 100

и нажимаю Add

А в системе он видится, как

Win + X -> Control Panel -> Administrative Tools - Computer Management - Computer Management (Local) - Storage - Disk Manager, через правый клик мышью на диске делаем его Online

Затем опять через правый клик выбираем Initilize Disk...

Устанавливаем что будет, как GPT (GUID Partition Table)

Затем опять через правый клик мышью на диску конвертируем его в Dynamic Disk...

Тем самым я подготовил диск к использованию сервисом Data Protection Managment

Шаг №2: Теперь нужно добавить данный динамический диск, как Storage в центральной консоли Microsoft System Center 2012 R2 DPM Administrator Console, запускаю ее на srv-dpm

Management - Disks -Add — в левой части окна отображаются доступные диски, выделяю свой единственный который в «Шаг №1» я добавил систему и нажимаю Add затем нажимаю OK

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

Хочу здесь и сейчас привести скриншот своего диска в продуктиве на который на работе бекапируются различные настроенные сервисы: File Server, SQL Database, Exchange Mailbox чтобы Вы ужаснулись…

Куча нарезанных кусочков различных бекапов, также на заметку это не просто два диска на 4Tb и на 2Tb — это Raid массивы на такой объем.

Как видите довольно просто сделать диск, как Storage в Server 2012 R2 DPM и этот диск после перевода его, как Storage пропадает из видимости если открыть «Мой компьютер» — это нормально.

Итого, заметка завершена, на этом я прощаюсь с уважением автор блога Олло Александр aka ekzorchik.

Резервное копирование SQL базы через DPM

Если честно говорить, то я был удивлен на новом рабочем месте, что базы данных от 1С 8.3 (SQL’ьные) бекапируются не через оснастку SQL Management Studio посредством Maintenance Plan. Об этом я уже публиковал пошаговую заметку если кто впервые на моем блоге.

• Контроль за удалением старых бекапов
• Что есть обслуживание базы данных

Здесь за резервное копирование отвечает продукт от Microsoft имя ему System Center 2012 R2 Data Protection Manager version: 4.2.1205.0. Я задался целью разобрать в опять же в шагах, как это настраивается и осуществляется бекапирование и восстановление.

Прежде чем приступить нужно

• Как развернуть System Center Data Protection Management 2012 R2
• Разворачиваем DPM 2012 R2 отдельно от SQL Server
• Как устанавливается агент Data Protection Management

Итак, агент DPM я установил на систему srv-sql

• srv-ad -> AD
• srv-dpm -> DPM
• srv-sql -> SQL

Шаг №1: Авторизуюсь на системе где установлена центральная консоль Microsoft System Center 2012 R2 DPM Administrator Console — это у меня srv-dpm

Protection - New и посредством мастера создаю Protection Group

Select protection group type: Servers, Next

Select group members: вижу свой домен polygon.local — вижу системы на которых есть агент DPM и вот моя srv-sql на которую я ранее установил агента, разворачиваю ее, перехожу в ALL SQL Servers - SRV-SQL — вижу базу под именем dbpolygon, отмечаю ее галочкой тем самым помещаю ее в создаваемую группу, а после нажимаю Next

Именую создаваемую группу которая у меня отвечает за резервное копирование базы данных с системы srv-sql:

Select data protection method:

и нажимаю Next

Select short-term goals:

Предопределяю сколько копий у меня будет

• Retention range: 5 days
• Express Full Backup: 23:00 Пн, Ср, Пт (т.е. полный бекап в 23 часа каждый понедельник, среду и пятницу, т.к. фирма работает в графике 5/2)

и нажимаю Next

Review disk allocation:

Резервирую место, хотя я оставляю все по дефолту полагаясь на мастера.

и нажимаю Next

Choose replica creation method:

DPM должен создать реплику резервируемого, оставляю по дефолту, пусть сейчас сделает. А в продуктиве лучше делать это вечером после работы дабы не нагружать сеть.

и нажимаю Next

Choose consistency check:

Проверка измененных синхронизируемых данных

и нажимаю Next

Summary:

Под итог предопределенных параметров посредством мастера

и нажимаю Create Group

Status:

Результат создание группы и реплики

Но увы не все работает сразу и как задумывалось, смотрю логи:

• Monitoring - (Alerts) All Alerts - Critical
• Occurred Since: 02.01.2010 19:17:44
• Affected Area: SRV-SQL\dbpolygon
• Computer: srv-sql.polygon.local
• Protection Group: Group_SQL
• Alert: Unable to configure protection

Ошибка ID 3170 говорит, что у задания нет полномочий на работу с SQL Instances и нужно, см. следующий шаг.

Шаг №2: Вот в логах Monitoring - (Alerts) Critical есть рекомендация, нужно на сервере srv-sql создать Login 'NT Service\DPMRA' с правами роли sysadmin.

На заметку: Когда будем создавать учетную запись не нажимаем Search

Страница General

• Login name: NT Service\DPMRA
• Windows authentication: отмечаем
• Default database: master
• Default language: English

Страница Server Roles

• Server roles: public & sysadmin

Страница Status

• Permission to connect to database engine: Grant
• Login: Enabled

Итого должно получиться вот так:

Шаг №3: Возвращаемся к окну с ошибкой в DPM - Monitoring - (Alerts) All Alerts - Critical и нажимаем на «Run configure protection job again...» и задание отработало, была снята резервная копия базы данных.

Шаг №4: Проверяю, что если что у меня есть бекап и я могу опираясь на календарь увидеть свои бекапы и восстановить базу данных:

Recovery - (Browse) Recoverable Data - polygon.local - SRV-SQL - All Protected SQL Instances - SRV-SQL - dbpolygon

вижу что есть бекап и его размер 48,39 Mb — а вот размер самой базы если смотреть через SQL Management Studio 5 Mb, вопрос почему размер так сильно увеличен.

Шаг №5: Чтобы восстановить базу нужно через правый клик мышью на базе в Recovery, выбрать сервер srv-sql, базу и нажать Recovery и далее через мастер, либо восстанавливаем в SQL Server, либо экспортируем ее как файлы

• dbpolygon.mdf
• dbpolygon_log.ldf

в необходимый каталог, пример:

Но скопированные файлы не просто буду в папке C:\1 сервера srv-sql, а будет сформирована структура каталогов:

\\srv-sql\c$\1\DPM_1-2-2020_19.29.2\SRV-SQL\dbpolygon\C-Volume\Program files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\DATA

а уже потом их можно добавить через SQL Management Studio:

srv-sql (SQL Server 11.0.7001 - POLYGON\ekzorchik)

Databases - Attach...

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

Занятно целых 14Gb, а это потому что при формировании группы я настройке оставил по дефолту и мастер зарезервировал место. Мне же достаточно этой заметкой было уяснить как DPM осуществляет резервное копирование баз SQL, а то поначалу было не понятно теперь же все прояснилось и был выявлен нюанс что на SQL сервере нужна специализированная учетная запись.

Замечу, я только учусь работать с DPM и не претендую на 100% правильность работы с DPM, так что заметки насчет DPM будут дополняться новыми знаниям.

На заметку: Как по мне излишне использовать DPM для бекапирования SQL, проще это делать средствами самого SQL. В нем можно настроить план обслуживания со всеми проверками, очистками и т.д + уведомление о ходе работы задания. (Оповещение о работе плана обслуживания)

На этом я пока прощаюсь, с уважением автор блога Олло Александр aka ekzorchik.

Как создать служебную учетную запись в Windows Server 2012 R2

И снова здрасьте, работа — а что есть лучше нового места работы — это новое место работы. Здесь я узнал (до этого никогда не использовал), что для нужд сервисов, т.е. от имени кого его(их) запускать введена компанией Microsoft технология управляемых служебных записей (аббревиатура MSA - Managed Service Accounts). Что самое интересное данная технология появилась еще на Windows Server 2008 R2, но я нигде ее не видел применения. А здесь она используется во всю. Раз так я тоже хочу ее применять, ведь это безопасность компрометации системных учетных записей.

Достоинства:

• У учетной записи MSA пароль сгенерирован системой и длина его 240 символов.
• Пароль меняется автоматические (по дефолту каждые 30 дней)
• Никак не сохраняется в системе

Требования к использованию:

• Уровень схемы AD = Windows Server 2012
• Права Domain Admins
• На контроллере домена должна присутствовать служба Microsoft Key Distribution Service (Служба распространения ключей)
• PowerShell-модуль для управления Active Directory

Служба задействующая gMSA (gMSA — Group Managed Service Accounts) поддерживается SQL Server 2008 R2 SP1, 2012;IIS; AD LDS; Exchange 2010/2013

На заметку: MSA pre-Windows Server 2012, Windows Server 2012 released gMSA (group Managed Service Accounts). gMSA should support SQL Serve.

• MSA – Managed Service Accounts (MSA)
• gMSA – Group Managed Service Account (gMSA)

В наличии домен контроллер

srv-dc.polygon.local (OC: Windows Server 2012 R2 Std)

Login: ekzorchik (Group: Domain Admins)

Шаг №1: Для создания учетной записи gMSA создаю корневой ключ KDS (KDS root key) на домен контроллере.

Win + R -> Command Prompt (Admin) - powershell

1234567891011

C:\Windows\system32\powershell PS C:\Windows\system32> Add-KdsRootKey -EffectiveImmediately Guid —- f88a882-11ad-d305-6c00f1708ea3 PS C:\Windows\system32>

Но как бы есть, но ключ заработает только через 10 часов, после окончания репликации. Так не пойдет, ускорим данный процесс:

1234567

PS C:\Windows\system32> Add-KdsRootKey -EffectiveTime ((get-date).addhours(-10)) Guid —- ffa75621-c6b0-1ebe-4f42-b12aeb2c73b4

Шаг №2: Проверяю, что корневой ключ KDS создался:

1	PS C:\Windows\system32> Get-KdsRootKey

Шаг №3: Чтобы создать учетную запись MSA. (ограничена одним каким-либо сервером)

Win + X -> Command Prompt (Admin)

123	C:\Windows\system32> powershell PS C:\Windows\system32> get-host

1	PS C:\Windows\system32> New-ADServiceAccount -Name msasql -RestrictToSingleComputer

• -Name -> имя создаваемой сервисной учетной записи
• -RestrictToSingleComputer -> Создание учетной записи действие которой ограничено одним каким-либо сервером

После чего проверяю, что в домене в сервисном OU=Managed Service Accounts появилась созданная учетная запись

Win + X – Control Panel – Administrative Tools – Active Directory Users and Computers

Задействуем снова консоль powershell и получим информацию о созданной учетной записи msasql:

123	PS C:\Windows\system32> Get-ADServiceAccount msasql (краткая информация) PS C:\Windows\system32> Get-ADServiceAccount msasql -properties * (расширенная информация)

Шаг №4: Чтобы создать учетную запись gMSA. (Group Managed Service Account). Групповая учетная запись, ограниченная применением группой, в которую включены несколько компьютеров:

1	PS C:\Windows\system32> New-ADServiceAccount -Name “gmsasql” -DNSHostName “srv-dc.polygon.local” -PrincipalsAllowedToRetrieveManagedPassword srv-sql$

• -Name "gmsasql" -> имя создаваемой учетной записи gMSA
• -DNSHostName -> имя которое для учетной записи будет в формате <name><domain suffix>

Т.к. по умолчанию период действия пароля ограничен 30 днями, можно его увеличить, к примеру до 90 дней перед автоматической сменой в примере выше указав ключ “-ManagedPasswordInvervalInDays” 90. (Кавычки не указываем)

Задействуем снова консоль powershell и получим информацию о созданной учетной записи gmsasql:

123	PS C:\Windows\system32> Get-ADServiceAccount gmsasql (краткая информация) PS C:\Windows\system32> Get-ADServiceAccount gmsasql -properties * (расширенная информация)

Также увидеть воочию созданную системную учетную запись нужно запустить оснастку Active Directory Users and Computer, нажать View - Advanced Features.

На заметку: Как учит Microsoft и Best Practice – один сервис = одна учетная запись, а не использовать одну везде и для всех случаев. Да удобно, но правильно так, к тому же обязательно составлять заметку как настроен сервис и какие учетные записи применяются.

Шаг №5: Помимо явного указания сервера к которому привязывается групповая системная учетная запись (gMSA) можно привязать к доменной группе которая включает в себя FQDN—имена систем:

1	PS C:\Windows\system32> dsadd group “CN=sqlserver,OU=IT,DC=polygon,DC=local”

после добавляем в эту группу систему srv-sql

12345

PS C:\Windows\system32> Uninstall-ADServiceAccount -Identity ‘gmsasql’ PS C:\Windows\system32> Set-ADServiceAccount -Identity gmsasql ` -PrincipalsAllowedToRetrieveManagedPassword sqlserver

Проверять к каким компьютерам или группе компьютеров привязана системная учетная запись gMSA:

1	PS C:\Windows\system32> Get-ADServiceAccount -Identity gmsasql -Properties PrincipalsAllowedToRetrieveManagedPassword

Шаг №6: Перед тем как прописать системную учетную запись (MSA) нужно установить командлеты PowerShell для работы Active Directory:

Т.к. одиночная и групповая системная учетная запись созданы выше теперь нужно прописать её(их) на конкретном сервере(рах):

Система: srv-sql.polygon.local (Windows Server 2012 R2 Std English)

Авторизуюсь на ней под учетной записью Login: ekzorchik Group:"Domain Admins"

Win + X -> Command Prompt (Admin) -> powershell

1	PS C:\Windows\system32> Install-WindowsFeature -Name “RSAT-AD-PowerShell”

На заметку: если добавить ключ «fl«, то вывод будет не в табличном режиме, а в строковом.

1	PS C:\Windows\system32> Install-ADServiceAccount -Identity “msasqm”

После обязательно проверяем работу учетной записи:

1	PS C:\Windows\system32> Test-ADServiceAccount -Identity “msasqm”

• True – статус означает, что учётная запись установлена на сервере.
• False – статус означает, что учётная запись не привязана в AD к системе на которой выполняем проверку

У меня статус True.

1	PS C:\Windows\system32>

Если открыть свойства системы srv-sql и перейти во вкладку Attribute Editor в атрибуте msDS-HostServiceAccount будет привязка к системной учетной записи CN=msasql,CN=Managed Service Accounts,DC=polygon,DC=local

Далее нужно на системе srv-sql через gpedit.msc указать что системную учетную запись msasql можно задействовать в роли указания, как запуск службы от ее имени.

Win + R -> gpedit.msc & Win + X – Run -> gpedit.msc – Local Computer Policy – Computer Configuration – Windows Settings – Security Settings – Local Policies – User Rights Assignment

• Log on as a batch job: прописываем системную учетную запись
• Log on as a service: прописываем системную учетную запись

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

Шаг №7: Как прописать групповую системную учетную запись (gMSA) нужно установить командлеты PowerShell для работы Active Directory на сервер srv-sql и отредактировать локальную групповую политику.

Win + X – Command Prompt (Admin) – PowerShell

123	PS C:\Windows\system32> New-ADServiceAccount -Name “gmsasql” -DNSHostName “srv-dc.polygon.local” -PrincipalsAllowedToRetrieveManagedPassword sqlserver PS C:\Windows\system32> Install-WindowsFeature -Name “RSAT-AD-PowerShell”

Шаг №8: Чтобы найти все учетные записи MSA & gMSA в домене, поиск ведем под учетной записью вхожей в группу Domain Admins на домен контроллере:

Win + X – Command Prompt (Admin) – PowerShell

1	PS C:\Windows\system32> Get-ADServiceAccount -Filter *

Шаг №9: Как сбросить пароль на системную учетную запись (Выполняем под учетной записью вхожей в группу Domain Admins на той системе на которой используется системная учетная запись):

Win + X – Command Prompt (Admin) – PowerShell

123	PS C:\Windows\system32> Get-ADServiceAccount -Identity msasql -Properties passwordlastset | select Name,ObjectClass,PasswordLastSet | ft PS C:\Windows\system32> Reset-ADServiceAccountPassword -Identity msasql

Если запустить эту команду на другой системе с которой нет привязки, то получите ошибку вида «Referenced service account is not installed on this computer.”

Шаг №10: Чтобы удалить системную учетную запись или групповую.

Удаляем учетную запись MSA с серверов (к примеру на srv-sql), где она была проинсталлирована командой Install-ADServiceAccount:

1234567891011

PS C:\Windows\system32> hostname srv-sql PS C:\Windows\system32> Test-ADServiceAccount -Identity “msasql” True PS C:\Windows\system32> Test-ADServiceAccount -Identity “gmsasql” True

1234567

PS C:\Windows\system32> Uninstall-ADServiceAccount msasql PS C:\Windows\system32> Test-ADServiceAccount -Identity “msasql” False WARNING: The Managed Service Account msasql is not linked with any computer object in the directory

После проверяем что в свойствах компьютера srv-sql, вкладка Attribute Editor (На домен контроллере) атрибут msDS-HostServiceAccount принял дефолтное значение <not set>, т.е. не назначено.

(on srv-dc.polygon.local)

123456789

PS C:\Windows\system32> Remove-ADServiceAccount -Identity msasql Are you sure you want to perform this action? Performing the operation “Remove” on target “CN=msasql,CN=Managed Service Accounts,DC=polygon,DC=local”. Нажимаю на клавиатуре клавишу “A” и нажимаю <ENTER> PS C:\Windows\system32>

Удаляем (из под доменной учетной записи с правами Domain Admins) учетную запись gMSA с серверов (к примеру на srv-sql) указанных явно или назначенную на доменную группу с вхожими в нее системами:

1234567

PS C:\Windows\system32> Test-ADServiceAccount -Identity “gmsasql” True PS C:\Windows\system32> Uninstall-ADServiceAccount gmsasql PS C:\Windows\system32> Remove-ADServiceAccount -Identity ‘gmsasql’

Работу заметки на Windows Server 2016 & Server 2019 не проверял, просто пока нет надобности.

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

Пока на этом, собственно, все, с уважением автор блога Олло Александр aka ekzorchik.

Создаем информационную базу через авторизацию gMSA

Сегодня я покажу один недокументированный способ использования связки кластера 1С при создании информационной базы подключения к SQL серверу. Не нужно указывать логин SQL\sa на подключение к серверу, плюс службы SQL и Агента 1С работают из под системной групповой учетной записи (gMSA). Это безопасность и единичность настройки. Не нужно создавать отдельные учетные записи, давать им доступ на сервер помещая их в группу локальных администраторов.

Тестовые системы приближенные в настоящий момент используемые у меня в боевом виде

• srv-ad.polygon.local (OS: Windows Server 2012 R2 Std English)
• srv-1с.polygon.local (OS: Windows Server 2012 R2 Std English)
• srv-sql.polygon.local (OS: Windows Server 2012 R2 Std English)

• Login: ekzorchik
• Password: 712mbddr@
• Group: "Domain Admins"

Шаг №1: Создаю на домен контроллере системную групповую учетную запись (gmsasql) и нацеливаю ее на группу sqlserver в которую включены компьютеры: srv-1c & srv-sql

Win + R -> Command Prompt (Admin)

123456789

C:\Windows\system32> powershell PS C:\Windows\system32> Add-KdsRootKey -EffectiveTime ((get-date).addhours(-10)) PS C:\Windows\system32> Get-KdsRootKey PS C:\Windows\system32> New-ADServiceAccount -Name “gmsasql” -DNSHostName “srv-dc.polygon.local” PS C:\Windows\system32> Set-ADServiceAccount -Identity gmsasql -PrincipalsAllowedToRetrieveManagedPassword sqlserver

1	PS C:\Windows\system32> Get-ADServiceAccount -Identity gmsasql -Properties PrincipalsAllowedToRetrieveManagedPassword

Шаг №2: На системы srv-sql & sql-1c устанавливаю коммандлеты для работы с групповой системной учетной записью gmsasql:

Win + R -> Command Prompt (Admin)

123456789

C:\Windows\system32> powershell PS C:\Windows\system32> Install-WindowsFeature -Name “RSAT-AD-PowerShell” PS C:\Windows\system32> shutdown /r/ t/3 PS C:\Windows\system32> Test-ADServiceAccount -Identity “gmsasql” True

Шаг №3: На системах srv-sql & srv-1c посредством локальной групповой политики даю права на запуск как сервис и при использовании скрипта использовать системную групповую учетную запись. Можно кстати создать единую групповую политику и нацелить ее на эти две системы.

Win + R -> gpedit.msc & Win + X – Run -> gpedit.msc – Local Computer Policy – Computer Configuration – Windows Settings – Security Settings – Local Policies – User Rights Assignment

• Log on as a batch job: добавляем системную учетную запись, т.е. POLYGON\gmsasql$
• Log on as a service: добавляем системную учетную запись, т.е. POLYGON\gmsasql$

или как единая GPO (on srv-dc)

Win + X - Control Panel - Administrative Tools - Group Policy Management - Group Policy Management - Forest: polygon.local - Domains — и через правый клик мышью на polygon.local выбираю "Create a GPO in this domain, and Link it here..."

• Name: GPO_GMSA
• Source Started GPO: (none)

Затем делаю привязку по безопасности к группе в которую включены две системы: srv-sql & srv-1c

и что еще важно во вкладку Delegation переходим и добавляем группу «Authenticated Users» права Read, должно быть вот так:

Вот скриншот настроенной групповой политики:

Computer Configuration - Policies - Windows Settings - Security Settings - Local Policies - User Rights Assignment

• Log on as a batch job: POLYGON\gmsasql$
• Log on as a service: POLYGON\gmsasql$

После на системах srv-sql & srv-1c делаю gpupdate /force и проверяю что политика применилась.

Win + R -> Command Prompt (Admin)

123	C:\Windows\system32> gpupdate /force C:\Windows\system32> shutdown /r /t 3

Шаг №4: Устанавливаю SQL Server из образа SW_DVD9_SQL_Svr_Enterprise_Edtn_2012w_SP4_64Bit_English_MLF_X21-43470.iso на srv-sql.

Описывать все шаги нет смысла я остановлюсь на тех что необходимые для указания что от имени групповой системной учетной записи нужно сделать запуск, а так за основу можно взять заметку «Как установить SQL Server на Server 2012 R2 Standard»

к примеру отмечаю компоненты:

• Database Engine Services
• Management Tools - Basic
• Management Tools - Complete

Так должно быть чтобы использовать групповую системную учетную запись: (Колонку Password не трогаем и не заполняю, пароль придет с домен контроллера)

Затем указываю, что буду использовать смешанную аутентификацию и добавляю групповую учетную запись:

После того, как SQL Server будет установлен нужно для Ваших баз которые будут подключаться в кластер 1С сделать чтобы у них владельцем значилась групповая системная учетная запись.

Шаг №5: Устанавливаю компонент «Администрирование сервера 1С:Предприятие» из пакета windows_8_3_16_1063 (x86) на srv-1c

Устанавливаем компоненты:

• 1С: Предприятие
• Сервер 1С: Предприятие
• Администрирование сервера 1С:Предприятие
• Интерфейс на различных языках: Русский и Английский
• Дополнительные функции администрирования

сперва указываем что нужно создать пользователя USR1CV8 и задаем ему пароль, к примеру 712mbbdr@

А затем запустить оснастку Services

Win + X - Control Panel - Administrative Tools - Services и изменить запуск от имени созданной учетной записи .\USR1CV8 у сервиса: «Агент Сервера 1С:Предприятия 8.3» вкладка «Log On» на Browse - Locations: отмечаем Entire Directory и вводим наименование доменной учетной записи:

Enter the object name to select: gmsasql и нажимаем Check Names, поля Password & Confirm password: очищаем и нажимаем Apply - OK

Перезапускаем службу «Агент Сервера 1С:Предприятия 8.3«: либо через оснастку, либо через консоль командной строки.

Шаг №6: Запускаю оснастку «Администрирование серверов 1С:Предприятия NEW» на сервере srv-1c которую установил(и) в «Шаг №5«, но увы оснастка не запускается:

Решение: Нужно дать права групповой системной учетной записи полные права на каталог: «C:\Program Files (x86)\1cv8\srvinfo»

через правый клик по каталогу srvinfo выбираю Properties, затем вкладка «Security» — Edit - Add — нажимаю на Object Types... и отмечаю что поиск указываемой учетной записи вести еще в Service Accounts (Сервисных аккаунтах) и нажимаю Ok, затем ввожу наименование групповой системной учетной записи gmsasql и нажимаю Check Names

И после того как ее добавил отмечаю что у нее должны быть полные права на данный каталог.

Для активации изменений также нужно перезапустить службу «Агент Сервера 1С:Предприятия 8.3» и только после проделанных действий выше получается возможным запуск службы "Агент Сервера 1С:Предприятия 8.3" от имени групповой системной учетной записи.

Но как же все таки запустить оснастку «Администрирование серверов 1С:Предприятия NEW» на сервере srv-1c?

Решение: нужно зайти в каталог «C:\Program Files (x86)\1cv8\8.3.16.1063\bin» и через правый клик мышью на bat—файле RegMSC.bat запустить его, как «Run as administrator» в ответ будет окно где произведена регистрация сервера и dll библиотек.

И вот теперь оснастка «Администрирование серверов 1С:Предприятия NEW» на сервере srv-1c успешно запускается:

Шаг №7: Создаю информационную базу в оснастке «Администрирование серверов 1С:Предприятия NEW»

И указываю параметры подключения к SQL серверу где у меня создана база/восстановлена из бекапа:

• Имя: 1ctest
• Описание: 1ctest
• Защищенное соединение:
• Сервер базы данных: srv-sql.polygon.local
• Тип СУБД: MS SQL Server
• База данных: 1ctest
• Пользователь сервера БД: не указываем
• Пароль пользователя БД: не указываем
• Разрешить выдачу лицензий сервером 1С:Предприятия: Да
• Язык (Страна): русский (Россия)
• Смещение дат: 2000
• Создать базу данных в случае ее отсутствия: не отмечаю галочкой
• Установить блокировку регламентных задаий: не отмечаю галочкой

Но не без ложки дегтя не бывает — инициализация создания информационной базы вываливается в ошибку что не установлен Microsoft SQL Server Native Client

Разбираюсь что к чему.

Через поисковик Google ввожу «SQL Server Native Client» и скачиваю ENU\x64\sqlncli.msi

После проделываю еще раз создание информационной базы и получаю уведомление что информационная база 1ctest уже зарегистрирована в кластере серверов 1С:Предприятия

Проверяю, а действительно ли есть подключение — ответ да есть.

если запустить 1С клиент и настроить подключение к текущему кластеру 1С и базе на нем, то будет ли произведено подключение?

Нажимаю на «Конфигуратор»

и подключение успешно к базе

Шаг №8: Все выше заработало, т.к. у меня сервисы на обоих серверах запускаются от имени групповой системной учетной записью, по сути у нее права как у системы.

На заметку: У меня кластер 1С не лицензионный, а в рамках тестовой площадки был крякнутый и найден на просторах интернета.

Итого: Я разобрал, как связать кластер 1с и сервер базы данных не указываю каждый раз пароль на учетную запись sa. К тому же не раскрываю ее пароль для сотрудников и главное 1С-администраторов.

Заметка работоспособна. На этом у меня всё, с уважением автор блога Олло Александр aka ekzorchik.

План обслуживания SQL базы 1C v7.7

Да у нас в конторе до сих пор работает в качестве основной базы данных это 1C v7.7 и она хоть не файловая, а SQL (Версия SQL 12.0.6329.1). Для меня если честно это что-то новое, вот файловая база – это я понимаю, имел дело. Даже проводил конвертацию в SQL «Переезд файловой базы 1с на sql работу». Ничего я разберу как она настроена. Просто я люблю, когда знаю и умею все сделать, что сделано до меня дабы знать, как восстанавливать, анализировать поведение и последующую модернизацию. Ниже перечень шагов, которые я проделал по созданию планов обслуживания на сервере в домене для SQL базы которая используется в 1C v7.7:

Шаг №1: Авторизуюсь на системе Windows Server 2012 R2 Std под учетной записью доменного администратора

Шаг №2: Запускаю оснастку Microsoft SQL Server Management Studio, авторизуюсь, у меня используется смешанная аутентификация.

Шаг №3: Создаю Maintenance Plan – где этапы соединены между собой «Зеленой линией»

Name Maintenance Plan: SQLMaintenance

Этап: Check Database Integrity

• Connection: Local server connection
• Database(s): All user databases (excluding master, model, msdb, tempdb)
• Include indexes: отмечаю галочкой

Этап: Rebuild Index Task

• Database(s): All user databases (excluding master, model, msdb, tempdb)
• Object: Tables and views
• Free space options: Default free space per page

Этап: Update Statistics

• Connection: Local server connection
• Database(s): All user databases (excluding master, model, msdb, tempdb)
• Update: All existing statistics
• Scan type: Full scan

Этап: Clean Up History

• Connection: Local server connection
• Backup and restore history: отмечаю галочкой
• SQL Server Agent job history: отмечаю галочкой
• Maintenance plan history: отмечаю галочкой
• Remove historical data older history: 4 Week(s)

Настраиваю для этого плана планировщик:

• Schedule type: Recurring
• Enable: отмечаю галочкой
• Occurs: Weekly
• Recurse every: 1 (week(s) on)
• Monday, Tuesday, Wednesday, Thursday, Friday: отмечаю галочкой
• Occurs once at: 1:00:00

Name Maintenance Plan: SQLReorganization

Этап: Reorganize Index

• Connection: Local server connection
• Database(s): All user databases
• Compact large objects: отмечаю галочкой

Настраиваю для этого плана планировщик:

• Schedule type: Recurring
• Enabled: отмечаю галочкой
• Occurs: Daily
• Recurs every: 1 (days)
• Occurs every: 1 hours
• Starting at: 8:00:00
• Ending at: 20:00:00
• No end date: отмечаю

Шаг №4: Чтобы получать информацию по работе данных «Планов обслуживания» я задействую заметку «Уведомление о событиях бекапа на SQL Server 2014» посредством которой получаю уведомления на всю работу SQL Server на данном сервере.

Итого я для себя на будущее составил инструкцию как на текущем месте обслуживается SQL базы для версии 1C версии 7.7.

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

На этом у меня всё, с уважением автор блога Олло Александр aka ekzorchik.

Клиент 1Сv7.7 в режиме Конфигуратор из под пользователя

Задача: Как заставить клиент 1Сv7.7 подключаться в режиме «Конфигуратор» к базе из под пользователя.

Странно я использую клиент 1С да еще версии 7.7 — это же древность, но нет моя ошибка. Не обязательно гнаться за самым новым если и старое работает в продуктивной среде и бизнес не в упадке, а дышит ровно. Мне правда до бизнеса с моей системно-административной точки зрения важно, чтобы вся вверенная мне инфраструктура работала и не было факапов. Что я и делаю.

Тут у меня спросили не знаю ли я, как можно клиент 1С 7.7 запускать в режиме «Конфигуратор» из под обычного пользователя потому как если запускать его в системе Windows 8.1, Windows 10 (у меня используется), то он крашится ошибками:

Что делается:

В системе авторизованы с правами локального пользователя не важно рабочая станция или доменная:

• C:\Program Files (x86)\1c77\bin\1cv7s.exe
• В режиме: Конфигуратор
• Информационные базы: выбираю базу и нажимаю "Ок"

в ответ ошибки:

1234567

При загрузке плагина “C:\Program Files (x86)\1Cv77\bin\config\SciColorer.dll” не удалось создать объект “SciColorer.SciColorerPlugin”Код ошибки 0x800401F3Недопустимая строка с указанием класса При загрузке плагина “C:\Program Files (x86)\1Cv77\bin\config\telepat.dll” не удалось создать объект “Telepat.Plugin”Код ошибки 0x800401F3Недопустимая строка с указанием класса

На заметку: Вариант запуска от имени администратора каждый раз не рассматриваю.

Решение:

По умолчанию в Windows на папки «Program Files» и «Program Files (x86)» стоят права «только чтение«.

А у обычного пользователя нет прав на запись в данный каталог, даже если я дам права на каталог 1Cv77 это не поможет, т.к. права наследуются от «Program Files (x86)«.

• Копирую всю папку или устанавливаю в корень логического диска C: — получается вот так c:\1cv77
• Даю права на запись пользователю в каталог C:\1cv77 под которым я сейчас авторизован в системе:

• Первый раз запускаем C:\1cv77\bin\1cv7s.exe через правый клик «Запуск от имени администратор«. Затем выбираем «Конфигуратор» и базу и нажимаем «ОК«

подключение прошло, выходим Файл - Выход

• Запускаю теперь под пользователем через двойной клик по 1cv7s, выбираю «В режиме": Конфигуратор и я подключаюсь без ошибок выше.
• Делаю Logoff (под пользователем alektest)/Logon (под пользователем alektest) и запускаю C:\1cv77\bin\1cv7s.exe захожу в конфигуратор к базе и ошибок нет.
• Перезагрузил систему и также захожу в конфигуратор к базе ошибок нет.
• Работает, проверил на работе. Теперь на рабочий стол выношу ярлык ссылающийся на c:\1cv77\1cv7s.exe

Итого, я решил небольшую практическую задачку и получил удовольствие. На этом я прощаюсь, с уважением автор блога Олло Александр aka ekzorchik.

Доступ к RDP через авторизацию RADIUS

Т.к. многие организации для удаленного подключения сотрудников из вне к ресурсам компании используют «Проброс порта«, как правило до терминального сервера, но я хочу рулить доступом. А доступ может быть организован через Remote Desktop Gateway — это не просто проброс RDP порта, но еще защита. Защита — использует только один порт входа из вне в вашу локальную сеть, не зная куда через Remote Desktop Gateway можно подключиться и не авторизовавшись на нем подключения не будет. К тому же чем меньше портов во вне открыто нет лучше. Серверная система на базе Windows Server 2012 R2 Std Eng

Тестовый стенд на котором данная заметка прорабатывается — это Debian 10 + Proxmox 6

Gateway:

• srv-gw.polygon.com
• IP (LAN): 10.90.90.2/24
• IP (WAN): 172.33.33.11/24

Domain Controller:

• srv-ad.polygon.com (AD,DNS,DHCP,)
• IP (LAN): 10.90.90.3

Terminal Server:

• srv-ts.polygon.com
• IP (LAN): 10.90.90.10

RDG:

• srv-rdsg.polygon.com
• IP (LAN): 10.90.90.11

Workstation:

• W10X64.polygon.com
• IP (LAN): 10.90.90.12

Тестовый стенд на базе гипервизора Debian 10 + Proxmox 6 с задействованным железом:

• Motherboard: Gigabyte 970A-DS3P
• RAM: CORSAIR Vengeance CMZ8GX3M1A1600C10 DDR3 — 8Гб 1600, DIMM, Ret x4
• CPU: AMD FX(tm)-6300 Six-Core Processor
• HDD: SSD накопитель SILICON POWER M-Series SP512GBP34A80M28 512Гб, M.2 2280, PCI-E x4, NVMe, WDC_WD5003ABYX-0, WD Blue WDS100T2B0A 1Тб, 2.5" SATA III

Шаг №1: На определенном железе поднят гипервизор Debian 10 + Proxmox 6

Шаг №2: Создана VM которая будет шлюзом сети домена во вне, в качестве оси будет выступать PfSense 2.4.4.

Шаг №3: На VM которая является домен контроллером под управлением Windows Server 2012 R2 Std English

VM ID: 101 (srv-s2012r2a)

srv-dc.polygon.com 10.90.90.3/24

Роли: Active Directory,DNS,DHCP

• Создаю доменную группу RDPVPNTS (в нее включен srv-ts)
• Создаю доменную группу RDPVPNAllow (в нее включен alektest)

Шаг №4: Поднимаю еще одну VM которая будет являться шлюзом, т.е. система (srv-rdsg.polygon.com) с ролью

Win + X - Control Panel - View by: Category - Small icons - Administrative Tools - Server Manager - Add roles and features — отмечаю галочкой роль Remote Desktop Services, затем галочкой Remote Desktop Gateway, соглашаюсь на установку необходимых дополнений в которые входит роль:

• Network Policy and Access Services
• Web Server (IIS)

и нажимаю «Add Features«, далее нажимаю везде «Next«, а после «Install»

Шаг №5: Настраиваю работу NPS в паре с Remote Desktop Gateway (RDGW)

srv-rdsg.polygon.com

Win + X - Control Panel - Administrative Tools - Remote Desktop Services - Remote Desktop Gateway Manager - RD Gateway Manager - SRV-RDSG (Local) - Policies (сконфигурируем авторизованные подключения) — Connection Authorization Policies - Create New Policy - Wizard — выбираю Create a RD CAP and a RD RAP (recommended) и нажимаю Next

• Type a name for the RD CAP (задаем имя шаблону): RDPVPN

и нажимаю Next

• Select at least one supported Windows authentication method: Password
• User group membership (required): Add Group... - добавляю группу RDPVPNAllow

и нажимаю Next

• Device Redirection: Enable device redirection for all client devices

и нажимаю Next, Next (Session Timeout), Next

• Type a name for the RDP RAP (задаем имя шаблону): RDPVPNTO

и нажимаю Next

• User Groups: подставляется ранее добавленная группа POLYGON\RDPVPNAllow

и нажимаю Next

• Network Resources: (Select an Active Directory Domain Services network resource group) Browse - если не указать, то через сервис Remote Desktop Gateway можно будет подключаться из вне к любой системе, но я же ограничиваю доступ к группе в которую у меня включен Terminal Server (srv-ts.polygon.local): RDPVPNTS

и нажимаю Next

• Allowed Ports: Allow connections only to port 3389

и нажимаю Next, Finish

Политики созданы:

и нажимаю Close

Шаг №6: Дабы активировать Remote Desktop Gateway необходим сертификат:

Win + X - Control Panel - Administrative Tools - Remote Desktop Services - Remote Desktop Gateway Manager - RD Gateway Manager — через правый клик мышью на SRV-RDSG (Local) открываю Properties (Свойства), перехожу на вкладке SSL Certificate

сейчас нет сертификата

• Create a self-signed certificate: нажимаю на Create and Import Certificate, и нажимаю «ОК«

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

нажимаю Apply для его применения к серверу srv-rdsg.polygon.com

нажимаю Apply для его применения к серверу srv-rdsg.polygon.com

Шаг №7: Можно увеличить безопасность изменив порт подключения через Remote Desktop Protocol, по умолчанию он 443, изменяем он в окне Properties вкладка Transport Settings. Я пока оставлю по дефолту.

Шаг №8: Проверяю, что из доменной сети могу обратиться на 443/tcp

https://srv-rdsg.polygon.com

Так Web-сервер IIS работает.

Шаг №9: Произвожу установку терминального сервера на srv-ts.polygon.com опираясь на заметку «Терминальный сервер в Server 2012 R2»

после открываю

Win + X - Control - Administrative Tools - Computer Management - Computer Management (Local) - System Tools - Local Users and Groups - Group — и в группу RDS Management Server добавляю систему на которой будет развернута роль Remote Desktop Gateway, у меня это srv-rdsg.polygon.com

Win + X - Control - Administrative Tools - Computer Management - Computer Management (Local) - System Tools - Local Users and Groups - Group - и в группу Remote Desktop Users добавляю группу RDPVPNAllow

Шаг №10: Теперь, как же подключиться к терминальному серверу если точка входа это система с ролью Remote Desktop Gateway

К примеру из локальной сети

W10X64.polygon.com — авторизуюсь на ней под учетной записью alektest, запускаю Win + R -> mstsc.exe

вкладка Общие

• Компьютер: srv-ts.polygon.com
• Пользователь: alektest

вкладка Дополнительно

перехожу в «Параметры«, отмечаю «Использовать следующие параметры сервера шлюза удаленных рабочих столов»

• Имя сервера: srv-rdsg.polygon.com
• Метод входа: Выбрать позднее
• Не использовать сервер шлюза удаленных рабочих столов для локальных адресов: снимаю галочку
• Использовать мои учетные данные шлюза удаленных рабочих столов для удаленного компьютера: отмечаю галочкой

и нажимаю «ОК«, для удобства сохраняю настройки подключения на рабочий стол, как srv-ts.rdp и нажимаю «Сохранить«. Затем нажимаю «Подключить«.

Окно говорит, что сейчас будет инициализировано подключение: подтверждаю нажатием на «Подключить»

Далее нужно указать учетные данные для подключения к srv-rdsg.polygon.com

• Имя пользователя: alektest
• Пароль: Aa1234567
• Запомнить меня: отмечаю галочкой

и нажимаю «ОК»

Происходит инициализация подключения

в ответ окно «Компьютеру не удается проверить удостоверение шлюза удаленных рабочих столов «srv-rdsg.polygon.com«. Подключаться к серверам без удостоверение небезопасно. Обратитесь за помощью к администратору сети.»

А все потому что сертификат который я создал для сервера srv-rdsg.polygon.com самоподписанный и не распространен на все клиентские станции домена.

Шаг №11: Как добавить самоподписанный сертификат сервера srv-rdsg.polygon.com на клиентские станции, я буду использовать помощь GPO, копирую его с системы srv-rdsg.polygon.com на srv-dc.polygon.com к примеру в каталог C:\1

srv-dc.polygon.local - Win + X - Control Panel - Administrative Tools - Group Policy Management — и создаю GPO: RDPVPNTS, нацелена она на

• Location: polygon.com
• Security Filtering: Authentication Users

после редактирую политику

Computer Configuration - Policies - Windows Settings - Security Settings - Public Key Policies — и добавляю данный сертификат в «Trusted Publishers» — Import — указываю его.

Computer Configuration - Policies - Windows Settings - Security Settings - Public Key Policies — и добавляю данный сертификат в «Trusted Root Certification Authorities» — Import — указываю его.

Итог настроенной политики

Теперь когда рабочие станции и узлы домена polygon.com сделаю перезагрузку и политика к ним применится подключение к терминальному серверу через шлюз будет возможно.

Шаг №12: Проверяю, что на клиентской рабочей станции W10X64 (Version 10.0.18362.356) сертификат присутствует

Win + R - control - Свойства браузера - вкладка "Содержание" - Сертификаты, тут нужно проверить наличие сертификата в «Доверенные корневые центры сертификации» и «Доверенные издатели»

у меня сертификат присутствует

Шаг №13: Проверяю, что теперь с добавленным сертификатом на клиентской рабочей станции W10X64 (Version 10.0.18362.356) я могу подключиться к терминальному серверу. Увы подключение не проходит

Разбираюсь почему?

Я забыл добавить в группу RDPVPNAllow учетную запись alektest

Шаг №14: Более вдумчиво проанализировал ошибку и пришел к выводу, что мой сервер аутентификации srv-rdsg.polygon.com не зарегистирирован в Active Directory

Win + X - Control Panel - Administrative Tools - Network Policy Server и через правый клик мышью на NPS (Local) регистрирую его нажатием на Register server in Active Directory, OK, OK

Шаг №15: Возвращаюсь к «Шаг №10«, запускаю сохраненный ярлык на рабочем столе srv-ts.rdp и нажимаю «Подключить«. Подключение проходит успешно.

если же просто создать подключение к srv-ts без указания шлюза, то соединение будет также установлено, т.к. группу RDPVPNAllow состоит в группе Remote Desktop Users, но это уже обычная авторизация в доменной сети.

Шаг №16: У системного администратора при использовании RD Gateway Manager появился инструмент посредством которого он может отключать удаленные сеансы прошедшие через через него, смотреть кто подключается, нет ли лишних.

Win + X - Control Panel - Administrative Tools - Remote Desktop Services - Remote Desktop Gateway Manager - RD Gateway Manager - SRV-RDSG (Local) - Monitoring

Итого всей этой заметкой я разобрался кстати снова, я когда ее только начал оформлять вспомнил, что уже делал такое, но использовал везде Windows Server 2016. Итог теперь в любой организации где я буду работать, то обязательно буду делать доступ из вне к Windows системам через роль Remote Desktop Gateway. На этом я прощаюсь, с уважением автор блога Олло Александр aka ekzorchik.

Статистика RDP авторизаций Terminal Server & Remote Desktop Gateway

Задача: Нужно с системы с ролью Remote Desktop Gateway формировать статистику кто на ней авторизовался через RDP соединение, как при работе связки извне, так и в пределах локальной сети.

Роль Remote Desktop Gateway настраивается по разобранной в лабораторных условиях заметке: «Доступ к RDP через авторизацию RADIUS» которая является полным сопоставление того что сейчас у меня на рабочем месте. Просто чтобы на работе сервис работал как надо все разбираюсь от и до со всеми нюансами.

Шаг №1: Т.к. у меня все системы в домене то посредством общей групповой политики Default Domain Policy активирую запись только полезных логов:

Srv-dc.polygon.com – Win + X – Control Panel – Administrative Tools – Group Policy Management – Group Policy Management – Forest: polygon.com – Domains – polygon.com – через редактирование Default Domain Policy – Default Domain Policy [SRV-DC.POLYGON.COM] Policy – Computer Configuration – Policies – Windows Settings – Security Settings – Local Policies – Audit Policy –

• Audit account logon events (аудит входа в систему): Success, Failure
• Audit logon events (аудит событий входа в систему): Success, Failure
• Audit privilege user: Success, Failure

Srv-dc.polygon.com – Win + X – Control Panel – Administrative Tools – Group Policy Management – Group Policy Management – Forest: polygon.com – Domains – polygon.com – через редактирование Default Domain Policy – Default Domain Policy [SRV-DC.POLYGON.COM] Policy – Computer Configuration – Policies – Windows Settings – Security Settings – Local Policies – Advanced Audit Policy Configuration – Audit Policies – Logon/Logoff

• Audit Account Lockout: Failure
• Audit Logoff: Success
• Audit Logon: Success and Failure
• Audit Other Logon/Logoff Events: Failure

После того, как все доменные компьютеры перезагрузятся, я посредством шагов ниже смогу снимать статистику RDP подключений.

Шаг №2: Качаю скрипт посредством разобранной ранее заметки: «Скачать файл встроенными средствами Windows»

От компании Microsoft посредством которого можно распарсить логи моего терминального сервера под управлением Windows Server 2012 R2 Std (Version 6.3.9600)

Win + X -> Command Prompt (Admin)

1234567891011

C:\Windows\system32>if not exist c:\Script mkdir c:\Script C:\windows\system32> cd /d c:\Script c:\Script>bitsadmin /transfer RDPConnectionParser.ps1 /download /priority normal https://gallery.technet.microsoft.com/Remote-Desktop-Connection-3fe225cd/file/136148/7/RDPConnectionParser.ps1 c:\Script\RDPConnectionParser.ps1 DISPLAY: ‘RDPConnectionParser.ps1’ TYPE: DOWNLOAD STATE: TRANSFERRED PRIORITY: NORMAL FILES: 1 / 1 BYTES: 2555 / 2555 (100%) Transfer complete.

Шаг №3: Разрешаю выполнение PowerShell скриптов:

Win + X -> Command Prompt (Admin)

12345678910111213

C:\Windows\system32> powershell PS C:\Windows\system32> set-executionpolicy Unrestricted PS C:\Windows\system32> cd C:\Script PS C:\Script> .\RDPConnectionParser.ps1 Writing File: C:\Users\aolloadm\Desktop\2020-01-27T09.21.19_RDP_Report.csv Done! PS C:\Script>

Шаг №4: Смотрю как выглядит лог, можно открыть его через Notepadd++ или же Excel, но вывод если в Excel не в колонках.

Шаг №5: Нужно отформатировать:

А) Открыв его в блокноте сохраняю как файл расширением txt

Б) Запускаем Excel, создаем новую книгу, файл – Открыть и указываем сохраненный ранее файл с расширением txt

Полученный результат:

По сути это анализ логов:

• Event View (Local): Applications and Services Logs – Microsoft – Windows – TerminalServices – LocalSessionManager – Operational

Но скрипт не анализирует лог

• Event Viewer\Applications and Services Logs\Microsoft\Windows\TerminalServices-RemoteConnectionManager

И

• Event Viewer\Windows Logs\Security (Event ID: 4624, Logon Type: 10)

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

• Maximum log size (KB): 65536
• When maximum event log size is reached: Archive the log when full, do not overwrite events

На заметку: В зависимости от того как разрастаются логи («%SystemRoot%\System32\Winevt\Logs\*») уже либо копировать их на удаленную систему либо удалять через планировщик.

На заметку: Может стоит настроить централизованный сбор логов на подобии LogAnalyzer (я его когда-то использовал).

Шаг №6: Задача: Сформировать отчет тех, кто подключался к терминальному серверу с 24.01.2020

1	PS C:\Script> .\RDPConnectionParser.ps1 -StartTime “January 24, 2020”

Шаг №7: Но, наверное, не правильно снимать лог с самого терминального сервера, т.к. IP Address – это откуда было произведено подключение, т.е. те компьютеры, которые в правиле Remote Desktop Gateway предопределены кто могут. Значит нужно сформировать точно такой же лог с сервера с ролью Remote Desktop Gateway (это на srv-rdsg.polygon.com):

Проделываю шаги «Шаг №1» & «Шаг №2», да вывод есть. Но вот только у меня же он выставлен в интернет через правило проброс порта при подключении из вне на WAN-IP:443 -> srv-rdsg.polygon.com:443 где записи внешних IP адресов. А все потому что на работе «Шаг №1» о попытках авторизации был деактивирован прошлым системным администратором. Задачи сбора логов не стояло, вот отключено и было.

Шаг №8: Есть бесплатная утилита, которая может считывать логи локально и подключившись из интерфейса к другой – имя есть WinLogOnView

• Отображает даты и время начала сессии и время окончания
• Вычисляет продолжительность.
• Как были авторизованы в системе:
• Interactive - локально
• Remote Interactive - через RDP соединение
• Можно выделить несколько строк и сформировать отчет в html

Шаг №9: Вообще коды где искать логи удаленных подключений к серверу в оснастке Event Log локально.

Сетевые логи (Network logs)

1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071

Microsoft-Windows-Terminal-Services-RemoteConnectionManager Event 1149 A successful RDP client network connection but does not indicate a successful authentication (despite what the log event has as description). System authentication Microsoft-Windows-Security-Auditing Event 4624 + LogonType : 10 or 7 Successful authentication with an account Event 4625 Failed authentication RDP Session Microsoft-Windows-TerminalServices-LocalSessionManager Event 21 Successful RDP logon and session start. Often preceded by an event 22. Event 22 Successful RDP logon and shell start. Often followed by an event 22. Event 24 The user has disconnected from an RDP session Event 25 The user has reconnected to an existing RDP session Event 39 The user formally disconnected from the RDP session. Event 40 The user disconnected from or reconnected to an RDP session Event 23 The user initiated a formal system logoff (versus a simple session disconnect) Microsoft-Windows-Security-Auditing Event 4778 The user reconnected to an existing RDP session. Often paired with ID 25. Event 4779 The user disconnected from from an RDP session. Often paired with ID 24, likely also 39 and 40. Event 4634 A user disconnected from, or logged off, an RDP session. Event 4647 The user initiated a formal logoff (NOT a simple disconnect). Microsoft-Windows-System Event 9009 A user has closed out an RDP connection.

Шаг 10: Сервис RDG не логирует, кто из вне подключается к нему, только из локальной сети. Чуть погодя я стал умнее и перестал так думать.

(Это в моей инфраструктуре)

Даже в оснастке RD Gateway Manager – Monitoring текущее WAN соединение идет от шлюза (у меня на работе TMG), значит можно сформировать лог. У меня на TMG Настроено вести логи в базу. Это так для пояснения.

Смотрим лог

Microsoft Forefront Threat Management – Forefront TMG (srv-gateway01) – Logs & Reports – (Tasks) – Edit Filter

• Filter by: Rule:Contains:IN.RemoteApp
• Filter by: Log Record Type: Equals: Firewall or Web Proxy Filter
• Filter by: Log Time:On or After:28.01.2020 0:00:00

И нажимаю Start Query

Пример полученного и отформатированного отчета в Excel

Самое большое зло этого RDG – это то что в логах фигурирует внешний IP это адрес TMG, а не WAN_IP. А все потому что в настройках правила стоит

Specify how Forefront TMG forwards requests to the published server: “Requests appear to come from the Forefront TMG computer”, хотелось бы видеть «Requests appear to come from the original client”

А в логах TMG есть WAN и статус успешно или разъединено, но нет привязки как дальше.

Чуть позже понял где я был не прав говоря, что RDG не логирует WAN-IP адрес.

RDG правильно ведет логи, я просто на тот момент не понимал что он записывает.

Шаг №11: Если на TMG настроить правило проброса порта до терминального сервера, то в логах и через программу WinLogOnView виден внешний WAN-IP и через какую учетную запись был совершен или не совершен вход. Но так можно перебирать учетные записи всего домена или даже заблокировать их неверным вводом пароля, а когда используешь RDG, то только предопределенные могу подключаться из вне.

Шаг №12: Переделал правило на TMG и теперь на RDG все же вижу внешний IP:

Настройки правила:

Вкладка General

• Name: IN. RDP to TS

Вкладка Action

• Action: Allow
• Log requests matching this rule: отмечаю галочкой

Вкладка Traffic

• Allow network traffic using the following protocol: HTTPS Server

Нажимаю Ports

• (Firewall Ports) Publish on this port instead of the default port: 20000
• (Published Server Ports) Send requests to this port on the published server: 443
• (Source Ports) Allow traffic from any allowed source port

Вкладка From:

• This rule applies to traffic from these sources: External, Internal (мои IP сети)

Вкладка To:

• Specify the network address of the server to publish: 10.90.90.11 (это RDG)
• Specify how Forefront TMG forwards requests to the published server: Requests appear to come from the original client

Вкладка Networks:

• Selected networks for this listener: External, Internal

Вкладка Schedule:

• Schedule: Always

Лог смотрится на Remote Desktop Gateway

Event View (Local): Applications and Services Logs – Microsoft – Windows –TerminalServices-Gateway – Operational

Event ID: 313 – Нет-то подключается с WAN—ip используя учетные данные

• The user "aollo@polygon.com", on client computer "176.193.190.74:50170", has initiated an inbound connection. This connection may not be authenticated yet.

Event ID: 312 – Не прошла аутентификация

• The user "aollo@polygon.com", on client computer "176.193.190.74:50166", has initiated an outbound connection. This connection may not be authenticated yet.

Event ID: 200 – Прошел авторизацию политики

• The user "POLYGON\AOllo", on client computer "176.193.190.74", met connection authorization policy requirements and was therefore authorized to access the RD Gateway server. The authentication method used was: "NTLM" and connection protocol used: "HTTP".

Event ID: 300 – после переключение на srv—ts02-host

• The user "POLYGON\AOllo", on client computer "176.193.190.74", met resource authorization policy requirements and was therefore authorized to connect to resource "srv-ts02-host.polygon.com".

Event ID: 303 – Продолжительность политики

• The user "POLYGON\AOllo", on client computer "176.193.190.74", disconnected from the following network resource: "srv-ts02-host.polygon.com". Before the user disconnected, the client transferred 2152 bytes and received 2006 bytes. The client session duration was 0 seconds. Connection protocol used: "HTTP".

Вот скрипт на PowerShell который позволяет из «User Data» формировать отчет:

1234567891011121314

$Events = Get-WinEvent -FilterHashtable @{Logname = “Microsoft-Windows-TerminalServices-Gateway/Operational” ; ID = 300,302,303} $ArrayList = New-Object System.Collections.ArrayListForeach ($Event in $Events){[xml]$Xml = $Event.ToXml()$Row = “” | Select Username,TimeCreated,IPAddress$Row.Username = $Xml.Event.UserData.EventInfo.Username$Row.TimeCreated = $Event.TimeCreated.ToString()$Row.IPAddress = $Xml.Event.UserData.EventInfo.IpAddress[void]$ArrayList.Add($Row)} $ArrayList | export-csv C:\script\log.csv -nti

Теперь дабы подключиться из вне нужно указывать сервер шлюза удаленных рабочих столов:

• Компьютер: srv-ts02-host.polygon.com
• Имя сервера: mail.polygon.com:20000

А все остальное как раньше.

Шаг №13: Раз мое руководство хочет видеть Excel документ кто из авторизованного списка подключался: учетная запись, дата и время, то в скрипте выше оставляем только ID=300 и добавляем колонку Resource означающую куда инициализировано подключение:

123456789101112131415

$Events = Get-WinEvent -FilterHashtable @{Logname = “Microsoft-Windows-TerminalServices-Gateway/Operational” ; ID = 300} $ArrayList = New-Object System.Collections.ArrayListForeach ($Event in $Events){[xml]$Xml = $Event.ToXml()$Row = “” | Select Username,TimeCreated,IPAddress,Resource$Row.Username = $Xml.Event.UserData.EventInfo.Username$Row.TimeCreated = $Event.TimeCreated.ToString()$Row.IPAddress = $Xml.Event.UserData.EventInfo.IpAddress$Row.Resource = $Xml.Event.UserData.EventInfo.Resource[void]$ArrayList.Add($Row)} $ArrayList | export-csv C:\script\log.csv -nti

Итого задача выполнена.

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

Тут если посмотреть на заметку «Настройка подключения к RDG на pfSense 2.4.4»  — я же вижу WAN адрес который авторизовался на RDG

На заметку: Не претендую на уникальность, но оформляя заметку понял как работает и как и где за что отвечает логирование от роли Remote Desktop.

Итого, данная заметка прояснила некоторые моменты, сформировала требования к понятию логирования RDP соединений, что и где смотреть. Дабы не заниматься ручным трудом возможно стоит посмотреть в сторону централизованного сбора логов (к примеру инструмент LogAnalyzer или на основе Windows сервиса) или писать под конкретную задачу PowerShell скрипт. На этом я прощаюсь, с уважением автор блога Олло Александр aka ekzorchik.

Полный доступ к почтовому ящику на Exchange 2010

Задача: Когда тебе звонит пользователь и просит посмотреть почему у него не пришло письмо, отправленное коллегой рядом, обычно начинаешь анализировать логи на почтовом сервере, у меня он Exchange 2010 14.03.0248.002 на Server 2008 R2 SP1 Ent, а все оказывает просто, к примеру, у него много папок и одним из правил письмо прибыло не во «Входящие», а в одну из папок. А я уж собрался анализировать все и вся. Сейчас я распишу, как настраивается полный доступ к любому почтовому ящику почтового сервера:

Шаг №1: Подключиться под RDP к почтовому серверу, предварительно состоять в доменной группе «Exchange Organization Administrations”

Шаг №2: Запустить оснастку Exchange Management Console и дать себе (системному администратору) полные права на почтовый ящик пользователя (ей)

Microsoft Exchange – Microsoft Exchange On-Premises (srv-mail.polgyon.com) – Recipient Configuration – Mailbox – и выделяю ящик, к примеру alektest и «Actions» нажимаю “Manage Full Access Permission” – Add – и в поле Search: указываю логин своей доменной учетной записи под которой я буду иметь возможность управлять подключенным почтовым ящиком, как своим:

Search: aollo – OK, либо же двойной клик мыши по учетной записи

Затем нажимаю Manage окна “Manage Full Access Permission”, а после Finish

Шаг №3: Как проверить, что права выданы и я могу взаимодействовать. Можно подключить его в почтовый клиент, либо же обращаться к почтовому ящику через Web – формат URL запроса следующий:

https://mail/owa/alektest@polygon.com/

если первый раз обращаемся, то настроим языковые параметры:

• Язык: русский (Россия)
• Часовой пояс: (UTC+04:00) Москва, Санкт-Петербург, Волгоград

И нажимаем «ОК» и вот я внутри почтового ящика, над которым помимо пользователя у меня теперь тоже полные права.

К последующим ящикам обращаемся, только изменяя URL на https://mail/owa/abakan@polygon.com и тут же если есть права подаем в его ящик.

На этом у меня всё, с уважением автор блога Олло Александр aka ekzorchik.