Обновить билет kerberos в домене для компьютера

Обновлено: 06.07.2024

Kerberos — сетевой протокол аутентификации, позволяющий передавать данные через незащищённые сети для безопасной идентификации. Более подробно узнать об этом протоколе можете в статье про Kerberos на Wikipedia. В домене ALT Linux этот протокол занимает важное место, так как обеспечивает инфраструктуру для аутентификации пользователей (для входа в систему, для использования сетевых ресурсов по протоколу SMB и доступа в Интернет через прокси-сервер).

Сервер аутентификации выполняет одну функцию: получает запрос, содержащий имя клиента, запрашивающего аутентификацию, и возвращает ему зашифрованный TGT (Ticket Granting Ticket, билет для получения билета). Затем пользователь может использовать этот TGT для запроса дальнейших билетов на другие службы. Часто специалисты билет называют «тикетом».

С практической точки зрения нас интересуют нюансы использования и отладки Kerberos.

Содержание

Итак, при создании ALT-домена настраивается также и служба Kerberos на сервере krb5kdc . Основной её чертой является крайняя немногословность (по соображениям безопасности), что затрудняет отладку.

В модуле «Домен» веб-интерфейса показывается текущее состояние в том числе и службы Kerberos. Если всё в порядке, то показывается

Альтернативный способ получить статус домена:

В ALT Linux Kerberos хранит все свои данные в LDAP. Поэтому для успешной работы Kerberos требуется как запуск сервера LDAP slapd , так и заполнение структуры базы для Kerberos (при проверке в LDAP ищутся записи класса krbRealmContainer ).

Если служба krb5kdc не запущена, то попробуйте запустить её вручную:

Настройка сервера Kerberos (KDC) осуществляется в файле /var/lib/kerberos/krb5kdc/kdc.conf

Там же видно, что журналы kdc и admin_server прописываются в секции [logging] и через syslogd попадают в файл /var/log/messages .

Внимание! Если служба krb5kdc не может быть запущена из-за того, что записи в LDAP не созданы (такое случалось на Шестой платформе, когда домен создавался до того, как настраивался сервер DHCP; в Седьмой платформе это исправлено), то нужно настроить DHCP и попробовать создать домен с другим именем.

Для заведения пользователей и в базе Kerberos в файле /etc/sysconfig/system должна быть указана роль сервера master:

Проверить, заведён ли пользователь можно программой kadmin.local .

Проверка заведённых принципалов:

Обратите внимание, выводятся как обычные пользователи, так и службы. Последние идут с FQDN (полным доменным именем) сервера, указанным через / от названия службы.

kadmin.local работает и при выключенной службе krb5kdc .
вы можете запустить kadmin.local без параметров и указывать команды прямо в появившейся командной строке
перечень команд можно посмотреть в man kadmin.local
команда listprinc может указываться с шаблоном. Например

Authenticating as principal root/admin@TEST.ALTLINUX with password. cas@TEST.ALTLINUX

завести принципала в Kerberos можно командой

Вообще рекомендуется использовать функции alterator-kdc-princ-functions.

Далее проверяем заведённого пользователя (пусть у нас есть принципал cas):

И смена пароля у принципала Kerberos:

Для использования утилит работы с билетами Kerberos на стороне клиента необходимо установить пакет krb5-kinit .

Укажите пароль и нажмите Enter

Обратите внимание, что билет для службы krbtgt выдан на сутки. Как управлять сроком выдаваемого билета и его обновлением, будет рассказано ниже.

Одним из основных требований успешного использования Kerberos является обеспечение одинакового времени на сервере и клиенте. В рамках ALT-домена эта задача решена использованием синхронизации по RFC 867. Для этого на сервере включается через xinetd daytime-tcp:

А на клиенте — служба settime-rfc867 :

Тикет Kerberos по умолчанию выдаётся не более чем на 1 сутки. Если хотите выдавать тикет больше, чем на сутки, пропишите:

В новых версиях Kerberos слабые алгоритмы (например, des-cbc-crc:afs3 ) по умолчанию запрещены к использованию. А на старых системах (клиентах или серверах на Пятой или Шестой платформе) они используются. Чтобы включить их поддержку, на новой системе пропишите в раздел [libdefaults] файла /etc/krb5.conf строку

Без этого с билетами Kerberos (и, как следствие с монтированием каталогов и доступом к прокси-серверу) будут проблемы.

Если в журнале при запуске службы krb5kdc появляется ошибка:

то это означает, что сервер LDAP ( slapd ) ещё не успел проинициализироваться для доступа krb5kdc. Увеличьте уровень загрузки службы krb5kdc с 40 до 41 (между запуском этих служб появится служба anacron ):

Отображает список кэшированных в настоящее время билетов Kerberos.

Для выполнения всех параметров этой команды необходимо быть по крайней мере администратором домена или эквивалентным ему.

Синтаксис

Параметры

Параметр	Описание
— LH	Обозначает старшую часть локального уникального идентификатора (LUID) пользователя, выраженную в шестнадцатеричном формате. Если не указано ни параметр – LH , ни -Li , команда по умолчанию принимает значение LUID пользователя, выполнившего вход.
-Li	Обозначает младшую часть локального уникального идентификатора (LUID) пользователя, выраженную в шестнадцатеричном формате. Если не указано ни параметр – LH , ни -Li , команда по умолчанию принимает значение LUID пользователя, выполнившего вход.
описания	Список текущих кэшированных билетов (TGT) и билетов службы для указанного сеанса входа в систему. Это параметр по умолчанию.
tgt	Отображает первоначальный TGT Kerberos.
Очистка	Позволяет удалить все билеты указанного сеанса входа в систему.
сеансы	Отображает список сеансов входа на этот компьютер.
kcd_cache	Отображает сведения кэша ограниченного делегирования Kerberos.
get	Позволяет запросить билет на целевом компьютере, заданном именем участника-службы (SPN).
add_bind	Позволяет указать предпочтительный контроллер домена для проверки подлинности Kerberos.
query_bind	Отображает список кэшированных предпочитаемых контроллеров домена для каждого домена, с которым связывался протокол Kerberos.
purge_bind	Удаление кэшированных предпочтительных контроллеров домена для указанных доменов.
кдкоптионс	Отображает параметры центр распространения ключей (KDC), указанные в RFC 4120.
/?	Отображает справку для этой команды.

Remarks

Если параметры не указаны, klist извлекает все билеты для текущего пользователя.

В параметрах отображаются следующие сведения.

билеты . перечисляет в настоящее время кэшированные билеты служб, с которыми вы прошли проверку подлинности, с момента входа. Отображает следующие атрибуты всех кэшированных билетов:

Логонид: LUID.

Клиент: Объединение имени клиента и имени домена клиента.

Сервер: Объединение имени службы и имени домена службы.

Тип шифрования кербтиккет: Тип шифрования, используемый для шифрования билета Kerberos.

Флаги билета: Флаги билета Kerberos.

Время начала: Время, в течение которого билет действителен.

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

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

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

TGT — список первоначального TGT-билета Kerberos и следующие атрибуты кэшированного билета:

Логонид: Указывается в шестнадцатеричном формате.

ServiceName: krbtgt

TargetName <SPN> : krbtgt

Имя_домена: Имя домена, который выдает TGT.

Таржетдомаиннаме: Домен, которому выдан билет TGT.

Алттаржетдомаиннаме: Домен, которому выдан билет TGT.

Флаги билета: Адрес и целевое действие и тип.

Ключ сеанса: Длина ключа и алгоритм шифрования.

Время начала: Время на локальном компьютере, на которое был запрошен билет.

EndTime: Время, когда билет стал недействительным. Когда билет пройдет на этот раз, он больше не может использоваться для проверки подлинности в службе.

Реневунтил: Крайний срок для продления билета.

Тимескев: Разница во времени с центр распространения ключей (KDC).

Енкодедтиккет: Закодированный билет.

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

Логонид: Указывается в шестнадцатеричном формате.

сеансы . позволяет вывести список и отобразить сведения обо всех сеансах входа на этом компьютере.

Логонид: Отображает сеанс входа в систему только по заданному значению. Если этот параметр не указан, отображаются все сеансы входа на этот компьютер.

kcd_cache — позволяет отображать сведения кэша ограниченного делегирования Kerberos.

Логонид: Отображает сведения о кэше для сеанса входа с указанным значением. Если не указано, отображает сведения о кэше для сеанса входа текущего пользователя.

Get — позволяет запросить билет в целевом объекте, указанном в имени субъекта-службы.

Логонид: Запрашивает билет с помощью сеанса входа с указанным значением. Если не указано, запрашивает билет с помощью сеанса входа текущего пользователя.

кдкоптионс: Запрашивает билет с заданными параметрами KDC

add_bind — позволяет указать предпочтительный контроллер домена для проверки подлинности Kerberos.

query_bind — позволяет отображать кэшированные, предпочитаемые контроллеры домена для доменов.

purge_bind — позволяет удалять кэшированные, предпочитаемые контроллеры домена для доменов.

кдкоптионс — для текущего списка параметров и их объяснений см. RFC 4120.

Примеры

Чтобы запросить кэш билетов Kerberos для определения отсутствия билетов, если целевой сервер или учетная запись имеют ошибку или если тип шифрования не поддерживается из-за ошибки с ИДЕНТИФИКАТОРом события 27, введите:

Чтобы узнать о характере каждого билета предоставления билетов, который кэшируется на компьютере для сеанса входа в систему, введите:

Чтобы очистить кэш билетов Kerberos, выйдите из системы, а затем снова войдите в систему, введите:

Чтобы диагностировать сеанс входа в систему и найти Логонид для пользователя или службы, введите:

Чтобы диагностировать сбой ограниченного делегирования Kerberos и найти последнюю обнаруженную ошибку, введите:

Чтобы определить, может ли пользователь или служба получить билет на сервере или запросить билет для определенного имени участника-службы, введите:

Для диагностики проблем репликации между контроллерами домена обычно требуется клиентский компьютер, предназначенный для определенного контроллера домена. Чтобы нацелить клиентский компьютер на конкретный контроллер домена, введите:

Чтобы запросить, к каким контроллерам домена недавно обращались этот компьютер, введите:

Чтобы повторно обнаружить контроллеры домена или очистить кэш перед созданием новых привязок к контроллеру домена с помощью klist add_bind , введите:

Почем не отрабатывает команда "kinit --renew"

sudo писал(а):
КОД: ВЫДЕЛИТЬ ВСЁ * */1 * * * root /usr/bin/kinit --renew > /dev/null 2>&1
Не подойдёт, так как kinit требует введения пароля, что в использовании Cron невозможно.

У меня китайская FreeBSD, в ней все возможно.

Issued Expires Principal
May 11 09:49:51 >>>Expired<<< krbtgt/DOMAIN.LOCAL@DOMAIN.LOCAL

Вводим тупо. Не дает обновиться.

Оно и понятно почему - потому, что хоть иногда надо читать маны.

-R, --renew
Try to renew ticket. The ticket must have the `renewable' flag
set, and must not be expired.

Возьмем новый билет и ставим флаг

Обновим билет пару раз для наглядности (прошу заметить, что никаких паролей не требуется)

Issued Expires Principal
Jun 16 08:21:11 Jun 16 18:21:11 krbtgt/DOMAIN.LOCAL@DOMAIN.LOCAL

Особое внимание прошу обратить на время выдачи билетов и их время жизни. Кто сказал, что невозможно ?

Вы бы лучше другую мою ошибку заметили, что написав команду под рутом crontab -e в конфигурации cron'a я указал root , что возможно только при правке системного crontab

Авторизация FreeBSD heimdal в AD используя ключи. (Согласен с автором . 3 вариант самый оптимальный, но FreeNAS после ребута не хотел принимать старый билетик и приходилось опять же ручками получать новый)

Статья написана в стиле "пометка что-бы не забыть", многие моменты подразумеваются известными и акцент делается на "подводные камни". В интернете по этому вопросу увы ничего не нашел, так же бьються над аналогичными проблемами ребята из Juniper Networks (не подсоединяет к домену) и IBM ( не получает список пользователей).

Для того, что бы службы на FreeBSD могли получать TGS (Ticket Granting Service - тикет на доступ к службе)
от Active Directory Key Distribution Center необходимо что бы в системе FreeBSD был TGT (Ticket Granting Ticket - тикет на получение тикетов).

В стандартном варианте настройке родного Kerberos (Heimdal 0.x_чего_то_там) на FreeBSD (вплоть до версии 7.1.) используется файл

/etc/krb5.conf [man krb5.conf]

и в файле-кеше ключей (обычно /tmp/krb5cc_0, т.к. все делается из под рута) появляется TGT, используя который
другие службы (pam_krb5, ldap, samba) могут обращаться к службам AD.

Для автоматизации получения ключа используются разные методы. Все они используют cron, для периодического получения/обновления ключа.

1.) Самый простой это

КОД: ВЫДЕЛИТЬ ВСЁ echo MyPassword | kinit DomainAdministrator

Метод прост, но "светит пароль" администратора, что не является хорошим тоном.

2.) Второй способ описан в статье Microsoft "Step-by-Step Guide to Kerberos 5 (krb5 1.0) Interoperability"
Заключается метод в следующем: создается пользовательский аккаунт, через который будет авторизоваться сервер.
С использованием команды из пакета Windows Resource Kit или Windows Support Tools

КОД: ВЫДЕЛИТЬ ВСЁ C:>Ktpass.exe -princ HOST/my_bsd_hostname@NT-DNS-REALM-NAME -mapuser user_account_for_bsd -pass account_password_for_bsd -out unixmachine.keytab

создается файл unixmachine.keytab в который пишутся ключи, которые могут быть использованы для авторизации без пароля,
используя команду на FreeBSD

КОД: ВЫДЕЛИТЬ ВСЁ kinit -k HOST/my_bsd_hostname@NT-DNS-REALM-NAME

3.) Наиболее элегантный.

Для получения ключей используется Samba 3.xx, которая чаще всего используется в связке с Active Directory.
Метод также подразумевает получение ключей в /etc/krb5.keytab и авторизацию через
КОД: ВЫДЕЛИТЬ ВСЁ kinit -k

для получения ключей наобходимо использовать

КОД: ВЫДЕЛИТЬ ВСЁ net -U DomainAdministrator net ads keytab ADD HOST

эта команда получает ключи в файл (по умолчанию) /etc/krb5.keytab
КОД: ВЫДЕЛИТЬ ВСЁ Vno Type Principal
5 des-cbc-crc HOST/my_bsd_hostname@NT-DNS-REALM-NAME
5 des-cbc-md5 HOST/my_bsd_hostname@NT-DNS-REALM-NAME
5 arcfour-hmac-md5 HOST/my_bsd_hostname@NT-DNS-REALM-NAME
Требования: Реализация Kerberos на FreeBSD heimdal не использует (пока что) tcp для Kerberos запросов, поэтому пользователь
DomainAdministrator должен быть в одной единственной группе (Domain Admins) и по возможности в самом верхнем OU.
Иначе будут ошибки

КОД: ВЫДЕЛИТЬ ВСЁ response too big for UDP, use TCP instead

Получив ключи, следует произвести некоторые магические действия с Active Directory.
В моем случае был Microsoft Windows Server 2008 Enterprise SP1, по традиции при его выпуске была допущена ошика
в реализации kerberos из-за чего при использовании

КОД: ВЫДЕЛИТЬ ВСЁ kinit -k HOST/my_bsd_hostname@NT-DNS-REALM-NAME

Microsoft Windows Server 2008 всех версиий возвращает KRB5KDC_ERR_C_PRINCIPAL_UNKNOWN из-за неправильной
интерпретации косой черты ("/") в имени принципала.
Лечится это частным патчем от Microsoft [KB951191], который Microsoft почему то высылает только по запросу
на электронный адрес, да еще в придачу защифрованным паролем. (актуально на 15.05.2009)

Далее для авторизации через kinit к сожалению не используется аттрибут serivcePrincipalName объекта
типа Computer, который создается при подключении Samba к домену и чьи ключи Samba помещает в /etc/krb5.keytab.
Для того, что бы этот аккаунт использовался для авторизации необходимо сделать два вещи

а.) установить аттрибут userPrincipalName в HOST/my_bsd_hostname@NT-DNS-REALM-NAME (по умолчанию он пуст для объекта Computer)
б.) установить отметку "Без предварительной проверки Kerberos". Это легче сказать чем сделать, т.к. диалоговое окно для таких
манипуляций доступно только для объектов типа User. Отметка это лишь бит в целом числе, поэтому.
Я использовал ADSI Edit (входит в поставку Windows Server 2008) для правки аттрибута userAccountControl объекта типа Computer, представляющего
FreeBSD в домене:

КОД: ВЫДЕЛИТЬ ВСЁ userAccountControl = 0x411000 (4263936 decimal) [ WORKSTATION_TRUST_ACCOUNT | DONT EXPIRE PASSWD | DONT REQUIRE PREAUTH ]

После установки патча, манипуляций с объектов Computer account, представляющего FreeBSD и прописав в cron

КОД: ВЫДЕЛИТЬ ВСЁ 0 * * * * /usr/bin/kinit --renew
* 2 * * * /usr/bin/kinit -k HOST/my_bsd_hostname@NT-DNS-REALM-NAME

Server: krbtgt/NT-DNS-REALM-NAME@NT-DNS-REALM-NAME
Ticket etype: arcfour-hmac-md5, kvno 2
Auth time: May 19 11:10:22 2009
End time: May 19 21:10:22 2009
Renew till: May 26 11:10:22 2009
Ticket flags: forwardable, renewable, initial

Идентификация и доступ в Active Directory

Доменные службы Active Directory (Active Directory Domain Services, AD DS ) обеспечивают идентификацию и доступ (Identity and Access, IDA ) для корпоративных сетей. Давайте посмотрим каким требованиям и критериям должна соответствовать структура IDA:

Она должна хранить информацию, о всех объектах Active Directory, среди которых: пользователи, группы безопасности, компьютеры, принтеры и другие объекты идентификации. Под объектом идентификации (identity) подразумевается, некое представление сущности, в задачи которой входит выполнение каких-либо действий в корпоративной сети. Простой пример, есть пользователь Вася и он работает с документами в общей папке на сервере. Эти документы имеют защиту на доступ, который определяет список контроля доступа (Access Contro l List, ACL). Доступом у нужным файлам, управляет подсистема безопасности сервера, где лежит папка, и при обращении к ней он производит сравнение объекта идентификации пользователя с теми объектами, которые присутствуют в его списке ACL, и уже на основании этого, он принимает решение предоставить или запретить пользователю доступ. Так как службы, компьютеры, группы и другие объекты выполняют определенные вещи в локальной сети, то у каждого из них есть свой объект идентификации. Данный объект содержит много информации, уникальной для каждого из них, например, имя пользователя, его идентификатор безопасности (Security Identifier, SID), пароль. Так, что хранилище объектов идентификации, является неотъемлемой частью Identity and Access. Все данные в Active Directory, располагаются в каталоге AD, которым управляет контроллер домена.
Проверка подлинности объекта идентификации. Тут общий принцип такой, когда пользователь обращается к документу, то сервер его ему не покажет, пока тот, не подтвердит подлинность объекта идентификации, который фигурирует в запросе. Чтобы все это сделать, у пользователя есть некая секретная информация, которая известна ему и инфраструктуре IDA, вот эти данные как раз и сравниваются с теми, что есть в хранилище объектов идентификации в момент проверки подлинности.

Протокол аутентификации kerberos

Чем хороша операционная система Windows, так это тем, что она очень унифицированная, за счет интерфейса SSPI (Security Support Provider Interface). SSPI - это механизм операционной системы Windows в задачи которого идет, предоставление приложениям не зависеть от различных решений протоколов аутентификации, позволяя работать абсолютно с любыми из них, если перефразировать, то любое приложение может использовать любой протокол аутентификации. Еще очень большой плюс интерфейса SSPI, то что он позволяет изолировать сетевой транспорт от протоколов аутентификации, если по простому, то эти протоколы становятся независимыми от протоколов передачи данных по сети, и приложению вообще до лампочки, какой из них использовать.

Именно за счет провайдеров Security Support Provider (SSP) сделан механизм аутентификации. Операционная система Windows уже имеет встроенные модули, но никто не мешает программистам, взять и написать свой и подключить его к SSPI

Протокол аутентификации kerberos пришел на смену устаревшему и уже с точки зрения не безопасному, протоколу NTLM, он был основным до Windows 2000. Протокол Kerberos всегда используется в построении механизмов Single Sign-On. В его основе лежит такой принцип, что если двум участникам известен некий ключ и у них есть возможность подтвердить это, то они смогут однозначно идентифицировать друг друга.

Пользовательский ключ - когда системный администратор заводит новую учетную запись пользователя, значение его пароля используется при создании ключа, он хранится рядом с самим объектом пользователя AD. И как написано выше, это ключ знают контроллер домена и пользователь, две стороны.

Системный ключ - в момент ввода компьютера в домен Active Directory он так же получает свой уникальный пароль, на его основании и создается ключ, все как у пользователя. Еще отмечу, что данный пароль каждый месяц автоматически меняется, поэтому старые компьютеры, которые долго не были включены, не могут пройти аутентификацию в домене, так как потеряны доверительные отношения.

Ключ службы (service key) - тут все просто, очень часто системные администраторы для запуска службы создают отдельного доменного пользователя, в следствии чего служба получит его ключ, но если она запускается под учетной записью системы (LocalSystem), то получит ключ компьютера.

Междоменный ключ (inter-realm key). Этот ключ обеспечивает междоменную аутентификацию и используется для обеспечения доверительных отношений в среде Aсtive Directory.

Давайте рассматривать каким образом происходит проверка подлинности Kerberos в домене Active Directory. И так пользователь или же компьютер, пытаются войти в локальную сеть домена, именно протокол Kerberos удостоверяется в подлинности указанных реквизитов, в следствии чего выдает пакет данных, а точнее билет или тикет (Ticket), по правильному он называется TGT (Ticket Granting Ticket).

Ticket (билет) является зашифрованным пакетом данных, который выдается доверенным центром аутентификации, в терминах протокола Kerberos — Key Distribution Center (KDC, центр распределения ключей). TGT шифруется при помощи ключа, общего для служб KDC, то есть клиент не может прочитать информацию из своего билета. Этот билет используется клиентом для получения других билетов.

Теперь когда у пользователя или компьютера есть билет TGT, он может его предоставлять любому сервису или ресурсу. В дальнейшем, при обращении к отдельным ресурсам сети, пользователь, предъявляя TGT, получает от KDC удостоверение для доступа к конкретному сетевому ресурсу — Service Ticket (TGS). Данный билет будет идентифицировать прошедшего проверку подлинности пользователя на сервере. Пользователь предоставит TGS билет для доступа к серверу, он его примет и подтвердит прохождение проверки подлинности. Вот тут Kerberos и показывает все свои достоинства, ему требуется лишь один сетевой вход и после получения им билета TGT он проходит проверку подлинности для всего домена целиком, что дает ему возможность получать идентификационные билеты на доступ к службам, не вводя ни каких учетных данных, все эти операции осуществляются за счет встроенных клиентов и служб Kerberos в Kerberos.

Сам Ticket-Granting Service состоит из двух вещей, первая это копия сессионного ключа и информация о клиенте. Все эти данные зашифрованы ключом, общим между сервисом к которому идет обращение и KDC. Это означает, что пользователь не сможет посмотреть эти данные, а вот служба или сервер к которому идет обращение да.

За счет высокого уровня безопасности протокола Kerberos, при передаче данных вы не увидите пароли или значения хэш в открытом виде. Еще одним требованием к работе с данным протоколом, выступает системное время, которое не может расходится с временем на контроллере домена более чем 5 минут

Сам SPN будет хранится в атрибуте Service-Principal-Name, у той учетной записи к которой он привязан и под которым стартует служба. Таким образом, SPN связывает воедино все части процесса. Клиент знает, к какой службе он хочет получить доступ. И при запросе ключа он строит строку SPN, к примеру, при помощи функции DsMakeSpn. Сервер KDC, получив эти данные, может найти учетную запись, под которой стартует эта служба, и, используя ключ этой учетной записи из Active Directory, создать билет доступа к службе и зашифровать его этим ключом.

Как производится настройка SPN мною уже была описана в одной из статей.

Детальная проверка kerberos от начала логирования

Давайте еще в картинках я расскажу более детально как происходит проверка подлинности kerberos, от момента ввода пароля пользователем. И так:

Читайте также: