Ж у р н а л   о   к о м п ь ю т е р н ы х   с е т я х   и   т е л е к о м м у н и к а ц и о н н ы х   т е х н о л о г и я х
СЕТИ И СИСТЕМЫ СВЯЗИ on-line
  ПОИСК: ПОДПИСКА НА НОВОСТИ: НОМЕР:
    ДОМОЙ • Архив: Новостей | Конференций | НомеровПодписка
 
   
 
   
    
РЕДАКЦИЯ
 
Все о журнале
Подписка
Как проехать
Где купить
Отдел рекламы
График выхода журнала
Адреса в Интернет

РУБРИКАТОР
   
• Инфраструктура
• Информационные
   системы

• Сети связи
• Защита данных
• Кабельные системы
• Бизнес
• Колонка редактора
• Электронная
   коммерция

• Только на сервере
• Системы
   учрежденческой
   связи

• Новые продукты


Rambler's Top100

  

Интеграция NetWare и Windows NT

Джеймс Дрюз

Дебаты о том, какая операционная система лучше – NetWare или Windows NT, продолжаются. Но зачем непременно ставить себя в условия выбора? Почему не воспользоваться достоинствами каждой из них? Конечно, на бумаге это выглядит просто, но как на практике совместить работу ОС Windows NT и NetWare? С какими проблемами вам придется столкнуться на пути интеграции двух систем?

В нашем центре компьютерных исследований вот уже в течение нескольких лет мы используем системы NetWare фирмы Novell и Windows NT фирмы Microsoft и достигли неплохих успехов в их интеграции. В настоящий момент мы поддерживаем более 200 рабочих станций под управлением Windows NT 4.0 в среде NetWare 4.11.

Решение использовать совместно Windows NT и NetWare вполне оправданно. Ведь в нашем распоряжении оказались достоинства обеих платформ — устойчивая операционная система и мощная сетевая поддержка, тем более что интегрировать NetWare и Windows NT становится все проще, в особенности после выхода программного средства Z.E.N.works (Zero Effort Networks): фирма Novell взяла на себя решение большей части проблем администрирования и управления настольными системами.

Регистрация в сети

Одной из основных проблем, с которой мы столкнулись, было то, что в случае с Windows NT необходимо обеспечить аутентификацию пользователя на локальной рабочей станции или в домене. И хотя эта задача решается различными способами, наиболее очевидный из них — создание всех необходимых пользовательских учетных записей на каждой рабочей станции NT. Можно поступить еще проще: для аутентификации пользователей создать домен NT, но этот сценарий требует наличия в сети сервера Windows NT. Мы не рассматриваем здесь эту возможность, поскольку наша пользовательская база, насчитывающая около 5 тыс. студентов, уже работающих с деревом NDS, постоянно меняется.

Другое решение — использование общей учетной записи Windows NT для всех пользователей. Это потребует создания единого пользовательского объекта на всех рабочих станциях NT (либо одного объекта в домене). В этой модели пользователям не нужно будет знать о существовании данной учетной записи: опция Auto Admin Logon может быть установлена в реестре каждой рабочей станции. Недостатком такого подхода является то, что пароль учетной записи представлен в реестре обычным текстом и может быть легко прочитан любым пользователем. К тому же становится несколько сложнее отследить, кто использует рабочую станцию с помощью встроенных в Windows NT средств аудита. Когда мы впервые установили Windows NT в лабораториях, мы решали проблему именно таким образом и лишь потому, что функции, описанные ниже, еще не были доступны в продуктах, с которыми мы работаем.

С помощью клиента для NT фирмы Novell — IntranetWare Client for NT и Workstation Manager мы нашли еще одно решение: Workstation Manager дает возможность клиенту Novell динамически создавать пользовательские учетные записи на всех рабочих станциях, где это необходимо. Таким образом, учетные записи или общая учетная запись NT могут создаваться на основе имени пользователя и пароля NetWare, что позволяет избежать необходимости вручную создавать и настраивать учетные записи на всех рабочих станциях подряд.

Workstation Manager также может удалять учетные записи с рабочих станций после того, как пользователь отключается. Но все равно остается один вопрос: нельзя ли каким-нибудь образом избежать генерации уникальных значений системного идентификатора ID на машине NT при создании и удалении динамических учетных записей? Короткий ответ — нет. Даже если вам придется входить в систему и выходить из нее по 100 раз в день, вы не выйдете за рамки возможных значений SID по крайней мере в течение 100 лет. SID — это уникальный ID, который присваивается каждой пользовательской учетной записи на рабочей станции NT. Windows NT не использует SID повторно — после того, как учетная запись была удалена. У нас в университете многие пользователи работают за разными машинами и в течение одного дня приходят и уходят по многу раз. Именно поэтому для создания временных учетных записей и их удаления после использования мы решили применить Workstation Manager. Это также помогает не засорять каталог C:\WINNT\Profiles, так как в нем Windows NT содержит информацию о локальных учетных записях.

