[
https://issues.apache.org/jira/browse/DIRSERVER-2156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15355126#comment-15355126
]
Emmanuel Lecharny commented on DIRSERVER-2156:
----------------------------------------------
My understanding is that no flag is sent by the client to the server, so the
decision to add an Address in the ticket should be based on teh fact that there
is an Address in teh initial request (and in this very case, it's null).
Now, I have to check the code to see where we add the client's address in the
ticket. My understanding is that if we don't have one, then we pick the one
provided by the network layer, which is not necessarily a good idea.
The code that set the Address is :
{noformat}
public final class TicketGrantingService
...
private static void generateTicket( TicketGrantingContext tgsContext )
throws KerberosException,
InvalidTicketException
{
...
newTicketPart.setClientAddresses(
tgt.getEncTicketPart().getClientAddresses() );
{noformat}
I guess that checking for the TGT ticket to see if the Address is null is
useless, because it's not null at this point. That means the TGT ticket has
already set this Adress beforehand. And as we can see in teh code :
{noformat}
public void messageReceived( IoSession session, Object message )
{
...
InetAddress clientAddress = ( ( InetSocketAddress )
session.getRemoteAddress() ).getAddress();
KdcReq request = ( KdcReq ) message;
KerberosMessageType messageType = request.getMessageType();
try
{
switch ( messageType )
{
case AS_REQ:
AuthenticationContext authContext = new
AuthenticationContext();
...
authContext.setClientAddress( clientAddress );
AuthenticationService.execute( authContext );
...
{noformat}
So we get an AS request, we get the client' address from the network layer, and
it's propagated from there.
I wonder if replacing the line where we store the address by :
{noformat}
...
if ( request.getKdcReqBody().getAddresses() != null )
{
authContext.setClientAddress( clientAddress );
}
...
{noformat}
would work (and if it's correct, assuming we might want to take the first
address fro teh KDC Req body structure...
Can you try that ?
> ApacheDS issues TGT kerberos ticket with address on IBM java
> ------------------------------------------------------------
>
> Key: DIRSERVER-2156
> URL: https://issues.apache.org/jira/browse/DIRSERVER-2156
> Project: Directory ApacheDS
> Issue Type: Bug
> Affects Versions: 2.0.0-M20
> Reporter: Martin Choma
> Attachments: IBMJavaIdentityPropagation.log,
> IBMJavaIdentityPropagation.pcapng, OracleJavaIdentityPropagation.log,
> OracleJavaIdentityPropagation.pcapng
>
>
> ApacheDS issues TGT kerberos ticket with address on IBM java , even if
> noaddresses = true is explicitelly set in krb5.conf.
> Address in ticket causing problem, because ApacheDS check address in ticket
> with address of connection. And that leads to error "error 38 Incorrect net
> address"
> I dont see this issue on IBM java and Active Directory, for instance, so I
> think it is not problem of client code.
> Also note that running ApacheDS with openJDK and oracle java I also don't
> see this.
> Only problematic combination is is ApacheDS vs. IBM java 8
> Tested use case is identity propagation / delegation.
> In attachment you can find relevant log with
> org.apache.directory.server.KERBEROS_LOG set to DEBUG for oracle and ibm
> java.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)