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

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

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

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

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


Rambler's Top100

  

Windows Services for Unix 2.0: новые возможности — новые проблемы

Эрик А. Холл

Пакет Windows Services for Unix 2.0 открывает новые возможности для кроссплатформенного взаимодействия, хотя и вносит отдельные проблемы в работу корпоративной сети.

Cколько лет существуют локальные вычислительные сети, столько же лет и проблемам интеграции различных сетевых платформ, выражающимся в том, что пользователи, работающие на одной платформе, не имеют полноценного доступа к данным, размещаемым на других платформах. И почти все это время производители предлагают продукты, позволяющие в той или иной степени разрешить эти проблемы.

Что касается пользователей операционной системы Microsoft Windows NT, то производители поддерживают их довольно однобоко. Если какую-никакую поддержку сред Apple Computer AppleTalk и Novell NetWare компания Microsoft в своем продукте Windows NT Server предоставляла всегда, то в отношении интеграции в среду Windows NT Unix-систем этого, к сожалению, не скажешь — по крайней мере, так было до выхода в прошлом году ее пакета Windows NT Services for Unix версии 1.0. По сути дела, этот продукт стал первым заслуживающим внимания решением для интеграции Windows NT с Unix, поскольку предоставляет многие базовые службы, такие, как сетевая файловая служба NFS (Network File System) и telnet-доступ. Правда, отсутствие в нем отдельных важных компонентов, например сервера NIS (Network Information Services), и всевозможные проблемы с качеством его функционирования заметно мешали его широкомасштабному внедрению в корпоративную среду.

Выпустив продукт Windows Services for Unix 2.0, Microsoft устранила кое-какие слабые места, имевшиеся в его первой версии, и повысила качество его работы. К сожалению, при этом не только не были ликвидированы в полном объеме старые проблемы, но были внесены и многочисленные новые. В довершение всего некоторые новые возможности могут быть реализованы лишь при развертывании этого продукта на серверах Windows 2000, а следовательно, недоступны для тех, кто хотел бы воспользоваться этими функциями, но по тем или иным причинам не может в одночасье перейти на Windows 2000. Последнее утверждение в большей степени касается сложных, крупномасштабных сетевых сред, в которых проблемы кроссплатформенной интеграции стоят особенно остро. Это связано с тем, что корпоративные сети чересчур сложны и изменения инфраструктуры в масштабе всего предприятия должны проводиться не сразу, а постепенно.

Улучшения имеются

В конце концов, если учесть все плюсы и минусы продукта Windows Services for Unix 2.0, то его можно оценить как лучший по сравнению с Windows NT Services for Unix 1.0, но это еще не означает, что он является самым лучшим решением для администраторов, стремящихся интегрировать свои сетевые службы Windows и Unix. Если говорить о пользователях версии 1.0 этого продукта, то им, несомненно, стоит установить его вторую версию, но в то же время многие администраторы только выиграют, если по-прежнему будут использовать решения, основанные на Unix, в частности сервер Samba, или инструментальные средства интегрирования NFS—NIS, устанавливаемые на Windows-клиентах. И тем не менее, несмотря на все слабые места версии 2 этого продукта, мы бы рекомендовали опробовать его всем, кто работает в смешанной сетевой среде, так как он действительно имеет много привлекательных возможностей.

Администраторы должны сами решать, какие из многочисленных компонентов, входящих в состав пакета Services for Unix 2.0, им устанавливать в своей сети, мы же сфокусировали свои испытания на службах NIS (которые функционируют только в среде Windows 2000), NFS со шлюзом (последний из которых позволяет серверу Windows NT объявлять смонтированные на удаленных системах каталоги NFS как разделяемые локальные ресурсы SMB) и telnet. К другим компонентам, входящим в пакет Windows Services for Unix 2.0, относятся клиент NFS, сервер PC-NFSD (NFS daemon), сервер RSH (remote shell), интерпретатор языка программирования Perl компании ActiveState и множество утилит для работы в среде Unix.

Централизованное управление пользователями

Наиболее притягательной характеристикой пакета Windows Services for Unix 2.0 является весьма многообещающая и заманчивая возможность объединения учетных записей пользователей Windows и Unix на базе имеющихся в составе пакета серверов NIS и PC-NFSD. Эта возможность, позволяющая определять учетные записи пользователей, управлять ими с единого устройства, обеспечивать аутентификацию и доступ пользователей к любым сетевым ресурсам с самых разных платформ, всегда была заветной мечтой сетевых администраторов. Однако воспользоваться ею удастся далеко не каждому пользователю, поскольку эффективность ее реализации в значительной степени зависит от особенностей сетевой среды и изобретательности сетевых администраторов, да и работает она не всегда должным образом.

