Close Topic Options

На ровном месте возникла проблема.

Коротко: Когда Outlook (разные версии) через LDAP запрашивает у Windows 2003 сервера (AD) список почтовых адресов, выводится только список пользователей, групповые адреса (Distribution Groups, Security Groups, имеющие почтовый адрес) не видны. В тоже время при том же запросе с Windows 2000 сервера (DC в том же домейне) видно все - и пользователи и группы. Как вытащить список групповых адресов из Windows 2003 сервера?

Развернуто: Жил-был домен Windows 2000. Почта на Linux (Exim), клиенты пользуются Outlook c IMAP. Почтовые адреса вытаскивались с AD через LDAP, видны были и пользватели и группы, имеющие почтовый адрес.
Теперь пришел приказ переходить на Exchange (естественно, 2007). Тут требуется, чтобы все DC были 2003 серверы (домен и лес на уровне 2000 Native или 2003 Native). Пришлось по очереди апгрейдить сервера с 2000 на 2003. И тут вылезла бяка. В смешанном домене (где есть и 2000 и 2003 сервера), если Outlook запрашивает лист адресов с 2000 сервера, все ОК, видны и пользователи и группы. Но если запрос делать с 2003 сервера, то видны только пользватели, групп не видно. То есть, проблема тут явно не в AD (ведь сервер 2000 показывет все нормально) а в том, как 2003 сервер обрабатывает LDAP запрос. Явно как то иначе - запрос ведь тот же (дефолт у Outlook). После апгрейда последнего 2000 DC в домене, у людей пропадут в Outlooke адреса групп. Стало быть, нужно как то вытащить их из 2003 сервера.

Гуглил немало, но нашел весма мало толковой информации. Все либо связано с Exchange, либо общие разговоры, либо безответные запросы в такой же ситуации (например тут). Причем эта проблема втречалась как без Exchange так и с ним. Что меня и тревожит, так как теперь нет никакой уверенности, что при наличии Exchange эти группы появятся. То есть, мне кажется, что эту проблему (отсутствие групп в ответах на LDAP запросы) нужн решать до запуска Exchange.

если есть возможность поиграться, то я-бы посоветовал следующее - взять один DC, выдернуть из сети, поставить на него exchange и посмотреть что получится. Появятся группы - хорошо. Нет - вернуть всё как было и думать дальше.

Не пройдет. У меня в домене все серверы 32бит, а Exchange 2007 инсталлируется только на 64бит Windows 2003 Server. Так что так и так мне новый сервер инсталлировать придется. Причем железо прибывает уже (надеюсь) завтра. На него пойдет свежий 64bit 2003 Server (как domain member) и сверху Exchange. Для запуска Exchange нужен домейн "Native 2000" или "Native 2003" (а в части книжек написано, что вообще только "Native 2003" и тогда я должен буду убить последний 2000 DC, лишившись групп). К тому же мне его быстро в эксплуатацию запускать надо, так что долго не поиграешься

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

бррр... получаешь новый сервер, ставишь его мембером, на него сливается вся AD. Отключаешь от сети и сокойно ставишь на него exchange. Он честно должен встать, ибо у тебя сервер будет одиноким контроллером домена и ничего ему не указ. Проверяешь работу групп. Если все ОК, то спокойно форматируешь новый сервак и ставишь 2003 мембером в сеть снова. А если всё плохо, то продолжаешь играть.
Какие проблемы?

P.S. Зачем убивать 2000-е для Native 2000 я тоже не понимаю. Другое дело, что 2000-е винды уже отжили свою и их таки по-любому пора апгрейдить. Вот только у меня у самого до сих пор домен на 2000-х.

Собственно, примерно так и придется делать.

Скорее всего придется переходить на "2003 native". В кнжках (даже на разных страницах одной книги) противоречивые данные - в одних местах домен должен быть не ниже "2000 native" в других только "2003 native" (хотя, скорее всего, первое). Но, "2003 native" дает кучу дополнительных возможностей, так что имеет мысл не мучаться больше с 2000. Тем более, что на 2003 сервере "2000 native" группы не видны. И есть призрачный шанс, что с переходом на "2003 native" все заработает.

Очередная коза, еще более суровая. Exchange 2007 (да и вся 2003 AD) жизненно зависят от DNS. Прчем это активный DNS - контроллеры (да и мемберы) домейна активно на лету пишут туда свои записи. Оказывется, беда возникла уже начиная с Windows 2000 Server SP4 - в DNS домейне из одного слова (например mydomain, а у меня как раз такой случай) проблемы с активной записью в DNS (отсюда и кучи ошибок в EventLog - правда, микрософт пишет, что в таком случае их можно игнорировать, DNS ведь работает). Тут нужно учесть, что по умолчанию имя DNS домейна совпадает с NETBIOS именем с домейна (тот же mydomain). Есть метода разрешить DNS записи и в такие домены, НО, Exchange 2007 в принципе не будет работать в случае "single label" DNS домейна. Таким образом, чтобы посадить в наш домейн Exchange 2007, у меня два пути:

1. Изменить имя DNS домейна (добавив туда суффикс), например, на mydomain.myorg, НЕ меняя NETBIOS имени (остается mydomain) - так называемый "disjoint namespace". И, Exchange 2007 такое (по бумагам для трех разных сценариев) поддерживает, главное, чтобы DNS домейн не был "single label". Процедура с виду несложная, только неясно, как поведут себя DNS серверы на контроллерах и мембер компутеры. Тут можно попутно домейн наглухо повесить (например, если новый DNS сразу не заработает).

2. Изменить NETBIOS имя домейна на mydomain.myorg (2003 домейн это позволяет). Тут уже автоматом DNS и NETBIOS имена будут совпадать, никакого "disjoint namespace". Но уже беглое знакомство с описанием сей процедуры (например, там нужен дополнительный 2003 сервер, НЕ контроллер, который следит за процедурой), и подготовки к оной (к тому же включающей большую часть пункта 1. выше), привело к грустным выводам. Тут уже точно придется домейн на какое то время повесить, да и не все еще ясно с мембер компутерами.

Вот и выбираю между двумя процедурами. Нет полной уверенности, что более простая процедура "disjoint namespace" спасет отца руссой демократии. К тому же ради благополучия будущего Exchange 2007 можно пойти и на переименование домейна (оставив оба namespace одинаковыми, для Exchange это явно лучше).

Никто не имеет опыта с подобными процедурами? Беда у меня еще и в том, что процедуры придется длать сразу "вживую", на работающем домейне. Строить "тренировочные" домейны нет ни сил ни времени.

А теперь отведу душу. Чем этим казалам из M$ помешали "single label" домейны? Это же внутренний домейн, не видный снаружи! Я понимаю, что во внешнем домейне это не пойдет, никто мне такого домейна и не зарегистрирует, но чем мешают внутренние домейны??? Или этот новый DNS сервер не различет внутренние и внешние домейны? Или эти казлы хотят, чтобы я свой Windows домейн строил на открытой сети и регистрировал свой DNS домейн у них?

RFC по email почитай. Там явно и недвусмысленно написано - после собаки - нормальный домен. С точкой. То есть НЕ single label. Именно поэтому Exchange и не работает с single label. Ибо это нарушение RFC. A сама винда работает. Ей таки действительно пофик.

Кстати, если уж говорить о казлах, то хочется спросить зачем надо было изначально делать single label? Ну ведь понятьно-же, что это не стандарт. Что мешало изначально сделать нормальный внутренний домен, удовлетворяющий всем требованиям нормального интернет-домена? Ну, кроме желания поиметь массу гемороая в будущем...

Проблема тут в том, что M$ молча, без лишнего шума, приравняли NETBIOS и DNS имена, перебросив при этом на DNS кучу функций, нужных лишь самому Windows домейну. Причем долгое время разные DNS и NETBIOS имена прекрасно мирно сосуществовали. Еще старый Exchange 5.5 прекрасно работал в таких условиях - там "E-mail domain name" выходящей почты указывался в установках, и ему было плевать на NETBIOS имя домейна. И для самого DNS сервера "single label name" тоже не проблема (если это внутренний домейн).

Так изначально домейн давным-давно делался, NETBIOS был сам по себе, DNS (вместе с почтой) сам по себе. То есть, структура NETBIOS имен не должна была соответствовать RFC по E-mail. Естественно, проще делать короткие NETBIOS имена без лишних суффиксов - в этом на было никакой необходимости. И проблемы с короткими (в одно слово) внутренними DNS домейнами тоже не было. Почта между разными пользователями одного мейл-сервера доставляется прямо в ящик. А для выходящей почты использовался адрес внешнего DNS домейна. Любой мейлер (да и тот же Exchange 5.5) прекрасно умел переписывать не только суффикс, но и весь адрес выходящей (и входящей) почты (из user@mydomain в firstname.surname@organisation.domain.com). Вначале даже с Windows2000 проблемы не было - ну, тикали собственные DNS серверы на DC для собственных нужд, и ладно, а вся остальная жизнь (включая почту) опиралась на другие DNS серверы.

Проблема возникла тогда, когда M$ перевел значительную часть внутренней жизни AD на "active DNS", молча приравняв DNS имена к NETBIOS именам. И, поскольку Exchange 2007 полностью живет на DNS сервере AD, то и возник конфликт с "single label DNS names".

Это что же, создавая 6 лет назад простенький W2000 домейн, мне нужно было предвидеть, что через N лет M$ переведт всю жизнь домейна на DNS, приравняв DNS имя к NETBIOS имени и это NETBIOS имя должно будет соответствовать RFC по email??? В те времена NETBIOS и DNS имена были совершенно разные и мало связанные вещи.

Не то, чтобы молча. Сразу с введением AD и приравняли. Просто поддерживали старые имена для совместимости с NT4 пока была поддержка NT4 как таковая. Сейчас NT4 уже давно не поддерживается и поддержка старый НТ-шных доменов не нужна.

И сейчас могут сосуществовать в домене. И DNS поддерживает single label. С этим проблем нет. Домен вполне себе существует. Проблема не с доменом, а с почтой (с Exchange). Ведь так?

И сейчас не должна. Если очень хочется, то можно делать домен какой хочешь. Ведь у тебя он и есть. И работает.

А вот тут-то и проблема. Внутрянняя почта у тебя НЕ СООТВЕТСТВОВАЛА RFC. И то, что раньше MS поддерживала такую конфигурацию никак не оправдывает тебя, как админа, что ты ее использовал. Даже внутрянняя почта должна соответствовать стандарту. А если ты идешь поперек стандарта, то не вини никого, кроме себя.

Ты эта... не путай AD и домены NT4. Не жили AD в 2000-х без DNS. Так что уже тогда было ясно (и четко сказано), что вся жизнь домена привязана к DNS. И вообще NETBIOS по сути умрет при первой-же возможности. И останется только DNS.

И еще раз, имя домена не обязано соответствовать RFC по email, если ты не собираешься юзать email. Оно должны соответствовать только для email'a.

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

Проблема то не с почтой вообще, а с Exchange 2007. Exim вполне себе справляется и сейчас.

А вот тут-то и проблема. Внутрянняя почта у тебя НЕ СООТВЕТСТВОВАЛА RFC. И то, что раньше MS поддерживала такую конфигурацию никак не оправдывает тебя, как админа, что ты ее использовал. Даже внутрянняя почта должна соответствовать стандарту. А если ты идешь поперек стандарта, то не вини никого, кроме себя.

