Kerberos構成ファイルを使用して...
[realms] DOMAIN.COM = { kdc = dc1.domain.com admin_server = dc1.domain.com }
... Linuxは、ADドメインメンバーでなくても、パスワード検証のためにActive Directoryと通信することができます。
$ kinit jdoe Password for [email protected]: $ klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: [email protected] Valid starting Expires Service principal 01/12/15 15:36:16 01/13/15 01:36:25 krbtgt/[email protected] renew until 01/19/15 15:36:16
この時点で、PAMを使用して/ etc/passwdにローカルLinuxユーザーを定義できますが、Active Directoryを介してTTYセッションを認証できます。 krb5を介した認証は、ログインごとのコンテキストとして行われます。
auth sufficient pam_krb5.so use_first_pass
しかし、krb5がPAMグローバルデフォルトの一部としてすでに実装されている場合、Sambaもそれを採用しないのはなぜですか? /etc/pam.d/sambaはKerberos化されたpassword-authファイルをインクルードしますが、SMBボリュームにアクセスするときは喜びがありません。デバッグログは、取得に失敗したことを示しています。非常に「あなたはドメインの一部ではありません」というSIDエラー。)
私の根底にある質問は、ドメインメンバーシップの余分なオーバーヘッド/複雑さなしに、Shellの場合と同様のkrb5 authn集中化をSambaで実行できるかどうかです。 NISクラスターシステムのグループにSambaサービスを実装する必要がありますが、各システムに異なるTDBSAMバックエンドを設定して、SMBパスワードの混乱を招くことは避けたいです。Kerberosをオーセンティケーターは素晴らしいですが、それでもローカルLinuxアカウントを介して承認/アクセスを定義し、domain-join、winbind DCの場合のように、すべてのドメインユーザーへのSambaアクセスを開かないようにしたいエミュレーション、または本格的なADサーバー。
別の方法として、LinuxクラスターのSambaには、より優れた集中型のバックエンド認証オプションがありますか?私はCTDBを調べましたが、異なるボリュームの中央認証ではなく、共有ストレージの仲介に向けられているようです...
Sambaは、人によって意味が異なります。一部の人にとって、これは、WinBindを使用して実際にWindows Serverを実行せずに疑似ドメインコントローラーサービスを提供することで、Microsoftに負担をかけずにLanManスタイルのネットワークを実装する方法です。これがおそらく「drookie」が「ADを実行しているようですが、何らかの理由で使用したくないようです」とコメントした理由です。とにかく、なぜSambaを使用するのですか?」どうして?私は主に基本的なCIFSサポートのためにSambaを使用しているからです。余分なWinBind/ADSホームディレクトリとキャッシュされたすべてのDCデータクラフトは、私が本当に望んでいないものです。承認とアクセスを定義するLinuxを探していました。ただし、許可されているユーザーにはKerberos認証を使用します(Samba、特にSamba4は、Windows ADドメインのLinuxノードの完全なActive Directoryエミュレーションに向かっており、SID/GUIDの継承、OUメンバーシップに至るまで、など。SambaはADプロファイルに基づいてオンザフライでアカウントを作成するため、Linuxローカルアカウントを作成する必要がないことを目標としています。
主にCIFS機能のためにSambaを探していたので、ADがKerberos呼び出しを介した認証部分にのみ使用できることを望んでいました(すでにSSHに実装されているため)。 KerberosをTTY/SSHレベルで機能させるためにドメイン参加が必要なかった場合、Samba + Kerberosで本当に必要ですか?残念ながら、答えはYESです。しかし、それにもかかわらず、LinuxホストをPDC/BDCに変更したり、すべての認証制御をADSモードに延期したりせずに、AD/Kerberos認証の目標を達成することができました。私が持っているものはうまくいきます、そしてこれが理由の私の解釈です:
基本的なKerberosはPAM/TTYレベルで機能します。これは、ユーザーがインタラクティブにパスワードを入力し、krb5ライブラリに直接入力するためです。リクエストを実行しているユーザーのコンテキストで実行する場合、ドメイン参加は必要ありません。ただし、CIFS共有を認証する場合、Windowsクライアントはユーザーが入力したパスワードをすでに暗号化しているため、Sambaがそれを取得するまでに、NTLMv2ハッシュになります。これがおそらく、O'Reillyの「ホーンビルの本」がSambaによって「auth PAMモジュールの行が完全に無視される」と言っている理由です。この場合、SambaはADサーバーに接続する必要があります安全に資格情報の詳細を取得して、ユーザー/パスワードが正しいかどうかを確認します。このため、ドメイン参加が必要です。基本的に、ドメインに参加しているSambaはKerberosプロキシとして機能し、ADに接続してクライアントの資格情報を確認します。
必要なドメイン参加があっても、ローカルのWinBindデーモンを実行したり、Linuxホストを完全なADサーバーにしたりする必要はないことがわかりました。これが私がSamba4設定ファイルで行ったことです:
security = ADS
passdb backend = tdbsam
realm = DOMAIN.COM
password server = *
encrypt passwords = yes
lanman auth = no
ntlm auth = no # NTLMv2
kerberos method = system keytab
username map = /etc/samba/smbusers
guest account = nfsnobody
map to guest = Bad User
obey pam restrictions = yes
私がしたことを指摘するほうがおそらく重要ですnotする:
最低限必要なことは、ローカルユーザーアクセスに関連するKerberosルックアップを有効にするためにドメイン参加が必要であることです。
# net ads join -U Administrator
# net ads keytab create
ただし、Linuxホストをカードを運ぶアクセス許可PDC/BDCまたはADSの代替に変えるサービスは有効にされていません。私はSamba + Kerberosをローカルユーザーの検証にのみ使用しており、それ以上は使用していません。
NISの上でSambaを実行できます。この場合、ユーザーデータベースはNISによって同期され、ドメインに参加しないと、スタンドアロンのSambaサーバーの束ができます。これは、ドメインユーザーまたは少なくとも各サーバーのパスワードを手動で追加する必要があることも意味します。これはおそらくあなたが望むものではありません。
ドメインに参加せずに、sambaユーザーのLDAPバックエンドとしてAD LDAPを使用して実験することもできます。
たくさんの選択肢がありますが、正直なところ、私はあなたの意見を理解していません。 ADを実行しているようですが、何らかの理由でADを使用したくありません。なんでとにかくSambaを使うのか。