因此,我试图为AIX服务器(所以是IBM )实现一个SSO/。它使用Kerberos对AD进行身份验证。
请记住,下面的数据是消毒的。
命令我的AD管理员,用于在AD服务器上创建keytab文件(注意/kvno 2)。
ktpass /princ HTTP/local.domain.com@LOCALDOMAIN.NET /mapuser PSLDAP@LOCALDOMAIN.NET /pass <PASSWORD> /crypto ALL /ptype KRB5_NT_PRINCIPAL /kvno 2 /out krb5.keytab我的krb5.conf文件:
[libdefaults]
default_realm = LOCALDOMAIN.NET
default_keytab_name = FILE:/keytabs/krb.keytab
default_tkt_enctypes = rc4-hmac
default_tgs_enctypes = rc4-hmac
dns_lookup_kdc = true
dns_lookup_realm = true
[realms]
LOCALDOMAIN.NET = {
kdc = localdc08.localdomain.net:88
kdc = otherdc08.localdomain.net:88
admin_server = localdc08.localdomain.net:749
master_kdc = localdc08.localdomain.net
default_domain = LOCALDOMAIN.NET
}
[domain_realm]
.LOCALDOMAIN.NET = LOCALDOMAIN.NET
LOCALDOMAIN.NET = LOCALDOMAIN.NET
localdc08.localdomain.net = LOCALDOMAIN.NET
localdc08.localdomain.net = LOCALDOMAIN.NET
localdomain.net = LOCALDOMAIN.NET
.localdomain.net = LOCALDOMAIN.NET
[logging]
kdc = FILE:/var/krb5/log/krb5kdc.log
admin_server = FILE:/var/krb5/log/kadmin.log
kadmin_local = FILE:/var/krb5/log/kadmin_local.log
default = FILE:/var/krb5/log/krb5lib.log这是我的krb5Login.conf LoginModule:
krbServer {
com.ibm.security.auth.module.Krb5LoginModule required
credsType=acceptor
refreshKrb5Config=true
principal="HTTP/local.domain.com"
useKeytab="/keytabs/krb5.keytab"
debug=true;
};这里是我正在运行的java (不能公开整个事情,因为IP)
context = new LoginContext("krbServer");
context.login();
// Get server credentials
Subject sub = context.getSubject();
serverCred = Subject.doAs(sub, new PrivilegedExceptionAction<GSSCredential>() {
public GSSCredential run() throws GSSException {
// mechanism OID for SPNEGO authentication
Oid spnegoOid = new Oid("1.3.6.1.5.5.2");
// null name defaults to currently logged in name
GSSCredential cred = authManager.createCredential(null,
GSSCredential.INDEFINITE_LIFETIME,
spnegoOid,
GSSCredential.ACCEPT_ONLY);
return cred;
}
});
context.logout();当我调用上面的代码时,我得到以下调试输出:
Constructor With Arg: krbServer Version: 1.7.0 Home: /dev/jre
LoginContext Constructed
[JGSS_DBG_CRED] Thread-2 JAAS config: debug=true
[JGSS_DBG_CRED] Thread-2 JAAS config: principal=HTTP/local.domain.com
[JGSS_DBG_CRED] Thread-2 JAAS config: credsType=accept only
[JGSS_DBG_CRED] Thread-2 config: useDefaultCcache=false (default)
[JGSS_DBG_CRED] Thread-2 config: useCcache=null
[JGSS_DBG_CRED] Thread-2 config: useDefaultKeytab=false
[JGSS_DBG_CRED] Thread-2 config: useKeytab=/keytabs/krb5.keytab
[KRB_DBG_CFG] Config:Thread-2: ConfigFile: /etc/krb5/krb5.conf
[JGSS_DBG_CRED] Thread-2 JAAS config: forwardable=false (default)
[JGSS_DBG_CRED] Thread-2 JAAS config: renewable=false (default)
[JGSS_DBG_CRED] Thread-2 JAAS config: proxiable=false (default)
[JGSS_DBG_CRED] Thread-2 JAAS config: tryFirstPass=false (default)
[JGSS_DBG_CRED] Thread-2 JAAS config: useFirstPass=false (default)
[JGSS_DBG_CRED] Thread-2 JAAS config: moduleBanner=false (default)
[JGSS_DBG_CRED] Thread-2 JAAS config: interactive login? no
[JGSS_DBG_CRED] Thread-2 JAAS config: refreshKrb5Config = true
[KRB_DBG_CFG] Config:Thread-2: ConfigFile: /etc/krb5/krb5.conf
[KRB_DBG_KDC] KdcComm:Thread-2: >>> KdcAccessibility: reset
[KRB_DBG_KDC] KdcComm:Thread-2: >>> KdcAccessibility: reset
[JGSS_DBG_CRED] Thread-2 Try keytab for principal=HTTP/local.domain.com
[KRB_DBG_KTAB] KeyTab:Thread-2Loading the keytab file ... >>> KeyTab: load() entry length: 73
[KRB_DBG_KTAB] KeyTableInputStream:Thread-2: >>> KeyTabInputStream, readName(): LOCALDOMAIN.NET
[KRB_DBG_KTAB] KeyTableInputStream:Thread-2: >>> KeyTabInputStream, readName(): HTTP
[KRB_DBG_KTAB] KeyTableInputStream:Thread-2: >>> KeyTabInputStream, readName(): local.domain.com
[KRB_DBG_KDC] EncryptionKey:Thread-2: >>> EncryptionKey: config default key type is rc4-hmac
[KRB_DBG_KTAB] KeyTab:Thread-2: Added key: 23 version: 2
[KRB_DBG_KTAB] KeyTab:Thread-2: Ordering keys wrt default_tkt_enctypes list
[JGSS_DBG_CRED] Thread-2 No Kerberos creds in keytab for principal HTTP/local.domain.com
[JGSS_DBG_CRED] Thread-2 Login successful
[JGSS_DBG_CRED] Thread-2 kprincipal : HTTP/local.domain.com@LOCALDOMAIN.NET
[JGSS_DBG_CRED] Thread-2 HTTP/local.domain.com@LOCALDOMAIN.NET added to Subject
[JGSS_DBG_CRED] Thread-2 Attempting to add KeyTab to Subject for HTTP/local.domain.com@LOCALDOMAIN.NET
[JGSS_DBG_CRED] Thread-2 find keys for HTTP/local.domain.com@LOCALDOMAIN.NET
[KRB_DBG_KTAB] KeyTab:Thread-2: Added key: 23 version: 2
[KRB_DBG_KTAB] KeyTab:Thread-2: Ordering keys wrt default_tkt_enctypes list
[JGSS_DBG_CRED] Thread-2 No keys to add to Subject for HTTP/local.domain.com@LOCALDOMAIN.NET
LoginContext login() method executed
LoginContext getSubject() method executed
Subject doAs() method executed, serverCred Name: default Lifetime: 2147483647
[JGSS_DBG_CRED] Thread-2 KeyTab is removed from subject
[JGSS_DBG_CRED] Thread-2 KerberosKey Kerberos Principal HTTP/local.domain.com@LOCALDOMAIN.NETKey Version 2key EncryptionKey: keyType=23 keyBytes (hex dump)=
0000: <MASKED>当我打电话给
public String validate(String encToken) {
byte[] token = Base64.decode(encToken);
GSSContext authContext;
try {
authContext = authManager.createContext(serverCred);
authContext.acceptSecContext(token, 0, token.length);
if (authContext.isEstablished()) {
return authContext.getSrcName().toString();
}
} catch (GSSException e) {
// fall through to the return
}
return null;
}
}我发现在我的令牌上调用的"acceptSecContext“命令返回一个值。我的印象是,acceptSecContext只返回一个需要传递给启动器的值。但是,发起者并不期望返回响应。此外(更重要的是),.isEstablished()方法返回false。
所以我的问题是
( 1)上述设置是否有问题?
2)当我为上下文对象调用login()方法时,为什么会发生这种情况?
[JGSS_DBG_CRED] Thread-2 Attempting to add KeyTab to Subject for HTTP/local.domain.com@LOCALDOMAIN.NET
[JGSS_DBG_CRED] Thread-2 find keys for HTTP/local.domain.com@LOCALDOMAIN.NET
[KRB_DBG_KTAB] KeyTab:Thread-2: Added key: 23 version: 2
[KRB_DBG_KTAB] KeyTab:Thread-2: Ordering keys wrt default_tkt_enctypes list
[JGSS_DBG_CRED] Thread-2 No keys to add to Subject for HTTP/local.domain.com@LOCALDOMAIN.NET如果它找到了键23版本2,为什么它会说“主体@域没有要添加的键?为什么它没有添加它找到的密钥?它对kvno=2有问题吗?”
3)我已经搜索了相当详尽的内容,无法确定如何解析来自acceptSecContext的输出以找出返回值。我正在接收的返回值(基-64编码)是oQcwBaADCgEC。
编辑:更新。来自acceptSecContext十六进制值的返回值为: 0xA1 0x07 0x30 0x05 0xA 0x03 0x0A 0x01 0x02
它来自以下站点(topic2),即第一个十六进制值(A1)对应于NegTokenTarg。这事儿可以理解。
下一个八进制应该是长度(如果长度需要更多的八位数,则使用最上面的位1)。因为最上面的位是0,长度是7倍。检查完毕。
下一个八进制(0x30)表示一个已构造的序列,下一个八进制表示序列长度(0x05);5个八进制表示签出。
然后我们有0xA0,0x03,0x0A,0x01,它表示序列元素0 (negResult)。
最后一个八进制(0x02)是枚举值,它被“拒绝”。
所以我的令牌被拒绝了。我怎么弄明白“为什么”?我想我需要和广告团队接触,找出他们到底发生了什么。
发布于 2016-02-02 18:25:19
我已经为其他有类似问题的人发现了这个问题。
结果发现OID不起作用。
对用于检索服务器凭据的java代码进行以下更改,解决了这个问题:
serverCred = Subject.doAs(sub, new PrivilegedExceptionAction<GSSCredential>() {
public GSSCredential run() throws GSSException {
// mechanism OID for SPNEGO authentication
Oid spnegoOid = new Oid("1.3.6.1.5.5.2");
// null name defaults to currently logged in name
GSSCredential cred = authManager.createCredential(null,
GSSCredential.INDEFINITE_LIFETIME,
spnegoOid,
GSSCredential.ACCEPT_ONLY);
cred.add(null,
GSSCredential.INDEFINITE_LIFETIME,
GSSCredential.INDEFINITE_LIFETIME,
new Oid("1.2.840.113554.1.2.2"),
GSSCredential.ACCEPT_ONLY);
return cred;
}我认为这与我没有反复谈判(发起者和接受者)有关,所以SPNEGO从来没有机会告诉发起者它喜欢什么机制以及什么是可用的,但是我的印象是SPNEGO Oid会容纳许多不同的机制,所以这个工作对我来说有点不清楚,但它起了作用。
增编:经过进一步研究,我找到了对这个问题的模糊引用,原因是“AIX中GSSCredential实现中的某些功能”。所以你就有了。
发布于 2016-01-16 04:38:36
您试过手动测试kinit和SPN给出的keytab吗?同样在您的jaas.conf中,您可能会使用useKeyTab=true和keyTab="keytab_filename“。但这可能是IBM特有的东西。
https://stackoverflow.com/questions/34820956
复制相似问题