В состав ядра Windows Services for Unix 2.0 входит служба User Name Mapping, которая отображает учетные записи пользователей и групп Unix в их Windows-эквиваленты, а также используется сервером NFS и его шлюзом для отображения списков контроля доступа (Access Control List — ACL) файловой системы.

Служба User Name Mapping способна извлекать идентификаторы пользователей и групп пользователей Unix из базы данных сервера NIS или из локально определяемых файлов “passwd” и “group”. Соответствующие учетные записи могут динамически отображаться в учетные записи Windows NT или Windows 2000 (например, в том случае, если учетная запись “ehall” платформы Unix соответствует учетной записи “ehall” платформы Windows NT), или для них задаются явные соответствия по типу “один ко многим” (когда одной учетной записи “ehall” платформы Windows NT ставятся в соответствие учетные записи “ehall” и “eric_hall” платформы Unix).

После определения всех данных службы User Name Mapping любой хост Windows Services for Unix готов к их использованию (например, удаленный сервер NFS может использовать образы списков контроля доступа службы User Name Mapping локального сервера). Таким образом, если учетные данные, зарегистрированные на всех платформах вашей сети, совместимы между собой, то достаточно отобразить их всего один раз.

На серверах Windows 2000, которые задействуют справочник Active Directory, сервер NIS может применяться локально.

В таком случае в схему базы данных Active Directory включается информация о пользователях и группах пользователей Unix, такая, как UID (идентификатор пользователя) и GID (идентификатор группы пользователей), домашний каталог, предпочтительная программная оболочка и т. д. Эта информация считывается службой User Name Mapping (описанной выше) путем указания клиенту NIS агента отображения на локальный сервер NIS. По существу, это позволяет выполнять рекурсивное отображение данных о пользователях и группах, хранящихся в справочнике Active Directory.

Наше тестирование показало, что с каждым из этих механизмов связаны те или иные проблемы. На свою систему, работающую под управлением Windows NT Advanced Server, мы скопировали с локального сервера Caldera Systems OpenLinux 2.3 файл паролей и групп и выполнили его динамическое и статическое отображение. Пользовательские учетные данные, которые были получены путем динамического отображения, не обеспечивали полноценного доступа к разделяемым ресурсам NFS этого сервера. Это выражалось в том, что механизм отслеживания прав доступа Windows NT время от времени отвергал запросы на доступ к ресурсам на основе динамически отображенных учетных записей пользователей. В случае же явного отображения учетных записей пользователей эти проблемы не возникали. И все же иногда статически отображаемая база учетных данных вдруг бесследно исчезала, и мы были вынуждены при каждом внесении изменений в базу данных заново создавать образы учетных записей вручную. Однако мы так быстро привыкли к этой весьма специфической процедуре, что стали воспринимать ее как нечто должное. Правда, в службе технической поддержки Microsoft нам обещали, что этот дефект программы будет в скором времени устранен.

На своем локальном сервере Windows 2000 Advanced Server мы установили серверный компонент службы NIS и определили атрибуты пользователей и групп пользователей, используемые в среде Unix — UID, GID и пр. Однако сервер NIS не предоставляет все данные полностью и не позволяет их полноценно редактировать. Например, на запросы ypcat passwd удаленных клиентов NIS возвращались все данные о пользователях, за исключением их полных имен. Кроме того, в сервере NIS не предусмотрено преобразование объявленного в Unix имени пользователя или группы пользователей. Это привело к тому, что мы не смогли преобразовать группу “Domain Users” в “users”, как это принято в среде Unix. По мнению представителей Microsoft, единственным способом объявления альтернативного имени является его изменение в процессе включения в справочник Active Directory.

Следует, однако, иметь в виду, что такой способ преобразования имен может негативно отразиться на степени информационной безопасности сети хотя бы потому, что сервер NIS распространяет данные о паролях и именах пользователей в относительно незащищенном виде. Если вы решите использовать сервер NIS для опубликования данных, содержащихся в базе учетных записей пользователей справочника Active Directory, то должны отдавать себе полный отчет в том, что любой человек, способный инициировать команду ypcat passwd, сможет легко расшифровать ваши учетные данные. Этот недостаток свойственен всем серверам NIS, и все же забывать об этом не следует.

