Вопрос или проблема
Я использую сертификаты, созданные в XCA, для авторизации пользователей eap-tls wifi в NPS.
Все работало до февраля, когда сервер обновился до KB5014754.
Теперь я перенастраиваю сертификаты, чтобы иметь новый OID 1.3.6.1.4.1.311.25.2 со значением SID контроллера домена пользователя. Я добавил новую строку X509v3 Subject Alternative Name:
otherName:ms-ntds-sec-ext;UTF8:S-1-5-56-3494754337-388234544-429167765-1670
X509v3 Subject Alternative Name выглядит так:
otherName:msUPN;UTF8:[email protected]
otherName:ms-ntds-sec-ext;UTF8:S-1-5-56-3494754337-388234544-429167765-1670
Это не работает. На контроллере домена в системном журнале событий появляется событие с Id 39 KDC ошибка.
Что я делаю не так?
1.3.6.1.4.1.311.25.2 не является подтипом OtherName – это тип расширения. SID имеет свое собственное расширение X.509v3, а не хранится как имя внутри расширения subjectAltName.
Расширение имеет аналогичную структуру с subjectAltName, но отличается из-за другого OID.
Вот как выглядит фактическая структура, согласно dumpasn1:
1223 51: SEQUENCE {
1225 3: OBJECT IDENTIFIER subjectAltName (2 5 29 17)
1230 44: OCTET STRING, encapsulates {
1232 42: SEQUENCE {
1234 40: [0] {
1236 10: OBJECT IDENTIFIER
: userPrincipalName (1 3 6 1 4 1 311 20 2 3)
1248 26: [0] {
1250 24: UTF8String '[email protected]'
: }
: }
: }
: }
: }
1276 77: SEQUENCE {
1278 9: OBJECT IDENTIFIER ntdsCASecurityExt (1 3 6 1 4 1 311 25 2)
1289 64: OCTET STRING, encapsulates {
1291 62: SEQUENCE {
1293 60: [0] {
1295 10: OBJECT IDENTIFIER
: ntdsObjectSID (1 3 6 1 4 1 311 25 2 1)
1307 46: [0] {
1309 44: OCTET STRING
: 'S-1-5-21-1376704245-510857609-3386413621-500'
: }
: }
: }
: }
: }
(Это тестовый сертификат, который я нашел на GitHub.)
Насколько я могу судить, XCA не поддерживает определение пользовательских расширений. Вам нужно будет использовать конфигурацию OpenSSL в ручном режиме (или настроить подчиненный CA в службах сертификатов AD).
С OpenSSL это может выглядеть примерно так (учтите, что я пишу это по памяти, поэтому синтаксис может быть полностью ошибочным в некоторых местах):
[extensions]
subjectAltName = blah
ms-ntds-sec-ext = ASN1:SEQUENCE:ntds_ext
[ntds_ext]
1 = IMP:0, SEQUENCE:ntds_sid
[ntds_sid]
type = OID:ntdsObjectSID
values = IMP:0, SEQUENCE:ntds_sid_value
[ntds_sid_value]
1 = OCTETSTRING:ASCII:S-1-2-345678
Ответ или решение
Для решения вашей задачи важно понять, что обновление Windows, описанное в патче KB5014754, изменило подход к сертификационной аутентификации. Это связано с тем, что новые требования к сертификатам теперь включают использование OID 1.3.6.1.4.1.311.25.2 для соответствия требованиям директивы, указанной в патче.
Теоретическая часть
В контексте использования сертификатов для аутентификации в сетях Wi-Fi с помощью EAP-TLS и NPS, сертификаты настраиваются для защиты передачи данных и подтверждения подлинности пользователей. После обновления KB5014754 сертификаты должны содержать специфическую расширенную структуру, которая включает SID (идентификатор безопасности) контроллера домена. Это OID используется не в качестве SubType внутри расширения subjectAltName, как это может показаться, а как самостоятельное расширение.
OID 1.3.6.1.4.1.311.25.2 представляет собой другое расширение, известное как ntdsCASecurityExt, который использует структуру X.509v3 для кодирования SID объекта. Это отличает его от стандартного subjectAltName.
Пример
Вы проводите генерацию сертификатов с использование XCA, однако XCA не поддерживает возможность добавить необработанные пользовательские расширения, что делает невозможным выполнение требований патча KB5014754 напрямую из XCA. Поэтому, вам потребуется использовать OpenSSL для создания таких сертификатов с необходимой структурой или обратиться к средствам Active Directory Certificate Services для создания подчиненного центра сертификации.
Практическое применение
Использование OpenSSL
Используя OpenSSL, можно создать сертификат с нужной конфигурацией следующим образом:
- Создайте конфигурационный файл OpenSSL. В этом файле вы должны определить нужные расширения и их содержание согласно необходимым спецификациям. Пример конфигурационного файла:
[extensions]
subjectAltName = blah
ms-ntds-sec-ext = ASN1:SEQUENCE:ntds_ext
[ntds_ext]
1 = IMP:0, SEQUENCE:ntds_sid
[ntds_sid]
type = OID:ntdsObjectSID
values = IMP:0, SEQUENCE:ntds_sid_value
[ntds_sid_value]
1 = OCTETSTRING:ASCII:S-1-5-21-1376704245-510857609-3386413621-500 # ваш SID- Используйте данный конфигурационный файл при генерации сертификата с помощью команды OpenSSL, например:
openssl req -new -x509 -days 365 -key yourkey.key -out yourcertificate.pem -config yourconfig.cnfИспользование AD Certificate Services
Если OpenSSL представляется слишком сложным или неподходящим, вы можете задействовать AD Certificate Services. Это решение более управляемое в среде Windows и позволяет легче интегрировать новые требования патча.
-
Настройте подчиненный центр сертификации, который бы учитывал требования OID 1.3.6.1.4.1.311.25.2 в процессе генерации сертификатов.
-
Обратитесь к документации Microsoft для настройки специфических шаблонов сертификатов, учитывающих SID и расширение ntdsCASecurityExt.
Заключение
Правильная настройка сертификатов, учитывающих последние изменения в требованиях безопасности Microsoft, является необходимым элементом для поддержки повышенной безопасности в вашей сети. Используя OpenSSL или Active Directory Certificate Services, вы сможете соблюсти необходимые требования и обеспечить стабильное функционирование ваших систем после внедрения обновлений Windows. Точное понимание и применение изменений помогут вам избежать ошибок и обеспечить соответствие новым требованиям безопасности.