Недавно в одной из организаций, с которой я сотрудничаю было принято решение перейти на режим терминальной работы с заменой всех компьютеров в сети на бездисковые рабочие станции (терминалы). Сразу встал вопрос - каким образом организовать разграничение доступа в Интернет для пользователей будущего сервера терминалов? Ранее эта проблема легко решалась на шлюзе под управлением FreeBSD с помощью IPFW и NetAMS, благо каждый пользователь сети однозначно идетифицировался по собственному IP. Но в новых условиях работы все пользователи будут выходить в интернет с одного физического адреса, а именно сервера терминалов. Долгое гугление дало одно-единственное решение - proxy-сервер с авторизацией. Статья SQUID+AD на этом сайте помогла сделать окончательный выбор. Не могу сказать, что я пришел в восторг от перспективы создания домена, да еще на Мастдае, но другой альтернативы нет. Но первое же "лабораторное" тестирование будущей схемы (на VMWARE) принесло еще один неприятный сюрприз - для подъема Active Directory жизненно необходим DDNS (Dynamic DNS) сервер. Таковой у меня имелся на том же шлюзе - "старый добрый" BIND, но Мастдай наотрез отказался с ним работать, ссылаясь на маловразумительные ошибки типа "SERVER_FAILURE", при этом, разумеется, в логах BIND никаких ошибок не было. Если же поднимать DNS на самом контроллере домена, ситуация искривлялась еще больше - появлялись два DNS сервера, обслуживающих одну и ту же зону, при этом обновлять ее РЕАЛЬНЫМИ ДАННЫМ мог только BIND (именно ему DHCP сообщал свои данные при выдаче новых адресов, да и TFTPD для загрузки по PXE тоже находится на FreeBSD). Замаячила совсем уж безрадостная перспектива подъема на Мастдае DHCP и TFTP. Но на это я, как говорил герой одной замечательной комедии, "пойтить не могу"!. Новое гугление принесло еще больше неразберихи - кто-то утверждал, что ему удалось заточить BIND для обслуживания запросов Active Directory, другие в один голос утверждали, что это невозможно, более того, возникший вследствие такого решения букет проблем превратит жизнь админа-испытателя в сущий ад, а закончится все неминуемым падением домена и полным разрушением Active Directory вообще :). Ну, как говорится, "глаза боятся, а руки делают", тем более я то пока буду "тренироваться на кошках".
2. Как же она работает или для чего Active Directory DNS?
На верный путь наставила статья "Dynamic DNS and Windows 2000 at Yale University"
(http://babs.its.yale.edu/yalead/ddns.asp). В ней достаточно подробно описано почему наличие DDNS так необходимо Мастдаю, что именно ему требуется от него, какие данные он там хранит и как использует. Если вкратце - для запуска многих служб (LDAP, Kerberos, Global Catalog и т.д.) ему необходимо иметь информацию, на каких серверах домена они запускаются и работают. Для этого в DNS заносятся соответствующие "SRV" записи. Но это еще не все: по идеологии мелкомягких локальная зона обязана содержать еще ряд вложенных зон (_msdcs, _tcp и прочие). Именно эти зоны он и апдейтит для занесения туда нужных ему сведений. Ну тут все понятно - парни из Редмонда готовы спать на потолке и брюки одевать через голову, лишь бы быть не такими как все остальные. Одни имена подзон чего стоят, если вспомнить, что underscore "_" в именах доменов вообще-то запрещены RFC :). Вобщем, ничего "военного" масдайный DNS в себе не несет, а значит мы вполне сможем без него обойтись.
3. Настраиваем BIND.
Вообще-то для безопасного обновления зон в BIND предусмотрен механизм ключей (hmac-md5), которыми BIND обменивается с желающими обновить ту или иную зону. Разумеется, гордая птица Мастдай выше все этого и ничего подобного делать не станет. Поэтому разрешения на обновления зон будет выдавать на определенный(ные) IP, на что BIND будет разумеется ругаться. Предположим, что у меня есть зона TEST.LOCAL с подсетью 192.168.10.0/24. BIND установлен на хосте с именем squid.test.local. Терминальный сервер иметт IP 192.168.10.10 и называется t-server.test.local. В named.conf она описана как:
zone "test.local" { type master; file "dynamic/test.local"; };
zone "10.168.192.in-addr.arpa" { type master; file "dynamic/10.168.192.in-addr.arpa"; };
Нам нужно создать ACL для обновления зон и указать в нем адрес контроллера домена. А так же создать следующие подзоны для корректной работы Active Directory:
$ORIGIN . $TTL 86400 ; 1 day DomainDnsZones.test.local IN SOA squid.test.local. root.test.local.( 200110220 ; serial 28800 ; refresh (8 hours) 7200 ; retry (2 hours) 2419200 ; expire (4 weeks) 86400 ; minimum (1 day) ) NS squid.test.local. $ORIGIN DomainDnsZones.test.local.
файл DomainDnsZones.test.local
$ORIGIN . $TTL 86400 ; 1 day ForestDnsZones.test.local IN SOA squid.test.local. root.test.local.( 200110220 ; serial 28800 ; refresh (8 hours) 7200 ; retry (2 hours) 2419200 ; expire (4 weeks) 86400 ; minimum (1 day) ) NS squid.test.local. $ORIGIN ForestDnsZones.test.local.
Проверям, что владельцем всех файлов в каталоге dynamic является bind
#chown bind *
и делаем BIND-у рестарт
#/etc/rc.d/named restart
И бежим смотреть в логи:
Jul 16 14:27:31 squid named[1182]: starting BIND 9.3.4-P1 -t /var/named -u bind Jul 16 14:27:31 squid named[1182]: zone 'test.local' allows updates by IP address, which is insecure Jul 16 14:27:31 squid named[1182]: zone '10.168.192.in-addr.arpa' allows updates by IP address, which is insecure Jul 16 14:27:31 squid named[1182]: zone '_msdcs.test.local' allows updates by IP address, which is insecure Jul 16 14:27:31 squid named[1182]: zone '_sites.test.local' allows updates by IP address, which is insecure Jul 16 14:27:31 squid named[1182]: zone '_tcp.test.local' allows updates by IP address, which is insecure Jul 16 14:27:31 squid named[1182]: zone '_udp.test.local' allows updates by IP address, which is insecure Jul 16 14:27:31 squid named[1182]: zone 'DomainDnsZones.test.local' allows updates by IP address, which is insecure Jul 16 14:27:31 squid named[1182]: zone 'ForestDnsZones.test.local' allows updates by IP address, which is insecure Jul 16 14:27:31 squid named[1182]: command channel listening on 192.168.10.1#953 Jul 16 14:27:32 squid named[1182]: running
Как и ожидалось есть ругань в сторону безопасности, но в целом все путём и BIND готов.
Теперь можно поднимать Active Directory. Мастер dcpromo на определенном этапе проверит указанный ему DNS и никаких изъянов в нем не обнаружит :) Через некоторое время в папке dynamic появятся файлы *.jnl (логи BIND), а еще через некоторое время в файлах зон появятся записи навроде этих:
Не смотря на то, что с BIND проблему решить удалось, я все таки остался недоволен всей схемой решения в целом. Ну не люблю я, образно говоря, ковырять в зубах спичкой, если под рукой есть зубочистка :) Это я про то, что proxy-сервер в моем понимании должен заниматься ПРОКСИРОВАНИЕМ, а не контролем доступа или квотированием трафика. Есть для этого гораздо более удобные и функциональные инструменты, как, например, уже упомянутые выше NetAMS и IPFW. Да и само по себе поднятие домена только ради избирательной раздачи Интернета (в случае работы всех пользователей в терминале все можно прекрасно разрулить локальными политиками) - тоже пальба из пушки по воробьям.
PS: сейчас я прорабатываю одну схемку, которая позволит мне обойтись без домена, прокси, ntlm аутентификации и всего этого кордебалета. Точнее говоря, будет использована старая добрая схема фильтрации по IP, но с учетом особенности работы в терминале. Если получится - обязательно напишу еще одну статью.
Друг , отправь мне пожалуйста примеры редактирования всех файлов на базе FREE BSD особенно касательно Active Directory. Мне интересно знать где прописать юзеров и пароли для входа в домен.
Я могу поднять все службы ( AD, DNS ... ) на win... 2003 server
Молодец, мне на старом BIND рулилось проще - вычитывались логи мастдаевского сервера и заносились в конфу локальной зоны. Потом зону один раз проапдейтили, и ... запретили это делать в дальнейшем (до смены состава компов в организации). Работает как часы, только, логи пришлось давить в DHCP.
Добавлять комментарии могут только зарегистрированные пользователи. [ Регистрация | Вход ]