Intereting Posts

Stunnel：ssl到ssl HP Procurve 5406ZL – 如何启用端口镜像？ Exchange 2010 SSL证书错误我如何使用{}运算符在执行中查找执行为什么只有13个根服务器如何从磁盘恢复文件crc错误？ FreeBSD 8.1networking连接不稳定为什么我不能使用这个简单的configuration来访问我的samba共享？（CentOS 6）如何计算以太网NIC到NIC的时间来发送一个MTU数据包（1500字节）？（OS排除）有没有替代cgi / fastcgi x3550中的错误消息与在bios级别未检测到的硬盘有关谷歌的DNS和我的Linux服务器允许非特权UNIX / Linux用户查看系统日志信息的首选方法结果（中止）导航到门户网站时如何将Linode恢复到Vagrant VM？

在Win2008域中启用AESencryption的单点login到Apache

关于使用Active Directory身份validation设置单点login到Apache托pipe网站的所有教程，都可以通过configuration具有不安全设置的Kerberos来实现。现在最好的做法是在Active Directory中禁用Kerberos的RC4-HMACencryption ，但是很多教程都要求重写krb5.conf的默认设置，并使所有的工作都适用于RC4-HMAC。

我想尝试使用AES256encryption设置单点login，并且设法使其工作，所以我正在logging这个问题并回答任何其他谁想要更好的安全性的网站。

从RC4-HMAC开始

我们先从RC4-HMAC开始，因为这很容易。设置SSO的标准步骤从创build具有关联SPN的域帐户开始，浏览器将使用该帐户来获得encryption凭证以发送到服务器。对于这个例子，我的用户是REALM \ HostServiceAccount：

UPN：[email protected]（因此Kerberos主体名称为[email protected]）
servicePrincipalName属性（也可以由setspn设置）：HTTP / host.example.com; HTTP /主机（Kerberos：HTTP/[email protected]）
单独保留encryption设置; 默认情况下，这使得RC4-HMAC成为最强的encryption方式，所以来自域的票据将具有这种encryptionfunction

我们将下列条目添加到我们的目标服务器上的/etc/krb5.conf中：

[libdefaults] default_realm = REALM.COM [domain_realm] .realm.com = REALM.COM realm.com = REALM.COM

我们创buildkeytab并让服务器读取它：

 # ktutil ktutil: add_entry -password -p HTTP/[email protected] -k 1 -e rc4-hmac Password for HTTP/[email protected]: <enter password here> ktutil: write_kt /etc/apache2/service.keytab ktutil: q # chown -v www-data:root /etc/apache2/service.keytab # chmod -v 440 /etc/apache2/service.keytab

（在这一点上，当然，你会想要使用kinit -kt service.keytab -S HTTP/[email protected] [email protected]来testingkeytab。）

最后，我们设置Apache来使用我们的密钥表来authentication用户：

 KrbDelegateBasic off KrbAuthoritative on KrbMethodK5Passwd off Krb5Keytab /etc/apache2/service.keytab KrbAuthRealms REALM.COM LogLevel debug

在我们重新启动Apache之后，如果一切顺利，我们会从Windows域计算机向服务器发出请求，并在Apache错误日志中查看以下内容：

 [debug] src/mod_auth_kerb.c(1641): [client ****] kerb_authenticate_user entered with user (NULL) and auth_type Kerberos, referer: **** [debug] src/mod_auth_kerb.c(1395): [client ****] Verifying client data using KRB5 GSS-API , referer: **** [debug] src/mod_auth_kerb.c(1411): [client ****] Client didn't delegate us their credential, referer: **** [debug] src/mod_auth_kerb.c(1430): [client ****] GSS-API token of length 185 bytes will be sent back, ****

在我们的客户端机器上运行klist（或Wireshark查看请求中的票据），我们看到确实已经使用RC4-HMAC票证进行身份validation：

 #4> Client: fluggo @ REALM.COM Server: HTTP/host.example.com @ REALM.COM KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)

向上移动到更好的encryption

一切都很好，但是，这不是我们的目标。 RC4-HMAC被认为是不安全的，所以让我们禁用它，并尝试使用AES256进行相同的设置工作。

首先，我们要求我们友好的邻居域pipe理员在REALM \ HostServiceAccount上启用高级encryption，这将是两个checkbox，分别标记为：

此帐户支持Kerberos AES 128位encryption
此帐户支持Kerberos AES 256位encryption

这些出现在不同的地方取决于你使用的工具; 最终结果应该是，msDS-SupportedEncryptionTypes的LDAP属性应该是0x18或十进制24，这表示只支持AES128和AES256。

为了达到这个效果，我们将杀死我们的本地客户机票：

 C:>klist purge Current LogonId is 0:0xdeadbeef Deleting all tickets: Ticket(s) purged!

如果我们再次执行请求，我们会看到请求失败，但是我们已经获得了更新的票证：

 C:>klist ... #3> Client: fluggo @ REALM.COM Server: HTTP/host.example.com @ REALM.COM KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96