Еще одна проблема, связанная с сервером NIS, состоит в том, что он запрещает назначение пользователям и группам пользователей идентификаторов UID и GID, меньших 100. Это означает, что вы не сможете применять встраиваемый модуль NIS справочника Active Directory для опубликования системных учетных записей. Хотя это, возможно, является весьма важной мерой обеспечения информационной безопасности, однако эффективность наших усилий по интеграции различных сетевых платформ от этого весьма заметно страдала, поскольку мы хотели бы хранить на сервере NIS учетную запись “httpd”, а также учетные записи некоторых других системных служб. К тому же если говорить о службе статического отображения учетных записей, то она не имеет подобных ограничений и позволяет свободно отображать учетную запись “root” пользователя с UID, равным 0, в учетную запись “Administrator” платформы Windows NT, а учетную запись группы “system” с GID, равным 0, в учетную запись группы “Domain Admins”. Хотя имеется возможность изменять идентификаторы UID и GID вручную, редактируя их численные значения, хранимые в справочнике Active Directory, нам не хотелось бы заниматься этим регулярно.

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

Однако если вы все-таки используете службу отображения файлов, то вам необходимо задать точное соответствие между различными образами учетных записей, с тем чтобы механизм обеспечения прав доступа Windows NT к разделяемым ресурсам NFS функционировал безукоризненно и не создавал проблем, аналогичных тем, с которыми нам приходилось сталкиваться при отображении списков ACL, используя службу динамического отображения данных.

Обратите внимание на то, что сервер PC-NFSD, входящий в ПО Services for Unix 2.0, не использует сервер User Name Mapping для аутентификации запросов клиентов NFS на установление соединения. Поэтому администраторам приходится для этой цели создавать дополнительную базу данных. Фактически это приводит к удвоению числа задач, возлагаемых на администраторов, и к возникновению дополнительных проблем синхронизации паролей, что, в свою очередь, ограничивает потенциальные возможности пакета Services for Unix 2.0 как единой платформы управления учетными записями пользователей.

Совместное использование файловых систем через NFS

Наиболее ценным в пакете Windows Services for Unix 2.0 является серверный компонент файловой системы NFS, позволяющий серверам Windows NT и Windows 2000 объявлять свои файловые системы FAT, CD-ROM и NTFS как разделяемые ресурсы NFS. Как оказалось, он хорошо справляется со всеми этими задачами, хотя системным администраторам, возможно, и придется столкнуться с отдельными, характерными именно для него проблемами.

Процесс предоставления файловых систем в совместное пользование на основе NFS является относительно простой операцией. Вам лишь следует указать встраиваемому модулю MMC (Microsoft Management Console) сервера NFS на сервер User Name Mapping, с тем чтобы передать ему информацию о том, на какие учетные записи пользователей и групп Windows NT и Windows 2000 следует отображать учетные записи NFS.

Кроме того, модуль MMC обеспечивает регистрацию системных событий (правда, для этого он использует не журнал Event Log, а обычный текстовый файл), разблокировку файлов на определенное время и конфигурирование “клиентских групп” (client groups), представляющих собой группы машин, учетные записи которых используются для контроля расширенного доступа к разделяемым ресурсам NFS. Настроив все конфигурационные параметры, разделяемые ресурсы NFS можно совсем просто создать, воспользовавшись диспетчером файлов Windows Explorer.

Если вы собираетесь совместно использовать какую-либо папку через NFS, вы присваиваете ей разделяемое имя и определяете права доступа клиентской группы NFS к данному разделяемому ресурсу. При этом списки контроля доступа для клиентских групп предоставляют более широкий уровень доступа к разделяемому ресурсу, чем списки ACL “родных” файловых систем. Клиентская группа All Machines устанавливается по умолчанию и наделяется правами на запись и считывание информации. Дополнительные клиентские группы могут иметь записи контроля доступа, ограничивающие полномочия доступа NFS только считыванием информации, или записи, открывающие разделяемый ресурс для привилегированного доступа пользователей определенных систем, что позволяет администраторам устанавливать необходимый уровень доступа для каждой конкретной системы.

