GSSAPI bindings for C#/.NET

21 Mar 2006 8:55 PM

Ian

All,

I was able to find an IETF document proposing some specifications for
GSSAPI C# bindings
(http://www.ietf.org/internet-drafts/draft-ietf-kitten-gssapi-csharp-bindings-00.txt),
but I was unable to find any suitable implementation. The goal is to
use MIT Kerberos to authenticate to remote services. Anyone have any
pointers on this? I'm beginning to feel like the best bet will be to
P/Invoke the MIT Kerberos libs to do this, but it seems like a pure
..NET implementation would obviously be preferable.

There are some Novell-namespaced classes in the most recent mono class
sources that seemed to bear some resemblance to these IETF bindings,
but these just seemed to reference Java classes to provide the actual
implementation.

Further to this, is it possible to use some facilities of the
System.DirectoryServices namespace to communicate with remote
kerberized services without your KDC being AD?

Thanks,
Ian

21 Mar 2006 9:08 PM

Dominick Baier [DevelopMentor]

Hi,

NegotiateStream in .NET 2.0 implements Kerberos V5 client and server.

not sure about S.DS - joe would know i guess.

---------------------------------------
Dominick Baier - DevelopMentor
http://www.leastprivilege.com

Show quoteHide quote

> All,
>
> I was able to find an IETF document proposing some specifications for
> GSSAPI C# bindings
> (http://www.ietf.org/internet-drafts/draft-ietf-kitten-gssapi-csharp-b
> indings-00.txt),
> but I was unable to find any suitable implementation. The goal is to
> use MIT Kerberos to authenticate to remote services. Anyone have any
> pointers on this? I'm beginning to feel like the best bet will be to
> P/Invoke the MIT Kerberos libs to do this, but it seems like a pure
> .NET implementation would obviously be preferable.
> There are some Novell-namespaced classes in the most recent mono class
> sources that seemed to bear some resemblance to these IETF bindings,
> but these just seemed to reference Java classes to provide the actual
> implementation.
>
> Further to this, is it possible to use some facilities of the
> System.DirectoryServices namespace to communicate with remote
> kerberized services without your KDC being AD?
>
> Thanks,
> Ian

21 Mar 2006 9:42 PM

Joe Kaplan (MVP - ADSI)

If he wants raw Kerberos, he needs to either use NegotiateStream, p/invoke
SSPI (InitializeSecurityContext for the client side), or p/invoke GSSAPI or
another Kerb library directly. NegotiateStream would be the easiest by far,
but I'm not sure how well it will interop with non-MS kerb implementations.

S.DS won't help here. It is basically for doing LDAP. LDAP on Windows can
use Kerb for auth, but you can't get to it directly. It is rolled up in the
LDAP API through its SASL implementation.

Joe K.

Show quoteHide quote

"Dominick Baier [DevelopMentor]" <dbaier@pleasepleasenospamdevelop.com>
wrote in message news:4580be631989bb8c81b4b12fb1d70@news.microsoft.com...
> Hi,
> NegotiateStream in .NET 2.0 implements Kerberos V5 client and server.
>
> not sure about S.DS - joe would know i guess.
>
> ---------------------------------------
> Dominick Baier - DevelopMentor
> http://www.leastprivilege.com
>
>> All,
>>
>> I was able to find an IETF document proposing some specifications for
>> GSSAPI C# bindings
>> (http://www.ietf.org/internet-drafts/draft-ietf-kitten-gssapi-csharp-b
>> indings-00.txt),
>> but I was unable to find any suitable implementation. The goal is to
>> use MIT Kerberos to authenticate to remote services. Anyone have any
>> pointers on this? I'm beginning to feel like the best bet will be to
>> P/Invoke the MIT Kerberos libs to do this, but it seems like a pure
>> .NET implementation would obviously be preferable.
>> There are some Novell-namespaced classes in the most recent mono class
>> sources that seemed to bear some resemblance to these IETF bindings,
>> but these just seemed to reference Java classes to provide the actual
>> implementation.
>>
>> Further to this, is it possible to use some facilities of the
>> System.DirectoryServices namespace to communicate with remote
>> kerberized services without your KDC being AD?
>>
>> Thanks,
>> Ian
>
>