Re: [Dev] Kerberos communication fails with java server to C# client

[Hasanthi Purnima Dissanayake]

Hi All,
The name-formats used in GSS-API are somewhat different than the
name-formats used in SSPI.  So the C# client could not identify the   SPN,
as the SPN name of the Java server is not windows compatible. After
providing the SPN name without realm when creating the client credentials
in C# client side the above problem solved.

Thanks Fara and Shazni for the suggestions and all the help. :)

Hasanthi Dissanayake

Software Engineer | WSO2

E: hasan...@wso2.com
M :0718407133| http://wso2.com 

On Tue, Jun 21, 2016 at 4:36 PM, Farasath Ahamed  wrote:

> Hi Hasanthi,
>
>
> On Tue, Jun 21, 2016 at 3:01 PM, Hasanthi Purnima Dissanayake <
> hasan...@wso2.com> 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("wso2@IS.LOCAL", 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/server.is.local@IS.LOCAL) 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: hasan...@wso2.com
>> M :0718407133| http://wso2.com 
>>
>> On Tue, Jun 21, 2016 at 2:32 PM, Shazni Nazir  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 37331
>>> LinkedIn : http://lk.linkedin.com/in/shazninazeer
>>> Blog : http://shazninazeer.blogspot.com
>>>
>>> On Tue, Jun 21, 2016 at 2:20 PM, Farasath Ahamed 
>>> 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 
 setspn -A HTTP/server 

 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 

 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 

Re: [Dev] Kerberos communication fails with java server to C# client

[Farasath Ahamed]

Hi Hasanthi,


On Tue, Jun 21, 2016 at 3:01 PM, Hasanthi Purnima Dissanayake <
hasan...@wso2.com> 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("wso2@IS.LOCAL",
> 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/server.is.local@IS.LOCAL) 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: hasan...@wso2.com
> M :0718407133| http://wso2.com 
>
> On Tue, Jun 21, 2016 at 2:32 PM, Shazni Nazir  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 37331
>> LinkedIn : http://lk.linkedin.com/in/shazninazeer
>> Blog : http://shazninazeer.blogspot.com
>>
>> On Tue, Jun 21, 2016 at 2:20 PM, Farasath Ahamed 
>> 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 
>>> setspn -A HTTP/server 
>>>
>>> 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 
>>>
>>> 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 

Re: [Dev] Kerberos communication fails with java server to C# client

[Hasanthi Purnima Dissanayake]

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 

On Tue, Jun 21, 2016 at 2:32 PM, Shazni Nazir  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 37331
> LinkedIn : http://lk.linkedin.com/in/shazninazeer
> Blog : http://shazninazeer.blogspot.com
>
> On Tue, Jun 21, 2016 at 2:20 PM, Farasath Ahamed 
> 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 
>> setspn -A HTTP/server 
>>
>> 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 
>>
>> 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 

Re: [Dev] Kerberos communication fails with java server to C# client

[Shazni Nazir]

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 37331
LinkedIn : http://lk.linkedin.com/in/shazninazeer
Blog : http://shazninazeer.blogspot.com

On Tue, Jun 21, 2016 at 2:20 PM, Farasath Ahamed  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 
> setspn -A HTTP/server 
>
> 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 
>
> 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 
>>
>
>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Kerberos communication fails with java server to C# client

[Farasath Ahamed]

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 
setspn -A HTTP/server 

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 

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 
>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

[Dev] Kerberos communication fails with java server to C# client

[Hasanthi Purnima Dissanayake]

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 
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev