それが簡単なため、最初にユーザーレベルのセキュリティを説明する。ユーザーレベルの セキュリティでは、クライアントはプロトコルネゴシエーションを伴って、直接 セッションセットアップ要求を送信する。この要求はユーザー名とパスワードを提供 する。サーバーはそのユーザー名/パスワードペアを受け取るか拒否するかのどちらか を行う。この段階で、サーバーはクライアントが結局接続しようと試みる共有が 何であるかを知るすべはなく、そのため、許可/拒否 について、以下の2つ以外をベースと出来ない:

もしもサーバーがユーザー名/パスワードペア認証を許可するならば、クライアントは、 その先パスワード指定なしで(tree connectionを使って) 共有をマウントできることを仮定する。クライアントは、すべてのアクセス権限が 最初のsession setup中で指定したユーザー名/パスワード認証 セットであることを仮定する。

複数のsession setup要求をクライアントが送信することも 可能である。サーバーが返信するとき、そのユーザー名/パスワードペアのための、 認証タグとして使うために、uidを送る。クライアントは この方法で複数の認証コンテキストを操作することが可能である(このことを行う アプリケーションの例としてはWinDDがある)。

Windowsネットワークユーザーアカウント名は大文字小文字に依存しない。すなわち、 アカウント名中の大文字小文字はすべて同一視されると言うことである。また、 大文字小文字の状態は保存されるが、大文字小文字の状態は関係ないということ である。Windows NT 3.10より前のWindowsとLanManagerシステムは、大文字小文字 の状態を保存する必要がない、大文字小文字を無視するパスワードを使っていた。 すべてのWindows NT ファミリシステムはパスワードについて、大文字小文字を保 存し、それを意識するように取り扱う。

共有レベルのセキュリティ中では、クライアント自身の認証はおのおのの共有毎に 分離している。クライアントはおのおのの tree connection要求(共有マウント) と共にパスワードを送るが、この操作で明示的にユーザー名を送らない。クライアント は、おのおのの共有にパスワードが関連づけられ、ユーザーから独立していることを 期待する。これは、Sambaは、ユーザー名がSMBサーバーに明示的に送られないために、 クライアントが使いたいとしているユーザー名をSambaが考えなければならないこと を意味する。たとえばNTのような、いくつかの商用SMBサーバーは共有レベルの セキュリティ中に直接共有とパスワードを関連づけるが、Sambaはいつでも、 共有/パスワードペアではなく、認証に使ったユーザー名/パスワードペアを使う UNIX認証スキームを使う。

Microsoftネットワーキングとの類似点を理解するために、パスワードあり/なし でリードオンリまたはフルアクセスできる共有フォルダーを作成できる、Microsoft Windows 9x/Meについて考えてみる。

多くのクライアントは、サーバーが共有レベルのセキュリティであったとしても、 session setup要求を送る。それらは通常有効なユーザー名を送るがパスワードは 送らない。Sambaは有効なユーザー名リスト中にこのユーザー名を記憶する。クライアント がtree connection要求を次に発行するとき、接続しようとする共有名の名前 (ホームディレクトリに有用)をこのリストに追加もし、smb.confファイル中の userパラメーター中にリストされているユーザーもである。 次にパスワードが、それらの可能なユーザー名に対して順番にチェックされる。 もしも一致したものが見つかれば、クライアントはそのユーザーとして認証される。

使用可能なユーザー名のリストが提供されていない場合、Sambaは、標準のアカウント データベースから、そのユーザーに対して提供されるパスワードとユーザーアカウントを UNIXのシステムコールを使って探し出すことを行う。システムがネームサービススイッチ (NSS)機能を持っていない場合、そのような検索は/etc/passwd データベースを対象として行う。NSSが有効なシステムの場合、検索は、 nsswitch.confファイル中で指定されたライブラリを通じて 行う。ライブラリを指定するそのファイル中のエントリは以下の通り:

passwd: files nis ldap
shadow: files nis ldap
group: files nis ldap

以下の例(実際に使われるようなものではないが)では、検索は、 /etc/passwdと /etc/groupに対して 行われ、見つからなければ NISでチェックし、次にLDAPでチェックする。

