过去配置过一次,有很多问题,但是最后似乎搞成了。
最近搞的时候又问题无数。所以还是要做个备忘,以免以后重蹈覆辙。
1. Apache的验证模块:mod_auth_kerb
地址:[url]http://modauthkerb.sourceforge.net/[/url]
此模块的问题:
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/mysite.example.com@EXAMPLE.COM。ktpass会自动加Domain。需为该映射设定一个密码,这个密码与用户原密码不同,kvno会做对应增加。type需要设定为KERBEROS_SRV_HST。
c. 在linux上测试该keytab
kinit -k -t keytabfile HTTP/mysite.example.com@EXAMPLE.COM
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
地址:[url]http://modauthkerb.sourceforge.net/[/url]
此模块的问题:
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/mysite.example.com@EXAMPLE.COM。ktpass会自动加Domain。需为该映射设定一个密码,这个密码与用户原密码不同,kvno会做对应增加。type需要设定为KERBEROS_SRV_HST。
c. 在linux上测试该keytab
kinit -k -t keytabfile HTTP/mysite.example.com@EXAMPLE.COM
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验证。
这个理想目前还无法实现(不过也许有商业软件已经实现了)。