В свете недавних событий с повышением вирусной активности многие организации стали уделять больше внимания вопросам всестороннего усиления мер безопасности в собственных ИТ-инфраструктурах. При этом некоторые из применяемых мер могут создать дополнительные сложности в работе самих ИТ-специалистов. Как известно, в последних вариациях вирусов-шифровальщиков, таких как Petya, используются такие инструменты компрометации учётных данных, как Mimikatz. Одним из методов защиты от Mimikatz является запрет на получение в Windows-системе привилегии SeDebugPrivilege. В инфраструктуре Active Directory настроить такое ограничение можно глобально для всех компьютеров домена с помощью параметра групповой политики "Debug programs" в разделе Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > User Rights Assignment: Если в данной политике явно задать доменную группу безопасности, то только члены данной группы смогут получить привилегию SeDebugPrivilege на всех компьютерах домена, на которые будет действовать данная групповая политика. Однако данная политика может осложнить жизнь не только инструментам типа Mimikatz, но и вполне легитимным приложениям, которые в своей работе могут использовать привилегии отладки. Например, после включения данной политики программа установки SQL Server 2012 может завершаться с ошибкой проверки правила "Setup account privileges" … The account that is running SQL Server Setup does not have one or all of the following rights: the right to back up files and directories, the right to manage auditing and the security log and the right to debug programs. To continue, use an account with both of these rights. …в том случае, если пользователь, от имени которого выполнятся установка, не был предварительно включён в соответствующую доменную группу безопасности, даже не смотря на то, что данный пользователь входит в группу локальных администраторов сервера. Если заглянуть в отчёт SystemConfigurationCheck_Report.htm, который создаётся в процессе установки SQL Server в каталоге типа "C:\Program Files\Microsoft SQL Server\110\Setup Bootstrap\Log\<отметка времени>\"…   …, то мы увидим, что срабатывает правило HasSecurityBackupAndDebugPrivilegesCheck, которое и выполняет проверку наличия прав доступа

Сообщение Получаем право SeDebugPrivilege для успешной установки Microsoft SQL Server 2012 при ограниченной доменной политике "Debug programs" появились сначала на Блог IT-KB.

На днях получил по электронной почте интересный комментарий к статье про подключение Debian GNU/Linux 8.6 к домену Active Directory с помощью SSSD и realmd от одного из наших читателей - Степана Кохановского. В силу того, что данный комментарий объёмен и описывает некоторое обходное решение известной проблемы, я решил опубликовать его в виде отдельного поста. Далее полностью процитирую комментарий Степана. В статье при вводе машины в домен появляется следующая ошибка: ... "! Couldn't set service principals on computer account CN=KOM-APP31,OU=Linux Servers,OU=KOM,DC=ad,DC=holding,DC=com: 00002083: AtrErr: DSID-03151785, #1: 0: 00002083: DSID-03151785, problem 1006 (ATT_OR_VALUE_EXISTS), data 0, Att 90303 (servicePrincipalName)" ... Автор обосновывает это тем, что при вводе использует учетные данные обычного доменного пользователя, а не администратора домена: "В моём примере видно, что процесс ввода в домен завершился успешно, однако с заполнением атрибута servicePrincipalName в свойствах учётной записи компьютера в домене возникла проблема, так как указанному в опции --user пользователю petya банально не хватило прав на это действие." Это не совсем верно. В этом можно легко убедиться, выполнив повторный ввод в домен под учетной записью доменного администратора. В моем случае ошибка воспроизводится даже при использовании системной учетной записи Administrator. Ошибка возникает на тех Debian-системах, где в качестве основного имени хоста используется короткое DNS имя, а не FQDN. Т. е. в тех случаях, когда вызов утилиты "hostname" без каких-либо параметров возвращает имя хоста без DNS суффикса. Баг описан в трекере Debian: Debian Bug report logs - #858981 А также на "родине" realmd и adcli, freedesktop.org: Bugzilla - Bug 86107 Если кратко, суть заключается в том, что adcli использует gethostname() для получения FQDN машины, что в результате приводит к ошибке при попытке зарегистрировать два одинаковых SPN: host/<netbiosname> и host/<fqdn>. Собственно, упомянутая выше ошибка "ATT_OR_VALUE_EXISTS" как раз возникает при попытке установить в атрибут LDAP значение, которое в нем уже есть. LDAP_TYPE_OR_VALUE_EXISTS refers to LDAP Result Code 20 which

Сообщение Обходное решение для ошибки регистрации servicePrincipalName (ATT_OR_VALUE_EXISTS) при подключении Debian GNU/Linux Jessie к домену Active Directory с помощью realm join появились сначала на Блог IT-KB.

Представим себе ситуацию, что есть некий сервер на базе Debian GNU/Linux, который уже введён в домен Active Directory с помощью SSSD и realmd и на нём уже имеется keytab-файл, который используется для механизмов аутентификации Kerberos и Single sign-on (SSO) при подключении к серверу по протоколу SSH. И вот возникает необходимость на данном Linux-сервере дополнительно настроить роль веб-сервера для служебных администраторских задач и организовать Kerberos SSO при подключении к веб-узлам этого веб-сервера. По ранее описанным примерам (здесь, здесь и здесь), предполагается, что для целей Kerberos-аутентификации веб-сервера Apache в домене Active Directory (AD) создаётся отдельная сервисная учётная запись типа User, для которой генерируется keytab-файл и в последствии привязывается к настройкам Apache на стороне Linux-сервера. С точки зрения аспектов безопасности такой поход (отдельный Linux-сервис = отдельная учётная запись в AD со своим keytab-файлом) можно считать вполне правильным. Но что, если Linux-сервис, использующий Kerberos-аутентификацию, используется не широким кругом пользователей, а исключительно для административных целей парой-тройкой системных администраторов? В таком случае создание отдельной учётной записи типа User в домене со своим keytab-файлом может показаться избыточным. В этой заметке мы рассмотрим пример того, как добавить дополнительную нужную нам запись servicePrincipalName (SPN) (на примере SPN-записи типа HTTP/) в уже имеющийся на Linux-сервере keytab-файл, ориентированный на сам хост (содержащий SPN-записи типа HOST/). В результате мы получим Kerberos аутентификацию на веб-узлах нашего Linux-сервера и при этом не будем плодить в домене лишние сервисные учётные записи типа User. Изменение учётной записи компьютера в AD Для начала нам необходимо обеспечить наличие всех нужных SPN-записей в свойствах учётной записи Linux-сервера (объект типа Computer) в домене AD. В нашем примере используется учётная запись компьютера kom-srv01.holding.com, который уже был ранее заведён в домен. Посмотрим текущее состояние SPN-записей в каталоге AD для этого хоста на любом Windows-компьютере, входящем в домен (для просмотра SPN достаточно прав рядового пользователя домена) с помощью утилиты setspn: setspn -L holding.com\kom-srv01

Сообщение Добавление SPN записей в keytab-файл (на стороне сервера Linux с помощью утилиты ktutil), связанный с учётной записью Computer в домене Active Directory появились сначала на Блог IT-KB.

System Security Services Daemon (SSSD) – это пакет приложений для управления аутентификацией и авторизацией в операционных системах на базе Linux. SSSD является отличной альтернативой монструозной Samba, позволяя подключить Linux машину к уже имеющемуся домену Active Directory. Большинство статей в интернет, описывающих использование SSSD для подключения к Active Directory, ставят перед собой задачу показать, насколько это легко и непринужденно. Зачастую, это очень короткие "истории успеха", в которых берется SSSD и Realmd, вводится пара команд, и все! Авторизация настроена. Спорить тут не с чем, так оно и есть. Но при этом надо держать в уме, что SSSD – это довольно сложный программный продукт, взаимодействующий с целым рядом отдельных подсистем хоста. В этой статье мне бы хотелось остановиться на некоторых нюансах настройки SSSD в Debian GNU/Linux и дать несколько полезных советов по его использованию в боевых условиях. Отмечу, что отправной точкой для исправления любых проблем с SSSD является вдумчивое чтение его логов, файлы которых расположены в /var/log/sssd. При этом отладочные логи SSSD достаточно подробны, их очень легко читать, и они включаются одной простой командой, не требующей перезапуска сервиса: # sss_debuglevel 7 Все описанные ниже особенности актуальны для версий SSSD 1.11.7 и 1.15.0. На момент написания этой статьи именно эти версии находятся в stable репозиториях Debian 8 Jessie и Debian 9 Stretch соответственно.   FQDN в качестве имени хоста Исторически сложилось, что в "родных" для SSSD дистрибутивах - RHEL и CentOS - принято в качестве имени хоста использовать FQDN, тогда как в Debian и Ubuntu - наоборот, короткое имя без DNS суффикса. На Debian эта идеологическая разница приводит не только к некорректной установке SPN (подробнее см. "Обходное решение для ошибки регистрации servicePrincipalName (ATT_OR_VALUE_EXISTS) при подключении Debian GNU/Linux Jessie к домену Active Directory с помощью realm join"), но и к отказу функции динамического обновления DNS. В отладочных логах SSSD можно увидеть, что некорректное имя хоста

Сообщение Рекомендации по настройке SSSD в Debian GNU/Linux появились сначала на Блог IT-KB.

Поведение вендоров ПО после публичного раскрытия информации об уязвимостях в процессорах Intel напоминало беспорядочную "стрельбу стоя с лошади из окопа", поэтому мы решили повременить с развёртыванием всех последних "чудо-патчей". По этой причине у нас в продуктивной среде ещё не развёрнуты Январские обновления для Windows Server, и с проблемой о которой пойдёт дальше речь, мы не столкнулись. Однако, возможно, информация будет полезна тем, кто собирается разворачивать эти обновления или уже развернул их и получил "нежелательный эффект". Информация по теме поступила от одного из наших коллег - Евгения Сидорова. Далее привожу его письмо. Если вы ещё не устанавливали январские кумулятивные обновления на свои контроллеры домена под управлением Windows Server 2012 R2 или Windows Server 2016, то, возможно, стоит ещё немного подождать и установить сразу февральские, благо ждать осталось недолго. Признанное проблемой данного обновления является ошибка "Error (0x80071128) occurred saving settings file. The data present in the reparse point buffer is invalid", возникающая при работе с консолью Group Policy Management (gpmc.msc) в процессе редактирования некоторых групповых политик. Как показывает практика, больше шансов нарваться на проблему, если изменять настройки в разделе Preferences, такими как Registry или Printers. Политика продолжает работать корректно, но в ней ничего нельзя удалить, изменить или добавить. Официального решения проблемы пока что нет, есть только кривенький Workaround, но и на том спасибо.   Решение проблемы (радикальное) Как правило, помогает удаление со всех контроллеров обновлений от 3 и 8 Января и последующая перезагрузка.   Обходное решение Кому-то помогает работать с GPMC с контроллера, на котором ещё нет этих обновлений, но в нашем случае это не сработало – обновления есть на трёх контроллерах из шести, но ошибка воспроизводилась на каждом. Если контроллеры домена свежие, но уровень домена ещё 2008 R2, то можно работать с групповыми политиками с контроллера на Windows Server 2008 R2 – там такой проблемы, по некоторой информации, нет. Точно работающий

Сообщение Январские обновления безопасности Microsoft Windows Server 2012 R2/2016 вызывают ошибку 0x80071128 "The data present in the reparse point buffer is invalid" при редактировании некоторых групповых политик появились сначала на Блог IT-KB.

В SharePoint Server 2013 есть проблема, которая тянется с предыдущих версий SharePoint. Суть её заключается в том, что информация о той или иной доменной группе безопасности, единожды попав в SharePoint из каталога Active Directory, не обновляется в SharePoint в дальнейшем. И если в последствии в Active Directory группа безопасности будет переименована, то получится так, что на всех веб-узлах SharePoint эта группа останется со старым именем, что в некоторых ситуациях может привести к путанице. В этой заметке мы рассмотрим действия, которые можно предпринять на стороне SharePoint Server для актуализации информации об именах групп безопасности. Рассмотрим пример, в котором изначально созданная в домене группа безопасности с именем "KOM\My-Group-Old-Name" и попавшая с этим именем в SharePoint, была через некоторое время переименована в Active Directory в "KOM\My-Group-New-Name". При этом SID группы, разумеется, остался прежним "s-1-5-21-2955499624-4996244754-1486499624-289425". Чтобы быстро получить SID доменной группы безопасности для сверки с тем, что мы видим в поле "Учётная запись" на узле SharePoint можем выполнить команду PowerShell: Get-ADGroup "My-Group-New-Name" | Select SID Теперь, убедившись в том, что речь идёт об одной и той же группе безопасности, чтобы обновить на стороне SharePoint Server информацию об имени группы выполним пару действий. Для начала обновим информацию в механизме "People Picker", который используется в SharePoint в тех местах, где требуется выбор пользователей или групп безопасности. Для этого на сервере SharePoint откроем командную строку с правами Администратора, перейдём в каталог исполняемых файлов и выполним смену имени с помощью утилиты stsadm. cd /d "C:\Program Files\Common Files\microsoft shared\Web Server Extensions\15\BIN\" stsadm -o migrategroup -oldlogin 'KOM\My-Group-Old-Name' -newlogin 'KOM\My-Group-New-Name' В результате выполнения команды мы можем получить сообщение об отсутствии или неуникальности пользователя, которое, как я понимаю, в данном случае можно проигнорировать. Вообще замечено, что информация в "People Picker" без выполнения вышеуказанной команды обновляется автоматически через некоторое время, но в некоторых случаях по какой-то невыясненной причине она остаётся устаревшей, поэтому выполнение

Сообщение Исправляем имя доменной группы в SharePoint 2013 после переименования в Active Directory появились сначала на Блог IT-KB.

