tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject [Bug 61977] New: JNDIRealm with SPNEGO, GSSAPI and SRV record fails to find LDAP SPN due to training sname period
Date Tue, 09 Jan 2018 02:12:35 GMT
https://bz.apache.org/bugzilla/show_bug.cgi?id=61977

            Bug ID: 61977
           Summary: JNDIRealm with SPNEGO, GSSAPI and SRV record fails to
                    find LDAP SPN due to training sname period
           Product: Tomcat 8
           Version: 8.5.20
          Hardware: PC
            Status: NEW
          Severity: blocker
          Priority: P2
         Component: Catalina
          Assignee: dev@tomcat.apache.org
          Reporter: marian.romascanu@nuance.com
  Target Milestone: ----

SPNEGO and JNDIRealm are integrated in catalina core library. 
The web application is using Kerberos SSO using SPNEGO and JNDIRealm.
The application requires using hostname-independent LDAP URLs in the JNDIRealm
configuration. This is done (e.g.) using a construct based on SRV records
similar to the following domain-based construct:
  <Realm className="org.apache.catalina.realm.JNDIRealm"
        connectionURL="ldap:///dc=testdomain,dc=example,dc=org"
   ...
The ldap:///dc=testdomain,dc=example,dc=org construct is internally resolved
into a query against a SRV record exposed by the DNS server (AD in this case):
_ldap._tcp.testdomain.example.org

This is visible in the wireshark trace of the transaction and in the logs.

The query return several valid hostnames corresponding to one of several Domain
Controllers and Tomcat JNDIREalm would chose one, e.g.:

dc1.testdomain.example.org IN A 1.2.3.4

In the DNS 

However when the JNDIREalm logic tries first to get a Kerberos ticket for the
GSSAPI/SASL protocol, it issues a TGS-REQ containing the DNS-returned hostname
plus a trailing dot as illustrated below in a trace excerpt. 

tgs-req
...
sname-string: 2 items
    SNameString: ldap
    SNameString: dc1.testdomain.example.org.

As a result the LDAP SPN is not found (KDC_ERR_PRINCIPAL_UNKNOWN) - the SPN
defined in AD is ldap/dc1.testdomain.example.org  w/o the trailing dot.

The issue is reported as originating in a JDK core library:
https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8149521
However the issue is being marked as resolved in JDK 8u152 - however fixed not
in the JNDI "servicelocator" but apparently at the Kerberos level - the krb5
component in the Java core runtime library, which is not being used by
Catalina.  Tests with Tomcat 8.20 and JRE 8u152 show the issue is still there.

There is a need for a bug fix in the catalina JNDIRealm for stripping the
trailing dot, if any, before attempting the LDAP SPN resolution.

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message