Archive for the ‘ Маленькие хитрости ’ Category

Web Application Proxy — товар скоропортящийся

У Web Application Proxy(WAP) в Widnows Server 2012 R2 есть нехорошая особенность: стоит серверу WAP постоять без дела (в выключенном состоянии или без связи с сервером AD Federation Services) пару недель — и он уже сам по себе не заработает. Симпотматика при этом наблюдается следующая: служба WAP не запускается, фиксируя в журнале событий System событие Event ID 7023 от источника Service Control Manager с ошибкой 401 (Unauthorized):
Читать далее

Реклама

Публикация Sharepoint на нестандартном порту.

Сегодня встретил на форуме Techent cообщение с такой вот проблемой, касающейся публикации Sharepoint (для справки: автор заменил в URL реальное имя своего домена на слово domen):

Добрый день. Проблема с публикацией SP в интернет.
Задал адрес в альтернативном доступе для Интернет указал как http://sp.domen.ru
На шлюзе (Kerio Control) опубликовал по порту 8855 натом на внутренний адрес и порт 80.
При заходе спрашивает логин-пароль, а далее дико дико тупит. Через раз вываливается в 504 тайм аут. Это если заходить на адрес http://sp.domen.ru:8855/sites/sitename
через раз показывает в итоге сам сайт кое как подгружая страницу, но работать на сайте не получается, ибо как сказал выше постоянно 504 gateway time out.
Что ему нужно? )

Естественно, Sharepoint нужно, прежде всего, чтобы в сопоставлениях альтернативного доступа был указан внешний URL для выделенной под внешней доступ зоны (у автора вопроса это, как выяснилось позже — зона Интернет), содержащий этот самый нестандартный порт 8855. Но и это не всё. Когда я посоветовал автору вопроса добавить во внешний URL зоны Интернет номер порта, он ответил, что он это пробовал, но эффекта это не дало.
После моей просьбы показать настройку сопоставлений альтернативного доступа была получена следующая картинка (с замазанным именем реального домена)

sharepoint-publication