В большинстве случаев создание и удаление динамических учетных записей должно стать приемлемым решением. Хотя, если вы позволяете пользователям делать свои настройки (схему цветов, фоновую заставку, пиктограммы и т. п.), имеет смысл задействовать мобильные пользовательские профили (roaming profiles), но это мы обсудим позже. Если ваши пользователи не склонны часто менять рабочую машину, вам лучше отказаться от механизма временных учетных записей. Тем самым вы сэкономите несколько секунд во время регистрации пользователя в сети, поскольку системе не нужно будет копировать каталог с пользовательскими профилями.

Объекты администрирования

Для того чтобы установить Workstation Manager в программу NWAdmin фирмы Novell, необходимо инсталлировать дополнительный модуль, создающий объекты NT Configuration. Эти объекты контролируют обработку учетных записей Workstation Manager. Они позволяют определять, например, какой тип регистрационного меню NetWare Client для Windows NT отображается во время входа в сеть, какие сценарии регистрации и файлы системной политики (policy files) применяются и как создаются локальные учетные записи. Каждый объект NT Configuration может быть связан с объектами User (пользователь), Group (группа) или OU (Organizational Unit — организационная единица).

В лаборатории мы создали два разных объекта NT Configuration: Normal Users — объект, создаваемый по умолчанию, и Administrators. Большинство наших пользователей относятся к категории Normal User — это студенты нашего же университета. Даже если пользователи отнюдь не студенты, все равно это решение с небольшими модификациями подойдет для любой корпоративной среды. Объекты Normal и Administrator NT Configuration различаются между собой тем, что последний включен в группу NT Administrators, в то время как профили Normal User связаны с каждым из объектов OU в дереве NDS.

Наша конфигурация определяет, что временная учетная запись должна быть создана на машине Windows NT при входе пользователя в систему, а файл системной политики — считываться с рабочей станции. Последний мы решили хранить на локальной рабочей станции, так как сотрудники факультета могут использовать Workstation Manager на своих персональных офисных машинах и мы не хотели бы, чтобы установленная нами конфигурация мешала их собственным настройкам.

Немного о доверии

Недостатком этой модели является необходимость доверять каждому администратору в дереве. При реализации этого подхода возникает и другая проблема, когда объект NT Configuration связан с объектом типа Группа. Если объект Пользователь входит более чем в одну группу, невозможно предсказать, какой объект NT Configuration будет использован во время регистрации.

С этим можно справиться, тщательно спланировав организацию связей объектов NT Configuration с организационными единицами или отдельными пользователями. Таким образом, если вы связываете конфигурации с объектами типа группа, то пользователь, принадлежащий более чем одной группе, получит только свой объект конфигурации Windows NT. Это гарантирует, что машина будет сконфигурирована соответствующим образом, поскольку при выборе конфигурации пользовательские объекты имеют наивысший приоритет.

Перечисленные проблемы должны быть решены в новых клиентах NetWare, которые будут поставляться вместе с ОС NetWare 5 и инструментарием Z.E.N.works фирмы Novell. Эти клиенты предоставят администратору возможность управлять настройками как отдельных пользователей, так и самих рабочих станций, включая параметры системной политики, данные о требуемых драйверах печати, разрешение мобильных пользовательских профилей и конфигурацию клиента Client32. Имея полную версию Z.E.N.works, администраторы могут устанавливать ограничения на регистрацию доступа для любой рабочей станции. Кроме того, поскольку администратор может заблокировать доступ к объектам рабочих станций NT в дереве, то остальные не смогут их модифицировать.

Четвертое решение проблемы интеграции — «научить» рабочую станцию NT «говорить» на языке NDS. С помощью пакета NDS for Windows NT фирмы Novell пользователи идентифицируются в домене под контролем NDS, администраторам надо всего лишь добавить их в объект домена в дереве NDS. Эта опция требует чуть боўльших затрат на администрирование, но при продолжительном применении экономит время, особенно если вы работаете с приложениями, требующими аутентификации в домене Windows NT, такими, как Microsoft Exchange и другими приложеними BackOffice.

Но при применении NDS для NT остается одна проблема — синхронизация паролей, так как в NDS и NT реализованы различные методы шифрования для хранения паролей. Если вы для изменения паролей используете SETPASS, DOS NetWare Administrator или утилиту третьей фирмы, синхронизация между паролями NDS и NT нарушится: пароль изменится только в NDS.

