Tomcat Windows身份验证：JNDIRealm不使用SPNEGO委派的凭据

Question

We have Tomcat 7.0.53 running on Linux, and we are trying to make Windows Authentication work as described here: https://tomcat.apache.org/tomcat-7.0-doc/windows-auth-howto.html#Tomcat_instance_%28Linux_server%29 .

SPNEGO alone works fine, it authenticate user quite well.

Then we have JNDIRealm connected with LDAP to fetch user roles, and that's where the problem arise.

After successful user authentication by SPNEGO we try to authenticate in JNDIRealm, and it seems like it don't use SPNEGO's delegated credentials, and auth fails. Moreover, when we try to use UserDatabaseRealm instead of JNDIRealm and set user with corresponding roles in tomcat-users.xml, this Realm won't use these credentials either, and auth fails again.

Catalina log says:

Apr 09, 2014 1:56:46 PM org.apache.catalina.realm.CombinedRealm authenticate
FINE: Attempting to authenticate user "username@DEFAULT.REALM.RU" with realm 
"org.apache.catalina.realm.JNDIRealm/1.0"
Apr 09, 2014 1:56:46 PM org.apache.catalina.realm.CombinedRealm authenticate
FINE: combinedRealm.authFail
    [Krb5LoginModule]: Entering logout
    [Krb5LoginModule]: logged out Subject

Our configuration files are listed below.

kr5.ini:

[logging]
    default = FILE:/var/lib/tomcat/logs/krb5libs.log
    kdc = FILE:/var/lib/tomcat/logs/krb5kdc.log
    admin_server = FILE:/var/lib/tomcat/logs/kadmind.log

[libdefaults]
    default_tkt_enctypes = aes128-cts rc4-hmac des3-cbc-sha1 des-cbc-md5 des-cbc-crc
    default_tgs_enctypes = aes128-cts rc4-hmac des3-cbc-sha1 des-cbc-md5 des-cbc-crc
    permitted_enctypes   = aes128-cts rc4-hmac des3-cbc-sha1 des-cbc-md5 des-cbc-crc
    default_realm = DEFAULT.REALM.RU

[realms]
    DEFAULT.REALM.RU = {
        kdc = dc01-one.default.realm.ru:88
        default_domain = DEFAULT.REALM.RU
    }

[domain_realm]
    .DEFAULT.REALM.RU = DEFAULT.REALM.RU
    .default.realm.ru = DEFAULT.REALM.RU
    default.realm.ru = DEFAULT.REALM.RU

jaas.conf:

com.sun.security.jgss.krb5.initiate {
    com.sun.security.auth.module.Krb5LoginModule required
    doNotPrompt=true
    principal="HTTP/appserver.default.realm.ru@DEFAULT.REALM.RU"
    useKeyTab=true
    keyTab="/var/lib/tomcat/conf/tomcat.keytab"
    storeKey=true
    debug=true;
};

com.sun.security.jgss.krb5.accept {
    com.sun.security.auth.module.Krb5LoginModule required
    doNotPrompt=true
    principal="HTTP/appserver.default.realm.ru@DEFAULT.REALM.RU"
    useKeyTab=true
    keyTab="/var/lib/tomcat/conf/tomcat.keytab"
    storeKey=true
    debug=true;
};

server.xml:

    <Realm className="org.apache.catalina.realm.JNDIRealm"
        debug="9"
        connectionURL="ldap://1.1.1.1:3268"
        connectionName="user_sys@default.realm.ru"
        connectionPassword="***"
        userBase="DC=****,DC=ru"
        userSearch="(&amp;(objectClass=user)(userPrincipalName={0}))"
        userRoleName="memberOf"
        userSubtree="true"
        roleBase="***"
        roleName="name"
        roleSubtree="true"
        roleSearch="(&amp;(objectClass=group)(member={0}))"
        referrals="follow"
        authentication="none"
        useDelegatedCredential="true"
        spnegoDelegationQop="auth"
        />
      </Realm>

Application context.xml:

<Valve 
    className="org.apache.catalina.authenticator.SpnegoAuthenticator"
    storeDelegatedCredential="true"
/>

Application web.xml:

<login-config>
    <auth-method>SPNEGO</auth-method>
</login-config>

When using FORM auth-method, JNDIRealm configuration (without last 3 parameters though - authentication, useDelegatedCredential and spnegoDelegationQop) work perfectly well

We tried to use SPNEGO SourceForge, with SPNEGO either as a HttpFilter or a Valve, but didn't succeed too.

Is anything in this configuration wrong? How can we make JNDIRealm use SPNEGO delegated credentials?

Answer 1

Solved this issue ourselves. The matter was in stripRealmForGss parameter of JNDIRealm - either omitting it (as in our case) or setting it to true made JNDIRealm try to connect to empty host. When we set stripRealmForGss="false", suddenly everything worked like a charm.