
1つのプロジェクトに対して、次のように複数のSamba共有を構成しました。
[global]
workgroup = <domain name>
netbios name = <machine name>
passdb backend = tdbsam
security = ads
encrypt passwords = yes
realm = <fully qualified domain>
password server = <ldap server ip>
[Share1]
path = <path>
......
アイデアは、接続されたユーザーがLDAPサーバーによって認証され、それらが作成するすべてのファイルは、同じ名前のLinuxユーザーが所有することです。 Linux システムは SAMBA 以外の用途に ldap を使用しません。
LDAPサーバーが変更されるまで、すべてが期待どおりに機能し、エラーが発生しますNT_STATUS_NO_TRUST_SAM_ACCOUNT
。 LDAPチームと通信していますが、他のすべてのActive Directory認証が正常に機能していることを確認すると、それに応じてSamba設定を変更することが私たちの責任であると予想しています-_-"
私が見たガイドは、ほぼすべてのLinuxボックスにOpenLDAPサーバーをインストールして使用する(必要ありません)、内部的にLDAPユーザーを使用するようにLinux認証を構成する、またはユーザー名以上の複雑なマッピングを実行することに焦点を当てています(私たちは必要ありません)。どちらかが必要です)不要です。
私たちはSamba 4.2を使用しており、私たち全員が知っているように、最新バージョンへのアップグレードは上記の設定では機能しません(LDAPサーバーが変更される前でも)。
要求された動作を達成するためにSambaを設定する他の(おそらくより正確な)方法を知っていますか?私たちに必要なのは、「ユーザー認証の確認」に応答するLDAPサーバーだけです。ユーザーマッピングもなく、ドメインにコンピュータもなく、複雑な構成もありません。
答え1
ドメインのメンバーになると(たとえば、「security = ads」に必要な場合)、サーバー用のコンピュータアカウントがディレクトリに作成されます。サーバーはこのアカウントを使用してドメインのリソースにアクセスします。
NT_STATUS_NO_TRUST_SAM_ACCOUNTは、コンピュータアカウントの使用に問題があることを示します(何らかの理由で資格情報が期限切れになった可能性があります)。ドメインを離れてもう一度サインアップ(「ネットワーク広告にサインアップ」)すると、この問題は解決されます。
以前のバージョンの Samba は、ドメインメンバーではなくリモートサーバーへの認証転送をサポートしていましたが、AFAICT はもう存在しませんでした。