|
此版本仍在开发中，尚不被认为是稳定的。对于最新的稳定版本，请使用 Spring Security Kerberos 2.2.0！ |
附录
附录 A：本文档中使用的材料
Dummy UserDetailsService 在示例中使用，因为我们没有真正的 用户来源。
public class DummyUserDetailsService implements UserDetailsService {
@Override
public UserDetails loadUserByUsername(String username)
throws UsernameNotFoundException {
return new User(username, "notUsed", true, true, true, true,
AuthorityUtils.createAuthorityList("ROLE_USER"));
}
}附录 B：Kerberos 速成课程
在任何身份验证过程中，通常都有三方 涉及。
首先是client有时是客户端计算机，但在大多数情况下
在场景中，它是坐在计算机上的实际用户，并且
尝试访问资源。然后是resource用户正在尝试
访问。在本例中，它是一个 Web 服务器。
然后是Key Distribution Center或KDC.在以下情况下
Windows 环境这将是一个Domain Controller.KDC是
一个真正将所有东西结合在一起的人，因此是最多的
环境中的关键组件。正因为如此，它也是
被视为单点故障。
最初Kerberos环境是设置和域用户
创建到数据库中的主体，加密密钥也是
创建。这些加密密钥基于共享密钥（即用户
password）和实际密码永远不会以明文形式保存。
有效KDC为域用户提供自己的密钥和其他密钥。
有趣的是，一个resource和KDC在身份验证过程中。
当客户端想要使用resource它首先
需要与KDC.Client将制作一个特殊的包装
其中包含加密和未加密的部分。未加密部分
包含有关用户和加密部分的信息
作为协议一部分的信息。Client将加密包
data 具有自己的键。
什么时候KDC从客户端接收此身份验证包
检查谁client声称来自未加密的部分，并且基于
根据它使用的信息client解密密钥
它的数据库。如果解密成功KDC知道这client就是它声称的那个。
KDC 返回给客户端的是名为Ticket Granting
Ticket由 KDC 自己的私钥签名。后来client发回此票证，它可以尝试解密它，如果
作成功了，它知道它本身就是一张票
最初签名并赠送给client.
当客户端想要获取可用于身份验证的票证时
通过服务，TGT被发送到KDC然后签署服务票证
使用服务自己的密钥。这是一个信任之间的时刻client和service被创建。此服务票证包含数据
这只是service本身能够解密。
什么时候client正在使用它之前发送的服务进行身份验证
收到服务票到一项服务，然后认为我没有
对这个人一无所知，但他给了我一张认证票。
什么service接下来可以做的是尝试解密该票证，如果
作成功，它知道只有知道我的另一方
credentials 是KDC因为我信任他，所以我也可以信任他
这个客户就是他声称的客户。
附录 C：设置 Kerberos 环境
执行 Kerberos 环境的生产设置超出了 本文档但本附录为您提供了一些帮助 开始设置开发所需的组件。
设置 MIT Kerberos
第一个动作是建立一个新的领域和一个数据库。
# kdb5_util create -s -r EXAMPLE.ORG
Loading random data
Initializing database '/var/lib/krb5kdc/principal' for realm 'EXAMPLE.ORG',
master key name 'K/[email protected]'
You will be prompted for the database Master Password.
It is important that you NOT FORGET this password.
Enter KDC database master key:
Re-enter KDC database master key to verify:kadmin命令可用于管理 Kerberos 环境，但您还不能使用它，因为数据库中没有管理员用户。
root@neo:/etc/krb5kdc# kadmin
Authenticating as principal root/[email protected] with password.
kadmin: Client not found in Kerberos database while initializing
kadmin interface让我们使用kadmin.local命令创建一个。
root@neo:/etc/krb5kdc# kadmin.local
Authenticating as principal root/[email protected] with password.
kadmin.local: listprincs
K/[email protected]
kadmin/[email protected]
kadmin/[email protected]
kadmin/[email protected]
krbtgt/[email protected]
kadmin.local: addprinc root/[email protected]
WARNING: no policy specified for root/[email protected]; defaulting to
no policy
Enter password for principal "root/[email protected]":
Re-enter password for principal "root/[email protected]":
Principal "root/[email protected]" created.然后通过修改启用管理员kadm5.acl文件并重新启动 Kerberos 服务业。
# cat /etc/krb5kdc/kadm5.acl
# This file Is the access control list for krb5 administration.
*/admin *现在您可以使用kadmin与之前创建的root/admin主要。 让我们创建我们的第一个用户user1.
kadmin: addprinc user1
WARNING: no policy specified for [email protected]; defaulting to no
policy
Enter password for principal "[email protected]":
Re-enter password for principal "[email protected]":
Principal "[email protected]" created.让我们创建第二个用户user2并导出 keytab 文件。
kadmin: addprinc user2
WARNING: no policy specified for [email protected]; defaulting to no
policy
Enter password for principal "[email protected]":
Re-enter password for principal "[email protected]":
Principal "[email protected]" created.
kadmin: ktadd -k /tmp/user2.keytab [email protected]
Entry for principal [email protected] with kvno 2, encryption type aes256-cts-hmac-sha1-96 added to keytab WRFILE:/tmp/user2.keytab.
Entry for principal [email protected] with kvno 2, encryption type arcfour-hmac added to keytab WRFILE:/tmp/user2.keytab.
Entry for principal [email protected] with kvno 2, encryption type des3-cbc-sha1 added to keytab WRFILE:/tmp/user2.keytab.
Entry for principal [email protected] with kvno 2, encryption type des-cbc-crc added to keytab WRFILE:/tmp/user2.keytab.让我们为 tomcat 创建服务票证并将凭据导出到
名为tomcat.keytab.
kadmin: addprinc -randkey HTTP/[email protected]
WARNING: no policy specified for HTTP/[email protected];
defaulting to no policy
Principal "HTTP/[email protected]" created.
kadmin: ktadd -k /tmp/tomcat.keytab HTTP/[email protected]
Entry for principal HTTP/[email protected] with kvno 2, encryption type aes256-cts-hmac-sha1-96 added to keytab WRFILE:/tmp/tomcat2.keytab.
Entry for principal HTTP/[email protected] with kvno 2, encryption type arcfour-hmac added to keytab WRFILE:/tmp/tomcat2.keytab.
Entry for principal HTTP/[email protected] with kvno 2, encryption type des3-cbc-sha1 added to keytab WRFILE:/tmp/tomcat2.keytab.
Entry for principal HTTP/[email protected] with kvno 2, encryption type des-cbc-crc added to keytab WRFILE:/tmp/tomcat2.keytab.设置 Windows 域控制器
这是使用Windows Server 2012 R2
|
互联网上到处都是关于如何设置 Windows AD 的好文章和视频 但这两个还是挺用的 Rackspace 和 Microsoft 技术网。 |
-
已完成正常的域控制器和 Active Directory 设置。
-
使用过的 DNS 域
example.org和 Windows 域EXAMPLE. -
我创建了各种域用户，例如
user1,user2,user3,tomcat并将密码设置为Password#.
最终，我还将我的虚拟机的所有 IP 添加到 AD 的 DNS 服务器中，以便 不要造成任何麻烦。
Name: WIN-EKBO0EQ7TS7.example.org
Address: 172.16.101.135
Name: win8vm.example.org
Address: 172.16.101.136
Name: neo.example.org
Address: 172.16.101.1服务主体名称 （SPN） 需要使用HTTP和
服务器名称neo.example.org其中运行 Tomcat Servlet 容器。这
与tomcat域用户及其keytab然后用作
服务凭证。
PS C:\> setspn -A HTTP/neo.example.org tomcat我导出了复制到运行 tomcat 的 linux 服务器的 keytab 文件。
PS C:\> ktpass /out c:\tomcat.keytab /mapuser [email protected] /princ HTTP/[email protected] /pass Password# /ptype KRB5_NT_PRINCIPAL /crypto All
Targeting domain controller: WIN-EKBO0EQ7TS7.example.org
Using legacy password setting method
Successfully mapped HTTP/neo.example.org to tomcat.附录 D：故障排除
本附录提供有关故障排除的一般信息 错误和问题。
|
如果您认为环境和配置设置正确，请执行 仔细检查并要求其他人检查可能的明显错误 或拼写错误。Kerberos 设置通常非常脆弱，但事实并非如此 总是很容易调试问题所在的地方。 |
GSSException: Failure unspecified at GSS-API level (Mechanism level:
Invalid argument (400) - Cannot find key of appropriate type to
decrypt AP REP - RC4 with HMAC)如果您看到指示缺少键类型的 abore 错误，则会发生这种情况
具有两种不同的用例。首先，您的 JVM 可能不支持
适当的加密类型，或者它在您的krb5.conf文件。
default_tkt_enctypes = rc4-hmac
default_tgs_enctypes = rc4-hmac第二种情况不太明显且难以追踪，因为它会导致
进入相同的错误。这个特定的GSSException如果您根本没有所需的加密密钥，这可能是由于 Kerberos 服务器中的配置错误或您的拼写错误 主要。
在大多数系统中，所有命令和库都会搜索 kerberos 从默认位置或特殊位置进行配置 就像 JDK 一样。很容易混淆，尤其是在使用 unix 时 系统，这些系统可能已经具有与 MIT 配合使用的默认设置 kerberos，指向 Windows 域。
这是一个具体的例子，发生的情况是ldapsearch尝试
使用 Kerberos 身份验证查询 Windows AD。
$ ldapsearch -H ldap://WIN-EKBO0EQ7TS7.example.org -b "dc=example,dc=org"
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Local error (-2)
additional info: SASL(-1): generic failure: GSSAPI Error:
Unspecified GSS failure. Minor code may provide more information
(No Kerberos credentials available)好吧，这看起来不太好，只是一个简单的迹象，表明我不喜欢 具有有效的 Kerberos 票证，如下所示。
$ klist
klist: Credentials cache file '/tmp/krb5cc_1000' not found我们已经有一个从 Windows AD 导出的键表文件可供使用 与在 Linux 上运行的 tomcat。让我们尝试使用它来进行身份验证 使用 Windows AD。
您可以有一个专用的配置文件，通常可以与 通过系统属性的本机 Linux 命令和 JVM。
$ cat krb5.ini
[libdefaults]
default_realm = EXAMPLE.ORG
default_keytab_name = /tmp/tomcat.keytab
forwardable=true
[realms]
EXAMPLE.ORG = {
kdc = WIN-EKBO0EQ7TS7.example.org:88
}
[domain_realm]
example.org=EXAMPLE.ORG
.example.org=EXAMPLE.ORG让我们使用该配置和键表来获取初始凭据。
$ env KRB5_CONFIG=/path/to/krb5.ini kinit -kt tomcat.keytab HTTP/[email protected]
$ klist
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: HTTP/[email protected]
Valid starting Expires Service principal
26/03/15 09:04:37 26/03/15 19:04:37 krbtgt/[email protected]
renew until 27/03/15 09:04:37让我们看看如果我们现在尝试对 Windows 广告。
$ ldapsearch -H ldap://WIN-EKBO0EQ7TS7.example.org -b "dc=example,dc=org"
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Local error (-2)
additional info: SASL(-1): generic failure: GSSAPI Error:
Unspecified GSS failure. Minor code may provide more information
(KDC returned error string: PROCESS_TGS)这可能仅仅是因为ldapsearch越来越困惑，简单
使用错误的配置。你可以看出ldapsearch使用
通过不同的配置KRB5_CONFIGenv 变量，就像我们一样
做过kinit.您还可以使用KRB5_TRACE=/dev/stderr获取
本机库正在做什么的更详细的输出。
$ env KRB5_CONFIG=/path/to/krb5.ini ldapsearch -H ldap://WIN-EKBO0EQ7TS7.example.org -b "dc=example,dc=org"
$ klist
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: HTTP/[email protected]
Valid starting Expires Service principal
26/03/15 09:11:03 26/03/15 19:11:03 krbtgt/[email protected]
renew until 27/03/15 09:11:03
26/03/15 09:11:44 26/03/15 19:11:03
ldap/[email protected]
renew until 27/03/15 09:11:03在上面，您可以通过查看查询成功时会发生什么
Kerberos 票证。现在，您可以尝试进一步的查询命令
即，如果您使用KerberosLdapContextSource.
$ ldapsearch -H ldap://WIN-EKBO0EQ7TS7.example.org \
-b "dc=example,dc=org" \
"(| ([email protected])
([email protected]))" \
dn
...
# test user, example.org
dn: CN=test user,DC=example,DC=org附录 E：配置浏览器以进行 Spnego 协商
火狐
完成以下步骤以确保您的 Firefox 浏览器是 启用以执行 Spnego 身份验证。
-
打开 Firefox。
-
在地址字段中，键入 about：config。
-
在筛选器/搜索中，键入 negotiate。
-
参数 network.negotiate-auth.trusted-uris 可以设置为 默认 https://，这对你不起作用。一般而言 如果 Kerberos 需要授权。
-
建议使用
https用于所有通信。
铬
使用 Google Chrome，您通常需要设置命令行参数 命令将与 Chrome 协商的服务器列入白名单。
-
在 Windows 计算机（客户端）上：Chrome 与 Internet Explorer，因此如果所有更改都应用于 IE（如所述） 在 E.3 中），无需通过命令行参数传递任何内容。
-
在 Linux/Mac OS 计算机（客户端）上：命令行参数
--auth-negotiate-delegate-whitelist仅当 Kerberos delegation 是必需的（否则不要设置此参数）。 -
建议使用
https用于所有通信。
--auth-server-whitelist="*.example.com"
--auth-negotiate-delegate-whitelist="*.example.com"您可以通过在 Chrome 的地址栏中输入 chrome://policy/ 来查看启用了哪些策略。
在 Linux 中，Chrome 还将从/etc/opt/chrome/policies/managed目录。
{
"AuthServerWhitelist" : "*.example.org",
"AuthNegotiateDelegateWhitelist" : "*.example.org",
"DisableAuthNegotiateCnameLookup" : true,
"EnableAuthNegotiatePort" : true
}