АйТи Фреш
Главная / Статьи / Windows и рабочие места
Windows и рабочие места

Сервис не получает Kerberos-билет после обновлений DC: как найти зависимость от RC4, когда журнал пуст

Автор: Семёнов Евгений Сергеевич, директор ООО «АйТи-Фреш» · · ~22 мин чтения
Сервис не получает Kerberos-билет после обновлений DC: как найти зависимость от RC4, когда журнал пуст
Иллюстрация к статье «Сервис не получает Kerberos-билет после обновлений DC: как найти зависимость от RC4, когда журнал пуст».

Типичная картина после обновления контроллеров домена: отвалилось сканирование в папку, не поднимается линкед-сервер SQL или приложение перестало пускать пользователей, а в журналах DC при этом чисто. Я разберу, что Microsoft поменяла в Kerberos в 2026 году, почему пустое поле msDS-SupportedEncryptionTypes, явно разрешённый RC4 и отсутствие AES-ключей — три разные проблемы с похожими симптомами, и как их различать, когда события KDCSVC молчат. С командами, битовыми масками и разбором домена частной школы на 29 рабочих мест.

«Мы ничего не меняли» — меняли, просто не вы

Звонок в понедельник: «в пятницу всё работало, сегодня программа не видит базу». Смотрю — обновления на контроллерах домена встали в выходные. И дальше начинается самое неприятное в этой истории: часть сервисов ломается сразу и громко, а часть — молча деградирует на NTLM и падает через две недели, когда кто-то отключит NTLM или сменит пароль сервисной учётке. Второй сценарий хуже, потому что связь с обновлением DC к тому моменту уже никто не проводит.

Причина — трёхфазный вывод RC4 из Kerberos, который Microsoft запустила обновлением KB5073381 от 13 января 2026 года в рамках устранения CVE-2026-20833. Обновление накрывает контроллеры на Windows Server 2012/2012 R2 (ESU), 2016, 2019, 2022, 23H2 и 2025. Первая фаза — только аудит: KDC начинает писать в системный журнал новые события и предупреждать, что вот эта конкретная выдача билета скоро станет невозможной. Вторая фаза, обновления от 14 апреля 2026 года, — это уже боевое изменение: значение DefaultDomainSupportedEncTypes по умолчанию становится 0x18, то есть только AES-SHA1 (AES128 + AES256), для всех учётных записей, у которых атрибут msDS-SupportedEncryptionTypes не задан явно. Третья фаза, июль 2026 года, убирает параметр отката RC4DefaultDisablementPhase — вернуть прежнее поведение одной строкой в реестре больше нельзя.

Ключевой момент, который в спешке пропускают: до апреля пустой атрибут означал «считаем, что учётка поддерживает DES, RC4 и AES-ключи сессии». После апреля пустой атрибут означает «считаем, что учётка поддерживает только AES-SHA1». Ничего в самой учётке не поменялось — поменялась трактовка пустоты. Именно поэтому админ смотрит в свойства сервисной учётки, видит там незаполненное поле, как и год назад, и делает неверный вывод, что его это изменение не касается.

И ещё одна деталь, про которую забывают при планировании: начиная с Windows Server 2025 контроллеры домена вообще не выдают RC4-билеты TGT. То есть если у вас в парке уже стоит DC на 2025, часть проблем вы поймали ещё до всей этой истории с CVE — просто не связали одно с другим.

Проверьте прямо сейчас, не выставлял ли кто-то RC4DefaultDisablementPhase в 0 или 1 «чтобы работало». После июльских обновлений этот костыль перестанет действовать, и вы получите ту же аварию, но уже без возможности откатиться — и, скорее всего, в отпускной период.
Цифры и версии: «Мы ничего не меняли» — меняли, просто не вы — схема
Цифры и версии: «Мы ничего не меняли» — меняли, просто не вы. Открыть схему в полном размере

Три разные причины, которые сваливают в одну кучу

Первая причина — атрибут msDS-SupportedEncryptionTypes не задан (значение null или 0). Учётка не сломана, просто у неё нет явной конфигурации, и KDC применяет к ней доменное значение DefaultDomainSupportedEncTypes. До апреля это давало RC4, после апреля — только AES-SHA1. Лечится это либо тем, что вы явно проставляете атрибут на конкретных учётках, либо тем, что осознанно выставляете доменное значение. Второй путь опаснее: он меняет поведение сразу всех учёток без явной настройки, включая те, о которых вы не знаете.

Вторая причина — RC4 разрешён явно. Это значение 0x4 (только RC4) или популярное 0x24, где к RC4 добавлен бит 0x20 — ключ сессии AES256. Такие учётки апрельское изменение не задело вообще: явная настройка всегда сильнее умолчания. Отсюда типичная ошибка планирования — «мы пережили апрель, значит, у нас всё чисто». Нет: вы пережили апрель именно потому, что где-то стоит явное разрешение RC4, и оно продолжает висеть уязвимостью к Kerberoasting. Июльская фаза убирает параметр отката на уровне домена — но не трогает ваши явные исключения на учётках. Это разные механизмы, их постоянно путают.

Третья причина — атрибут говорит одно, а ключей нет. Учётка помечена как поддерживающая AES, но AES-ключи для неё в базе AD физически отсутствуют. Так бывает с учётками, заведёнными ещё во времена контроллеров на Windows Server 2003, пароль которым с тех пор ни разу не меняли: AD начал хранить AES-ключи только с контроллеров Windows Server 2008. Ключи AES вычисляются из пароля и соли в момент смены пароля — нет смены, нет ключей. Сервис при этом честно просит AES, KDC честно не может его выдать, и билета нет. Если атрибут у такой учётки задан с AES, KDC пишет события 207 (аудит) и 209 (отказ); если атрибут пуст — 202 и 204.

И четвёртая ловушка, уже не причина, а способ обмануть самого себя при диагностике. В событиях 4768/4769 поле MSDS-SupportedEncryptionTypes — это не то, что лежит в атрибуте, а вычисленное значение. На Windows Server 2022 и ниже KDC всегда показывает там DES и RC4 ради совместимости со старыми контроллерами, независимо от ваших настроек. Начиная с Windows Server 2025 показываются только AES-SHA1 и сильнее. Я видел, как из-за этого поля разворачивали ошибочный вывод «у нас весь домен на RC4» и шли откатывать обновления. Не надо. Сверяйтесь с реальным значением атрибута в AD.

Значение атрибута в PowerShell возвращается десятичным, а вся документация Microsoft — в шестнадцатеричном. 28 и 0x1C — это одно и то же. На этой мелочи ошибаются чаще, чем на всей остальной теме вместе взятой.
Сервис не получает Kerberos-билет после обновлений DC: как найти зависимость от RC4, когда журнал пуст — схема
Схема к статье. Открыть схему в полном размере

Домен «Логос-Лицея»: 29 рабочих мест и четыре разных RC4 в одном домене

Частная школа «Логос-Лицей», 29 рабочих мест: бухгалтерия, учебная часть, учительская, два компьютерных класса на тонких местах и администрация. Обслуживаем по аутсорсу. Домен на двух контроллерах: DC01 на Windows Server 2019 и DC02 на Windows Server 2022, функциональный уровень 2016. Прикладной сервер — SQL Server 2019 и сервер 1С с бухгалтерией и зарплатой, терминальный сервер на восемь сессий для бухгалтерии и завуча, NAS Synology в домене под учебные материалы и сканы личных дел, два МФУ Kyocera со сканированием в папку и контроллер СКУД на турникете, который ходит в AD по LDAP и Kerberos. Обновления ставим по регламенту: тестовый DC в первую неделю, боевые — во вторую.

После апрельского цикла в течение суток прилетели три обращения. Первое: сканирование в папку с обоих МФУ отваливается с «ошибка аутентификации», хотя пароль сервисной учётки не менялся два года. Второе: линкед-сервер между SQL и базой СКУД, откуда 1С забирает табель охранников и техперсонала, перестал подниматься под доменной учёткой. Третье, самое мутное: учителя на терминальном сервере периодически не могут открыть папку с материалами на Synology, а через пять минут могут. Именно третий симптом чуть не увёл нас в сторону — он выглядел как сетевая нестабильность, а на деле был откатом на NTLM, который то срабатывал, то нет.

Копали так. Сначала выгрузили состояние атрибутов по всему домену — картинка сразу перестала быть однородной:

