Chapter 3. サーバタイプとセキュリティモード

Andrew Tridgell

Samba Team

Jelmer R. Vernooij

The Samba Team

John H. Terpstra

Samba Team

Table of Contents

機能と利便性
サーバタイプ
Sambaセキュリティモード
ユーザレベルのセキュリティ
共有レベルのセキュリティ
ドメインセキュリティモード(ユーザレベルのセキュリティ)
ADS セキュリティモード(ユーザレベルのセキュリティ)
サーバセキュリティ(ユーザレベルのセキュリティ)
パスワードの検査
共通のエラー
何がSambaをサーバにするか?
何がSambaをドメインコントローラにするか?
何がSambaをドメインメンバにするか?
常時パスワードサーバへの接続不可
スタンドアロンサーバはドメインコントローラに変換された が、ユーザのアカウントが動作しない

この章では、Sambaで設定可能なサーバのタイプに関する情報を提供する。Sambaへのマイグレーションか、 単に使いたいと思っているMicrosoft ネットワーク管理者は、Microsoft Windows管理者にわかりやすい 言葉で、Sambaの文脈においてその意味を知りたいはずである。これは、サーバそれ自身をどのように 設定するかという詳細を得る前に重要なセキュリティモードの機能を定義すると同様に重要であること を意味する。

この章では、Microsoftサーバとクライアントにどのように関連することと、Sambaのセキュリティモードが できることについての概要を提供する。

しばしば聞かれる質問は、なぜSambaを使うのかである。ほとんどの章は、機能と利便性 に注目した節を含んでいる。情報がこの質問に答える手助けを提供することを希望している。しかし、 我々は公正で合理的であることを望むので、すべての機能がSambaに対して好ましいとは限らないことを 警告する。利便性は競合他社の方にあるかもしれない。

機能と利便性

2人の人が汚れた道を歩いていたとき、1人が突然小さな赤い石を蹴飛ばした。それは 彼のつま先を傷つけ、サンダルに突き刺さった。彼は石を取り去り、苦しみと激怒 のあまりののしった。もう1人は石を見て、これはガーネットだ。これを 貴重な宝石に変えられる。そして、いつの日かこれはプリンセスを非常に幸福に するだろう!

この物語の教訓:2人の人は同じ石に対して2つの非常に異なった観点を持っていた。それと 同じかどうかにかかわらず、Sambaはその石と似ている。正しく扱えばとても優れた宝物に なるが、それに関わる時間を持つことが出来ないことを強いられるならば、それは非常に 不愉快なものになる。

SambaはUNIXサーバとMicrosoft Windows 3.xクライアントのための相互運用性を提供する ためのプロジェクトとして開始された。それは、ささやかなスタートから大きく成長し、 いまや巨大システムに適合する機能を提供するようになった。しかし若干の問題点も ある。このような節ではその両方について触れる。

そのため、この章で説明されている機能の利点は何であろうか?

  • Samba-3はMicrosoft Windows NT4 ドメインコントローラを置き換えられる。

  • Samba-3はネイティブのMicrosoft Active Directoryドメインと同じように NT4スタイルのMicrosoft Windows NT4スタイルのドメインとのすぐれた相 互運用性を提供する。

  • Samba-3は完全なNT4スタイルのドメイン間の信頼関係を許可する。

  • SambaはMicrosoft Windows NT4ドメインコントローラで出来るよりも より柔軟性のある認証機能を許可するセキュリティモードを持っている。

  • Samba-3は複数の同時アクセス可能なアカウントデータベースバックエンドを 使える(暗号化パスワードはWindowsネットワーキングのために固有となる形 式でアカウントデータベース中に格納される)。

  • アカウントデータベースバックエンドは複数の方法で複製され配布される。 これは、Samba-3がMicrosoft Windows NT4よりもより優れた柔軟性を与え、 多くの場合、Microsoft Windows 200xのActive Directory ドメインよりも かなり便利なユーティリティとなる。

サーバタイプ

Microsoftネットワークの管理者はしばしば3つの異なったタイプのサーバを参照する:

  • ドメインコントローラ

    • Primary Domain Controller (PDC)

    • Backup Domain Controller (BDC)

    • ADS Domain Controller

  • ドメインメンバサーバ

    • Active Directory Domain Server

    • NT4 Style Domain Domain Server

  • スタンドアロンサーバ

ドメイン制御を扱っている節(ドメイン制御), バックアップのドメイン制御(バックアップドメイン制御),と ドメインメンバシップ(ドメインメンバシップ)は 3つのサーバの役割のためのSambaの設定に言及する適切な情報を提供する。Sambaドメイン セキュリティの実装のための基礎を作るために、それらの章のそれぞれについて、精通 しておくことを強く推奨する。

スタンドアロンサーバはアカウント管理が独立している。スタンドアロン サーバとして設定することがサーバにとって何を意味するかについてのより広い評価を 得るために、スタンドアロンサーバを参照のこと。

Sambaセキュリティモード

この節では、Sambaのセキュリティモードの機能と目的について説明する。おのおののモードの ためにMicrosoft Windows クライアントを設定する方法と同様におのおののセキュリティモード についてどのようにSambaが実装しているかを正確に理解することは、ユーザの不満と管理者の 心労をとても減らすだろう。

Microsoft Windows ネットワークはもともとServer Message Block(SMB)プロトコルと 呼ばれていたプロトコルを使っている。1996年あたりから、プロトコルは Common Internet Filesystem(CIFS)プロトコルとしてより知られるようになった。

SMB/CIFSネットワークにおいては、ユーザレベル共有レベルという2つのセキュリティのみがある。それらをまとめて セキュリティレベルとして参照する。それら2つのセキュリティレベル の実装において、SambaはMicrosoft Windows NT4/200xサーバでは出来ない柔軟性を提供する。 実際、Sambaは共有レベルのセキュリティを1つの方法で実装しているが、 ユーザレベルのセキュリティについては4つの方法で実装している。 それらをまとめて、Sambaでのセキュリティレベルの実装を セキュリティモードと呼ぶ。それらは、 share, user, domain, ADSserverモードとして知られている。 それらはこの章で解説されている。

セッションのセットアップ時にクライアントに対してSMBサーバは動作しているサーバの セキュリティレベルを伝える。それはシェアレベルとユーザレベルという2つのオプション である。2つのうちのどちらかをクライアントが受け取り、それは、クライアントがそれ 自身を認証するときに試みる方法に影響する。それはSambaサーバをセキュリティ化する 方法には直接(たいして)影響しない。これは奇妙に聞こえるが、それはSMBのクライアント/ サーバアプローチに適合する。SMB中では、すべてはクライアントによって開始され、 制御され、サーバはクライアントに対して、何が有効で、どのような動作が許可されるか のみを通知できる。

clientという語は、たとえばWindowsワークステーション、Windows サーバ、あるいはその他の平凡なSMBまたはCIFSクライアントアプリケーション(たとえば smbclient)のような、SMB/CIFSサーバによって提供されるサービスを 使うものすべてのエージェントを参照する。

ユーザレベルのセキュリティ

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

  1. ユーザ名/パスワード ペア

  2. クライアントマシンの名前

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

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

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

設定例

ユーザレベルのセキュリティを実現する smb.conf の例は以下の通り:

security = user

これはSamba-2.2.xの既定値である。

共有レベルのセキュリティ

共有レベルのセキュリティ中では、クライアント自身の認証はおのおのの共有毎に 分離している。クライアントはおのおのの 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でチェックする。

設定例

共有レベルのセキュリティを設定するsmb.conf パラメータは以下の通り:

security = share

ドメインセキュリティモード(ユーザレベルのセキュリティ)

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

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

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

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

  1. プライマリドメインコントローラ(PDC) - ドメインに1つのみ。

  2. バックアップドメインコントローラ(BDC) - ドメインに複数配置可能。

  3. ドメインメンバサーバ(DMS) - ドメインに複数配置可能。

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

設定例

Sambaをドメインメンバサーバとする

この方法はsmb.confファイル中に以下のパラメータを必要とする:

security = domain
workgroup = MIDEARTH

この方法を動作させるために、SambaサーバはMicrosoft Windows NTセキュリティドメイン にジョインする必要がある。これは以下の方法で行う:

  1. Microsoft Windows NT ドメインコントローラ上で、サーバマネージャを つかい、Sambaサーバのマシンアカウントを追加する。

  2. UNIX/Linuxシステム上で以下を実行する:

    root# net rpc join -U administrator%password

