Table of Contents
この文書にはNTサーバーを使わないでNTワークステーションのログオンサービスを提供するための 情報が記述されている。これはLukeによって管理されている、 http://mailhost.cb1.com/~lkcl/cifsntdomain.txt のsgmlバージョンである。
(NTワークステーションのTCP/IP設定中で)ワークグループの代わりにドメインを選択することは 可能であり、必須である再起動後に、ユーザー名とパスワードを入力し、ドメインを選択すれば 正しくログオンできる。この文書に対する、上記作業の経験からの、何らかのフィードバック 、何らかのコメント、修正と追加事項は歓迎する。
ここで説明するパケットはNetmon.exeによって簡単に(そしておそらくそれを使うことでより よく理解でき)得られる。NETLOGON、lsarpcとsrvsvcトランザクションパイプを正しくデコード するために、使用しているシステムに一致するNetmonのバージョンを使う必要がある。 この文書は、NTサービスパック1の、それに適合したバージョンのNetmonから得られている。 これは、この文書よりもより有益であろう、注釈付きのパケットトレースが生成されることを 目的としている。
また、NTドメインログオンサービスを完全に実装するため、NTの認証の暗号化部分を 説明する文書も必要である。この文書は comp.protocols.smbから公開されている、 ntsecurity.net のからの要約とsamba digestからとその他のソースからのものを使っている。
コピーは以下にある:
http://ntbugtraq.rc.on.ca/SCRIPTS/WA.EXE?A2=ind9708;L=ntbugtraq;O=A;P=2935
http://mailhost.cb1.com/~lkcl/crypt.html
Linus Nordbergによる、 このプロトコルに関するC言語での実装は、以下にある:
http://samba.org/cgi-bin/mfs/01/digest/1997/97aug/0391.html
http://mailhost.cb1.com/~lkcl/crypt.txt
デバッグ情報の提供のためにはNT workstationのCheck Buildバージョンも必要であり、 NETLOGON中で完全なデバッグを有効にする。これは以下のようにして、REG_SZ レジストリーキーを 0x1ffffff に設定することで行える:
HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
不正にレジストリを編集すると、使用しているマシンを動作不能にさせる 事になる。このプロトコルの不正な実装になる。上記の"Liability:"を参照のこと。
ネットワーク上の各パケットはAPI呼び出しにおいて固有のオリジンを持っていることを 心にとめておくこと。そのため、その定義がほかの所で便利に文書化されている、 構造体や列挙型かもしれない。
この文書は、決して完全でも正式でもない。以下のようものだけではなく、 抜けているところがある:
ユーザー名からRID(やその他(へのマッピング。
ユーザーIDとグループIDが何であるかということ。
種々の、特定の定数または列挙型の正確な意味と定義。
ワークステーションがドメインのメンバーになるときの、返されるエラーコードと エラーコードの使用法(後で説明)。失敗時に返されるエラーコードは、ワークステーション上で すでにドメインのメンバーになっているという表示を行わせる。
ワークステーションにそのパスワードを変更させることが出来るようにする、 NetrServerPasswordSetコマンドの暗号化の側面。このパスワードは長期でのセッションキー を生成するのに使われる[このコマンドを拒否するのも可能で、その場合は既定値の ワークステーションパスワードを保持する]。
| cket Traces from Netmonitor (Service Pack 1 and above) |
| ul Ashton and Luke Leighton's other "NT Domain" doc. |
| FS documentation - cifs6.txt |
| FS documentation - cifsrap2.txt |
| Paul Ashton: loads of work with Net Monitor; understanding the NT authentication system; reference implementation of the NT domain support on which this document is originally based. |
| Duncan Stansfield: low-level analysis of MSRPC Pipes. |
| Linus Nordberg: producing c-code from Paul's crypto spec. |
| Windows Sourcer development team |
SMBトランザクションパイプ中で、いくつかの"構造体"がここで説明されていて、 開始時に4バイト境界で整列されたSMBヘッダーがある。正確に"構造体"を整列させる 必要性は、正確には知られても、文書化されてもいない。
UDP NETLOGON Mailslot中で、いくつかの"構造体"がここで説明されていて、開始時に、 mailslotの先頭に2バイト境界で整列されている。
Domain SIDはS-revision-version-auth1-auth2...authNという形式である。たとえば、 Domain SID is of the format S-revision-version-auth1-auth2...authN. S-1-5-123-456-789-123-456である。ここで、5はサブバージョンでもありえる。
参照する文字バッファーが文字を含むなら、文書化されていないバッファーポインターは0以外で なければならない。それが正確に何であるかは不明である。0x0000 0002は、バッファーが 存在することを指示するためのトリックを行っているように見える。もしも、バッファー ポインターがNULLの場合、構造体が参照するものはSMBデータストリームへ(あるいは から) 置かれない。これは、経験的に得られたものであり、例えば、バッファーポインターがNULLの、 LSA SAMログオンレスポンスパケットのユーザー情報はデータストリーム中には挿入されない。 いろいろと推測することは出来るが、バッファーポインターの配列が正確になんなのかは 未知である。
構造体(コンテナー)の配列は、カウンターとポインターを持つように見える。もしもカウンターが ゼロならば、ポインターもゼロである。SMBデータストリームにさらなるデータは存在しない。 もしも、カウンターがゼロでない場合、ポインターもゼロではない。ポインターの直後には また、コンテナーのサブ構造体の配列が続くカウンターが来る。カウンターは最後のサブ構造体 の後に3回目のカウンターが来る。
msrpcパケットヘッダー中のコマンド番号
0x00
0x02
0x0B
0x0C
num of sub-authorities in domain SID
SID revision number
num of sub-authorities in domain SID
6 bytes for domain SID - Identifier Authority.
domain SID sub-authorities
注意:ドメイン SID はどこかで文書化されている。
length of unicode string
max length of unicode string
4 - undocumented.
length of unicode string
null-terminated string of unicode characters.
padding to get unicode string 4-byte aligned with the start of the SMB header.
max length of unicode string
0 - undocumented
length of unicode string
string of uncode characters
0x18 - length (in bytes) including the length field.
0 - root directory (pointer)
0 - object name (pointer)
0 - attributes (undocumented)
0 - security descriptior (pointer)
0 - security quality of service
5 - SID type
0 - undocumented
domain SID unicode string header
domain SID unicode string
注意: 文字列の長さを指定示すために、どちらを使うかについて、 UNICODE文字列ヘッダーとUNICODE文字列自身との間で競合がある。これは解決されねばならないだろう。
注意: SIDタイプは、たとえば別名、既定のグループ等などを指示する。これは どこかで文書化されている。
5 - well-known SID. 1 - user SID (see ShowACLs)
5 - undocumented
domain RID
0 - domain index out of above reference domains
注意: ログオンサーバー名は、2つの'\'で始まり、大文字である。
注意: アカウント名は、LSAリクエストチャレンジからのログオンクライアント名で、最後に$があり、大文字である。
undocumented buffer pointer
logon server unicode string
account name unicode string
sec_chan - security channel type
logon client machine unicode string
注意: ログオンサーバー名は2つの'\'で始まり、大文字である。
undocumented buffer pointer
logon server unicode string
undocumented buffer pointer
logon client machine unicode string
注意: 要求中にこの構造体が使われた時にはいつでも、引き続く認証検査で使われるため、 受け取ったクライアントで計算された認証情報のコピーを取る必要がある。仮定された意図は、認証された 要求/応答の痕跡を維持することである。
client and server names
???? padding, for 4-byte alignment with SMB header.
pointer to client credentials.
client-calculated credentials + client time
注意: 要求中にこの構造体が使われた時にはいつでも、引き続く認証検査で使われるため、 受け取ったクライアントで計算された認証情報のコピーを取る必要がある。仮定された意図は、認証された 要求/応答の痕跡を維持することである。
logon account info
client-calculated credentials + client time
ptr_id_info_1
domain name unicode header
param control
logon ID
user name unicode header
workgroup name unicode header
arc4 LM OWF Password
arc4 NT OWF Password
domain name unicode string
user name unicode string
workstation name unicode string
注意: たぶん、戻される認証情報は、おそらく認証チェインが脆弱でない事を、サーバーが検査するためのものである。
client identification/authentication info
pointer to return credentials.
return credentials - ignored.
logon level
switch value
switch (switch_value)
case 1:
{
ID_INFO_1 id_info_1;
}
undocumented buffer pointer.
num referenced domains?
undocumented domain name buffer pointer.
32 - max number of entries
4 - num referenced domains?
domain name unicode string header
referenced domain unicode string headers
domain name unicode string
referenced domain SIDs
??? padding to get 4-byte alignment with start of SMB header
domain name string length * 2
domain name string length * 2
undocumented domain name string buffer pointer
undocumented domain SID string buffer pointer
domain name (unicode string)
domain SID
注意: 16バイトのユーザーセッションキーが何のためかを知ることはすてきであろう。
logon time
logoff time
kickoff time
password last set time
password can change time
password must change time
username unicode string header
user's full name unicode string header
logon script unicode string header
profile path unicode string header
home directory unicode string header
home directory drive unicode string header
logon count
bad password count
User ID
Group ID
num groups
undocumented buffer pointer to groups.
user flags
user session key
logon server unicode string header
logon domain unicode string header
undocumented logon domain id pointer
40 undocumented padding bytes. future expansion?
0 - num_other_sids?
NULL - undocumented pointer to other domain SIDs.
username unicode string
user's full name unicode string
logon script unicode string
profile path unicode string
home directory unicode string
home directory drive unicode string
num groups
group info
logon server unicode string
logon domain unicode string
domain SID
other domain SIDs?
注意: cifsrap2.txtの section5, page 10を参照。
| 0 for shi1_type indicates a Disk. |
| 1 for shi1_type indicates a Print Queue. |
| 2 for shi1_type indicates a Device. |
| 3 for shi1_type indicates an IPC pipe. |
| 0x8000 0000 (top bit set in shi1_type) indicates a hidden share. |
shi1_netname - pointer to net name
shi1_type - type of share. 0 - undocumented.
shi1_remark - pointer to comment.
shi1_netname - unicode string of net name
shi1_remark - unicode string of comment.
share container with 0 entries:
0 - EntriesRead
0 - Buffer
share container with > 0 entries:
EntriesRead
non-zero - Buffer
EntriesRead
share entry pointers
share entry strings
padding to get unicode string 4-byte aligned with start of the SMB header.
EntriesRead
0 - padding
注意: cifs6.txt section 6.4を参照 - その中で説明されているフィールドはここで補足する。 例えば、以下でリストされたタイプは6.4.1で説明されているfServerTypeと同じである。
0x00000001 All workstations
0x00000002 All servers
0x00000004 Any server running with SQL server
0x00000008 Primary domain controller
0x00000010 Backup domain controller
0x00000020 Server running the timesource service
0x00000040 Apple File Protocol servers
0x00000080 Novell servers
0x00000100 Domain Member
0x00000200 Server sharing print queue
0x00000400 Server running dialin service.
0x00000800 Xenix server
0x00001000 NT server
0x00002000 Server running Windows for
0x00008000 Windows NT non DC server
0x00010000 Server that can run the browser service
0x00020000 Backup browser server
0x00040000 Master browser server
0x00080000 Domain Master Browser server
0x40000000 Enumerate only entries marked "local"
0x80000000 Enumerate Domains. The pszServer and pszDomain parameters must be NULL.
500 - platform_id
pointer to name
5 - major version
4 - minor version
type (SV_TYPE_... bit field)
pointer to comment
sv101_name - unicode string of server name
sv_101_comment - unicode string of server comment.
padding to get unicode string 4-byte aligned with start of the SMB header.
名前付きパイプ上のSMBトランザクションの詳細はcifs6.txtを参照。
MSRPCは\PIPE\という名前のSMBトランザクションパイプ上で行われる。
たとえば、パイプ名\PIPE\srvsvcでSMBopenXを送信することで、
まず初めに16ビットのファイルハンドルを得ておかねばならない。そうすると次に
SMB Transを実行でき、処理が終了したら、ファイルハンドル上でSMBCloseを送る必要がある。
Trans Requestは(これについては知られていないが)1つのUINT16ではなく2つのUINT16 セットアップパラメーターと、MSRPCヘッダーを含むために十分なUINT8データパラメーターと MSRPCデータを送る必要がある。最初のUINT16セットアップパラメーターはRPCを指定するために 0x0026か、Set Named Pipe Handle Stateを指示するために、0x0001のどちらかでなければ ならない。2番目のUINT16パラメーターは、上記で得られた、パイプ用のファイルハンドルで なければならない。
Trans Request中の、0x0026 (RPC pipe)であるAPIコマンド用のデータセクションは、RPCデータが 後に来るRPCヘッダーである。0x0001のAPIコマンド(Set Named Pipe Handle state)のための データセクションは、2バイトである。その2バイトの中に現れるものは、0x00 0x43のみである。 The Data section for an API Command of 0x0026 (RPC pipe) in the Trans Request is the RPC Header, followed by the RPC Data. The Data section for an API Command of 0x0001 (Set Named Pipe Handle state) is two bytes. The only value seen for these two bytes is 0x00 0x43.
MSRPC ResponseはMSPRCヘッダー、MSRPCデータとMSRPCフッター(訳注:tail)がある、標準 SMB Transレスポンス内で、レスポンスデータとして送信される。
Trans Requestが少なくとも2バイト境界(おそらく4バイト)に配置される必要があるだろうと いうことは、推測される。これは、SMBに対して標準的な慣習である。また、MSRPCヘッダーと MSRPCデータの間での4バイト単位境界を含む、MSRPCヘッダーの4バイト単位境界とは独立している。 It is suspected that the Trans Requests will need to be at least 2-byte aligned (probably 4-byte). This is standard practice for SMBs. It is also independent of the observed 4-byte alignments with the start of the MSRPC header, including the 4-byte alignment between the MSRPC header and the MSRPC data.
最初に、IPC$共有に対してSMBtconX接続が行われる。コネクションは、平文ではなく、 暗号化したパスワードを使って行わなければならない。次に、SMBOpenXがパイプ上で行われる。 次に、Set Named Pipe Handle Stateが、APCコマンドを受け取れるようにパイプがなった後に 送られる必要がある。最後に、SMBcloseが送られる。
解決されること:
lkcl/01nov97において、RPCパイプのためのNULL文字で終端している\PIPE\名の後に2バイトが 存在するように見える。今のところ分かっている値は以下の通り:
initial SMBopenX request: RPC API command 0x26 params:
"\\PIPE\\lsarpc" 0x65 0x63; 0x72 0x70; 0x44 0x65;
"\\PIPE\\srvsvc" 0x73 0x76; 0x4E 0x00; 0x5C 0x43;
[Duncan Stansfieldによる作業を受け取った後、この節は書き直される予定]
興味深い注意:もしも、パックされたデータを0x0100 0000と設定した場合、 すべての4バイトと2バイトワードの順番は逆転する!
NTLSAとNETLOGON名前付きパイプのおのおのの開始は、以下で始まる:
reply same as request (0x05)
reply same as request (0x00)
one of the MSRPC_Type enums
reply same as request (0x00 for Bind, 0x03 for Request)
reply same as request (0x00000010)
the length of the data section of the SMB trans packet
call identifier. (e.g. 0x00149594)
the remainder of the packet depending on the "type"
インタフェースには番号が付けられている。同じパイプ名srvsvc上で1つより多い インタフェースを使う場面にはまだ出会ったことがない。
abstract (0x4B324FC8, 0x01D31670, 0x475A7812, 0x88E16EBF, 0x00000003) transfer (0x8A885D04, 0x11C91CEB, 0x0008E89F, 0x6048102B, 0x00000002)
"タイプ"がレスポンスヘッダーのBINDであった場合、ヘッダーの後のパケットの残りの "タイプ"は、BindAckであるべきである。
maximum transmission fragment size (0x1630)
max receive fragment size (0x1630)
associated group id (0x0)
the number of elements (0x1)
presentation context identifier (0x0)
the number of syntaxes (has always been 1?)(0x1)
4-byte alignment padding, against SMB header
num and vers. of interface client is using
num and vers. of interface to use for replies
length of the string including null terminator
the string above in single byte, null terminated form
リプライパケット中でヘッダーの後に配置されるレスポンス
same as request
same as request
zero
the address string, as described earlier
4-byte alignment padding, against SMB header
the number of results (0x01)
4-byte alignment padding, against SMB header
result (0x00 = accept)
reason (0x00 = no reason specified)
the transfer syntax from the request
すべての他のパケットのためのヘッダーの後のパケットの残り
the size of the stub data in bytes
presentation context identifier (0x0)
operation number (0x15)
a packet dependent on the pipe name (probably the interface) and the op number)
RPCバインドは、あるRPCパイプ(例えば\PIPE\lsarpc)と"transfer syntax"(RPC_Iface 構造体を参照)を関連づける手続きである。これを行う目的は不明である。
Note: The RPC_ResBind SMB Transact request is sent with two uint16 setup parameters. The first is 0x0026; the second is the file handle returned by the SMBopenX Transact response.
Note: The RPC_ResBind members maxtsize, maxrsize and assocgid are the same in the response as the same members in the RPC_ReqBind. The RPC_ResBind member transfersyntax is the same in the response as the
Note: The RPC_ResBind response member secondaddr contains the name of what is presumed to be the service behind the RPC pipe. The mapping identified so far is:
RPC_ResBind response:
"\\PIPE\\ntsvcs"
"\\PIPE\\lsass"
"\\PIPE\\lsass"
"\\PIPE\\wksvcs"
"\\PIPE\\NETLOGON"
注意: バインド要求とバインド承認の両方におけるRPC_Packet fraglength メンバーは、RPC_Packet headerを含めて、RPCデータ全体の長さを含まなければならない。
Request:
| RPC_Packet |
| RPC_ReqBind |
Response:
| RPC_Packet |
| RPC_ResBind |
このパイプ上で取られる動作の順番は以下の通り:
| IPC$ share (SMBtconX)への接続を確立する。暗号化パスワードを使用。 |
| "\\PIPE\\lsarpc"という名前でRPCパイプを開く。ファイルハンドルを格納する。 |
| ファイルハンドルを使い、Named Pipe Handle stateを0x4300に設定する。 |
| LSA Open Policy要求を送る。ポリシーハンドルを格納する。 |
| ポリシーハンドルを使い、LSA Query Info Policy要求などを送る。 |
| ポリシーハンドルを使い、LSA Closeを送る。 |
| IPC$共有をクローズする。 |
このパイプの定義のための、問い合わせの識別子は以下の通り:
0x2c
0x07
0x0d
0xff
0xfe
0xfd
0x00
注意: ポリシーハンドルはどんな好みのものでもあり得る。
buffer pointer
server name - unicode string starting with two '\'s
object attributes
1 - desired access
注意: レスポンス中のinfo classはリクエスト中のものと同じである必要がある。
注意: レスポンス中のnum_entriesはリクエスト中のnum_entriesと同じでなければならない。
LSA policy handle
num_entries
undocumented domain SID buffer pointer
undocumented domain name buffer pointer
DOM_SID[num_entries] domain SIDs to be looked up.
completely undocumented 16 bytes.
注意: レスポンス中のnum_entriesはリクエスト中のnum_entriesと同じでなければならない。
LSA policy handle
num_entries
num_entries
undocumented domain SID buffer pointer
undocumented domain name buffer pointer
names to be looked up.
undocumented bytes - falsely translated SID structure?
このパイプ上の動作の順番は以下の通り:
| IPC$ 共有 (SMBtconX)に対して接続を確立する。暗号化パスワードを使用。 |
| "\\PIPE\\NETLOGON"という名前でRPCパイプを開く。ファイルハンドルを格納する。 |
| ファイルハンドルを使い、Named Pipe Handle stateを0x4300に設定する。 |
| クライアント用のチャレンジデータを作成する。LSA Request Challengeを送信する。Server Challengeを格納する。 |
| セッションキーを計算する。LSA Auth 2 Challengeを送信する。Auth2 Challengeを格納する。 |
| Client Credsを計算して検証する。LSA Srv PW Setを送信する。Server Credsを計算、検証する。 |
| Client Credsを計算して検証する。LSA Srv Logonを送信する。Server Credsを計算、検証する。 |
| Client Credsを計算して検証する。LSA Srv Logoffを送信する。Server Credsを計算、検証する。 |
| IPC$共有をクローズする。 |
このパイプの定義のための、問い合わせ識別子は以下の通り
0x04
0x06
0x02
0x03
0x0f
0x0e
注意: ログオンサーバー名は2つの'\'で始まり、大文字である。
注意: ログオンクライアントはマシンであり、ユーザーではない。
注意: チャレンジが発行されたものに対する最初のLanManager パスワードハッシュは、(小文字の)マシン名それ自身である。あとで、これを変更するであろう 呼び出し(LSA Server Password Set)が発行されるであろう。これらの呼び出しを抑制すると、 常時同じパスワードで扱うことが出来るようになる(すなわち、小文字でのマシン名のLM#)。
undocumented buffer pointer
logon server unicode string
logon client unicode string
client challenge
注意: リクエストとレスポンスの間で、クライアントの認証情報を計算し、 クライアントが計算した認証情報と比較する(この手続きは以前に受け取ったクライアントの 認証情報を使う)。
注意: レスポンス中のneg_flagsはリクエスト中のものと同じである。
注意: そのあとの認証パケット中で使われるという理由で、ここで受け取った クライアントが計算した認証情報のコピーを取る必要がある。
client identification info
client-calculated credentials
padding to 4-byte align with start of SMB header.
neg_flags - negotiated flags (usual value is 0x0000 01ff)
注意: 新しいパスワードはキーを生成するために古いパスワードを使って DES暗号化を使うことが推測される。
注意: リクエストとレスポンスの間で、クライアント認証情報を計算し、 クライアントが計算した認証情報と比較する(この手続きは以前に受け取ったクライアントの 認証情報を使う)。
注意: サーバーの認証情報はクライアントが計算した認証情報と、クライアント時間+1秒から構築される。
注意: そのあとの認証パケット中で使われるという理由で、ここで受け取った クライアントが計算した認証情報のコピーを取る必要がある。
注意: valid_user は、もしもユーザー名とパスワードハッシュが、要求されたドメインに対して 有効ならば、Trueである。
undocumented buffer pointer
server credentials. server time stamp appears to be ignored.
if (valid_user)
{
UINT16 3 - switch value indicating USER_INFO structure.
VOID* non-zero - pointer to USER_INFO structure
USER_INFO user logon information
UINT32 1 - Authoritative response; 0 - Non-Auth?
return 0 - indicates success
}
else
{
UINT16 0 - switch value. value to indicate no user presumed.
VOID* 0x0000 0000 - indicates no USER_INFO structure.
UINT32 1 - Authoritative response; 0 - Non-Auth?
return 0xC000 0064 - NT_STATUS_NO_SUCH_USER.
}
注意: mailslotsはレスポンスmailslotを含み、それは送信されるべきレスポンスである。 ターゲットのNetBIOS名はREQUEST_NAME<20>であり、ここで、REQUEST_NAME はリクエストを送信したマシンの名前である。
注意: レスポンス中のNTversion, LMNTtoken, LM20tokenはリクエスト中で与えられたものと同じである。
0x0007 - Query for PDC
machine name
response mailslot
padding to 2-byte align with start of mailslot.
machine name
NTversion
LMNTtoken
LM20token
注意: レスポンス中のマシン名は先頭に2つの'\'が付く。
注意: レスポンス中のNTversion, LMNTtoken, LM20tokenはリクエスト中のものと同じである。
注意: レスポンス中のユーザー名はおそらくリクエスト中のものと同じである。
0x0012 - SAM Logon
request count
machine name
user name
response mailslot
alloweable account
domain SID size
domain SID, of sid_size bytes.
???? padding to 4? 2? -byte align with start of mailslot.
NTversion
LMNTtoken
LM20token
このパイプのための定義で、クエリの識別は以下の通り:
0x0f
0x15
注意: レスポンス中のスイッチの値と共有レベルはリクエスト中のものとおそらく同じである。
注意: cifsrap2.txt (section 5)はここで、限定的に手助けとなるかもしれない。
pointer (to server name?)
server name
padding to get unicode string 4-byte aligned with the start of the SMB header.
share level
switch value
pointer to SHARE_INFO_1_CTR
share info with 0 entries
preferred maximum length (0xffff ffff)
Intel byte ordered addition of corresponding 4 byte words in arrays A1 and A2
DES ECB encryption of 8 byte data D using 7 byte key K
Lan man hash
NT hash
md4(machine_password) == md4(lsadump $machine.acc) == pwdump(machine$) (initially) == md4(lmowf(unicode(machine)))
ARC4 encryption of data D of length Ld with key K of length Lk
subset of v from bytes m to n, optionally padded with zeroes to length l
E(K[7..7,7],E(K[0..6],D)) computes a credential
4 byte current time
8 byte client and server challenges Rc,Rs: 8 byte client and server credentials
C->S ReqChal,Cc S->C Cs
C & S compute session key Ks = E(PW[9..15],E(PW[0..6],Add(Cc,Cs)))
C: Rc = Cred(Ks,Cc) C->S Authenticate,Rc S: Rs = Cred(Ks,Cs), assert(Rc == Cred(Ks,Cc)) S->C Rs C: assert(Rs == Cred(Ks,Cs))
ドメインへの参加において、クライアントはオプションとしてそのパスワードを変更しようと し、ドメインコントローラーはレジストリの設定に依存して、その更新を抑制するかもしれない。 これは以降毎週毎に起きるであろう。
C: Tc = Time(), Rc' = Cred(Ks,Rc+Tc) C->S ServerPasswordSet,Rc',Tc,arc4(Ks[0..7,16],lmowf(randompassword()) C: Rc = Cred(Ks,Rc+Tc+1) S: assert(Rc' == Cred(Ks,Rc+Tc)), Ts = Time() S: Rs' = Cred(Ks,Rs+Tc+1) S->C Rs',Ts C: assert(Rs' == Cred(Ks,Rs+Tc+1)) S: Rs = Rs'
ユーザー: パスワードがPのユーザーUはドメインにログオンしようとする(ワークステーションと ドメインのような付随的なデータは省略される)
C: Tc = Time(), Rc' = Cred(Ks,Rc+Tc) C->S NetLogonSamLogon,Rc',Tc,U,arc4(Ks[0..7,16],16,ntowf(P),16), arc4(Ks[0..7,16],16,lmowf(P),16) S: assert(Rc' == Cred(Ks,Rc+Tc)) assert(passwords match those in SAM) S: Ts = Time()
S->C Cred(Ks,Cred(Ks,Rc+Tc+1)),userinfo(logon script,UID,SIDs,etc) C: assert(Rs == Cred(Ks,Cred(Rc+Tc+1)) C: Rc = Cred(Ks,Rc+Tc+1)
最初のドメインへの参加において、マシンパスワードがよく知られた値であるように、 セッションキーは、ネットワーク上で盗聴している誰にでも、計算することが出来た。 マシンがリブートするまで、パスワードと同等の、NTとLMの一方向関数による暗号化 パスワードを、このセッションキーは使うであろう。このマシンが2回目にリブートする 前にログインする任意のユーザーは、パスワードと同等のものがばれてしまうであろう。 もちろん、新しいマシンのパスワードはとにかくこの時点でばれてしまう。
ログオンスクリプト、プロファイルパスと、SIDのような戻り情報は、TCPチェックサム以外の 何かによって保護されるように見えない。
サーバーのタイムスタンプは無視されるように見える。
クライアントは、それに対する使用法が分からない、SamLogonリクエスト中で ReturnAuthenticatorを送る。しかし、その時間はサーバーによって戻されるタイムスタンプ として使われる。
パスワードのOMFは解読できる暗号でネットワーク上に送信すべきでない。SAM中のowf値を 使う同じ機能でサーバーが計算するARC4(Ks,md4(owf))を使って送るべきである。
SIDとRIDはどこかで詳細に説明がある。
SIDはNTセキュリティID(DOM_SID構造参照)である。これらは以下の形式を取る:
| revision-NN-SubAuth1-SubAuth2-SubAuth3... |
| revision-0xNNNNNNNNNNNN-SubAuth1-SubAuth2-SubAuth3... |
現在、SIDのリビジョンは1である。 Sub-Authoritiesは相対ID(RID)として知られている。
S-1-0-0
S-1-1-0
S-1-2-0
S-1-3-0
S-1-3-1
S-1-3-2
S-1-3-3
S-1-4
RIDはsub-authorityであり、SIDの一部か、グループRIDの場合は、DOM_GID構造の一部であり、 USER_INFO_1構造ではLSA SAMログオンレスポンスの中である。 A RID is a sub-authority value, as part of either a SID, or in the case of Group RIDs, part of the DOM_GID structure, in the USER_INFO_1 structure, in the LSA SAM Logon response.