Да, строго говоря несоответствие есть. Однако оно разрешается внутренними средствами мейлера. Снаружи все ОК - адрес мейлера в DNS разрешается, принимает и высылает только мейлы с нормальными, вполне соответсвующими RFC адресами.

Вот мой 2000 домейн и пользовался собственным DNS, а вся остальная жизнь, включая почту, использовала другой. Теперь эта лафа кончилась

Увы, вариант 1 я выписал по недопониманию. Там недостаточно просто создать новую зону и вставить адресные ссылки на сервера - там еще вагон фолдеров с другими AD ссылкаим (SRV, ссылки на глобальные каталоги итд, плюс еще куча других изменений в AD). Вручную этого не сделаешь. То есть, остается только путь 2 - по сути единственный легальный путь для таких изменеий. И для этого у M$ есть специальные тулы. Там можно не только менять DNS и/или NETBIOS имена домена, но и менять структуру домена. То есть, просто смена имен это одна из простейших задач для данных инструментов. И эти тулы подготавливают корректные новые DNS зоны.

Пререквизиты вроде есть (процедура описана тут, готовый к инсталляции Exchange сервер будет командовать парадом). Деваться мне некуда, на уикеэнде придется проводить процедуру. Ничего сверхестественного там нет, нужно очень точно следить за шагами. Только теперь придется тщательно продумать новые имена (чтобы потом не было мучительно больно за бесцельно прожитые годы )

мой тебе совет- использовать доменное имя то, которое зарегено в "большом интернете". А потом в DNS'e уже разруливать что видно снаружи, а что нет, чтоб внутренние адреса снаружи не светились. Так оно проще будет и не должно быть мучительно больно.

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

Думал я об этом. Куча плюсов, но, боюсь, не пойдет. У меня свой внешний домен со своим DNS. Естественно, у него primary зона (одна из secondary у провайды). А AD хочет сама быть primary => то есть, желательно, чтобы эти серверы друг друга не видели. Проблема решается, если внешний DNS сервер с внешней primary зоной сидит в DMZ и обслуживает только запросы из внешней сети. Вторй DNS сервер (тоже в DMZ) своих зон не имеет (разве что внутренние, не имеющие отношения к AD), наружу посылает только запросы, сам запросов снаружи не обслуживает, а обслуживает только запросы из внутренней сети и на него форвардятся DNS серверы AD. Кстати, очень секюрная конфигурация получается - primary сервер моей внешней зоны внутреннюю сеть вообще видеть не будет, и если его завалят или поломают хитро*умными запросами, то ничего страшного не произойдет (по крайней мере в течении TTL). А второй сервер (наверное, лучше cache only), обслуживающий запросы из внутренней сети, снаружи завалить будет гораздо труднее - он запросы из внешней сети будет игнорировать. А это, кстати, идея, придется ее обмозговать и, пожалуй, даже реализовать (это я про разделение внешнего DNS сервера на два, с разными функциями).

Но я отвлекся. Безотносительно к вопросу о сосуществовании двух primary DNS серверов, имеющих зоны с однаковыми именами (но разными сетями и IP-адресами), тут возникнет небольшой геморрой с получением (из внутренней сети) IP-адресов внешних машин нашей сетки (DNS сервер AD не будет никуда форвардить запросов на имена своей зоны, он там сам primary). То есть, такие имена и адреса придется дублировать из внешей зоны во внутреннюю. Некоторые общие имена, (например, www.mydomain.xxx) придется зарезервировать только для внешней сети (а изнутри должны быть видны и внешний и внутренний www серверы, так что для внутреннего придется придумывать другое имя). Да и с реверсом своих зон будут проблемы - у меня внешние машины в очень разных сегментах сети сидят - то есть, запросы придется форвардить наружу и очень бдительно следить, чтобы внешние имена ненароком не дублировались во внутренней сети. В общем, очком чую, до добра это не доведет... Но у меня есть еще время поразмышлять на эту тему до утра субботы.