Есть у нас в обороте старенькая версия ABBYY FineReader 9.0 с небольшим количеством конкурентных лицензий и сервером лицензирования. Сервер лицензирования выдаёт клиентским компьютерам лицензии при запуске ПО на этих компьютерах, а при исчерпании пула лицензий клиент получает сообщение о невозможности запуска приложения. Распределение лицензий происходит по простому принципу "кто первый встал, того и тапки", и как-то всегда хватало приобретённого количества лицензий на всех. Однако в последнее время специалисты тех.поддержки стали фиксировать жалобы пользователей на участившиеся ситуации с нехваткой лицензий. На сервере лицензирования картина действительно выглядела так, как будь-то нам не хватает лицензий. Однако небольшой социологический опрос с пристрастием выявил тенденцию, в последнее время ставшую модной среди пользователей, более или менее активно пользующихся FineReader. Раз или два столкнувшись с сообщением о нехватке лицензий, некоторые пользователи стали хитрить, запуская приложение в самом начале рабочего дня и держа его открытым весь день. Это привело к тому, что другие пользователи стали получать сообщение о нехватке лицензий ещё чаще, после чего также стали пользоваться тактикой преждевременного запуска, загоняя ситуацию в тупик ещё больше. Стоит отметить то, что суть этой проблемы заключается не в хитрых пользователях, а в том, что ABBYY FineReader 9.0 использует конкурентное распределение лицензий и при этом не имеет встроенных механизмов высвобождения лицензий для простаивающих экземпляров ПО. Не исключено, что в новых более современных версиях ABBYY FineReader эта проблема решена, однако мы имеем то, что имеем, и с этим как-то нужно жить. Итак, мы имеем хитрых пользователей и, как следствие, нехватку конкурентных лицензий. Возникла идея о том, что если мы сможем забороть хитрецов, то вопрос нехватки лицензий самоликвидируется. После некоторых изысканий был выбран простой, но действенный вариант – автоматизация закрытия процессов FineReader на простаивающих компьютерах с помощью PowerShell. Ведь здесь всё логично и по честному – не работаешь за компьютером, значит не используешь ПО, а не используешь ПО, значит верни конкурентную лицензию в

Сообщение ABBYY FineReader 9.0 - Решаем проблему высвобождения конкурентных лицензий появились сначала на Блог IT-KB.

С тех пор, как мы в одной из прошлых заметок рассматривали процесс развёртывания HP Product Bulletin, прошло немало времени. За это время продукт успел побывать в фазе активной поддержки, после чего был "заморожен" со стороны HP и его обновления какое-то время не выпускались, затем уже в HPE провели его ребрендинг и снова вернули к жизни. Поэтому для тех, кто активно работает с оборудованием HP/HPE, на сегодняшний день этот продукт может быть всё ещё полезен. В этой заметке мы сделаем акцент на то, как развернуть актуальную версию HPE Product Bulletin Gateway таким образом, чтобы она выполнялась в контексте сервисной учётной записи Group Managed Service Account (gMSA). Как я понял, в актуальной версии Product Bulletin в целях ребрендинга HP –> HPE была обновлена лишь графическая оболочка инсталлятора и самого приложения. При этом Backend приложения, судя по всему, изменён не был, так как у Product Bulletin Gateway остались все прежние "детские болезни", типа того, что служба HPPB_Gateway не приспособлена для работы в более или менее новых серверных ОС Windows Server и по прежнему требует интерактивного режима работы. Например, попытка запуска службы в Windows Server 2012 R2 приведёт к ошибке типа: Log Name: System Source: Service Control Manager Event ID: 7030 Level: Error Description: The HPPB_Gateway service is marked as an interactive service. However, the system is configured to not allow interactive services. This service may not function properly. При этом, даже если включить в ОС поддержку старых интерактивных служб и пытаться запустить службу от имени сервисной учётной записи, результат будет неутешительным. Поэтому автоматизацию запуска процесса PB Gateway мы будем достигать путём создания задачи в планировщике задач (Task Scheduler), но уже не в контексте обычной доменной учётной записи, как это было рассмотрено ранее, а в контексте сервисной учётной записи gMSA. Примеры основных приёмов работы с gMSA можно найти в соответствующем разделе Вики. Создаём в

Сообщение Запуск HPE Product Bulletin Gateway в контексте учётной записи gMSA появились сначала на Блог IT-KB.

