ad_*_*ewb 5 ubuntu active-directory likewise-open apache-2.2
我的 Ubuntu 和 Apache + PHP + MySQL 在我们的 Intranet 上运行良好。该盒子只能通过 IP 地址访问（当前）。现在我想设置它，以便已经通过企业 Active Directory 服务器进行身份验证的用户可以连接到该网站并使 AD 用户名流向 PHP，而无需用户再次提供他们的 AD 凭据。我听说这叫做 SSPI，但这显然是 Windows 独有的。我发现了在 Linux 下执行此操作的无数不同指南，这些指南涉及编辑各种配置文件，但没有一个指南对我有意义，因为他们中的大多数都试图在此过程中设置 Samba 共享，而我只需要针对 AD 的纯身份验证。当它最终加入域时，我得到的最接近的是“同样开放”，但是后来我发现让 Apache 与“同样开放”一起工作的说明在那之后就没有意义了。我遵循的说明说会有一个包含适当 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 对话？
Kerberos 是你的朋友！（这是 AD 实际用于身份验证的内容）
\n\n\n\nSoureforge 源代码以及如何将 Kerberos 模块安装到 Apache 中
\n\n您可能首先需要：libapache2-mod-auth-kerb，如下所示：
\n\nhttp://www.microhowto.info/howto/configure_apache_to_use_kerberos_authentication.html
\n\n全文：
\n\n将 Apache 配置为使用 Kerberos 身份验证\n后台
\n\nKerberos 是一种支持单点登录 (SSO) 概念的身份验证协议。在会话开始时经过一次身份验证后，用户可以访问整个 Kerberos 领域的网络服务，而无需再次进行身份验证。为此，必须使用支持 Kerberos 的网络协议。
\n\n对于 HTTP，通常使用 SPNEGO 身份验证机制（简单且受保护的 GSS-API 协商）提供对 Kerberos 的支持。这也称为 \xe2\x80\x98 集成身份验证\xe2\x80\x99 或 \xe2\x80\x98 协商身份验证\xe2\x80\x99。Apache 本身不支持 SPNEGO，但可以通过 mod_auth_kerb 身份验证模块添加支持。\n场景
\n\n假设您希望限制对网站http://www.example.com/的访问。将使用 Kerberos 和 SPNEGO 执行身份验证。不支持 SPNEGO 的 Web 浏览器无需访问该网站。
\n\n被授予访问权限的用户是 Kerberos 领域 Examples.COM 的成员，名为 dougal、brian、ermintrude 和 dylan。可以使用主体 bofh/admin 来管理该领域。\n先决条件
\n\n下面的描述假设您已经在 Web 服务器上安装了 Apache 和 Kerberos。
\n\nApache 应该处于这样一种状态：您可以从相关网站请求至少一个页面以进行测试。它不需要包含任何真实内容（如果包含，那么您可能需要采取措施将服务器与未经授权的用户隔离，直到服务器得到适当的保护）。
\n\nKerberos 应处于以下状态：EXAMPLE.COM 已配置为默认领域，并且可以在 Web 服务器上获取该领域的票证。\n方法\n概述
\n\n这里描述的方法有六个步骤：
\n\n安装 mod_auth_kerb 身份验证模块。\n为 Web 服务器创建服务主体。\n为服务主体创建密钥表。\n指定要使用的身份验证方法。\n指定授权用户列表。\n重新加载 Apache 配置。
\n\n请注意，除了在 Web 服务器上启用 SPNEGO 之外，可能还需要在 Web 浏览器中显式启用它。Mozilla Firefox 就是这种情况。看：
\n\n配置 Firefox 以使用 SPNEGO 和 Kerberos 进行身份验证
\n\n安装mod_auth_kerb认证模块
\n\n如上所述，Apache 本身不提供对 SPNEGO 的支持，但可以使用模块 mod_auth_kerb 添加它。大多数主要 GNU/Linux 发行版中都包含该模块，但由于它是第三方模块，因此通常与 Apache 分开打包。在基于 Debian 的系统上，它由 libapache2-mod-auth-kerb 包提供：
\n\napt-get install libapache2-mod-auth-kerb\n在基于 Red Hat 的系统上使用 mod_auth_kerb 包：
\n\nyum install mod_auth_kerb\nApache 模块必须先加载才能使用，但上述两个包都安排了此操作自动发生。如果出于任何原因您需要手动执行此操作，则适当的配置指令是：
\n\nLoadModule auth_kerb_module /usr/lib/apache2/modules/mod_auth_kerb.so\n（其中模块的路径名应替换为适合您的系统的路径名）。\n为 Web 服务器创建服务主体
\n\nSPNEGO 要求为 Web 服务器创建 Kerberos 服务主体。服务名称定义为 HTTP，因此对于服务器 www.example.com，所需的服务主体名称为 HTTP/www.example.com@EXAMPLE.COM。
\n\n如果您使用 MIT Kerberos，则可以使用 kadmin 命令创建服务主体：
\n\nkadmin -p bofh/admin -q "addprinc -randkey HTTP/www.example.com"\n有关如何创建服务主体以及为何需要服务主体的更多信息，请参阅 microHOWTO 使用 MIT Kerberos 创建服务主体。\n为服务主体创建密钥表
\n\n密钥表是一种用于存储与一个或多个 Kerberos 主体相对应的加密密钥的文件。mod_auth_kerb 需要一个才能使用上面创建的服务主体。如果您使用 MIT Kerberos，则可以使用 kadmin 命令创建密钥表（如服务主体）。它的所有权必须能够被 Apache 进程读取。
\n\n在基于 Debian 的系统上，密钥表的合适位置是 /etc/apache2/http.keytab，合适的所有者是 www-data：
\n\nkadmin -p bofh/admin -q "ktadd -k /etc/apache2/http.keytab HTTP/www.example.com"\nchown www-data /etc/apache2/http.keytab\n在基于 Red Hat 的系统上，合适的位置是 /etc/httpd/http.keytab，合适的所有者是 apache：
\n\nkadmin -p bofh/admin -q "ktadd -k /etc/httpd/http.keytab HTTP/www.example.com"\nchown apache /etc/httpd/http.keytab\n-k 选项指定密钥表的路径名，如果密钥表不存在，则将创建该路径名。
\n\n请参阅 microHOWTO 使用 MIT Kerberos 将主机或服务主体添加到密钥表，以获取有关密钥表的创建、其目的以及为什么默认密钥表（通常为 /etc/krb5.keytab）不适合由以下网络服务使用的更多信息：不要以 root 身份运行。
\n\n如果您希望检查密钥是否已正确添加到密钥表中，那么您可以尝试使用它作为服务主体进行身份验证，然后使用 klist 查看生成的票证授予票证：
\n\nkinit -k -t /etc/apache2/http.keytab HTTP/www.example.com\nklist\n指定要使用的身份验证方法
\n\n必须告知 Apache 哪些网站的哪些部分要使用 mod_auth_kerb 提供的身份验证。这是使用值为 Kerberos 的 AuthType 指令完成的。然后需要一些进一步的指令来配置 mod_auth_kerb 的行为方式。
\n\n如果目的是将这些指令应用于整个给定网站，那么可以将它们放置在一个容器中，其路径对应于该网站的根目录：
\n\n<Location />\n AuthType Kerberos\n AuthName "Acme Corporation"\n KrbMethodNegotiate on\n KrbMethodK5Passwd off\n Krb5Keytab /etc/apache2/http.keytab\n</Location>\nAuthName 指令指定 HTTP 授权领域。其目的是向用户指示他可能知道的各种密码中的哪些是需要访问特定网站的。使用真正的 Kerberos 身份验证，不应该出现密码提示，并且 mod_auth_kerb 似乎在没有指定 AuthName 的情况下工作得很好；然而 Apache 文档指出这是必需的，因此无论如何提供一个似乎是谨慎的做法。合适的值可能是域名、Kerberos 领域的名称或网站所属组织的名称。
\n\n除了 SPNEGO 协议之外，mod_auth_kerb 还能够使用基本身份验证向用户询问密码，然后通过尝试向 KDC 进行身份验证来验证该密码。如果授权用户需要从不属于 Kerberos 领域的计算机访问网站，这可能很有用，但它的安全性明显低于真正的 Kerberos 身份验证。默认情况下启用 SPNEGO 和密码身份验证。在此示例中，不要求非 SPNEGO 启用的 Web 浏览器可以访问该站点，因此已使用 KrbMethodK5Passwd 指令禁用密码身份验证。为了完整起见，已使用 KrbMethodNegotiate 指令显式启用 SPNEGO。
\n\nKrb5Keytab 指令指定已添加 HTTP 服务主体的密钥表的路径名。它应该与在此过程前面传递给 kadmin ktadd 命令的任何内容相匹配。
\n\n尽管本示例中使用了容器，但将上述指令放置在 、 或容器内或 .htaccess 文件内同样可以接受。\n指定授权用户列表
\n\n设置身份验证方法本身并不限制对服务器的访问。这是因为 Apache 默认允许匿名用户访问，除非覆盖该行为，否则将不会调用身份验证方法（无论它是什么）。
\n\n在此示例中，只有四个用户需要访问权限，最简单的安排方法是通过 Require 指令：
\n\n<Location />\n # ...\n Require user dougal@EXAMPLE.COM brian@EXAMPLE.COM ermintrude@EXAMPLE.COM dylan@EXAMPLE.COM\n</Location>\n请注意，每个名称均由其所属的 Kerberos 领域限定。
\n\n对于具有大量用户的服务器，这显然不是一个可扩展的解决方案，但是 Apache 有其他授权方法可以有效地处理大量用户，包括 mod_authz_dbd 和 mod_authnz_ldap。\n重新加载 Apache 配置
\n\n请参阅导致系统服务重新加载其配置。在最新的基于 Debian 的系统上，所需的命令是：
\n\nservice apache2 force-reload\n安全注意事项\n密码身份验证
\n\n如上所述，mod_auth_kerb 能够使用 HTTP 基本身份验证从 Web 浏览器请求用户名和密码，然后使用 Kerberos 检查该用户名和密码是否有效。与真正的 Kerberos 身份验证相比，此方法具有三个严重缺点：
\n\nThe password is sent unencrypted as part of the HTTP stream.\nThe password is exposed to the Apache server.\nThe password must be entered mid-session.\n第一个问题可以通过启用 TLS (SSL) 访问并禁用纯 HTTP 来解决。第二点和第三点不太容易处理，并且破坏了单点登录模型（特别是 Kerberos）提供的许多安全优势。
\n\n在实践中，有时需要允许来自不属于 Kerberos 领域的主机或来自不支持 SPNEGO 的用户代理的访问。因此，建议永远不要将密码身份验证用作后备措施是不切实际的，但是如果可以且不应该仅仅因为默认情况下启用密码身份验证而被允许，那么最好避免这样做。\nSPNEGO
\n\n使用 SPNEGO 进行身份验证解决了上面列出的问题，但它与 HTTP 集成的方式远非理想。当客户端对 Kerberos 网络服务进行身份验证时，身份验证过程的产品之一是加密密钥，客户端和服务器可以使用该密钥来保护它们之间的任何进一步通信。当使用 SPNEGO 对 HTTP 连接进行身份验证时，不会使用此功能，这意味着如果在身份验证完成后连接被劫持，则无法阻止攻击者发出未经授权的 HTTP 命令。
\n\n使用 TLS (SSL) 来保护连接可以大大降低这种风险。这可以防止连接建立后被劫持，并防止服务器接受到没有有效证书的网站的连接。由于可以颁发证书的组织数量众多，因此这不是一个完美的解决方案。有一个解决方案使用通道绑定将 TLS 密钥链接到 Kerberos，但在撰写本文时该解决方案尚未得到广泛实施（并且 mod_auth_kerb 不支持）。
\n| 归档时间： |
|
| 查看次数： |
8196 次 |
| 最近记录： |