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("wso2@IS.LOCAL",
GSSName.NT_USER_NAME);
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: hasan...@wso2.com
M :0718407133| http://wso2.com <http://wso2.com/>
On Tue, Jun 21, 2016 at 2:32 PM, Shazni Nazir <sha...@wso2.com> 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/
> localh...@wso2.org. 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 <farasa...@wso2.com>
> 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: farasa...@wso2.com
>> Mobile: +94777603866
>> Blog: blog.farazath.com
>> Twitter: @farazath619 <https://twitter.com/farazath619>
>>
>> On Tue, Jun 21, 2016 at 2:03 PM, Hasanthi Purnima Dissanayake <
>> hasan...@wso2.com> 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: hasan...@wso2.com
>>> M :0718407133| http://wso2.com <http://wso2.com/>
>>>
>>
>>
>
_______________________________________________
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev
