4.1. Подготовка инфраструктуры

Aladdin SecurLogonУстановка и развёртываниеAladdin SecurLogon

Требования к техническому обеспечению

Минимальные требования к техническому обеспечению ПК с установленным Aladdin SecurLogon®, при которых обеспечивается корректная работа программы, приведены в таблице (Требования к техническому обеспечению).

Требования к техническому обеспечению

Компонент	Минимальная конфигурация
Свободное дисковое пространство	Не менее 200 МБ
Оперативная память	Не менее 2 ГБ
USB-интерфейс	USB 2.0 тип А или совместимые

Требования к совместимости

Поддерживаемые устройства аутентификации

Для надёжного хранения и обработки ключевой информации могут быть использованы следующие модели устройств аутентификации (токенов, электронных ключей) и смарт-карт ридеров:

Семейство	Модели
JaCarta-3	JaCarta-3 PKI; JaCarta-3 ГОСТ; JaCarta-3 PKI/ГОСТ; JaCarta-3 ГОСТ/SecurBIO®; JaCarta-3 PKI/ГОСТ/SecurBIO
JaCarta-2	JaCarta-2 SE; JaCarta-2 ГОСТ; JaCarta-2 PRO/ГОСТ; JaCarta-2 PKI/ГОСТ; JaCarta-2 PKI/BIO/ГОСТ
JaCarta (USB-токены и смарт-карты)	JaCarta LT; JaCarta PRO; JaCarta PKI; JaCarta SecurBIO; JaCarta SF/ГОСТ; JaCarta PRO/ГОСТ; JaCarta PKI/ГОСТ; JaCarta PKI/BIO; JaCarta PKI/SecurBIO; JaCarta PKI/Flash; JaCarta PKI/ГОСТ/Flash
Ридеры и смарт-карты	Aladdin LiveOffice®; Aladdin SecurBIO Reader JCR761-001; Aladdin SecurBIO Reader JCR781
Сторонние токены	Рутокен ЭЦП 2.0/3.0; eToken PRO (Java)

Поддерживаемое ПО

Пользователи Aladdin SecurLogon® имеют возможность работать со следующими доменными службами:

Microsoft Active Directory;
Samba Domain Controller;
ALD PRO;
FreeIPA.

Пользователи Aladdin SecurLogon® имеют возможность работать со следующими центрами сертификации (далее по тексту — ЦС):

Aladdin Enterprise Certificate Authority;
Dog Tag Certificate System;
Microsoft Certificate Services.

Требования к пользовательским сертификатам

Для успешной двухфакторной аутентификации с использованием сертификатов необходимо выполнение следующих условий:

на токен необходимо записать открытый ключ (сертификат) и закрытый ключ пользователя, помещенные в один контейнер;
пользовательские сертификаты должны содержать следующие поля:

i. “Поставщик (Issuer)” — поле идентификации ЦС, выдавшего сертификат владельцу:
```
- CN (CommonName) — наименование поставщика, подписывающего сертификат;

- DC (DomainComponent) — компонент DNS имени (адреса) владельца сертификата, указывается несколько раз, в каждом случае как часть DNS пути;
```
Примечание. Пример заполненного поля Issuer:
```
*CN = DC_WIN-CA*
*DC = dc*
*DC = test*
```
ii. “Субъект (Subject)” — поле идентификации субъекта (владельца) сертификата:
```
- CN (CommonName) — наименование субъекта (владельца) сертификата;
- DC (DomainComponent) — компонент DNS имени (адреса) владельца сертификата, указывается несколько раз, в каждом случае как часть DNS пути;
```
Примечание. Пример заполненного поля Subject:
```
*CN = Domain User Test*
*DC = dc*
*DC = test*
```
iii. дополнительное имя субъекта SAN (SubjectAltName) — дополнительные реквизиты владельца сертификата:
```
- OtherName (Другое имя) — логин и домен пользователя по следующему шаблону: Principal Name=login@domain.ru.
```
Примечание. Пример заполненного поля SubjectAlternativeName | Other Name:
```
*Principal Name=<d_user@dc.test>*
```
- у сертификата должен быть установлен период действия;
- в сертификате должны быть указаны CRL или OCSP (при наличии).