Никакая аутентификация пользователя

Никакая Аутентификация пользователя UAM не требует никакой информации аутентификации. Когда FPLogin и FPLoginExt команды не используют Аутентификацию пользователя UAM, нет никакого параметра UserAuthInfo. Соответствующее нечувствительное к регистру имя протокола UAM ни для Какой Аутентификации пользователя UAM No User Authent. Когда пользователь входит в систему как Гостевой пользователь, Никакой UAM Аутентификации пользователя используется.

Для реализации средств управления доступом каталога, описанных позже в этом разделе, сервер должен присвоить Идентификатор пользователя и Группу ID пользователю для сеанса.

Числа Идентификатора пользователя и Идентификационные номера Группы присваиваются от того же пула чисел. Кроме того, начиная с AFP 2.1, серверы AFP должны присвоить нуль пользователям, входящим в систему как Гостевой пользователь и 1 Администратору/Владельцу.

В этом UAM сервер присваивает пользователю «Всех» права доступа для каждого каталога в каждом объеме сервера. «Все» права доступа описаны в разделе Directory Access Controls.

Пароль в виде открытого текста

Пароль в виде открытого текста UAM передает имя пользователя и пароль к серверу как открытый текст (т.е. не закодированный). Имя протокола для Пароля в виде открытого текста UAM Cleartxt Passwrd.

Для FPLogin команда, UserAuthInfo параметр состоит из имени пользователя (который является строкой до 255 символов Macintosh Roman), сопровождаемый паролем пользователя (до 8 байтов). Для FPLoginExt команда, UserAuthInfo параметр состоит из имени пользователя (который является строкой до 255 символов Unicode), сопровождаемый паролем пользователя (до 8 байтов). Чтобы гарантировать, что пароль пользователя выровненный на ровной границе байта в пакете, клиенту AFP, вероятно, придется вставить нулевой байт (0x00) между именем пользователя и паролем. Если пользователь обеспечивает пароль, который короче, чем 8 байтов, он должен быть дополнен в конце с нулевыми байтами для создания пароля восемь байтов длиной. Допустимый набор символов в паролях состоит из всех 8-разрядных символов ASCII.

Сравнение имени пользователя нечувствительно к регистру, но сравнение пароля чувствительно к регистру для этого UAM. Если существует пользователь указанного имени, пароль которого соответствует пароль, предоставленный вызывающей стороной FPLogin или FPLoginExt, пользователь аутентифицировался, и вход в систему успешно выполняется. Если пароли не соответствуют, a kFPUserNotAuth код результата возвращается.

UAM Пароля в виде открытого текста должен использоваться клиентами AFP, только если прошедшая сеть безопасна против подслушивания. Иначе, информация о пароле может быть считана из FPLogin или FPLoginExt пакеты команды любым слушающим в сети.

Рисунок 3-1 показывает блок запроса для вызова FPChangePassword при использовании Пароля в виде открытого текста UAM.

Exchange случайного числа

В средах, в которых сеть не безопасна против подслушивания, Exchange Случайного числа является более безопасным методом аутентификации пользователей. Имя протокола для этого UAM Randnum Exchange. С Exchange Случайного числа пароль пользователя никогда не отправляется по сети и не может быть взят путем подслушивания. Получение пароля от информации, отправленной по сети, является столь же трудным как повреждение зашифрованного пароля DES.

С Exchange Случайного числа UAM только имя пользователя отправляется в параметре UserAuthInfo FPLogin или FPLoginExt команда. Если имя пользователя допустимо, сервер генерирует восьмибайтовое случайное число и передает его обратно клиенту AFP, вместе с Идентификационным номером и a kFPAuthContinue код результата. kFPAuthContinue код результата указывает, что все хорошо в этой точке, но еще не аутентифицировался пользователь. Клиент AFP тогда шифрует случайное число с паролем пользователя и отправляет результат в сервер в UserAuthInfo параметр FPLoginCont команда вместе с Идентификационным номером возвратилась ранее сервером в блоке ответа от FPLogin или FPLoginExt команда. Сервер использует Идентификационный номер для соединения более раннего FPLogin или FPLoginExt команда с этим вызовом к FPLoginCont. Сервер ищет пароль для того пользователя и использует его в качестве ключа для шифрования того же случайного числа. Если два зашифрованных числа соответствуют, пользователь аутентифицировался, и вход в систему успешно выполняется. Иначе, сервер возвращает a kFPUserNotAuth код результата.

Следующие шаги объясняют Exchange Случайного числа UAM более подробно:

1. Клиент AFP отправляет FPLogin или FPLoginExt блок команды со строкой UAM и UserAuthInfo параметр, содержащий строку имени пользователя. Для FPLogin, имя пользователя может быть до 255 символов Macintosh Roman долго; для FPLoginExt, имя пользователя может быть до 255 символов Unicode долго.

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

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

4. И клиент AFP и сервер используют Стандарт шифрования данных Национального института стандартов и технологий (NIST DES) алгоритм для шифрования случайного числа. Чувствительный к регистру пароль пользователя применяется как ключ шифрования для генерации восьмибайтового значения. Сервер применяет тот же алгоритм к паролю, который это считает связанным с именем пользователя в его базе данных.

5. Клиент AFP отправляет зашифрованное значение в сервер в UserAuthInfo параметр FPLoginCont команда, вместе с Идентификационным номером это получило от сервера. Сервер использует Идентификационный номер для соединения предыдущего FPLogin или FPLoginExt команда с ее соответствием FPLoginCont команда.

6. Сервер сравнивает зашифрованное значение клиента AFP с зашифрованным значением, полученным с помощью пароля от его пользовательской базы данных. Если два зашифрованных значения соответствуют, процесс аутентификации завершен, и вход в систему успешно выполняется. Сервер возвращает код результата kFPNoErr клиенту AFP. Если два зашифрованных значения не соответствуют, сервер возвращается kFPUserNotAuth код результата.

Рисунок 3-2 показывает блок запроса для вызова FPChangePassword при использовании Exchange Случайного числа UAM.

Двухсторонний Exchange случайного числа

С Двухсторонним Exchange Случайного числа UAM пользователь аутентифицируется к серверу, и сервер аутентифицируется пользователю, принимающему меры против спуфинга (т.е. с помощью поддельного сервера для получения паролей или данных). Этот метод использует те же шаги в качестве Exchange Случайного числа UAM с тремя дополнительными шагами. Соответствующая строка UAM 2-Way Randnum.

Когда клиент отправляет, как Exchange Случайного числа UAM, Двухсторонний Exchange Случайного числа запускается UAM FPLogin или FPLoginExt запросите к серверу, включающему имя пользователя пользователя. Если сервер находит имя пользователя в базе данных имени пользователя, сервер возвращает Идентификационный номер, восьмибайтовое случайное число и код результата kFPAuthContinue. Клиент тогда кодирует случайное число с паролем пользователя и отправляет закодированное число и Идентификационный номер к серверу в FPLoginCont запрос. Если закодированный пароль соответствует копию сервера случайного числа, закодированного копией сервера пароля, клиент аутентифицируется и kFPNoErr возвращается.

Дополнительные шаги Двухстороннего Exchange Случайного числа

1. Клиент отправляет к серверу FPLoginCont запрос, включающий второе восьмибайтовое случайное число.

2. Сервер кодирует второе восьмибайтовое случайное число с, он - копия пароля пользователя от пользовательской базы данных и возвращает закодированное случайное число в FPLoginCont блок ответа.

3. Клиент кодирует случайное число с паролем пользователя и сравнивает его с закодированным случайным числом от сервера. Если они соответствуют, сервер также аутентифицируется.

Рисунок 3-3 показывает запрос и блочные форматы ответа для FPLoginCont команда, когда Двухсторонний Exchange Случайного числа используется UAM.

Двухсторонний Exchange Случайного числа UAM не доступен для использования с FPChangePassword команда. Вместо этого Exchange Случайного числа UAM должен использоваться для изменения пароля. Пользователь, уже вошедший в систему с помощью Двухстороннего Exchange Случайного числа UAM и кто изменяет его или ее пароль, уже аутентифицировал сервер, таким образом, нет никакой потребности аутентифицировать сервер снова при помощи Двухстороннего Exchange Случайного числа UAM.

Обмен ключами Диффи-Хеллмана

Обмен ключами Диффи-Хеллмана (DHX) является реализацией Протокола Согласования ключей Diffie-Hellman с помощью реализации SSLeay/OpenSSL CAST 128 в режиме CBC. Имя протокола UAM для DHX ‘DHCAST128’.

DHX силен против пакетных атак сниффинга, но уязвим для активных атак такой “Человек в Середине”. Нет никакого способа для клиента проверить, что сервер знает пароль, таким образом, мог легко имитироваться сервер. Существует некоторая слабость в использовании фиксированных векторов инициализации, p и g. Когда сервер требует паролей в открытом тексте, DHX полезен.

С DHX клиентом и сервером каждый генерирует случайное число, Ra и Rb соответственно, служащие «закрытыми ключами» для сеанса. Возведение в степень модуля использования клиента и сервера, чтобы получить «открытые ключи», маму и Мбит, от закрытых ключей и обмениваться ими. Клиент комбинирует Ра и Мбит, и сервер комбинирует маму с Rb для генерации идентичных сеансовых ключей, K.

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

Когда UAM является DHX, таблица 3-1 перечисляет значения, используемые для вычисления содержания сообщений, которыми обмениваются между клиентом и сервером.

Для DHX константы p и g определяются следующим образом (MSB сначала):

UInt8 p = { 0xBA, 0x28, 0x73, 0xDF, 0xB0, 0x60, 0x57, 0xD4, 0x3F,  0x20, 0x24, 0x74,  0x4C, 0xEE, 0xE7, 0x5B  };

UInt8 g = { 0x07 };

Для DHX, клиент к серверу (C2SIV) и сервер клиенту S2CIV), векторы инициализации определяются следующим образом:

UInt8 C2SIV[] = { 0x4c, 0x57, 0x61, 0x6c, 0x6c, 0x61, 0x63, 0x65  };

Uint8 S2CIV[] = { 0x43, 0x4a, 0x61, 0x6c, 0x62, 0x65, 0x72, 0x74  };

Входя в систему Используя DHX

Последовательность входа в систему при использовании DHX UAM состоит из обмена четырьмя сообщениями, показанными в Таблице 3-2. В Таблице 3-2 символ вертикальной черты (|) используется для разделения элементов, составляющих сообщение.

Табличная 3-2  последовательность Входа в систему с помощью DHX

Сообщение	Отправитель/Получатель	Содержание
1	Клиент к серверу	| FPLogin (2 байта) | AFP Vers | ‘DHCAST128’ | имя пользователя (дополненное) | мама |
2	Сервер клиенту	| ID | Мбит | (данный случай, ServerSig, S2CIV) K | и код результата
3	Клиент к серверу	| FPLoginCont (2 байта) | ID | (данный случай + 1, пароль, C2SIV) K |
4	Сервер клиенту	Код результата kFPNoErr если аутентификация была успешна

В ответ на сообщение 1 сервер может возвратить следующие коды результата (но это может задержать отправку некоторых из этих кодов результата до сообщения 4):

• kFPBadUAM — сервер не поддерживает DHX UAM.

• kFPBadVersNum — сервер не поддерживает требуемую версию AFP.

• kFPParamErr — имя пользователя не допустимо.

• kFPMiscErr — сеанс уже аутентифицируется.

• kFPServerGoingDown — сервер закрывается.

• kFPUserAlreadyLoggedOnErr — сервер позволяет только один активный сеанс на пользователя.

• kFPAuthContinue — сервер подготовлен продолжать входить в систему процесс.

Сервер может задержать отправку некоторых вышеупомянутых кодов результата до четвертого сообщения, или может отчет a kFPUserNotAuth результат как kFPParamErr ограничить сумму информации, раскрытой клиенту.

В ответ на сообщение 3 сервер может возвратить любой из следующих кодов результата:

• kFPNoErr — аутентификация была успешна; сервер дешифровал данный случай/пароль и проверил, что данный случай был постепенно увеличен должным образом, и пароль, отправленный клиентом, соответствует пароль на сервере.

• kFPUserNotAuth — пароль является неправильным.

• kFPParamErr — аутентификация перестала работать, и сервер предпочитает не указывать, недопустимы ли имя пользователя или пароль.

• kFPPwdExpiredErr — пароль пользователя истек.

• kFPPwdNeedsChangeErr — пароль пользователя должен быть изменен.

Рисунок 3-4 показывает запрос и блоки ответа для FPLogin при использовании DHX UAM.

Изменение паролей Используя DHX

Нет никакого эквивалента FPLoginCont при изменении пароля, таким образом, клиент должен отправить FPChangePassword команда, по крайней мере, дважды и использование ID для отслеживания состояние изменяющего пароль процесса. ID сначала появляется в сообщении 1 и установлен в 2 байта 0x00. Сервер отправляет ненулевое значение за ID в сообщении 2, и клиент должен скопировать его с сообщения 2 в сообщение 3. Ключ, используемый для шифрования старых и новых паролей, создается таким же образом как ключ при входе в систему. Значения p и g являются теми же значениями, использующимися при входе в систему.

При использовании DHX UAM, последовательность изменения пароля состоит из обмена по крайней мере четырьмя сообщениями, показанными в Таблице 3-3. В Таблице 3-3 символ вертикальной черты (|) используется для разделения элементов, составляющих сообщение.

Табличная 3-3  последовательность Изменения пароля с помощью DHX

Сообщение	Отправитель/Получатель	Содержание
1	Клиент к серверу	| FPChangePassword (2 байта) | ‘DHCAST128’ | Имя пользователя (дополненное) | ID (0x00 0x00) | мама |
2	Сервер клиенту	| ID | Мбит | (данный случай, ServerSig, S2CIV) K | и код результата
3	Клиент к серверу	| FPChangePassword (2 байта) | ‘DHCAST128’ | Имя пользователя (дополненное) | ID | (данный случай + 1, newPassword, oldPassword, C2SIV) K |
4	Сервер клиенту	Код результата kFPNoErr если был изменен пароль

В ответ на сообщение 1 сервер может возвратить любой из следующих кодов результата (или может ожидать, пока это не получает второе FPChangePassword команда для возврата первых трех кодов результата):

• kFPBadUAM — сервер не поддерживает DHX для изменения паролей.

• kFPParamErr — имя пользователя не допустимо.

• kFPServerGoingDown — сервер закрывается.

• kFPAuthContinue — сервер подготовлен продолжать изменяющий пароль процесс.

В ответ на сообщение 3 сервер может возвратить любой из следующих кодов результата:

• kFPNoErr — пароль был изменен.

• kFPUserNotAuth — старый пароль является неправильным.

• kFPParamErr — ограничить сумму информации, выпущенной клиенту.

• kFPPwdPolicyErr — новый пароль не соответствует политике паролей сервера.

• kFPPwdSameErr — новый пароль совпадает со старым паролем.

• kFPPwdTooShortErr — новый пароль слишком короток.

Рисунок 3-5 показывает запрос и блоки ответа для вызова FPChangePassword с DHX UAM.

Обмен ключами Диффи-Хеллмана 2

Обмен ключами Диффи-Хеллмана 2 (DHX2) является реализацией Протокола Согласования ключей Diffie-Hellman с помощью реализации SSLeay/OpenSSL CAST 128 в режиме CBC. Имя протокола UAM для DHX2 ‘DHX2’.

DHX2 отличается от DHX в начале использования того DHX2 переменного размера (p) и генератор (g) значения, который позволяет серверам выбирать надлежащий уровень безопасности. Минимальный размер начала увеличен до 512 битов для улучшения сопротивления численным методам атаки. Кроме того, в отличие от DHX, DHX2 не использует подпись сервера (ServerSig) в сообщении 2.

DHX2 силен против пакетных атак сниффинга, но уязвим для активных атак такой “Человек в Середине”. Нет никакого способа для клиента проверить, что сервер знает пароль, таким образом, мог легко имитироваться сервер. Существует некоторая слабость в использовании фиксированных векторов инициализации, p и g, улучшенного путем помещения случайных данных случаев сначала в зашифрованных частях сообщений. Когда сервер требует паролей в открытом тексте, DHX2 полезен.

Как с DHX, в DHX2 клиент и сервер каждый генерирует случайное число, Ra и Rb соответственно, служащие «закрытыми ключами» для сеанса. Возведение в степень модуля использования клиента и сервера, чтобы получить «открытые ключи», маму и Мбит, от закрытых ключей и обмениваться ими. Клиент комбинирует Ра и Мбит, и сервер комбинирует маму с Rb для генерации идентичных сеансовых ключей, K.

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

