|
||
|
ActiveDirectoryと連携するメールサーバ(WinbindとMBOX)LinuxのメールアカウントをActiveDirectoryで管理する方式です。1.メールサーバのアカウントをAD上のユーザーと連携できる 2.メールのパスワードをActiveDirectoryで統一管理。 などが主なメリットです。 複雑なことに思えますが、やっていることはシンプルで、Linuxのユーザー認証のときローカルユーザーに加えて、ActiveDirectory上もチェックする。ということです。 認証の仕組み 必要なものは3つ。 ・構築済みのActiveDirectory ・意図した通りに動作するメールサーバ (SMTP・POP) ・Sambaに含まれているWinbind Mbox形式とは、メールを1つのファイルへ追記する形で格納する方式です。 Mbox形式はMairDir形式に比べると注意する点が多いです。 新規に作るならMailDir形式のほうが簡単でしょう。 メール形式にMBox形式を用いる場合、AD連携させると問題になりやすいのがホームディレクトリの取り扱いです。 DovecotのMBox形式ではメールの保存領域以外に、IMAP向けのホームディレクトリ(~/mail)を要求します。 従って、ホームディレクトリの自動作成を考慮しておく必要があります。 ホームディレクトリがないとメールの取り出しに失敗します。 ここで事前設計として考慮しておく点があります。 パターン1 使いもしないホームディレクトリがどんどん増えていく必要はない。初めからユーザーのホームディレクトリが不要な設定にする。 ただしこの運用はPOPでのみ動作して、将来のIMAP化には対応していない。 パターン2 Dovecotのデフォルト通りの構成として、ホームディレクトリを自動作成を設定する。 ただしSELinuxを調整する気がないのなら無効化する必要がある。 もしも貴方が不運にもLinuxのローカルユーザーによるメールアカウントと、AD連携によるWindowsユーザーによるメールアカウントの二重管理している場合は、ホームディレクトリパスをそれぞれ分けるのが無難。 ややこしいので、最初に基本の設定を行い、最後にパターン別に分岐する説明をします。 他の調整については別ページにて解説しています。 1.メールサーバの構築 (MailBox形式)#yum install postfix (デフォルトで入っている)#yum install dovecot /etc/postfix/main.conf の編集 mydestination = $myhostname, localhost.$mydomain, example.local (追加) inet_interfaces = all inet_protocols = ipv4 mynetworks = localhost #home_mailbox = MailDir/ コメントアウト確認 mail_spool_directory = /var/mail 末尾にスラッシュがないこと /etc/dovecot/dovecot.conf の編集 listen = * :: を削除して*だけに変更 protocols = pop3 imap lmtpを削除してpop3だけに /etc/dovecot/conf.d/10-auth.conf の編集 disable_plaintext_auth = no /etc/dovecot/conf.d/10-mail.conf の編集 POP3のみでホームディレクトリを自動生成しない場合 mail_location = mbox:/var/empty:INBOX=/var/mail/%u:INDEX=MEMORY IMAPを使ったり、ホームディレクトリがある場合 mail_location = mbox:~/mail:INBOX=/var/mail/%u /etc/dovecot/conf.d/10-ssl.conf の編集 #ssl = required #コメントアウト サービスを再起動します。 #service postfix restart #service dovecot restart #chkconfig postfix on #chkconfig dovecot on テストユーザーを作成し、試験します。 #useradd -s /sbin/nologin user1 #passwd user1 仮メールを1通送っておきます。でないとPOPで失敗します。 #mail -s TestMail user1@example.local test (本文入力) . (ドットで終了) この時点でメールクライアントを接続し、user1@example.localへメールが送受信できるか確認します。 1.サービスが正常に起動していない 2.ファイアウォールが閉まってる 3.テストメール送信に失敗して、まだメールが1通もない 2.AcitveDirectoryへ参加するActiveDirectoryに参加するためにはsambaが必要です。今回の環境ならsamba3で可能です。#yum install samba なお、samba4の場合、後に必要になるwinbindが含まれていない模様。 追加インストールします。 winbind-clientsには、後で使用するwbinfoなどが含まれています。 #yum install samba-winbind samba-winbind-clients DNSがActiveDirectoryのドメインコントローラを向いている必要があります。 コマンドで、現在のDNSがどこに向いているかを確認します。 #cat /etc/resolv.conf /etc/samba/smb.conf の編集 [global] netbios name = mailsv #security = user #コメントアウト security = ads workgroup = EXAMPLE realm = EXAMPLE.LOCAL #注意。ここは大文字で指定 ドメイン参加 #net ads join -U administrator ADの管理者パスワードを入力し、AD上にコンピュータアカウントが生成されていれば成功です。 以下のメッセージも成功です。 Joined 'MAILSV' to dns domain 'example.local' No DNS domain configured for mailsv. Unable to perform DNS Update. DNS update failed! AD側のDNSのアップデートが失敗しているので、netbios nameと同じ名前をADのDNSのAレコードに追加しておきます。 3.Linuxの認証をActiveDirectoryと連携させる/etc/nsswitch.conf の編集password: files winbind shadow: files winbind group: files winbind filesの後にwinbindを続けることで、ローカル認証→次にWinbind経由のAD認証となります。 /etc/samba/smb.conf の編集 [global] security = ads netbios name = mailsv workgroup = EXAMPLE realm = EXAMPLE.LOCAL idmap config * : backend = tdb idmap config * : range=10000-20000 winbind use default domain = yes /etc/krb5.conf の編集 [libdefaults] default_realm = EXAMPLE.LOCAL [realms] EXAMPLE.LOCAL = { kdc=dc1.example.local #ドメインコントローラのFQDN kdc=dc2.example.local #追加のドメインコントローラのFQDN admin_server = dc1.example.local #ドメインコントローラのFQDN } [domain_realm] .example.local = EXAMPLE.LOCAL #大文字で設定 example.local = EXAMPLE.LOCAL PostfixやSSHなどsamba以外からWinbindを利用可能にするためにはpamの設定が必要です。 /etc/pam.d/system-authファイルをコマンドで設定変更する。 #authconfig --enablewinbindauth --update 8系の場合、以下のようにコマンドを変更します。 #authconfig --enablewinbind --enablewinbindauth --update 設定が完了したら、連携できるようWinbindを起動。(authconfig実行時にwinbindは起動されますが) ActiveDirectoryと連携するだけならsambaのその他サービス(smb、samba、nmbd)は起動する必要ありません。 #service winbind start #chkconfig winbind on 試験 いくつかのコマンドで、ユーザー情報をADから正しく取得できるかを試します。 #wbinfo -p Winbindの起動確認 #wbinfo -t ドメイン接続確認。root権限いる #wbinfo -u ADから全てのユーザーを取得する #wbinfo -g ADから全てのグループを取得する #getent passwd 'example\winuser1' シングルクォーテーションなことに注意 getentはユーザーのマッピング情報をpasswd形式で表示します。 ここでエラーが出るのなら、nsswitch.confやsmb.confのwinbind系の設定値がミスってます。 getentを使用して成功した場合はユーザーがログインしたものとみなされます。 Linuxが払いだすマッピング用のSID(ここでは10000から20000の間)が1つ消費され、SIDとUIDのマッピング情報がTDBへ書き込まれます。 マッピング用TDB (/var/lib/samba/winbindd_idmap.tdb) は、WindowsのSIDとLinuxのUIDを関連付けたものです。
マッピング用TDBの中身を確認するには #net idmap dump とします。 マッピング用TDBからマッピングエントリを削除する場合は 表示されたWindowsのSIDを使ってdeleteコマンドを使用します。 #net idmap delete S-1-5-21-2659596216-558067740-645703359-10103 次に、ADに対してユーザーのパスワード認証が正しくできるかを確認します。 #wbinfo -a Administrator%P@sswd パスワードの認証テスト。%は区切り文字。root権限いる #kinit winuser1@EXAMPLE.LOCAL レルムは大文字で指定 kinitはケルベロスチケットの取得を行います。 kinitはパスワード入力に成功すると、なんのメッセージも表示されません。 認証が成功しない場合、以下のようなメッセージが表示されます。 エラー kinit: Cannot find KDC for requested realm while getting initial credentials エラーの場合はkrb5.conf の設定内容をチェックをします。大文字小文字、つづり間違いが考えられます。 4.ホームディレクトリを考慮し調整するパターン1 ホームディレクトリを不要とする/etc/dovecot/conf.d/10-mail.conf の編集 mail_location = mbox:/var/empty:INBOX=/var/mail/%u:INDEX=MEMORY ホームディレクトリが必要な理由はdovecotがIMAPで使うINBOXを配置するからです。 絶対POPしか使わないなら、そもそもこのINBOXの設定は不要です。 ここでいうINBOXはdovecotの10-mail.confの 「 mail_location = mbox:~/mail:INBOX=/var/mail/%u 」 の INBOX=/var/mail/%u のことではなく ~/mailと指定されている ~mail/.imap/INBOX のことです。 IMAP用のINBOXをemptyへ破棄しつつ、INDEXファイルはメモリー上に配置することでPOPの動作に特化させます。 これならホームディレクトリが作成されずに済みます。 パターン2 ホームディレクトリを自動作成させる /etc/sysconfig/selinux の編集 SELINUX=disabled selinuxファイル設定変更を有効にするにはOSの再起動が必要となります。 とりあえずコマンドでも一時的にSELinuxを無効化できます。 #setenforce 0 一時的にSELinuxを無効化 #mkdir /home/EXAMPLE ドメイン名のディレクトリを作成 #chmod 1777 /home/EXAMPLE スティッキービット付きアクセス権を与える dovecotがログインして、ホームディレクトリを作成できない理由はSELinuxによって書き込みが禁止されているためと、必要となるパス/home/EXAMPLE/winuser1 のEXAMPLEディレクトリの部分が作成できないためです。 EXAMPLEを管理者が作成し、それにスティッキービットのフルアクセス権(1777)を与えることで、ユーザーがホームディレクトリを作成できるようになります。 ではなぜ /home/EXAMPLE/ユーザー名 なのか。それはsmb.confの暗黙のデフォルト値が template homedir = /home/%D/%U となっているからです。 ここを単純に template homedir = /home/%U と書き換えてはダメなのか。 ダメではありませんが、その場合 /home にスティッキービット付のフルコントロールを与える必要があります。 伝統的ディレクトリのデフォルトのパーミッションを変更するのも気持ちが悪いですし、他に利用しているLinuxのローカルユーザーもいるかもしれませんし。 だからADと連携しているユーザーのホームディレクトリは /home/EXAMPLE の下へ集めておくか、いっそ template homedir = /home_data/%U のように、全く別の場所に追い出したほうが良いでしょう。 パターン2A ホームディレクトリは管理者が作成 #mkdir /home/EXAMPLE ドメイン名のディレクトリを作成 #mkdir /home/EXAMPLE/win_user1 ユーザーのディレクトリ作成 #chmod 700 /home/EXAMPLE/win_user1 パーミッションを指定 #chown winuser1:"domain users" /home/EXAMPLE/winuser1 このやり方のなにが良いのか。 メールサーバをAD連携して困るのは、その瞬間からAD上の全ユーザーがメールを送受信できるようになることです。 管理者がホームディレクトリを作成しないとメールが受信できない → 管理者が許可したユーザーのみメール受信可 なおPOPによる取り出しは制御できますが、SMTPによるメールの着信はしてしまいます。 (/var./spool/mail のアクセス権を変更して、管理者がファイルを作らないとメール受信できないような方法も考えられますが) 5.メールの送受信試験をするActiveDirectory上に存在するユーザー名をメールアドレスにして(例えば winuser1@example.local)、メールサーバへ送信します。正しく着信し、winuser1のパスワードでメールが取り出せれば成功です。 |
|