Maybe a more detailed explanation is necessary here. We managed a 24x7 set of Batch Queuing Servers.
We have thousands of users. Users often work under project deadlines and stack-up the Batch Queuing Manager with many jobs. Once, the number of jobs hit 250,000. We are moving toward Kerberos and NFS V4 to protect sensitive data. Credentials are UID based. Once a user has a Credential, that interactive user can run as many jobs as necessary, even log out and back in, until the Credential expires, without having to renew it or create a new one. In integrating that into the Batch Queueing System, here is the sequence of events: 1. When user submits a job, Kerberos username & password prompted for 2. Username & password immediately encrypted. 3. Clear text entry memory locations are cleaned. 4. Kerberos username and password are validated to be correct. 5. Encrypted username & password now part of job stream. 6. Sometime in the future Batch Queuing Master sends job to Server. 7. Batch Queueing Server, needs to have a Kerberos Credential for job. 8. If one exists it will be used. 9. If expiration is less than 25% of endtime - starttime away, it gets new one. A. If one doesn't exist, one is obtained. B. It never does a renew. Job run time could exceed maximum lifetime. C. Periodically, get new Credential if expiration time is nearing. I have coded steps 1 - 7 into the Batch Queuing System Submitter and Server using API calls. Granted, step 5 is risky, but management has accepted it, and I have to do it. Step 8 is where I am now. Since klist finds existing Credentials I'm working doing something similarly within the Batch Queuing Server with API calls. Step B was my choice to make coding a little easier. Does this give you a little more info about my thought process? :-) Thanks for hangin' in there with me. I'm under a deadline to have this all working by the end of October. This was my first exposure to Kerberos so I'm learning as I go. ---- Not all who wander are lost. | ---- ___o | [EMAIL PROTECTED] Chuck Keagle | ------- \ <, | Work: (425) 865-1488 Enterprise Servers: HPC | ----- ( )/ ( ) | Cell: (425) 417-3434 http://card.web.boeing.com/Webcard.cfm?id=73990 > -----Original Message----- > From: Ken Hornstein [mailto:[EMAIL PROTECTED] > Sent: Friday, September 29, 2006 11:24 AM > To: Keagle, Chuck > Cc: kerberos@mit.edu > Subject: Re: API help with ticket expiry > > >If the Credential is available, I'm trying to figure how > long it will > >be be fore it expires. I'm not counting on magic. Just > looking at, if > >I already have a Credential, I might not have to generate a new one. > > But ... the existing APIs already give you that (the ones I > talked about). > > I have to confess that upon rereading your original note, I > am confused as to what exactly the issues are. > > --Ken >
________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos