Блокировки Level П oplock позволяют нескольким клиентам иметь открытым один файл при условии, что ни один клиент не выполняет операций записи в файл. Это важно для сред со старыми машинами. Большинство открытий в режиме совместимости этих клиентов отображается в запрос открытия для совместно используемого доступа к файлу для чтения/записи. Однако помните, что это может также отменять блокировки oplock для других клиентов, даже если ни один из клиентов в действительности не намерен писать в файл.
Последовательность действий почти такая же, как у исключающей блокировки oplock. Основное различие состоит в том, что сервер информирует клиента, что он должен прекратить блокировку Level II oplock, когда никто не пишет в файл. То есть клиент А, например, может открыть файл для желательного доступа READ и общего доступа READ/WRITE. Это означает, что клиент А не будет выполнять никаких записей в файл.
Когда клиент В открывает файл, сервер должен синхронизироваться с клиентом А, если последний имеет какие-либо буферизованные блокировки Когда он синхронизируется, запрос клиента В на открытие может быть завершен. Клиент В, однако, информируется, что он имеет Level II oplock, а не исключающую блокировку oplock для файла.
В этом случае ни один клиент с блокировкой level П oplock на файле не сможет буферизировать какую-либо информацию блокирования на локальной клиентской машине. Это позволяет серверу гарантировать, что если выполняется какая-либо операция записи, то ему необходимо только уведомить клиентов level II, что блокировка должна быть прервана, без необходимости синхронизации всех аксессоров (средств доступа) файла.
Level II oplock может быть ПРЕРВАНА В НИКУДА (BROKEN ТО NONE), означая, что некоторый клиент, открывший файл, выполнил теперь операцию записи в файл. Так как ни один клиент level II не может создать ситуацию блокирования буфера, то информация на сервере остается в согласованном состоянии. Записывающий клиент, например, не сможет записать в заблокированный диапазон по определению. Однако данные опережающего чтения могут буферизироваться на клиентской машине, снижая тем самым объем сетевого трафика, требуемого файлу. Когда прерывается блокировка level II oplock, буферизирующий клиент должен очистить свои буферы и прекратить выполнение всех операций на файле через сеть. Никакого ответа на прерывание oplock от клиента не ожидается, когда сервер прерывает его из LEVEL II в NONE.
Каждый сервер делает доступными для клиентов в сети множество ресурсов. Ресурсом может быть дерево каталогов, именованный канал, принтер и т.д. Клиентская машина видит сервер как единственного поставщика файла или другого доступного ресурса, поэтому она не знает о каких-либо зависимостях от хранения или службы.
Протокол CIFS требует аутентификации сервера пользователей, прежде чем будет разрешен доступ к файлу, и каждый сервер аутентифицирует своих собственных пользователей. Клиентская система должна посылать информацию аутентификации на сервер, прежде чем сервер разрешит доступ к своим ресурсам.
Протокол CIFS определяет два метода, которые могут быть выбраны сервером для безопасности: общий уровень и уровень пользователя.
Сервер общего уровня делает доступным некоторый каталог на дисковом устройстве (или другой ресурс). Для доступа может потребоваться дополнительный пароль. Таким образом, любой пользователь в сети, знающий имя сервера, имя ресурса и пароль, получает доступ к ресурсу. Серверы с безопасностью общего уровня могут использовать различные пароли для одного и того же общего ресурса, где различные пароли предоставляют различный уровень доступа.
Сервер уровня пользователя делает некоторый каталог на дисковом устройстве (или другой ресурс) доступным, но требует дополнительно, чтобы клиент предоставил имя и соответствующий пароль пользователя для получения доступа. Серверы уровня пользователя могут применить имя учетной записи и пароль, предоставленные клиентом. Серверы уровня пользователя предпочтительнее серверов общего уровня для любой новой серверной реализации, так как организации обычно считают, что сервер уровня пользователя легче администрировать. Серверы уровня пользователя могут применять имя учетной записи для проверки списков контроля доступа на отдельных файлах или иметь один список контроля доступа, который применяется ко всем файлам в каталоге.
Когда сервер уровня пользователя проверяет имя учетной записи и пароль, предоставленные клиентом, идентификатор, представляющий этот аутентифицированный экземпляр пользователя, возвращается клиенту в поле Идентификатор пользователя (UID) ответного SMB. Этот UID должен включаться во все последующие запросы, сделанные от имени пользователя с этого клиента. Сервер общего уровня не возвращает в поле UID никакой полезной информации.
Модель безопасности на уровне пользователя была добавлена после выпуска первоначального диалекта протокола CIFS, и, следовательно, некоторые клиенты могут оказаться неспособными послать имена учетных записей и пароли на сервер. Сервер в режиме безопасности на уровне пользователя, общающийся с одним из таких клиентов, будет позволять клиенту соединяться с ресурсами, даже если клиент не прислал информацию об имени учетной записи и пароле:
1. Если имя компьютера клиента идентично имени учетной записи, известной на сервере, и если предоставленный пароль для соединения с общим ресурсом совпадает с паролем этой учетной записи, неявно будет выполнен "вход пользователя в систему" с помощью этих значений. Если это не сработает, то сервер может отказать в запросе или присвоить используемое по умолчанию имя учетной записи по своему выбору.
2. Значение UID в последующих запросах клиента будет игнорироваться, и весь доступ будет проверяться в предположении имени учетной записи, выбранной выше.
Следующие примеры показывают интерфейс командной строки, позволяющий серверу предлагать дисковый ресурс, а клиенту соединяться и использовать этот ресурс.
a) NET SHARE
Команда NET SHARE при выполнении на сервере определяет имя каталога, который будет сделан доступным для клиентов в сети. Должно быть задано общее имя, которое предоставляется клиентам, желающим получить доступ к каталогу.
Примеры:
NET SHARE docs=c:\dirl\
Делает общедоступными все файлы в каталоге C:\DIR1 и его подкаталогах с общим именем docs в качестве имени, используемого для соединения с этим ресурсом.
b) NET USE
Клиенты могут получить доступ к одному или нескольким предлагаемым каталогам с помощью команды NET USE. Когда посылается команда NET USE, пользователь может свободно получить доступ к файлам без дополнительных специальных требований.
Примеры:
NET USE: d: \\SERVERl\DOCS отображает диск d: в общедоступный каталог DOCS на сервере Serverl. Пользователь может теперь обращаться к файлам на SERVER1 C:\DIR1, используя d:. Например, dir d: *.* выдаст список всех файлов на SERVER1 c:\dirl.
NET USE * \\SERVERl\DOCS mycoolpwd отображает следующий доступный диск, который использует DOCS на server 1, защищенный паролем mycoolpwd.
Для серверов уровня пользователя клиент обычно не должен предоставлять пароль с помощью команды NET USE. Если пользователю предлагается ввести пароль, обычно это указывает на сетевую проблему (например, он не может контактировать с контроллером домена, чтобы проверить полномочия). Этот сценарий предоставляет хорошую возможность проверить инструменты сетевого мониторинга (см. часть IV). Сейчас можно попробовать проверить, существует ли проблема безопасности:
NET USE * \\SERVERl\DOCS/USER:domainname\username password
Клиентское программное обеспечение должно помнить идентификатор диска, поставляемый вместе с запросом NET USE, и связать его со значением идентификатора дерева (TID), возвращаемого сервером в заголовке SMB. Последующие запросы, использующие этот TID, должны включать только имя пути доступа относительно присоединенного поддерева, так как сервер интерпретирует поддерево как корневой каталог (виртуальный корень). Когда пользователь ссылается на один из удаленных дисков, клиентское программное обеспечение просматривает свой список дисков для этого узла и включает идентификатор дерева, связываемый с этим диском в поле TID каждого запроса.
Отметим, что когда каталог объявляется общедоступным, будут затронуты все файлы, лежащие под этим каталогом. Если определенный файл находится внутри области нескольких общих ресурсов, то соединение с любой из областей общих ресурсов получает доступ к файлу с полномочиями, определенными для предложения, поименованного в NET USE. Сервер не будет проверять вложенные каталоги с более ограничительными полномочиями.
Сервер CIFS хранит зашифрованную форму пароля клиента. Чтобы получить аутентифицированный доступ к серверным ресурсам, сервер посылает вызов клиенту, на который клиент отвечает подтверждением, что он знает пароль клиента.
Аутентификация использует шифрование DES в блочном режиме. Функция шифрования DES, обозначенная как Е(К, D), получает семибайтный ключ (К) и восьмибайтный блок данных (D) и создает восьмибайтный зашифрованный блок данных в качестве своего значения. Если данные для шифрования длиннее восьми байтов, функция шифрования применяется к каждому блоку из восьми последующих байтов и результаты соединяются вместе. Если ключ длиннее семи байтов, то данные сначала полностью шифруются с помощью первых семи байтов ключа, затем следующие семь байтов и т.д., соединяя каждый раз результаты. Другими словами, чтобы зашифровать 16-байтовую величину D0D1 с помощью 14-байтового ключа К0К1:
Е(К0К1, D0D1) = Е(К0, D0)E(K0,D1)E(K1, D0)E(K1, Dl)
Поле EnayptionKey (Ключ Шифрования) в ответе SMB_COM_NEGPROT содержит восьмибайтный вызов, обозначенный ниже как "С8", выбираемый уникальным, чтобы предотвратить атаки повторного воспроизведения. Клиент отвечает 24-байтовым ответом, обозначенным "Р24" и вычисляемым, как описано ниже. (Примечание. Имя "EneryptionKef является историческим — оно на самом деле не содержит ключа шифрования.)
Клиент посылает ответ на вызов в запросе SMB_COM_TREE_CONNECT, SMB_COM_TREE_CONNECT_ANDX и/или SMB_COM_SESSION_SETUP_ANDX, который следует за обменом сообщением SMB_COM_NEGPROT. Сервер должен проверить ответ, выполняя те же вычисления, которые делает клиент при его создании, и проверить, что строки совпадают.
Если строки не совпадают, то, возможно, клиентская система неспособна шифровать; если это так, то строка может быть паролем пользователя открытым текстом. Сервер должен попробовать проверить строку, как если бы это был незашифрованный пароль.
Поле SMB, используемое для хранения ответа, зависит от ответа:
Password в SMB_COM_TREE_CONNECT
Password в SMB_COM_TREE_CONNECT_ANDX-
Account Password в SMB_COM_SESSION_SETUP_ANDX
(Примечание. Здесь имена также являются историческими и не отражают это использование.)
Содержимое ответа на вызов зависит от диалекта CIFS, как показано в следующих разделах.
Диалекты протокола NT LM 0.12 и более поздние версии поддерживают операции распределенной файловой системы (DFS — Distributed File System). DFS предоставляет для этого протокола способ использования единственной согласованной схемы именования файлов, которая может охватывать совокупность различных серверов и ресурсов общего доступа. Модель DFS использует модель на основе направлений. Этот протокол определяет способ, которым клиенты получают направления.
Клиент может установить в заголовке запроса SMB флаг, указывающий, что клиент хочет, чтобы сервер разрешил в DFS пути доступа SMB, которые известны серверу. Сервер пытается разрешить запрошенное имя в файл, содержащийся внутри локального дерева каталогов, указанного TID запроса, и затем нормально продолжить. Если путь доступа запроса разрешается в файл на другой системе, то сервер возвращает следующую ошибку.
STATUS_DFS_PATH_NOT_COVERED - сервер не поддерживает часть пространства DFS, требуемую для разрешения пути доступа в запросе. Клиент должен запросить на этом сервере направление для дополнительной информации.
Клиент запрашивает направление с помощью запроса TRANS2-DFS-GETREFERRAL, содержащего интересующий путь доступа DFS. Ответ с сервера указывает, как клиент должен продолжить.
Метод, с помощью которого топологическое представление DFS хранится и поддерживается серверами, не определен этим протоколом.
Заголовок SMB
Хотя каждая команда SMB имеет определенное кодирование, в заголовке SMB есть несколько полей, которые имеют значение для всех SMB. Как можно увидеть в распечатке ниже, протокол SMB выполняется поверх NetBIOS, который переносится поверх TCP, реализованный поверх IP, который реализован поверх метода доступ к среде Ethernet. Эти поля описаны в последующих разделах.
