Groups | Search | Server Info | Login | Register
Groups > comp.protocols.kerberos > #5403
| From | Michael B Allen <ioplex@gmail.com> |
|---|---|
| Newsgroups | comp.protocols.kerberos |
| Subject | Re: IAKERB Starter Credentials Solution |
| Date | 2025-04-26 15:33 -0400 |
| Organization | TNet Consulting |
| Message-ID | <mailman.185.1745696008.2322.kerberos@mit.edu> (permalink) |
| References | <CAGMFw4jy=ceiETpLu9Aa1W0TYnjHedW3DMx7fss4XFrD-HzN=w@mail.gmail.com> <aA0Lm7Ln7IU3t22Z@ubby> <CAGMFw4imyZmEsWkX0KRqkHyPsCZiiKad1dDcP1hwNxzcFV4eRg@mail.gmail.com> |
On Sat, Apr 26, 2025 at 12:36 PM Nico Williams <nico@cryptonector.com> wrote: > Rather than a callback I'd prefer to have a new major status code that > indicates that the application must call a function to extract the > prompts / supply answers, and this would use the partial security > context handle to sequence things. > Yeah, when trying to do iakerb_gss_init_sec_context and there's no TGT (or Ticket), then just returning an error is reasonable. Applications would have to add new code to set a callback or catch an error so neither way is going to be transparent. But of course applications are not going to use the gss_acquire_cred_* functions (and they probably should not). When the user gets an error, they will have to use some utility that knows to use gss_acquire_cred_with_password with IAKERB to some IAKERB-aware service. Then, with a TGT in their ccache, the application should now init IAKERB successfully. Correct? Mike -- Michael B Allen Java AD DS Integration https://www.ioplex.com/ <http://www.ioplex.com/>
Back to comp.protocols.kerberos | Previous | Next | Find similar
Re: IAKERB Starter Credentials Solution Michael B Allen <ioplex@gmail.com> - 2025-04-26 15:33 -0400
csiph-web