Ubuntu + Apache + Active Directoryを設定する方法は？
UbuntuとApacheがあります+ PHP + MySQLはイントラネット上のボックスで正常に動作しています。ボックスにはIPアドレス経由でのみアクセスできます（現在）。次に、次のように設定します。エンタープライズActive Directoryサーバーを介して既に認証されているユーザーは、Webサイトに接続して、ADユーザー名をPHPにフロースルーさせることができます。ユーザーは再びAD資格情報を提供する必要はありません。これはSSPIと呼ばれますが、これは明らかにWindowsのみのことです。Linuxでこれを行うには、あらゆる種類の構成ファイルの編集を含む無数の異なるガイドのように見えますが、ほとんどのガイドは私には意味がありません。プロセスでSamba共有を設定しようとしていますが、ADに対する純粋な認証のみが必要です。最も近いのは、最終的にドメインに参加したときの「likewise-open」でしたが、Apacheを動作させるために見つけた手順は「」同様にオープン」はその後意味がありませんでした。 e適切なApacheバイナリを含む '/ opt/likewise /'ディレクトリですが、 '/ opt'には何もありません（空のディレクトリです）。
次のように想定します。
AD server primary DC hostname: ad.primarydc.com (parent company owns this)
AD server primary DC IP: 172.130.0.25
Our AD domain: MAIN (main.ad.primarydc.com)
Our AD domain IP: 10.1.134.67
Our AD admin account that can join computers to the domain: MAIN\admin
Ubuntu box IP: 10.1.134.15
Ubuntu box name: thebox
Ubuntu 12.04.2 LTS
「likewise-open」がインストールされ、「domainjoin-cli」はボックスがドメイン（THEBOX）に参加したことを示し、lw-get-statusは見慣れたものをたくさん返します。
以前は 'winbind'および 'libapache2-mod-auth-ntlm-winbind'がインストールされていました（最初の試行から。ドメインに参加することはできませんでした）。
従うのが簡単で実際に機能する初心者向けのガイドがあれば、最初からやり直したいと思います。
ApacheにADと通信させるには、正確に何をする必要がありますか？
ケルベロスはあなたの友達です！ （ADが実際に認証に使用するもの）
Soureforge Source＆KerberosモジュールをApacheにインストールする方法
おそらく必要になるでしょう：最初にlibapache2-mod-auth-kerbを：
http://www.microhowto.info/howto/configure_Apache_to_use_kerberos_authentication.html
全文：
Kerberos認証を使用するようにApacheを構成するにはバックグラウンド
Kerberosは、シングルサインオン（SSO）の概念をサポートする認証プロトコルです。セッションの開始時に一度認証されると、ユーザーは再度認証することなく、Kerberosレルム全体のネットワークサービスにアクセスできます。これが機能するには、Kerberos対応のネットワークプロトコルを使用する必要があります。
HTTPの場合、Kerberosのサポートは通常、SPNEGO認証メカニズム（シンプルで保護されたGSS-APIネゴシエーション）を使用して提供されます。これは、「統合認証」または「ネゴシエート認証」とも呼ばれます。 Apache自体はSPNEGOをサポートしていませんが、mod_auth_kerb認証モジュールを使用してサポートを追加できます。シナリオ
Webサイトへのアクセスを制限したいとします http://www.example.com/ 。認証は、KerberosとSPNEGOを使用して実行されます。 SPNEGOが有効になっていないWebブラウザからWebサイトにアクセスできる必要はありません。
アクセス権が付与されるユーザーは、KerberosレルムEXAMPLE.COMのメンバーであり、dougal、brian、ermintrude、およびdylanという名前が付けられています。レルムはプリンシパルbofh/adminを使用して管理できます。前提条件
以下の説明は、ApacheとKerberosの両方がWebサーバーにすでにインストールされていることを前提としています。
Apacheは、テスト目的で、関連するWebサイトから少なくとも1つのページを要求できる状態である必要があります。実際のコンテンツが含まれている必要はありません（含まれている場合は、適切に保護されるまで、許可されていないユーザーからサーバーを分離するための手順を実行する必要があります）。
Kerberosは、EXAMPLE.COMがデフォルトのレルムとして構成されており、Webサーバーでそのレルムのチケットを取得できる状態である必要があります。メソッドの概要
ここで説明する方法には、6つのステップがあります。
Mod_auth_kerb認証モジュールをインストールします。 Webサーバーのサービスプリンシパルを作成します。サービスプリンシパルのキータブを作成します。使用する認証方法を指定します。許可されたユーザーのリストを指定します。 Apache構成を再ロードします。
WebサーバーでSPNEGOを有効にするだけでなく、Webブラウザー内で明示的に有効にする必要がある場合があることに注意してください。これはMozillaFirefoxの場合であることが知られています。見る：
SPNEGOとKerberosを使用して認証するようにFirefoxを設定
mod_auth_kerb認証モジュールをインストールします
上記のように、Apache自体はSPNEGOのサポートを提供していませんが、モジュールmod_auth_kerbを使用して追加できます。これはほとんどの主要なGNU/Linuxディストリビューションに含まれていますが、サードパーティのモジュールであるため、通常はApacheとは別にパッケージ化されています。 Debianベースのシステムでは、パッケージlibapache2-mod-auth-kerbによって提供されます。
apt-get install libapache2-mod-auth-kerb
パッケージmod_auth_kerbによるRedHatベースのシステムでは：
yum install mod_auth_kerb
Apacheモジュールは使用する前にロードする必要がありますが、上記の両方のパッケージでは、これが自動的に行われるようになっています。何らかの理由でこれを手動で行う必要がある場合、適切な構成ディレクティブは次のとおりです。
LoadModule auth_kerb_module /usr/lib/Apache2/modules/mod_auth_kerb.so
（モジュールのパス名は、システムに適したものに置き換える必要があります）。 Webサーバーのサービスプリンシパルを作成します
SPNEGOでは、Webサーバー用にKerberosサービスプリンシパルを作成する必要があります。サービス名はHTTPとして定義されているため、サーバーwww.example.comの場合、必要なサービスプリンシパル名はHTTP/[email protected]です。
MIT Kerberosを使用している場合、サービスプリンシパルはkadminコマンドを使用して作成できます。
kadmin -p bofh/admin -q "addprinc -randkey HTTP/www.example.com"
サービスプリンシパルを作成する方法と必要な理由の詳細については、microHOWTO MIT Kerberosを使用してサービスプリンシパルを作成する）を参照してください。サービスプリンシパルのキータブを作成します。
キータブは、1つ以上のKerberosプリンシパルに対応する暗号化キーを格納するためのファイルです。 mod_auth_kerbは、上記で作成したサービスプリンシパルを利用するために1つ必要です。 MIT Kerberosを使用している場合、kadminコマンドを使用して（サービスプリンシパルと同様に）キータブを作成できます。その所有権は、Apacheプロセスから読み取り可能である必要があります。
Debianベースのシステムでは、キータブの適切な場所は/etc/Apache2/http.keytabであり、適切な所有者はwww-dataです。
kadmin -p bofh/admin -q "ktadd -k /etc/Apache2/http.keytab HTTP/www.example.com"
chown www-data /etc/Apache2/http.keytab
Red Hatベースのシステムでは、適切な場所は/etc/httpd/http.keytabであり、適切な所有者はApacheです。
kadmin -p bofh/admin -q "ktadd -k /etc/httpd/http.keytab HTTP/www.example.com"
chown Apache /etc/httpd/http.keytab
-kオプションはキータブへのパス名を指定します。キータブがまだ存在しない場合は作成されます。
キータブの作成、その目的、およびデフォルトのキータブ（通常は/etc/krb5.keytab）の詳細については、microHOWTO MIT Kerberosを使用してキータブにホストまたはサービスプリンシパルを追加する）を参照してください。ルートとして実行されないネットワークサービスでの使用には適していません。
キーがキータブに正しく追加されていることを確認したい場合は、キーを使用してサービスプリンシパルとして認証し、klistを使用して結果のチケット許可チケットを表示できます。
kinit -k -t /etc/Apache2/http.keytab HTTP/www.example.com
klist
使用する認証方法を指定します
Apacheは、mod_auth_kerbによって提供される認証を使用するWebサイトの部分を通知する必要があります。これは、Kerberosの値を持つAuthTypeディレクティブを使用して行われます。次に、mod_auth_kerbの動作を構成するために、さらにいくつかのディレクティブが必要です。
これらのディレクティブを特定のWebサイト全体に適用することを目的としている場合は、サイトのルートに対応するパスを持つコンテナーに配置できます。
<Location />
AuthType Kerberos
AuthName "Acme Corporation"
KrbMethodNegotiate on
KrbMethodK5Passwd off
Krb5Keytab /etc/Apache2/http.keytab
</Location>
AuthNameディレクティブは、HTTP認証レルムを指定します。その目的は、特定のWebサイトにアクセスするために、ユーザーが知っている可能性のあるさまざまなパスワードのどれが必要かをユーザーに示すことです。真のKerberos認証では、パスワードプロンプトは表示されないはずであり、mod_auth_kerbは、AuthNameが指定されていなくても完全に機能しているように見えます。ただし、Apacheのドキュメントにはそれが必要であると記載されているため、とにかくそれを提供するのが賢明に思えます。適切な値は、ドメイン名、Kerberosレルムの名前、またはWebサイトが属する組織の名前です。
SPNEGOプロトコルに加えて、mod_auth_kerbには、基本認証を使用してユーザーにパスワードを要求し、KDCへの認証を試行してそのパスワードを検証する機能があります。これは、承認されたユーザーがKerberosレルムの一部ではないマシンからWebサイトにアクセスできる必要がある場合に役立ちますが、真のKerberos認証よりも安全性が大幅に低下します。 SPNEGOとパスワード認証の両方がデフォルトで有効になっています。この例では、SPNEGOが有効になっていないWebブラウザーからサイトにアクセスできる必要はないため、KrbMethodK5Passwdディレクティブを使用してパスワード認証を無効にしています。完全を期すため、SPNEGOはKrbMethodNegotiateディレクティブを使用して明示的に有効になっています。
Krb5Keytabディレクティブは、HTTPサービスプリンシパルが追加されたキータブのパス名を指定します。これは、この手順の前半でkadminのktaddコマンドに渡されたものと一致する必要があります。
この例ではコンテナが使用されていますが、上記のディレクティブを、、コンテナ、または.htaccessファイル内に配置することも同様に受け入れられます。許可されたユーザーのリストを指定する
認証方法を設定しても、それ自体でサーバーへのアクセスが制限されることはありません。これは、Apacheがデフォルトで匿名ユーザーによるアクセスを許可するためであり、その動作がオーバーライドされない限り、認証方法（何であれ）は呼び出されません。
この例では、アクセスが必要なユーザーは4人だけであり、それを手配する最も簡単な方法は、Requireディレクティブを使用することです。
<Location />
# ...
Require user [email protected] [email protected] [email protected] [email protected]
</Location>
各名前は、それがメンバーであるKerberosレルムによって修飾されることに注意してください。
ユーザー数が多いサーバーの場合、これは明らかにスケーラブルなソリューションではありませんが、Apacheには、mod_authz_dbdやmod_authnz_ldapなどの多数のユーザーを効率的に処理できる他の承認方法があります。 Apache構成をリロードします
システムサービスに構成を再ロードさせるを参照してください。最近のDebianベースのシステムでは、必要なコマンドは次のとおりです。
service Apache2 force-reload
セキュリティに関する考慮事項パスワード認証
上記のように、mod_auth_kerbには、HTTP基本認証を使用してWebブラウザーからユーザー名とパスワードを要求し、Kerberosを使用してそのユーザー名とパスワードが有効かどうかを確認する機能があります。このアプローチには、真のKerberos認証と比較して3つの重大な欠点があります。
The password is sent unencrypted as part of the HTTP stream.
The password is exposed to the Apache server.
The password must be entered mid-session.
これらの最初のポイントは、TLS（SSL）を介したアクセスを有効にし、プレーンHTTPを無効にすることで対処できます。 2番目と3番目のポイントは扱いにくいため、シングルサインオンモデルによって、一般的にはKerberosによって提供されるセキュリティ上の利点の多くが損なわれます。
実際には、Kerberosレルムの一部ではないホストから、またはSPNEGOをサポートしないユーザーエージェントからのアクセスを許可する必要がある場合があります。このため、パスワード認証をフォールバックとして使用しないことを推奨するのは非現実的ですが、デフォルトで有効になっているという理由だけで許可できる場合と許可しない場合は、避けるのが最善です。 SPNEGO
SPNEGOを使用した認証は、上記の懸念に対処しますが、HTTPと統合する方法は理想からはほど遠いものです。クライアントがKerberosネットワークサービスに対して認証する場合、認証プロセスの製品の1つは、クライアントとサーバーがそれらの間のそれ以上の通信を保護するために使用できる暗号化キーです。これは、HTTP接続がSPNEGOを使用して認証される場合は使用されません。つまり、認証の完了後に接続がハイジャックされた場合、攻撃者が不正なHTTPコマンドを発行するのを防ぐことはできません。
このリスクは、TLS（SSL）を使用して接続を保護することで大幅に減らすことができます。これにより、接続が確立されるとハイジャックされるのを防ぎ、サーバーが有効な証明書を持たないWebサイトへの接続を受け入れるのを防ぎます。証明書を発行できる組織が多数あるため、完全なソリューションではありません。チャネルバインディングを使用してTLSキーをKerberosにリンクするソリューションがありますが、執筆時点では広く実装されていませんでした（mod_auth_kerbではサポートされていません）。