Конечно, предпочтительным вариантом показать сопоставления было получить выдачу команды Get-SPAlternateURL в Powershell (с текстом работать удобнее), но для понимания, кто виноват и что делать, этой картинки достаточно.
На картинке мы видим, что для зоны Интернет назначено единственное (создаваемое по умолчанию) сопоставление внешнего имени (http://sp.domen.ru:8855) самого на себя. Но так как у автора вопроса в реальности подключение на порт 8855 на шлюзе перенаправляется на порт 80 сервера Sharepoint, а не 8855, то это сопоставление не работает. Поэтому подключение извне воспринимается как относящееся к зоне По умолчанию, и в страницах ответа возвращаются URL, соответствующие зоне По умолчанию, но не зоне Интернет.
Чтобы сопоставление заработало, нужно добавить правильный внутренний URL (по которому перенаправляется запрос на шлюзе) в список внутренних URL для зоны Интернет.

Для этого на странице, скриншот который приведен выше, надо перейти по ссылке «Добавить внутренние URL-адреса».  На открывшейся странице в строке ввода «Добавить внутренний URL» следует написать для нашего случая http://sp.domen.ru. А в общем случае там нужно указать URL с именем хоста из внешнего имени (в нашем случае это sp.domen.ru), но с портом внутреннего сервера, на который реально перенаправляются внешние запросы (в нашем случае это — порт HTTP по умолчанию). А в  списке зон  ниже на этой странице нужно выбрать зону Интернет.
При такой настройке Sharepoint будет (в нашем случае) понимать, что если он получил запрос на 80-й порт с именем хоста sp.domen.ru (это имя передаётся в заголовке запроса HTTP), то все URL ссылок в ответе (на картинки, на ссылки для перехода и пр.) должны начинаться с внешнего URL зоны для внешнего доступа — http://sp.domen.ru:8855

После такой настройки публикация Sharepoint ожидаемо заработала.

PS Как сообщил автор, в данном случае публикация была чисто с целью протестировать саму возможность публикации. Ну, а для работы, конечно, в целях безопасности публиковать Sharepoint нужно исключительно по протоколу HTTPS. Но это уже другая история.

 

На изолированной от Интернет машине обновления лучше отключать явно.

Ставил сегодня по некоторой, совершенно не важной для дальнейшего рассказа, надобности  .NET 4.0 из полного пакета установки на изолированную от всяческих сетей свежую виртуальную машину (Win2K8 x86 SP2 ) на стенде. Хотя пакет и полный, и формально из интернета ему выкачивать ничего не надо — установить не получилось: установщик вернул код ошибки 0x8024402c. Этот код ошибки, как известно,  относится к службе автоматического обновления (Windows Update) и означает, что эта служба не смогла установить связь с сервером обновлений (центральным в Microsoft или местным WSUS). Это хорошо было видно и по журналу этой службы (%WinDir%\WindowsUpdate.log): да, пыталась, да получила ошибку таймаута.

Ну, почему получила ошибку — это очевидно: машина-то к интернету не подключена, совсем. Интереснее другое: зачем она вообще туда полезла и, главное, — как сделать, чтобы не лазила, причём второе важнее. Поэтому у меня возникла идея всё-таки слазить в настройки Windows Update и явным образом указать не проверять обновления.

Идея сработала — после отключения обновлений пакет .NET 4.0 установился без проблем.

Dynamic Access Control для Windows 7

В своих новых (некогда) ОС Windows 8 и Windows Server 2012 Microsoft реализовала ряд технологий, получивших общее маркетинговое название «динамическое управление доступом» (Dynamic Access Control, DAC). В частности, динамическое управление доступом включает в себя использование для авторизации доступа к файл-серверу не только SID учётных записей пользователей и групп безопасности, в которые эти записи входят, но и других атрибутов учётных  записей в каталоге Active Directory (таких, как принадлежность к определённому подразделению) через посредство утверждений (claims) о пользователе. Технологии эти, похоже, оказались интересными пользователям, но, к сожалению, Microsoft плохо озаботилась тем, чтобы подробно их документировать в Technet Library — ограничившись, по существу, лишь описанием типовых сценариев развёртывания. И теперь время от времени на различных форумах я натыкаюсь на вопрос, вынесенный в заголовок — можно ли использовать динамическое управление доступом для клиентов файл-сервера, работающих под управленем более ранних версий ОС Windows — такими, как Windows 7. Читать далее

О перерывах в репликации Active Directory

Как и многих специалистов IT, у меня есть своя домашняя лаборатория. Устроена она на обычном компьютере (правда, с 32 ГБ памяти), под VMWare Workstation.  На виртуальных машинах в наше время можно попробовать очень многое. Но после того, как попробовал, я очень редко ликвидирую старые, некогда настроенные стенды — наборы виртуальных машин. Большинство из них спокойно лежат на диске и ждут своего часа (мало ли что понадобится посмотреть для ответа на вопрос на форуме Technet), но это возможно не всегда. Например, если в состав набора входит несколько контроллеров домена в одном лесу, то оставлять их лежать просто так нельзя  — пролежат они больше времени жизни захороненных объектов и откажутся после этого реплицироваться. Поэтому такие виртуалки, на которых находятся контроллеры доменов, я время от времени (раз в один-два месяца) запускаю, чтобы они не забыли друг про друга.

Один из таких наборов содержит у меня три контроллера домена (КД) под управлением Windows 2012 R2 в двух подсетях, соединённых маршрутизатором: два — в одной подсети (и сайте), один — в другой (и тоже в отдельном сайте) . На днях я в очередной раз запустил всё это хозяйство, и решил вдруг проверить — а действительно ли они реплицируются, и тут выяснилось — что нет: по некоторым (неважным для последующего рассказа) причинам один из интерфейсов маршрутизатора отключился от виртуального сегмента LAN, в результате чего связь между подсетями оказалась потеряна. Причём потеряна она была не далеко в этот раз, но (к счастью) до того, как истекло время жизни захороненных объектов — всё это неплохо было видно в выдаче команды repadmin /showrepl.

После восстановления работоспособности маршрутизатора я решил провести реплликацию вручную, через консоль AD Sites & Services. Репликация от одиночного КД прошла нормально, но вот обратная репликация — на одиночный КД с группы из двух КД идти отказалась. Ошибка при этом вылезла странная: «The naming context is in the process of being removed or is not replicated from the specified server». Странная — потому что все контексты (т.е. разделы каталога) давным-давно были реплицированы куда надо и ниоткуда не удалялись.

Читать далее

Доступ пользователей к терминальному серверу только с отведенных для каждого из них компьютеров.

Введение.

Недавно на форуме русского Microsoft Technet мне попался такой вопрос одного из участников: «возможно ли задавать условия по двум критериям для доступа к терминальному серверу («узел сессий удаленного рабочего стола») под управлением Windows Server 2008 — диапазон ip (или список имен компьютеров) и логин (или группа)» Т.е., спрашивающий хотел разрешить вход с каждого из компьютеров (или их групп) только определённым пользователям (или группам пользователей).

В принципе, ответ на этот вопрос несложный. Сам по себе терминальный сервер («служба удаленных рабочих столов») такой возможности контролировать доступ к нему не даёт. Однако эта задача легко и просто решается в современных версиях Windows с помощью брандмауэра Windows в случае, если терминальный сервер и компьютеры, с которых выполняется вход, являются членами домена.

Задача мне показалась интересной, и я решил промоделировать её решение в лабораторной среде.

Основой решения является использование защиты подключений с помощью IPSec с расширением от Microsoft (протокол AuthIP).Это расширение позволяет производить при подключении аутентификацию и пользователя, и компьютера, с которого было выполнено подключение. Интеграция же IPSec с брандмауэром Windows позволяет в правилах брандмауэра использовать эту информцию — то есть, указать, к каким пользователям и компьютерам это правило применяется.

Пример настройки, приведенный ниже, годится для терминального сервера, работающего под управлением Windows Server 2008 R2 и выше, и компьютеров, с которых произодится подключение, под управлением ОС Windows 7 и выше. Однако, с некоторыми модификациями — а именно, отказом от неподдерживаемой в Windows Vista и Windows Server 2008 возможности указания портов протокола TCP в правилах безопасности подключения — такая настройка возможна и для терминального сервера под управлением Windows Server 2008, и для клиентов под управлением Windows Vista.

Читать далее

Добавление сетевого интерфейса в RRAS в Windows 2008

Сегодня возникла нужда добавить дополнительную сетевую карту на шлюзовой (NAT в Интернет и VPN в центральный офис) сервер на одной из площадок — у начальства возникла идея сделать гостевой WiFi с доступом в интернет. Дело нехитрое, сетевую карту наш техник вставил, сервер включил. Но интерфейс в оснастке управления службы маршрутизации и удаленного доступа (RRAS не появился). Что было совершенно ожидаемо — сервер работает под Windows 2008, а в ней Microsoft почему-то выпилила автоматическое добавление в RRAS интерфейсов для новых сетевых адаптеров.
Проблема эта известная, но штатный способ борьбы с ней не отличается изяществом: надо деактивировать, а затем — заново активировать и настроить службу маршрутизации и удаленного доступа. Это означает и существенный перерыв в обслуживании, и риск внесения ошибок при конфингурировании (впрочем, последнего можно избежать, если перед деактивацией сохранить конфигурацию RRAS командой netsh, а после активации — применить сохраненную конфигурацию).
К счастью, народ нашел более простой способ добавления новых интерфейсов в RRAS — только он не документирован, а описание его погребено в толще форумов Technet, в последнем сообщении вот этой темы.
В связи с этим, я вижу смысл опубликовать его здесь.

Читать далее