Note

Samba-2.2.4とそれ以降の Samba 2.2.x 系列では、以下を実行することで、Windows NT4スタイル ドメインへの自動ジョインが可能である:

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

Samba-3では同じことを以下の方法で行う:

root# net rpc join -U Administrator%password

Samba-3ではDOMAIN_NAMEPDC_NAME を指定する必要はないので、smb.confファイルの設定からこれをわかるようにする(訳注:訳があやしい)。

Windowsドメインコントローラによってアカウントが認証される時に、UIDを割り当てるため、 このモードを使う認証は、おのおののユーザに対する標準UNIXアカウントがあることを要求 する。このアカウントは、/etc/passwdエントリ中で不正なシェルと して設定するような方法で、Microsoft Windows以外のクライアントによってログオンする ことをブロックすることができる。ユーザアカウントに対して不正なシェルを割り当てる 最も良い方法は、シェルに/bin/falseを割り当てることである。

ドメインコントローラは、利便性のために任意の場所に配置できる。BDCを配置する推奨は、 物理ネットワーク毎に配置し、もしもPDCがリモートネットワークセグメントにあるならば、 WINS(詳細はネットワークのブラウジングを参照)を 使うのが基本である。

Sambaサーバ上でWindowsユーザにUIDを割り当てる別の方法は、 WinbindWinbind: Use of Domain Accountsにある。

ドメインメンバシップについてのより詳細な情報は Domain Membershipを参照のこと。

ADS セキュリティモード(ユーザレベルのセキュリティ)

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 modemixed modeの ADS操作。 The term realmという単語はKerberosベースのセキュリティアーキテクチャ (Microsoft ADSによって使われるような)を説明するのに使われる。

設定例

realm = your.kerberos.REALM
security = ADS

以下のパラメータを必要としても良い:

password server = your.kerberos.server

この設定オプションの参考情報として、 ドメインメンバシップSamba ADS ドメインメンバシップを参照してほしい。

サーバセキュリティ(ユーザレベルのセキュリティ)

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

  • Microsoft Windows NT4/200xパスワードサーバ上でアカウントロックアウトの可能性。

  • Lack of assurance that the password server is the one specified.

  • リモートでプロファイルを格納するときに特に必要な、Winbindと一緒に動かない。

  • このモードはパスワードサーバに対して接続をオープンにでき、また長期間それとオープンしたままにできる

  • 突然リモートのパスワードサーバが停止したときに、不正にSambaサーバのセキュリティを壊す。

  • このモードでは、Sambaサーバのために属するドメイン中のパスワードサーバにセキュリティアカウントがない(訳注:訳が微妙)。

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

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

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

Note

server security modeでSambaサーバが動作しているとき、 パラメータpassword serverをターゲットの認証サーバの 正確なNetBIOSマシン名に設定することは必要である。Sambaは、ターゲットの認証 サーバの選択は任意であり、ドメイン名から決定できないという理由で、NetBIOS 名前検索からこれを決定できない。本質的に、 サーバセキュリティモードのSambaサーバはワークグループ モードとして知られているものとして動作している。

設定例

Microsoft Windows NTを認証サーバとして使う

この方法はsmb.confファイル中に以下のパラメータを追記することになる:

encrypt passwords = Yes
security = server
password server = "NetBIOS_name_of_a_DC"

ユーザ名/パスワードペアが正しいかどうかを確認する2つの方法がある。 1つは提供された認証メッセージングプロセスの一部としてリプライ情報を使う ことであり、もう1つはエラーコードを使うことである。

このモードの設定の悪い点は、セキュリティの観点でSambaが偽のユーザ名と偽の パスワードをパスワードサーバに送る可能性があることと、もしもリモートの サーバが偽のユーザ名と偽のパスワードの認証拒否に失敗すると代替の認証か 承認作業が使われてしまうと言うことである。数回の認証の繰り返し後にサイト がパスワードロックを使う場合、これはユーザをロックアウトしてしまう。

認証要求でのこのモードの使用はユーザが標準UNIXアカウントがあることを必要と する。このアカウントは非SMB/CIFSクライアントからのログオンを防止するために ブロックすることが出来る。