К сожалению, все это может стать слишком обременительным, поскольку каждый сервер NFS имеет свои собственные независимые клиентские группы, каждая из которых содержит свой набор индивидуально обслуживаемых машин. Например, вы хотите, чтобы некоторые системы имели доступ к четырем различным NFS-серверам с полномочиями root; для этого вы должны отредактировать клиентские группы на каждом из этих четырех серверов и явно назначить полномочия привилегированного доступа к каждому разделяемому ресурсу каждого хоста для каждой группы. Если эти клиенты добавляются путем указания имени хоста, то IP-адреса, которые использовались ими в тот момент, когда было добавлено имя хоста, будут закреплены за данными именами как разрешающие доступ идентификаторы. Если сервер DHCP назначает системам новые IP-адреса, они лишаются доступа к соответствующим разделяемым ресурсам.

Учитывая то, что операционные системы Microsoft широко используют службу Dynamic DNS, мы надеялись, что интеграция с механизмом предоставления прав доступа, основанным на именах хостов, будет более тесной. Кроме того, нам очень хотелось бы, чтобы информация о клиентских группах хранилась не в системных базах данных, а (когда это возможно) в справочнике Active Directory — хотя бы потому, что значительная часть данных, касающихся хостов, возможно, уже находится в этом справочнике.

После сортировки списков контроля доступа клиентских групп списки ACL пользователей и групп пользователей считываются из соответствующей файловой системы. При этом входящие пары идентификаторов UID—GID будут приведены в соответствие с учетными записями Windows NT и Windows 2000 посредством службы User Name Mapping. Например, если пользователь запрашивает доступ к какому-либо каталогу файловой системы NTFS (NT File Sistem) или файлу, то полномочия доступа NTFS будут определяться уже уровнем доступа, который присвоен данному пользователю. Это вполне работоспособная схема хотя бы потому, что объединенные списки ACL существенно упрощают администрирование файловой системы. В первую очередь такую стратегию оценят те, кому приходилось управлять множеством списков ACL для одного дерева каталогов.

Мы столкнулись с еще одной проблемой: файлы, создаваемые пользователями в файловой системе NFS, оказываются для них недоступными. Те, кто изучал ОС Windows NT, должны помнить, что если имеется несколько одновременно действующих прав доступа (например, когда полномочия доступа некоего пользователя отличаются от полномочий доступа группы пользователей, к которой он относится), то при обработке запроса на доступ применяется полномочие, предоставляющее пользователю наименьшие права, при условии, что одно из них не является полномочием No Аccess (нет доступа), которое подавляет все другие полномочия.

Если пользователь создает на сервере NFS файл, заблокированный для группового доступа, то это равносильно тому, что первичная группа NT, к которой относится этот пользователь, наделяется полномочиями No Аccess. Аналогичная ситуация возникает при создании файла, заблокированного для доступа сторонних (world) пользователей; в этом случае полномочиями No Аccess наделяется NT-группа Everybody. Любая последующая попытка прочитать такой файл приведет к тому, что список ACL с полномочиями No Аccess заблокирует все другие полномочия, отвергая тем самым запрос на доступ.

Так как многие Unix-системы и приложения создают файлы с правами доступа “rwxr- x---”, эта проблема периодически будет всплывать. Для ее устранения достаточно вручную отредактировать реестр таким образом, чтобы он позволил серверу NFS не интерпретировать эти полномочия как No Аccess.

После модификации кода реестра, перезагрузки сервера и переустановки списков ACL файловой системы NTFS проблема блокировки файлов полностью исчезает. Для всех вновь создаваемых файлов по-прежнему сохранится возможность определять явные полномочия его владельца и групповые полномочия, но, даже если они и не будут определены, в списке ACL все равно будет отсутствовать соответствующая этим файлам установка No Аccess.

Что интересно, необходимость явной подстройки реестра, по сути дела, является возвратом к прошлому — пакет Windows NT Services for Unix 1.0 имел множество “ручек и кнопок” для явной настройки элементов управления подобного типа. Однако в пакете Windows Services for Unix 2.0 все элементы управления были полностью упразднены, так что любая необходимая подстройка этого пакета выполняется посредством ручного вмешательства в исходный код реестра. Еще более усугубляет ситуацию полное отсутствие документации, в которой описывалась бы процедура внесения изменений в реестр. Это вынуждает пользователей платить службе технической поддержки Microsoft за инструкции по обеспечению правильного функционирования ее же собственного продукта.

