API help with ticket expiry - Kerberos

This is a discussion on API help with ticket expiry - Kerberos ; I'm working on making a batch queuing manager get a ticket for a user job that will execute without user interface in such a way the user doesn't have to put Kerberos username and password in clear text in the ...

+ Reply to Thread
Results 1 to 8 of 8

Thread: API help with ticket expiry

  1. API help with ticket expiry

    I'm working on making a batch queuing manager get a ticket for a user
    job that will execute without user interface in such a way the user
    doesn't have to put Kerberos username and password in clear text in the
    job stream. When user submits job, it may or may not run until after
    the current ticket has expired. Then the job could run longer than a
    ticket lifetime.

    My plan is to create a new ticket whenever the current ticket has less
    than 2 hours left before expiration.

    I have been able to create the ticket using encrypted username/password
    and am now working on making sure the ticket doesn't expire before the
    job ends. Granted, this isn't the safest mechanism, but users don't
    want jobs to abort if ticket expires when they are not around.

    krb5_timeofday() will obtain what I need (seconds since epoch) for the
    current time-of-day.

    How would one go about obtaining the seconds since epoch for the ticket
    expiration time-of-day?

    I've Scoured the API list and haven't found one to do it easily. I
    could take the time and date and convert them to seconds since the epoch
    but would like to find an easier way to do it.

    Thanks.

    ----
    Not all who wander are lost.

    | ---- ___o | chuck.keagle@boeing.com
    Chuck Keagle | ------- \ <, | Work: (425) 865-1488
    Enterprise Servers: HPC | ----- ( )/ ( ) | Cell: (425) 417-3434
    http://card.web.boeing.com/Webcard.cfm?id=73990
    <>

    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  2. Re: API help with ticket expiry

    >I have been able to create the ticket using encrypted username/password
    >and am now working on making sure the ticket doesn't expire before the
    >job ends. Granted, this isn't the safest mechanism, but users don't
    >want jobs to abort if ticket expires when they are not around.
    >
    >krb5_timeofday() will obtain what I need (seconds since epoch) for the
    >current time-of-day.
    >

    How would one go about obtaining the seconds since epoch for the ticket
    >expiration time-of-day?


    Assuming you have a krb5_ticket structure around (actually, I suspect you
    really have a krb5_creds structure, so lets use that), you can find
    the expiration time in creds.times.endtime structure member.

    --Ken
    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  3. RE: API help with ticket expiry

    Thanks for the pointer to look at starttime and endtime. I'm pretty new
    to Kerberos. Still gathering quite a chunk of knowledge.

    That should work when the same job is running a long time and needs to
    update the ticket.

    When the next batch job is submitted, it comes from a new execution of
    the submit program.
    This program has no left around Credential or Ticket structure. If the
    user's Credential is unexpired, I'm working the issue of not updating it
    every time the same user submits a new job. Sometimes, jobs are
    submitted hundreds at a time through higher level job execution scripts.
    Don't want to overwhelm the KDC.

    With neither a krb5_ticket nor a krb5_creds current structure, I tried
    using krb5_get_credentials using KRB5_GC_CACHED and a NULL in_cred
    parameter but an endtime of 0 comes back from that call.

    Other ideas are welcome.

    ----
    Not all who wander are lost.

    | ---- ___o | chuck.keagle@boeing.com
    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:kenh@cmf.nrl.navy.mil]
    > Sent: Wednesday, September 27, 2006 9:14 PM
    > To: Keagle, Chuck
    > Cc: kerberos@mit.edu
    > Subject: Re: API help with ticket expiry
    >
    > >I have been able to create the ticket using encrypted

    > username/password
    > >and am now working on making sure the ticket doesn't expire

    > before the
    > >job ends. Granted, this isn't the safest mechanism, but users don't
    > >want jobs to abort if ticket expires when they are not around.
    > >
    > >krb5_timeofday() will obtain what I need (seconds since

    > epoch) for the
    > >current time-of-day.
    > >

    > How would one go about obtaining the seconds since epoch for
    > the ticket
    > >expiration time-of-day?

    >
    > Assuming you have a krb5_ticket structure around (actually, I
    > suspect you really have a krb5_creds structure, so lets use
    > that), you can find the expiration time in
    > creds.times.endtime structure member.
    >
    > --Ken
    >


    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  4. Re: API help with ticket expiry

    >When the next batch job is submitted, it comes from a new execution of
    >the submit program.


    Well, this is the problem. If there are no credentials available, you
    can't magically generate them.

    --Ken
    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  5. RE: API help with ticket expiry

    If the Credential is available, I'm trying to figure how long it will be before 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.

    Maybe the klist source will show me what needs to be done. If you don't have a Credential it shows none. If you have a Credential, it shows the expiration date/time.

    -----
    Not all who wander are lost!

    Chuck Keagle | ---- ___o | chuck.keagle@boeing.com
    Enterprise Servers | ------- \ <, | work: (425)865-1488
    High Performance Computing | ----- ( )/ ( ) | cell: (425)417-3434



    From: Ken Hornstein
    Sent: Thu 9/28/2006 10:33 PM
    To: Keagle, Chuck
    Cc: kerberos@mit.edu
    Subject: Re: API help with ticket expiry


    >When the next batch job is submitted, it comes from a new execution of
    >the submit program.


    Well, this is the problem. If there are no credentials available, you
    can't magically generate them.

    --Ken
    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  6. Re: API help with ticket expiry



    Keagle, Chuck wrote:

    > If the Credential is available, I'm trying to figure how long it will be before 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.
    >
    > Maybe the klist source will show me what needs to be done. If you don't have a Credential it shows none. If you have a Credential, it shows the expiration date/time.
    >


    If you get a ticket good for 8 hours, and renewable for 3 days:
    kinit -l 8h -r 3d user@realm
    the MIT klist will show Valid starting, Expires and renew until times.

    The Heimdal klist -v will these as well.

    Renewable might be good for batch jobs.


    > -----
    > Not all who wander are lost!
    >
    > Chuck Keagle | ---- ___o | chuck.keagle@boeing.com
    > Enterprise Servers | ------- \ <, | work: (425)865-1488
    > High Performance Computing | ----- ( )/ ( ) | cell: (425)417-3434
    >
    >
    >
    > From: Ken Hornstein
    > Sent: Thu 9/28/2006 10:33 PM
    > To: Keagle, Chuck
    > Cc: kerberos@mit.edu
    > Subject: Re: API help with ticket expiry
    >
    >
    >
    >>When the next batch job is submitted, it comes from a new execution of
    >>the submit program.

    >
    >
    > Well, this is the problem. If there are no credentials available, you
    > can't magically generate them.
    >
    > --Ken
    > ________________________________________________
    > Kerberos mailing list Kerberos@mit.edu
    > https://mailman.mit.edu/mailman/listinfo/kerberos
    >
    >


    --

    Douglas E. Engert
    Argonne National Laboratory
    9700 South Cass Avenue
    Argonne, Illinois 60439
    (630) 252-5444
    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  7. 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


  8. RE: API help with ticket expiry

    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 | chuck.keagle@boeing.com
    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:kenh@cmf.nrl.navy.mil]
    > 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


+ Reply to Thread