среда, 22 октября 2014 г.

Подпись к сообщениям электронной почты (колонтитул) в Exchange 2013

В ECP:
  1. Перейдите в раздел Поток обработки почты > Правила.
  2. Нажмите кнопку Добавить Значок "Добавить",, а затем — Применить заявления об отказе.
  3. В поле Новое правило введите имя правила.

вторник, 21 октября 2014 г.

Сохранение отправленных писем в SharedMailbox при отправке со своего ящика

Пример:
Создал Shared Mailbox support@domain.ru. Подключил его 3-им пользователям со своими персональными ящиками (делегировал FullAccess на SharedMailbox) и у каждого в реестре добавил запись(для Outlook 2010):

пятница, 17 октября 2014 г.

Миграция Exchange 2010 на Exchange 2013

How to use Kerberos Constrained Delegation with Forefront TMG

Using TMG, one-time passwords and Kerberos Constrained Delegation

How to configure TMG for SSL Client Certificate Authentication

Right click on the listener that you created before and select the “Authentication” tab.
SSL Client Certificate Authentication
Select “SSL Client Certificate Authentication” from the dropdown menu. You can only choose “Windows Active Directory” to validate the credentials.

Claws Mail быстрый и легкий клиент электронной почты

четверг, 16 октября 2014 г.

Fortigate — достойная замена уходящему Microsoft Forefront TMG

Как выписать мультидоменный сертификат в Windows CA

Через certreq создать запрос на создание SAN-сертификата, ибо через GUI винда такого не делает:


Certreq.exe -new RequestPolicy.inf SAN_cert.req


Kerberos Constrained Delegation in ISA Server 2006

Публикация web-сайтов через ISA с использованием KDC

Configuring Exchange Server for Kerberos constrained delegation

In this scenario, to use Kerberos constrained delegation, the virtual directory used for Outlook Web Access on all the Exchange servers in your deployment (the /Exchange virtual directory in this solution) must be configured to accept Kerberos authentication, and Kerberos constrained delegation must be enabled on your Exchange servers. If your deployment includes both Exchange front-end and back-end servers, your Exchange front-end servers must be configured as front-end servers that support Kerberos constrained delegation.

среда, 8 октября 2014 г.

Как найти админа домена в Windows-сети

 Задача

Найти админа домена в Windows-сети

 Решение

Типичной целью пентеста внутри корпоративной сети (чаще всего построенной на ActiveDirectory) бывает компрометация контроллеров домена, то есть получение учетки с правами группы Domain Admins.

Обычно как получается с такими сетями: находим дырявые сервисы, получаем контроль над хостом, из памяти добываем учетки (креды либо хешики) и с ними идем уже на другие хосты, пока не найдем где-нибудь процессы юзера из группы Domain Admins. Если честно, то, сколько помню пентестов, проблемы найти админов не было — они обнаруживались сами собой и достаточно быстро. И как-то даже мысль не приходила в голову, что есть такая задачка — находить их.

Но вот наткнулся на интересный топик блога компании NetSPI и осознал, что «точечный удар» будет более профессиональным подходом. Самое интересное, что можно с правами обычного доменного юзера оперативно найти администраторов.

Итак, начнем. Первая подзадача — определить всех админов домена. То бишь наших жертв. Фактически не считается, что эта информация приватная, а потому доступна она всем юзерам домена по умолчанию. Узнать их можно, например, стандартной командой

Net group "Domain Admins" /domain

Но если помнишь, с ActiveDirectory можно работать через LDAP, причем опять-таки по умолчанию для доступа к нему требуется любая доменная учетка. Как следствие, мы можем получить не только перечень админов, но и, по сути, структуру юзеров и групп, а также много другой интересной информации.

Вторая подзадачка — найти процессы, запущенные от админов домена. Это уже более специфическая тема. Методов несколько.

Есть такая штука, как Service Principle Name (SPN). Если очень примерно, то это имя сервиса, под которым он регистрируется в AD для работы Kerberos-аутентификацией. Но нас интересует здесь несколько другое. А именно то, что в LDAP’е мы можем просмотреть SPN с привязкой к аккаунту AD, под которой он запущен. То есть если какой-то сервис был запущен изначально под учетной записью администратора домена, то в LDAP’е для этой учетки будет SPN-запись с названием сервиса, а главное с именем хоста, где этот сервис запущен. Чтобы не ползать вручную по LDAP’у, NetSPI написали скрипт на PowerShell для удобного и быстрого поиска по группам.

Но у этого способа есть один минус. На практике только Microsoft’овские сервисы регистрируют себя в домене, а если учесть, что их нечасто запускают из-под доменных учеток, то шансы не очень велики. С другой стороны, если вспомнить, что каждый хост имеет учетную запись в AD, то мы можем легко найти все сервисы какого-то типа. Самый практичный пример — найти все MS SQL сервисы, которые есть в домене! И без какого-либо сканирования.

Иную возможность предоставляет нам NetBIOS. Мы с правами обычного юзера можем запросить у контроллеров домена информацию по активным сессиям. В итоге мы можем получить имя хоста с админскими процессами. Минус заключается в том, кто информация о сессиях будет за короткий промежуток времени, то есть если не было взаимодействия с контроллером, то мы не увидим админа в списке. А потому надо систематически запрашивать контроллеры — админчик когда-нибудь точно появится.

С помощью тулзы NetSess можно сделать запрос инфы, а с помощью скриптика автоматизировать поиск по выводу.


Получаем перечень сессий, используя NetSess

NetSPI в блоге предложил еще два метода: запрашивать отдельные хосты на сессии юзеров через NetBIOS или, если есть учетка локального админа (одна на многих хостах), удаленно запрашивать список запущенных процессов. Но, имхо, оба они работают в редких случаях, да и шумноваты.

Источник: https://xakep.ru/2014/12/24/easy-hack-191/