Мы столкнулись и с рядом других проблем, куда более серьезных по той причине, что они могут привести к заметному снижению общего уровня информационной безопасности сети. Во-первых, пользовательские учетные записи, помеченные операционными системами Windows NT и Windows 2000 как “disabled” (отключены), по-прежнему разрешают доступ к файлам сервера NFS. Поскольку контроль доступа к сетевым ресурсам полностью базируется на списках ACL файловой системы, то выполняется лишь проверка полномочий доступа пользователей — никакой их аутентификации не проводится. Если вы блокируете учетную запись конкретного пользователя, то она тем не менее все еще будет продолжать обеспечивать полный доступ через сервер NFS, поскольку полномочия доступа используемой файловой системы не запрещают его. Это не что иное, как распределенная дыра, и мы надеемся, что в ближайшее время компания Microsoft залатает ее.

Во-вторых, если сервер NFS используется для разделения файловой системы FAT (или CD-ROM), то никакого реального контроля доступа не существует и в помине, поскольку в этой файловой системе вообще нет никаких полномочий, ограничивающих доступ. В таком случае любой человек может добраться до любого файла FAT (или CD-ROM), если на его машине смонтирован соответствующий сетевой диск. При условии, например, что учетная запись привилегированного пользователя монтирует разделяемый ресурс во время запуска системы, любой пользователь, имеющий доступ к точке монтирования файловой системы, получает неограниченный доступ к этому разделяемому ресурсу. Хотя эту проблему нельзя оставлять без внимания, все же большинство пользователей едва ли станут разделять файловые системы FAT через сервер NFS, так что риск, связанный с этим, на практике оказывается незначительным. С другой стороны, эта проблема все-таки заслуживает рассмотрения, потому что файловая система FAT, разделяемая через NFS, предоставляет более свободный доступ к ресурсам, чем та же FAT, разделяемая через сервер SMB.

Еще одна потенциальная проблема состоит в том, что любой пользователь, способный редактировать идентификаторы UID и GID, которые он посылает в запросах на доступ к ресурсам, может иметь, по существу, неограниченный доступ к серверу. Например, пользователь вполне способен установить ОС Linux на свой ПК и сформировать учетную запись, имеющую тот же UID, что и пользователь Windows NT, обладающий мощными полномочиями доступа. Поскольку при доступе к сетевым ресурсам через сервер NFS пакета Windows Services for Unix 2.0 аутентификация пользователей не проводится (выполняется лишь контроль доступа), то получение любым из них доступа высокого уровня не представляет никакой проблемы. Хотелось бы, чтобы в следующие версии этого продукта была включена поддержка службы Kerberos, обеспечивающей аутентификацию пользователей сервера NFS.

Службы шлюза NFS

Одним из перспективных компонентов продукта Windows Services for Unix 2.0 является шлюз NFS, действующий в качестве клиента NFS и обладающий дополнительной возможностью повторной публикации удаленных точек монтирования файловой системы NFS как разделяемых ресурсов SMB, доступных для пользователей Windows. Тестирование показало, что этот компонент хорошо работает с разделяемыми ресурсами сервера NFS версии 3 и отнюдь не блещет при использовании разделяемых ресурсов сервера NFS версии 2.

Испытывая NFS-шлюз с разделяемыми ресурсами NFS 3, которые размещены на системе Solaris 7, мы могли легко создавать и редактировать файлы с рабочей станции Windows NT 4.0 посредством протокола SMB. Правда, при этом мы не могли определять никаких полномочий доступа к ресурсам файловой системы (клиент SMB воспринимает разделяемый ресурс как том DOS и не выполняет операцию контроля списков ACL). Поскольку шлюз NFS также использует службу User Name Mapping для корреляции учетных записей пользователей и групп Windows с идентификаторами UID и GID платформы Unix, то чаще всего полномочия по умолчанию нас вполне устраивали. При этом пользователь Windows получал полномочия “owner” (“владелец”) платформы Unix, а основная группа пользователей Windows наряду с группой сторонних пользователей получала полномочия “считывание—исполнение” платформы Unix.

Если все же потребуется внести изменения в эти полномочия, то пользователям придется подключаться к хосту через telnet или монтировать разделяемые ресурсы на сервере NFS и изменять их собственноручно.

Тестируя шлюз NFS с разделяемыми ресурсами NFS 2, принадлежащими хосту Caldera OpenLinux 2.3, мы не добились даже такого уровня функциональности. Что бы мы ни делали, мы так и не смогли “уговорить” шлюз NFS позволить хотя бы одному пользователю создать один-единственный файл в каком-нибудь каталоге: каждая наша попытка завершалась уведомлением о том, что “носитель” доступен только для считывания.

Другой неприятной характеристикой шлюза NFS является неудобство его конфигурирования, которое выражается в том, что отдельные его компоненты приходится конфигурировать в совершенно различных местах. Если для конфигурирования привилегированного сервера User Name Mapping применяется встраиваемый модуль консоли MMC, то для настройки серверов используется контекстное меню окна Network Neighborhood, а для управления отдельными разделяемыми ресурсами NFS — и вовсе внешняя утилита с графическим интерфейсом. Только для того, чтобы понять, как заставить все компоненты шлюза функционировать должным образом, нам пришлось просмотреть кучу документации. Однако после настройки шлюза с разделяемыми ресурсами сервера NFS 3 он работал вполне прилично.

Telnet и остальное

Как мы уже говорили, пакет Windows Services for Unix представляет собой обширный набор инструментальных средств интеграции разнообразных платформ. Некоторые из этих средств, такие, как программа chown, позволяющая задавать владельца файла с помощью интерфейса командной строки, будут удобными для любого администратора Windows. Этот инструментарий крайне полезен уже только потому, что в Windows NT вообще отсутствуют какие бы то ни было средства, обладающие аналогичными функциями.

Другим интересным компонентом пакета Windows Services for Unix 2.0 является сервер telnet, предоставляющий удаленный доступ к серверу Windows NT через интерфейс командной строки. К сожалению, этот компонент не очень хорошо продуман, поэтому и пользы от него немного, если учесть, что в качестве управляющего интерфейса в среде Windows интенсивно используется графический интерфейс. Правда, иногда, когда нам было нужно запускать или останавливать службу с удаленного узла, telnet позволял нам полностью добиться того, чего мы хотели.

Самая же неприятная особенность этой службы — то, что она не поддерживает должным образом управляющие telnet-символы Interrupt Process (Прервать процесс) или Abort Output (Прервать вывод по ошибке), хотя в соответствующих документах RFC они значатся как обязательные. Если вы используете эмулятор терминала, который сервер telnet понимает не полностью (а таких эмуляторов хватает), то вам не удастся так легко вырваться из листинга каталога (или команды chown -r) и придется ждать его завершения, прежде чем исправить свою ошибку или сделать что-нибудь еще. Немаловажно и то, что единственным защищенным механизмом аутентификации, поддерживаемым сервером telnet, является собственный механизм аутентификации Microsoft NTLM. Мы же надеялись, что для аутентификации доступа к разделяемым ресурсам смешанной сетевой среды будет использована недавно внедренная компанией Microsoft технология Kerberos.

Если брать в целом, то пакет Windows Services for Unix 2.0 обеспечивает довольно высокий уровень интеграции серверов Windows NT и Windows 2000 со средой Unix. Вместе с тем он определенно имеет множество узких мест, требующих доработки и усовершенствования. Мы надеемся, что к выходу следующей версии продукта компания Microsoft исправит все его грубые ошибки. И все же, несмотря на недостатки, пакет Windows Services for Unix 2.0 заслуживает самого пристального внимания со стороны сетевых администраторов, тем более что он является единственным продуктом подобного рода на рынке. Сегодня существуют и другие решения, обеспечивающие более высокий уровень интеграции в специфических областях применения (в частности, такие продукты, как Samba, имеют более широкие функциональные возможности по совместному использованию файлов на базе протокола SMB, чем шлюз NFS пакета Windows Services for Unix 2.0). Однако мы думаем, что их можно будет с успехом использовать совместно с этим пакетом.





  
13 '2000
СОДЕРЖАНИЕ

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

• Кризис перепроизводства оптических сетей

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

• Оптическое волокно: борьба микрометров

• Не только видеть, но и "слышать" дефекты кабелей

• Linux бросает вызов

• Windows Services for Unix 2.0: новые возможности - новые проблемы

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

• Резервирование высокоскоростного доступа

• Интегрированные устройства доступа АТМ

только на сервере

• Безотказная электронная почта

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

• Gigabit Ethernet для медного кабеля - высокая скорость передачи и устойчивая работа?

• Новая NDS, или Откуда ждать кроcсплатформенное администрирование

• Модернизация сети: что делать и как

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

• Сетевые приманки и капканы

электронная коммерция

• Обработка электронных платежей

бизнес

• Итоги сентябрьской Интернет-конференции АДЭ

• Региональная дистрибуция, как зеркало российской экономики

• Готовьте Сеть для инвесторов

новые продукты

• "Младшая сестра" в семействе Symmetra, Серверы PRIMEPOWER стали мощнее


• КАЛЕЙДОСКОП



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