По появившейся на днях информации, развёртывание Январских кумулятивных обновлений для ОС Windows Server 2012 R2 (KB5009624) может привести к проблемам в работе служб Active Directory Services (ADDS), так как серверы с ролью контроллера домена могут начать циклические перезагрузки. Microsoft уже подтвердили наличие проблемы, о чём можно прочитать по соответствующим ссылкам на Microsoft Docs: Windows Server 2022 Known issues and notifications Windows 10 20H2 and Windows Server 20H2 Known issues and notifications Windows 8.1 and Windows Server 2012 R2 Known issues and notifications Можно встретить сообщения о том, что после установки KB5009624 на Windows Server 2012 R2 могут возникнуть проблемы с запуском виртуальных машин с использованием UEFI в Hyper-V. Опять же, это подтверждается со стороны Microsoft: Virtual machines (VMs) in Hyper-V might fail to start. Также есть информация о замеченных проблемах с дисковыми томами с файловой системой ReFS, которые после установки Январских обновлений могут перестать монтироваться и начать отображаться как RAW. На данный момент времени Microsoft со своей стороны при проявлении данной проблемы предлагает удалять Январское обновление: KB5010691: ReFS-formatted removable media may fail to mount or mounts as RAW after installing the January 11, 2022 Windows updates. Кроме того, есть информация о том, что и обновления, выпущенные в Январе для серверных ОС Windows Server 20H2 и клиентских ОС Windows 10 (KB5009543), а также Windows 11 (KB5009566) могут вызвать проблему использования L2TP VPN, сложности с RDP и всё те же внезапные перезагрузки серверов с ролью контроллера домена. Для получения подробностей и обходном решении, читайте раздел "Известные проблемы, связанные с этим обновлением" в соответствующих KB. Есть информация о том, что проблемные обновления уже отозваны из каталога Windows Update, однако они всё ещё могут оставаться в метаданных локальных служб WSUS. Поэтому стоит воздержаться от их развёртывания в продуктивных средах до тех пор, пока со стороны Microsoft не будут выпущены корректирующие обновления.

Сообщение Январские накопительные обновления Windows Server могут вызывать циклические перезагрузки контроллеров домена ADDS, сломать ВМ с UEFI в Hyper-V и вызвать отказ в работе ReFS появились сначала на Блог IT-KB.

Данный материал является переводом оригинальной статьи "Active Directory Pro : Robert Allen : How to Update Group Policy on Remote Computers" и рассчитан на начинающих администраторов Windows. В конфигурации по умолчанию доменные компьютеры обновляют групповые политики (Group Policy) при запуске операционной системы, а затем политики автоматически обновляются в фоновом режиме каждые 90 минут. Но бывают случаи, когда вы вносите изменения в существующие объекты групповой политики (Group Policy Objects/GPO) или создаете новые GPO, и вам нужно, чтобы изменения вступили в силу немедленно. Далее мы рассмотрим три различных способа удаленного обновления групповой политики. Первый способ лучше всего подходит для старых клиентов Windows, второй и третий способы - для систем, работающих под управлением 2012 года и более поздних версий. Способ 1: Использование утилит GPUpdate и PsExec Этот способ использует на клиентских компьютерах встроенную в Windows команду под названием gpupdate. Чтобы немедленно принудительно обновить групповую политику на локальном компьютере, используют команду вида: gpupdate /force Параметр /force принудительно обновит все политики, а не только новые. Однако, если у вас множество компьютеров, которые нуждаются в обновлении, было бы непросто входить в каждый из них и выполнять эту команду. Чтобы выполнить указанную (или любую другую) команду на удаленном компьютере, вы можете воспользоваться утилитой PsExec из набора инструментов Sysinternals. Вот пример использования PsExec для удаленного обновления групповой политики: PsExec \\Computername gpupdate Просто замените Computername на фактическое имя хоста удаленного компьютера.   Способ 2: Использование Консоли Group Policy Management В Windows Server 2012 и более поздних версиях теперь можно принудительно обновлять групповую политику на удаленных компьютерах с помощью консоли управления групповой политикой Group Policy Management. Этот метод очень прост и позволяет запускать обновление в одном подразделении (Organizational Unit/OU) или во всех подразделениях Active Directory. Шаг 1: Найдите в главном меню Консоль управления групповой политикой "Group Policy Management". Вы можете открыть эту консоль на компьютере, на котором установлены средства RSAT.

Сообщение Как принудительно обновить групповые политики на удаленных компьютерах в домене Active Directory появились сначала на Блог IT-KB.

При централизованном развёртывании агентов мониторинга System Center 2016 Operations Manager (SCOM) на множество серверных систем в доменной инфраструктуре можно столкнуться с проблемой невозможности обнаружения серверов с ролью контроллера домена Active Directory. Работа мастера "Computer and Device Management Wizard" при явном указании списка контроллеров домена и учётной записи администратора домена может заканчиваться сообщением "Discovery failed … There were no computers discovered that met your criteria". Большинство классических причин проблемы обнаружения можно найти, перейдя по ссылке, указанной в сообщении. Однако в некоторых ситуациях помогает предварительный анализ алертов, генерируемых самим SCOM, а также сопутствующих событий в Event-логах на сервере SCOM и на той системе, которую мастер развёртывания пытается опросить. Например, в нашей ситуации, в SCOM был обнаружен алерт с ошибкой обнаружения следующего вида: Alert: An error occurred during computer verification from the discovery wizard Source: SCOM10.holding.com Path: SCOM10.holding.com Description: Computer verification failure for Machine Name: DC01.holding.com is 0x80070005. Access is denied. Этот алерт был сгенерирован на базе ассоциированного события 11551 в event-логе "Operations Manager" на сервере SCOM: Log Name: Operations Manager Source: Health Service Modules Event Number: 11551 Logging Computer: SCOM10.holding.com Description: Computer verification failure for Machine Name: DC01.holding.com is 0x80070005. Access is denied. Проверяем сопутствующие события в event-логе контроллера домена и в журнале "Security" обнаруживаем сообщение 4822 следующего вида: Log Name: Security Source: Microsoft-Windows-Security-Auditing Event ID: 4822 Task Category: Credential Validation Level: Information Keywords: Audit Failure Computer: DC01.holding.com Description: NTLM authentication failed because the account was a member of the Protected User group. Account Name: admin-petya Device Name: SCOM10 Error Code: 0xC000006E В данном случае, по описанию события, очевидным становится то, что проблема связана с возникновением ошибки NTLM аутентификации для учётной записи доменного администратора. И связана эта ошибка может быть с тем, что используемая при обнаружении в SCOM учётная запись администратора включена в домене в специальную группу безопасности "Protected Users". А на

Сообщение Ошибка обнаружения контроллеров домена в SCOM 2016 Discovery Wizard "Discovery failed. There were no computers discovered that met your criteria … Computer verification failure 0x80070005. Access is denied" появились сначала на Блог IT-KB.

Первичный опыт развёртывания кластера 1С:Предприятие 8.3 (в варианте инсталляции с настройками "по умолчанию") и его начальной тестовой эксплуатации выявил некоторые неочевидные особенности функционирования службы агента сервера 1С ("1C:Enterprise 8.3 Server Agent"), выполняющейся в контексте локальной сервисной учётной записи USR1CV8. Изучение этих особенностей и подтолкнуло к мысли о том, что для запуска этой службы на серверах 1С в составе доменной инфраструктуры Active Directory, вместо обычной локальной учётной записи, логичней и безопасней будет использовать учётную запись Group Managed Service Account (gMSA). Началась вся история с того, что на этапе подготовки серверов под будущий кластер 1С, в ходе инсталляции серверной части 1С:Предприятие 8.3 на каждом из серверов был задан уникальный пароль для вновь создаваемой инсталлятором локальной сервисной учётной записи USR1CV8. И всё было вроде бы хорошо, пока служба агента сервера 1С работала изолировано в рамках локальной системы. Но почти сразу после сборки двух-узлового кластера 1С была обнаружена проблема с периодической блокировкой этой самой локальной учётной записи USR1CV8 на обоих серверах кластера. В следствии такой блокировки через некоторое время останавливалась и служба агента сервера 1С, работающая от имени этой учётной записи. Ручная разблокировка учётной записи проблема не решала, так как через некоторое время ситуация повторялась и учётная запись заново блокировалась. Была предпринята попытка установить одинаковый пароль для одноимённых локальных учётных записей USR1CV8 на обоих серверах 1С. После этого блокировки учётных записей прекратились, и как следствие, прекратились неконтролируемые остановки службы агента сервера 1С. Однако, не смотря на это, в логе безопасности Windows (%SystemRoot%\System32\Winevt\Logs\Security.evtx) на обоих серверах наблюдалась одинаковая картина - каждые несколько секунд продолжали регистрироваться события безуспешных попыток аутентификации локального пользователя USR1CV8 на соседнем сервере кластера 1С. При этом на каждом из серверов, в каталоге хранения технологического журнала для службы агента сервера 1С (лог процесса ragent), наблюдался бурный рост лог-файлов с регистрацией множества однотипных событий, указывающих на безуспешные попытки взаимной аутентификации. В данной ситуации простым

Сообщение Использование учётной записи gMSA для службы "Агент сервера 1С:Предприятие 8.3" на серверах кластера 1С:Предприятие появились сначала на Блог IT-KB.

При настройке пользовательской среды для серверов RDS с ролью Remote Desktop Session Host могут использоваться дополнительные меры усиления безопасности, которые могут быть реализованы путём внедрения разного рода ограничений, диктуемых специальными групповыми политиками действующими только на серверах фермы RDS. И ранее мы рассматривали пример политики "User Group Policy loopback processing mode", которая включает форсированное применение параметров пользовательской среды на серверах RDS. Практика показала, что такие настройки могут вызывать проблемы у тех доменных пользователей, для которых в свойствах учётной записи в домене назначено сетевое расположение профиля. Например, имеется некий доменный пользователь, у которого в свойствах учётной записи задан параметр "Profile path" (атрибут profilePath), указывающий на сетевой каталог на файловом сервере. В этом каталоге будут хранится данные профиля этого пользователя и они будут использоваться по умолчанию при входе пользователя на любую доменную систему. Предположим, у пользователя есть несколько рабочих станций с Windows, на которых он работает. И на какую бы из этих станций не вошёл пользователь, ему будет подгружена привычная для него рабочая среда (документы в профиле, оформление рабочего стола и т.п.) из этого сетевого каталога. Однако, если такой пользователь войдёт на сервер фермы RDS, имеющий ранее упомянутую агрессивную настройку среды с помощью специальной групповой политики, то тут у него могут начаться проблемы разного рода. Например, из самого безобидного, поле того как, пользователь поработает в ферме RDS, выйдет из ней и войдёт на свою рабочую станцию, то он может обнаружить что у него пропали обои рабочего стола, которые он настраивал для себя ранее и которые теперь перенастроены в соответствии с политиками RDSH. То есть когда мы настраиваем политики фермы RDS, мы предполагаем, что при входе в ферму у пользователя подгрузится специальный диск профиля User Profile Disk, ассоциированный с этой фермой. А на самом деле у подобного пользователя произойдёт форсированная загрузка сетевого профиля AD из сетевого каталога. В итоге может получится некий конфликт настроек

Сообщение Конфликт групповых политик для серверов RDS c User Profile Disk с сетевыми профилями доменных пользователей появились сначала на Блог IT-KB.

Замечено, что на Linux системе, подключенной к домену Active Directory с помощью SSSD, после некоторого времени простоя системы при попытке выполнить команду sudo происходит длительное ожидание запроса на ввод пароля (от 10 до 15 секунд). Последующие попытки использования sudo отрабатывают уже быстро. Проблема также воспроизводится, если выполнить принудительное аннулирование всех записей кеша sssd командой типа "sss_cache -E". Экспериментальным путём подтверждено, что проблема может проявлять себя более выраженно в случае, если выполняющий команду sudo пользователь в домене имеет учётную запись, являющуюся членом большого количества групп безопасности и при этом есть группы, включающие в себя большое количество других учётных записей. О подобной проблеме известно уже давно и предлагается некоторое "костыльное" решение, которое имеет смысл использовать лишь там, где этой действительно необходимо. Суть решения сводится к тому, чтобы в конфигурационный файл /etc/sssd/sssd.conf в секцию описания домена добавить параметр ignore_group_members. ... [domain/sub.holding.com] ... ignore_group_members = True Для вступления изменений в силу потребуется перезапуск службы sssd: # systemctl restart sssd Это предотвращает избыточную попытку sssd получить информацию о всех членах групп, участником которых является текущая учётная запись пользователя, выполняющего команду sudo. Но следует помнить про то, что включение данной опции, может свести на нет работу некоторых инструментов. Например, при выполнении команды "getent group 'Domain Admins'" без использования опции ignore_group_members мы получим список всех членов доменной группы 'Domain Admins', а при включении опции ignore_group_members мы уже не получим информации о членах группы. Включение опции ignore_group_members в нашем случае по результатам замеров показало примерно 4-кратное сокращение времени выполнения sudo. Интересно то, что, судя по старым записям, ещё в версии sssd 1.14 в работу механизма кеширования были привнесены улучшения, которые предполагали избавление от проблемы и отказ от костыля с ignore_group_members. Но судя по тому, что мы видим на практике с актуальными версиями sssd проблема никуда не делась.

Сообщение Медленная работа SUDO при использовании SSSD появились сначала на Блог IT-KB.

