Hi Hasanthi,

On Tue, Jun 21, 2016 at 3:01 PM, Hasanthi Purnima Dissanayake <
[email protected]> wrote:

> Hi Fara/Shazni,
>
> Thanks for the feedback. Here I'm using a sample standalone Java server
> and C# client which communicates through a socket. And I'm using the fully
> qualified name as you suggested.
>
> As this error comes when validating the server token the the issue should
> be with the SPN of java server. Following is the code snippet which I'm
> using generate the server token.
>
>                     GSSName serviceName = manager.createName("[email protected]",
> GSSName.NT_USER_NAME);
>

You seem to be using the service account here. Can you try using the
Service Principal name under which you registered the java sever (that will
be something like HTTP/[email protected]) instead. As Shazni has
pointed out use the SPN name along with realm at all places. I faced a
similar situation during implementing IWA using Kerberos, and giving the
SPN name along with the domain did the trick for me.



>                     GSSCredential serviceCredentials =
> manager.createCredential(serviceName,
>                             GSSCredential.INDEFINITE_LIFETIME, spnegoOid,
> GSSCredential.ACCEPT_ONLY);
>                     GSSContext context =
> manager.createContext(serviceCredentials);
>                     serverToken = context.acceptSecContext(serviceTicket,
> 0, serviceTicket.length);
>
> Here IS.LOCAL is the realm name and wso2 is the account name. When
> executing this I got a value for 'serverToken' and the exception occurs
> when the client uses this 'serverToken' to validate.
>
> Thanks,
>
> Hasanthi Dissanayake
>
> Software Engineer | WSO2
>
> E: [email protected]
> M :0718407133| http://wso2.com <http://wso2.com/>
>
> On Tue, Jun 21, 2016 at 2:32 PM, Shazni Nazir <[email protected]> wrote:
>
>> HI Hasanthi,
>>
>> I've one question. What's this Java Server? Is it a standalone server you
>> have custom written or is it a WSO2 server?
>>
>> When it comes to Kerberos related work for SOAP, we faced a couple of
>> issues with related to service principal (SPN) name. In that discrepancies
>> were noticed when using service principal name without a realm. For
>> example, if the service principal name is, esb/localhost and the realm is
>> WSO2.ORG, you have to specify the SPN as a fully qualified name; like
>> esb/[email protected]. I'm not sure whether your issue is related to
>> this. Maybe you can check if that's the case.
>>
>> Shazni Nazeer
>> Mob : +94 777737331
>> LinkedIn : http://lk.linkedin.com/in/shazninazeer
>> Blog : http://shazninazeer.blogspot.com
>>
>> On Tue, Jun 21, 2016 at 2:20 PM, Farasath Ahamed <[email protected]>
>> wrote:
>>
>>> Hi Hasanthi,
>>>
>>> Assuming that you are using an AD as the Kerberos Server, Have you
>>> registered a Service Principal for both the C# client and Java Server in
>>> the AD?
>>>
>>> You can do this using the setspn.exe. Also, when you registering the SPN
>>> register all possible value that principal can take.
>>> For eg: Let's say the hostname of your java server is *server.is.local*,
>>> you can do
>>>
>>> setspn -A HTTP/server.is.local <service_account>
>>> setspn -A HTTP/server <service_account>
>>>
>>> to add your java server as a service principal in the Kerberos Server.
>>> You can do the same for the C# client as well. Can you check whether you
>>> have already registered the Service Principals by listing them out using
>>> commands specified in [1]
>>>
>>> [1]
>>> https://blogs.msdn.microsoft.com/psssql/2009/02/13/searching-for-duplicate-spns-got-a-little-easier/
>>>
>>> Thanks,
>>>
>>> Farasath Ahamed
>>> Software Engineer,
>>> WSO2 Inc.; http://wso2.com
>>> lean.enterprise.middleware
>>>
>>>
>>> Email: [email protected]
>>> Mobile: +94777603866
>>> Blog: blog.farazath.com
>>> Twitter: @farazath619 <https://twitter.com/farazath619>
>>>
>>> On Tue, Jun 21, 2016 at 2:03 PM, Hasanthi Purnima Dissanayake <
>>> [email protected]> wrote:
>>>
>>>> Hi I'm implementing Kerberos communication between java (GSSAPI) to
>>>> C#(SSPI).
>>>>
>>>> The KDC is an Active Directory. When it comes to Java client vs Java
>>>> server and C# client vs C# Server, for both the scenarios this works fine.
>>>>
>>>> When using Java client - server the process happens as below and it
>>>> works fine:
>>>> * Client uses JAAS and creates TGT in client side
>>>> * Server uses JAAS and creates TGT in server side
>>>> * Client uses service principle name of the server to create the
>>>> context and using that context it invokes initSecContext and creates SGT
>>>> and pass it to the server
>>>> * Server uses acceptSecContext() to validate the SGT
>>>>
>>>> When using C# client  -server the process happens as below and it works
>>>> fine too
>>>> *  Client creates credentials and invokes init() to create client TGT
>>>> * Client passes this TGT to the server and server passes this TGT to
>>>> accept(), to validate the TGT , then generates server TGT and passes it to
>>>> client
>>>> * Client gets the TGT from server and passes it to int() to create the
>>>> SGT
>>>> * Client passes this SGT to server and server uses accept() to validate
>>>> the SGT
>>>>
>>>> When using C# client  - Java server te process happens as below. [1][2]
>>>> * Client creates credentials and invokes init() to create TGT
>>>> * Client passes this TGT to the server and server use this TGT and
>>>> passes it to acceptSecContext() to validate the TGT and to generate server
>>>> TGT and passes it to client
>>>> * Client gets the TGT from server and passes it to int() to create the
>>>> SGT and pass the SGT to server.
>>>> * Server uses acceptSecContext() to validate the SGT
>>>>
>>>> When I'm implementing the third use case it fails to validate the TGT
>>>> of Java server from the C# client side with the following exception.
>>>>
>>>> "Failed to invoke InitializeSecurityContext for a client. The specified
>>>> principle is not known in the authentication system."
>>>>
>>>> [1]
>>>> https://msdn.microsoft.com/en-us/library/windows/desktop/aa380496(v=vs.85).aspx
>>>> [2] https://msdn.microsoft.com/en-us/library/ms995352.aspx
>>>>
>>>> Any suggestion is highly appreciated to recover this issue.
>>>>
>>>> Thanks,
>>>>
>>>>
>>>>
>>>> Hasanthi Dissanayake
>>>>
>>>> Software Engineer | WSO2
>>>>
>>>> E: [email protected]
>>>> M :0718407133| http://wso2.com <http://wso2.com/>
>>>>
>>>
>>>
>>
>
Thanks,
Farasath
_______________________________________________
Dev mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/dev

Reply via email to