Table of Contents
この章では、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 Active Directoryドメインと同じように NT4スタイルのMicrosoft Windows 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のセキュリティモードの機能と目的について説明する。おのおののモードのために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,ADSとserverモードとして知られている。それらはこの章で解説されている。
セッションのセットアップ時にクライアントに対してSMBサーバは動作しているサーバのセキュリティレベルを伝える。それはシェアレベルとユーザレベルという2つのオプションである。2つのうちのどちらかをクライアントが受け取り、それは、クライアントがそれ自身を認証するときに試みる方法に影響する。それはSambaサーバをセキュリティ化する方法には直接(たいして)影響しない。これは奇妙に聞こえるが、それはSMBのクライアント/サーバアプローチに適合する。SMB中では、すべてはクライアントによって開始され、制御され、サーバはクライアントに対して、何が有効で、どのような動作が許可されるかのみを通知できる。
client
という語は、たとえばWindowsワークステーション、Windowsサーバ、あるいはその他の平凡なSMBまたはCIFSクライアントアプリケーション(たとえばsmbclient
)のような、SMB/CIFSサーバによって提供されるサービスを使うものすべてのエージェントを参照する。
それが簡単なため、最初にユーザレベルのセキュリティを説明する。ユーザレベルのセキュリティでは、クライアントはプロトコルネゴシエーションを伴って、直接セッションセットアップ要求を送信する。この要求はユーザ名とパスワードを提供する。サーバはそのユーザ名/パスワードペアを受け取るか拒否するかのどちらかを行う。この段階で、サーバはクライアントが結局接続しようと試みる共有が何であるかを知るすべはなく、そのため、許可/拒否について、以下の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 ldapshadow: files nis ldapgroup: files nis ldap
以下の例(実際に使われるようなものではないが)では、検索は、/etc/passwd
と /etc/group
に対して行われ、見つからなければ NISでチェックし、次にLDAPでチェックする。
ドメインセキュリティは、すべてのユーザとグループアカウントを、中央の共有されているアカウントリポジトリに保存するメカニズムを提供する。中央のアカウントリポジトリはドメイン(セキュリティ)コントローラ間で共有される。ドメインコントローラとして振る舞うサーバはドメインに対するセキュリティコンテキストに参加するすべてのマシンに、認証と確認サービスを提供する。プライマリドメインコントローラ(PDC)はセキュリティアカウントデータベースの完全性を管理するための責任を負うサーバである。バックアップドメインコントローラ(BDC)はドメインログオンと認証サービスのみを提供する。通常、BDCはPDCが行うよりもより反応性がよいネットワークログオン要求を提供する。
Sambaがsecurity = domainモードで動作中の時、Sambaサーバはドメインセキュリティ信頼アカウント(マシンアカウント)を持ち、ドメインコントローラに対してすべての認証要求をパススルーする。別の言い方をすると、この設定は、実際、それがドメインコントローラとして振る舞う場合にも、Sambaサーバをドメインメンバサーバにする。ドメインセキュリティに参加するすべてのマシンはセキュリティデータベース中にマシンアカウントを持たなければならない。
ドメインセキュリティ環境ないで、セキュリティアーキテクチャの基盤は、ユーザレベルのセキュリティを使う。ドメインメンバであるマシンは開始時に認証を行わなければならない。アカウントデータベース内にあるアカウントエントリの一部であるマシンアカウントは、その名前がマシンのNetBIOS名であり、パスワードはランダムに生成され、ドメインコントローラと他のマシンの両方に知られている。もしもマシンアカウントがセットアップ中に認証されなければ、ユーザは、それが認証できないため、そのマシンを使ってドメインにログオンできない。マシンアカウントはマシン信頼アカウントとして参照される。
ドメインメンバの設定には以下の3つのパターンがある:
プライマリドメインコントローラ(PDC) - ドメインに1つのみ。
バックアップドメインコントローラ(BDC) - ドメインに複数配置可能。
ドメインメンバサーバ(DMS) - ドメインに複数配置可能。
それぞれについて別の節で解説する。まずはじめに、もっとも関心のある基本的なDMSの設定について説明する。
Sambaをドメインメンバサーバとする
この方法はsmb.conf
ファイル中に以下のパラメータを必要とする:
security = domain |
workgroup = MIDEARTH |
この方法を動作させるために、SambaサーバはMicrosoft Windows NTセキュリティドメインにジョインする必要がある。これは以下の方法で行う:
Microsoft Windows NT ドメインコントローラ上で、サーバマネージャを つかい、Sambaサーバのマシンアカウントを追加する。
UNIX/Linuxシステム上で以下を実行する:
root#
net rpc join -U administrator%password
Samba-2.2.4とそれ以降の Samba 2.2.x 系列では、以下を実行することで、Windows NT4スタイルドメインへの自動ジョインが可能である:
root#
smbpasswd -j
DOMAIN_NAME
-rPDC_NAME
\ -U Administrator%password
root#
net rpc join -U Administrator%
password
Samba-3ではDOMAIN_NAME
かPDC_NAME
を指定する必要はないので、smb.conf
ファイルの設定からこれをわかるようにする(訳注:訳があやしい)。
Windowsドメインコントローラによってアカウントが認証される時に、UIDを割り当てるため、このモードを使う認証は、おのおののユーザに対する標準UNIXアカウントがあることを要求する。このアカウントは、/etc/passwd
エントリ中で不正なシェルとして設定するような方法で、Microsoft Windows以外のクライアントによってログオンすることをブロックすることができる。ユーザアカウントに対して不正なシェルを割り当てる最も良い方法は、シェルに/bin/false
を割り当てることである。
ドメインコントローラは、利便性のために任意の場所に配置できる。BDCを配置する推奨は、物理ネットワーク毎に配置し、もしもPDCがリモートネットワークセグメントにあるならば、WINS(詳細はネットワークのブラウジングを参照)を使うのが基本である。
Sambaサーバ上でWindowsユーザにUIDを割り当てる別の方法は、WinbindとWinbind: Use of Domain Accountsにある。
ドメインメンバシップについてのより詳細な情報はDomain Membershipを参照のこと。
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 termrealm
という単語は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 = serverはuser modeで動いていることをSambaがクライアントに報告することを意味するが、実際には別のユーザモードサーバに対してすべての認証要求を渡す。これは、真の認証サーバを差す追加のpassword serverパラメータを必要とする。真の認証サーバは別のSambaサーバでも、Windows NTサーバでもよく、後者は標準で暗号化パスワードをサポートしている。
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のセキュリティモードの性質は明白であるが、それでも完全に間違っている(訳注:意味取れない)。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を変更する必要があるかもしれない。