现在我们只需要用新的algorithm更新我们的keytab，我们应该是黄金的：

 # mv /etc/apache2/service.keytab ~/old.keytab # ktutil ktutil: add_entry -password -p HTTP/[email protected] -k 1 -e aes256-cts-hmac-sha1-96 Password for HTTP/[email protected]: <enter password here> ktutil: add_entry -password -p HTTP/[email protected] -k 1 -e aes128-cts-hmac-sha1-96 Password for HTTP/[email protected]: <enter password here> ktutil: write_kt /etc/apache2/service.keytab ktutil: q # chown -v www-data:root /etc/apache2/service.keytab # chmod -v 440 /etc/apache2/service.keytab

我们甚至不需要重启Apache。只需重新提交请求。

糟糕…它不起作用。如果我们看Apache的错误日志，我们看到：

 [debug] src/mod_auth_kerb.c(1641): [client ****] kerb_authenticate_user entered with user (NULL) and auth_type Kerberos [debug] src/mod_auth_kerb.c(1249): [client ****] Acquiring creds for [email protected] [debug] src/mod_auth_kerb.c(1395): [client ****] Verifying client data using KRB5 GSS-API [debug] src/mod_auth_kerb.c(1411): [client ****] Client didn't delegate us their credential [debug] src/mod_auth_kerb.c(1430): [client ****] GSS-API token of length 9 bytes will be sent back [debug] src/mod_auth_kerb.c(1110): [client ****] GSS-API major_status:000d0000, minor_status:000186a5 [error] [client ****] gss_accept_sec_context() failed: Unspecified GSS failure. Minor code may provide more information (, )

那么这是一个荒谬无益的错误信息，但是出了什么问题呢？答案和一个解决scheme，遵循！

事实certificate，这里的主要问题是AES256打算解决的问题之一。

TL; DR ：keytab中的主体名称现在需要与帐户名称匹配。

问题

如果我们运行KRB5_TRACE=/dev/stderr kinit [email protected]当帐户启用了RC4-HMACencryption时，我们会在输出中看到以下行：

 [8192] 1441829478.537451: Selected etype info: etype rc4-hmac, salt "", params ""

现在我们已经启用了AES256，但是，该行看起来像这样：

 [8200] 1441829508.947208: Selected etype info: etype aes256-cts, salt "REALM.COMHostServiceAccount", params ""

当交换机从NTLMauthentication到Kerberos时，指定了RC4-HMACalgorithm来重新使用NTLM散列。微软拒绝在哈希中join一个salt，以使现有系统能够更容易地与Kerberos进行互操作。现在用户有升级的机会，为AES256和AES128algorithm指定一个salt，salt是用户名。

如果我们使用不同的用户名为RC4-HMAC和AES256生成密钥表，我们可以看到这一点。用RC4-HMAC：

 fluggo@host:~$ ktutil ktutil: add_entry -password -p HTTP/[email protected] -k 1 -e rc4-hmac Password for HTTP/[email protected]: 12345 ktutil: add_entry -password -p [email protected] -k 1 -e rc4-hmac Password for [email protected]: 12345 ktutil: write_kt rc4.keytab ktutil: q fluggo@host:~$ klist -Kek rc4.keytab Keytab name: FILE:rc4.keytab KVNO Principal ---- -------------------------------------------------------------------------- 1 HTTP/[email protected] (arcfour-hmac) (0x7a21990fcd3d759941e45c490f143d5f) 1 [email protected] (arcfour-hmac) (0x7a21990fcd3d759941e45c490f143d5f)

哈希是一样的，所以这两个条目是等价的。但是用AES256：

 fluggo@host:~$ ktutil ktutil: add_entry -password -p HTTP/[email protected] -k 1 -e aes256-cts-hmac-sha1-96 Password for HTTP/[email protected]: 12345 ktutil: add_entry -password -p [email protected] -k 1 -e aes256-cts-hmac-sha1-96 Password for [email protected]: 12345 ktutil: write_kt aes.keytab ktutil: q fluggo@host:~$ klist -Kek aes.keytab Keytab name: FILE:aes.keytab KVNO Principal ---- -------------------------------------------------------------------------- 1 HTTP/[email protected] (aes256-cts-hmac-sha1-96) (0x5746fa6f9b0c990ba7fb20acd85065040d66e843a043508569841768ef2b7917) 1 [email protected] (aes256-cts-hmac-sha1-96) (0x6a98fdccbce4db77f40192f4e916e0900a1b9cba2f6ca8bc737d968e4b961c25)

哈希是不一样的主要名称很重要，它需要匹配帐户的UPN。

一个办法

由于用户名必须正确才能使密钥表生效，因此我们生成一个新的密钥表，其中包含活动目录在证书上使用的主体名称：

 # rm /etc/apache2/service.keytab # ktutil ktutil: add_entry -password -p [email protected] -k 1 -e aes256-cts-hmac-sha1-96 Password for [email protected]: <enter password here> ktutil: add_entry -password -p [email protected] -k 1 -e aes128-cts-hmac-sha1-96 Password for [email protected]: <enter password here> ktutil: write_kt /etc/apache2/service.keytab ktutil: q # chown -v www-data:root /etc/apache2/service.keytab # chmod -v 440 /etc/apache2/service.keytab

Apache关心keytab中的主体名称，所以它不会自己find这些条目。相反，我们只是指示Apache使用任何可以find的工作主体：

 KrbServiceName Any

我希望Apache能够用正确的名字find委托人，但是这并不重要，因为我们的委托人是唯一的委托人。

重新启动Apache，刷新页面，身份validation应该现在工作。