パスワードの検査

Microsoft Windows クライアントはチャレンジ/レスポンス認証モデル(NTLMv1と NTLMv2として知られる)の一部としての暗号化パスワードか、単独か、あるいは 単純なパスワードベースの認証のための平文パスワードを使うことが出来る (訳注:aloneがよく分からない)。これはSMBプロトコルで実現され、パスワード は平文または暗号化されてネットワーク経由で渡されるが、同じ認証要求では 両方は使われない。

暗号化パスワードが使われるとき、以下の2つの方法でユーザが入力した パスワードは暗号化される:

  • unicodeのパスワード文字列をMD4でハッシュ。 これはNTハッシュとして知られているものである。

  • パスワードは大文字化され、14バイトに短縮 される。この文字列に5バイトのNULL文字が追加され、"magic" な8バイト値に暗号化するために、2つの56ビットDESキー形式 に分割される。結果はLanManハッシュという16ビットの値である。

Microsoft Windows 95 サービスパック1より前とWindows NT バージョン3.xとバージョン 4.0のサービスパック3より前では、パスワード認証のどちらかのモードを使う。すべての それより後のMicrosoft Windowsバージョンはもはや既定値で平文パスワードをサポート しない。

Microsoft Windows クライアントは10分またはそれより長くアイドルな時にネットワーク マッピングを切断するという習性がある。切断した、マップされたドライブ接続を 使うためにユーザが試みるとき、クライアントはキャッシュされたパスワードの コピーを使って再接続する。

Microsoftが既定値のパスワードモードを変更したとき、平文パスワードのキャッシュ サポートをやめた。これは、平文パスワードを使うためにレジストリパラメータを修正 したときに、それは動くようになるが、もしもリモートの認証サーバが暗号化パスワード をサポートしないときに、切断されたサービスのマッピングを試みるときに失敗する ことを意味する。そのようなクライアントで平文パスワードを再度有効にすることは 良い考えではないと確かに言える。

以下のパラメータは、平文テキストでの認証を使うときに、Windows 9x/Meクライアントが 大文字化したユーザ名とパスワードをSMBサーバに送る前に問題になる時に使うことが できるものである:

既定値では、Sambaはローカルのシステムアカウントデータベース中でユーザ名を検索する前に ユーザ名を小文字に変更する。これは、UNIXユーザ名が慣習的に小文字のみで構成されている ことによるためであり、username-levelパラメータは滅多に必要と さない。

しかしながら、UNIXシステム上のパスワードはしばしば大文字小文字を混ぜた文字で構成され ている。これは、平文認証を使ってSambaサーバに接続しようとするWindows 9x/Meクライアント 上でのユーザのために、password levelが、パスワードに現れること が出来る大文字の最大数を設定しなければならないことを意味する。 もしもサーバのOSが伝統的なDESバージョンを使うcrypt()を使うならば、 password levelを8に設定することは、結果としてWindowsユーザ にとって、大文字小文字を無視したパスワードとして見える。これはまた、一致するまで (あるいはすべての組み合わせが失敗するまで)1つ1つ、Sambaがパスワード文字列の組み合わせ を試みるために、より長いログイン時間がかかるという結果となる。

最も適用するのによいオプションは、Sambaが使われている所はどこでも、暗号化パスワード をサポートすることを有効にすることである。平文パスワードを使うためにレジストリを 変更する試みは、結局はユーザの苦情と不便を導くことになるだろう。

共通のエラー

我々はいつでも間違いを犯す。正しい場所で正しい時間と同じくらいの長さで間違いを犯す のは問題ない(訳注:意味がよく取れない)。製品版での重要な障害は重要視されるが、 ラボでの開発バージョンにおいてのバグは期待されるものである。

Sambaメーリングリスト上の議論の題名となる共通の誤解と間違いを見てみよう。 その多くは、Samba実装を試みる前にあなたの宿題としてその多くが回避可能である。 そのいくつかは、英語を母国語としない人にとって、潜在的に曖昧で、とても紛らわしい 多くのフレーズを持つ英文の誤解釈の結果である。

何がSambaをサーバにするか?

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

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

何がSambaをドメインコントローラにするか?

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

何が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を変更する必要がある かもしれない。