При построении современной почтовой системы нужно учитывать множество факторов, чтобы защитить получателей/отправителей почтовой системы от спамовых и фишинговых почтовых сообщений. Все мы хорошо знаем о Sender Policy Framework (SPF), который позволяет проверить не подделан ли домен отправителя почтового сообщения, но изощренность злоумышленников ставит перед нами новые задачи которые можно, а главное нужно решать с помощью стандартов DomainKeys Identified Mail (DKIM) и Domain-based Message Authentication, Reporting and Conformance (DMARC).
-
Реализация DKIM для Exchange Server 2013
-
Повышаем доступность прокси-сервера Squid с помощью UCARP с балансировкой нагрузки между двумя виртуальными серверами на базе Ubuntu Server 14.04.2
Несмотря на довольно стабильную работу прокси-сервера Squid в средах с большим количеством пользователей, может возникнуть желание повышения уровня доступности такого важного на сегодняшний день информационного ресурса, как доступ в Интернет для конечных пользователей. В этой заметке будет рассмотрен пример настройки двух прокси-серверов Squid для повышения доступности с параллельным распределением нагрузки между этими серверами. -
Базовая настройка брандмауэра Ubuntu Server 14.04 LTS с помощью iptables
Как было справедливо замечено в комментариях к одной из прошлых заметок о конфигурации Ubuntu Server, говоря о вопросах безопасности, стоит обратить отдельное внимание на вопрос настройки брандмауэра на нашем Linux-сервере граничащем с сетью Интернет. В этой заметке мы кратко рассмотрим пример настройки встроенного в ядро Linux брандмауэра Netfilter с помощью интерфейса управления iptables на Ubuntu Server 14.04 LTS. Мы настроим ряд базовых правил брандмауэра, включим на нашем Linux-сервере функцию пересылки трафика (ip forwarding) превратив тем самым его в роутер, а также рассмотрим пару простых примеров настройки пересылки трафика. -
Настройка прокси сервера Squid 3.3 на Ubuntu Server 14.04 LTS. Часть 3. Конфигурация DNS , NTP и установка Squid
Для обеспечения корректной работы механизмов аутентификации прокси-сервера Squid нам потребуется выполнить настройку механизма разрешения имён DNS и службу синхронизации времени по протоколу NTP. В первой заметке мы определились с тем, что наш Ubuntu Server будет включён в существующую инфраструктуру Active Directory (AD), где в качестве серверов DNS выполняющих разрешение имён как внутренних зон DNS так и любых внешних, выступают контроллеры домена. Поэтому Ubuntu Server будет настроен нами как DNS-клиент отправляющий DNS-запросы к контроллерам домена. Помимо этого, для успешной работы Kerberos нам потребуется, чтобы текущее время на Ubuntu Server было сопоставимо с временем на клиентских компьютерах и контроллерах домена. Как правило, в инфраструктуре AD клиентские компьютеры синхронизируют время с контроллерами домена, где работает службы NTP, поэтому по аналогии настроим Ubuntu Server на получение точного времени с контроллеров домена. В конце этой заметки, после настройки DNS и NTP, выполним установку Squid. -
Установка и базовая настройка SharePoint Server 2013 SP1 на Windows Server 2012 R2 (в топологии Two-tier farm). Часть 8 – Настройка Службы поиска и создание сайта центра поиска
Данная заметка цикла об установке и базовой настройке SharePoint Server 2013 SP1 будет посвящена настройке общей службы SharePoint – Службе поиска (Search Service). Онлайн документацию на русском языке о развертывании и настройке Службы поиска можно найти в документе Создание и настройка приложения-службы поиска в SharePoint Server 2013. Все проводимые нами действия будут разделены на два основных этапа, каждый из которых имеет свои подзадачи:1. Настройка Службы поиска (Search Service Application)
1.1. Создаём управляемую учетную запись SharePoint Managed Account для Службы поиска
1.2. Создаём служебное веб-приложение Службы поиска (Service Application)
1.3. Настраиваем источники контента (Content Sources)
1.4. Запускаем первый обхода источника контента (Full Crawl) и проверяем результат.2. Настройка сайта Центра поиска (Global Search Center Site)
2.1. Создаем управляемую учетную запись (Managed Account)
2.2. Создаем веб-приложение (Web Application)
2.3. Создаем семейство сайтов (Site collection)
2.4. Регистрируем запись в DNS для Host Header
2.5. Регистрируем SPN для Host Header
2.6. Настраиваем доступ пользователей к корневому сайту
2.7. Задаем Центр поиска в настройках Службы поиска и проверяем результат. -
Установка и базовая настройка SharePoint Server 2013 SP1 на Windows Server 2012 R2 (в топологии Two-tier farm). Часть 6 – Создание семейства сайтов для Личных сайтов (My Sites)
Ёмкое определение ещё одной сущности SharePoint носящей название Личные сайты (My Sites) можно найти в документе Компоненты логической архитектуры (SharePoint Server 2010)Личные сайты — это особые сайты SharePoint, персонализированные для каждого пользователя. Создание личных сайтов включено по умолчанию как часть службы профилей пользователей, и каждый пользователь организации может создать свой уникальный личный сайт.
Как понятно из этого определения, перед развертыванием ещё одной общей службы, расширяющей функциональность фермы SharePoint – Службы профилей (User Profile Service) нам желательно уже иметь развернутое семейство сайтов для узлов Личных сайтов, чем мы и займёмся в данной части нашего цикла заметок об установке и базовой настройке SharePoint Server 2013 SP1
Описание архитектурных особенностей и полного порядка настройки выделенного Семейства сайтов для узлов Личных сайтов изложено на русском языке в документах:
- Обзор личных сайтов в SharePoint Server 2013
- Планирование личных сайтов в SharePoint Server 2013
- Настройка личных сайтов в SharePoint Server 2013Для развертывания нового семейства сайтов для узлов Личных сайтов нам нужно выполнить цепочку действий аналогичную той, что уже была ранее описана в заметке Часть 3 – Создание семейства сайтов, а именно:
1. Создание управляемой учетной записи SharePoint (Managed Account)
2. Создание веб-приложения SharePoint (Web Application)
3. Выполнение базовых настроек веб-приложения
4. Создание семейства сайтов (Site collection)
5. Регистрация записи в DNS для Host Header корневого сайта семейства сайтов
6. Регистрация Service Principal Name (SPN) для Host Header корневого сайта семейства сайтов для обеспечения аутентификации Kerberos
7. Проверка доступности корневого сайта семейства сайтовПоэтому, чтобы не повторяться с точки зрения демонстрации этих действий с использованием графического интерфейса SharePoint (через веб-узел Центра администрирования (ЦА)), в этот раз мы рассмотрим пример, того как все эти действия можно выполнить с помощью SharePoint 2013 Management Shell.
-
Remote Desktop Services – Строим отказоустойчивую ферму RD Connection Broker на базе Windows Server 2012
Ранее мы рассматривали пример построения фермы Remote Desktop Connection Broker (RDCB) на базе Windows Server 2008 R2. С выходом Windows Server 2012 технологии повышения доступности для служб RDS претерпели определённые изменения, в частности теперь для построения отказоустойчивой фермы RDCB не используются механизмы Windows Failover Cluster. В этой заметке мы попробуем рассмотреть процедуру создания новой фермы RDCB на базе Windows Server 2012 с применением Windows NLB, как средства повышения доступности и балансировки сетевой нагрузки для ролей RD Connection Broker и RD Web Access. После создания фермы RDCB выполним ряд настроек, которые позволят нам считать инфраструктуру RDS минимально подготовленной к использованию в соответствии со следующим планом:
- Среда исполнения
- Подготавливаем виртуальные сервера
- Создаём кластер NLB
- Подготавливаем SQL Server
- Устанавливаем роли Remote Desktop Services
- Создаём высоко-доступный RD Connection Broker
- Добавляем сервера в высоко-доступный RD Connection Broker
- Добавляем на сервера роль RD Web Access
- Создаём коллекцию сеансов – Session Collection
- Настраиваем цифровые сертификаты
- Настраиваем веб-узлы RD Web Access
- Настраиваем Roaming User Profiles и Folder Redirection
- Публикуем приложения RemoteApp
- Устанавливаем языковой пакет
- Настраиваем перенаправление печати -
Отделяем трафик Hyper-V Shared Nothing Live Migration
После перевода серверов виртуализации на Windows Server 2012 возникло желание использовать новый функционал Hyper-V - Shared Nothing Live Migration для хостов, не являющихся членами кластеров. Здесь я опишу практический пример действий, которые были выполнены для того, чтобы отделить трафик миграции от основного трафика управления хостом виртуализации. В рассматриваемом примере имеется два сервера виртуализации HP ProLiant DL380 G5 с дополнительно установленным двух-портовым гигабитным сетевым адаптером HP NC360T. Таким образом каждый сервер имеет по четыре гигабитных сетевых интерфейса, которые мы будем использовать в следующем порядке:- Port 1 NC373I (On-Board NIC1) – Под трафик резервного копирования DPM
- Port 2 NC373I (On-Board NIC2) – Под трафик Live Migration (LM)
- Port 3 NC360T (PCI-E NIC Port1) – Под трафик управления хостом
- Port 4 NC360T (PCI-E NIC Port2) – Под трафик виртуальных машин
-
Windows Server 2012 - The DNS service on server has stopped running
Заметил на паре серверов с Windows Server 2012 одну особенность – периодически останавливающуюся службу DNS Client, о чем назойливо сообщал SCOM:
Alert: DNS Service Stopped Source: Microsoft Windows Server 2012 Standard Path: KOM-AD01-NPS01.holding.com Description: The DNS service on server KOM-AD01-NPS01.holding.com has stopped running
В эвент-логе на этих серверах можно было видеть события - сначала об остановке службы…
EventID 7036 The DNS Client service entered the stopped state.
и через некоторое время – о её повторном запуске..
EventID 7036 The DNS Client service entered the running state.
Судя по соседним событиям лога, никакого криминала в это время в системе не происходило и поэтому понять природу такого поведения клиента с наскоку не удалось. Интересно то, что на других серверах с Windows Server 2012 такого поведения службы DNS не наблюдалось и по сути эти два сервера отличались от других разве что только пониженной сетевой активностью. В ходе экспериментов удалось заметить то, что отключение Windows Firewall приводило к тому, что служба работала постоянно без остановок. Где-то на форумах в интернете (ссылку к сожалению не сохранил) наткнулся на информацию про то, что на новых системах DNS клиент может останавливаться в случае отсутствия активности. Как я понял, в Windows Server 2012 тип запуска службы DNS Client отображается как Automatic (Trigger Start), в отличие, например, от Windows Server 2008 R2, где он был Automatic, а служба при этом работала постоянно. Там же дали совет о том, что дабы заставить службу DNS Client работать без остановок, надо включить в правилах Windows Firewall разрешающее правило сетевого обнаружения - Network Discovery (LLMNR-UDP-In)
Так как в нашей сети работает DNS сервер, LLMNR нам на самом деле не нужен, но для "успокоения" SCOM этот метод оказался вполне работоспособным и вот уже более двух недель наблюдения на двух исходных серверах служба DNS Client работает без остановок.
-
Антивирус для Windows Server - настраиваем список исключений. Обновлено 11.08.2016
В ходе настройки политик управления клиентами любого антивирусного ПО необходимо определять список каталогов, имён процессов или даже расширений фалов, которые должны исключаться из Real-Time сканирования. Постараюсь собрать в одном месте информацию о рекомендуемых параметрах исключений и по мере необходимости буду его корректировать. Стоит отметить, что список составлен исходя из приложений, которые эксплуатируются в моём рабочем окружении. Список разделен по основным категориям сервисов и там где возможно есть ссылки на официальные рекомендации производителей ПО. Во всех случаях подразумевается что программное обеспечение установлено в каталоги «по умолчанию».
Онлайн-курсы Евгения Лейтана
Внедрение Microsoft System Center Operations (SCOM) 2016/201913 уроков (6 часов видео), лабораторные работы и вручение именного сертификата.
Промокод "IT-KB_60" со скидкой 60%!
RSS - Записи