Когда UAM является DHX2, таблица 3-4 перечисляет значения, используемые для вычисления содержания сообщений, которыми обмениваются между клиентом и сервером.

Для DHX2 клиент к серверу (C2SIV) и сервер клиенту (S2CIV) векторы инициализации определяются следующим образом:

UInt8 C2SIV[] = { 0x4c, 0x57, 0x61, 0x6c, 0x6c, 0x61, 0x63, 0x65  };

Uint8 S2CIV[] = { 0x43, 0x4a, 0x61, 0x6c, 0x62, 0x65, 0x72, 0x74  };

Kerberos

Клиент AFP учится, поддерживает ли сервер Kerberos UAM путем исследования kSupportsDirServices бит в Flags параметр, возвращенный FPGetSrvrInfo команда. Если тот бит установлен, сервер, поддерживающий Kerberos, UAM помещает свое основное имя в DirectoryNames параметр, возвращенный FPGetSrvrInfo.

Клиент AFP использует основное имя, чтобы определить, поддерживает ли сервер Kerberos v4 или v5.

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

• два байта Flags параметр

• Строка версии AFP

• Строка UAM (Client Krb v2)

• kFPUTF8Name (определенный как 3)

• длина следующего имени пользователя

• Имя пользователя UTF-8–encoded

• kFPUTF8Name (определенный как 3)

• длина области в этом следует

• Область UTF-8–encoded

Сервер отвечает с кодом результата kFPAuthContinue. Блок ответа содержит два байта ID значение.

Если клиент использует Kerberos v4, он вызывает FPLoginCont, обеспечение следующих значений в блоке запроса:

• Имя пользователя UTF-8–encoded

• байт клавиатуры, если Вы необходимы, чтобы вынудить имя пользователя закончиться на ровной границе

• длина следующего билета

• тикет, созданный KClientGetTicketForService()

Если сервер возвращает код результата, пользователь аутентифицируется kFPNoErr и блок ответа, состоящий из параметра два байта длиной и аутентификатора.

Если клиент использует Kerberos v5, он вызывает FPLoginCont, обеспечение следующих значений в блоке запроса:

• ID, возвращенный FPLoginExt

• Имя пользователя UTF-8–encoded

• байт клавиатуры, если Вы необходимы, чтобы вынудить имя пользователя закончиться на ровной границе

• длина следующего билета

• тикет, созданный gss_init_sec_context с GSS_C_MUTUAL_FLAG и GSS_C_REPLAY_FLAG набор и никакая привязка канала

Если сервер возвращает код результата, пользователь аутентифицируется kFPNoErr и блок ответа, состоящий из параметра два байта длиной и аутентификатора.

После того, как клиент получает FPLoginCont ответный пакет, клиент отправляет FPGetSessionToken команда с типом kGetKerberosSessionKey (8) для получения случайного сеансового ключа от сервера. Этот сеансовый ключ шифруется на использовании сервера gss_wrap() и дешифрован на клиенте, использующем gss_unwrap(). Обратите внимание на то, что клиент может вызвать FPGetSessionToken позже для получения маркера разъединения.

Рисунок 3-6 показывает запрос и блоки ответа для FPLoginExt и FPLoginCont при использовании Kerberos UAM.

Переподключение

В отличие от другого UAMs, описанного в этом разделе, которые используются для входа сервера AFP, Переподключение, которое UAM используется только, чтобы повторно подключить к серверу. UAM Переподключения может использоваться, когда первоначальное соединение было сделано с помощью UAM, обеспечивающего сеансовый ключ, такой как DHX, DHX2 и Kerberos. Имя протокола UAM для Переподключения UAM ‘Recon1’.

Цели Переподключения UAM:

• Хранилище в маркере, возвращенном FPGetSessionToken команда вся требуемая информация, чтобы повторно соединиться, даже если был перезагружен сервер.

• Используйте только безопасную хеш-функцию и симметричный алгоритм шифрования.

• Обеспечьте взаимную аутентификацию, чтобы доказать, что сервер, с которым повторно соединяется клиент, является тем же первоначально аутентифицировавшимся сервером.

• Гарантируйте, чтобы поставивший под угрозу сеансовый ключ или отобрал значение, не поставит под угрозу долгосрочный ключ сервера.

Таблица 3-7 перечисляет переменные, используемые для вычисления значений для Переподключения UAM.

Для переподключения UAM, клиент к серверу (C2SIV) и сервер клиенту S2CIV), векторы инициализации определяются следующим образом:

UInt8 C2SIV[] = { 0x57, 0x4f, 0x4d, 0x44, 0x4d, 0x4f, 0x41, 0x42 };

Uint8 S2CIV[] = { 0x57, 0x4f, 0x4d, 0x44, 0x4d, 0x4f, 0x41, 0x42 };

Таблица 3-8 описывает общие методы атаки и путей, которыми Переподключение UAM защищен от этих атак.

id = (t1, cid)k1

cred = (s, m, exp, t3, user, domain)ks

(sessionInfo, s, m, exp, cred)k1

id = (t1, cred)k1

k2 = (cred, s)H

cred' = (s', m', exp', t3', user, domain)ks

(sessionInfo, s', m', exp', cred')k2

Используя учетные данные, чтобы повторно соединиться

Если соединение с сервером теряет работоспособность по какой-либо причине, у клиента есть текущие учетные данные (cred), Lamports хешируют семя (s), и максимальное количество времен для выполнения хеша (m). Сервер знает долгосрочный ключ сервера (ks).

1. Клиент регистрирует назад в использовании FPLoginExt команда, указывая Recon1ReconnectLogin как UAM и отправка следующей информации к серверу:

   (sig, (s)H(n), n, t2, (clientNonce)k, cred)

   Где sig

   ((s)H(n), n, t2, (clientNonce)k)HMAC(s)

   и k

   (s)H(n-1)

2. Сервер использует свой долгосрочный сеансовый ключ (ks) дешифровать cred. Если дешифрование перестало работать, сервер приводит попытку входа в систему к сбою.

3. Если дешифрование успешно выполняется, сервер получает s, m, exp, t3, user, и domain от учетных данных.

4. Сервер вычисляет (cred)H и ищет его в списке аннулирования. Если найдено, учетные данные истекли, таким образом, сервер приводит попытку входа в систему к сбою.

5. Если (cred)H не найден в списке аннулирования, проверках сервера exp, m >= n, и HMAC(s) user/domain. Если кто-либо недопустим, сервер приводит попытку входа в систему к сбою.

6. Сервер вычисляет (s)H(n) использование s от дешифрованных учетных данных и n от клиентского пакета и сравнивает результат со значением (s)H(n) если в клиентском сообщении. Если они не соответствуют, сервер приводит попытку входа в систему к сбою.

7. Сервер дешифрует и хеширует clientNonce, выбирает serverNonce, добавляет (cred)H, t3+now к списку аннулирования, и отправляет следующее значение клиенту:

   (serverNonce, (clientNonce)H)k

   где k

   (s)H(n-1)

8. Клиент дешифрует значение, проверяет (clientNonce)H, и хеши serverNonce. Клиент использует FPLoginCont команда для отправки следующего значения в сервер:

   ((serverNonce)H)k

   где k

   (s)H(n-1)

9. Сервер дешифрует значение и проверяет (serverNonce)H. Если они не соответствуют, сервер приводит попытку входа в систему к сбою.

10. Если они соответствуют, сервер отвечает клиенту с кодом результата kFPNoErr. Клиент теперь зарегистрирован.

11. И сервер и клиент делают следующее вычисление:

    k1' = (clientNonce, serverNonce)H

12. Клиентские вызовы FPGetSessionToken использование k1' как сеансовый ключ для получения новых учетных данных. Это также вызывает FPDisconnectOldSession сказать серверу разъединять старый сеанс и передавать его ресурсы новому сеансу.

Таблица 3-11 суммирует обмен между клиентом и сервером при пересоединении.

Наследованные права доступа

Версия 2.1 AFP и более поздние поддержки наследовались, права доступа через Пустые Права доступа каталога укусили в битовом массиве Каталога. То, когда Пустые Права доступа укусили, установлено для каталога, его другие биты права доступа проигнорированы, и биты права доступа родителя каталога применяются к каталогу, включая присоединение группы родителя.

Пустые Права доступа укусили, не может быть установлен для каталога, который является точкой доли. Аналогично, Пустые Права доступа укусили, не может быть установлен для корневого каталога объема (Каталог ID = 2) совместно используемого тома, потому что это всегда - точка доли для администратора/владельца.