Hello, This is my first experience using Kerberos and lucky me it's with Tomcat on Linux. We're only using it to access an MSSQL database for now - no single sign-on (yet). So far the testing has been done on one server and it's been pretty successful. We're now looking to enable this functionality on the other two servers that make up this environment. My questions are mostly around best practices when it comes to managing tickets with multiple tomcat instances for a single app so I'll just get to it:
- We will have three tomcat instances on three different linux servers all running the same application that will be connecting to the same MSSQL instances. Here are the two options I've come up with that make the most sense right now - 1. Have each Tomcat instance use the same SPN and get tickets on their own respective servers. The means that at any given time there would be three active tickets for the same SPN but I would have each tomcat instance doing kinits and kdestroys as the app is started or stopped. Or 2. I need to create a new SPN (and new AD accounts?) for each tomcat instance accessing the MSSQL database and each tomcat instance would be doing kinits and kdestroys with its own ticket. I'm leaning towards option #1 but perhaps someone has another option or can lend some thoughts as to which way I should proceed? - On each server, we need to go through a process that requests a ticket when tomcat starts, uses the ticket as long as the JVM is running and then destroys the ticket when the JVM is stopped. I'm thinking that I modify the tomcat startup script in /etc/init.d so that when the specific tomcat option is called the following things happen: start:: - kdestroy is called to clear any existing tickets in the tomcat ticket cache (cache is in custom location w/ custom filename) - kinit is called to request a renewable ticket - lets say 14 days - tomcat process starts as normal stop:: - tomcat process stops as normal - kdestroy is called to clear any existing tickets in the tomcat ticket cache (cache is in custom location w/ custom filename) Once the ticket has been requested, I would have a crontab job go out and do renewals every 12 hours - noon and midnight perhaps? Does a ticket renewal in the middle of the day become too risky with the application running in production? Then once a week, I would have the application stopped for DB re-indexing, other maintenance, etc. We should never get to the point where the JVM is running for 2 weeks and then causes a problem when the ticket expires. Would these align with best practices that others have done or seen in similar scenarios? Do the ticket lifespans and renewal timeframes make sense or should they be less often / more often? I really appreciate any feedback or thoughts on this - thanks! - Jim