В этой заключительной части нашего плана развёртывания Icinga на Debian GNU/Linux 12 "Bookworm" мы коротко обозначим основные моменты конфигурации веб-сервера Apache для интеграции Icinga Web 2 со службой каталогов Microsoft Active Directory, опираясь на более подробный материал, изложенный ранее в статье "Аутентификация и авторизация пользователей Active Directory в Icinga Web 2 (Kerberos и SSO)". Рассмотренные в этой статье разделы "Подготовка инфраструктуры", "Создаём политику PAM", "Добавляем LDAP-ресурс для авторизации в Icinga Web 2", "Добавляем User Backend для аутентификации в Icinga Web 2", "Добавляем User Group Backend для авторизации в Icinga Web 2", "Проверяем возможность поиска доменных групп", "Создаём роли с привязкой к доменным группам" справедливы и для нового развёртывания Icinga 2 на базе Debian 12. Отличия появляются для раздела "Настройка Apache на Kerberos-аутентификацию и PAM авторизацию". При установке модулей к Apache вместо модуля libapache2-mod-auth-kerb теперь потребуется установить libapache2-mod-auth-gssapi: # apt-get install libapache2-mod-auth-gssapi libapache2-mod-authnz-pam Устанавливаемые модули будут автоматически включены в конфигурацию Apache на заключительном этапе установки. Можно проверить, присутствуют ли среди активированных модулей Apache нужные нам модули: # apache2ctl -M | grep -E "gss|pam" auth_gssapi_module (shared) authnz_pam_module (shared) Правим конфигурацию виртуального каталога "/icingaweb2": # nano /etc/apache2/conf-available/icingaweb2.conf Содержимое конфигурации сайта будет с учётом использования модуля auth_gssapi_module и конечный вид файла может быть таким: Alias /icingaweb2 "/usr/share/icingaweb2/public" <Directory "/usr/share/icingaweb2/public"> Options SymLinksIfOwnerMatch AllowOverride None #Require all granted AuthType GSSAPI AuthName "Kerberos Authentication" #GssapiSSLonly On GssapiBasicAuth Off GssapiAllowedMech krb5 GssapiNegotiateOnce On GssapiCredStore keytab:/etc/krb5.keytab #Require valid-user Require pam-account apache2-icingaweb2 ErrorDocument 401 /IcingaUnauthorized.html SetEnv ICINGAWEB_CONFIGDIR "/etc/icingaweb2" <IfModule mod_rewrite.c> RewriteEngine on RewriteBase /icingaweb2/ RewriteCond %{REQUEST_FILENAME} -s [OR] RewriteCond %{REQUEST_FILENAME} -l [OR] RewriteCond %{REQUEST_FILENAME} -d RewriteRule ^.*$ - [NC,L] RewriteRule ^.*$ index.php [NC,L] </IfModule> <IfModule !mod_rewrite.c> DirectoryIndex error_norewrite.html ErrorDocument 404 /icingaweb2/error_norewrite.html </IfModule> DirectoryIndex index.php </Directory> У пользователя (или его группы), от имени которого работает служба apache2 должен быть доступ на чтение к keytab файлу: # chown root:www-data /etc/krb5.keytab # chmod

Сообщение Развёртывание Icinga 2 на базе Debian 12. Часть 6. Конфигурация веб-сервера Apache для интеграции Icinga Web 2 c Active Directory появились сначала на Блог IT-KB.

Рассмотренный ранее сервер Patchman на базе веб-фреймворка Django, в нашем случае функционирует в инфраструктуре, имеющей службу каталогов Microsoft Active Directory, поэтому для большего удобства работы с веб-интерфейсом Patchman возникает желание настроить на веб-сервере аутентификацию пользователей с помощью протокола Kerberos, а также авторизацию с помощью протокола LDAP через доменные группы безопасности. То есть, предполагается реализация механизма SSO (Single Sign-On) для того, чтобы пользователи не вводили какие-то локальные учётные записи каждый раз при входе в веб-интерфейс Patchman, а прозрачно получали доступ к сайту на основе своей доменной учётной записи, в контексте которой запущен клиентский браузер.Так как веб-интерфейс Patchman работает на базе веб-фреймворка Django, то, по сути, описываемая далее настройка будет относится именно к этому фреймворку и пример рассмотренной далее конфигурации может быть применим и для других проектов, реализованных на базе Django. Всю настройку условно можно разделить на 3 части: Настройка веб-сервера Apache для работы с аутентификацией Kerberos; Настройка фреймворка Django на LDAP-авторизацию с помощью модуля django-auth-ldap; Дополнительная конфигурация модуля django-remote-auth-ldap, чтобы "подружить" Kerberos аутентификацию с LDAP авторизацией.   Часть 1. Kerberos и Apache В рамках данной заметки мы не будем рассматривать процедуры подключения сервера к домену или получения keytab-файла, необходимого для работы Kerberos в Linux. Предполагаем, что наш сервер Patchman уже подключен к домену, например так, как это описано в Вики-статье "Подключение Debian GNU/Linux 12 (Bookworm) к домену Active Directory с помощью SSSD и настройка PAM для доменной аутентификации и авторизации в SSHD". То есть в системе уже имеется keytab-файл, используемый для процессов доменной аутентификации Kerberos. В этом файле, как минимум, должны быть записи типа host/<server fqdn>. Проверим содержимое записей keytab-файла: # klist -e -k -t /etc/krb5.keytab Регистрируем в домене для учётной записи веб-сервера SPN-запись вида HTTP/<server fqdn> и добавляем в keytab-файл соответствующие записи. Подробно эта процедура описана ранее в статье "Добавление SPN записей в keytab-файл (на стороне сервера Linux с помощью

Сообщение Patchman : Kerberos аутентификация и LDAP авторизация в Django в домене Active Directory появились сначала на Блог IT-KB.