Apache与SPNEGO备忘
过去配置过一次，有很多问题，但是最后似乎搞成了。
最近搞的时候又问题无数。所以还是要做个备忘，以免以后重蹈覆辙。
1. Apache的验证模块：mod_auth_kerb
地址： http://modauthkerb.sourceforge.net/
此模块的问题：
a. 这个模块支持HTTP Negotiation验证（即SPNEGO），但是不支持NTLM只支持Kerberos。而IE似乎在某种情况下会返回NTLM，所以自动的Negotiation验证就会失败（此问题待考）。FF完全按照config所设的来，所以没有问题。
b. 如果Negotiation失败，可以用HTTP Basic验证。但是Basic验证很不安全，必须和HTTPS结合使用。本模块只支持Basic，不支持其他备选的验证方式。Basic验证也可关闭。
c. 如果失败，可以将验证委托给其他模块，但没有试验过，可能需要自己编程。
d. 错误信息不友好，常让人不明所以。
e. 它仅仅是一个验证模块，并不会记录cookie/session来保持验证信息，所以每次访问都会有一次401。
Solaris另有一个模块也支持Negotiation，与前者稍有不同，没有用过，不述。
2. Linux使用Windows Domain作为Kerberos服务器
a. linux上配置/etc/krb5.conf，通常直接设domain就可以了，会根据DNS自动寻找kdc服务器。
b. 时间要同步。最好将domain controller作为ntp服务器。
c. 测试命令：
kinit
kvno
kdestroy
klist
3. 从Windows Domain中导出Kerberos所需的keytab
a. 在domain中建立一个用户，表示一项服务。
b. 到domain controller上用命令行，使用ktpass.exe导出keytab。
注意：Windows 2003 sp1的ktpass有bug（shit M$），导致导出的keytab密码不对！需改用Windows 2003 sp2的ktpass。
ktpass可将用户映射为一个serviceprincipalname，格式为service/fqdn@DOMAIN。对于mod_auth_kerb来说，默认前缀为HTTP。所以假设domain为EXAMPLE.COM（Domain都是全大写的），site的fqdn为mysite.example.com（域名为小写的，并且必须是完全域名），则princ为：HTTP/[email protected]。ktpass会自动加Domain。需为该映射设定一个密码，这个密码与用户原密码不同，kvno会做对应增加。type需要设定为KERBEROS_SRV_HST。
c. 在linux上测试该keytab
kinit -k -t keytabfile HTTP/[email protected]
4. 配置apache的conf文件
略
5. 验证过程需要对上域名，所以
a. 要使用fqdn，如果是CNAME要使用最后的name。
b. 需要PTR记录，从IP指回fqdn。
c. 如无PTR，或许可以在linux上写上hosts文件，内容为IP对应fqdn。
结论：
确实挺烦。而且灵活性不够，比如我怎样只为内网（hostname不含完整域名后缀）启用kerb，而外网用其他验证模式？设成几个vhost有点太过。Basic不安全。每次都401浪费。
当前目标：找一个纯Java的解决方案，然后最好能很灵活的配置。
可以根据条件（如hostname、port、来源IP、时段等）设定不同的验证方案。
可以顺序发出几个不同的auth候选：
Negotiation
Kerberos
NTLM
Digest
Basic
可以选择其中几种，也可以去掉最后的Digest/Basic改转为form-based验证。
这个理想目前还无法实现（不过也许有商业软件已经实现了）。
最近搞的时候又问题无数。所以还是要做个备忘，以免以后重蹈覆辙。
1. Apache的验证模块：mod_auth_kerb
地址： http://modauthkerb.sourceforge.net/
此模块的问题：
a. 这个模块支持HTTP Negotiation验证（即SPNEGO），但是不支持NTLM只支持Kerberos。而IE似乎在某种情况下会返回NTLM，所以自动的Negotiation验证就会失败（此问题待考）。FF完全按照config所设的来，所以没有问题。
b. 如果Negotiation失败，可以用HTTP Basic验证。但是Basic验证很不安全，必须和HTTPS结合使用。本模块只支持Basic，不支持其他备选的验证方式。Basic验证也可关闭。
c. 如果失败，可以将验证委托给其他模块，但没有试验过，可能需要自己编程。
d. 错误信息不友好，常让人不明所以。
e. 它仅仅是一个验证模块，并不会记录cookie/session来保持验证信息，所以每次访问都会有一次401。
Solaris另有一个模块也支持Negotiation，与前者稍有不同，没有用过，不述。
2. Linux使用Windows Domain作为Kerberos服务器
a. linux上配置/etc/krb5.conf，通常直接设domain就可以了，会根据DNS自动寻找kdc服务器。
b. 时间要同步。最好将domain controller作为ntp服务器。
c. 测试命令：
kinit
kvno
kdestroy
klist
3. 从Windows Domain中导出Kerberos所需的keytab
a. 在domain中建立一个用户，表示一项服务。
b. 到domain controller上用命令行，使用ktpass.exe导出keytab。
注意：Windows 2003 sp1的ktpass有bug（shit M$），导致导出的keytab密码不对！需改用Windows 2003 sp2的ktpass。
ktpass可将用户映射为一个serviceprincipalname，格式为service/fqdn@DOMAIN。对于mod_auth_kerb来说，默认前缀为HTTP。所以假设domain为EXAMPLE.COM（Domain都是全大写的），site的fqdn为mysite.example.com（域名为小写的，并且必须是完全域名），则princ为：HTTP/[email protected]。ktpass会自动加Domain。需为该映射设定一个密码，这个密码与用户原密码不同，kvno会做对应增加。type需要设定为KERBEROS_SRV_HST。
c. 在linux上测试该keytab
kinit -k -t keytabfile HTTP/[email protected]
4. 配置apache的conf文件
略
5. 验证过程需要对上域名，所以
a. 要使用fqdn，如果是CNAME要使用最后的name。
b. 需要PTR记录，从IP指回fqdn。
c. 如无PTR，或许可以在linux上写上hosts文件，内容为IP对应fqdn。
结论：
确实挺烦。而且灵活性不够，比如我怎样只为内网（hostname不含完整域名后缀）启用kerb，而外网用其他验证模式？设成几个vhost有点太过。Basic不安全。每次都401浪费。
当前目标：找一个纯Java的解决方案，然后最好能很灵活的配置。
可以根据条件（如hostname、port、来源IP、时段等）设定不同的验证方案。
可以顺序发出几个不同的auth候选：
Negotiation
Kerberos
NTLM
Digest
Basic
可以选择其中几种，也可以去掉最后的Digest/Basic改转为form-based验证。
这个理想目前还无法实现（不过也许有商业软件已经实现了）。