No, I've gotten it working with Tomcat 5.5 before... Hard to say where to look, but if you're not seeing the Kerberos exchange happening at all, here are a couple places to look:
- your principal needs to match the server name you're using to hit the site (if your site is "my.site.com", the principal needs to be "HTTP/my.site.com@ SITE.COM") - the app server needs to know to use the Krb5LoginModule (seems to vary by app server) - you might want to try adding the JAVA_OPTS I mentioned for JBoss (in runjboss.sh) to your Tomcat startup script (probably in catalina.sh, methinks) - finally, the dreaded AD configuration that we keep coming back to... here's a weird little tidbit (though by no means the only trouble I've had in the past with this piece): we've only been able to get this working using one AD account per SPN / principal. If we try to (or accidentally) map another SPN to the same AD account, it just silently stops working on the associated server(s). What makes matters worse is there seems to be no way to undo the damage after that (disassociate an SPN from an account -- even by deleting the account), and I've actually had to change a server's DNS name to get a "fresh" account and SPN before it started working. It might help if you could post a more complete Tomcat log so we can see what happens when you hit the server, and also the output of doing: klist -k ...and: kinit -V -k -t myspnaccount.keytab HTTP/[email protected] Good luck! - Bill On Thu, Oct 14, 2010 at 5:03 PM, Brian C. Hill <[email protected]> wrote: > Hi Bill, > > Unfortunately, I have not sorted it out. > > I'm using tomcat 5.5.23 from the tomcat5 rpm bundled with CentOS 5 (which > bundles the jpp tomcat 5 rpm). > > Is there some reason that this should _not_ be done in tomcat? > > Thanks for the follow-up! > > Brian > > > On 10/14/2010 10:24 AM, William Markmann wrote: > > Brian, > > Not sure if you've sorted this out or not, but I was just setting up > another server with this same basic configuration and thought of something > else... I'm not sure if you've said which application server you're using, > but this applies to JBoss. > > It's mentioned in the user manual that for JBoss you need to edit > login-config.xml. I'd done that, but still wasn't getting a Kerberos > exchange to happen when I hit my server. It started working when I went > back and added the following to bin/runjboss.sh: > > JAVA_OPTS=...[snip]...-Djava.security.krb5.conf=/opt/myapp/krb5.conf > -Dsun.security.krb5.debug=true > -Djava.security.krb5.realm=MYREALM.COM-Djava.security.krb5.kdc= > mykdc.mydomain.com > > I don't remember how I settled on that particular mix of flags, but > that's what I had on my other working servers. After adding that and > restarting JBoss, I started seeing Kerberos exchanges happening properly. > Hope that helps. > > - Bill > > On Mon, Oct 11, 2010 at 12:43 AM, Brian C. Hill <[email protected]> wrote: > >> Hi Scott, et al, >> >> Sorry for the long delay. >> >> Some of you have mentioned that the problem I'm having probably has to do >> with a credential problem between CAS and AD, but I don't even see traffic >> going to the AD, which makes me think something else is wrong (though I >> won't be surprised if CAS<->AD winds up being the next show-stopper). >> >> I've attached the login-webflow.xml file. >> >> Thanks for your help! >> >> Brian >> >> >> >> On 10/4/2010 6:52 PM, Scott Battaglia wrote: >> >> Can you also attach your webflow? I'm not a SPNEGO expert but maybe >> between all of us on the list, we can help :-) >> >> Thanks >> Scott >> >> >> On Mon, Oct 4, 2010 at 9:41 PM, Brian C. Hill <[email protected]> wrote: >> >>> Hello, >>> >>> I have to admit that with all of the reports of how easy this was to set >>> up for all of you, I am surprised that I am having the opposite experience: >>> too many files, too many components, too many players (kerberos, SSL >>> required between CAS client and CAS server, ldap, java, tomcat/jboss, >>> spnego, AD, etc..). >>> >>> I suppose the biggest frustration is that even with everything set to >>> debug, I don't really see any specific errors except for maybe this one: >>> >>> * 2010-10-05 00:47:46,518 DEBUG >>> [org.jasig.cas.support.spnego.web.flow.SpnegoNegociateCredentialsAction] - >>> Authorization header not found. Sending WWW-Authenticate header >>> * >>> I do have LDAP auth working, but ... >>> >>> I don't have SPNEGO working. I've tested it with both Firefox and I.E. I >>> try connecting to a simple web page set up with mod_auth_cas, which >>> redirects to CAS to get a ticket, which I can get with LDAP auth. But with >>> SPNEGO, it seems that the windows credentials from my current login (yes, >>> same AD) don't get passed to the site and I still get redirected to the CAS >>> server, which will then not authenticate me: >>> >>> * The credentials you provided are not supported by CAS >>> >>> *With a tcpdump, I don't see the simple web page ask the cas server to >>> validate the ticket being presented to it by the browser - I guess that >>> means that it isn't getting any such credentials from the browser, which >>> causes it to redirect to the cas login page. >>> >>> Note that I took out the LDAP auth from deployerConfigContext.xml to make >>> sure that only SPNEGO would be used. >>> >>> I set up everything as the SPNEGO page says to. >>> >>> I suspect that my problem is with one of the following: >>> >>> 1) <property name="loginConf" value="/WEB-INF/login.conf" /> >>> >>> Does this have to be more explicit, like a full real path? >>> >>> 2) Kerberos >>> >>> The keys that my AD admin generated are: >>> >>> HTTP/<fqdn unix hostname>@<AD Domain> >>> >>> as opposed to >>> >>> HTTP/<fqdn unix hostname>@ <kerberos realm> >>> >>> Will this not work? >>> >>> 3) I saw a post in which someone came to the conclusion that the "user >>> account can't be used for both SPN and binding the LDAP server" >>> >>> The format isn't the same (the kerberos user is a user@<kerberos >>> realm>, LDAP auth user is in DN format), but the user they both reference is >>> the same one. >>> >>> Am I misunderstanding something? >>> >>> I figure I am getting very close to making this work >>> deployerConfigContext.xml is posted below. >>> >>> Thanks for any help! >>> >>> Brian >>> >>> >>> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- >>> >>> >>> <?xml version="1.0" encoding="UTF-8"?> >>> <beans >>> xmlns="http://www.springframework.org/schema/beans";<http://www.springframework.org/schema/beans> >>> >>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";<http://www.w3.org/2001/XMLSchema-instance> >>> >>> xmlns:p="http://www.springframework.org/schema/p";<http://www.springframework.org/schema/p> >>> >>> xmlns:sec="http://www.springframework.org/schema/security";<http://www.springframework.org/schema/security> >>> xsi:schemaLocation="http://www.springframework.org/schema/beans >>> http://www.springframework.org/schema/beans/spring-beans-3.0.xsd >>> http://www.springframework.org/schema/security >>> http://www.springframework.org/schema/security/spring-security-3.0.xsd";> >>> >>> <bean id="authenticationManager" >>> >>> class="org.jasig.cas.authentication.AuthenticationManagerImpl"> >>> <property name="credentialsToPrincipalResolvers"> >>> <list> >>> <bean >>> >>> class="org.jasig.cas.authentication.principal.UsernamePasswordCredentialsToPrincipalResolver" >>> /> >>> <bean >>> >>> class="org.jasig.cas.support.spnego.authentication.principal.SpnegoCredentialsToPrincipalResolver" >>> /> >>> <bean >>> >>> class="org.jasig.cas.authentication.principal.HttpBasedServiceCredentialsToPrincipalResolver" >>> /> >>> </list> >>> </property> >>> <property name="authenticationHandlers"> >>> <list> >>> <bean >>> class="org.jasig.cas.support.spnego.authentication.handler.support.JCIFSSpnegoAuthenticationHandler"> >>> <property name="authentication"> >>> <bean >>> class="jcifs.spnego.Authentication" /> >>> </property> >>> <property >>> name="principalWithDomainName" value="false" /> >>> <property name="NTLMallowed" >>> value="true"/> >>> </bean> >>> <bean >>> class="org.jasig.cas.authentication.handler.support.HttpBasedServiceCredentialsAuthenticationHandler"> >>> <property name="httpClient" >>> ref="httpClient" /> >>> </bean> >>> </list> >>> </property> >>> </bean> >>> >>> <sec:user-service id="userDetailsService"> >>> <sec:user name="battags" password="notused" >>> authorities="ROLE_ADMIN" /> >>> </sec:user-service> >>> >>> <bean id="attributeRepository" >>> >>> class="org.jasig.services.persondir.support.StubPersonAttributeDao"> >>> <property name="backingMap"> >>> <map> >>> <entry key="uid" value="uid" /> >>> <entry key="eduPersonAffiliation" >>> value="eduPersonAffiliation" /> >>> <entry key="groupMembership" >>> value="groupMembership" /> >>> </map> >>> </property> >>> </bean> >>> >>> <bean id="serviceRegistryDao" >>> class="org.jasig.cas.services.InMemoryServiceRegistryDaoImpl" /> >>> >>> <bean name="jcifsConfig" >>> class="org.jasig.cas.support.spnego.authentication.handler.support.JCIFSConfig"> >>> <property name="jcifsServicePrincipal" value= >>> "[email protected]" <[email protected]> /> >>> <property name="jcifsServicePassword" value="xxxxx" /> >>> <property name="kerberosDebug" value="true" /> >>> <property name="kerberosRealm" value="my.domain.tld" /> >>> <property name="kerberosKdc" >>> value="ad-server.my.domain.tld" /> >>> <property name="loginConf" value="/WEB-INF/login.conf" /> >>> </bean> >>> >>> </beans> >>> >>> >>> -- >>> You are currently subscribed to [email protected] as: >>> [email protected] >>> >>> >>> To unsubscribe, change settings or access archives, see >>> http://www.ja-sig.org/wiki/display/JSG/cas-user >>> >>> >> -- >> You are currently subscribed to [email protected] as: [email protected] >> >> To unsubscribe, change settings or access archives, see >> http://www.ja-sig.org/wiki/display/JSG/cas-user >> >> >> -- >> You are currently subscribed to [email protected] as: >> [email protected] >> >> To unsubscribe, change settings or access archives, see >> http://www.ja-sig.org/wiki/display/JSG/cas-user >> >> > > > -- > Bill Markmann > > Counterpoint Consulting, Inc. > (p) 571-338-2455 > (f) 202-403-3425 > (e) [email protected] > (w) http://www.counterpointconsulting.com/ > > -- > You are currently subscribed to [email protected] as: [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user > > > -- Bill Markmann Counterpoint Consulting, Inc. (p) 571-338-2455 (f) 202-403-3425 (e) [email protected] (w) http://www.counterpointconsulting.com/ -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