Get-ADObject -Filter {ObjectClass -eq 'computer' -or ObjectClass -eq 'user'} `
  -Properties msDS-SupportedEncryptionTypes,servicePrincipalName,PasswordLastSet |
  Select-Object Name,ObjectClass,
    @{n='EncTypes';e={$_.'msDS-SupportedEncryptionTypes'}},
    @{n='HasSPN';e={[bool]$_.servicePrincipalName}},PasswordLastSet |
  Sort-Object EncTypes | Export-Csv .\enctypes.csv -Encoding UTF8 -NoTypeInformation

Из 38 объектов с SPN у 26 атрибут был пуст, у 8 стояло 28 (0x1C — RC4 плюс AES), у 3 — 4 (0x4, чистый RC4), и у сервисной учётки сканера — 36 (0x24). То есть в одном домене одновременно жили все четыре сценария из предыдущего раздела.

Дальше — точечная проверка с проблемной машины. Команда klist даёт куда более внятную ошибку, чем прикладной софт:

klist get HOST/nas01.logos.local

Ответ: Error calling API LsaCallAuthenticationPackage (GetTicket substatus): 0x80090342 и klist failed with 0xc00002fd: The encryption type requested is not supported by the KDC. В журнале Security на DC по тому же запросу — событие 4769 с Failure Code 0xE, то есть KDC_ERR_ETYPE_NOTSUPP. Это и есть железное подтверждение: билет не выдан именно из-за типа шифрования, а не из-за SPN, пароля или доверия.

Чем кончилось. Учётке МФУ (0x24) выставили 0x18 после того, как прошивку Kyocera обновили до версии с поддержкой AES — до этого она честно умела только RC4, и тут никакой атрибут не помог бы. Учётке SQL-сервиса меняли пароль: атрибут у неё был пуст, но и AES-ключей не было, потому что учётку завели ещё в 2011 году, когда школа стояла на старом домене и пароль с тех пор не трогали; после смены пароля ключи появились, линкед-сервер поднялся. Компьютерным учёткам с 0x1C оставили как есть — они рабочие, RC4 там уже не используется по факту, и трогать их в аварийном режиме смысла нет. Контроллер СКУД перевели с доменной на локальную аутентификацию для веб-интерфейса — производитель на письмо не ответил, а турникет на входе в школу не может ждать ответа вендора. Итог: около трёх часов работ в субботу, ноль откатов обновлений, четыре учётки приведены в порядок, одна железка признана безнадёжной. Домен целиком на AES мы закрыли уже спокойно, за две следующие недели.

Если приложение «то работает, то нет» — почти наверняка вы смотрите на молчаливый откат Kerberos на NTLM. Это не сеть. Проверяйте klist на клиенте и Failure Code 0xE в 4769 на контроллере.
Памятка: Домен «Логос-Лицея»: 29 рабочих мест и четыре разных RC4 в одном домене — схема
Памятка: Домен «Логос-Лицея»: 29 рабочих мест и четыре разных RC4 в одном домене. Открыть схему в полном размере

Почему журнал пуст, а билета всё равно нет

Начнём с того, где вообще смотреть. Диагностические события KDC пишутся в журнал System под источником KDCSVC, идентификаторы 201–209. Логика простая: 201 и 202 — предупреждения фазы аудита (клиент заявил только RC4 / у службы нет AES-ключей, и при этом msDS-SupportedEncryptionTypes у неё не задан), 203 и 204 — их же боевые версии-ошибки в фазе принуждения. 206 и 207 — предупреждения обратного случая: служба принимает только AES, а клиент AES не заявляет либо у самой учётной записи службы AES-ключей нет; 208 и 209 — соответствующие ошибки. Особняком стоит 205: оно пишется при старте службы KDC, сообщает, что в DefaultDomainSupportedEncTypes явно включены небезопасные алгоритмы, и никогда не превращается в ошибку. Событие 205 — это ваш индикатор «кто-то руками разрешил RC4 всему домену».

А теперь главное. Отсутствие этих событий не доказывает совместимость — Microsoft прямо об этом предупреждает в KB. Причин пустого журнала я насчитал пять, и каждую видел живьём. Первая: события пишет тот контроллер, который обслужил запрос, — если у вас три DC и обновления доехали не на все, а клиенты распределяются по сайтам, то ищете вы не там. Вторая: подкатегория аудита «Kerberos Service Ticket Operations» в части Failure на многих доменах не включена, и события 4769 с кодом 0xE просто не создаются. Плюс поля с типами шифрования в 4768/4769 появились только на Windows Server 2019 и новее, а на 2016 — лишь с накопительным обновлением января 2025 года: на непропатченном DC 2016 искать их бесполезно. Третья: размер журнала Security по умолчанию мал, а на боевом DC он крутится за часы — к утру понедельника пятничных записей уже нет.

Четвёртая причина — самая коварная. Значительная часть отказов происходит на стороне клиента и до KDC не доходит вообще. Linux-хост с keytab, в котором лежат только RC4-ключи; NAS или СХД, где доменная интеграция реализована сторонним стеком; Java-приложение со своей реализацией GSS-API; МФУ, где Kerberos — это три галочки в веб-интерфейсе. Такие устройства либо сами отваливаются на NTLM, либо падают с невнятной ошибкой у себя в логе, и на контроллере домена не появляется ни строчки. Пятая: часть прикладного софта настолько аккуратно проглатывает отказ Kerberos, что вы узнаёте о проблеме только по замедлению или по жалобе «долго открывается».

Практический вывод: пустой журнал — это повод для активной проверки, а не для галочки «совместимость подтверждена». Активная проверка выглядит так: с реального клиента запросить билет к реальному SPN через klist get, посмотреть тип шифрования выданного билета в klist tickets, и параллельно на DC найти соответствующее 4769. В поле Ticket Encryption Type значение 0x17 — это RC4-HMAC, 0x12 — AES256-SHA1, 0x11 — AES128-SHA1. Если после апрельских обновлений у вас в проде всё ещё встречается 0x17 — у вас есть явное исключение, и вы точно знаете, где искать.

Перед началом аудита увеличьте журнал Security на контроллерах хотя бы до 1 ГБ и включите Failure для подкатегории Kerberos Service Ticket Operations. Иначе вы будете месяц собирать данные, которых физически нет.

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

Не пытайтесь начать с того, чтобы прочитать все события руками. Microsoft выложила в открытый доступ два скрипта в репозитории Kerberos-Crypto: List-AccountKeys.ps1 показывает, какие ключи реально есть у учёток, засветившихся в журнале, а Get-KerbEncryptionUsage.ps1 разбирает 4768/4769 и показывает, какое шифрование фактически используется, с фильтром по алгоритму. Запускать на контроллере домена от администратора:

.\List-AccountKeys.ps1
.\Get-KerbEncryptionUsage.ps1 -Encryption RC4

Это даёт список кандидатов за пару минут вместо двух дней ручного разбора. Дальше уже точечно.

Мой порядок приоритетов такой. Первое — учётки с SPN, у которых атрибут содержит 0x4 или включает бит RC4: это те, кто переживёт даже июль и останется уязвимым. Второе — учётки с SPN и пустым атрибутом, у которых пароль не менялся больше пяти лет: у них с высокой вероятностью нет AES-ключей, и они сломаются молча. Третье — не-Windows: NAS, СХД, МФУ, Linux-хосты с keytab, старые аппаратные шлюзы. Четвёртое — доменные доверия, если они у вас есть: там свой атрибут поддерживаемых типов шифрования на объекте доверия, и его надо смотреть отдельно.

На что можно забить, чтобы не утонуть. На обычные пользовательские учётки без SPN — им атрибут задавать не нужно вообще, тип шифрования для их сервисных билетов определяется конфигурацией устройства. На компьютерные учётки современных Windows — они сами обновляют свой атрибут при загрузке после применения политики. На значения вроде 0x1C, если по журналам видно, что фактически используется AES: это безопасное переходное состояние, приводить его к 0x18 стоит планово, а не в аварию. И честно: гнаться за 100 % чистотой в первую неделю не надо, задача — убрать сломанное и убрать явный RC4, а не выровнять все атрибуты до одного значения.

Централизованно тип шифрования удобнее задавать групповой политикой: Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → Security Options → «Network security: Configure encryption types allowed for Kerberos». Ставите AES128_HMAC_SHA1 и AES256_HMAC_SHA1, применяете на нужное OU, перезагружаете машины — атрибуты в AD обновятся сами. Отдельным исключениям RC4 добавляете галочку RC4_HMAC_MD5 и выносите их в отдельное OU, чтобы список исключений был виден глазами, а не только через выгрузку.

Смена пароля сервисной учётки, у которой нет AES-ключей, — операция с простоем сервиса. Планируйте её в окно, а не «сейчас быстро попробуем»: половина аварий в этой теме случается не от обновлений Microsoft, а от того, что кому-то в среду днём захотелось проверить гипотезу.
Порядок действий: Порядок действий: за что браться сначала, на что можно забить — схема
Порядок действий: Порядок действий: за что браться сначала, на что можно забить. Открыть схему в полном размере

Если RC4 всё-таки нужен — оставляйте его точечно

Иногда деваться некуда: железка снята с поддержки, вендор молчит, замена стоит денег и в бюджет этого года не влезает. Это нормальная ситуация, и решение здесь есть — но правильное решение ровно одно: явно проставить msDS-SupportedEncryptionTypes на конкретной учётной записи, включив в него RC4, и держать список таких исключений на бумаге. Хоть в вики, хоть в отдельном OU с говорящим названием.

Чего делать не надо — так это возвращать RC4 всему домену через DefaultDomainSupportedEncTypes. Технически это работает и снимает симптом за пять минут. Практически это означает, что вы вернули Kerberoasting-поверхность для всех учёток без явной конфигурации, включая администраторские сервисные, и никто об этом не вспомнит следующие три года. Контроллер, кстати, будет напоминать: событие 205 в System при каждом старте службы KDC ровно об этом и сообщает. Если у вас это событие есть — у вас именно такая конфигурация.

Отдельно проговорю то, что читают невнимательно и потом строят на этом план. Июльская фаза удаляет параметр RC4DefaultDisablementPhase — то есть отменяет возможность откатить умолчание. Она не удаляет и не переписывает явные исключения на учётках. Ваш 0x4 на учётке старого сканера как работал, так и будет работать. Это одновременно и хорошая новость (аварии в июле у подготовленных не будет), и плохая (никто вас не заставит убрать долги, придётся самим).

И про krbtgt, раз уж речь о ключах. В доменах, которые поднимались давно и мигрировали по функциональным уровням, у krbtgt может не быть AES-ключей — они появляются при смене пароля этой учётки, которая происходит при поднятии функционального уровня домена до 2008 и выше. Если ваш домен когда-то стартовал на 2003 и уровень поднимали без смены пароля krbtgt, проверьте это отдельно. Симптомы будут широкие и неочевидные, а причина — на самом дне.

Если вендор устройства утверждает, что AES поддерживается, но по факту KDC видит только RC4 — сначала обновляйте прошивку, потом заводите исключение. В моей практике примерно половина таких «неподдерживающих» устройств лечится прошивкой, вышедшей три года назад.

Чего бояться не надо

Риск этой истории в интернете сильно накручен. Это не апокалипсис уровня «домен не поднимется». Windows-клиенты и серверы поддерживают AES-SHA1 в Kerberos начиная с Vista и Server 2008, компьютерные учётки обновляют свой атрибут сами, обычные пользователи вообще ничего не заметят. Реально ломается узкая полоса: старые сервисные учётки без смены пароля, не-Windows устройства и то, что кто-то однажды починил, руками вписав RC4 в атрибут. У организации на 20–50 рабочих мест вроде «Логос-Лицея» это пять-пятнадцать объектов, и найти их — работа на полдня, а не на квартал.

Второе, что успокою: откатывать обновления безопасности не надо почти никогда. Соблазн велик, симптом снимается мгновенно, а дальше вы просто переносите ту же аварию на июль, но уже без параметра отката и, скорее всего, без себя — потому что в июле в отпуске будет тот, кто знал, что откатывали. Если нужен экстренный обход прямо сейчас, ставьте точечное исключение на конкретную учётку, а не откат на весь домен и не удаление патча.

И третье, спорное — скажу как есть. Единого мнения, доводить ли домен ровно до 0x18 на каждом объекте, в сообществе нет. Часть коллег настаивает на явном атрибуте у всего, что имеет SPN; часть считает, что пустой атрибут после апреля и так означает AES-only, и плодить явные значения — это лишняя сущность, которую потом никто не сопровождает. Я на стороне вторых с одной поправкой: явно задаю атрибут только там, где нужно отклониться от умолчания — то есть на исключениях. Остальное пусть управляется умолчанием, которое Microsoft уже сдвинула в правильную сторону. Так список того, за чем надо следить, остаётся коротким и обозримым, а это в эксплуатации ценнее теоретической чистоты.

Практический минимум на ближайший месяц: включить Failure-аудит Kerberos на DC, прогнать Get-KerbEncryptionUsage.ps1 с фильтром по RC4, выписать список объектов, проверить событие 205 на каждом контроллере. Четыре пункта, полдня работы, и вы точно знаете своё положение.

Частые вопросы

У сервисной учётки поле msDS-SupportedEncryptionTypes пустое. Это плохо?

Само по себе — нет, но после обновлений от 14 апреля 2026 года пустое значение трактуется контроллером как «только AES-SHA1» (0x18), а не как «RC4 и AES», как было раньше. Если у учётки при этом физически нет AES-ключей — билета она не получит. Проверьте дату последней смены пароля: у учёток, созданных давно и без смены пароля, AES-ключей нет, и создаются они только сменой пароля.

В журнале нет ни одного события KDCSVC 201–209. Значит, всё совместимо?

Нет, и Microsoft об этом предупреждает прямо в KB5073381. События пишет только тот контроллер, который обслужил запрос; журнал Security на боевом DC может ротироваться за часы; Failure-аудит подкатегории Kerberos Service Ticket Operations часто выключен; а отказы не-Windows устройств с keytab вообще не доходят до KDC. Пустой журнал — повод для активной проверки через klist get с реальных клиентов, а не подтверждение готовности.

Можно ли просто вернуть RC4 через реестр и не мучиться?

До июля 2026 можно было выставить RC4DefaultDisablementPhase (HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters) в 0 или 1 и перезагрузить DC, но июльские обновления поддержку этого параметра убрали. Возврат RC4 всему домену через DefaultDomainSupportedEncTypes работает, но возвращает поверхность атаки Kerberoasting для всех учёток без явной настройки — контроллер будет писать об этом событие 205 при каждом старте KDC. Правильный обход — явное исключение на конкретной учётной записи.

Июльская фаза отключит RC4 полностью, включая мои явные исключения?

Нет. Июльские обновления убирают только параметр отката RC4DefaultDisablementPhase, то есть возможность вернуть прежнее умолчание на уровне домена. Учётные записи с явно заданным msDS-SupportedEncryptionTypes, включающим бит RC4 (0x4), продолжат работать как раньше. Это и означает, что убирать такие исключения придётся самостоятельно — автоматически они не отвалятся.

Как быстро понять, что билет не выдан именно из-за типа шифрования?

С проблемного клиента выполните klist get с нужным SPN, например klist get HOST/server.domain.local. Ошибка 0xc00002fd с текстом про неподдерживаемый KDC тип шифрования — прямое попадание. Подтверждение на контроллере — событие 4769 с Failure Code 0xE (KDC_ERR_ETYPE_NOTSUPP). Если код ошибки другой, ищите проблему в SPN, пароле или доверии, а не в RC4.

Нужно ли задавать msDS-SupportedEncryptionTypes обычным пользователям?

Нет. Для пользовательских учётных записей без SPN этот атрибут задавать не требуется — тип шифрования сервисных билетов и ключей сессии определяется конфигурацией устройства. Сосредоточьтесь на объектах с SPN, компьютерных учётках старых систем, объектах доверия и не-Windows интеграциях.

Столкнулись с похожей задачей? Обращайтесь — решим

Если у вас происходит что-то из описанного в этой статье — или любая другая проблема с ИТ-инфраструктурой, — обращайтесь в любое время. Мои специалисты и я лично разберём ситуацию, найдём настоящую причину и доведём до решения.

Возьмёмся и за разовую задачу, и за постоянное обслуживание. Первичная консультация — бесплатно и без обязательств.

📞 +7 903 729-62-41 💬 MAX: +7 903 729-62-41 ✈ Telegram @ITfresh_Boss

С уважением, Семёнов Евгений Сергеевич, директор «АйТи Фреш» — IT-аутсорсинг для компаний до 50 рабочих мест, 15+ лет практики

Источники

© ООО «АйТи-Фреш» · Москва · Все статьи