The Java application we have written, runs on a Java client which request an AP_REQ
from a centralized KDC any time this is needed. The Java application uses the
API provided by the Java Generic Security Services JGSS API. Using these APIs
we have been able to get from the KDC a Kerberos token (AP-REQ) but we do not see
any way to get a service ticket from the KDC. In addition we do not
see how the java client application can locally create an authenticator.
Problems to solve
We have not been able to find any information how to generate in our client application
a kerberos token (AP-REQ) using the cached value of the service ticket and such a ghost authenticator.
Basically, we have these main questions:
1. How a Java client application can interact with a KDC in order to get a plain Kerberos service ticket
and not a kerberos token (AP-REQ)?
2. How a Java client application can generate locally an authenticator?
3. How a Java client application can generate a Kerberos token (AP-REQ) starting from
a locally cached Kerberos service ticket and a newly locally generated authenticator?
Based on your knowledge and experience can you help us in providing any clue, link, sample, or
whatever you think can solve our questions?
thanks for your help
This topic has been locked.
1 reply Latest Post - 2012-12-18T13:09:24Z by JPdev
Pinned topic Request information, help about java - kerberos and (AP-REQ) -
Answered question This question has been answered.
Unanswered question This question has not been answered yet.
Updated on 2012-12-18T13:09:24Z at 2012-12-18T13:09:24Z by JPdev
JPdev 270003K04U18 PostsACCEPTED ANSWER
Re: Request information, help about java - kerberos and (AP-REQ) -2012-12-18T13:09:24Z in response to SystemAdminHello,
You can't do that from a client.
In the case of the Kerberos V5 mechanism, there is no more than one round trip of tokens during context establishment. The client first sends a token generated by its initSecContext() containing the Kerberos AP-REQ message . In order to generate the AP-REQ message, the Kerberos provider obtains a service ticket for the target SERVER using the client's TGT. The service ticket is encrypted with the SERVER's long-term secret key and is encapsulated as part of the AP-REQ message. After the SERVER receives this token, it is passed to the acceptSecContext() method which decrypts the service ticket and authenticates the client.
Note this is the Oracle/sun explanation of this particular complicated trick.
Hope this help