Active Directory, настроенному с репликацией — нужен способ управлять хостом аутентификации входа в систему
Я имел подобный вопрос здесь на днях и решил его с помощью этого. Это выглядит простым, и это, и это работает, я могу послать электронное письмо от своего VPS только и получить почту в моем адресе приложений Google. просто заставьте Вас установить Вас записи MX (устанавливающий рекорд SPF, также хорошая идея помочь с анти-мерами по спаму), установите имя хоста в постфиксе (main.cf), делайте изменения предложенными в ссылке и Вашей пользе для движения. Вам не нужны никакие правила брандмауэра, потому что Вам не нужен открытый порт для отправки почты (по крайней мере, мне, кажется, не нужно так или иначе) (я думаю и ожидаю, чтобы быть исправленным кем-то более хорошо осведомленным если неправильно),
Я собираюсь предположить (возможно, ошибочно), что у вас есть AD клиентов на удаленном сайте, и поэтому у вас есть DC на этом сайте. Если это так, то, как заявил Эван, вы захотите настроить сайты и службы Active Directory для обоих сайтов / подсетей. Затем KCC построит топологию репликации между контроллерами домена на основе конфигурации ADS&S. В нынешнем виде у вас, вероятно, есть трафик репликации, проходящий через глобальную сеть, основанный на топологии внутрисайтовой репликации, а не на топологии межсайтовой репликации.
Затем локатор DC на каждом клиенте найдет в нем DC ' ближайший сайт для аутентификации. Обязательно настройте контроллер домена на удаленном сайте как GC (или включите кэширование универсального членства в группе в настройках сайта NTDS для удаленного сайта).
Если я ошибаюсь и у вас нет клиентов AD на удаленном сайте, почему у вас есть DC на удаленном сайте?
То, что вы описываете, скорее всего, совершенно нормально. Если локальный DC не отвечает в течение короткого периода времени, клиент свяжется с любым другим DC в домене, независимо от местоположения. (В Windows 2008 есть новый параметр, который делает следующее ближайшее местоположение более эффективным). На самом деле существует очень сложный алгоритм, которому следуют клиенты Windows, который называется DC Locator.
Можно сделать процесс более детерминированным, настроив стоимость сайтов и ссылок на сайты (если вы этого не сделали), а также используя приоритет и вес записей DNS SRV в поддомене _msdcs. Клиенты пытаются связаться с сервером с самым низким приоритетом. Вес - это механизм балансировки нагрузки, который используется при выборе целевого хоста из тех, которые имеют такой же приоритет. Клиенты случайным образом выбирают записи SRV, которые определяют целевые хосты, с которыми необходимо связаться, с вероятностью, пропорциональной весу.
DNS возвращает список IP-адресов, которые соответствуют целевому домену в записях SRV (то есть IP-адреса контроллеров домена в указанном домене), которые отсортированы по приоритету и весу. Клиент проверяет каждый IP-адрес в указанном порядке. Ping - это запрос UDP LDAP на порт 389. Клиент проверяет каждый контроллер домена из списка. После каждого эхо-запроса клиент ждет одну десятую секунды ответа на эхо-запрос (или любой предыдущий эхо-запрос), а затем пингует следующий контроллер домена. Случайный выбор контроллеров домена обеспечивает первый уровень балансировки нагрузки. Выполнение нескольких запросов ping в быстрой последовательности гарантирует, что алгоритм обнаружения завершится через конечный промежуток времени.
Обратите внимание, что, когда клиент устанавливает соединение с DC, он создает сродство (иногда называемое «липкостью») с этим DC. По умолчанию клиенты Windows Vista / 2008 и более поздних версий будут пытаться повторно обнаруживать контроллеры домена каждые 12 часов, и это можно настроить с помощью групповой политики. Существует также исправление, позволяющее включить такое поведение в Windows XP / 2003.
Дополнительная информация:
Как оптимизировать расположение контроллера домена или глобального каталога, который находится за пределами сайта клиента. Существует также исправление, позволяющее включить такое поведение в Windows XP / 2003.
Дополнительная информация:
Как оптимизировать расположение контроллера домена или глобального каталога, который находится за пределами сайта клиента. Существует также исправление, позволяющее включить такое поведение в Windows XP / 2003.
Дополнительная информация:
Как оптимизировать расположение контроллера домена или глобального каталога, который находится за пределами сайта клиента. http://support.microsoft.com/kb/306602
Записи ресурсов SRV
http://technet.microsoft.com/en-us/library/cc961719.aspx
Местоположение контроллера домена Процесс
http://technet.microsoft.com/en-us/library/cc978011.aspx
Функция DsGetDcName
http://msdn.microsoft.com/en-us/library/windows/desktop /ms675983%28v=vs.85%29.aspx[12120 visibleВключение клиентов для поиска следующего ближайшего контроллера домена
http://technet.microsoft.com/en-us/library/cc733142%28WS.10%29 .aspx
Типы локаторов
http://technet.microsoft.com/en-us/library/cc978019.aspx
Похоже, вам нужно использовать «Сайты и службы Active Directory» оснастка определяет подсети, физические местоположения (известные как «Сайты») с хорошо связанными подсетями и соединения между сайтами (известные как «Ссылки сайтов») , которые составляют физическую сеть, лежащую в основе вашего Активного Каталог (AD), чтобы контроллеры домена могли принимать правильные решения о репликации, а клиенты могли принимать правильные решения о том, какие серверные компьютеры использовать для обслуживания входа в систему. Без описания физической топологии вашей сети все различные части серверных и клиентских операционных систем, которые полагаются на связь с компьютерами контроллеров домена (DC), в основном «летают вслепую» и не имеют возможности судить, какие DC находятся физически близко и , таким образом, более эффективно общаться.
Как только вы ' Если вы проинформировали AD о физической структуре сети, вы обнаружите, что все «просто работает» намного эффективнее. Не беспокойтесь слишком сильно о балансировке нагрузки для "количества пользователей" - это не будет иметь значения, если вы определите сайты и подсети (если только у вас нет действительно очень плохого соотношения количества пользователей и контроллеров домена. или очень высокая частота входов в систему). Я думаю, что большинство ваших проблем связано с тем, что вы ничего не сказали AD о физической топологии вашей сети. (Есть некоторые более глубокие «настройки», которые можно выполнить в DNS, чтобы повлиять на выбор контроллеров домена на данном сайте, но, в основном, клиенты «бросают кости» и общаются с любым контроллером домена на своем сайте. Для меня этого всегда было достаточно. производственные развертывания.)
Все эти настройки с сайтами, ссылки сайтов и подсети на самом деле просто меняют то, что хранится в DNS. Клиенты используют DNS, чтобы определить, на каком сайте они находятся (просматривая свою подсеть), и, как только они это узнают, они используют DNS для поиска контроллеров домена для связи. Фактические записи DNS, которые выполняют эту работу, - это записи ресурсов (RR) «SRV», хранящиеся в зоне DNS «_msdcs.domain.com». Очевидно, что для того, чтобы все это работало, клиенты должны иметь доступ к DNS-серверу, который может возвращать записи для DNS-зоны «_msdcs.domain.com». Обычно предпочтительно использовать DC в качестве DNS-сервера (поскольку Microsoft сделала эту конфигурацию «просто работающей» очень хорошо), чтобы не указывать какие-либо DNS-серверы, отличные от DC, в конфигурациях клиентской сети (т. Е. Не помещайте DNS-серверы ISP в качестве "вторичных" DNS-серверов в областях DHCP или " Процедура установки контроллера домена в качестве GC действительно проста, и вы должны иметь по одному на каждом сайте (даже если вы не обязательно понимаете, для чего они нужны). Пометить каждый DC как GC - не лучшая идея, хотя в такой маленькой среде, как ваша, это не сильно изменится. Однако в более крупных средах больше не обязательно лучше, когда речь идет о репликах GC.