Поддержка «мобильных» пользователей

Поддержка обновленной версии файла NTUSER.DATОдна из проблем, с которой мы столкнулись, — что делать с приложениями, которые заносят свои записи в раздел реестра HKEY_CURRENT_USER. В идеальном случае этот раздел реестра должен использоваться только для запоминания пользовательских настроек, отличных от установок по умолчанию. К сожалению, многие приложения заносят туда установки, которые необходимы для запуска приложения.

Что же делать администратору? Если вы уже работаете с такими приложениями или утилитами, как WinINSTALL фирмы Seagate Software или NAL (Novell Application Launcher) фирмы Novell, в комбинации с утилитой snAppShot фирмы Novell, то сможете легко определить, какие установки в HKEY_CURRENT_USER были созданы при инсталляции приложений. С этой информацией вы создаете файл .REG, который разные пользователи будут импортировать перед запуском определенного приложения. Конечно, это не лучший выход из положения.

Для решения этой проблемы мы следим, чтобы файл NTUSER.DAT, расположенный в каталоге WINNT\Profiles\ Default User, регулярно обновлялся. Мы настраиваем клиент на рабочих станциях NetWare таким образом, чтобы вместо пользовательских профилей на них применялись динамические и временные учетные записи. Последние создаются на рабочей станции Windows NT, когда пользователь регистрируется в сети. По завершении сеанса работы учетная запись удаляется. При такой схеме пользователь каждый раз, входя в систему, получает обновленные копии необходимых файлов, включая и NTUSER.DAT, который содержится в каталоге WINNT\Profiles\Default User. Получить обновленную копию файла NTUSER.DAT несложно. Используя WinINSTALL, мы определяем те приложения, установки которых хранятся в HKEY_CURRENT_USER и создаем файл .REG, который может быть использован для импортирования в NTUSER.DAT. Для обновления файла NTUSER.DAT необходимо проделать следующее:

  • зарегистрироваться на машине в качестве администратора;
  • создать локальную учетную запись пользователя (например, REGUSER);
  • зарегистрироваться под именем REGUSER;
  • импортировать установки реестра через файл .REG;
  • зарегистрироваться на машине в качестве администратора;
  • скопировать файл NTUSER.DAT из каталога Profiles пользователя REGUSER в каталог Default User;
  • удалить учетную запись REGUSER с локальной машины NT.

Итак, решив проблему регистрации, неплохо было бы сделать так, чтобы каждая рабочая станция NT, которую вы настроили, «помнила» бы выбранную схему цветов, фон и установки ярлыков. Если вы выбрали вариант с клиентом Novell, у вас есть возможность сохранить эти установки. При работе с Client32 файл NTUSER.DAT, содержащий раздел реестра HKEY_CURRENT_USER, и другие файлы из пользовательского каталога Profiles остаются на сервере NetWare, таким образом сохраняя предпочтения каждого пользователя.

Место хранения этих файлов зависит от версии NetWare. Если у вас установлена NetWare 3.х или даже более ранние версии, использующие базу данных Bindery, то эти профили хранятся в пользовательском каталоге Mail на томе SYS. В схеме NDS они располагаются в разделе Windows NT 4.0 Workstation Profile, в каталоге соответствующего пользователя.

Еще один совет: для нормального функционирования должно быть включено пространство имен типа LONG для серверов 4.11 или OS2 для серверов 4.0х. При регистрации на рабочей станции вышеупомянутый каталог переносится на локальную рабочую станцию. Изменения копируются обратно после окончания сеанса. В случае сбоя, происшедшего до того, как пользователь выйдет из системы, все изменения будут потеряны. Если пользователь снова работает за той же самой машиной, то клиент Windows NT определит, что локальная копия пользовательского профиля является более новой, чем копия, хранящаяся на сервере, и он запросит, какую версию необходимо применить.

В текущем клиенте NetWare набор мобильных пользовательских профилей реализуется на уровне рабочей станции. При их применении пользователи данной рабочей станции только выиграют.

При работе с Z.E.N.works набор мобильных пользовательских профилей реализуется на уровне объекта Пользователь. Позволяя лишь определенным пользователям иметь мобильные профили, вы сможете предупредить множество потенциальных проблем. Например, если настройки одного и того же приложения отличаются на разных машинах, то установки реестра, которые хранятся в HKEY_CURRENT_ USER и следующие за пользователем от машины к машине, могут неверно указывать на расположение файлов в конкретной файловой системе. Другие установки, такие, как ярлыки рабочего стола, также могут быть ошибочными, так как указанные в них пути к файлам были созданы для другой машины.