Аналогично. Несколько лет назад я был очень рад, когда мы избавились от 5.5 (тоже был геморрой) и перешли на Exim с IMAP, аутентификация через LDAP на Windows сервере. Но новый шеф хочет Exchange... Если бы я знал заранее все грабли, на которые уже наступил, то скорее всего не мучался бы вообще с апргрейтом старого 2000 домена, а построил бы параллельно новый 2003 с нуля вместе с Exchange итд. Правда, тут тоже хватает граблей Но руководсво хочет побыстрее (да и не предвидел я таких заморочек), во и пришлось перестраивать работающий домен. А теперь уже отступать некуда, теперь только вперед.

Что-то ты там с DNS-aми мудришь не в ту сторону. Вполне обычное решение на www.mydomain.com выдавать разные адреса в зависимости от того, откуда пришел запрос. Да и с дубляжом не ясно... зачем дублировать? Поставить в dmz кеширующий сервер, который за твоей зоной будет лазать к тебе в AD и всё. А ты к нему за внешними хостами наружу. Primary для твоей зоны будет в AD. В описании зоны прописан тот, который в DMZ. Ну в общем, всё вроде должно быть просто и понятно...

QUOTE (FiL @ 15-02-2008, 00:07)

Что-то ты там с DNS-aми мудришь не в ту сторону. Вполне обычное решение на www.mydomain.com выдавать разные адреса в зависимости от того, откуда пришел запрос.

Это просто, если на DNS сервере(ах) две разные зоны - одна открытая интернет для запросов снаружи, вторая окрытая во внутреннюю сеть, для запросов из внутренней сети. И обе зоны master - внутренняя потому как это нужно для работы AD, внешняя потому как мастер официально зарегистрированного домена.

QUOTE

Да и с дубляжом не ясно... зачем дублировать? Поставить в dmz кеширующий сервер, который за твоей зоной будет лазать к тебе в AD и всё. А ты к нему за внешними хостами наружу. Primary для твоей зоны будет в AD. В описании зоны прописан тот, который в DMZ. Ну в общем, всё вроде должно быть просто и понятно...

Если этот кеширующий сервер будет обслуживать внешних клиентов и лазить за моей зоной mydomain.com внутрь в AD, то все мои внутренние IP-адреса буду открыты для публичного обозрения. То есть, мне однозначно нужно иметь две разные зоны - одну для внешнего DNS и другую для внутреннего пользвания, недоступную снаружи.

Кстати, http://forums.msexchange.org/m_1800436336/mpage_1/key_/tm.htm#1800436336тут[/URL] рассмотрены три возможных решения для внутренней зоны - mydomain.com, subdomain.mydomain.com, mydomain.internal. Там же и куча ссылок. И глваная проблема первого решения именно необходимость дублирования (по крайней мере части) записей внешней зоны во внутреннюю. Плюс возможные конфликты DNS. Пока наиболее симпатичным кажется второе решение.

Или про дублирование ты имел в в виду, зачем дублировать серверы (один для запросов снаружи, второй для запросов изнутри)? Секюрити. http://www.isaserver.org/tutorials/You_Need_to_Create_a_Split_DNS.htmlТут[/URL] это подробно описано. Без меня люди додумались, это еще покруче, чем я раньше написал.

ЗЫ. Ссылки почему-то отображаются некорректно

QUOTE (valja @ 15-02-2008, 12:28)

Если этот кеширующий сервер будет обслуживать внешних клиентов и лазить за моей зоной mydomain.com внутрь в AD, то все мои внутренние IP-адреса буду открыты для публичного обозрения. То есть, мне однозначно нужно иметь две разные зоны - одну для внешнего DNS и другую для внутреннего пользвания, недоступную снаружи.

нет. не обязательно. Я сейчас не могу подробнее расписать, у меня времени нет, через 3 минуты уезжаю. Но можно на одну зону разным клиентам разные адреса выдавать.