web-dev-qa-db-ja.com

Samba：ローカルユーザーのAD認証

通常SSH経由でアクセスされるLinux開発サーバーがたくさんあります。各開発者は、Puppetによって管理される各ボックスにローカルアカウントを持っています。ログインは秘密鍵のみを介して行われます。ローカルパスワードはありません。

これらのボックスでSambaを実行し、ADドメインに対して認証したいと思います。 Samba以外のAD認証は必要ありません。他のすべてはSSHと秘密鍵を介してアクセスされます。

これが私のsmb.confです：

[global]
 workgroup = DOMAIN
 server string = Samba Server Version %v
 security = ADS
 realm = DOMAIN.FQDN
 encrypt passwords = yes
 log level = 3
 log file = /var/log/samba/%U.log

[homes]
 comment = Home Directories
 browseable = no
 writable = yes

ドメインに参加したので、Kerberos構成は問題ないと確信しています。

関連する（つまり、非標準）nsswitch.conf行：

passwd:     files winbind
group:      files winbind

問題は ADUIDからUNIXUIDへのマッピング のようです。デフォルトのTDBバックエンドは、ADユーザーが接続するときにオンデマンドで「仮想」UNIXアカウントを作成しますが、これは必要ありません。ユーザーfooをローカルユーザーfooにマップする必要があります。 idmap uid行とidmap gid行を追加すると、ユーザーは正常に認証されますが、アカウントはUNIXアカウントにマップされません。

何か案は？ Somoeneはこれを以前に行ったことがあるはずです！すべてのマシンで一貫したUID/GIDを維持するのが面倒なので、winbindとADを使用してすべてのアカウント情報を提供するように切り替えたくありません。また、再発明したくない既存のPuppet制御のユーザー構成にも多くのことを取り入れました。

authenticationsambawinbind
1
markdrayton

Winbindサービスが実行されていることを確認してください。

/etc/pam.d/sambaでセットアップします。

account     [default=bad success=ok user_unknown=ignore]  pam_winbind.so
account     required      pam_permit.so

password    sufficient    pam_winbind.so use_authtok
password    required      pam_deny.so
session     required      pam_limits.so

auth       required pam_nologin.so
auth sufficient pam_winbind.so use_first_pass
auth required   pam_deny.so

Pamの変更には、winbindの再起動が必要な場合があります。すべきではありませんが、実際の経験ではとにかくそれを行うと言われています。

Smb.confには、次のものも必要です。

realm = YOURKERBEROSREALMNAME
password server = the Host or IP of your ADC
idmap backend = rid:DOMAIN=5000-100000000
idmap uid = 10000-10000000
idmap gid = 10000-10000000
winbind use default domain = Yes
winbind enum users = Yes
winbind enum groups = Yes

DOMAINはワークグループまたはドメイン名であり、レルムはkrb5.confにあるものと一致します。

Smb.confの変更後、sambaサービスを再起動します

2
labradort

から http://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/idmapper.html#id260455

Windowsネットワークドメイン（NT4スタイルまたはADS）のSambaメンバーは、さまざまな方法でIDマッピングを処理するように構成できます。使用するメカニズムは、winbinddデーモンが使用されているかどうか、およびwinbind機能がどのように構成されているかによって異なります。ここでは、構成オプションについて簡単に説明します。

Winbindは使用されません。ユーザーとグループはローカルです：

Winbinddが使用されていない場合、Samba（smbd）は、基盤となるUNIX/Linuxメカニズムを使用して着信ネットワークトラフィックのIDを解決します。これは、セッションセットアップ要求でLoginID（アカウント名）を使用し、それをgetpwnam（）システム関数呼び出しに渡すことで行われます。この呼び出しは、最新のUNIX/Linuxシステムでネームサービススイッチ（NSS）メカニズムを使用して実装されます。 「ユーザーとグループはローカルです」とは、ローカルシステムの/ etc/passwdと/ etc/groupにそれぞれのみ保存されることを意味します。

たとえば、ユーザーBERYLIUM\WambatWがSambaサーバーへの接続を開こうとすると、着信SessionSetupAndX要求がシステムコールを実行して、/ etc/passwdファイルでユーザーWambatWを検索します。

この構成は、スタンドアロンのSambaサーバー、ドメインメンバーサーバー（NT4またはADS）、およびsmbpasswdまたはtdbsamベースのSambapassdbバックエンドのいずれかを使用するPDC）で使用できます。

方程式からwinbindを取り除くだけの場合、ADユーザーがローカルの/ etc/passwdユーザーと同じであると仮定すると、状況はhonkydoreyになるようです。

1
jwinders