Все это становится довольно обременительным при применении мобильных пользовательских профилей. Если вы работаете с Microsoft Internet Explorer 4.0, то вам нужно будет обратить внимание еще на одну проблему конфигурации. Когда мы экспериментировали с мобильными профилями у себя в лаборатории, возникла одна неприятная проблема — кэш файлов браузера Internet Explorer переместился из каталога, общего для всех пользователей, в каталог, приписанный к профилю конкретного пользователя. Мы обнаружили, что это вызывает серьезные задержки, когда пользователь начинает или заканчивает сеанс работы в среде Windows NT. К счастью, мы смогли решить эту проблему, изменив установки IE 4.0.

Необходимо также обратить внимание на то, что некоторые приложения хранят свои настройки в разделе реестра HKEY_CURRENT_USER. Это не так страшно, если вы работаете с приложениями, которые установили сами, но у вас могут не запускаться приложения, инсталлированные другими пользователями, включая программы, установленные администратором. Мы решили эту проблему, добившись того, что файл NTUSER.DAT, расположенный в каталоге WINNT\ Profiles\Default User, своевременно обновлялся (см. врезку «Поддержка обновленной версии NTUSER.DAT»).

Файл NTUSER.DAT содержит раздел реестра HKEY_ CURRENT_USER. Когда пользователь первый раз начинает сеанс работы на рабочей станции NT, система копирует каталог WINNT\Profiles\ Default User в его каталог Profiles. Это позволяет администраторам иметь базовый набор опций, предварительно сконфигурированных для пользователей.

Установка файлов системной политики

Для поддержки рабочих станций NT полезно запомнить следующее правило: не игнорируйте файлы системной политики. С их помощью вы сможете контролировать различные настройки рабочей станции NT и пользовательских профилей, включая ограничение доступа к окну панели управления и схеме цветов рабочего стола. Для установки параметров системной политики мы применяем утилиту POLEDIT фирмы Microsoft. Независимо от того, работаете ли вы с клиентом Microsoft или Novell, файл NTCONFIG.POL, расположенный на соответствующем сервере, используется для установки ограничений.

Недостатком данного подхода является то, что файлы .POL должны быть расположены на всех серверах сети, по крайней мере на тех из них, которые рабочая станция может выбрать в качестве предпочитаемого. Если Default Computer или Default User используются для установки ограничений системной политики, то для пользователей или рабочих станций, которые не являются частью заблокированного домена (в нашем случае это сотрудники факультета), будут созданы дополнительные записи в файле .POL. В случае, когда системному администратору понадобится исключить некоторых пользователей или часть рабочих станций, это может стать для него серьезной проблемой. Ведь для каждого пользователя, который должен быть исключен, нужно создать отдельную запись в POLEDIT.С помощью клиента Z.E.N.works фирма Novell сделала возможным выполнение почти всего, что можно сделать с помощью POLEDIT в рамках NDS. К тому же становится намного легче контролировать учетные записи пользователей и машины, к которым вы хотите применить ограничения. К сожалению, в настоящий момент в продукте не предусмотрено средств добавления в интерфейс пользовательских расширений. Но фирма Novell планирует ввести такие функции в следующей версии клиента.





  
10 '1998
СОДЕРЖАНИЕ

колонка редактора

• Наперегонки со светом

локальные сети

• Недорогие серверы на базе Pentium II

• Экранировать или не экранировать?..

• Интеграция NetWare и Windows NT

• Локальная сеть - кварц или медь?

• RAID: концепция живет и развивается

• Новые программные средства закрывают брешь в управлении Windows NT

бизнес

• NT-серверы IBM вырываются вперед

• SMCC расширяет каналы сбыта

• Слияние двух надежд

интернет и интрасети

• Ingram - поставщик услуг электронной коммерции

• Лоцманы в море информации

корпоративные сети

• Бум пропускной способности

• Технология ATM и современные корпоративные сети

• Хвала Общей информационной модели

• Объектное расширение реляционной СУБД: зачем и как (Часть II. Как?)

• Выбираем пограничный коммутатор ATM

услуги сетей связи

• Интернет и ТфОП: вопросы подключения маршрутизаторов к городским АТС

• Проблемы внедрения технологии DSL

защита данных

• Средства контроля безопасности на базе протокола IP

• Резервирование в централизованных системах бесперебойного электропитания

системы учрежденческой связи

• Аспекты техобслуживания цифровых УПАТС



 Copyright © 1997-2007 ООО "Сети и Системы Связи". Тел. (495) 234-53-21. Факс (495) 974-7110. вверх