ドメインセキュリティは、すべてのユーザーとグループアカウントを、中央の共有されている アカウントリポジトリに保存するメカニズムを提供する。中央のアカウントリポジトリは ドメイン(セキュリティ)コントローラー間で共有される。ドメインコントローラーとして振る舞う サーバーはドメインに対するセキュリティコンテキストに参加するすべてのマシンに、認証と 確認サービスを提供する。プライマリドメインコントローラー(PDC)はセキュリティアカウント データベースの完全性を管理するための責任を負うサーバーである。バックアップドメイン コントローラー(BDC)はドメインログオンと認証サービスのみを提供する。通常、BDCはPDCが 行うよりもより反応性がよいネットワークログオン要求を提供する。

Sambaがsecurity = domainモードで動作中の時、 Sambaサーバーはドメインセキュリティ信頼アカウント(マシンアカウント)を持ち、ドメイン コントローラーに対してすべての認証要求をパススルーする。別の言い方をすると、この設定は、 実際、それがドメインコントローラーとして振る舞う場合にも、Sambaサーバーをドメインメンバー サーバーにする。ドメインセキュリティに参加するすべてのマシンはセキュリティデータベース 中にマシンアカウントを持たなければならない。

ドメインセキュリティ環境ないで、セキュリティアーキテクチャの基盤は、ユーザーレベルの セキュリティを使う。ドメインメンバーであるマシンは開始時に認証を行わなければならない。 アカウントデータベース内にあるアカウントエントリの一部であるマシンアカウントは、 その名前がマシンのNetBIOS名であり、パスワードはランダムに生成され、ドメインコントローラー と他のマシンの両方に知られている。もしもマシンアカウントがセットアップ中に認証 されなければ、ユーザーは、それが認証できないため、そのマシンを使ってドメインにログオン できない。マシンアカウントはマシン信頼アカウントとして参照される。

ドメインメンバーの設定には以下の3つのパターンがある:

それぞれについて別の節で解説する。まずはじめに、もっとも関心のある基本的なDMSの設定について 説明する。

root# smbpasswd -j DOMAIN_NAME -r PDC_NAME \
	 -U Administrator%password

root# net rpc join -U Administrator%password

Samba-2.2とSamba-3の両方は、NT4スタイルのRPCベースのセキュリティを使って Active Directoryドメインに参加することが出来る。これは、ドメインがネイティブ モードで動作しているときに可能である。ネイティブモードのActive Directory は完全にNT4スタイルのドメインメンバーを許可する。これは世間一般の考えに反して である。

もしも、Active DirectoryをSamba-3と一緒に使っているとき、ネイティブなAD メンバーとしてジョインできる。なぜそれを望むか?NT互換の認証プロトコルの使用 をセキュリティポリが禁止するかもしれない。Windows2000とそれ以降のすべての マシンはKerberosを使用している。この場合、NT4スタイルのドメインとしての SambaはNT互換の認証データを引き続き要求する。ADメンバーモード中のSambaは、 Kerberosチケットを受け取ることが出来る。

Microsoft WindowsのActive Directoryサービス(ADS)を使うサイトは、以下の 用語の重要性に気づくべきである: native mode と mixed modeの ADS操作。 The term realmという単語はKerberosベースのセキュリティアーキテクチャ (Microsoft ADSによって使われるような)を説明するのに使われる。

サーバー席モードはドメインメンバーサーバーとして振る舞うのが出来ない場合に残されている ものである。この機能を使わないことを強く推奨する。サーバーセキュリティモードは 以下のような多数の欠点がある:

サーバーセキュリティモード中で、Sambaサーバーはクライアントに、ユーザーレベルセキュリティ であることを報告する。クライアントは次に以前に説明したようにsession setupを行う。 Sambaサーバーはユーザー名/パスワードペアをクライアントから得、クライアントから得た ユーザー名/パスワードペアと正確に同じものを送って password serverにログインしようとする。もしもサーバーが ユーザーレベルのセキュリティで動作していて、パスワードを受け入れるならば、Samba はクライアントからの接続を許可する。このパラメーターは password serverとしてSambaサーバーを、別のSMBサーバーを使う ことができるようになる。

どのセキュリティレベルであるかとクライアントに告げるとき、これらすべての開始時に もしも暗号化をサポートしているのであrばそのこともクライアントに告げる。もしも そうであれば、クライアントに対して乱数を使った暗号化キーを送信する。クライアント は暗号化形式ですべてのパスワードを送る。Sambaは既定値でこのタイプの暗号化を サポートする。

パラメーターsecurity = serverは user modeで動いていることをSambaがクライアントに報告する ことを意味するが、実際には別のユーザーモードサーバーに対してすべての認証要求を渡す。 これは、真の認証サーバーを差す追加のpassword server パラメーターを必要とする。真の認証サーバーは別のSambaサーバーでも、Windows NT サーバーでもよく、後者は標準で暗号化パスワードをサポートしている。

ある人たちにとって、Sambaのセキュリティモードの性質は明白であるが、 それでも完全に間違っている(訳注:意味取れない)。 security = serverはSambaがサーバーとして 動くと言うことを意味していることを仮定している。が、違う。この設定は、 Sambaが、別のSmBサーバーがユーザー認証サーバーだけの提供元として使うことを 試みることを意味している。

Sambaはセキュリティモードが選択されたとしてもサーバーである。Sambaが ドメインセキュリティコンテキストの外で使われた場合、既定値にセキュリティ モードをしておくのが最適である。Samba-3の既定値では、ユーザーモードの セキュリティを使う。

smb.conf パラメーター security = domainは 実際にSambaをドメインコントローラーとして振る舞わさせるのではない。この設定は Sambaがドメインメンバーになることを期待することを意味する。より詳細については PDCとしてのSambaを参照のこと。

想像してみよう!So many others do. But whatever you do, security = userはSambaをドメインメンバー として振る舞わせることを考えてはいけない。保証期限が切れる前に製造者の マニュアルを読みなさい。より詳細については、 ドメインメンバーシップを参照のこと。

“ なぜ、server_validate()は単に、パスワードサーバーに対する接続を再接続しないで あきらめるのか?私はSMBプロトコルに詳しくはないが、たぶん、クラスターサーバー プロセスはそのクライアントワークステーションの方に、パスワードサーバーから 渡されたセッションキーを渡し、それはクライアントから送信されたパスワード ハッシュが、セッションキーが異なるそのあとの接続で動作しないことを意味する。 (訳注:ちょっと不安)そのため、server_validate()は中断しなければならない。 ”

本当に。それは、なぜ security = server が全くひどいハックである理由である。認証をパススルーすることが分かっている、 security = serverモードである、 security = domainを使ってほしい。

“ DOMAINに入ろうとしたとき、イベントログに tried credentials DOMAIN/username; effective credentials SERVER/usernameが表示された。 ”

通常これはSambaサーバーがドメインコントローラーとして設定される前にユーザーかマシン アカウントが作成されたことによるものである。サーバーがドメインコントローラーになる まえに作成されたアカウントは、ローカルのアカウントであり、 SERVERドメイン中のメンバーとして見えるものとしてに認証され、Windows 2000とそれ 以降の中のローカルユーザーアカウントとほとんど同じである。Sambaサーバーがドメイン コントローラーになったとに作成されたアカウントは、 ドメイン アカウントであり、DOMAINメンバーのメンバーとして認証される。

これは、pdbedit -L -v usernameコマンドをを発行することによって 確かめられる。もしも、これがDOMAINという結果を出したならば、アカウントはドメイン アカウントであり、もしもSERVERであれば、そのアカウントはローカルアカウントである。

これを解決する最も簡単な方法は、アカウントを削除し再作成することである。しかしながら、 この方法は、ユーザープロファイルの確率に問題を引き起こすかもしれない。 pdbedit -u username -I DOMAINコマンドを使うことも出来る。 ドメインに一致するためにユーザーSIDとプライマリグループSIDを変更する必要がある かもしれない。